On Tue, Nov 15, 2016, at 04:03 AM, Simon Sapin wrote:
> On 11/11/16 12:22, Manish Goregaokar wrote:
> > Servo currently has a style tree (stylesheets->rulelist->rules->other
> > rules and rule lists) in style::Stylesheet[1], and this is shared with
> > the DOM via Arcs. As I understand it, Gecko, on the other hand, just
> > uses the CSSOM DOM tree and has no "style tree" otherwise. Reading
> > rules in Gecko requires traversing through CSSOM objects. This is a
> > straightforward solution to the same-object restriction; if your style
> > tree is made up of these objects in the first place there's nothing to
> > worry about.
> >
> > Servo can't use this solution. Trying to thread style through the DOM
> > will mean merging the style and script crates, and it will be quite
> > complicated to make Servo's style system generic over CSSOM
> > implementations for stylo to work.
> 
> I’ve proposed this approach before, and I don’t think it would be that 
> complicated. The only parts of components/style that access this tree 
> (other than the parsing part creating it) is Stylist::update and 
> Stylist::set_device taking &[Arc<Stylesheet>] and traversing the tree.
> 
> I’m sure we can reasonably define a trait to abstract this traversal. 
> The "leaves" of this tree (selector list, declaration block, …) would 
> stay in style crate, but the tree structure and the ownership/mutability 
> story doesn’t need to be handled there.

I suppose that means Gecko would maintain the tree directly as well for
stylo, rather than creating a parallel DOM tree on demand like what I'm
currently doing.

I guess it is probably doable, but that means parsing and traversing the
tree would involve lots of additional FFI calls to build and access the
tree in Gecko side. Not sure whether that is something we want.

> Bobby argued that we should keep that tree in the style crate because it 
> can implement some operations that won’t have to be re-implemented in 
> both Servo and Gecko/Stylo.
> 
> But I don’t know if there is much to share anyway, and the alternative 
> (maintaining parallel trees) also has its complexity.

There are some, like serialization. It doesn't sound like a good idea to
have a serialization algorithm involves both Gecko code and Servo code.

- Xidorn
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Reply via email to