- From: Yoav Weiss <yoav@yoav.ws>
- Date: Thu, 21 Nov 2013 09:38:15 +0100
- To: Kornel Lesiński <kornel@geekhood.net>
- Cc: whatwg <whatwg@whatwg.org>, Simon Pieters <simonp@opera.com>
On Thu, Nov 21, 2013 at 3:53 AM, Kornel Lesiński <kornel@geekhood.net>wrote: > > An <img> element will be de-facto required for a while as a fallback, but > could it be optional eventually? I think that even if browsers implement > <picture> using <img>, the <img> element itself should be hidden in shadow > DOM. > That would eliminate the need of authors to explicitly specify an <img>, but it'd create 2 <img> children if they did (which would be needed for fallback for a long while). > If we don't explicitly define <picture> as wrapper for <img> then yes, > we'll need separate test cases for <picture>, but: > > - hopefully plenty of cases can be adapted with little more than > find'n'replace <img src=" with <picture><source src=" > - We don't need to bring all the legacy baggage of <img>, so a bunch of > tests for Netscape'isms can be deleted. > - Image element has weird stuff like .complete property that can change > synchronously. Kill it! With clean slate we can define only minimal, > quirk-free API that is much easier to deal with. > - Test cases is something that can be shared between browser vendors, and > the community can help adapt <img> test cases to <picture>, so we can > spread the effort. > > Since support for <img> cannot be dropped in the near future (or the far one, for that matter), that would create a lot of test duplication, which is a significant cost. Test cost is not only writing them initially (which as you say, can be a joint effort), but also their maintenance and run-time. Letting <img> do all the heavy lifting resolves this issue, without any major downsides. Starting fresh is always cleaner, but the cost is rather high.
Received on Thursday, 21 November 2013 08:38:41 UTC