W3C home > Mailing lists > Public > www-style@w3.org > September 2005

Defining Browser Compatibility Without Relying on the Browser

From: Richard York <richy@smilingsouls.net>
Date: Sun, 18 Sep 2005 11:35:20 -0500
Message-ID: <432D9748.7040209@smilingsouls.net>
To: www-style@w3.org

Start by using CSS to create a definition file for your browser that 
contains the specific cases you may need to explicitly check 
compatibility for using an @required rule set, followed by the specific 
property/value sets that the browser supports.

For instance, if I wanted to define that the browser supports the 
"fixed" value of the background-attachment property on the <body> 
element, this would be done as follows.

body {
	background-attachment: fixed !supported;

This overrides any support defined by the browser.

Scenario two: "fixed" is supported and "scroll" is unsupported.

body {
	background-attachment: fixed !supported;
	background-attachment: scroll !unsupported;

Scenario three: "fixed" is only supported by the <body> element, but not 
it's descendants.

body * {
	background-attachment: fixed !unsupported;

This is all saved in a .css file.  Then, the .css definition file is 
loaded, presumably the author uses their own user-agent detection to 
selectively supply the compatibility definition file.


Or perhaps,
<link rel="stylesheet compatibility" href="file.css"  type="text/css" />

Finally, the author can define rule sets based on the support of a 
particular property:

/* !supported is implied */

@required(background-attachment: fixed;)
	div {
		background: url('some/file') fixed;

Disclaimer: I don't see much benefit in this feature personally.  I 
believe server-side processing to be more appropriate.  I'm merely 
pointing out that it is possible to deploy such a feature without 
relying on the browser to tell the truth about what it supports.

Richard York

Mail_IMAP: A PHP/C-client/PEAR solution for webmail
Author: Beginning CSS: Cascading Style Sheets for Web Design
Received on Sunday, 18 September 2005 16:35:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:20 UTC