Over the past few weeks I’ve received a number of emails from visitors to CSS3.info regarding CSS3 validation errors when using vendor specific extentions, for example -moz, -webkit, to implement CSS3 in their websites.

This certainly isn’t a new topic, and in fact Joost de Valke first raised the issue on this website back in January 2007, however a glance over the W3C mailing-list archive highlights that this debate is still going strong, with a number of interesting ideas raised, and I thought it would make an interesting discussion point for the CSS3.info community.

The problem is that, at present, none of the CSS3 modules have yet receached the status of becoming an official W3C Recommendation, as such any of these specifications could in theory be changed at time, particularly those that are still in the early stage of development.

Obviously browser vendors (with the exception of course of our beloved friend Microsoft) are keen to support these up and coming CSS3 specifications, however as they are still at an “experimental” stage of development it is necessary for the various css3 properties to be implemented using vendor specific extensions in order to avoid any possible conflicts with current or future css specifications.

Web designers are equally keen to implement these latest CSS3 techniques in their projects as browser support, along with interest from the wider community, continues to grow – a quick search around the blogosphere shows countless new CSS3 tutorials being added to the web on a weekly basis, and sites such as CSS3Gallery.net showcasing web designers putting CSS3 to great use in their projects. However many are facing a catch 22 situation, weighing up the pros and cons between utilising the latest that CSS3 has to offer against the fact that their creations won’t pass the W3C Validator, with some web designers even going so far as to question the importance of validation.

When Joost De Valk brought this concern before the W3C back in January 2007, he was met with a somewhat muted response, however the debate has continued to intesify and a number of interesting suggestions have been put to the W3C:

- That the CSS3 Validator could offer the option to ignore vendor specific extensions,

- That the CSS3 Validator could highlight vendor specific extentions with a warning, rather than an error,

- Or my own personal favourite, that the validator could mark such code as ‘experimental’ rather than error, or warning

Either or these methods would allow web designers to continue to validate their pages, an important process for spotting any errors in your code, as despite some designers questioning the importance of validation, personally I think it’s a necessary and important tool.

In the meantime, several web designers have suggested their own personal ways of overcoming the problem, with many commenting out CSS3 code until they have validated their pages, so that at least they can check the accuracy of their CSS2.1 code.

In conclusion I’d like to say that, in my opinion, both sides of the argument present some valid points – obviously the W3c can’t be expected to validate what isn’t technically valid CSS, however perhaps the word ‘error’ is too strong, and marking vendor specific code with a ‘warning’ or ‘experimental’ status would be a happy medium between the needs of the W3C and designers eager to implement CSS3.

At the same time, I have to question whether or not the time has yet come for designers to be implementing CSS3 in their client projects. I think CSS3 is perfectly acceptable to be used in a designer’s own projects, and quite essential to promote the growth of CSS3, but is it really acceptable to sell a client experimental code that could cease to function at any time if the W3C ammends a specification, or browser vendors change the syntax with which a property is implemented?

Once again I turn the debate over to you, CSS3.info’s readers, how to you feel about this issue, and what’s the best solution from your point of view?

Source: http://www.css3.info/the-big-css3-validation-debate/#

Related posts

• Do’s and Dont’s in web site building (0)
• The Beauty of CSS (1)
• PHP $_SERVER variables are not safe for use in forms, links (1)
• 6 New Web Technologies of 2009 You Need to Use Now (1)
• 960 Gridder: Easy to use layout design tool (0)

CSS is not a difficult language to learn, though there are bugs and browser discrepancies to deal with. He wrote off CSS when he compared IE5/Mac layouts in Netscape 4, but regained religion in 2002.

What about CSS is so beautiful to him?

“Standards” are “widely recognized” and “regularly used.” “Standards give us some kind of consistent target to build toward.” Standards benefit those who build the tools and build with the tools.

In nature, beauty goes beyond the surface down to structure and up to ecosystems. You often get accessibility bundled with CSS as a package deal.

Feedback from Wired News reader, which he shares “by no means in a raconteur style”: If you ask for feedback after you redesign a site, 90% of the feedback will be negative. “Your colours are awful; they’re too bright. I can’t read your type. Your designer sucks and should be fired.” Positive feedback to his own site followed a little formula, including one message that ended with “By the way, I’m blind.” “And that hit me like a ton of bricks…. His message basically completely fundamentally changed the work I do…. I don’t just design for people who can appreciate the beautiful designs and type I use on a site. I also design for blind people. I also design for people who can’t get out of the house because of a mobility impairment.”

Advantages: “Fstr” (sic) in real or apparent speeds. Simpler code; greater flexibility; one version.

Mistakes? Boxiness: Overreliance on the box model and making the box visible. “This can be a symptom of starting with CSS too early” in the design process, doing “only what we can immediately remember in CSS.” Image replacement: “A year ago at South by Southwest I deprecated image replacement.” We already have a tag for that in HTML: img with alt. In fact, a lot of the success of CSS Zen Garden is image replacement. You can’t zoom into it, for example [though you can with sIFR – zoom then reload]. Presentational class and id names: large, redtext, top-line, borderred, rightcol. Use page-title, subhead, main, module, secondary instead. Accessibility assumptions: Just for the blind or PDA users. Imitation.

Related posts

• PHP $_SERVER variables are not safe for use in forms, links (1)
• 6 New Web Technologies of 2009 You Need to Use Now (1)
• 960 Gridder: Easy to use layout design tool (0)
• The Big CSS3 Validation Debate (2)
• 45+ New jQuery Techniques For Good User Experience (3)

Andrée Hansson has created 960 Gridder, a grid layout tool for web developers that you can either use as an integrated component to layout your websites or use it as a bookmarklet. The grid is fully customizable but it defaults to the “960px grid standard”.

960 Gridder will automatically identify if jQuery is present at the website and if it is not, it will include it.

It injects your website of choice and you can then work with this tool to help you out with whichever layout/design task you find it useful for.

By default, it is set to work with 12 columns, 60 pixel wide columns with a 10 pixel spacer left and right of the column, making it a 20 pixel wide gutter (which actually is the ones this gridder renders).

You can see and read about the “960 standard” at http://960.gs.

Related posts

• Why use a CMS? (4)
• PHP $_SERVER variables are not safe for use in forms, links (1)
• 6 New Web Technologies of 2009 You Need to Use Now (1)
• Do’s and Dont’s in web site building (0)
• The Beauty of CSS (1)