- From: Simon Sapin <simon.sapin@exyr.org>
- Date: Wed, 10 Jul 2013 18:18:59 +0100
- To: marc@marcomorain.com
- CC: www-style@w3.org
Le 10/07/2013 17:21, Marc O'Morain a écrit :
> Hi Simon,
>
> My tokenizer is complete and I have started work on my parser. I think
> I have found another issue:
>
>> 5.4.3 Consume a qualified rule
>>
>> 〈{〉
>> Consume a simple block and assign it to the qualified rule's block. Return the qualified rule.
>>
>> simple block with an associated token of 〈{〉
>> Assign the block to the qualified rule's block. Return the qualified rule.
> The second of the statements above does not seem to make sense – I
> don't think that a token can be of type 'simple block' – I think you
> can just remove that second section and leave the first. (consume a
> simple block...).
Hi Marc,
The explanation is just before section 5.3.1:
> All of the algorithms defined in this spec may be called with either(
> a list of tokens or of component values. Either way produces an
> identical result.
But I agree with you that this is more confusing than helpful. As I said
before, I’d be in favor of having "Parse a list of component values" be
an intermediate step between tokenization and the other parsing
algorithm, which would all take a list of component values as their
input. This makes sure they can not get block nesting wrong.
(And again, this does not add constraints to implementation design: an
implementation that parses straight from a flat stream of tokens without
materializing a tree of component values could still be conformant.)
By the way, (off topic) my tests are now at their "permanent" URL:
https://github.com/SimonSapin/css-parsing-tests
Cheers,
--
Simon Sapin
Received on Wednesday, 10 July 2013 17:19:11 UTC