Compiling selectors with cssparser::Parser

[twilco]

Hi there!

I'm using Kuchiki to write a toy browser engine. I need to implement the cssparser::QualifiedRuleParser trait to parse CSS stylesheets into kuchiki::Selectors and declarations belonging to those selectors (e.g. margin: auto), similar to what Servo does here.

However, the KuchikiParser is private, so I can't pass it as the first argument to selectors::parser::SelectorList::parse.

There is kuchiki::Selectors::compile(&str), but I don't have a &str in parse_prelude and parse_block. Instead, I have a cssparser::Parser, which can go right into the second argument of selectors::parser::SelectorList::parse.

---

My issue can be solved in one of two ways:

1. Expose the KuchikiParser as part of the public API.
2. Add a new kuchiki::Selectors::compile method that takes a cssparser::Parser as input instead of a &str.

It's possible I might be better off using the html5ever, selectors, and cssparser crates directly, but I wanted to explore these options, too. Do either of these fit with your vision for the Kuchiki API?

[SimonSapin]

cssparser is a private dependency of kuchiki, by design. This means that updating to an incompatible version of cssparser (for example from 0.25.x to 0.26.x) is not a breaking change. Both of your proposed solutions would make it a public dependency, which I’d rather not do.

Two alternative options are:

• In parse_prelude, extract a rule’s prelude as a string to give to Selectors::compile:

  fn parse_prelude<'t>(
      &mut self,
      input: &mut Parser<'i, 't>,
  ) -> Result<Self::Prelude, ParseError<'i>> {
      let start = parser.position();
      while let Ok(_) = parser.next() {}  // EndOfInput is the only error returned by next
      let prelude_str = parser.slice_from(start);
      kuchiki::Selectors::compile(prelude_str)
  }

  This duplicates the runtime work of tokenization for selectors.

• Make your own tree data structure instead of Kuchiki. This is a fair amount of initial work and additional code you have to maintain, but it provides a lot more flexbility.

  See for example https://github.com/SimonSapin/victor/blob/fdb11f3e87f/victor/src/dom/mod.rs which uses indices into a big Vec<Node> instead of Rc<Node>. This makes a bunch of things easier (for example there’s no Cell or RefCell, mutation goes through &mut Document) with the tradeoff that no node is dropped until the whole document is. That may be ok for something that doesn’t support JavaScript with access to the DOM, or other arbitrary "user" code.

  But even if you stick with Rc<Node>, there may be other assumptions or choices that Kuchiki makes that you could make differently.

[twilco]

cssparser is a private dependency of kuchiki, by design...Both of your proposed solutions would make it a public dependency, which I’d rather not do.

Fair enough, I thought this might be the case.

Thanks for your detailed alternatives — I'll extract the string from the parser for now. Supporting JavaScript, while a very, very distant goal, is something I'd like to do eventually. I'll press forward and see if Kuchiki will work for me. Thanks for your help, and for creating this crate!