On 25/02/14 11:42, David Bruant wrote:
Hi,
If I may weigh in, I wonder if passing Acid3 is a valuable goal in the
short term.
IE8 scores 20/100 at Acid3. All major websites and most websites have to
support IE8, because it's the current "boat-anchor browser" [1]. So most
websites don't need the features that make a 100 score.
Specifically, SVG might be a big piece and since IE8 doesn't support it,
usage is still very rare in websites.
Aiming at IE8 parity (... or rather the intersection of IE8 and current
standards, obviously) feels like a more practical goal if you want to
support the web as it is today. An incomplete list of relevant features
to get to IE8 parity [2].
Said differently, aiming at IE8 parity can only yield a much much better
supported-website-count/effort ratio than passing Acid3.
I think I agree that passing Acid 3 in the next four months is not going
to happen. But that's more because it requires a whole set of
technologies that we don't have an implementation of in Servo (SVG, DOM
Range+traversal, etc.) and which don't obviously seem like high
priorities compared to getting the fundamental architecture right.
I also think that the acid tests in general and acid 3 in particular are
rather flawed tests; they make great PR pieces and that's a good reason
to target them, but the actual things that they test are a grab-bag of
random features and implementation bugs from the time they were written.
Having said that, I don't think that using "IE8 parity" as a metric is
very useful. IE8 takes a lot of non-standard codepaths on real sites, so
merely targeting the standard features it implements is not going to
give you an end result that is actually compatible with all the sites
that work with IE8 (for example, I believe that IE8 still has the old
attachEvent junk rather than the standard addEventListener API, so by a
literal reading of the above you wouldn't implement events at all).
I think a better way to proceed is to try to implement the parts that
change the underlying architecture as early as possible (so, on the DOM
side, this would be HTML parsing, page loading, script scheduling,
history navigation, etc.) and as a minimum target as-good-as-gecko (or
webkit or blink, or whatever) scores on the relevant web-platform-tests
for those features (in practice we want to aim for 100% of course, but
as long as we at least pass the tests that everyone else passes the
compat. story should be OK). Once this is done we survey web content to
see which higher-level features are most used and implement those in
priority order using the same approach.
My method isn't likely to produce the best short-term gains, but I think
it's the best route to compatibility with real sites in the long term.
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
