Table of topic groups > Front page of CSS-guide > Proposals > eXtensible Cascading Style Sheets (XCSS)

eXtensible Cascading Style Sheets (XCSS)

Topics

• Common
• A proposal to XCSS

Common

Microsoft has been designed much proprietary CSS. In my mind the aims of Microsoft could be fulfilled best by developing XCSS (eXtensible Cascading Style S heets).

A proposal to XCSS

In order not to destroy accessibility, XCSS should be fully compatible with CSS and is should be parsable and validate able with a standard validating system.

The first matter can be fulfilled so, that the CSS concerns only the user interface + some possibilities to use special user interface features in web pages, for example:

a:hover {display:floating-box; content: attr(title); border: 2px solid #666; height:30px;above:30px} /* this create a floating box above the link when mouse goes over the link; In this example the only necessary proprietary is the display value */

The result resemble following standard CSS:

p.special:before {display:block; content: attr(title); border: 2px solid #666;height:30px;}

If you download Opera 4.x+ and visit in this page, you can see a block box over the previous paragraph:

:hover:before {display:block; content: attr(title); border: 2px solid #666;height:30px;}

In principle dynamic pseudo-classes (:hover, :active and :focus) can be applied also to other elements as only to the element A. Netscape 6.x supports them to some form element but other browsers only to the element A. If they could be combined with :before and :after, then could be used for example the following rule: p:hover:before.

Expressing the attribute title with standard or proprietary CSS could increase the accessibility very much, because the standard title text is very small! This is the positive way to be innovative without violating accessibility in the web! The attribute title can be rendered with a standard advisory text (the previous element has an advisory text), but the text is quite small and better presentation could be desirable. Browser designer could fight, who can invent most positive innovations without affecting any harm to other browsers. These extension must not be ready. Also half-made implementations can test. Best proposals could be one day official standards.

In order to separate standard and proprietary CSS from each other, the media attribute should tolerate proprietary values. The only rule to all CSS-capable browsers should be that if the media value is not recognized, the whole style sheet should be ignored, for example Opera and Netscape should ignore the following link element:

<LINK rel="stylesheet" media="IE55" href="IE55.css" type="text/css" />

That file could include all the proprietary CSS (for example scrollbar-3d-light-color: aqua;), which MS has brought to MS IE 5.5. At the same principle Opera use CSS in the WML (I handle it in the page Help for TM WML menu) implementation and Netscape use in XUL (eXtensible User interface Language).

If some older CSS-capable browser read it, the syntax must be standard to ensure CSS1 compatible parsers to read most parts of the CSS. All CSS1 browsers should have forward compatible parsing and XCSS should be as much as possible backward compatible.

XCSS could give the possibility to tailor CSS for WAP devices, which can't ever handle large quantity of CSS, for example:

<?xml-stylesheet media="handheld" href="xml-sheet2.css" type="text/css"?>
<!-- That XML-stylesheet gives common information -->
<!-- That following XML-stylesheet gives specific information -->
<?xml-stylesheet media="Nokia" href="xml-sheet2.css" type="text/css"?>

I hope that at this way CSS could be implemented to WML.

But the proprietary CSS should be validate able. The best situation is, if all browser designers create a parser, which validate the code and complains errors like JavaScript interpreters. At least Microsoft should stop accepting invalid syntaxes and other invalid encoding and demand instead to create in all respects valid and well-formed encoding. Forward compatible parsing and internal validating can't work properly, if the browser accepts invalid encoding! Concerning proprietary CSS this is much more important than in standard CSS. Standard CSS has proper online and offline validator, but to proprietary CSS needs proper validating system. The system itself could be standardized.

All HTML document types have DTD-files (Document Type Definition). XCSS could have also some kind of definition file, in this case Property Definition file. I take an example of possible IE55.pd:

<!-- An example, how the proprietary CSS in MS IE 5.5 could be expressed in a XCSS pd-file -->
<!ENTITY % standard "http;//..."-- a refer to web page; the page could be fixed and the UA could use also internal information -- >
<!ENTITY % scrollbar "scrollbar-3d-light-color | scrollbar-arrow-color" -- proprietary scrollbar properties -- >
<!PROPERTIES -- scrollbar-3d-light-color "%standard; | %scrollbar;">

The first comment could tell information to the parser and validator, for example:

/* # /parser/IE55.pd for example Opera 3.x doesn't read it; the notation # comes from Perl or C++ */
scrollbars {color:#ffc}

If the proprietary CSS of MS IE 5.5 could be defined with standard syntax, an external XCSS validator utility could check the proprietary XCSS file, if the XCSS has valid syntax and it use valid properties and property values. In order to ensure, that CSS2 validator would not complain any proprietary extensions, XCSS extensions should not put among standard compliant CSS but only into own external CSS-files. In the beginning of the CSS file is the instruction to find the *.pd for XCSS extensions.

W3C has also a proposal User Interface for CSS3. Some of them could be expressed as XCSS. If proposals of W3C has completely new features they could be as XCSS instead of listing them ordinary way. CSS3 base on modules.

The syntax to *.pd files borrowed from HTML and XML DTD-files. It might be different and resemble the syntax of scripting languages. Because it is needed only into validating purposes, it could be easier to authors to use the same kind of syntax in XML DTD-files and XCSS PD-files.

Perhaps it could be reasonable to define also proprietary pseudo-classes or pseudo-elements. They need an own declaration, for example:

<!PSEUDO-ELEMENT :last-letter "...">

I know that CSS3 proposals have new pseudo-elements and that might be even in some proposal. Creating new pseudo-elements or -classes should remember the progressive rendering. If the rendering must stop and even go backward, the rendering process is slower compared to situation, when the browser can use progressive rendering. For example the possible pseudo-element :last-line is harmful, because the browser must go first to the end of the element and then backwards to start rendering the last line.

CSS3 base on modularization. XCSS could perform better the idea of modularization than the existing proposal of CSS3. The author should tell, which modules he wants to use, for example:

/* # moduleHandheld.pd
# modulePrint.pd */

The advance of this system is, that an XCSS validator could complain properties of property values, which don't belong to certain modules even if used properties and property values are standard. Standard modules don't need path information.

This system doesn't however prevent all errors. It can check thoroughly only so-called declaration blocks (everything, which is inside {}). Concerning rules, it can only check the syntax and used pseudo-element and -classes, but it can't check if rules are reasonable. For example td > body {display:inline} or table pd {display:inline} are valid CSS-rules, but at the respect of HTML they are nonsense.

In order to check this, XCSS validator should compare XCSS-files with DTD-files. This cause however limitation. XCSS-files could be used only with defined document types. If the author needs only certain document type, the parser could get also following information:

/* # /parser/css.pd;
# dtd="http://www.w3.org/TR/xhtml1/"/DTD/xhtml1-transitional.dtd";*/

If the parser doesn't get this information, it doesn't try to validate if used element names are reasonable.

Browsers could use also plug-ins applications. I hope, that browser designers could put the CSS-implementation in module, which is easy to update and the user could update only the module without downloading the whole application. Then bugs could be fixed more often.

Indeed - first proper implementation according to the specifications! Only if the time table allows, proprietary extensions. Supporting of proprietary extensions should not happen on expense of standard implementations.