- From: Kornel Lesiński <kornel@geekhood.net>
- Date: Tue, 19 Nov 2013 01:55:59 -0000
- To: WHATWG <whatwg@lists.whatwg.org>
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
Received on Tuesday, 19 November 2013 01:56:31 UTC