[whatwg] Editorial: ASCII case-insensitive string comparison
When I read Anne van Kesteren's Encoding specification recently, I came across the following definition, borrowed from HTML5: Comparing two strings in an ASCII case-insensitive manner means comparing them exactly, code point for code point, except that the characters in the range U+0041 to U+005A (i.e. LATIN CAPITAL LETTER A to LATIN CAPITAL LETTER Z) and the corresponding characters in the range U+0061 to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL LETTER Z) are considered to also match. The construction ‘are considered to also match’ seems awkward here since the intended meaning is clearly not that the characters match in addition to doing something else like in ‘I don’t just want you to laugh but to also sing along’ or ‘our face/tongue system allow[s] us to talk and eat—but also to sing and act’. The most natural place for ‘also’ is probably in front of ‘considered’ (yielding ‘are also considered to match’). (Another solution would be to remove the need for ‘also’ by rewriting the phrase, for instance to something like ‘except that the characters in the range U+0041 to U+005A ([...] A to [...] Z) are considered equivalent to the corresponding characters in the range U+0061 to U+007A ([... a] to [... z])’.) Øistein E. Andersen
Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)
While that information may be available at the time the img tag is parsed, I don’t believe it will be available at the time of prefetching — I’m happy to research this further and report back with citations. I’m sure I don’t have to tell you that “disable prefetching on img tags just in case there are matching sources” is going to be a hard sell to vendors that do prefetch. If we’re left with a solution that fetches the original src before applying any custom source logic, well, we’re no better off than we would be with one of the scores of script-based solutions that have come about in the past year. To your original point, though: as much as you can absolutely make a case that a simpler implementation will benefit developers if inherently more stable, you can’t convince me that `img set` suits the needs of developers as well as `picture`. In fact, even if you were to convince me, it wouldn’t matter. Picture is, for better or worse, what developers want and expect in a “responsive images” element. There’s certainly no shortage of proof of that, on this page alone: http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/ At the moment, the Community Group server seems to be down due to excessive traffic. I’m regret that picture would be more difficult to implement; I do. If there’s anyone that can understand that frustration, it’s another developer. But implementing a completely disparate method way of specifying media sources based on client-side information is in no way beneficial to the end author — and certainly holds no provable benefit to the end _user_. All things being equal for the end user, implementor convenience should not take priority over developer convenience. This is the syntax that the developer community almost whole-heartedly agrees upon — and when was the last time you saw that phrase used in reference to proposed standards? If implementor convenience does take priority over that of authors, well, here we are — but let’s not frame it as though it’s doing developers some thickly-veiled favor. They’ve voiced their preference, in no uncertain terms. Mat Marquis On May 11, 2012, at 2:52 PM, Simon Pieters wrote: There seem to be two proposals for what syntax to use for the responsive images use case: several elements vs. an attribute. I think an attribute is simpler to implement and thus likely to result in fewer bugs in browsers, which in turn benefits Web developers. With img src=... srcset=..., in the parser case, all the information is available when the tag has been parsed. Excellent! In the scripted case, we need to await a stable state when the src or srcset attributes are changed (because the same script might also change the other), and then process the attributes again. The spec already does this for src= because of the crossorigin= attribute, so it's basically a solved problem already for img in the spec. With pictureimg src=...source ../picture, in the parser case, the browser can't know it has all the information is not available until the picture element has been popped off the stack (since there might be futher source elements), which necessarily delays fetching the image. Moreover, scripts might have changed things before then, because scripts can run between the time that the picture element is added to the document and the time it is popped off the stack, which is a potential source for bugs. In the scripted case, we need to listen for changes to img elements' parents, changes to img element's attributes, changes to source elements' parents, and changes to source elements' attributes, and await a stable state and then process the picture element's img and source elements' attributes (for both the old and new picture element, if you moved an element between two picture elements), which is more complex than the attribute case. -- Simon Pieters Opera Software
Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)
On Sat, 12 May 2012, Boris Zbarsky wrote: On 5/12/12 9:28 AM, Mathew Marquis wrote: While that information may be available at the time the img tag is parsed, I don’t believe it will be available at the time of prefetching Which information? At least in Gecko, prefetching happens when the tag is parsed. So in fact in Gecko the srcset approach would be much more amenable to prefetching than the picture approach. Yes, I should have mentioned that is also true in the various types of optimistic resource loading/parsing that Opera does e.g. the delayed script execution mode and the speculative tokenisation feature.
Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)
On May 12, 2012, at 6:28 AM, Mathew Marquis m...@matmarquis.com wrote: While that information may be available at the time the img tag is parsed, I don’t believe it will be available at the time of prefetching — I’m happy to research this further and report back with citations. I’m sure I don’t have to tell you that “disable prefetching on img tags just in case there are matching sources” is going to be a hard sell to vendors that do prefetch. If we’re left with a solution that fetches the original src before applying any custom source logic, well, we’re no better off than we would be with one of the scores of script-based solutions that have come about in the past year. To your original point, though: as much as you can absolutely make a case that a simpler implementation will benefit developers if inherently more stable, you can’t convince me that `img set` suits the needs of developers as well as `picture`. In fact, even if you were to convince me, it wouldn’t matter. Picture is, for better or worse, what developers want and expect in a “responsive images” element. There’s certainly no shortage of proof of that, on this page alone: http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/ At the moment, the Community Group server seems to be down due to excessive traffic. The key to making the case for the picture element or something like it is to cite use cases. Most of the comments on that blog post just give opinions, without use cases backing them up. A lot more weight will be placed on explanations of *why* developers love something (e.g. it lets them do X where they otherwise couldn't, it lets them do Y more easily, etc) than just testimonials that they love it. Regards, Maciej P.S. Your examples in that blog post are not equivalent. Here are two examples that I believe would be equivalent for resolution adaptation only, presuming a 600x200 image and a 1200x400 scaled version: img src=catface.jpg alt=A cat's face srcset=catf...@2x.jpg 2x picture style=width: 600px; width: 200px id=catface_picture alt=A cat's face source src=catface.jpg source src=catf...@2x.jpg media=min-device-pixel-ratio: 2 img src=catface.jpg alt=A cat's face /picture Other than more general verbosity, there are a few other other differences that show up: 1) The picture version has to repeat the alt text. 2) The picture version has to repeat the URL to the 1x asset. 3) The picture version has to explicitly set a width and height, because it does not have the built-in scaling semantics of srcset and so cannot rely on intrinsic size, since it will end up different between the two images. 4) The picture version has to use a specific order, while in the srcset version, order doesn't matter.
Re: [whatwg] Editorial: ASCII case-insensitive string comparison
On 12/05/2012 13:47, Øistein E. Andersen wrote: When I read Anne van Kesteren's Encoding specification recently, I came across the following definition, borrowed from HTML5: Comparing two strings in an ASCII case-insensitive manner means comparing them exactly, code point for code point, except that the characters in the range U+0041 to U+005A (i.e. LATIN CAPITAL LETTER A to LATIN CAPITAL LETTER Z) and the corresponding characters in the range U+0061 to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL LETTER Z) are considered to also match. The construction ‘are considered to also match’ seems awkward here since the intended meaning is clearly not that the characters match in addition to doing something else like in ‘I don’t just want you to laugh but to also sing along’ or ‘our face/tongue system allow[s] us to talk and eat—but also to sing and act’. Sure they do. They match in addition to the usual matching rules (i.e. comparing them exactly, code point for code point). A pair of characters match if they have the same code point. A pair of characters also match if one is an ASCII upper-case character and the other is the equivalent ASCII lower-case character (or vice-versa). Alex -- Alex Bishop alexbis...@gmail.com
Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)
On Sat, May 12, 2012 at 11:17 AM, Maciej Stachowiak m...@apple.com wrote: On May 12, 2012, at 6:28 AM, Mathew Marquis m...@matmarquis.com wrote: While that information may be available at the time the img tag is parsed, I don’t believe it will be available at the time of prefetching — I’m happy to research this further and report back with citations. I’m sure I don’t have to tell you that “disable prefetching on img tags just in case there are matching sources” is going to be a hard sell to vendors that do prefetch. If we’re left with a solution that fetches the original src before applying any custom source logic, well, we’re no better off than we would be with one of the scores of script-based solutions that have come about in the past year. To your original point, though: as much as you can absolutely make a case that a simpler implementation will benefit developers if inherently more stable, you can’t convince me that `img set` suits the needs of developers as well as `picture`. In fact, even if you were to convince me, it wouldn’t matter. Picture is, for better or worse, what developers want and expect in a “responsive images” element. There’s certainly no shortage of proof of that, on this page alone: http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/ At the moment, the Community Group server seems to be down due to excessive traffic. The key to making the case for the picture element or something like it is to cite use cases. Most of the comments on that blog post just give opinions, without use cases backing them up. A lot more weight will be placed on explanations of *why* developers love something (e.g. it lets them do X where they otherwise couldn't, it lets them do Y more easily, etc) than just testimonials that they love it. Regards, Maciej P.S. Your examples in that blog post are not equivalent. Here are two examples that I believe would be equivalent for resolution adaptation only, presuming a 600x200 image and a 1200x400 scaled version: img src=catface.jpg alt=A cat's face srcset=catf...@2x.jpg 2x picture style=width: 600px; width: 200px id=catface_picture alt=A cat's face source src=catface.jpg source src=catf...@2x.jpg media=min-device-pixel-ratio: 2 img src=catface.jpg alt=A cat's face /picture Other than more general verbosity, there are a few other other differences that show up: 1) The picture version has to repeat the alt text. 2) The picture version has to repeat the URL to the 1x asset. 3) The picture version has to explicitly set a width and height, because it does not have the built-in scaling semantics of srcset and so cannot rely on intrinsic size, since it will end up different between the two images. 4) The picture version has to use a specific order, while in the srcset version, order doesn't matter. Does the id=catface_picture attribute play an essential role in this example, or is it just extra clutter in the picture example? Adam
Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)
On May 12, 2012, at 12:35 PM, Adam Barth w...@adambarth.com wrote: On Sat, May 12, 2012 at 11:17 AM, Maciej Stachowiak m...@apple.com wrote: On May 12, 2012, at 6:28 AM, Mathew Marquis m...@matmarquis.com wrote: While that information may be available at the time the img tag is parsed, I don’t believe it will be available at the time of prefetching — I’m happy to research this further and report back with citations. I’m sure I don’t have to tell you that “disable prefetching on img tags just in case there are matching sources” is going to be a hard sell to vendors that do prefetch. If we’re left with a solution that fetches the original src before applying any custom source logic, well, we’re no better off than we would be with one of the scores of script-based solutions that have come about in the past year. To your original point, though: as much as you can absolutely make a case that a simpler implementation will benefit developers if inherently more stable, you can’t convince me that `img set` suits the needs of developers as well as `picture`. In fact, even if you were to convince me, it wouldn’t matter. Picture is, for better or worse, what developers want and expect in a “responsive images” element. There’s certainly no shortage of proof of that, on this page alone: http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/ At the moment, the Community Group server seems to be down due to excessive traffic. The key to making the case for the picture element or something like it is to cite use cases. Most of the comments on that blog post just give opinions, without use cases backing them up. A lot more weight will be placed on explanations of *why* developers love something (e.g. it lets them do X where they otherwise couldn't, it lets them do Y more easily, etc) than just testimonials that they love it. Regards, Maciej P.S. Your examples in that blog post are not equivalent. Here are two examples that I believe would be equivalent for resolution adaptation only, presuming a 600x200 image and a 1200x400 scaled version: img src=catface.jpg alt=A cat's face srcset=catf...@2x.jpg 2x picture style=width: 600px; width: 200px id=catface_picture alt=A cat's face source src=catface.jpg source src=catf...@2x.jpg media=min-device-pixel-ratio: 2 img src=catface.jpg alt=A cat's face /picture Other than more general verbosity, there are a few other other differences that show up: 1) The picture version has to repeat the alt text. 2) The picture version has to repeat the URL to the 1x asset. 3) The picture version has to explicitly set a width and height, because it does not have the built-in scaling semantics of srcset and so cannot rely on intrinsic size, since it will end up different between the two images. 4) The picture version has to use a specific order, while in the srcset version, order doesn't matter. Does the id=catface_picture attribute play an essential role in this example, or is it just extra clutter in the picture example? Extra clutter. I forgot to delete it after I switched that example from using externally declared style to a style attribute. Corrected versions: img src=catface.jpg alt=A cat's face srcset=catf...@2x.jpg 2x picture style=width: 600px; width: 200px alt=A cat's face source src=catface.jpg source src=catf...@2x.jpg media=min-device-pixel-ratio: 2 img src=catface.jpg alt=A cat's face /picture
Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)
On May 11, 2012, at 8:52 PM, Simon Pieters wrote: There seem to be two proposals for what syntax to use for the responsive images use case: several elements vs. an attribute. There are two proposals because they solve two different use cases. Both use cases are becoming increasingly important. Unfortunately, these use cases are commonly collapsed into one. I have done it myself in the past. I tried to clarify the use cases recently.[1] Use case #1 --- Document author needs to display different versions of an image at different breakpoints based on what I’m calling, for a lack of a better phrase, art direction merits. * Example 1: News site shows photograph speaking at a auto factory. On wide screens, the news site includes a widescreen version of the photograph in which the cars being built can clearly be seen. On small screens, if the photograph is simply resized to fit the screen, Obama’s face is too small to be seen. Instead, the document author may choose to crop the photograph so that it focuses in on Obama before resizing to fit the smaller screen. [1] * Example 2: On the Nokia Browser site where it describes the Meego browser[2], the Nokia Lumia is show horizontally on wide screens[3]. As the screen narrows, the Nokia Lumia is then shown vertically and cropped[4]. Bryan and Stephanie Rieger, the designers of the site, have talked about how on a wide screen, showing the full phone horizontally showed the browser best, but on small screens, changing the img to vertical made more sense because it allowed the reader to still make out the features of the browser in the image. Current proposed solution: picture element[5] Use case #2 --- For a variety of reasons, images of various pixel density are needed. These reasons include current network connection speed, display pixel density, user data plan, and user preferences. * Example 1: The use of high-density images for the new iPad on Apple.com.[6] * Example 2: A user on a slow network or with limited data left may explicitly declare that he or she would like to download a high resolution because they need to see a sharper version of an image before buying product, etc. Current proposed solution for use case #2: img srcset[7] IMHO Neither proposed solution handles all of the use cases. I’m not convinced that one solution needs to solve both of them, but I do think if we’re getting close to implementing one of the proposed solutions, we need to consider how it would work in conjunction with a solution for the other use case. To be more specific, if img srcset were to be implemented in a browser--potentially solving use case #2, but leaving use case #1 open--what would happen when we realized that use case #1 still needed to be solved? Would we end up with some bastardized mixture of picture and imgset syntax? When Ted proposed img srcset, he wrote[7]: Ultimately I don't think addressing the multiple-resolution case needs to wait for a solution to these other cases. We don't need to SOLVE ALL THE PROBLEMS! right now. In a similar vein, the responsive images community group, focused on use case #1 and explicitly chose to ignore the problems described in use case #2. While I agreed with that focus earlier, I now think this may be a mistake. As much as I don’t want to bog down solving either use case, it seems likely that if we don’t look at both at the same time, that we’ll end up with[8]: picture alt= source src=mobile.jpg / source src=medium.jpg media=min-width: 600px / source src=fullsize.jpg media=min-width: 900px / img src=foo-lores.jpg srcset=foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x alt=decent alt text for foo. /picture Which would make no one happy. -Jason [1] http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/ [2] http://browser.nokia.com/smartphones.html [3] http://browser.nokia.com/resources/images/home-feature.png [4] http://browser.nokia.com/resources/images/smartphones/choose-me...@320.png [5] https://github.com/Wilto/respimg [6] http://blog.cloudfour.com/how-apple-com-will-serve-retina-images-to-new-ipads/ [7] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/035746.html [8] Yes, yes, this is an exaggeration, but you get my point.
Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)
I didn’t want to cloud my previous email with my opinions on various solutions, but as you may expect, I have some thoughts on the solutions to these two use cases. On May 13, 2012, at 12:43 AM, Jason Grigsby wrote: Use case #1 --- Document author needs to display different versions of an image at different breakpoints based on what I’m calling, for a lack of a better phrase, art direction merits. A solution to this use case should put 100% of the control in the hands of authors. It should provide the same control over images in html that is granted to authors over css images by media queries. Use case #2 --- For a variety of reasons, images of various pixel density are needed. These reasons include current network connection speed, display pixel density, user data plan, and user preferences. A solution to this use case should allow an author to supply a list of images at different densities (or better yet an image in a format that supports multiple densities), BUT the user agent should decide which image density is right for the situation. Ideally, the user agent would make a decision about the appropriate image based on: * Connection speed * Display density * Data plan * User preference Obviously not all of these can be supported currently and the list isn’t necessarily comprehensive. The point I’m making is that there are multiple factors to picking the right density. The user agent is in the best position to make these decisions. -Jason
Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)
I’ve put together a summary of potential use cases addressed by the picture markup and posted them to the WHATWG wiki, along with a few key implementation details: http://wiki.whatwg.org/wiki/Adaptive_images I don’t mind saying that the `img set` markup is inscrutable to the point where I may well be missing the mark on what it’s trying to achieve, but it certainly seems to overlap with many of the things for which media queries were intended—albeit in a completely siloed way. As media queries continue to advance over time, are there plans to continue adding functionality to `img set` in parallel? I would hate to think we could be painting ourselves into a corner for the sake of easier implementation on the UA side. I don’t claim to be any smarter than the average developer, but I am speaking as a core contributor to jQuery Mobile and having worked on the responsive BostonGlobe.com designs: tailoring things for client capabilities is kind of my thing. I fear the developer community has little hope of understanding this pattern, and there has been no small amount of consensus on that point: http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/#comments I worry that, when faced with this markup, developers will simply opt to serve the largest possible image in a src. In fairness, that approach works with far less headache. -Mat Marquis On May 12, 2012, at 6:43 PM, Jason Grigsby wrote: On May 11, 2012, at 8:52 PM, Simon Pieters wrote: There seem to be two proposals for what syntax to use for the responsive images use case: several elements vs. an attribute. There are two proposals because they solve two different use cases. Both use cases are becoming increasingly important. Unfortunately, these use cases are commonly collapsed into one. I have done it myself in the past. I tried to clarify the use cases recently.[1] Use case #1 --- Document author needs to display different versions of an image at different breakpoints based on what I’m calling, for a lack of a better phrase, art direction merits. * Example 1: News site shows photograph speaking at a auto factory. On wide screens, the news site includes a widescreen version of the photograph in which the cars being built can clearly be seen. On small screens, if the photograph is simply resized to fit the screen, Obama’s face is too small to be seen. Instead, the document author may choose to crop the photograph so that it focuses in on Obama before resizing to fit the smaller screen. [1] * Example 2: On the Nokia Browser site where it describes the Meego browser[2], the Nokia Lumia is show horizontally on wide screens[3]. As the screen narrows, the Nokia Lumia is then shown vertically and cropped[4]. Bryan and Stephanie Rieger, the designers of the site, have talked about how on a wide screen, showing the full phone horizontally showed the browser best, but on small screens, changing the img to vertical made more sense because it allowed the reader to still make out the features of the browser in the image. Current proposed solution: picture element[5] Use case #2 --- For a variety of reasons, images of various pixel density are needed. These reasons include current network connection speed, display pixel density, user data plan, and user preferences. * Example 1: The use of high-density images for the new iPad on Apple.com.[6] * Example 2: A user on a slow network or with limited data left may explicitly declare that he or she would like to download a high resolution because they need to see a sharper version of an image before buying product, etc. Current proposed solution for use case #2: img srcset[7] IMHO Neither proposed solution handles all of the use cases. I’m not convinced that one solution needs to solve both of them, but I do think if we’re getting close to implementing one of the proposed solutions, we need to consider how it would work in conjunction with a solution for the other use case. To be more specific, if img srcset were to be implemented in a browser--potentially solving use case #2, but leaving use case #1 open--what would happen when we realized that use case #1 still needed to be solved? Would we end up with some bastardized mixture of picture and imgset syntax? When Ted proposed img srcset, he wrote[7]: Ultimately I don't think addressing the multiple-resolution case needs to wait for a solution to these other cases. We don't need to SOLVE ALL THE PROBLEMS! right now. In a similar vein, the responsive images community group, focused on use case #1 and explicitly chose to ignore the problems described in use case #2. While I agreed with that focus earlier, I now think this may be a mistake. As much as I don’t want to bog down solving either use case, it seems likely that if we don’t look at both at the same time, that we’ll end up with[8]: picture
[whatwg] runat (or server) attribute
Hi, With Server-Side JavaScript taking off, could we reserve runat (or maybe an even simpler and more concise server boolean attribute) for a standard and (via CommonJS) potentially portable way for server-side files to be created (and discourage use of HTML-unfriendly and syntax-highlighter-unaware processing instructions)? I know in the past Ian has showed a lack of interest in tending to HTML in other contexts (e.g., in rejecting a common include syntax), but could we at least lay this simple foundation for encouraging server-side portability (in a way that works well with existing syntax highlighters)? Thanks, Brett
Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)
On 5/12/12 9:28 AM, Mathew Marquis wrote: While that information may be available at the time the img tag is parsed, I don’t believe it will be available at the time of prefetching Which information? At least in Gecko, prefetching happens when the tag is parsed. So in fact in Gecko the srcset approach would be much more amenable to prefetching than the picture approach. -Boris
