Re: [libcroco-list] Libcroco notes

[Bjoern Hoehrmann <derhoermi gmx net>]

* Peter Moulder wrote:
>This is unfortunate, in that the grammar specification at §4.1 has no
>separate token for §4.3's <integer> type, and gives no indication of
>what information is required for token values.  If the lexer token value
>must communicate the distinction between `3' and `3.0' for NUMBER
>tokens, then what other distinctions must be communicated to the
>application?  Should NUMBER tokens (and PERCENTAGE/DIMENSION tokens?)
>report a CRString value instead of / as well as the double value?  (In
>the case of counter-increment, it would suffice to have a boolean
>indicating whether or not it's a valid <integer>.)  If we report the
>original string representation for numbers, then one wonders whether any
>other token types need an uninterpreted form in their token value, e.g.
>the original escaped form of an ident/name/string/...  (At the moment my
>feeling is to exclude this information until someone calls for it.)

The concrete CSS 2 grammar is not all that important, it's merely an
aid to clarify certain aspects of the general processing model. It's
only important what the actual application that has knowledge about
individual properties and such behaves as required in the specs. The
CSS specifications basically assume you have a monolithic user agent
that combines all such things, so it assumes you have knowledge about
the properties like their syntax or in case of shorthand properties
what they resolve to and such. Libcroco is not designed this way, so
what matters for libcroco is that it enables higher-level apps to do
what the specification requires.

For the specific case, you can tell the difference between 1 and 1.0
only through using the location information and look into the original
style sheet at that location, that's a bit inconvenient. My main use
for libcroco is to build tools that help people to write better code,
validators, pretty printers, and such; these tools benefit very much
from getting as much information about the original input as possible,
that's why Dodji added the location information throughout the code,
for example. Retaining the original string for input would be good,
it would help to preserve e.g. "CSS hacks" as in common use today in
e.g. a pretty printer. I'm not sure though what'd be the best way to
solve this problem.

>A particularly relevant other bug to add to this list [already briefly
>discussed with Dodji on IRC] is that libcroco currently has incorrect
>behaviour for rulesets that are valid core CSS but not valid CSS2.

(Note that CSS 2.1 changes and clarifies some of the rules here, some
things previously not covered by the forward compatibility rules now
have clear conformance requirements; at some point libcroco should be
updated to take those into account; that might have to wait until we
publish the CSS 2.1 test suite with test for the relevant rules.)

>The creation of this `any' type can simultaneously address the
>above-mentioned problems of units and rgb types, and would presumably
>also separate out any `,' or `/' character into a separate `any' symbol
>(DELIM token).

Yes. This would in fact be necessary to allow implementations to
support the CSS 2.0 font-family property, e.g.

  font-family : {};

Is a legal value which libcroco can't really handle at the moment.

>[*1]: libcroco must still pass this declaration to the application, as it is
> only the rules of the counter-increment property that make it invalid.
> libcroco has no knowledge of individual CSS properties, and this
> ignorance is good for e.g. SVG agents, as SVG has in some cases
> different validity rules from standard CSS2, e.g. allowing unitless
> length values.  It may well be useful to add optional knowledge of
> standard CSS property rules, so long as SVG etc. callers can use
> different properties.

I'd prefer to have such knowledge at a higher level than libcroco, I
think the existing exceptions for e.g. rgb() aren't really helpful,
at least not for my purposes. The more generic the better, as far as
I'm concerned :-)
-- 
Björn Höhrmann · mailto:bjoern hoehrmann de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/