data-uri: adds inline-image() to embed data-URIs - #775
Conversation
The "inline-image" function reads images, encodes them using base64 encoding, and embeds them into the generated CSS files as data-URIs. More about data-URIs: http://en.wikipedia.org/wiki/Data_URI_scheme This causes a significant reduction in the number of HTTP requests sent although it increases the size of the resulting CSS code. Multiple occurrences of the same data-URI are easily handled by server-side GZIP compression and hence redundancy should not be a drawback for the majority of the client audience. The original author of this patch is: Marc Boeker <marc.boeker@onchestra.com>
|
Thanks for submitting :) |
|
Cool function. Probably should be a note that the resulting CSS is only IE8+ compatible and max URI length in IE8 is 32KB. |
|
What is IE? Never head of it yet. Can I eat this? :) Yeah absolutely, we should mention to use this feature with caution. |
|
Actually, we could add a command line flag that allows Alternatively, this can also be handled by using "url" to target IE directly using So for IE, you'd write: .lt-ie7 #some-element { But this does mean that these resources will be downloaded Or does anybody have better suggestions? |
|
Hm or we just inform the developer, that IE has limited support for data-uri's and let it up to the developer to find a solution. I'm personally not a friend of patching anything to make it work in IE. Everyone who has to support IE already knows a viable solution to switch between data-uri's and an extra stylesheet for IE. In the long term, IE (I hope) will support regular data-uri's like most of the other browsers too. And until that, we should use an extra stylesheet. @gorakhargosh What do you think? |
|
+1 for this and I agree with @marcboeker everyone who's using less will know how to use an extra stylesheet for IE if they want to support. |
|
+1! |
|
I guess in web browser this function should act as a bypass to "url(...)" |
|
I think other things need to be resolved before this could happen. For instance, does a URL reference that I would use to pull the image relative to the LESS file? Or the resulting CSS file? Documentation on that is not clear. And, as far as I can tell, this would only work in Node-based compilation, correct? If so, this would break browser testing or HTML-based LESS systems. |
|
For HTML-based compliation it would work if it just "noop'ed" to a url(xxx) Compass and stylus have no problem with it use the working directory the On Wed, Aug 1, 2012 at 4:04 PM, matthewdl <
|
|
Is this functionality in .LESS 1.3.0 ? i.e. the current shipping version? |
|
Would like to get this functionality in a project I'm working on. Compass (SASS) has had this for a while now: Compass/compass@5a015b3 |
|
Any update on this pull request? |
|
could aim for 1.4.0 We're not ignoring pull requests - we've gone from 70 to 17 in 6 months. The fact it hasn't been closed is a good thing ;) |
|
A more general solution might be a function #selector {
background-image: data-uri(image/jpeg, path/to/some/image.jpg);
}One advantage here would be that it could also be used for things like fonts, for example: @font-face {
font-family: MyCoolFont;
src: data-uri(font/ttf, path/to/my-cool-font.ttf) format("truetype");
} |
as described in a comment on less#775
|
closing to take #1086 instead as it has several improvements. |
as described in a comment on #775
as described in a comment on #775
The "inline-image" function reads images, encodes them
using base64 encoding, and embeds them into the generated
CSS files as data-URIs.
More about data-URIs:
http://en.wikipedia.org/wiki/Data_URI_scheme
This causes a significant reduction in the number of
HTTP requests sent although it increases the size of the
resulting CSS code. Multiple occurrences of the same data-URI
are easily handled by server-side GZIP compression and hence
redundancy should not be a drawback for the majority of the
client audience.
The original author of this patch is:
Marc Boeker marc.boeker@onchestra.com