[whatwg] Features for responsive Web design

[Nils Dagsson Moskopp]

Ian Hickson <ian at 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>