(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. _______________________________________________ Libcroco-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/libcroco-list
