The road to Acid2

[Patrick Walton]

Hi everyone,

Now that we've essentially passed Acid1 (once one remaining pull request
is merged), Acid2 is on the horizon! I've identified the issues that
were immediately apparent between us and Acid2 and created a wiki page
and a milestone to track our progress:

https://github.com/mozilla/servo/wiki/Acid-test-features

https://github.com/mozilla/servo/issues?milestone=4&state=open

Please feel free to add to these lists.

Many of these issues will be fixed by Simon's "newnewcss"
infrastructure, which involves moving away from `rust-css` and the
NetSurf CSS library to a pure Rust implementation. Other than that, the
largest tasks will be implementing tables, followed by `position:
absolute` and `position: fixed`. There are several other, smaller tasks
which are cleanly separable and would be great for contributors if
anyone is interested: negative margins, negative clearance, transparent
PNGs, data URLs, negative heights, and the `:hover` selector come to mind.

As always, feel free to hop by `#servo` on irc.mozilla.org with any
questions. Thanks!

Patrick

[Brian Anderson]

On 08/26/2013 04:17 PM, Patrick Walton wrote:
> Hi everyone,
>
> Now that we've essentially passed Acid1 (once one remaining pull
> request is merged), Acid2 is on the horizon! I've identified the
> issues that were immediately apparent between us and Acid2 and created
> a wiki page and a milestone to track our progress:

Awesome! It looks so tantalizingly close.

[L. David Baron]

On Monday 2013-08-26 16:17 -0700, Patrick Walton wrote:
> Other than that,
> the largest tasks will be implementing tables, followed by
> `position: absolute` and `position: fixed`. There are several other,
> smaller tasks which are cleanly separable and would be great for
> contributors if anyone is interested: negative margins, negative
> clearance, transparent PNGs, data URLs, negative heights, and the
> `:hover` selector come to mind.

Is it worth prioritizing having working incremental layout so that
you can benchmark the architecture for doing incremental updates
(and make sure it performs acceptably) over these tasks that you
list? (As somebody following from a distance, I'm more concerned
about that, because it seems likely to be the sort of thing that
might require changes in architecture and thus rewriting code that
would implement the above.)

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

[Patrick Walton]

On 8/26/13 9:11 PM, L. David Baron wrote:
> Is it worth prioritizing having working incremental layout so that
> you can benchmark the architecture for doing incremental updates
> (and make sure it performs acceptably) over these tasks that you
> list? (As somebody following from a distance, I'm more concerned
> about that, because it seems likely to be the sort of thing that
> might require changes in architecture and thus rewriting code that
> would implement the above.)

We have a plan for incremental layout which is partially implemented
already. Right now, I believe what is implemented is that changes that
require only repaints do not reflow, and there is some initial work on
style struct diffing and dirty bit propagation. Also intrinsic width
bubbling is skipped if it is not needed. DLBI is underway but needs the
flow tree construction to be rewritten to be useful.

It definitely makes sense to get incremental layout (and perhaps bidi)
working before redoing too much code that would have to be rewritten. At
this point I think that the "visitor + kernel function" pattern will
work with incremental reflow, so any changes that can fit into this
framework are likely to be incremental-safe. This includes stuff like
margin collapsing, negative margins, and negative heights. Also, areas
that are pure CSS parsing strike me as fine to work on.

Areas where we will have to be careful to make incremental-safe are
tables, absolute positioning, and fixed positioning. I think some of
that stuff should wait on the flow tree construction phase to be
rewritten to be incremental. I would advise against making sweeping
changes to flow tree construction in the current framework; better to
just push on the flow tree construction rewrite to be bottom-up,
parallelizable, and to propagate dirty bits efficiently (i.e. be
incremental). However, as I said I think constraint solving changes,
especially if they're just to kernel functions, are fine.

Patrick

[Simon Sapin]

Le 27/08/2013 05:23, Patrick Walton a écrit :
> It definitely makes sense to get incremental layout (and perhaps bidi)
> working before redoing too much code that would have to be rewritten.

Maybe also writing modes / vertical text?

Even if the actual feature is not a priority, it might be easier to
rewrite the layout code to use logical keywords (eg. measure/extent
instead of width/height) while we don’t have much layout code.

http://dev.w3.org/csswg/css-writing-modes/
http://dev.w3.org/csswg/css-writing-modes/#abstract-box

--
Simon Sapin

[Patrick Walton]

On 8/27/13 1:48 AM, Simon Sapin wrote:
> Maybe also writing modes / vertical text?
>
> Even if the actual feature is not a priority, it might be easier to
> rewrite the layout code to use logical keywords (eg. measure/extent
> instead of width/height) while we don’t have much layout code.
>
> http://dev.w3.org/csswg/css-writing-modes/
> http://dev.w3.org/csswg/css-writing-modes/#abstract-box
>

Agreed. I actually filed a bug for this yesterday:

https://github.com/mozilla/servo/issues/799

Patrick