From: Bjoern H. <der...@gm...> - 2001-10-01 02:38:36
|
Hi, 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 * it must distinguish between CSS levels (1, 2, 3) * it must provide explicite information on valid values * it must enable applications to resolve shorthand properties * 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 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. 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. 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/). regards, -- Björn Höhrmann { mailto:bj...@ho... } http://www.bjoernsworld.de am Badedeich 7 } Telefon: +49(0)4667/981028 { http://bjoern.hoehrmann.de 25899 Dagebüll { PGP Pub. KeyID: 0xA4357E78 } http://www.learn.to/quote/ |
From: Robin B. <ro...@kn...> - 2001-10-21 19:12:28
|
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 |
From: Bjoern H. <der...@gm...> - 2001-10-25 02:00:59
|
* Robin Berjon wrote: >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. Yeah! >For the forward compat rules, I don't think that should go into CSS::SAC. Well, at least some higher-level interface to CSS::SAC to get a proper parser if you want to do something CSS Level X specific. >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. I thought CSS::Properties for properties, CSS::Selectors for selectors, etc. if this was not too obvious for you ;-) >> 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 ! Shouldn't be too hard, I can write a Perl Script to extract data, that's why we are here :-) Prose restricitons and additions will be hard, though. >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. Just do it for some properties, interesting would be font-family font margin clip vertical-align text-shadow This should cover most of the not too simple cases ;-) -- Björn Höhrmann { mailto:bj...@ho... } http://www.bjoernsworld.de am Badedeich 7 } Telefon: +49(0)4667/981028 { http://bjoern.hoehrmann.de 25899 Dagebüll { PGP Pub. KeyID: 0xA4357E78 } http://www.learn.to/quote/ |