Following Adam Barth's reply on the WHATWG list, I'd like to discuss implementation options for the picture element. I'm not yet certain that I'd be able to commit to implementing it, but I'd like to get a sense of what needs to be done. Once I'd know I can commit to it, I'll send a proper "Intent to implement".Since the biggest hurdle to full implementation is off-main-thread CSS parsing, the first phase is likely to exclude the syntax parts that rely on media queries.What would be the ideal fallback options for syntax that does include MQs? Will the fallback img@src be fetched and presented instead? (That seems like the simplest way to tackle this)If I understand correctly, the first phase implementation requires the following:* Avoid preloading of img@src & img@srcset resources when the img tag is inside an unclosed picture tag. Perform preloading that simulates picture's source selection algorithm in this case.* Avoid immediate resource loading when img@src is parsed, and verify that the parent is not picture first. That will require insertion to the DOM before the resource can be loaded (if it wasn't already preloaded). If the parent is picture, proceed with picture's source selection algorithm.
* Implement the sizes attribute on both img and source (when it's under picture), but support only parsing of a single value (no breakpoints are allowed)* Implement parsing of picture's extended srcset syntax, and base resource selection on it when sizes is present.Regarding the second phase, implementing it requires off-main-thread MQ evaluation and (preferably) calc() evaluation. One way to achieve that is to wait long enough until CSSValue is overhauled, as part of the Oilpan effort. Adam has estimated the timeframe for this to happen in over a year, possibly two.Since this is a pretty long wait, I've been thinking of implementing a simpler CSS parser (possibly relying on Eric Seidel's tokenizer CL), that can focus on MQ evaluation and possibly calc().Will such a "duplicate" parser be acceptable?
It can also be the initial step towards implementing a CSS parser that would eventually replace Bison. As a side effect of such a parser, it'd enable the preloadScanner to evaluate link@media internally, without joining the main thread, and enable hooking the preloadScanner directly to the networking thread without losing the savings that this evaluation provides.
Does any of this make sense? Am I missing any important roadblocks? Does this sound like a viable implementation plan?
On Tue, Jan 28, 2014 at 3:17 PM, Yoav Weiss <yo...@yoav.ws> wrote:
* Avoid immediate resource loading when img@src is parsed, and verify that the parent is not picture first. That will require insertion to the DOM before the resource can be loaded (if it wasn't already preloaded). If the parent is picture, proceed with picture's source selection algorithm.
Waiting to load <img> elements until they are inserted into the DOM isn't likely to be compatible with the web because many web sites that img elements created outside the DOM will start their network loads before being inserted in the DOM. In fact, some web sites won't event insert the img elements into the DOM until their load event fires. That's actually good for the user experience because that means the image will always appear in the next frame.
On 29 January 2014 00:49, Adam Barth <aba...@chromium.org> wrote:On Tue, Jan 28, 2014 at 3:17 PM, Yoav Weiss <yo...@yoav.ws> wrote:
* Avoid immediate resource loading when img@src is parsed, and verify that the parent is not picture first. That will require insertion to the DOM before the resource can be loaded (if it wasn't already preloaded). If the parent is picture, proceed with picture's source selection algorithm.
Waiting to load <img> elements until they are inserted into the DOM isn't likely to be compatible with the web because many web sites that img elements created outside the DOM will start their network loads before being inserted in the DOM. In fact, some web sites won't event insert the img elements into the DOM until their load event fires. That's actually good for the user experience because that means the image will always appear in the next frame.Yes, a common pattern in JS is: img = new Image(); img.onload = foo; img.src = url;
Perhaps a compromise would work: when src is set on a image, post a task to the message loop that will start loading the src attribute, unless in the meantime it has been added to the DOM as a child of a picture element. We'd need to check that this doesn't regress performance too much.
I took a slightly different approach in a local branch, basically "marking" the element when an attribute is set by JS, thus enable img@src resource loading only when the attribute was set that way.I'm not certain my approach is valid (e.g. each attribute set by JS now has to set this boolean, which is not ideal), but it seems to work. I've now uploaded it, and am running perf tests, to see its implications.
--
Simon Pieters
Opera Software
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
I agree that the "what to implement" parts should be specified. IMO we should spec:
* JS based 'src' setting should trigger an immediate download, before the element is added to the DOM* Parser based 'src' setting shouldn't trigger an immediate download. The full selection algorithm should be triggered once HTMLImageElement is added to the DOM.
Adam
I wonder if we can also make incremental progress by shipping the img@srcset implementation we already have in the tree. It seems like that's a subset of the full proposal that might make sense to ship in parallel with working on the rest of the feature.
Hi Yoav,
I just wanted to know what the current status of <picture> is, and if
there's any way I can help with the implementation/shipping of this
feature. Let me know!