On 02/08/2013 09:36 AM, Simon Sapin wrote:
Hi dev-servo,
So my CSS parser in Rust is coming along nicely:
https://github.com/SimonSapin/rust-cssparser/
It’s mostly complete, although I still need to write some tests and
catch up with spec changes. We’re working on the remaining css3-syntax
issues in the CSS WG.
http://dev.w3.org/csswg/css3-syntax/
Right now the parser returns a tree-like data structures where the
nodes are at-rules, style rules, declarations, and unparsed "component
values". The latter are close to tokens, and expected to by parsed
further into selectors, values for a given property, etc. This is out
of scope for this parser library.
Next on the roadmap for this parser is to keep track of source
location (line and column number) for error reporting purpose. The
current data structure approach would mean adding source location
information to every token or at least every rule/declaration; which
is a bit heavy-weight.
I’m told that Gecko does all the parsing (including selectors and
property values) in one pass, and thus just queries the tokenizer for
source location information when an error is encountered. I’d still
like to keep the generic parser (specified by the css3-syntax spec)
separated from the rest, so the closest would be passing a bunch of
callback functions to the parser. The caller would have to keep track
of some context (an maybe even a stack) by itself (what rule is this
next declaration in?)
Thoughts? How should a CSS parser be architectured for servo?
I think at this stage your guess is probably better than mine, but I
agree with your intuition that putting the raw source info directly into
the CSS data structure not be a winning strategy, though if that info
was interned and represented as a single word it might be reasonable.
Does this information matter once parsing has completed successfully?
One thing to consider with the callback approach is that creating a
closure environment requires allocation and if you end up doing it a lot
the churning allocations could be worse for perf than just sticking a
bunch of integers into every data structure.
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
