Upcoming changes to oxvg

[noahbald]

I've been doing a fairly large refactor with OXVG to improve it's performance and APIs, however it'll come with some breaking changes that I'd like to figure out with your project before I release it. The main issue being that there will no longer be a Node and Element trait -- with these being replaced by types instead.
The reasoning behind this change is included in this pull request (noahbald/oxvg#176).

I'm happy to do the work to get things compatible with parcel-html, and I'm thinking we could do one of the following

• Replace the traits in oxvg.rs with functions to translate between crate::arena::Node and oxvg_ast::node::Node
  • Simplest approach to start with
  • Keep control of crate::arena::Node with Parcel
  • Performance cost of translation
• Replace crate::arena::Nodewith oxvg_ast::node::Node
  • Would need to wait for oxvg_ast to include html parsing
  • Lose control of crate::arena::Node with Parcel
  • Simplify optimize.rs method by matching against attribute value types rather than attribute names

Look forward to hearing your thoughts -- I really appreciate you choosing to use oxvg as a dependency!
You can also join the discord or email me depending on your comm preference.

[devongovett]

The fun part: parse; dont validate. Previously, treating names and values as strings we can only derive information through expensive operations like querying data from HashMap, regex, parsers, etc, which is wasted time.
Now that we do all parsing upfront, with Element, Attr, etc; the structure, data, and validity of these types are known ahead of time.

Nice work. This has been a key part of lightningcss's performance as well.

I think ideally HTML would be parsed similarly as well, but that would be a significant amount of work. Are the Node/Attribute types extensible? What happens to unknown nodes/attributes? If those are represented with some less optimal but generic structure perhaps that could work for HTML for now. The HTML optimization pass is really simple (e.g. removing whitespace) and happens in a single pass so I'm not too worried about performance. Happy to go with a translation layer as well. What do you think is easiest?

[noahbald]

I think ideally HTML would be parsed similarly as well

I think we can progressively add HTML types as needed, we don't necessarily need to add the entire spec in one go.

Are the Node/Attribute types extensible?

They're not extensible like they were as traits. I suppose one could add wrapper types if needed.

What happens to unknown nodes/attributes?

Unknown attributes and elements are represented with a more generic structure.

Happy to go with a translation layer as well. What do you think is easiest?

Probably a translation layer is easier regarding development effort for both of us. I think that's a good approach to start with and we can look into a more extensive method some time in the future.