On Tue, Jan 28, 2014 at 3:17 PM, Yoav Weiss <yo...@yoav.ws> wrote:
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.
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.
* 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?
We have some simplified CSS parsers for some performance critical code paths. I'm not sure how much of the CSS language this simplified parser would need to parse. If you need to parse constructs like calc(), you'll pretty much need a full lexer...
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.
That seems valuable. We'd also like to be able to do some simple CSS selector matching during preloading, for example to preload background-images for elements that match a class selector. It's like we could make that work if we had a threadsafe lexer.
Does any of this make sense? Am I missing any important roadblocks? Does this sound like a viable implementation plan?
That basically sounds like a viable plan. There are some details to work out regarding the compatibility impact and whether we'll want to have two CSS lexers.
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.