- From: Simon Pieters <simonp@opera.com>
- Date: Fri, 18 Oct 2013 00:32:48 +0200
- To: "Yoav Weiss" <yoav@yoav.ws>, "Marcos Caceres" <w3c@marcosc.com>, Kornel Lesiński <kornel@geekhood.net>
- Cc: "Anselm Hannemann" <info@anselm-hannemann.com>, public-respimg@w3.org
On Thu, 17 Oct 2013 18:45:06 +0200, Kornel Lesiński <kornel@geekhood.net> wrote: > Why is testing of an element require more tests than testing a set of > attributes? Is that just due to a policy? > > In my experience amount of tests is correlated to number of features and > their edge cases and AFAIK srcN and picture have similar feature set. In > both cases you'll need to test different combination of sources, media > queries, mutations, browser states, etc. > > On one hand you'll have bunch of DOM traversal tests, on the other bunch > of > parser edge cases. Overall seems to be the same league to me. Assuming an algorithm that is equivalent to srcN but with elements, as opposed to the current <picture> spec that uses steps from <video>'s media source selection algorithm, I agree that testing of the algorithm itself is in the same ballpark. The fact that <picture> can be in an incomplete state during parsing means it needs more tests, but not by a huge amount. However, I think a bigger problem is the duplication of things that aren't the selection algorithm. Fallback would need to be reimplemented and retested, not only in the browser but also in ATs. Given the track record of <object>, it's not unlikely that a new element would suffer from poor behavior or poor interop for the fallback case in browsers or ATs, or both, for quite some time. <img>'s fallback is well supported and well tested, and srcset/src-N gets a free ride. Similarly for crossorigin, usemap, ismap, width, height, .naturalWidth, .naturalHeight, .complete, painting on a canvas, interaction with CSS stuff like object-fit, UI features like the context menu, and so on. -- Simon Pieters Opera Software
Received on Thursday, 17 October 2013 22:33:24 UTC