W3C home > Mailing lists > Public > www-style@w3.org > October 2003

Proposal - browser specific CSS

From: Marc <manarth@zioncore.com>
Date: Wed, 15 Oct 2003 14:08:55 +0200
Message-Id: <200310151208.h9FC8tDM032373@lanalana.inria.fr>
To: www-style@w3.org



==========
1.  SPECIFY THE TYPE ATTRIBUTE TO ESTABLISH THE CSS VERSION

Current HTML include statement:
    <link rel="stylesheet" href="style.css" type="text/css" 
media="screen" />

It seems that no matter how the standards are set, browsers all seem to 
exhibit different behaviour.  Call them 'bugs', call them 'features', 
whatever.

So web developers innovate new ways to get around these features.
e.g
    body #div_iv  {attrib: value} /* (is interpreted by MS Internet 
Explorer for Windows) */
    body>#div_id {attrib: value} /* (is NOT interpreted by MS Internet 
Explorer for Windows) */

Perhaps the type attribue should be redefined:
    <link rel="stylesheet" href="style.css" type="text/css" 
media="screen" />
    <link rel="stylesheet" href="style.css" type="text/css3" 
media="screen" />
    <link rel="stylesheet" href="style.css" type="text/css4" 
media="screen" />

It's too late to redefine the type attribute for CSS2 - let's consider 
establishing the standard for future development.  This would allow 
developers to build distinct style sheets for varying browser 
compliance.  Obviously this is a change to both the HTML and the CSS 
standards.

There is precedent: the HTML dtd (doctype declaration) specifies the 
version of HTML is being sent, so why not do the same for CSS?

==========
2.  ALLOW CSS STATEMENTS TO BE USER-AGENT SPECIFIC

Adding a deliberate 'Exclude' statement into CSS would allow developers 
to deliberately introduce different style elements depending on what 
browser was used.  This avoids 'dirty hacks' like the example above; 
allowing developers to cater for different browsers' implementations of 
CSS in a more meaningful and deliberate fashion.

==========
SUMMARY

Browser developers are not perfect.  If we choose to recognise this fact 
at this stage of development, then we can take steps now to ensure that 
a buggy browser won't break too badly.
To fail to prepare is to prepare to fail.

==========
Marc Deglos.
Received on Wednesday, 15 October 2003 08:09:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:24 GMT