Re: [whatwg] Built-in image sprite support in HTML5
On Fri, Dec 2, 2011 at 5:14 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Dec 1, 2011 at 10:09 AM, David Weitzman dweitz...@gmail.com wrote: Reviving an old question here: is there anything in current or upcoming web specs that should give me hope that I will eventually see a day when sprites are either unnecessary at a protocol level or easily supported in img tags? The thread you're continuing answered that question. The Media Fragments spec allows one to address a piece of a sprite sheet as an image (for use in img and the like) when it is supported. David: you might want to lobby the browsers through bug reports to start implementing support for it. :-) Cheers, Silvia.
Re: [whatwg] Built-in image sprite support in HTML5
Reviving an old question here: is there anything in current or upcoming web specs that should give me hope that I will eventually see a day when sprites are either unnecessary at a protocol level or easily supported in img tags? On Thu, Aug 26, 2010 at 4:01 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Aug 25, 2010 at 7:00 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: It would, however, be good to have an indication where HTML would like to see it going. Would it be better for a media fragment URI for images such as http://example.com/picture.png#xywh=160,120,320,240 to display the full image with the rectangle somehow highlighted (as is the case with fragment URIs to HTML pages), or would it be better to actually just display the specified region and hide the rest of the image (i.e. create a sprite)? What makes the most sense for images? The CSS Image Values Module ( http://dev.w3.org/csswg/css3-images/#url ) is currently recommending Media Fragments as a way to sprite out a portion of a resource. We have a note that we're expecting a spec to reference at some point. ~TJ
Re: [whatwg] Built-in image sprite support in HTML5
On Thu, Dec 1, 2011 at 10:09 AM, David Weitzman dweitz...@gmail.com wrote: Reviving an old question here: is there anything in current or upcoming web specs that should give me hope that I will eventually see a day when sprites are either unnecessary at a protocol level or easily supported in img tags? The thread you're continuing answered that question. The Media Fragments spec allows one to address a piece of a sprite sheet as an image (for use in img and the like) when it is supported. On the protocol level, SPDY should reduce much of the pain of multiple small resources, and make spriting unnecessary or at least less necessary. ~TJ
Re: [whatwg] Built-in image sprite support in HTML5
On Wed, Aug 25, 2010 at 7:00 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: It would, however, be good to have an indication where HTML would like to see it going. Would it be better for a media fragment URI for images such as http://example.com/picture.png#xywh=160,120,320,240 to display the full image with the rectangle somehow highlighted (as is the case with fragment URIs to HTML pages), or would it be better to actually just display the specified region and hide the rest of the image (i.e. create a sprite)? What makes the most sense for images? The CSS Image Values Module ( http://dev.w3.org/csswg/css3-images/#url ) is currently recommending Media Fragments as a way to sprite out a portion of a resource. We have a note that we're expecting a spec to reference at some point. ~TJ
Re: [whatwg] Built-in image sprite support in HTML5
On Thu, Aug 26, 2010 at 9:01 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Wed, Aug 25, 2010 at 7:00 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: It would, however, be good to have an indication where HTML would like to see it going. Would it be better for a media fragment URI for images such as http://example.com/picture.png#xywh=160,120,320,240 to display the full image with the rectangle somehow highlighted (as is the case with fragment URIs to HTML pages), or would it be better to actually just display the specified region and hide the rest of the image (i.e. create a sprite)? What makes the most sense for images? The CSS Image Values Module ( http://dev.w3.org/csswg/css3-images/#url ) is currently recommending Media Fragments as a way to sprite out a portion of a resource. We have a note that we're expecting a spec to reference at some point. ~TJ Oh, wow, that's good to know. Thanks! Silvia.
Re: [whatwg] Built-in image sprite support in HTML5
On Wed, 4 Aug 2010, Silvia Pfeiffer wrote: However, what exactly happens with a media fragment URI like http://example.com/picture.png#xywh=160,120,320,240 is not fully specified in the Media Fragment URI spec. I would recommend fixing that. :-) Well, that goes into implementation issues and really has nothing to do with the URI specification itself. Specifications have everything to do with implementation issues. That's what they're for. If the specification doesn't say how to get interoperablel implementations, then it's not very useful. As we adopt media fragment URIs into the HTML5 spec, we should prescribe what the user experience is meant to be, such that UAs can implement a consistent handling. I don't think it makes sense to have the HTML spec define what other specs mean. We've had to do it in places, but only when the other specifications have dropped the ball. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Built-in image sprite support in HTML5
On Thu, Aug 26, 2010 at 8:10 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 4 Aug 2010, Silvia Pfeiffer wrote: However, what exactly happens with a media fragment URI like http://example.com/picture.png#xywh=160,120,320,240 is not fully specified in the Media Fragment URI spec. I would recommend fixing that. :-) Well, that goes into implementation issues and really has nothing to do with the URI specification itself. Specifications have everything to do with implementation issues. That's what they're for. If the specification doesn't say how to get interoperablel implementations, then it's not very useful. There are recommendations for what to do with video in the browser. I can encourage the group to also make recommendations for what it means for images in the browser. However, the use of Media Fragment URIs in applications in general really cannot be prescribed - what a video editor does with a media fragment URI is different to what a video playlist player does and again different to what it means in the browser and probably different again for pick your random application here. Not all applications display a timeline - not all applications allow interaction with the resource, some applications want to use the resource in context (i.e. with access to the rest of the resource), others don't. It is early times for Media Fragment URIs so some of these use cases will have to be experimented with before a good recommendation can be made. As we adopt media fragment URIs into the HTML5 spec, we should prescribe what the user experience is meant to be, such that UAs can implement a consistent handling. I don't think it makes sense to have the HTML spec define what other specs mean. We've had to do it in places, but only when the other specifications have dropped the ball. I will take the desire to have a clear specification for what Web browsers are to do with Media Fragment URIs back into the Media Fragment WG. I believe Web browsers are a special and the most important use case for such URIs, so it makes sense to specify that clearly. It would, however, be good to have an indication where HTML would like to see it going. Would it be better for a media fragment URI for images such as http://example.com/picture.png#xywh=160,120,320,240 to display the full image with the rectangle somehow highlighted (as is the case with fragment URIs to HTML pages), or would it be better to actually just display the specified region and hide the rest of the image (i.e. create a sprite)? What makes the most sense for images? Cheers, Silvia.
Re: [whatwg] Built-in image sprite support in HTML5
On Wed, Aug 25, 2010 at 7:00 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: As we adopt media fragment URIs into the HTML5 spec, we should prescribe what the user experience is meant to be, such that UAs can implement a consistent handling. I don't think it makes sense to have the HTML spec define what other specs mean. We've had to do it in places, but only when the other specifications have dropped the ball. I will take the desire to have a clear specification for what Web browsers are to do with Media Fragment URIs back into the Media Fragment WG. I believe Web browsers are a special and the most important use case for such URIs, so it makes sense to specify that clearly. It would, however, be good to have an indication where HTML would like to see it going. Would it be better for a media fragment URI for images such as http://example.com/picture.png#xywh=160,120,320,240 to display the full image with the rectangle somehow highlighted (as is the case with fragment URIs to HTML pages), or would it be better to actually just display the specified region and hide the rest of the image (i.e. create a sprite)? What makes the most sense for images? I definitely think creating a sprite makes the most sense. There are a lot more usage of spriting out there then there are of highlighting a particular portion of an image loaded using img / Jonas
Re: [whatwg] Built-in image sprite support in HTML5
On Aug 25, 2010, at 7:00 PM, Silvia Pfeiffer wrote: There are recommendations for what to do with video in the browser. I can encourage the group to also make recommendations for what it means for images in the browser. However, the use of Media Fragment URIs in applications in general really cannot be prescribed - what a video editor does with a media fragment URI is different to what a video playlist player does and again different to what it means in the browser and probably different again for pick your random application here. Not all applications display a timeline - not all applications allow interaction with the resource, some applications want to use the resource in context (i.e. with access to the rest of the resource), others don't. It is early times for Media Fragment URIs so some of these use cases will have to be experimented with before a good recommendation can be made. When different kinds of applications may need different behavior, one possible solution is for the spec to have different conformance classes. In this case, for the feature to be useful for Web content authors, it's pretty important for browsers to all do the same thing, even if other types of applications may behave differently. I will take the desire to have a clear specification for what Web browsers are to do with Media Fragment URIs back into the Media Fragment WG. I believe Web browsers are a special and the most important use case for such URIs, so it makes sense to specify that clearly. Yes, definitely. It would, however, be good to have an indication where HTML would like to see it going. Would it be better for a media fragment URI for images such as http://example.com/picture.png#xywh=160,120,320,240 to display the full image with the rectangle somehow highlighted (as is the case with fragment URIs to HTML pages), or would it be better to actually just display the specified region and hide the rest of the image (i.e. create a sprite)? What makes the most sense for images? It should crop to the selected region, i.e. create a sprite. This is a more generally useful behavior. Regards, Maciej
Re: [whatwg] Built-in image sprite support in HTML5
On Fri, 21 May 2010, David Weitzman wrote: There are various approaches to using image sprites with HTML and CSS, but at the end of the day they are all essentially hacks. A solution that would be simpler than any existing approach would be to introduce new attributes for img to specify x and y offsets and clipping on images. With that you would get simpler markup for sprites and better accessibility. One downside of this approach is that with background image sprites you can have a CSS class that abstracts away the name of the sprite image. With img tags you would have to specify the URL and height/width individually on every sprited image. I think the right solution is a fragment identifier. On Sat, 22 May 2010, Silvia Pfeiffer wrote: On Sat, May 22, 2010 at 3:23 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: The Media Fragments WG has a draft spec out for, well, Media Fragments, which let you specify which section of an image you want right in the url. �The browser should then automatically cut it out and serve just the sprite you want. Yes, I was going to suggest that spec, too, see http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-space However, what exactly happens with a media fragment URI like http://example.com/picture.png#xywh=160,120,320,240 is not fully specified in the Media Fragment URI spec. I would recommend fixing that. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Built-in image sprite support in HTML5
On Wed, Aug 4, 2010 at 10:19 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 21 May 2010, David Weitzman wrote: There are various approaches to using image sprites with HTML and CSS, but at the end of the day they are all essentially hacks. A solution that would be simpler than any existing approach would be to introduce new attributes for img to specify x and y offsets and clipping on images. With that you would get simpler markup for sprites and better accessibility. One downside of this approach is that with background image sprites you can have a CSS class that abstracts away the name of the sprite image. With img tags you would have to specify the URL and height/width individually on every sprited image. I think the right solution is a fragment identifier. On Sat, 22 May 2010, Silvia Pfeiffer wrote: On Sat, May 22, 2010 at 3:23 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: The Media Fragments WG has a draft spec out for, well, Media Fragments, which let you specify which section of an image you want right in the url. The browser should then automatically cut it out and serve just the sprite you want. Yes, I was going to suggest that spec, too, see http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-space However, what exactly happens with a media fragment URI like http://example.com/picture.png#xywh=160,120,320,240 is not fully specified in the Media Fragment URI spec. I would recommend fixing that. :-) Well, that goes into implementation issues and really has nothing to do with the URI specification itself. The media fragment URI specification can propose what is possible to happen for representing a media fragment URI and it does so by now: http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#media-fragment-display. But really, the application has to decide for itself what makes sense. As we adopt media fragment URIs into the HTML5 spec, we should prescribe what the user experience is meant to be, such that UAs can implement a consistent handling. Cheers, Silvia.
Re: [whatwg] Built-in image sprite support in HTML5
HTTP-level solutions are vulnerable to broken proxies and caches, of which there are many. This is why HTTP pipelining doesn't really work. Yeah I know, but does that mean HTML should work around lack of features in HTTP? I mean you could say HTML5 is vulnerable to broken browsers :-)
Re: [whatwg] Built-in image sprite support in HTML5
On Tue, Jun 1, 2010 at 9:22 AM, Mike Hearn m...@plan99.net wrote: HTTP-level solutions are vulnerable to broken proxies and caches, of which there are many. This is why HTTP pipelining doesn't really work. Yeah I know, but does that mean HTML should work around lack of features in HTTP? I mean you could say HTML5 is vulnerable to broken browsers :-) Yes, but if the browser has a bug it is much easier to detect, fix and deploy the fix. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Built-in image sprite support in HTML5
On Sun, May 30, 2010 at 3:58 AM, Mike Hearn m...@plan99.net wrote: Yeah, I'd think this isn't really a problem that should be solved as part of HTML5 but rather as improvements to the protocol level. Spriting is after all just a hack around the strict 1-file-1-request nature of HTTP and not something that's really fundamental. For instance theoretically SPDY should solve this problem. Or indeed so would HTTP pipelining, if it was used more often. HTTP-level solutions are vulnerable to broken proxies and caches, of which there are many. This is why HTTP pipelining doesn't really work. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Built-in image sprite support in HTML5
Finally, there have been proposals for removing the need to sprite altogether, by allowing authors to send a bunch of resources packed into a single compressed archive, and just addressing individual files inside of it. Yeah, I'd think this isn't really a problem that should be solved as part of HTML5 but rather as improvements to the protocol level. Spriting is after all just a hack around the strict 1-file-1-request nature of HTTP and not something that's really fundamental. For instance theoretically SPDY should solve this problem. Or indeed so would HTTP pipelining, if it was used more often.
Re: [whatwg] Built-in image sprite support in HTML5
On Fri, May 21, 2010 at 8:07 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: However, what exactly happens with a media fragment URI like http://example.com/picture.png#xywh=160,120,320,240 is not fully specified in the Media Fragment URI spec. One thought was to just highlight the area that is specified - similar to a lightbox - where the other areas in the image/video are darkened. That follows the idea of fragments being a focus region. Another thought is to zoom into that area and decode, but not display the others. The first idea doesn't make any sense to me as an author. It seems like it would be vastly less useful than the second. It's just a stylistic effect, which you don't even have any control over -- and authors don't like being unable to control style precisely. What I'd expect is the second thing: that URL should behave exactly like a manually-cropped version of picture.png, so you don't have to use positioning hacks or serve a separate cropped file. This would be useful for spriting -- although resource packages, or another HTTP pipelining substitute, sounds like a still better idea.
[whatwg] Built-in image sprite support in HTML5
There are various approaches to using image sprites with HTML and CSS, but at the end of the day they are all essentially hacks. A solution that would be simpler than any existing approach would be to introduce new attributes for img to specify x and y offsets and clipping on images. With that you would get simpler markup for sprites and better accessibility. One downside of this approach is that with background image sprites you can have a CSS class that abstracts away the name of the sprite image. With img tags you would have to specify the URL and height/width individually on every sprited image. Thoughts? - David
Re: [whatwg] Built-in image sprite support in HTML5
On Fri, 2010-05-21 at 10:12 -0700, David Weitzman wrote: There are various approaches to using image sprites with HTML and CSS, but at the end of the day they are all essentially hacks. A solution that would be simpler than any existing approach would be to introduce new attributes for img to specify x and y offsets and clipping on images. With that you would get simpler markup for sprites and better accessibility. One downside of this approach is that with background image sprites you can have a CSS class that abstracts away the name of the sprite image. With img tags you would have to specify the URL and height/width individually on every sprited image. Thoughts? - David It does seem like a good idea, because it does make sure that the sprites are accessible, which they really aren't at the moment. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Built-in image sprite support in HTML5
On Fri, May 21, 2010 at 10:12 AM, David Weitzman dweitz...@gmail.com wrote: There are various approaches to using image sprites with HTML and CSS, but at the end of the day they are all essentially hacks. A solution that would be simpler than any existing approach would be to introduce new attributes for img to specify x and y offsets and clipping on images. With that you would get simpler markup for sprites and better accessibility. One downside of this approach is that with background image sprites you can have a CSS class that abstracts away the name of the sprite image. With img tags you would have to specify the URL and height/width individually on every sprited image. Agreed on all points about the current spriting solutions being hacks. This problem is already being addressed on multiple fronts, though they are all still somewhat theoretical at the moment. The Media Fragments WG has a draft spec out for, well, Media Fragments, which let you specify which section of an image you want right in the url. The browser should then automatically cut it out and serve just the sprite you want. The CSSWG has a few proposals in a very rough state, detailed in the CSS Images spec. Finally, there have been proposals for removing the need to sprite altogether, by allowing authors to send a bunch of resources packed into a single compressed archive, and just addressing individual files inside of it. So, while none of these are exactly imminent, there is activity in this sphere already occuring. ~TJ
Re: [whatwg] Built-in image sprite support in HTML5
On Sat, May 22, 2010 at 3:23 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, May 21, 2010 at 10:12 AM, David Weitzman dweitz...@gmail.com wrote: There are various approaches to using image sprites with HTML and CSS, but at the end of the day they are all essentially hacks. A solution that would be simpler than any existing approach would be to introduce new attributes for img to specify x and y offsets and clipping on images. With that you would get simpler markup for sprites and better accessibility. One downside of this approach is that with background image sprites you can have a CSS class that abstracts away the name of the sprite image. With img tags you would have to specify the URL and height/width individually on every sprited image. Agreed on all points about the current spriting solutions being hacks. This problem is already being addressed on multiple fronts, though they are all still somewhat theoretical at the moment. The Media Fragments WG has a draft spec out for, well, Media Fragments, which let you specify which section of an image you want right in the url. The browser should then automatically cut it out and serve just the sprite you want. Yes, I was going to suggest that spec, too, see http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-space . However, what exactly happens with a media fragment URI like http://example.com/picture.png#xywh=160,120,320,240 is not fully specified in the Media Fragment URI spec. One thought was to just highlight the area that is specified - similar to a lightbox - where the other areas in the image/video are darkened. That follows the idea of fragments being a focus region. Another thought is to zoom into that area and decode, but not display the others. It is indeed something that the HTML5 spec when it adopts media fragments will have to specify/recommend to browsers how to implement. The media fragment WG has this far starte putting together recommendations for display at http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#media-fragment-display - it would be good to have this discussion here and feed back any suggested changes/improvements. Cheers, Silvia.
