Re: The picture element: complexity

Hi Simon,

while I totally understand <picture> with its source elements is complex to implement and needs more tests than a simple attribute I wonder what you would propose as alternative to e.g. media-query usage within source elements. This is needed to solve the art direction use-case (http://usecases.responsiveimages.org/#art-direction) amongst others (like high-contrast or print – compare: http://usecases.responsiveimages.org/#matching-media-features-and-media-types).
If you have an idea how this could be solved using an easier to implement syntax, I would be happy to help doing this. Simply I believe (and know for certain) the srcset attribute alone is not enough to solve the 'Responsive Images' problem entirely.

Hope we can solve all outstanding issues with responsive images soon and I'm happy to discuss possible solutions with you.

-Anselm Hannemann | @helloanselm | info@anselm-hannemann.com


> W3C home > Mailing lists > Public > public-html@w3.org > September 2013
> 
> The picture element: complexity
> 
> This message: [ Message body ] [ Respond ] [ More options ]
> Related messages: [ Previous message ]
> From: Simon Pieters <simonp@opera.com> 
> Date: Thu, 12 Sep 2013 12:19:24 +0200
> To: HTMLwg <public-html@w3.org> 
> Message-ID: <op.w3amymniidj3kv@simons-macbook-pro.local> 
> The design using multiple elements makes the implementation much more
> complex compared to a design using a single element. I've mentioned this
> before [1].
> 
> <source> for <video> and <audio> is also too complex. My experience with
> quality assurance for <video> at Opera suggests that <source> is a mistake
> that we should not repeat. There are too many edge cases. If I had
> realized this before it shipped in browsers I would have argued that
> <video> be changed to not use <source> elements, but now we're stuck with
> it.
> 
> The argument against this I usually get is that the Priority of
> Constituencies design principle says that the needs of authors should win
> over the needs of implementors. However, this design principle needs to be
> considered together with the rest of the design principles, in particular
> in this case Avoid Needless Complexity [2]. In the case of resource
> selection using one element vs. using multiple elements, I would argue
> that the latter is about an order of magnitude more complex in the
> implementation and the needed tests because it enables more edge cases
> that simply cannot happen when you only have one element.
> 
> To illustrate my point, I have submitted some of the tests I've written
> for media elements' resource selection algorithm which test for a few of
> these edge cases.
> 
> http://w3c-test.org/web-platform-tests/submissions/326/html/semantics/embedded-content-0/media-elements/loading-the-media-resource/
> 
> (If you have comments on the tests, please use
> https://critic.hoppipolla.co.uk/r/307 , thanks!)
> 
> So for instance a test like
> http://w3c-test.org/web-platform-tests/submissions/326/html/semantics/embedded-content-0/media-elements/loading-the-media-resource/031.html
> wouldn't be a possible case to test if it was a single element.
> 
> With this in mind, my recommendation is to make it a requirement for the
> solution to responsive images to use a single element, <img>. You can use
> a single attribute or multiple attributes to address the various use
> cases, that doesn't make a significant difference to the complexity.
> 
> [1]
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/035784.html
> 
> [2] http://www.w3.org/TR/html-design-principles/#avoid-needless-complexity
> 
> Simon Pieters
> Opera Software
> 
> Received on Thursday, 12 September 2013 10:19:54 UTC
> This message: [ Message body ]
> Previous message: Cyril Concolato: "Re: Updating sourcing in-band text track for MP4 files"
> Mail actions: [ respond to this message ] [ mail a new topic ]
> Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]
> Help: [ How to use the archives ] [ Search in the archives ]
> This archive was generated by hypermail 2.3.1 : Thursday, 12 September 2013 10:19:55 UTC