Re: [css] CSS::Properties

[Robin B. <ro...@kn...>]

On Monday 01 October 2001 04:37, Bjoern Hoehrmann wrote:
>    CSS::SAC and CSS::DOM need some CSS::Properties module, SAC to adhere
> to the forwared compatibility rules (i.e. ignore unknown properties,
> ignore invalid values, etc.) if the user wants to parse some stylesheet
> according to some specified CSS version, DOM to resolve shorthand
> properties to the real properties. Requirements for this module are

Yes, and this takes a lot of work to do right (says the guy that tried that 
back in the early days of CSS::Parser). But it would be a great win. I think 
we can start small (but clean) and try to build on top of that.

For the forward compat rules, I don't think that should go into CSS::SAC. CSS 
SAC just parses the syntax, and doesn't care about the specific versions. 
Ignoring unknown rules ought to be taken care of by a SAC Filter I think. Eg 
CSS::SAC::Filter::CSS2 would only let through events that are correct CSS2 
events and weed the rest out. Building it into CSS::SAC will imho be 
cumbersome at best.

By the way, I'm not sure that CSS::Properties is a good name as we would also 
want to deal with @rules and selectors. The former are probably easier, the 
latter probably insanely hard :-) But properties is a good place start.

>   * it must distinguish between CSS levels (1, 2, 3)
>   * it must consider CSS modules
>   * it should be easily extensible for new CSS levels
>   * it should consider CSS profiles
>   * it should consider SVG 1.0

All of these can probably be resolved together. CSS::Properties::CSS1 would 
define what's good for CSS1. CSS::Properties::CSS2 would then import that, 
and define somehow what it *doesn't* want to import (eg deprecated stuff), 
and add its own. Saying what one doesn't want would be necessary for 
profiles, SVG, etc. This is probably a matter of agreeing on common data 
structures, and providing ways to filter and merge them. Not too hard. We 
could use hashes to merge stuff, and filters could simply weed out the keys 
they don't want (the most common case).

>   * it must provide explicite information on valid values

The above hash could have a hashref as its value that would in turn contain a 
valid_values entry, the value of which would be an array of valid 
LexicalUnits. This scheme can probably (I haven't thought about it too 
deeply) work for simple (ie not shorthand) properties. If not I'm pretty sure 
something similar can be devised.

>   * it must enable applications to resolve shorthand properties

Again, another key of that hash, say resolve_shorthand, would point to a sub 
that would know how to do that. All it needs to receive is the content of the 
property, and it could return a hash of simple-property/property-values. 
Again, if that's not sufficient, then something similar can be done imho.

> We can make a deal, someone provides a template for the data and I will
> fill that template with data from CSS 1.0, CSS 2.0, SVG 1.0 and
> occasionally CSS Level 3.

Wow, I admire your courage ! With sufficient reflexion on the above outlined 
schemes, I could provide you with the template. I unfortunately don't have 
the time to fill in the data.

> The CSS property value notation is quite complex. Think of property
> values as XML DTD content models, thus order, occurences, alternates,
> etc. shall be considered.

As much as possible I think we should keep things simple for simple 
properties (eg provide an array of valid values for those that take only 
alternates) and provide maximal flexibility for the more complex ones (ie use 
Perl code in coderefs). If there are intermediate cases that don't work with 
the former but are too simple (or too frequent) to warrant the latter then we 
can start using code-templating techniques. The problem is, it's hard to 
define this a priori.

> This module, in combination with CSS::SAC would enable us to write some
> CSS::Validator module. If I get any time, I'll write that module as
> contribution to the W3C HTML Validator (http://validator.w3.org/).

I'd be able to contribute to CSS::Validator as well. I just don't have time 
to go through the entire CSS/SVG specs one by one to patiently list all 
content model variations and find the best scheme to express them all in the 
simplest way. With some premunching of those however, I could most certainly 
help finding a Perl solution.

-- 
_______________________________________________________________________
Robin Berjon <ro...@kn...> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
-----------------------------------------------------------------------
Doctor:   "Ah, ah that's a catch question. With a brain your size you
don't think, right?" 
-- Dr. Who