Re: [libcroco-list] Libcroco notes

[Peter Moulder <Peter Moulder infotech monash edu au>]

(Thanks mental; though it appears that I've already subscribed myself to
 libcroco-list.)

On Sun, Aug 28, 2005 at 07:03:21PM +0200, Bjoern Hoehrmann wrote:

> There is no way to tell the difference between x:3y and x:3.0y which
> is important to know since some properties like counter-increment do
> not allow numbers but only integers.

Indeed, the definition of the counter-increment property seems to
suggest that `counter-increment: mycounter 3.0' is an invalid
declaration and should be ignored by the application[*1] when searching
for a value of the standard CSS2 counter-increment property.

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 CRNum structure does not scale well to CSS3, since the units are
> hardcoded, only known unit identifiers are recognized, so properties
> using CSS3 unit identifiers like x:3rem; can't be processed.
> 
> The hardcoded handling of rgb() is unfortunate, it seems one cannot
> access the location information for the individual numbers and the
> values are clamped to integers 0..255. It would be better, and it
> seems simpler for libcroco, to simply handle rgb() values as generic
> functions. That's probably a bit too late now though, perhaps an
> option could be added to treat them that way...
> 
> Is there a reason why CRTerm stores operators and such not as simple
> values? At the moment x:1+2 would be two terms, it would seem a bit
> more intuitive and simpler to make that three terms...

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.
libcroco should be using the core CSS grammar to do the parsing, and
either the calling application or libcroco itself should ignore
declarations that aren't valid CSS2.  This involves creating a type to
represent the `any' symbol of core CSS grammar
(http://www.w3.org/TR/REC-CSS2/syndata.html), similar to the existing
CRTerm type that represents the `term' symbol of Appendix D's CSS2
grammar.

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).


Out of curiosity, what software currently uses libcroco?  I know of
librsvg, inkscape; I believe Dodji aims for mlview to use it, but the
current stable version doesn't.  The question of what users libcroco has
may affect interface decisions: e.g. if a particular function isn't used
by any widespread software, then that may influence how hard we work to
preserve backwards compatibility for that function.

Inkscape presents no backwards compatibility requirements (it has
libcroco copied into its source tree, and I'm the maintainer of its
libcroco bits).  librsvg doesn't use a local copy, so source
compatibility is desirable, but its libcroco use is very localized and
is wrapped in #if HAVE_LIBCROCO.

pjrm.


[*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.