On Thu, Nov 21, 2013 at 3:53 AM, Kornel Lesiński <[email protected]>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.
