On Tue, 19 Nov 2013 01:12:12 -0000, Tab Atkins Jr. <[email protected]>
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
