Re: [whatwg] maincontent element spec updated and supporting data provided
On Oct 18, 2012, at 2:36 PM, Ian Hickson wrote: > > I just wanted to make sure everyone is clear that this part > is not part of the HTML specification, and is not a WHATWG specification. > We have previously had miscommunications about this kind of thing, e.g. > with responsive images, where there was some expectation from some people > that if a proposal got written up, it would be adopted. This is not the > case; what decides whether a proposal is adopted or not is whether it has > real use cases and compelling reasoning. Off-topic, but just for the record: there was no expectation that the RICG’s proposal would simply be accepted wholesale, for obvious reasons—just that we would be able to collaborate with the WHATWG on it. It wouldn’t have made much sense for us to call it a “proposal” otherwise, after all. :) On-topic: the `main` class/ID pattern is an exceedingly common one, for sure. I use it all the time myself, in conjunction with `role="main"`. I was originally of the mind that the role of “primary content” was served by the first `article` element within the document, but where the first `article` just represents the first sectioned stand-alone content in the document, it could be something like an infographic — capable of functioning independent of the surrounding document, but not the entirety of the primary content. Given the clear meaning of the proposed element, the low barrier to adoption by web developers, and the potential benefits this could have in terms of syndication and accessibility: it certainly sounds interesting! The RICG published a stand-alone “use cases” document a while back ( http://usecases.responsiveimages.org ), to facilitate work on the extension specification. Is anything like this in the works for `main`/`content`/`maincontent`, at present? Seems like it would be a good next step!
Re: [whatwg] Features for responsive Web design
On Oct 11, 2012, at 1:10 PM, Ian Hickson wrote: > On Thu, 11 Oct 2012, Mathew Marquis wrote: >> On Oct 11, 2012, at 12:36 PM, Ian Hickson wrote: >>> On Thu, 11 Oct 2012, Markus Ernst wrote: >>>> >>>> IMHO as an author, the "bandwidth" use case is not solved in a future >>>> proof manner >>> >>> It's not solved at all. I didn't attempt to solve it. Before we can >>> solve it, we need to figure out how to do so, as discussed here >>> (search for "bandwidth one"): >>> >>> http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0247.html >> >> The RICG has proposed a solution to dealing with the overarching issue >> of bandwidth; it’s described in the following post: >> http://www.w3.org/community/respimg/2012/06/18/florians-compromise/ >> >> In the interest of keeping relevant information on the list, I’ll >> repost the relevant section here: >> >> It would assume a great deal if authors were to make this decision for >> the users. It would add a point of failure: we would be taking the >> bandwidth information afforded us by the browser, and selectively >> applying that information. Some of us may do it wrong; some of us may >> find ourselves forced to make a decision as to whether we account for >> users with limited bandwidth or not. To not account for it would be, in >> my opinion, untenable — I’ve expressed that elsewhere, in no >> uncertain terms. I feel that bandwidth decisions are best left to the >> browser. The decision to download high vs. standard resolution images >> should be made by user agents, depending on the bandwidth available — >> and further, I believe there should be a user settable preference for >> “always use standard resolution images,” “always use high >> resolution images,” ”download high resolution as bandwidth >> permits,” and so on. This is the responsibility of browser >> implementors, and they largely seem to be in agreement on this. >> >> In discussing the final markup pattern, we have to consider the above. >> Somewhere, that markup is going to contain a suggestion, rather than an >> imperative. srcset affords us that opportunity: a new syntax _designed_ >> to be treated as such. I wouldn’t want to introduce that sort of >> variance to the media query spec — a syntax long established as a set >> of absolutes. > > How does this address the points in the e-mail I cited above? Where you were stating that you personally had yet to propose a solution to the issue of bandwidth, I thought it might bear mentioning that there has been a fair amount of discussion around the issue. I apologize if I’ve diverged too far from the original topic.
Re: [whatwg] Features for responsive Web design
On Oct 11, 2012, at 12:36 PM, Ian Hickson wrote: > On Thu, 11 Oct 2012, Markus Ernst wrote: >> >> IMHO as an author, the "bandwidth" use case is not solved in a future >> proof manner > > It's not solved at all. I didn't attempt to solve it. Before we can solve > it, we need to figure out how to do so, as discussed here (search for > "bandwidth one"): > > http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0247.html The RICG has proposed a solution to dealing with the overarching issue of bandwidth; it’s described in the following post: http://www.w3.org/community/respimg/2012/06/18/florians-compromise/ In the interest of keeping relevant information on the list, I’ll repost the relevant section here: It would assume a great deal if authors were to make this decision for the users. It would add a point of failure: we would be taking the bandwidth information afforded us by the browser, and selectively applying that information. Some of us may do it wrong; some of us may find ourselves forced to make a decision as to whether we account for users with limited bandwidth or not. To not account for it would be, in my opinion, untenable — I’ve expressed that elsewhere, in no uncertain terms. I feel that bandwidth decisions are best left to the browser. The decision to download high vs. standard resolution images should be made by user agents, depending on the bandwidth available — and further, I believe there should be a user settable preference for “always use standard resolution images,” “always use high resolution images,” ”download high resolution as bandwidth permits,” and so on. This is the responsibility of browser implementors, and they largely seem to be in agreement on this. In discussing the final markup pattern, we have to consider the above. Somewhere, that markup is going to contain a suggestion, rather than an imperative. srcset affords us that opportunity: a new syntax _designed_ to be treated as such. I wouldn’t want to introduce that sort of variance to the media query spec — a syntax long established as a set of absolutes.
Re: [whatwg] Features for responsive Web design
On Oct 10, 2012, at 4:14 AM, Maciej Stachowiak wrote: > > On Oct 9, 2012, at 2:49 PM, Tab Atkins Jr. wrote: > >> On Tue, Oct 9, 2012 at 11:48 AM, Ian Hickson wrote: >>> On Tue, 9 Oct 2012, Mark Callow wrote: On 2012/10/06 7:09, Ian Hickson wrote: > I agree, when there's 3x displays, this could get to the point where we > need to solve it. :-) With the current displays, it's just not that big a deal, IMHO. If by 3x you mean displays whose dpi is 3x that of CSS pixels (96dpi), they already exist in retail products. I saw 2 last week. >>> >>> Can you elaborate? >>> >>> How many device pixels per CSS pixel do browsers on those devices use? Are >>> they just making CSS pixels smaller, or are they actually using 3x? >> >> http://www.zdnet.com/google-nexus-10-tablet-to-have-higher-res-display-than-ipad-705466/ >> appears to be 299dpi >> http://www.iclarified.com/entry/index.php?enid=3 appears to be 440dpi >> >> These devices aren't out yet, but I suspect browsers would be >> more-or-less as high-dpi as possible. > > This page lists several devices with physical DPI higher than 288 (3x the > nominal CSS dpi) but none with a CSS pixel ratio greater than 2x. (To be > fair, the data is incomplete and may be inaccurate, though to my knowledge > the entries for Apple devices are all correct). So it's not a given that the > cited hardware dpi values would lead to higher CSS pixel ratios in the > corresponding software. No, but we do know that things are continuing to trend towards higher PPI displays, and that at some point that may lead to a higher CSS pixel ratio. As a member of the jQuery Mobile project I’ve seen this for myself with the test devices we’re receiving constantly—every new screen is sharper than the last. In fairness, no, we can’t predict the future one way or the other. That’s exactly why it’s better to plan for it than not.
Re: [whatwg] Features for responsive Web design
mplicated syntaxes, e.g. all > the event handler attributes (whose syntax is JavaScript), or style="" > (whose syntax is CSS). See also for many of the pragmas, > the attribute, , media="" attributes, etc. > Saying “there are worse things” doesn’t make much of a case for a worse thing. Better that we focus on finding the best possible approach here and avoid our previous mistakes. >> Furthermore, introducing an API would not help the use case of just >> parsing HTML in, say, Python, to programatically download all images >> from a page (or something like that). > > Sure, but for that case you just need to write a library once (just like > you only need to write an HTML parsing library once). > > >> This reminds me that ATOM have a byte length. Surfing via >> mobile, I certainly know that I would like images to show if they can be >> downloaded in a reasonable time – but I want to skip 5MB photos. > > Given that newer mobile networks are actually faster than the networking a > lot of people in the US have to their house, I don't know how much of a > lifetime such a feature would have. This seems incredibly specific to privileged browsing contexts, and hardly a standpoint that accounts for the millions of users in developing countries accessing the Internet from mobile devices alone. Users with limited bandwidth and a per-kilobyte economic cost for access to a resource that—by very design—is meant to be open and accessible to users of any context. Tim Berners-Lee can speak to that far better than I ever could. >>>> a) using the 'monocrhome' MQ to serve gray scale images to >>>> black-and-white printers or e-ink displays. Displaying a color image >>>> on a monochrome display does not always work well, as two different >>>> colors of similar luminosity would be impossible to distinguish in a >>>> monochrome environment. I expect this need to grow together with the >>>> increasing popularity of HTML based ebooks. >>> >>> Is this a real use case or a theoretical one? Until we didn't support >>> it, nobody once mentioned that it was a use case they cared about -- >>> they only mentioned dimensions as being the issue. >> >> There seem to be quite some web devices that use black-and-white epaper. >> In a world in which people optimize content for mobile, tablets and >> accessability, I would certainly consider this when making a site. >> <http://www.youtube.com/watch?v=zXZDn2Ia9js> > > Are there any sites today that do this? > > >>>> 3) you syntax is terser, which is in generally a good thing, but I >>>> think it crosses the limit, as a large number of people have >>>> expressed confusion as to w and h were min or max, for example. The >>>> extra verbosity of my syntax gets you an extra bit of clarity, >>>> admittedly at the cost of having multiple elements. >>> >>> I agree that there's a small learning curve, but it seems pretty easy >>> to understand. Do we really want to trade the small learning curve for >>> a perpetuity of verbosity? >> >> As a programmer using Python, I am would argue for the latter. If markup >> is easier to read and understand for humans, people make fewer errors. >> Certainly, in uncommon cases (I consider a common case) verbosity is >> helpful for both learning and readability. > > Well sure, the point is to strike the right balance. > > >>> Fundamentally, a multiple-element solution here is simply a >>> non-starter, IMHO. The pros of the multielement solution with verbose >>> media queries are about the same in magnitude as the pros of the >>> one-attribute solution with terse syntax, but the cons of the terse >>> syntax are small whereas the cons of the multiple-element syntax are >>> immense. For the multi-element solution to be a net positive over the >>> one-attribute solution, the magnitude of its "pros" would have to be >>> enormous. >> >> Does readability count? > > It's not at all clear to me that the proposals are more > readable. It's certainly not an enormous enough difference to be relevant. Perhaps, given the lack of clarity on this point, we might consult the opinion of authors. > On Wed, 5 Sep 2012, Mathew Marquis wrote: >>> >>> Whether it's easier for script is hard for me to say, because I don't >>> really understand what scripts are going to be doing here. Can you >>> elaborate? What will scripts need to do here? >>&
Re: [whatwg] Features for responsive Web design
On Sep 6, 2012, at 7:26 AM, Simon Pieters wrote:
> On Wed, 05 Sep 2012 19:45:41 +0200, Mathew Marquis
> wrote:
>
>> I can say for my own part: manipulating strings is far more difficult than
>> manipulating the value of individual attributes. It’s hard to imagine a
>> situation where I’d prefer to muck through a space/comma separated string
>> rather than a set of independent elements and attributes. Unless the plan is
>> to include an API similar to classList, though it would then be occupied by
>> a set of strings describing disparate information.
>
> The implementation complexity for multiple elements is much greater compared
> to an attribute (or even several attributes, so long as it's just one
> element) plus an API. See
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/035784.html and
> search for "it doesn't involve multiple elements." in
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0070.html
> for why.
>
>> Given `srcset="img2.jpg 2x 300w, img3.jpg 600w 2x"`, I can only envision a
>> classList-style API returning something like one of the following:
>>
>> 1) [ "img2.jpg", "2x", "300w", "img3.jpg", "600w", "2x" ]
>> This obviously isn’t ideal where authors will have no idea what information
>> is being manipulated without keeping constant tabs on the current index as
>> compared to the string in the markup. Even if the order of these separate
>> concerns were normalized, the inclusion or omission of any individual aspect
>> of a rule would mean a flurry of `console.log`s in order to figure out which
>> index represented which concern — or careful counting of spaces in one’s
>> markup, which certainly seems error-prone to me. I know I would certainly
>> make mistakes, there.
>>
>> 2) [ "img2.jpg 2x 300w", "img3.jpg 600w 2x" ]
>> We’re still left parsing space-seperated strings for relevant information,
>> albeit smaller ones.
>
> 3) [ { src:"img2.jpg", x:2, w:300 }, { src:"img3.jpg", x:2, w:600 } ]
>
> Except as host objects so that setting the properties actually updates the
> attribute. (src="" can also be exposed in the same API.)
>
>> I don’t feel there’s much of a case to be made in favor of writing regular
>> expressions to parse and manipulate strings, rather than manipulating
>> elements and attributes — though, as always, I’m happy to reach out to the
>> author community and ask. If I’m completely off-base here — and I may well
>> be — I’d certainly be interested in reading more about the plans for an API.
>
> (3) above doesn't need regexps.
After a quick read through the existing spec for `source`, it seems we wouldn’t
be forced to manipulate `source` elements and attributes themselves in order to
reevaluate the most appropriate `source` for a given `picture` element. We
would instead be setting the `src` on the `picture` element itself.
http://dev.w3.org/html5/spec/single-page.html#the-source-element
Given the parity between JavaScript’s `matchMedia` and `media` attributes, and
given `devicePixelRatio` for determining the appropriate resolution, it would
make it simple to determine the most appropriate source before setting it on
the `picture` element: then, we need only access one element in the DOM, set a
relevant value within a single attribute, and we’re finished. This makes
_setting_ values an equally trivial task with either solution—though if the
author is inclined towards making layout decisions based on `em`s (an
increasingly common practice), those values will have to be converted to
pixel-based values in order to work with the extended `srcset` syntax.
In terms of retrieving information from either element, the previous discussion
stands: we’re left parsing a single string or tapping into a highly-specific
API attached to `img` in the case of the extended `srcset` syntax, or accessing
standalone elements and attributes in the case of `picture`. The latter
certainly seems easier from an authorship perspective; I’m curious as to how
much more complication is involved in implementing an API on `img`, to cater to
the extended `srcset.`
>
> --
> Simon Pieters
> Opera Software
>
Re: [whatwg] Features for responsive Web design
On Sep 4, 2012, at 3:47 PM, Ian Hickson wrote: >> >> [...] >> >>> On Thu, 24 May 2012, Florian Rivoal wrote: >>> >>> I don't understand why this is better than: >>> >>>>> alt="..."> >>> >>> ...which as far as I can tell does exactly the same thing. >> >> It is better because art direction and bandwidth use cases can be solved >> differently in an appropriate manner: >> - For the bandwidth use case, no MQ is needed, but only some information on >> the sources available to let the UA decide which source to load. >> - For the art direction use case OTOH, the element is more >> intuitive >> to handle and also easier to script, as sources can be added or removed via >> DOM. > > I don't understand why it's more intuitive and easier. It seems way more > unwieldly. I’m not sure how exactly to prove to you that developers find the extended syntax unintuitive apart from continuing to point out the things that developers themselves have said on the topic, and I’m still not certain how the way it “feels” trumps the sentiments that you’ve read for yourself. I suppose we’ve reached an impasse. > > Whether it's easier for script is hard for me to say, because I don't > really understand what scripts are going to be doing here. Can you > elaborate? What will scripts need to do here? > > If it is harder to script, we can always provide a dedicated API. > > Manipulating from script would be a huge pain -- you'd have to > be manipulating lots of elements and attributes. > I can say for my own part: manipulating strings is far more difficult than manipulating the value of individual attributes. It’s hard to imagine a situation where I’d prefer to muck through a space/comma separated string rather than a set of independent elements and attributes. Unless the plan is to include an API similar to classList, though it would then be occupied by a set of strings describing disparate information. Given `srcset="img2.jpg 2x 300w, img3.jpg 600w 2x"`, I can only envision a classList-style API returning something like one of the following: 1) [ "img2.jpg", "2x", "300w", "img3.jpg", "600w", "2x" ] This obviously isn’t ideal where authors will have no idea what information is being manipulated without keeping constant tabs on the current index as compared to the string in the markup. Even if the order of these separate concerns were normalized, the inclusion or omission of any individual aspect of a rule would mean a flurry of `console.log`s in order to figure out which index represented which concern — or careful counting of spaces in one’s markup, which certainly seems error-prone to me. I know I would certainly make mistakes, there. 2) [ "img2.jpg 2x 300w", "img3.jpg 600w 2x" ] We’re still left parsing space-seperated strings for relevant information, albeit smaller ones. I don’t feel there’s much of a case to be made in favor of writing regular expressions to parse and manipulate strings, rather than manipulating elements and attributes — though, as always, I’m happy to reach out to the author community and ask. If I’m completely off-base here — and I may well be — I’d certainly be interested in reading more about the plans for an API.
Re: [whatwg] Features for responsive Web design
On Aug 7, 2012, at 3:09 PM, Ian Hickson wrote: > On Tue, 15 May 2012, Matthew Wilcox wrote: >> >> I do not see much potential for srcset. The result of asking the author >> community was overwhelmingly negative, indirection or no indirection. > > I'm happy to consider specific feedback, but at the time in this thread > where this e-mail was sent, We had yet to receive any negative commentary > at all on the mailing list, so this seems a bit vague. :-) A great deal of author feedback was posted to http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/, the link to which was posted to the mailing list several times. You’ll notice that the comments are nearly unanimous. At the time this was posted the CG sites were taken down due to excessive traffic, as authors sounded off on the subject. There was also no small measure of relief from the #whatwg regulars once the IRC traffic died down, as I recall. Prominent members of the developer community haven’t been terribly subtle in their opinions of the markup, either: https://twitter.com/zeldman/status/233232252111302657 When the syntax is the butt of jokes at high-profile conferences, it might be time to accept that we authors aren’t especially partial to it. If you’d prefer I instruct the developer community to comment on this thread instead, I’m happy to do so. If author sentiment was somehow ignored the first time, though — if it either went wholly unnoticed by the decision-makers, or is now being disregarded due to where those sentiments were posted — I don’t see where it will change much apart from several hundred more emails to prove a fairly self-evident point. Since author preference has been cited several times in support of the terseness of the extended `srcset` syntax, I think it’s probably best that we not discount the methods by which authors voice their own preference if the real goal is an author-friendly pattern — unless we’re dismissing the “authors will prefer the shorter syntax” argument as well. Perhaps that would be the second best course of action here. Mat Marquis
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On Jul 23, 2012, at 5:38 PM, Steve Faulkner wrote: > Hi Mat, > as I previously previously mentioned, I am concerned about the use of the > alt attribute on when it would be much better to allow text > alternatives inside the picture element. > Some of the advantages are: > Markup can be used to structure text alternative content. > The length of the alt text is no longer a constraint, as it is currently > for assistive tech. > > > > > > > > > > is there any reason why you think the use of alt attribute on picture is > preferable to > > > > alt text > > > > > > > Yeah, this would be a bit tricky in terms of backwards-compatibility, as you said. I feel the gut reaction from a lot of authors would be “I don’t want that text showing up in some browsers but not others,” then (sadly) omission. It’s hide-able with CSS, as you said, but it would add some complexity. > > note:role=img is just of polyfill purposes. > > or > > > > > > > > > > > > caption text > This seems like a great candidate for `figcaption`, and could be pollyfilled, in a way, through the use of `aria-describedby`. I wouldn’t want to discourage the use of `alt` tags on either `picture` or the fallback `img`, but — and correct me if I’m wrong — isn’t `aria-describedby` specced to take precedence over the `alt` attribute? That might be the ideal approach — and even if not, a bit of redundancy may not hurt there. > > I can understand that backwards compatibility may be of concern in the > first example, but that can be resolved through the use of CSS to clip or > hide text content if so desired. > > regards > Stevef > > > > On 23 July 2012 20:06, wrote: > >> Send whatwg mailing list submissions to >>whatwg@lists.whatwg.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >>http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org >> or, via email, send a message with subject or body 'help' to >>whatwg-requ...@lists.whatwg.org >> >> You can reach the person managing the list at >>whatwg-ow...@lists.whatwg.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of whatwg digest..." >> >> >> When replying to digest messages, please please PLEASE update the subject >> line so it isn't the digest subject line. >> >> Today's Topics: >> >> 1. Re: Media queries, viewport dimensions, srcset and picture >> (Mathew Marquis) >> >> >> -- >> >> Message: 1 >> Date: Mon, 23 Jul 2012 11:39:14 -0400 >> From: Mathew Marquis >> To: whatwg@lists.whatwg.org >> Cc: Florian Rivoal >> Subject: Re: [whatwg] Media queries, viewport dimensions, srcset and >>picture >> Message-ID: >> Content-Type: text/plain; charset=windows-1252 >> >> WHATWG, >> >> The Responsive Images Community Group was recently asked to furnish a >> formal draft proposal for consideration by the HTML WG. I thought it best >> to post it here along with some details, where Ian Hickson has mentioned >> that he?ll be considering this issue again within a few days. >> >> More and more it seems that it?s a waste of effort trying to retrofit the >> original srcset proposal to cover all the use cases of the original >> `picture` proposal. As we attempt to do so, the `srcset` msyntax grows more >> confusing, and shares an increasing amount of overlap with media queries ? >> though with some obvious holes, for example: units other than `px`. To >> those ends, the Responsive Images Community Group has officially published >> a draft proposal based on Florian Rivoal?s proposed compromise ( >> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/036160.html) >> between the two markup patterns. In this way, `srcset` retains the >> purpose for which it was originally proposed: a terse, easily-implemented >> syntax for switching image sources based on the client resolution. >> >> The draft proposal can be found here: >> http://www.w3.org/community/respimg/wiki/Picture_Element_Proposal >> >> Discussion with the HTML WG can be found here: >> http://lists.w3.org/Archives/Public/public-html/2012Jun/0113.html >> >> ## Proposed Markup >> >> >> >> >> >> >> >> >> The chain of events followed by the above markup pattern are: >> >> 1.
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
WHATWG, The Responsive Images Community Group was recently asked to furnish a formal draft proposal for consideration by the HTML WG. I thought it best to post it here along with some details, where Ian Hickson has mentioned that he’ll be considering this issue again within a few days. More and more it seems that it’s a waste of effort trying to retrofit the original srcset proposal to cover all the use cases of the original `picture` proposal. As we attempt to do so, the `srcset` msyntax grows more confusing, and shares an increasing amount of overlap with media queries — though with some obvious holes, for example: units other than `px`. To those ends, the Responsive Images Community Group has officially published a draft proposal based on Florian Rivoal’s proposed compromise ( http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/036160.html ) between the two markup patterns. In this way, `srcset` retains the purpose for which it was originally proposed: a terse, easily-implemented syntax for switching image sources based on the client resolution. The draft proposal can be found here: http://www.w3.org/community/respimg/wiki/Picture_Element_Proposal Discussion with the HTML WG can be found here: http://lists.w3.org/Archives/Public/public-html/2012Jun/0113.html ## Proposed Markup The chain of events followed by the above markup pattern are: 1. If the `picture` element is unsupported, the `img` contained therein is shown as fallback markup. 2. If picture is supported, use `media` attributes to determine which source element best suits the user’s viewport, following the same logic as `video`’s specced use of `media` attributes. 3. Once an appropriate source element has been selected, the `srcset` attribute determines which image source is best suited to the user’s screen resolution. If only a single resolution is necessary, the `src` attribute will function as expected, instead. In terms of selecting a source element, this markup leverages all the strengths of media queries — the syntax created for this very purpose — to handle the “art direction” use case. However, as has been detailed at length here and elsewhere, `device-pixel-ratio` media queries are poorly suited towards these decisions. As an author, using vendor-prefixed `min-device-pixel-ratio` media queries in the example above would involve a massive amount of text and twice as many source elements. This could get unwieldy for authors very quickly, a concern voiced numerous times in these ongoing discussions. Further, implementation of MQ-based resolution switching is far more difficult on the UA side: a very real concern. Once we’ve used media queries to determine the most appropriate source element, srcset’s originally intended usage becomes absolutely ideal for our purposes: simply determining the appropriate image source for a user’s resolution. It’s worth noting that this example is, in fact, the most convoluted this element can ever be. This pattern in no way precludes the use of srcset on an `img` tag for simply preforming resolution switching, nor does it preclude the use of `picture` as originally proposed for the “art direction”/screen size use cases, with `src` in source elements rather than `srcset`. ## Bandwidth We cannot reliably make assumptions about bandwidth based on client capabilities — a MacBook Pro with a Retina display may be tethered to a 3G phone; a high-resolution mobile device is as likely to be connected to WiFi as it is an EDGE connection. Based on previous discussion on the list, I think we’re largely in agreement that bandwidth decisions are best left to the browser. It would assume a great deal if authors were to make this decision for the users. It would add a point of failure: we would be taking the bandwidth information afforded us by the browser, and selectively applying that information. Some of us may do it wrong; some of us may find ourselves forced to make a decision as to whether we account for users with limited bandwidth or not. To not account for it would be, in my opinion, untenable — I’ve expressed that elsewhere, in no uncertain terms. The decision to download high vs. standard resolution images should be made by user agents, depending on the bandwidth available — and further, I believe there should be a user settable preference for “always use standard resolution images,” “always use high resolution images,” ”download high resolution as bandwidth permits,” and so on. In discussing the final markup pattern, we have to consider the above. Somewhere, that markup is going to contain a suggestion, rather than an imperative. I think `srcset` affords us that opportunity: a new syntax _designed_ to be treated as such. I wouldn’t want to introduce that sort of variance to the media query spec — a syntax long established as a set of absolutes. It seems `srcset` won’t be going anywhere, and that’s not an indictment. There i
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On May 29, 2012, at 6:49 AM, Florian Rivoal wrote: >> * It has two attributes that could easily be confused as doing the >> same job. There's little clear logic as to why they're split, from an >> authors viewpoint. > > It might be confusing, but there is logic in the splitting: > > srcset="." lets you describe the properties of a set of > equivalent images, and the browser decides which > one is more appropriate given the environment. > > should be displayed based on the properties of the medium > you're displaying on. > This makes perfect sense, and certainly seems to cover all of the potential use cases of `picture` and `srcset` alone — even so far as preserving the brevity of the original proposal, in cases where that markup pattern is most appropriate. Is it fair to say that `srcset` will likely remain drafted as a solution to the resolution issue alone, and that `picture` with `srcset` functionality added should be handled as a separate proposal altogether? Just looking for some guidance on how to proceed from here. Thanks, Mat Marquis
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On May 24, 2012, at 3:58 AM, Florian Rivoal wrote: > On Wed, 23 May 2012 21:18:25 +0200, Scott Jehl wrote: > >> With this proposal, could "src" be used on a source element if you don't >> need the features srcset provides? >> >> Or maybe, would that just be equivalent to srcset with a single source >> listed? > > I have no strong preference for src vs srcset with a single source and no > density > qualifier, but yes, one of them should be available. > I’m a little uneasy at the silence following Florian’s proposal. I’d love to hear the WHATWG’s thoughts on this compromise. > - Florian
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On May 23, 2012, at 11:21 AM, Florian Rivoal wrote: > > Having said all that, I think srcset="foo.jpg 1x, foo2.jpg 2x" is quite > good, because it does indeed provide the browser with a set of images with > different quality, leaving it free to pick the appropriate one. > > On the other hand, I think that including 600w 400h in there is misguided. > It doesn't help for the problem of picking the right image for the right > resolution/bandwidth combination, but is too crippled to be useful as > media queries meant to serve different images to in different scenarios. > serves these use cases much better. > > Here's what I think we should do: > > 1) simplyfy srcset to only accept the *x qualifier > > 2) add support for srcset as an attribute of the sub-element of > the element (in addition to src, or instead of it? I am not > sure). > > Then you could do stuff like this: > > > > > Honestly, I think this is a brilliant compromise between the two patterns: combining authors’ overwhelming preference for media queries, the need for layout-based art direction, the (relative) simplicity of `srcset` for implementors, and the potential to hinge low/high res images on future bandwidth detection without compromising media queries in the process. I believe this is now my preferred solution, and I hope I’m not alone in that. > > Note that it is different from: > > > src="long.jpg"> > src="long2.jpg"> > src="tall.jpg"> > src="tall2.jpg"> > > > > because it allows the browser to be smart about loading the high or low > res image depending on the network conditions. The solution purely based > on media queries doesn't let you do that. > > One final note: the "1x, 2x" ... solution still has one problem that I > think cannot be properly solved purely in html/css. Even though the > browser can be smart about which image to used based on network > conditions, it still cannot escape the fact that to change its mind half > way through, it will have wasted time downloading the wrong image. It > may be worth it in some cases, but it is still wasteful. > > I believe the only way out is through an image format that: > - stores multiple resolutions in one file > - stores the higher resolution as incremental information on top of the > low res, so that downloading low res images isn't a waste of time even if > you want the high res. > - is designed so that the browser can stop downloading half way through > the file, if it determines it got sufficiently high resolution given the > environment. > > This would allow browsers to switch from wanting a high res image to > wanting a low res image without having to restart the download from > scratch, which is really bad, as the main reason for switching from high > to low is a bad network. When the browser is aiming for the high res > image, it still gets some lower quality image to display temporarily while > the higher quality image is being downloaded. > > I am not enough of an image guy to know if progressive jpeg or webp or > some other existing format has these characteristics. > > The "1x, 2x..." syntax probably needs to be tweaked to accommodate such > images: > srcset="standard.jpg 1x, progressive.prog 0.1-4x" > > Even if we don't have an existing format for that, the html syntax should > probably anticipate it, so that soon-to-be implemented UAs don't get > confused when they get served content from the longer term future that > uses this syntax. > > As an aside, This syntax might work to mix raster images and vector > images: srcset="foo.svg 0.1-0.5x, foo.jpg 1x"
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On May 22, 2012, at 5:43 AM, Anne van Kesteren wrote: > On Tue, May 22, 2012 at 10:21 AM, Markus Ernst wrote: >> I am somehow surprised that there are no reactions to this proposal. To me >> as a humble author it looks like it would address the main issue of both >> and @srcset, as it leaves the MQ to CSS, and thus separates design >> from content. > > 1. It does not address the pixel density use case. 2. A pattern-based > approach was actually mentioned in Ian Hickson's email when he > announced the srcset attribute. > We’re apt to see the element used in one of two ways: * Serving a size-appropriate image source in a flexible layout, wherein the size of the images will be controlled by CSS—typically, `max-width: 100%`. Using a pixel density MQ will serve a larger image within this constraint. Inherent size is not a concern with this case—which is fortunate, as this will likely require sources with varying dimensions, per the “art direction” case. * Serving a static-dimension asset at varying resolutions, a la Apple.com. To always rely on the intrinsic size of another source is to negate the art direction use case — however, we could simply add optional `width` and `height` attributes to `picture`, constraining the higher res image to a specified set of dimensions. This leaves control in the authors’ hands in a simple, predictable way without negating either use case. I can’t speak to this personally, but Kornel has mentioned that using said attributes instead of relying on a calculated inherent width will avoid reflows. It should likely be an option in either case. > > -- > Anne — Opera Software > http://annevankesteren.nl/ > http://www.opera.com/
Re: [whatwg] Correcting some misconceptions about Responsive Images
>> >> I don’t think this is the case. The public has largely resigned this to >> “`srcset` is happening because the WHATWG said so,” for certain, and that >> doesn’t seem entirely false—but I don’t think “hopeless acceptance” is the >> situation at present. I’ve been off the grid for a few days, but as I catch >> up on the conversation it seems as though a number of the RICG’s members >> have been contributing to the incremental improvement of the `srcset` >> proposal. I’m all for it, of course, as the goal was never _this or that_ >> solution so much as a solution that covers our use cases in the most >> developer-friendly way possible—and above all else, a solution with the most >> benefit to users. >> >> The goal now—as ever—is the best possible solution. If we’re limited to >> `srcset`, then the goal is to make that as useful as possible. However, I’d >> be lying if I said it isn’t frustrating, feeling as though we’re all working >> from a forgone conclusion. > > It's unfortunate that there was an expectation set early in the RICG > that their purpose was to produce spec-ready text to be included into > HTML. Hopefully we'll do a better job in the future communicating > that what's necessary is use-cases to design a feature around, so we > don't run into similar expectation mismatches. > > ~TJ You’re certainly right that it’s not worth bickering about, and I apologize if I came across that way. I only hope that “we’ll do a better job in the future” has no reflection on the current discussions — mis-matched processes are no reason to throw away useful data, after all, and the Community Group has no shortage of that.
Re: [whatwg] Features for responsive Web design
On May 18, 2012, at 5:19 PM, Kornel Lesiński wrote:
> On Fri, 18 May 2012 20:24:00 +0100, André Luís wrote:
>
>>> Make no mistake; this is not a pride or attachment thing, this is a
>>> knowing the reasons thing. I personally don't think answers
>>> things well enough, nor do I think srcset does. Not for general use
>>> cases - but for specific one-off use cases, each has benefits.
>>
>> Absolutely. And from what I read (and I admit not reading the entire
>> archive of messages, but still, prefer to say my piece anyway) the
>> main concern about picture was the potencial verbosity. Instead of
>> trying to solve this issue, it got discarded.
>
> in its current form is unable to support bandwidth-based
> negotiation well (and that's not simply a matter of adding bandwidth media
> query) and has no mechanism to specify scaling factor for intrinsic sizes of
> images.
Is there currently any documentation explaining how bandwidth is better handled
by `srcset`? Seeing as any discussion around bandwidth is almost entirely
theoretical, I have a hard time understanding where bandwidth concerns preclude
one approach or the other.
There’s a case to be made that few people implementing any form of “responsive
images” solution will find a need to rely on an image’s intrinsic width, as
doing so effectively negates any flexibility to begin with, which is almost
entirely the point of either solution. This is a valid point, however, and very
likely something that we could solve on the implementor’s side.
There’s no prior precedent this sort of thing—there’s no reason we can’t find a
way to preserve an image’s intrinsic width using `picture`. I wonder if simply
adding `width` and `height` attributes on the element (similar to `img`) might
solve this, in the event that the author wants to rely on an intrinsic size
instead of CSS?
>
> IMHO those are pretty serious drawbacks that limit its functionality, which
> is much worse than "ugly, but gets job done" state of srcset.
>
> There are two categories of use-cases ("art-directed" and "dpi/optimization")
> and is suited for only one of them, so please don't frame the
> decision as "discarding" of a perfectly good solution, as it wasn't.
>
>
>
> srcset addresses both dpi/optimisation and art-directed use-cases. It has its
> own problems, such as confusing microsyntax, so suggestions how to improve
> this are welcome.
>
> Lamenting and accusing WHATWG of wrongdoing is not productive.
André didn’t seem to claim any loyalty to one solution or the other and, unless
I’ve missed something earlier in the thread, certainly didn’t accuse anyone of
“wrongdoing.” You’ve jumped to an oddly defensive place here, and that only
reinforces an “us vs. them” perception that I’m certain we’d all prefer to move
away from. I know I would.
> If you'd like to see proposal succeed, then please help fixing its
> drawbacks. Make selection and embedding of 2x images easier. Give UA freedom
> to use cached higher-quality images when it can. Give UA freedom to choose
> images to minimize bandwidth or maximize quality. Reduce verbosity of most
> common cases.
This is where I assumed we would be working with you, and I continue to hope
that we can. I’d really prefer there not be “sides” in this, rather than all of
us seeking the best possible solution. If you feel `picture` could have
potential given improvements on the UA end, well, that’s what we’re here
for—your input, and your collective expertise.
If we can bring `picture` in line with what implementors have in mind while
preserving something close to the markup pattern authors prefer, we’ll have a
solution that benefits everyone equally.
> I've tried to raise those issues on the Responsive Images group's
> mailinglist, but got no constructive feedback.
We were admonished in an earlier thread for using the RICG’s mailing list to
work in a vacuum (though it was seldom used, and any meaningful conclusions
were published to the RICG). If this is the correct forum for these ongoing
discussions, it’s likely best that we keep it here.
>
> --
> regards, Kornel Lesiński
Re: [whatwg] Correcting some misconceptions about Responsive Images
Well, if nothing else, I can certainly speak to the Community Group’s frustration on this subject — and to a lesser extent, the development community in general. > However, it still looks like the most upsetting implication of his > timeline, namely that the WHATWG is prioritizing implementors over > authors, remains unclarified. Is it a misconception to say that the > levels of priority outlined in the W3C HTML design principles [4] are > not being followed here? Especially since it seems that we can extend > Tim's timeline with: > > 7. Authors react negatively to the addition of 'srcset' in the draft. For myself at least, much of the frustration came from an eagerness to work with the WHATWG on solving this issue only to be met with sentiment to the tune of “that’s okay; we’ve pretty much solved this already.” `srcset` went from an initial proposal to addition to the draft within a handful of days, during which time we were told that we hadn’t followed the proper processes for proposing `picture`, and were lacking for proof, citations, and documentation. We were asked to furnish use cases, polyfills, a more formal proposal, and proof of developer sentiment on their preferred markup pattern. While we we working to provide these, `srcset` went from http://junkyard.damowmow.com/507 to a draft based largely on conversation in the IRC channel. Speaking for myself, one can’t help but feel as though we were given a separate set of rules and a process of our own. During this time, the most common argument was that some variation of `srcset`—or simply forgoing media queries altogether—would be easier for implementors, and that the `picture` markup contained too many characters. Where there’s no shortage of evidence that authors prefer the more verbose syntax, well, we were left with only one initial conclusion. > 8. The 'living' draft is not changed and the authors' anger eventually > fades into hopeless acceptance because once something goes in to the > draft, it is set in stone forever and for all time. I don’t think this is the case. The public has largely resigned this to “`srcset` is happening because the WHATWG said so,” for certain, and that doesn’t seem entirely false—but I don’t think “hopeless acceptance” is the situation at present. I’ve been off the grid for a few days, but as I catch up on the conversation it seems as though a number of the RICG’s members have been contributing to the incremental improvement of the `srcset` proposal. I’m all for it, of course, as the goal was never _this or that_ solution so much as a solution that covers our use cases in the most developer-friendly way possible—and above all else, a solution with the most benefit to users. The goal now—as ever—is the best possible solution. If we’re limited to `srcset`, then the goal is to make that as useful as possible. However, I’d be lying if I said it isn’t frustrating, feeling as though we’re all working from a forgone conclusion. > Ok, so 8 is both hyperbolic and in the future, but a lot of people > seem to think that this is where we are headed. Personally, I'm not > angry about this and I'm willing to calmly listen to corrections, I'm > just trying to wade through all the misinformation here. > > -Brenton Strine > > [1] http://timkadlec.com/2012/05/wtfwg/ > [2] http://adactio.com/journal/5474/ > [3] http://www.goodreads.com/author_blog_posts/2463167-secret-src > [4] http://www.w3.org/TR/html-design-principles/
Re: [whatwg] , `img set`, and polyfills
On May 14, 2012, at 8:29 PM, Kang-Hao (Kenny) Lu wrote: > (12/05/15 7:17), Mathew Marquis wrote: >> It’s worth noting that a practical polyfill may not be possible when using >> `img set`, for reasons detailed at length elsewhere: >> http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/ >> http://www.netmagazine.com/features/state-responsive-images >> >> Long story short: attempting to write a polyfill for `img set` leaves us in >> the exact situation we were in while trying to solve the issue of responsive >> images strictly on the front-end. We would be saddling users with a >> redundant download—first for the original src, then for the >> appropriately-sized source if needed. >> >> Where the new element would be all but ignored by existing browsers, >> efficient polyfills become possible. In fact, two `picture` polyfills exist >> today: http://wiki.whatwg.org/wiki/Adaptive_images#Functional_Polyfills > > Sorry but I don't understand why as used around by > these polyfills listed can't be used along . > > If your point is that some Web developers will not cater for NoScript > users and chose to include in , I think those authors can > use without @src too (if I understand correctly). > Scott Jehl has just posted a great write-up of some of the challenges associated with working around the `img` tag. https://gist.github.com/2701939 > > Cheers, > Kenny
[whatwg] , `img set`, and polyfills
It’s worth noting that a practical polyfill may not be possible when using `img set`, for reasons detailed at length elsewhere: http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/ http://www.netmagazine.com/features/state-responsive-images Long story short: attempting to write a polyfill for `img set` leaves us in the exact situation we were in while trying to solve the issue of responsive images strictly on the front-end. We would be saddling users with a redundant download—first for the original src, then for the appropriately-sized source if needed. Where the new element would be all but ignored by existing browsers, efficient polyfills become possible. In fact, two `picture` polyfills exist today: http://wiki.whatwg.org/wiki/Adaptive_images#Functional_Polyfills Thanks, Mat Marquis
Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)
On May 13, 2012, at 7:03 PM, Boris Zbarsky wrote: > On 5/13/12 3:20 PM, Mathew Marquis wrote: >> I doubt any UAs will be forced to misinterpret common media queries because >> they haven’t been accounted for. > > Opera has already been forced to do this. For example, in its projection > mode it matches both the "projection" and "screen" media queries (technically > a spec violation) because of all the sites that explicitly say "screen" when > they really mean "not print" (or in the absence of that query in downrev UAs > when they mean "screen, projection, tv"). Now of course part of the problem > here is that "screen", "projection", and "tv" are mutually exclusive, which > is in retrospect silly. > > This is an excellent example of the fundamental divide about optimism vs > pessimism here: the things that web authors doubt UA vendors will be forced > to do because of web authors making bogus assumptions are things that UA > vendors have already been forced to do for years because web authors ... make > bogus assumptions. > > -Boris You make an excellent case for standards bodies working more closely with developers during the implementation of things like media queries. With a better sense of the ways developers might misuse, misinterpret, or fail to understand standards, issues like you describe could potentially be better avoided. But I suppose we’ve gone off-topic, to an extent.
Re: [whatwg] Fallback for
On May 13, 2012, at 4:20 PM, Kornel Lesiński wrote: > > Syntax used on the wiki: > http://wiki.whatwg.org/wiki/Adaptive_images > > places alt on the new element: > > > > > > > > I think it can be improved in two ways: > > - Instead of having alt on , it could be on the fallback . This > will give better backward-compatibility. Seems perfectly reasonable to me. I assumed an alt tag on both picture and the fallback, but this could serve to both cut down on redundancy for authors _and_ encourage authoring that’s equally accessible whether or not `picture` is supported. > > - Use of an attribute for alternative content is very limiting, e.g. image of > a comic cannot have dialog marked up well. Use of an non-empty element opens > up possibility of richer alternatives. I whole-heatedly agree. The primary objective is accessibility, for certain, but being able to serve tabular data as the fallback for a complex infographic stands to benefit _everyone_. I’d love to explore this further. > > > The processing rules for extracting fallback from would be: > > 1. Take all children of > 2. Remove/ignore all elements. > 3. Interpret all elements as their alt text. > > > > > > > > and > > > > >This is structured fallback > > > The two examples above would have "This is unstructured fallback" and "This > is structured fallback" as their alt, respectively. > > > A use case for markup in alt: > > > >CountryMost popular browser... > > > Trying to put all data in alt="" wouldn't work well, and > > > > doesn't contain the information that the map conveys, so that's at best a > caption, not an alternative. > > -- > regards, Kornel Lesiński
Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)
On May 13, 2012, at 1:01 PM, Benjamin Hawkes-Lewis wrote: > On Sun, May 13, 2012 at 5:21 PM, Mathew Marquis wrote: >>> AND they have to update their sites and mediaqueries when we get >>> something new to optimize for. I don't think they will do that, based on >>> how extremely big the problem with -webkit-prefixes are. >>> >>> I've seen enough of the web to be sceptical. >> >> The amount of “developers can never be trusted with this” sentiment I’ve >> heard from the members of this group is incredibly depressing. > > That it depresses you does not mean that taking a more optimistic > viewpoint will produce specifications that will result in better > end-user experiences. > >> When we get “something new to optimize for,” we start adding that thing >> going forward. The evolution of media queries—or, say, HTML5—hasn’t led to a >> need to constantly revisit every piece of client work a developer has ever >> produced. > > In the case of webkit prefixes, authors have needed to update their > work, have failed to do so, and now user agents are having to support > webkit prefixes. > > The key problem about designing a responsive images solution around > user agent characteristics not image characteristics is that authors > will inevitably make more false assumptions about what images match > what user agent characteristics than user agents will. As a result, > user agents may be forced to misinterpret media queries in order to > provide their users with better user experiences. Correct me if I’m wrong, but wouldn’t this same reasoning apply to layouts that depend heavily on media queries? The primary characteristics in play are screen size and resolution. I doubt any UAs will be forced to misinterpret common media queries because they haven’t been accounted for. I doubt UAs could, in fact—or would care. It wouldn’t be a matter of neglecting to support their product. It would be a matter of neglecting to supporting a screen at 310px wide. This is to say nothing of the fact that the objective of a responsive layout _is_ to properly accommodate the widest possible range of displays. The things you’re trying to prevent are the things we’re trying to avoid anyway. > > What authors _can_ do and user agents _cannot_ do is describe their > images. Such metadata never needs to be misinterpreted and allows user > agents to iterate and improve the end-user experience even when the > author either does not care about them, or has moved on, or is long > dead. Is authors not caring about user agents a real problem? > Certainly is - witness Opera's failed efforts to get authors to > support more than Webkit, witness the widespread inaccessibility of > web services, etc. > > Depressing but true. > > -- > Benjamin Hawkes-Lewis
Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)
On May 13, 2012, at 9:42 AM, Odin Hørthe Omdal wrote: > >> Connection speed >> As an extension of the iPad example above, it would also be >> irresponsible to serve the high res image to users that do have a high >> pixel density display but are not on a fast internet connection for >> whatever reason. So you might write: >> >> >> >> >> > > As I said, this is one of my big gripes with this proposal. I don't > think this'll work satisfactorily, it puts the burden on figuring out > what is correct for that user into the page author's control. That model > skews the responsibility so that instead of only a few browser engines > having to get it right, millions of web page authors have to get it > right. We’re speaking in theoreticals here, which is what makes it hard for me to wrap my head around it being anyone’s major gripe with either proposal. Maybe a bandwidth media query isn’t the solution? Maybe, when the time comes, we do rely on the UA to make that decision. Maybe there’s a user preference that could be set. This line of reasoning doesn’t speak for or against either approach, however. > > AND they have to update their sites and mediaqueries when we get > something new to optimize for. I don't think they will do that, based on > how extremely big the problem with -webkit-prefixes are. > > I've seen enough of the web to be sceptical. The amount of “developers can never be trusted with this” sentiment I’ve heard from the members of this group is incredibly depressing. When we get “something new to optimize for,” we start adding that thing going forward. The evolution of media queries—or, say, HTML5—hasn’t led to a need to constantly revisit every piece of client work a developer has ever produced. We’re speaking in terms of optimization because that’s what it is: incremental improvements to the way assets are loaded. As more become available, requests become more tailored. > > > What if a the author doesn't write that min-connection-speed query > there? And who is the author of a page to decide such things anyway? > What about latency? Should there be a max-latency: 10ms, there as well? > What about cost? I have a fast line, but it costs money to download > stuff, so I'd like the smaller pictures. What about if I have slow > internet connection, but I'd want to print the page, thus getting the > best version of the image? Or if I'm sitting with my new fancy hires KDE > Tablet and loading your page in a background-tab, letting it render and > be finished while I continue to read the page I'm on (the browser might > very well want to load the highres picture then, even though the > connection is slow, but with MQ, not that lucky). I think this has has forked well into “should we have bandwidth available in a media query” territory. It’s a worthwhile topic for sure, but apart from being a minor and—again—purely speculative factor in considering an adaptive images approach, it is another conversation. Mat Marquis
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: 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: [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 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 and > syntax? > > When Ted proposed , 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
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 , 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 > in the spec. > > With ..., 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 > 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] for responsive bitmapped content images
On May 10, 2012, at 8:36 AM, Scott González wrote: > You should look into the previous discussions at > http://www.w3.org/community/respimg/ > > There's also a prototype using media queries at > https://github.com/scottjehl/picturefill. I realize you specifically said > you think media queries don't solve all of the problems, but it seems worth > looking at. > I can’t second Scott’s suggestion enough. There is a ton of history and valuable conversation around this topic already in the Community Group, and we’ve been working with a couple of browser reps trying to get this thing solved. We’ve even gone so far as to put the solution that seems to have the most legs together as a sort-of spec, so all the details are in one easily-parsed place: https://github.com/Wilto/respimg > > On Thu, May 10, 2012 at 3:58 AM, Edward O'Connor wrote: > >> Hi, >> >> When authors adapt their sites for high-resolution displays such as the >> iPhone's Retina display, they often need to be able to use different >> assets representing the same image. Doing this for content images in >> HTML is currently much more of a pain than it is in CSS (and it can be a >> pain in CSS). I think we can best address this problem for bitmap[1] >> content image by the addition of a srcset="" attribute to the existing >> element. >> >> The srcset="" attribute takes as its argument a simplified variant of >> the image-set() microsyntax[2]. It would look something like this: >> >> >srcset="foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x" >>alt="decent alt text for foo."> >> >> takes one or more comma separated image specifiers. An >> image specifier consists of a URL to an image asset and an associated >> scale factor, expressed as a number followed by the literal character >> 'x'. (The value of is treated as if it had a 1x scale >> specified, so you can avoid duplicate references to the base asset.) >> >> User Agents may make their asset selection before fetching any of the >> assets, thus avoiding multiple asset loads & the associated performance >> problems in constrained bandwidth environments. >> >> The intrinsic size of the can be computed by dividing the >> intrinsic size of the actual image asset chosen with that asset's >> associated scale factor. Suppose that foo-lowres.jpg is 100x100 and >> foo-highres.jpg is 200x200 in the above example. If the UA chooses >> foo-lowres.jpg, it computes the intrisnic size as (100/1)x(100/1) = >> 100x100. If the UA chooses foo-highres.jpg, it computes the intrisnic >> size as (200/2)x(200/2) = 100x100. >> >> A nice thing about this proposal is its backwards compatibility story. >> Browsers which don't yet support will simply use the asset >> referenced by . A polyfill could easily be written to check for >> & swap out a different asset into , much like >> existing libraries which check for data-fullsrc="" or the like. >> >> Why provide a scale factor and not a media query? Well, media queries >> are claims about UA state, whereas here we're asserting something about >> the relationship between the image assets. Also, User Agents should be >> free to use whichever asset they deem best suited to their current >> situation, taking into account not just "media-queriable things" like >> device resolution but also any scaling applied to the with CSS, >> its width="" and height="" attributes, or even things like the current >> page zoom level. >> >> Of course there are other things like bandwidth availability, data plan >> usage, etc. that web developers might want to take into account when >> choosing which image assets to load. This is definitely something worth >> exploring. In the future we could extend the asset descriptors to cover >> such cases. Something like this, maybe: >> >> >> >> I'm purposefully not making a proposal for how to describe bandwidth, >> data plan usage, or such things here. 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. >> >> One downside to this proposal is that the srcset="" attribute takes a >> microsyntax, and as a rule we try to avoid novel microsyntaxes in >> attribute values. I think this particular microsyntax is pretty >> straightforward and shouldn't cause all that much confusion for authors. >> >> I think this is preferable to adding a suite of attributes with complex >> inter-relationships, such as in Anselm Hannemann's proposal from last >> August[3]. In such a proposal, we would either need to have a pre- >> approved list of image scales (like Anselm's xs, s, m, l, xl), which >> over-constrains designers' ability to create, or we would be introducing >> user data into attribute names which—with the one exception of the >> data-*="" attributes—is something I really don't think we should do. >> >> Some have argued that we should "just use conneg" to serve the best >> image. This isn't an acceptable solutio
Re: [whatwg] for responsive bitmapped content images
On May 10, 2012, at 9:47 AM, Simon Pieters wrote:
> On Thu, 10 May 2012 15:24:28 +0200, Tab Atkins Jr.
> wrote:
>
>> This proposal has a similar issue to image-set() - if the 2x means
>> "twice the resolution" (which it should), this will *not work by
>> default*. If you make a 5 inch wide image and save it as 200dpi, when
>> you send it to the browser its automatic size will be 10 inches wide.
>> Browsers are constrained by back-compat to always display images at
>> 96dpi. You can get around this by explicitly setting , but
>> we shouldn't require that if we can avoid it.
>>
>> This isn't hard to fix, of course; the fix just isn't included right now.
>
> We should indeed fix it.
>
>> CSS3 Images has the image-resolution property, which lets you tell the
>> browser what resolution to display the image at (that is, how it
>> should determine the automatic size). You can say "image-resolution:
>> from-image;" to get it to use the image's native resolution, whatever
>> it is. So, we need to add a rule to the UA stylesheet that says
>> "img[srcset] { image-resolution: from-image; }".
>
> Do we want from-image here? Or do authors prefer to serve 96dpi images that
> are bigger, and specify the intended dpi in the markup?
>
>> In the closely-related case of using image-set() in CSS, we can just
>> have the "winning image" set the default resolution. An earlier
>> version of the image() function let you set an image's resolution
>> immediately, but we punted it for simplicity at level 3. This would
>> do the same thing.
>>
>> That all said, I don't like the "2x" notation. It's declaring "this
>> image's resolution is twice that of a normal image". This has two
>> problems. For one, we already have a unit that means that - the dppx
>> unit. Using "2dppx" is identical to the meaning of "2x". Since
>> image-set() is newer than the dppx unit, we should change it to use
>> instead.
>>
>> For two, I'm not sure that it's particularly obvious that when you say
>> "2x", you should make sure your image was saved as 196dpi. You have
>> to already know what the default resolution is. As well, I think that
>> values like 300dpi are pretty common, and they don't map to integral
>> 'x' values. If people say "screw it" and use "3x", this'll be
>> slightly wrong and I think will cause ugly blurring. If we make this
>> take , people can just use the dpi unit.
>
> Can we just use CSS's 'dpi' instead?
>
>
Hey guys. Don’t know if it’s too early to chime in with this, but we were told
by some members of the Chrome team that any browser that supports DNS
prefetching — including assets — wouldn’t consider “looking-ahead” on the img
tag as an option. The original src would be fetched in any case, saddling users
with a redundant download.
I’ve been living and breathing this topic in the Responsive Images Community
Group for months now, so I’m psyched to see the problem getting some attention!
>
>> I agree overall that this is the right approach - declaring relevant
>> information to the browser and letting it decide what to do is better
>> than trying to set up constraints by yourself. For example, using MQ
>> could result in the silly situation of downloading a high-res image at
>> first because you're on 4G, then throwing them away and downloading
>> low-res images when you drop to 2G. Using image-set() or @srcset
>> would let the browser keep the images it had already downloaded.
>
> Indeed.
>
> --
> Simon Pieters
> Opera Software
Re: [whatwg] RWD Heaven and responsive-images
>> >> The above is just a my proposal in advancing this discussion, and >> until there is no feedback about this from people on the "RWD Heaven: >> if browsers reported device capabilities in a request header" and the >> "add html-attribute for "responsive images"" threads, and other >> developers concerned in Responsive Web Design, I don't think I should >> just create the group and hope that the discussion will just move and >> concentrate there on its own. So open for feedback on this! >> >> Kind regards to all, >> Viktor I’m certainly not opposed to a more productive venue for hashing out some of these issues, but I still worry that we’re backtracking. We’ve already covered a lot of the same ground on this list as a large group of us did months ago ( https://etherpad.mozilla.org/responsive-assets is one of many venues in which this took place ). While I’m in no way railing against having a bunch of new eyes on this problem and new potential solutions, I’m afraid of going back and rehashing the same ideas for the sake of people just joining the conversation. By the time we reach a conclusion—possibly the same conclusion—and present it to the list again, who’s to say we wouldn’t find ourselves repeating the process all over again? Basically, I’d want to ensure that any discussion within the group takes place in a very public and easy-to-digest way, so we have an easy reference for people joining the conversation late in the game. I’d also love to see a representative from each of the big browsers and a couple of people close to the standards process directly involved, so we can stay as focused and productive as possible. I’m happy to reach out to people, to those ends. Any way you slice it, you’re right that this list isn’t the place for continued discussion of this sort. Viktor, if you’re willing to set up such a group, that’s probably a more appropriate venue—at least for the time being.
Re: [whatwg] add html-attribute for "responsive images"
On Feb 9, 2012, at 6:36 AM, Jordan Dobson wrote: > Tim, > > Very good suggestion. This would allow us to keep our markup clean and > stash these extra references elsewhere in the code as we see fit. > > +1 > > -- > Jordan Dobson • Designer / Developer • 425-444-8014 • JordanDobson.com > > On Thu, Feb 9, 2012 at 3:11 AM, Tim van Oostrom wrote: > >> I'm also late in this discussion but followed it globally. Maybe a >> structure like Microdata's itemref="" is an option too. >> >> You could do: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> This gives you the ability to share the sources with multiple img >> elements. For example when you have a placeholder image for devices that >> you do not support. >> Unfortunately we were informed early on that it was very unlikely we’d ever get a vendor to sign off on a pattern that involves “looking ahead” on an img tag. Modifying the behavior of img itself doesn’t sound viable. I worry that we’re all getting hung up on throwing ideas around—which is understandable for sure, and this is some great conversation. I think the bottom line is that we’re all in agreement on what’s needed, exact implementation aside: a markup-based means of delivering alternate image sources based on device capabilities, to prevent wasted bandwidth and optimize display on screen and in print. From an accessibility standpoint, it should at the very least equal img’s alt tag. For non-supporting browsers, fallback content should be displayed. If we all agree on these key points—and that there’s a clear need and an obvious benefit to the users—I should think we’re ready to carry this conversation forward and start ironing out the technical details elsewhere, alongside the vendors.
Re: [whatwg] add html-attribute for "responsive images"
On Feb 8, 2012, at 8:38 AM, David Goss wrote: > > > > > > > Becomes this: > > > > > > This feels a bit convoluted to me, to be honest—the addition of the non-semantic, non-display gives me the creeps. It also leave us with two different markup patterns that serve the same goal, though not radically different by any means. Don’t get me wrong: I’d be okay with this pattern—hell, I’m receptive to any potential solution. I just feel there’s something to be said for keeping the element consistent and self-contained.
Re: [whatwg] add html-attribute for "responsive images"
On Tuesday, Feb 7, 2012, at 7:35 AM, David Goss wrote: > On 7 February 2012 11:31:15 +0100, Anselm Hannemann wrote: > > Am 07.02.2012 um 11:16 schrieb Matthew Wilcox: > > To me this makes most sense /from an author perspective/ (I make no claims > > as to how practical this really is): > > > > > >> media="min-width:320" /> > >> media="min-width:480" /> > >> media="min-width:640" /> > > > > > > > > > > > > The reason being: > > > > * it's easy to read > > * it uses familiar element structures and properties > > * it allows us to adjust to any given media requirement, not just screen > > size (you could query bandwidth with this > syntax, though I contest > > bandwidth is the domain of server side adaption rather than client side) > > This is a good solution except the fallback img element would be twice loaded > in your case which is not good. > There should be the img element containing the standard (normal) size and src > elements to add diff. other resolutions. With that the browser won't load the > resource twice. > > Would it? I think Matthew's example implies that a supporting browser > *wouldn't* load the src from the unless none of the s got a > media match. Right? I’m not sure how it’s intended to work with currently, but I believe the fallback is only loaded if is unsupported—if none of the sources match, I believe nothing is displayed. I may be wrong, but that seems to be the most predictable behavior. > > The way I proposed it would have the same behaviour but have the as the > first child element of , making it more apparent that it's the > default content as well as the fallback content. Also, it would contain > important attributes like alt. So: > > > >media="min-width:320" /> >media="min-width:480" /> >media="min-width:640" /> > > > And: > > - unsupporting browsers would get default.jpg (but the author could implement > some JS to run the media queries and swap in the most appropriate > image if desired) > - supporting browsers narrower than 320px would also get default.jpg, because > none of the s would get a media match > - supporting browsers 320px or wider would get the image from the last > to get a media match (because a 800px wide screen would match all 3 > in this example) > > I'm not really sure whether should get an alt attribute - my > thinking is that if one alt attribute doesn't correctly describe all the > s then perhaps they are different content. Matthew's example does > make sense, in that the extra alt attributes describe the way the image has > been cropped (although it's still the same image). But maybe it would be > better to only allow alt on the to reinforce the idea that all the > s should basically be the same image albeit > cropped/monochrome/whatever. I’m with you, here. I’m hesitant to have any logic hinge on the fallback img, though, as it wouldn’t be strictly required—the fallback content could be, say, descriptive text instead (Granted I wouldn’t do it, but just trying to keep things as flexible as possible). I do think all sources should be described by a single alt tag, though, possibly on itself? > > FWIW, whatever becomes of the discussion about sending media-query-like data > in headers to the server (RWD Heaven: if browsers reported device > capabilities in a request header), we need this responsive image markup > regardless. Hear hear! > > Thanks > > David
Re: [whatwg] add html-attribute for "responsive images" Mathew Marquis
> I think we need to decide whether markup-based solution is a workaround > forced on us because there was no good solution or whether it is a solution > we should pursue, if implemented properly. To your first point: I figure we do have solutions already, even if they’re not spectacular. A completely JS-based approach is perfectly viable, if a bit wasteful on larger screens; we have one in place on BostonGlobe.com right now. I wouldn't say this is a gut reaction from a handful of developers backed into a corner, by any means. Really, it follows the same logic that seems to have gone into the "media" aspect of ’s sources: if we can prevent wasteful requests in a way that predictably falls back for older browsers, why shouldn’t we? Where the source logic would only be limited by MQ it would allow us to, say, serve high-res images to higher DPI screens without incurring any cost to lower DPI screens, without requiring UA detection or server-side logic. On the other hand: if one were to want to automate the cropping process, the various sources could be generated by server-side logic and output to the page. > And this brings us to a very technical discussion about RESTfulness of either > approaches (server-side negotiation vs. markup-based descriptors). > > -- Pros of server-side negotiation: > > If you look at an image as a unique resource, then representing it with a > unique URL and adjusting diff crops or resolutions of the image for > device-targeting based on HTTP headers is very much like using unique > resource URL and altering output format based on accept headers, which is the > RESTful and recommended approach. > > I can see an argument that diff crops of the same image are not the same > resource, but esp. in the context of targeting diff. devices, I think that's > not true. If XML and JSON versions of a document are the same resource, then > device-specific versions of an image should be as well. > > Good food for thought, however. > > Thanks, > > Irakli >
Re: [whatwg] add html-attribute for "responsive images"
> > Am 25.01.2012 16:39 schrieb Matthew Wilcox: > > > >> It's also worth noting another use case for this being in mark-up and not > >> just server-negotiated rescaling of a single image: > >> > >> Imagine a profile photo on an About page. At large sizes you want to use a > >> full body shot, at smaller sizes you need to retain what's important but > >> no > >> longer clear at small scales: a recognisable face - so you substiture a > >> head and shoulders shot. > >> > >> That's a strong use case where the semantic meaning of the content is the > >> same but requires a different resource to be properly conveyed at > >> differing > >> scales. > >> > > > > This use case shows some kind of consistency issue: The printed version of > > a page might match a different media query, and thus use a different image. > > If the images have different contents, this can result in a confusing user > > experience. > > > > In order to work around this, UAs might want to keep the first image > > loaded, when the content is used for a different type of media, such as > > print or PDF output. (That could also be the case for changes of window > > size.) > > > > I think Matthew has it about right with the about page example. I think as > long as the user can recognise that it's the same image (albeit > cropped/zoomed in some way to adapt to the media) then we're okay. I’m late to the conversation! It looks like a bunch of us have been thinking in parallel with some of the folks in this thread--we've reached many of the same conclusions you guys have, and ended up with pseudo-markup nearly identical to yours—albeit under the working name . Our brainstorming (be warned, some of it ain’t pretty) can be found here: https://etherpad.mozilla.org/responsive-assets I recently published a sum-up of our thinking at A List Apart ( http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/ )—in short, using the markup pattern as the inspiration, with the use of media attributes on the elements to determine the rendered source, and the inclusion of an --ideally a smaller image, to account for the lowest-common-denominator--as a fallback similar to the way Flash or an image might be used as a fallback. I'd love to start this conversation up again, so we can talk through any potential issues!
