What would a new CSS validator look like?
Author(s) and publish date
- By:
-
-
Olivier Thereaux
-
- Published:
A couple of weeks ago I attended, along with a few hundred other W3C participants, the yearly Technical Plenary meeting: a week's worth of meetings, encounters, ideas and exchanges. For many of us, this is the most exciting and exhausting time of the year: it takes quite a lot of stamina to survive through a week intellectual and geeky stimulation from breakfast to bedtime.
Discussions at the TPAC week have born some wonderful fruits we will soon talk about, but today I wanted to share a thought experiment started over lunch on the technical plenary day. Daniel, the co-chair of the CSS Working Group, was waxing lyrical about the power and simplicity of a CSS engine entirely built in javascript: simple, fast, portable across platform, distributed computing needs… What about rewriting the CSS validator that way?
I don't yet have a clear opinion on Daniel's idea, but I like his approach. The CSS Validator is now a 6-years-old piece of software with a level of complexity deriving from years of following the CSS specifications and their evolutions, a reasonably low amount of known bugs, a test suite, and only few souls brave enough to dive into its massive collection of java code.
What if we started again from scratch today? What if today we build a brand new CSS validator? Or, better, what if today we build a brand new tool to help bring better CSS style sheets to the web? What would you build? What would you want to use?
- What would the basic features of that tool be? How would they be different from the existing CSS validator?
- What would the cool extra features of that tool be?
- What engine, what language would you build this tool with?
- Would you sacrifice some flexibility for performance and simplicity? For example, one of the very costly features of the current validator is to have different tokenizers, parsers and grammars for CSS1 CSS2 and CSS2.1. Would it be a big loss if the tokenizer and parser were only defined by the latest stable CSS, while keeping the ability to check against each "profiles" (properties and values)?
- Update 2008-11-12: clarified the last question about “obsolete” CSS 1 and 2.
- Update 2008-11-12: there is an entry on a public w3c wiki with a section on the vision and roadmap for the CSS validator. Let's record the ideas of this blog conversation on the wiki?
Daniel Glazman just posted on his weblog a few more thoughts on this question:
(4) Yes and no; no (aren’t CSS 1 and 2 more important than ever?).
– Jens.
the amount of code is not what I would call massive, but it is indeed calling for a refactoring
"CSS engine entirely built in javascript: simple, fast, portable across platform, distributed computing needs"
The engine would be as simple as the architecture behind it. But even with the support of closures, I doubt it would be that much simpler that the Java one (which is not overly complicated). "Portable across platform", it depends what is called "platform", for Java it's the JVM, for Javascript it could be a web browser or a standalone runtime, all of them adhering more or less strictly to the ECMAscript specification. "Distributing computing needs" : I don't understand this point (?).
As a user, I don't care about the underlying language used for coding the validator.
Maybe when CSS2 is obsolete, let's say in 2014.
From Daniel's post:
"I think that if a new validator is built, it should create a community of maintainers and be integrable easily in third-party apps."
The community part is not specific for "a new validator", the same could be done for the current one, but it requires time available from the commiters.
Damien,
When I wrote “ increasingly obsolete CSS1 and CSS2” I was of course considering CSS2.1 (in particular its grammar) as the current (and not obsolete) reference. :)
I’d be willing to forgo CSS1 and CSS2 support. I think an author writing CSS today and using a validator as a helper tool does not need to target CSS1 or CSS2.
I’d want the low-level parser to implement whatever happens to be the latest in the forward-compatible parsing rules. By default, I’d want the higher lever to know about all CSS properties from the CSS and SVG working groups in any spec in WD or above.
I’d want it to know about the vendor-specific properties from Mozilla, WebKit, Opera, Microsoft, Prince and HP at least on the level of recognizing the prefixes and not complaining about the vendor extensions as if they were typoed properties. (People who are working near the edge of CSS development use these properties and seeing too many errors caused by vendor properties drown out the real typos.)
Restricting checking to a profile such as CSS 2.1, CSS Beijing, SVG-specific CSS or only W3C properties (vendor stuff excluded) could be UI options. I think the style sheet itself shouldn’t contain any versioning syntax. I think the forward-compatible parsing model and the lack of versioning syntax in CSS is are its greatest versioning features.
I think it would make sense to build the tool in GWT-friendly Java or Rhino-friendly JavaScript so that the validator could be deployed both on a JVM and on a browser runtime. I have two reasons to care about running on a JVM: integration with Validator.nu and integration with Eclipse.
Writing a new CSS validator versus writing a new CSS engine seems to me be be relatively distinct tasks, maybe not for their technical implementation but for their goals.
A 100% JavaScript CSS validator could be embedded in tools like Firebug and help developers stick to the open standards as they are developing their code instead of having to resort to the last decade's methodology of code, load, refactor, refresh, lather, rinse, repeat.
In other words, what I'd like to see come out of a JavaScript version of a CSS validator is better development tools with usable user interfaces for developers. Perhaps a Firebug-enabled CSS validator could do things like highlight the lowest common denominator of CSS profile that any particular CSS rule supports, based on its declarations. This is, in my opinion, the best way to encourage people to use the standards in the first place.
As for CSS1 vs CSS2 vs CSS3 or whatever, I feel like it's still very important to be able to selectively target all (or at least the current CSS2.1 and future CSS3) versions.
Anyway, just my off-the-cuff 2¢.
I don't really care about what language it's built in. What I would like instead is a good, well-documented API for integrating tools and web-services with the online validator.
I think the validator should be able to validate against each release of CSS (1, 2, 2.1, 3 etc).
It should be aware of vendor-specific properties, selectors etc. and inform the user about them, and what current browsers they are supported by.
It should warn if parts of newer specifications are being used when validating against an older specification (validating against CSS2.1, but using CSS3 selectors or properties etc.)
I wish it could help me find parts to optimize, where to use shorthand declarations, what rule sets can be joined etc. Like many of the online formatters and optimizers do already.
if it could make me coffee in the morning as well then I have nothing more to complain about.
Olivier, if you meant "latest technology (CSS2.1, CSS3)" then perhaps you should write that to avoid confusion between the old REC-CSS2 and CSS Level 2 (CSS2.1).
Henri -- The CSSWG resolved that the validator should include properties in any draft that is CR or higher, not just any WD.
@Meitar, could you give more details about what you mean by:
Several people indeed seem to agree that a JS-based validator could be easily included in browser and authoring tool, and that sounds very useful indeed.
@Erik: do you know of the current API for interaction with the CSS validator and would you have suggestions to improve it?
@Olivier: Sorry, didn't see you had asked me that 'til now. :)
The idea I had when I wrote the above comment was just that I'd like to see my in-browser tools such as Firefox show me not only the effect of my declarations but also to what standards I'm coding to. Therefore, a validator for CSS, which should theoretically already be aware of the fact that, say, text-decoration is a property specified as far back as CSS1, should also be able to expose that fact to me in its UI.
Assuming all of my declarations are specified in CSS1 and if the tool checked each one, it would then be able to tell me that the entire CSS rule in question "should be supported by any UA that supports CSS1."
Taking this concept further, a tool like that could also recognize vendor-specific extensions, as Erik mentioned. In the future, say if -webkit-transform became supported in CSS3 officially, it could then tell me this. ("You're using a vendor specific extension but if you target CSS3, you no longer need to.")
Again, just some thoughts… I hope this answers your question. :)
I hope this project bears some fruits as I've just wasted hours on trying to get css-validator to run locally.
I mean this is a great application on the website, but it's a royal PITA to build (just look on the mailing list). FWIW is a css validator with at least CSS 2.1+ support. And it should be able to use that app on a variety of usecases, e.g. incorporate it into an IDE for on-the-fly syntax checking. JavaScript would be OK for me.