Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding Polymer to a page causes Typekit fonts to break #408

Closed
ithinkihaveacat opened this issue Jan 28, 2014 · 15 comments
Closed

Adding Polymer to a page causes Typekit fonts to break #408

ithinkihaveacat opened this issue Jan 28, 2014 · 15 comments

Comments

@ithinkihaveacat
Copy link

For some reason, simply adding platform.js and polymer.js to an HTML page breaks Typekit fonts.

Note that because of Typekit's policies, custom fonts will only appear on jsbin.com, localhost, and a few other domains. I can add additional domains if necessary.

Also, it's not JS Bin's JavaScript that's causing the problem; the same bug occurs on a completely static domain—with, without.

@ithinkihaveacat
Copy link
Author

Sorry, clicked the wrong button. This is still a problem!

@sjmiles
Copy link
Contributor

sjmiles commented Jan 28, 2014

polymer.js doesn't seem to matter here, only platform.js, so it's likely the problem is a typekit incompatibility with the ShadowDOM poyfill.

For the record, you must load platform.js first in any document to give ShadowDOM polyfill the best hope for compatibility.

In this case, loading platform.js first doesn't solve the problem, so it's likely that typekit is using one of the few remaining incompatible incantations.We'll have to study it to have more details.

@ithinkihaveacat
Copy link
Author

Interestingly removing Bootstrap's CSS also seems to fix the problem.

(And thanks for the tip about loading order.)

@sjmiles
Copy link
Contributor

sjmiles commented Jan 28, 2014

The bootstrap css seems to break the typekit all by itself (without platform.js being involved at all).

http://jsbin.com/UnURIwIT/2/edit

@ithinkihaveacat
Copy link
Author

@sjmiles Is

http://jsbin.com/UnURIwIT/2/edit

the right link? It doesn't have any Bootstrap, but it doesn't have any Typekit on it either.

@ithinkihaveacat
Copy link
Author

Looking through the network tab in Chrome, the broken version loads Twitter's Bootstrap CSS twice, as does a version with only platform.js and a CSS file. (The first time it seems to be loaded by the HTML parser, and the second time (erroneously?) by HTMLImports.js.)

So, I'm wondering if the breakage is due to:

  1. The browser loads Twitter Bootstrap CSS.
  2. Typekit JS injects a <link rel="stylesheet" ...> into the page, which is also loaded by the browser. At this point everything looks as should but then...
  3. HTMLImports starts scanning the page, and discovers the Typekit CSS, and attempts to load it via XHR.
  4. HTMLImports' XHR load of the Typekit CSS is blocked by Access-Control-Allow-Origin.
  5. HTMLImports' XHR load of Twitter Bootstrap CSS is not blocked, and is applied on top of the existing page, which reverts the fonts back to what they were before the Typekit fonts were applied.

So the reason Typekit's fonts load without Twitter Bootstrap is that (1) and (5) never happen. Perhaps I can fix this by making sure Typekit only kicks in after platform.js has done its work. But I'm also wondering why HTMLImports is so industriously reloading and applying assets that have already been loaded.

@sjmiles
Copy link
Contributor

sjmiles commented Jan 29, 2014

Sorry, the correct link is here:

http://jsbin.com/UbufOFOK/2/edit

On Wed, Jan 29, 2014 at 1:35 AM, Michael Stillwell <notifications@github.com

wrote:

Looking through the network tab in Chrome, the broken versionhttp://jsbin.com/UnURIwIT/2/editloads Twitter's Bootstrap CSS twice, as does a
version with only platform.js and a CSS file http://jsbin.com/examoce/5.
(The first time it seems to be loaded by the HTML parser, and the second
time (erroneously?) by HTMLImports.js.)

So, I'm wondering if the breakage is due to:

  1. The browser loads Twitter Bootstrap CSS.
  2. Typekit JS injects a <link rel="stylesheet" ...> into the page,
    which is also loaded by the browser. At this point everything looks as
    should but then...
  3. HTMLImports starts scanning the page, and discovers the Typekit
    CSS, and attempts to load it via XHR.
  4. HTMLImports' XHR load of the Typekit CSS is blocked by
    Access-Control-Allow-Origin.
  5. HTMLImports' XHR load of Twitter Bootstrap CSS is not blocked, and
    is applied on top of the existing page, which reverts the fonts back to
    what they were before the Typekit fonts were applied.

So the reason Typekit's fonts load without Twitter Bootstrap is that (1)
and (5) never happen. Perhaps I can fix this by making sure Typekit only
kicks in after platform.js has done its work. But I'm also wondering why
HTMLImports is so industriously reloading and applying assets that have
already been loaded.


Reply to this email directly or view it on GitHubhttps://github.com//issues/408#issuecomment-33568864
.

@ithinkihaveacat
Copy link
Author

Interesting, that's problematic for me as well. So perhaps there's something that causes the Typekit JS to go wrong in some circumstances, and Polymer's tickling this bug.

I've logged a ticket with Typekit, will update this issue when they get back to me.

/cc @bramstein

@sjmiles
Copy link
Contributor

sjmiles commented Jan 29, 2014

All the variations have confused me at this point, so forgive me.

Polymer's tickling this bug.

When I include bootstrap.css, whether using any Polymer stuff or not, there
is a problem.

When I remove bootstrap.css, whether using any Polymer stuff of not, there
is not a problem.

Where is the case where Polymer is causing a problem by itself?

Scott

On Wed, Jan 29, 2014 at 9:18 AM, Michael Stillwell <notifications@github.com

wrote:

Interesting, that's problematic for me as well. So perhaps there's
something that causes the Typekit JS to go wrong in some circumstances, and
Polymer's tickling this bug.

I've logged a ticket with Typekit, will update this issue when they get
back to me.

/cc @bramstein https://github.com/bramstein


Reply to this email directly or view it on GitHubhttps://github.com//issues/408#issuecomment-33606751
.

@ithinkihaveacat
Copy link
Author

Yes I think both bootstrap.css and Typekit are a necessary component--Polymer just happens to turn a working page into a broken page in some circumstances. (As in the original report.)

@bramstein
Copy link

I just had a quick look at this, and this isn't really a bug, nor is anything broken. The Typekit fonts are loaded correctly, they're just overwritten by another stylesheet with a higher specificity than the Typekit styles (which are user defined in this case.) Fixing the specificity should make the fonts display.

What worries me a little is that something is making a XHR request to fetch the CSS inserted by the Typekit JavaScript, which fails due with an Access Control error (as it should).

@ithinkihaveacat
Copy link
Author

@bramstein Thank-you, I think you're right--the example with bootstrap.css and Typekit is not problematic: if Typekit rules are followed by boostrap.css rules, boostrap.css wins, and vice-versa, and so http://jsbin.com/UbufOFOK/2/ doesn't demonstrate that bootstrap.css or Typekit is broken.

So we're back to the question of why adding Polymer to a page changes its appearance. I'm suspicious of HTMLImports!

@ithinkihaveacat
Copy link
Author

The problem with HTMLImports is fixed in googlearchive/HTMLImports@5297e25; as of this commit it no longer re-applies linked CSS files.

This didn't make it into the 0.1.4 release but I guess it will make it to 0.1.5?

@ithinkihaveacat
Copy link
Author

@sjmiles Thanks for looking into this!

@ithinkihaveacat
Copy link
Author

Just to confirm: the problem is fixed in Polymer 0.2.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants