Suggestion: allow @import from Google Web Fonts in styles hosted on userstyles.org

edited September 2011 in userstyles.org
The help page at http://userstyles.org/help/coding#main-article says (in its section «Limits on user styles») that any style's maximum size is 64 kb, and that @import directives are forbidden.

Unfortunately, such restrictions makes it necessary for a style to contain an entire font file whenever @font-face directive is used, and also makes it difficult (by imposing the 64 kb limit). For example, in order to contain my style http://userstyles.org/styles/46091/ below the given 64 kb limit while still embedding a font in the only possible way (base64-encoded), I had to use a relatively small subset of «PT Sans» font glyphs, and only one font style (without bold, or italic, or bold italic variants), and in only one font format (the most compact, WOFF).

Suggestion: allow style authors to rely on http://www.google.com/webfonts/ (Google Web Fonts) hosting of fonts, because your only concern («If an @import is done to a slow-loading server, it will cause browser hangs») is, most likely, not valid for the tremendous server infrastructure of Google. Google Web Fonts API described at http://code.google.com/apis/webfonts/docs/getting_started.html#Quick_Start provides a flexible font subsetting, and the correct font format (WOFF, or TTF, or EOT, or SVG) is automatically downloaded according to the results of browser sniffing.

Easy example: @import url('http://fonts.googleapis.com/css?family=Inconsolata');

Complex example: @import url('); /* here «text=…» is used for font subsetting */

Comments

  • You know, I don't even know if @import is still slow. I'll have to do some testing.
  • edited September 2011
    Consider enabling @import from fonts.googleapis.com before testing whether it's safe to enable @import from any other (slower) server. The former takes a few minutes and a few lines of code; the latter takes hours, especially if the testing is going to be thorough and to involve several generations of available browsers. It's easy to understand how important your crucial decision about all @imports is; but that decision won't be delayed much if you agree to implement my initial suggestion first.
  • You have to take into consideration things like connectivity problems as well. It's one thing for a style not to apply until the @import works, it's another to hang the browser at startup.

    I'm not sure why you need to do that @import anyway. Can't you just include the code that serves up? It's only a few lines.
  • A style's author should not just download Google's CSS and copy+paste it to the style (instead of @import) because, apparently, that CSS is a browser-dependent result of «browser sniffing» (for example, if I recall it correctly, Google offers TTF fonts for Mozilla Firefox 3.5 and Opera 10, but WOFF for Firefox 3.6 and Opera 11). The URLs of their fonts are, I am afraid, subject to sudden changes as well. I mean, when I open http://fonts.googleapis.com/css?family=Inconsolata and see an URL such as http://themes.googleusercontent.com/static/fonts/inconsolata/v1/BjAYBlHtW3CJxDcjzrnZCIbN6UDyHWBl620a-IRfuBk.woff I cannot safely judge that «BjAYBlHtW3CJxDcjzrnZCIbN6UDyHWBl620a-IRfuBk» depends on the font name only (and not a moon phase and the configuration of some server farm) and I can expect «v1» to become «v2» someday (without any prior notification), so the user style (after copy+paste of that) would someday become outdated and broken inevitably.

    I also understand that, while in userC*.css, an @import from a slow server can hang the browser, which is awful, that's why I am not advocating enabling @imports altogether, but you could make Google Web Fonts an exception to the rule, because their servers are pretty much reliable: they may give the requested data, they may fail, but I've never seen them hanging (delaying the file). And also, since their CSS code are very compact (that's «only a few lines» as you said), getting it from the Net probably won't significantly delay the browser start — even for the user with a slow connection (say, a PSTN modem or GPRS).
  • Moving the theme up (after 10 days of no reply).
  • Any @import to a remote site has the possibility of taking a long time due to connectivity problems, which would make Firefox hang at startup. There are many issues unrelated to the reliability of the server that can cause this. It's just not worth it to me to expose Stylish users to this possibility.
  • Any chance this could be revisited?
  • Only if Firefox fixes their stuff.
  • I highly need the import directives as well. Currently, having to copy paste all the code back and forth is just wrong and counterproductive. It would be so much easier if I could just link the style to a dropbox-shared document, so the workflow would be so much easier.
    Besides, I don't think connectivity problem would be an issue for more than 80% of the user base, and it's not like most stylers would import extremely huge files that would actually make a lag.
  • The question is not the size of the file so much as the possibility of a connection issue where the request never completes. This could happen on the server or on the client.
  • hmm so I guess the issue is something beyond my comprehension.
    Guess I'll just stick with how it currently is and wait for the time when it might actually be feasible. Thanks.
  • It would be so much easier if I could just link the style to a dropbox-shared document
    It would also be much easier to deliver some malicious XBL via the Dropbox document. No thank you!
  • edited July 2014
Sign In or Register to comment.