Table of topic groups > Front page of CSS-guide > Proposals > Cascading Script Sheets

Cascading Script Sheets

Topics

• Common
• Script attributes
• Embedded script definitions
• External script files
• Pattern matching with scripts
• Media rules with scripts
• New syntax proposals
• Advances of my proposal
• Relation to other proposals

Common

A proposal to a new system to use scripts. In theory scripts could be organized like CSS! It does have corresponding definition styles, which I present. My proposal base on main features of CSS2 and how they could be applied to scripts, especially the pattern matching and media rules of CSS2. In theory scripts could use same patterns as CSS2. This could cause several advances, which I explain later.

At first this proposal concerns only JavaScripts and then the name was Cascading JavaScript Sheets (CJS). But I read about ecma-scripts, which is a new standard scripting language, which base on JavaScript of Netscape and JScript of Microsoft. This is then a proposal of next generation ECMAScripts.

Because I have used only JavaScripts, my examples base on them. First I handle common features of scripts and Cascading Style Sheets (CSS) because this is important.

Note: all code is marked as blue and inside the normal text CSS and scripts are in italics.

Script attributes

This is an example of CSS-style attribute with properties:

<TD style="border:1px solid #660033; background-color:aqua;">

A direct script attribute inside the element A could be like this:

<A href="some.html" name="my_face_image" onMouseOver= "document.my_face_image.src='redface.gif'; window.status='E-mail\ to\ Tapio\ Markula\ (tapio.markula@nic.fi)';return true">

Both CSS-properties and direct scripts use the same separator mark ;. Commonly most scripts can't be direct, because IE 3.02 can't understand some definitions and it might give error messages.

Embedded script definitions

Normally scripts are made so, that the function part is embedded to the document HEAD like this:

<SCRIPT Language="JavaScript" type="text/javascript">
<!--
function nayta(num, typ)
{var uusikuva = typ+ "_ankkuri["+(num-8)+"].src";
document.images[num-8].src = eval(uusikuva); }

if (document.images)
{var browser=true;
var a_ankkuri=new Array(12);
var b_ankkuri=new Array(12);
var Nimi= new Array(" ...");
for (i="0"; i<12; i++)
{ a_ankkuri[i]= new Image();
a_ankkuri[i].src=Nimi[i]+".gif";
b_ankkuri[i]= new Image();
b_ankkuri[i].src=Nimi[i]+"b.gif"; }
}
else
var browser=false;
// -->
</SCRIPT>

A corresponding CSS style element and typical CSS would look like this:

<STYLE type="text/css">
<!--
h2{text-align:center; margin-left:20px;}
-->
</STYLE>

In the script attributes are references to functions like this:

<A href="..." onMouseOver="if(browser) nayta(5, 'c');>

There are two common features:

• Both are inside comments to prevent old browsers to read them
• Both have round brackets. CSS uses them in round so-called declarations and declarations + selectors create rules. Scripts use them round function definitions (function ()). In both languages can be nested with round brackets.

The main difference between embedded script function calls and CSS-rules is, that scripts need always direct function-call attributes. CSS doesn't need them even if they can use attributes class and id.

In fact I recommend to avoid always embedded scripts, because in XHTML-documents it is necessary to use CDATA and following syntax cause only error messages to existing browsers:

<SCRIPT language="JavaScript" type="text/javascript"> <![CDATA[ ... some script ... ]]> </SCRIPT>

The time of embedded scripts in anyway soon over, because XSLT (translation language from XML to (X)HTML) creates XHTML-documents, which should be read also in older browsers.

External script sheets

Both scripts and CSS can use external files. The format of an external CSS-file is following.

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

The format of an external js-file is following:

<SCRIPT Language="JavaScript" type="text/javascript"></SCRIPT>

Pattern matching with scripts

Previous examples concern scripts, but my proposal concerns also other script languages even if I use in all examples scripts. If scripts could use the same pattern matching system as CSS2, it would be much more easier to use scripts. CSS2 style patterns could be added into script functions like in this example:

[name="my_face_image"] function() {document.my_face_image.src='redface.gif'}

The syntaxes base on CSS2 attribute selectors, which are like this:

[name="my_face_image"] { color: blue; }

In the case of script this doesn't work yet. The browser can't know, what it should to do. But CSS has already solved this problem. In order to display the attribute href in various situations, there are active pseudo-classes (read about them), which have following format:

a:hover { color: red }
:hover {color: red }

In fact active pseudo-classes in CSS2 have corresponding scripts (they don't match however exactly each others) in the situations, where scripts are intended to exchange link images (scripts can do also other functions and they can exchange other image as just the image, where the mouse pointer is located). Because CSS2 dynamic pseudo-classes make the same kind of effects as scripts, the create some events. And these are common events:

• :hover correspond onMouseOver.
• :active is the same as the situation between onMouseDown and onMouseUp.
• :focus is quite the same as onClick, because in CSS2 :focus is in force until the mouse is clicked in another place.

Both style sheets and script sheets could be focused into same elements, but they have however different interpreters (in my home page same elements have both onMouseOver/Out and :hover; :active and :focus: look at the combination - you need IE 4.01+, Opera 4.x+ or Mozilla Gecko (Netscape 6.0/Mozilla 0.6+) to see how they work).

In the meanwhile, I thought that it is confusing to use two kinds of name systems. I tried to combine CSS pseudo-classes and event handlers of scripts. But there is too many event handlers and it is not any sense to try to get them match exactly each others. However into CSS3 could be added some behavioral extension so, that events in scripts could match better CSS dynamic pseudo-classes. Also scripts might have some extra events. Here is some proposals to CSS3 and CESS (on the left is CSS3 and on the right CESS):

• :visited = :onChecked (this could be used then also with the element A)
• :hover = :onMouseOver
• :active = :onMouseActive or :onActive (:active = :onMouseDown + :onMouseUp) - new to scripts
• :activeUp = :onMouseUp - new to CSS3
• :activeDown = :onMouseDown - new to CSS3
• :focus = :onClick (using the mouse) and :onFocus (in the keyboard navigation)

The same kind of syntax could also be used in scripts like in this example (all characters are lowercase letters, because now event handlers are inside script files, which are case-sensitive):

[name="my_face_image"] :onmouseover function() {document.my_face_image.src='redface.gif'}

I read about event properties of BECSS. It suggest to use onClick in CSS. This proposal is then dependent on the BECSS proposal concerning event properties in BECSS and pseudo-classes in CESS.

You might ask, what the advance of my suggestion. And the answer is simple. According to my suggestion this could perform a function call:

<A name="my_face_image" href="some.html">

But it could be just easier if I could use contextual selectors. Then this could perform a function call:

<DIV><Ahref="some.html"></DIV>

It would need this kind of pattern:

div :onmouseover function() {document.my_face_image.src='redface.gif'}

Also so-called methods, which are written to the BODY of HTML-documents could be moved into external files and control by the pattern matching principle.

<SCRIPT language="JavaScript" type="text/javascript">
<!--
document.write(document.lastModified)
// --></SCRIPT>
Instead of this could be written like this:
<DIV><SCRIPT language="JavaScript" type="text/javascript id="date"></SCRIPT></DIV>

Also, methods could get script-rules like in these examples:

[id="date"] document.write(document.lastModified) /* this syntax base on CSS2-level attribute selectors */
*.#date document.write(document.lastModified)/* this syntax base on CSS1-level id-selectors */
div script document.write(document.lastModified) /* this syntax base on CSS1-level matching patterns/contextual selectors */

But at this connection it would reasonable to ask, if methods should be always used inside functions. Then the command part of the script could be always inside curly brackets. The reason of this matter is, that according to my proposal, there are always needed some kinds of function calls. These are in my proposal are primary matching patterns, but also JS 1.1 style function calls inside elements could be used. The the previous example should look out like this:

[id="date"] function date() {document.write(document.lastModified)} /* this syntax base on CSS2-level attribute selectors */
div script function date() {document.write(document.lastModified)} /* this syntax base on CSS1-level matching patterns/contextual selectors */

I know that this might cause some limitations, but the system must be very simple and as close as possible to the CSS-syntax. There might be needed some tiny alterations into function syntaxes, but according to my proposals these could be minimal. The main alteration is, that methods like document.write(document.lastModified) should have the possibility to put into exact place to the documents indirectly. The [id="date"] could identify the exact place with matching attributes inside some element. Today I use it directly inside the document body, but this is against my proposal and XHTML needs CDATA blocks in order to use scripts. Those kinds of scripts can't be read with existing browser, because script interpreters can't understand CDATA areas. All scripts inside the document head or body are anyway problematic.

In the last example I just added a rule set before the function. Then the syntax consist always of following parts:

1. Rule set part (= CSS2-style patterns).
2. Command part (= functions with curly brackets).

With the same rules could make with CSS the presentation to the script like in these examples:

[id="date"] {background-color:yellow; border: 1px solid #660033;}
div script {background-color:yellow; border: 1px solid #660033;}

Because CSS calls definitions, which are inside curly brackets ({...}) as declarations, the same term could be used also in script sheets instead of writing about function bodies. If there is need of nested curly brackets, they are called both at the the same name (block or group).

In XML-documents should not according to CSS2 specifications use this kinds of patters "DIV.class {...}" it should in my mind not use in my proposal neither in script sheets. In fact this should also be rejected "*.#date{...}" and use only [id="date"] {...} style definitions. According to my proposal only part of CSS2 level matching patterns should be used with script sheets:

• These could come from CSS2:
  • Universal selector ( this might be in practice only a theoretical pattern, because there might be no sense to use it with scripts; But it is in this list because it is a part of the whole system and it might be needed)
  • Element type selectors like a function func(){...}
  • Attribute selectors like [target="new"] function func(){...}
  • Adjacent sibling selector like ol+ul function func(){...}
  • First-child selector like ul >li function func(){...}
  • (Link pseudo-classes and dynamic pseudo-classes)
• Some new pseudo-classes, which I have made proposals for CSS3.
• New pseudo-classes into scripts:
  • Some behavioral extensions to pseudo-classes
• Combinations of all of previous patterns like td :onmouseover [target="new"] function func(){...}
• !important (this is problematic, because in CSS it is used inside declarations, which doesn't fit to scripts - it should be used outside curly brackets)

The cascading-principle mean in the case of script sheets primary the cascading order. Pattern matching creates always priority-systems. And the interpreter should examine before doing anything, which have the highest priority. If there is definition, which have the same priority, the last would be used.

There might be useful to give the possibility to use the import rule to create easily exchangeable variations.

Media rules with scripts

CSS2 has media rules to make from the same page different versions to various devices. This could be also applied to scripts using media rule of CSS. The there would not be scripts in the WAP (media handheld or tty) version or the page!

The media rule is primary used with the media attribute (for example media="screen"), but also by using other methods of CSS2. (Read about them.)

New syntax proposals

My proposal needs next generation script syntax and then it is reasonable to use new link relation to it, which could be the same kind of to the style sheet and it could use the element LINK and the file extension *.ess. The document would not need any scripts - only these two link relations and the script would work in normal computer and portable handheld devices. This is the first step in my proposal:

<LINK rel="scriptsheet" type="text/js" Language="ecmascript" media="handheld, tty" href="script_sheet_handheld.ess">
<LINK rel="scriptsheet" type="text/js" Language="ecmascript" media="screen" href="script_sheet_screen.ess">

Browsers could read also the old generation script, which are defined with the element SCRIPT, but this element could have also the next generation embedded script sheets. Because the script could be written also with some other language than script and the language attribute should be always mentioned.

I read about Ecma standardard 5.1.4 The syntactic grammar, where I read:

Productions of the syntactic grammar are distinguished by having just one colon ":" as punctuation.

This is in my mind just, what I mean. JavaScript has many kind of property syntaxes, but in my mind all property syntaxes should be like in CSS. This seems to be done in ecmascript, but I'm not totally sure. Here is three examples of different syntaxes in JavaScript 1.1.:

In my mind all stylistic properties should be CSS like properties, because then the whole system could be clearer. For the sake of compatibility, browsers could support also old-fashioned syntaxes. I recommend however to replace HTML 3.2 like properties with CSS like properties. Scripts can have properties, which have not any value. But then they can be mixed to methods. The default value could be for example normal.

Advances of my proposal

I have got an e-mail, where the writer was skeptical. He admit that re-using the selecting mechanism of CSS in order to simplify javascript code is an interesting idea - just this matter is the aim of my proposal.

Today the way to use scripts is old-fashioned compared to CSS and XSL - but it could be performed using the pattern matching. I want some comments about this proposal, which cause at least following advances:

• Easier to control large sites.
• When style sheets and script sheets could use same kind of syntaxes, they would be easy to remember.
• No problems with old browsers, because there is no need of a use script inside documents at all
• Simple and systematic basic scripting system
• If they would have, they could be taken off in WAP-devises like style sheet properties and there could be different versions of script sheets into computers and portable devices.

Relation to other proposals

I got information from W3C, that my proposal is reminiscent of the JSSS proposal that Netscape made years ago (1996). I have a little discussed about JSSS (JavaScript Based Style Sheets) proposal of Netscape, which is script base system of handling styles. In that mean JSSS in can't be seen as an early predecessor of my proposal. That proposal base on applying scripts with style sheets. My proposal bases on using CSS2 level pattern matching rules and CSS2 level media rules with scripts. This is not extensions to BECSS, but BECSS + CESS could be in my mind very powerful combination. It is also a need to think the relation of my proposals to DOM 2.0.

Look at also a list of other proposals.