Problem using new immutable API with Slab-based DOM tree

[nicoburns]

I am using a slab::Slab to store nodes for my DOM implementation. The new immutable API in html5ever 0.28 has required me to wrap my node tree in a RefCell so that I can mutate it from html5ever's trait methods. However, html5ever's ExpandedName<'a> type also requires me to return a (plain) reference into my tree, which is not possible if my tree is wrapped in a RefCell.

I believe the best fix for this (assuming that the new interior mutability-based API is indeed necessary - it seems awkward!) is to make ExpandedName an associated type on the TreeSink trait which implements AsRef<ExpandedName> or alternatively has methods to access the fields of ExpandedName individually. This would allow implementers of TreeSink to choose one of the following strategies:

• Use the existing ExpandedName type if their tree supports it.
• Use a variant of ExpandedName that uses a RefCell Ref (or MutexGuard, etc)
• Return cloned/owned names

I would be happy to put up a PR for this if this seems like a reasonable solution. I have not yet completed my migration, so I am unsure if I will run into further problems. I have now migrated the rest of the code. This seems to be the only thing I couldn't solve with a RefCell.

[jdm]

I ran into the same problem with example code when updating to the new API. I ended up using Box::leak and was not thrilled about it.

[jdm]

https://github.com/servo/html5ever/blob/main/html5ever/examples/print-tree-actions.rs#L83

[jdm]

I like the sound of your proposal!