More advice for the full screen mode.
I list below all topic groups, which I have done according to subjects, which they handle. You can return to this topic group by using this menu and the link Table of topic groups on the top of the each page.

Cascading Script Sheets



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();
b_ankkuri[i]= new Image();
b_ankkuri[i].src=Nimi[i]+"b.gif"; }
var browser=false;
// -->

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

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

In the script attributes are references to functions like this:

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

There are two common features:

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[S][Pw]), 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:

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[S][Pw] - 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):

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:


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">
// --></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:

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.

W3C: BECSS: event properties.

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[S].)

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.:

document.lastModified => document.lastModified: normal; /* a property without any spesific value*/
document.bgColor= 'white' => background-color: yellow; /* this is a HTML 3.2 attribute like property */
location.host: port => location.host: port; /* this is a CSS like property */

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:

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[S].