data-uri doesn't support fonts #2541
Comments
"too large" is 64kb if I'm not mistaken. And |
|
Hmm, it seems it's Hence you can use it with your max arbitrary size. |
|
Could be, though it's a subject for another ticket. |
|
Closing as not an issue. |
|
Search Google, people seem to be doing it. Check the mime type is correct.
Less handles all files the same.
See
https://github.com/less/less.js/blob/master/lib/less/functions/data-uri.js
|
|
What I actually found it to be was that it wasn't doing it correctly in combo with a mixin. Not sure if that's attributable to LESS or the LESS translator in .NET I'm using. Would love to see a test in the project for both web font data uri usage and usage through a mixin (if that's supposed to work). By that I mean passing the file path to a mixin and the data-uri action happening inside the mixin. It works fine if the data-uri function is set up directly with the file path (at least for some font types, but I think it's a mime type issue that I'm trying to figure out). |
|
@Nettsentrisk I'm not sure if I understand your problem. Does your "LESS translator in .NET" supports
Post a minimal code that works and a minimal code that does not.
.font-face(@name, @file: @name) {
@font-face {
font-family: @name;
src: data-uri('@{file}.woff') format('woff');
}
}
// usage
.font-face('Foo Bar', 'fonts/foobar');
Aside of above I wonder if embedding font files into CSS is a good idea in general (taking font file sizes into account, its nothing but your pages performance killer. Even if cached, browser still has to traverse through all that "binary" garbage when parsing). |
|
It supports data-uri, but it seems that it maybe runs the parsing of it too early, before variables and mixins have been run and compiled, so it thinks that the data-uri uses with variables aren't valid and ignores them. I've registered an issue with the library it pertains to. As far as embedding fonts into CSS, apparently it's the new hotness in front end performance. |
The same argument could be applied to images. I haven't seen any research done, but embedding into css is very common.
You are right, I came across this the other day. It seems we use the path from the location of the |
|
@Nettsentrisk I raised #2629 |
Oops, sorry my bad (fixed).
Well, I assume @Nettsentrisk tries to use something like http://jaicab.com/2015/03/03/introducing-localfont-a-localstorage-solution/, then it probably makes sense (not counting that the whole idea is just a "current browsers state" workaround - is "regular HTTP caching" in modern browsers that bad so it's worth all that extra scripting? I won't believe until I see some real tests :), but never mind) But in general, the only normal use-case is to embed relatively tiny files (e.g. some project specific "2px border line"). I doubt if there could be any reason to embed 100kb file (be it image, font or svg) to a 200kb CSS. |
Just a small aside, HTTP/2 will unfortunately make all of our best practices in this regard suddenly worst practices. Because of streams and multiplexing, HTTP/2 actually handles multiple concurrent streams more efficiently than larger single files. I'm not sure if SPDY is in the same boat (which is already implemented in all major browsers), but it's possible. So that's just to echo others with saying, if it's an issue, fixing it is good. But it might be a bad idea to continue inlining resources like this in the long run. |
|
Yes. And SPDY too - it was used as sn experimental protocol to feed into
http/2 design and is now deprecated.
|
|
@lukeapage It wasn't entirely "experimental" since it's currently implemented across the board, and was integrated into Apache. But yes, it is now deprecated for HTTP/2. Or, another way of saying that, is that the next version of SPDY is now called HTTP/2. |
Although is perfectly valid to embed
fontsdirectly incss, thedata-urifunction doesn't seem to support fontse.g.
returns
while this is expected:
The text was updated successfully, but these errors were encountered: