[Top]
More advice for the full screen mode.
   
Sivut toimivat riittävän hyvin MS IE 4.0+, Opera 5.x+, Netscape 6.0+/ vast. Mozilla ja Konqueror 3.x selaimilla. Yleisesti ottaen sivut toimivat parhaiten uusimmilla Opera selaimilla. Sivujen toimivuus vanhemmissa selaimissa on heikko, erityisesti Netscape 4.x kohdalla.

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.
 
 
Search:
[Help]

Harmfulness of proprietary CSS

The the syntax of What kind of non-standard (proprietary) CSS browsers support in Opera and Netscape/Mozilla is according to CSS". The only matter, which is different, is that some property and pseudo-class selector names start at hyphen (for example in Opera -replace and in Netscape :-moz-dummy-option). Even if somebody puts among standard CSS2 What kind of non-standard (proprietary) CSS browsers support of Opera or Netscape, it doesn't cause any syntax problems for MS IE or presumably for some other application, which understand CSS. Using such Netscape/Mozilla specific CSS, which concerns the presentation of documents, it just cause that for example forms are rendered differently as in other browsers. Differences are not however drastic and presentation differences don't cause serious functionality problems. In fact properties, which use the -moz- prefix are not (or at least most of the are not) non-standard properties but experimental CSS3-implementations. Because the final CSS3 specification might define them differently as working drafts Mozilla Gecko browsers don't support them without the prefix.

Most of the proprietary CSS in MS IE is not harmful for other browsers. One of my e-mail friends send me an example of CSS, where some CSS was defined for the element H1. One line was MS IE specific CSS. That line caused Opera to ignore the whole declaration block for the element H1. Below is fragments of the original code, which I got from an e-mail:

h1 {
font-variant : small-caps;
font-size : 20pt;
...
margin-bottom : 1em;
color : #005a9c;
background : transparent;
/* below is the MS IE specific CSS */
filter: progid:DXImageTransform.Microsoft.DropShadow (color: '#C0C0C0', offX=3, offY=2); }

In principle Opera should be able to pass at least part of the encoding, which is written only for MS IE because of they should notice future specifications (the forward compatible parsing principle). Partially Opera can do this, but not in all respects. In the example above is so much features, which don't belong to CSS2, that Opera can't survive it. I examined, what matters are against CSS2 and what caused the fact that Opera ignored the whole declaration-block. I changed the original code first into the format filter:progidDXImageTransformMicrosoftDropShadow(color: '#C0C0C0', offX=3, offY=2), which Opera can pass. After that I changed it. The result was following:

  1. First filter:progid: is according to CSS2 specification invalid, because the double dot (:) should be used in CSS immediately after the name of the property (white space is however allowed) and property values should terminate to semicolon (filter:progid;). This matter didn't cause the problem in Opera and it can pass this kind of syntax, which is against CSS2. The browser must be aware, that future specifications might have property values like progid:... or properties use the format property:sub-property: (subordinated properties).
  2. Property values use dots in DXImageTransform.Microsoft.DropShadow. This is a decisive matter. These kinds of syntaxes might be added to CSS3. The basic idea of forward-compatible parsing is that the browser could skip properties, which might become into future specifications. The property starts according to CSS2 by using syntax property:value. If Opera finds unknown values, in my mind Opera should try to find the termination of the property, either ; or }. Now Opera can't find the termination of the block, it ignores the whole declaration-block. In my mind, Opera should not skip the whole declaration-block, but just the property filter. In other hands Opera interprets presumably DXImageTransform.Microsoft.DropShadow as a selector, when the declaration block should be terminated with curly brackets (}) either before or after DXImageTransform. The rest part of the code should then belong to a new declaration-block. Because the declaration-block is not broken at the place, where Opera expects, it can't terminate the block. If Opera interprets at this it behaves ok ignoring the whole declaration-block (not only the property filter). Opera Software just have not taking account that any future specification can have dots in property values. The presumably logic of Opera as a code example:
    progid:}
    DXImageTransform.Microsoft.DropShadow
    /* after this code should be a new declaration-block, which start at open curly bracket ({) */
    or
    progid:DXImageTransform}
    .Microsoft.DropShadow
  3. Before a CSS-function is a space (DropShadow (color...)). A space in property values means that a single property ends and after the space is a new property value, which belongs to the same value set. According to the CSS2 syntax the browser should understand DXImageTransform.Microsoft.DropShadow and (color:...) to be two values of the same property. This is not however allowed because the syntax value() in CSS2 a CSS-function, which must write together. According to my logic the syntax of the value, which only MS IE understands should be DropShadow(color...). This is a decisive matter. I believe that CSS3 can't tolerate this kind of syntax because the common habit in computer languages is to write functions and arguments, which are inside normal brackets together (in addition of CSS for example JavaScript encoding follows this principle). In my mind in this case MS IE is too tolerable, "kind" toward syntax errors. Because of the syntax error Opera could determine, where the declaration block ends, it ignored the whole declaration-block.
  4. Another property is a value of the first property ((color: '#C0C0C0', offX=3, offY=2)). This has no effect and into CSS3 will become these kinds of features. Opera 5.x and other CSS1-CSS2 supporting browsers should be able to parse.

Partially the problem is in Opera, because it can't skip syntax errors in unknown properties (this is fixed versions, which are newer than 5.12). I made a test page[S], which demonstrates problems 2 and 3. Mozilla 0.9 can render it correctly like Opera 6.0 Beta 1 for Windows.

The author of the code, which I have used as an example wrote to me 28.09.2001 that he had error in DropShadow(color...) and it should be DropShadow(color...). According to an e-mail MS IE 6.0 accepts a space, but it is bad matter, because browsers should skip properties, which use invalid syntaxes and read the next valid property or the termination of a declaration-block. If browsers accept syntax error it cause validating problems.

In this case the encoding might in principle conform with some CSS3 proposal and the following encoding might be valid CSS3 property syntax:

filter: progid:DXImageTransform.Microsoft.DropShadow(color: '#C0C0C0', offX=3, offY=2)

That kind of syntax has not however proposed to any CSS3-proposals. The only proposal, which supports the property filter is SVG (Scalable Vector Graphics). It is a special language and the property filter doesn't belong to common used proposed CSS3-properties. In SVG the proposed syntax is quite different as in MS IE.

W3C: W3C Specification - Scalable Vector Graphics (SVG) 1.0 (Candidate Recommendation 20000802).

In fact the property filter is a proprietary property even if Microsoft gives in its WWW-sites incorrect impression, that MS IE uses the property filter according to a CSS3 proposal. Microsoft explains the usage of the property filterat the following way (I added to the text some emphasizing):

Filters often create effects that can be generated with script. This raises the question, "Why use filters if script can do the job?" There are several reasons for using filters. The most important is because they don't require script. For better or worse, many HTML authors do not use scripting. Filters are a convenient package for the same functionality that scripting provides. Another benefit of filters is that they are easier to author and can be applied to entire classes of elements, because they use the declarative and inherited syntax of CSS.

Filters and transitions display properly only on systems that have the color palette set to display 256 colors or more.

Almost any object can have filters applied to it. However, the object that the filter is applied to must have layout before the filter effect will display. Put simply having layout means that an object has a defined height and width. Some objects, like form controls, have layout by default. All other filterable objects gain layout by setting the height or width property, setting the position property to absolute, or setting the contentEditable property to true.

MS IE supports however really such properties, which are proposed for CSS3. As such it is good to have experimental level implementations - but common Web-sites are wrong places to test them! Because Microsoft recommends to use half-made specifications in the Internet, it breaks recommendations of W3C, where to use working draft -level specifications.

In general encodings, which might be harmful for other browsers are misuse of dominant position in the software markets. Everybody knows, that the purpose of Microsoft is to create total monopoly state in browser markets. Some means are supporting of proprietary and half-made specifications. By using them MS use "browser dominance terrorism"! If using of half made specification cause clear problems to other browsers, they should not be used in the Internet. At this point of view using of harmful encoding in the Internet used documents is supporting of the browser dominance terrorism of MS! I hope that all readers of this page could read "moral principles", which I have done.

[Top]