- From: Timothy Hatcher <timothy@apple.com>
- Date: Mon, 18 Nov 2013 18:05:32 -0800
- To: Kornel Lesiński <kornel@geekhood.net>
- Cc: WHATWG <whatwg@lists.whatwg.org>
> On Nov 18, 2013, at 5:55 PM, Kornel Lesiński <kornel@geekhood.net> wrote: > > On Tue, 19 Nov 2013 01:12:12 -0000, Tab Atkins Jr. <jackalmage@gmail.com> > wrote: > >>> AFAIK it makes it as easy to implement and as safe to use as src-N. >>> >>> Simon, who initially raised concerns about use of <source> in <picture> >>> found that solution acceptable[2]. >>> >>> I'd love to hear feedback about simplified, atomic <source> from other >>> vendors. >> >> The cost there is that <picture><source> is now treated substantially >> differently than <video><source>, despite sharing a name. > > The substantial difference is that it lacks JS API exposing network/buffering state, but IHMO that's not a big loss, as those concepts are not as needed for pictures. > > IMHO the important thing is that on the surface (syntactical level) they're the same - multiple <source> elements where the first one matches. > >> Otherwise, though, I'm fine with this as well. The only innovation >> that src-N offers over <picture> is the variable-width images syntax, >> and that can be baked into <source src> as well. > > That was exactly my thought. Combination of src-N features with less contentious syntax would be ideal. > > <source> can support number of attributes, so if there are objections to some features or parts of src-N syntax, it can be split into multiple attributes on <source> to be introduced gradually later/as needed (e.g. <source media>, <source sizes>, <source 3d-google-glass-hologram-set>, etc.) without risking explosive complexity of combined microsyntaxes. > > -- > regards, Kornel I agree. <picture> and <source> better match the spirit of HTML. Where multiple numbered attributes is just a kludge. — Timothy Hatcher
Received on Tuesday, 19 November 2013 02:05:58 UTC