- From: Nils Dagsson Moskopp <nils@dieweltistgarnichtso.net>
- Date: Wed, 5 Sep 2012 18:09:40 +0200
- To: Ian Hickson <ian@hixie.ch>
- Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>
Ian Hickson <ian@hixie.ch> schrieb am Tue, 4 Sep 2012 19:47:38 +0000 (UTC): (regarding <picture>) > I don't understand why it's more intuitive and easier. It seems way > more unwieldly. Personally, I consider <picture> with <source> to be very similar to using ATOM <enclosure>s in podcasting. The relation – there are several sub-resources that represent (more or less) one logical resource – directly maps to a container element with other elements in it. Having <source> elements would also allow to support future image formats while still having a fallback via content-type. […] > Manipulating <picture> from script would be a huge pain -- you'd have > to be manipulating lots of elements and attributes. Well, is manipulating <audio> or <video> from script a huge pain? I actually have one use case that would benefit from having separate elements instead of an attribute – replacing <source> elements with links to their content for accessability purposes. I did something like this when I hacked elinks to (badly) support HTML5 media elements <http://blog.dieweltistgarnichtso.net/html5-media-elements-in-elinks>. Consider that any attribute microsynthax would introduce a burden on programmatic DOM manipulation, as the attribute would have to be parsed separately. „Do X for every <source> child element“ is cognitively cheap in comparison to maintaining a mental model of the attribute in question – different from other mental models used in HTML – in your working memory. 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). > > Anyway, with your proposal, would this be valid, to address the > > bandwidth-only use case?: > > > > <img src="normal.jpg" alt="" srcset="high.jpg 2x, normal.jpg 1x"> > > > > […] > > Would also like to see if there's a way of using srcset to hint to > > the UA that it can skip the image under low throughput conditions > > e.g. GPRS. Same would apply to image-set in CSS This reminds me that ATOM <enclosures> 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. > […] > > On Wed, 8 Aug 2012, Florian Rivoal wrote: > > > > 1) Your syntax (almost, see point 2) replicates the behavior of > > max-width and and max-height Media Queries, but doesn't give access > > to other existing and future media queries, some of which may > > actually be useful. For example: > > > > 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> > > b) Microsoft is proposing a MQ which lets you detect that the UA > > has been put in hight contrast mode (for accessibility reasons), > > and that your content should follow along. Wouldn't it be better if content would be high-contrast always? Making things optional may lead to fragmentation, consider media container formats where streaming is optional and Ogg. Having a slight contrast problem myself, I can attest to the fact that my eyes do not have support for media queries. Gray-on-grey text and graphics need to die. […] > > 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 <p> a common case) verbosity is helpful for both learning and readability. > 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? -- Nils Dagsson Moskopp // erlehmann <http://dieweltistgarnichtso.net>
Received on Wednesday, 5 September 2012 16:11:23 UTC