[Top]
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.
 
 
Search:
[Help]
To the normal page

E What kind of non-standard (proprietary) CSS browsers support

Common

What kind of non-standard (proprietary) CSS browsers support must look from different points of views:

  1. Proprietary CSS can be designed only for the internal usage of the browser, when CSS-files defines any kinds of default settings (preferences) of the browser. These kinds of style sheets are UA style sheets (UA CSS, UA = User Agent = any application, which use style sheets to define its preferences).
  2. It can be designed especially for define the interface of the browser, when it is UI CSS (UI = User Interface). This kind of CSS can be UA CSS, or document CSS (I handle these points of views shortly in the page 5[S]). I doesn't normally affect to presentation of the actual page, but it concerns rather just the interface, like the color of the scroll bars, mouse cursor etc.
  3. It can concern the presentation of the document itself.
  4. It can be designed for the Web-author. This kind of CSS can concern both the document and the interface.
  5. It can harmless to browsers, which don't support it. It can be also serious harmful for browsers, which can't interpret it.

The usage of What kind of non-standard (proprietary) CSS browsers support should be avoided in common Web pages. It can be a little bit used, but using proprietary CSS in my mind should be used following "moral principles":

Between standard and What kind of non-standard (proprietary) CSS browsers support are implementations of working draft level proposals for CSS3. W3C recommends to use non-finished specification only in special test pages. The usage of them should be limit only to intranet solutions. MS IE supports them most. Also Netscape 6.x supports a little unfinished CSS3 proposals. I don't handle them in this page just at all. I made however a list of proprietary and proposed CSS-features, which I have found (or I have read) to be supported in MS IE 5.5, Netscape 6.1 and Opera 5.12.

Note 1. The disadvantage of proprietary CSS is that the official CSS validator of W3C tells that the CSS is invalid. In order to avoid this problem, it is reasonable to define proprietary CSS in own CSS-files. With some script can be done a function, which finds the special CSS-file only for the use of certain browser. Indeed this doesn't help users of Opera, because they can choose, how they identify their browsers. A CSS-file, which have proprietary CSS, might always cause problems for some users of Opera.

Note 2. If special feature of MS IE are used, it could be find, if also such features, which work only in new Netscape/Mozilla and Opera are also used. They support much such standard CSS2 features, which are not supported in MS IE but which make browsing with previous mentioned browsers especially comfortable. Properly designed these features don't cause any harm to browsers, which don't support them. I have use one proprietary feature of MS IE but much more such features, which works only in Opera and new Netscape/Mozilla browsers. I have not in any connection tried in purpose to make harm to visitors, which use MS IE (I have however in purpose made this site so, that it doesn't work optimal in the Netscape 4.x series).

[Top]

UA and UI CSS

Topics

UA CSS in Mozilla Gecko browsers

Browsers after Netscape 4.x have much UA CSS. In concerns both the interface and the presentation of documents. Netscape (and evaluation version of it like Mozilla) are in my mind first browsers, which use UA CSS at the way, which is explained in the CSS2 specification - defining the default presentation of (X)HTML elements. Default setting are stored in /res/html.css, /res/forms.css and /res/quirk.css CSS-files (/ = the base directory of Netsape/Mozilla).

The used CSS is primary standard CSS2. In my mind the most inconvenient feature in the UA CSS files is, that part of the UA CSS is defined by using the keyword !important. Then Web-authors can wonder, why some defined CSS don't work. Below is a piece of code from the file html.css:


frameset {
display: block ! important;
overflow: hidden;
}
...
iframe {
background-color: transparent ! important; /* (b=49779) */
border: 2px inset;
}

What kind of non-standard (proprietary) CSS browsers support in UA CSS files is absolutely ok, because it is for the internal usage of the browser. But "teasing" authors by using the keyword !important is in my mind inappropriate. It can't be assumed, that authors could understand to use the same keyword to override default settings, which are defined in UA CSS files!. In addition there is a small inconvenient feature in the UA CSS. Some standard CSS2 property values to the element LI are defined so, that default property values of that element are different as W3C has been recommend.

Indeed concerning the /res/quirk.css the usage of the important rule is ok, because the purpose is to emulate with certain DTD the buggy behaviors of the Netscape 4.x series. In this case is also correct to use proprietary CSS in order to cause non-standard behaviors.

The existence of UA CSS and proper usage of it could be possible mentioned? I don't have found information about the UA CSS, which new Netscape/Mozilla browsers use.

[Top]

UA CSS in Opera 4.x+ browsers

Like Netscape/Mozilla Opera 4.x+ doesn't use an external UA CSS file in order to define the default settings of (X)HTML elements. Indeed according to an e-mail Opera does have a default UA CSS-file, which is built into the browser, but not available as an external UA CSS-file in some folder of Opera.

Instead it use external CSS-files in order to define default settings for other other file types and special implementations like rendering WML 1.x documents. UA CSS files are stored in Opera 5.1x to the sub-folder Styles (in Opera 4.x in the root directory of Opera). Concerning WML the purpose of What kind of non-standard (proprietary) CSS browsers support is to define the presentation of the element card by using position:deck, make linking to work and show used images (the property -replace()). To use proprietary CSS for this purpose is fully acceptable.

I have written a letter to Opera Software because it doesn't inform, that the proprietary CSS is especially designed as UA CSS. According to the Web-site of Opera Software the What kind of non-standard (proprietary) CSS browsers support: can be used - even if it is not recommendable - to use in XML-documents to get linking to work. (concerning Opera 5.x the proprietory CSS is exactly the same CSS, which Opera use in UI CSS files; Opera 4.x use a little bit different proprietory CSS in UA CSS files as Opera Software once informed in the Web-site).

This CSS is useful for example in a situation, where for Netscape 6.x has been done *.xml documents, which use the XLink linking language, which is supported in Netscape but not in Opera. In order to get the linking to work at least partial in Opera, it is necessary to add to the CSS-file the same CSS, which is primary intended as UI CSS for Opera.

Hopefully Opera supports one day also standard XML linking systems in order to get rid of using propriety CSS in XML-documents. Then the What kind of non-standard (proprietary) CSS browsers support could be used only as UI CSS.

It could be also fair, if Opera Software could announce, that Opera 5.x use proprietary UI CSS (it is not necessary list, which files and how they use it). The company could also tell, that What kind of non-standard (proprietary) CSS browsers support should be be used only in intranet solution, where all people use Opera as the default browser.

Opera Software: Web specifications supported in Opera 5 - the details.
[Top]

UI CSS

As I have been already mentioned, the proprietary CSS in Opera and new Netscape/Mozilla is not (at least primary) intended for the Internet use. The What kind of non-standard (proprietary) CSS browsers support for MS IE is in principle level different as the proprietary CSS in Opera and Netscape/Mozilla because it is designed especially for Web-authors. The final purpose is is that Web-sites could work properly only in MS IE browsers. This aim violates the basic principles of the WWW and the Internet because WWW is intended as global net community, which use common agreed standards.

The proprietary CSS in MS IE concerns much UI CSS, for example defining the color of scroll bars (for example scrollbar-base-color: #603;). In principle non-standard UI CSS is such CSS, which belongs to UI CSS, when the user could define the presentation of his own browser. Using proprietary UI CSS in common Web-sites is in basic level a little bit questionable. But defining color of scroll bars doesn't cause any harm to other browsers. That's why I have used it in the "link books". Because CSS2 has some UI CSS, the fact that Microsoft calls them as extensions is in this connection appropriate.

Even if proprietary UI CSS belongs in principle among UA CSS, I don't resist the usage of such non-standard UI CSS, which doesn't cause harm to other browsers. Browser designers could even fairly compete, which browser helps visitors to understand better the content of Web-pages without causing any harm to other browser, which also visit in the same pages.

The UI CSS of Opera doesn't have UI CSS features. The proprietary UI CSS of new Netscape/Mozilla includes some UI CSS features. Netscape 6.x doesn't support the outline property, but it has non-standard proprietary properties, which make the same task. In principle they could be used in common Web-sites even if it is not recommendable. Because Netscape/Mozilla doesn't tell about this possibility, it might be impolite to use those properties.

[Top]

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]

DTD-switches

In a way proprietary features are such features, which belong to the specifications, but implementations broke in purpose existing specifications. New MS IE and Netscape/ Mozilla browsers use DTD-switches, when with certain without DTD or with certain DTD new browsers work in some matters at the same way as older and more buggy browsers. Newer browsers support overall better CSS and HTML specifications and they are designed to work in certain modes better according to the CSS and (X)HTML specifications than in another mode.

Netscape/ Mozilla calls the better mode as the standard mode/ strict mode. The opposite is the quirks mode.

Microsoft calls the better mode as the standard-compliant mode, when the other mode is just the mode, where the standard-compliant mode has not been turned on. The "switching mechanism" is in MS IE 6.0 for Windows, MS IE 5.0 for Mac, Netscape 6.x/ corresponding Mozilla and Opera 7.x+ browsers.

In fact Opera 7.5x and newest Netscape/Mozilla browsers have a third mode (the Almost Standards mode).

Activating the Right Layout Mode Using the Doctype Declaration.

Maybe the most remarkable effect is in MS IE browsers, where the switch affects calculating width and height properties in MS IE browsers. The system works quite well except calculating the width property in tables. In MS IE 5.0 for Mac the DTD-switch affects also to the width attribute of the TABLE element. MS IE 5.0 for Mac handles in the standard-compliant mode the width attribute like the corresponding property, which is an error at the sight of HTML (I handle these matters also in the page 10[S]). In Mozilla Gecko and Opera 7.5x browser the standard and almost-standard mode differs each others when calculating the width of the table.

The switch cause also in MS IE into proprietary CSS. MS IE doesn't accept for example scroll bar properties in the standard-compliant mode. That's why pages, which are inside IFRAME and which have colored scroll bars, use DTD, which doesn't switch the standard-compliant mode on. Other pages work in new MS IE and Netscape/Mozilla according to strict/ standard-compliant modes.

I have found some differences and I have read from web pages about them. I found also that Netscape/ Mozilla defines non-standard behavior by using the quirk.css and a part of the information base also on that UA CSS file (differences, which are caused with this CSS-file are not general necessary to test). I have got also information through e-mails. The table below is not complete, but it mentions some possible differences (because I have not personally tested all listed matter, the table might have errors and I need help to get it better and the table doesn't make difference between the standard and almost-standard modes):

MS IE 6.0 for Windows MS IE 5.0 for Mac Netscape 6.2.1Opera 7.x
The first element inside BODY and TD elements have different top margins (concerning TD also the bottom margins of the last elements are different) if they are not set with CSS. Yes (UA CSS)
width and height properties for generic block-level elements. Yes Yes
The width property for the TABLE element. Yes (Maybe)
The width property for TD and TH elements together with table-layout:fixed. Yes Yes
The need of display:inline-block for ordinary inline level elements together with width and height properties. Yes
Applying CSS for the HR element. Yes (UA CSS)
Different font size handling inside heading elements (H1 etc.). Yes (prop. UA CSS)
Different wrapping of the PRE element. Yes (prop. UA CSS)
The presentation of list elements is different. Yes (UA CSS)
Different display type for the MAP element. Yes (UA CSS)
Different margin for the IMG element, if the image has the align="left" or align:right attribute. Yes (UA CSS)
Different handing of percentage heights on images and tables. Yes
Background properties for table elements. Yes (UA CSS)
Inheritance for most text related properties works/doesn't work for TABLE and CAPTION elements (font-size, font-weight, font-style, font-variant and for the element TABLE text-align). Yes (partially prop. UA CSS)
When tables have a border style of inset or outset, the border color is based on the background color of the table or of the nearest ancestor with non-transparent background. Yes (needs tests)
The empty-cells property defaults to hide/ show empty cells. Yes (UA CSS)
Table cells with a border have a minimum width of one pixel. Yes (needs tests)
The basic table layout strategy ignores/accepts paddings. Yes (needs tests)
Floated tables never move/ move to the next "line" if they don't fit next to other floats (if they don't move to the next line they just keep widening the page). Yes (needs tests)
Slightly different default presentation for INPUT elements. Yes (UA CSS)
Browsers render font-size:xx-small - font-size:xx-large differently (look at Model8c.html[S]). Yes Yes
The CSS parser accepts invalid names of id and class selectors. Yes
The CSS parser reads @import even if it is not on the top of the style sheet. Yes
The CSS parser accepts hexadecimal colors not beginning with #. Yes Yes
The CSS parser interprets unitless numbers as px (concerning Netscape browsers except for the font-size property because Netscape 4.x did according to the specifications; in general this matter doesn't concern the line-height property and any other properties where numeric values have distinct meaning). Yes (but a buggy fixing) Yes
Accepting of proprietary CSS. Yes

Notes:

  1. Netscape/ Mozilla has also some HTML element and attribute related matters, which can't change with CSS. I have tried to list such default settings, which can change equal with CSS (in most cases the behavior can set equal with standard CSS but in some cases changes might need proprietary CSS, which Netscape/ Mozilla use much in their UA CSS files; in principle it is possible to change with proprietary UA CSS stand behaviors into non-standard).
  2. In the site of Mozilla org. according David Baron the basic table layout strategy handles widths differently in some way and Mozilla browsers. Because I didn't find any differences I put that matter into parenthesis. In principle Netscape/ Mozilla and MS IE 6.0 should have different handling of the width property with the TABLE element in the standard(-compliant) mode.
  3. David says also, that Mozilla browsers have a minimal difference handling xx-small-xx-small values. I didn't find any difference in handling font-size:xx-small - font-size:xx-large. That's why I don't mention about any difference in this matter. The effect might be different in different versions and Netscape 6.2.1 just doesn't have this difference.
  4. According to David the behavior of certain form control elements in Netscape/ Mozilla can alter also with some JavaScript encoding but I have tried to list only such features, which can be changed only by altering the DTD of the document.
  5. I have listed some details also in the extra page, which handles CSS-implementation errors of MS IE browsers[S].
  6. The switching point, where standard(-compliant) mode is on, is different in MS IE and Netscape/Mozilla browsers. In Netscape/ Mozilla browsers the strict mode starts from HTML 4.0 Strict or HTML 4.01 Transitional document types. In MS IE the standard-compliant mode starts from the HTML 4.0 Transitional document type, if the URL ("http://www.w3.org/TR/REC-html40/loose.dtd") has been given. If the URL has not been given standard-compliant mode starts from the HTML 4.0 Strict document type.
  7. The DTD-declaration must be on the top of the page without anything before it. I had in the CSS-site in some pages before it a comment, when MS IE understood XHTML 1.0 Transitional documents so that the standard-compliant mode was off.
Microsoft: CSS Enhancements in Internet Explorer 6 Public Preview; The Mozilla org.: Mozilla Quirks Mode Behavior.

[Top]

Details

I handle non-standard and proposed features for CSS3 in in CSS-tables and notes for them (Table 1[S] Table 2[S] Notes 1[S] Notes 2[S]). In addition of listed proprietary CSS, according to some e-mails Netscape/Mozilla use much more proprietary CSS than I have listed. I don't however list such CSS extensions, which are not used in files (/res/html.css, /res/forms.css and /res/quirk.css), which defines presentations for (X)HTML elements.

Below is a list of mentioned proprietary and CSS3 proposed features according to the order, which they have in the previous mentioned pages:

In addition I mention in the page, which handles JavaScript tricks[S] using of the value expression.

[Top]

Software-specific encoding

Topics

Common

In addition that browsers support nonstandard CSS or markup up tags, some editing software support nonstandard features. Some of them might be supported by some browsers but at least a part of the encoding is only for the internal usage of the software itself.

I handle two cases. The first is related both with HTML and CSS encoding. The latter concerns just HTML-encoding and at that mean it goes over the topic of this page. In some respects it however resembles the first case. Because of the quite small meaning I don't handle the latter case in a separate extra page. I a little bit compare these two cases.

MSHTML and "FPHTML"

Microsoft writes about MSHTML. MS Office 2000 applications creates it. In addition of ordinary HTML markup MSHTML has also so-called XML data islands (<xml> ... </xml>) and proprietary CSS for Office-applications (in many cases the proprietary CSS use the prefix -mso- like Mozilla Gecko browsers use the -moz- prefix). The aim of the proprietary encoding seems to to maintain better original formatting than using standard HTML when Web-documents has been converted back to the original file formats like Word 2000 and Exel 2000 documents.

The MSHTML of MS Office 2000 was in fact the proposal of Microsoft for the HTML 5.0 specification but it was rejected. It was however discussed with in W3C.

W3C: XML in HTML Meeting Report (W3C Note 11 May 1998).

The way how MS Office 2000 combines HTML and XML is today totally nonstandard. If the document use XML, the whole document must be valid XML, not only data islands. MS Office XP creates the same kind of MSHTML, which doesn't fulfil formally the requirements of XML.

Word for Office 11 supports at some way XHTML through the InfoPath application.

Cover Pages: Microsoft Office 11 and InfoPath [XDocs]; InfoWorld: Exploring XML in Office 11.

MS IE 5.x+ might understand a part of the MSHTML but not everything. The way how Microsoft thinks software designing can be seen in the fact that MS IE doesn't support properly the paged media (paged media handles page margins and page breaks in printing). But when MSHTML has been imported into Word 2000 and printed with Word page breaks work better than in MS IE because of the proprietary CSS for MS Office applications. MSHTML-documents have been intended to print with MS Office applications.

MSHTML has very much encoding which is only for the internal usage MS Office applications. I removed once half of the MSHTML created by Word 2000. If I take account that the code had text approximately about 70-80% of the total quantity of markup codes and CSS definitions was special MSHTML.

MSHTML stress unnecessary Web-servers by feeding unnecessary encoding into the Internet. If with Office application has been created MSHTML and the final product has been sent into Internet, Internet has been used as if an intranet of Microsoft products. In my mind MSHTML doesn't belong into the Internet but only into some intranet solutions. According to an e-mail there are applications, which convert MSHTML into ordinary HTML, at leastMicrosoft Office HTML Filter 2.0.

Microsoft: Microsoft Office HTML Filter 2.0.

Word 97 tries to create almost standard HTML. If special formatting (for example bold or italic text) has been used the result is in most cases invalid but relative easy to fix with some HTML editor, which creates valid HTML and which can HTML-encoding errors.

Because it is not possible to create directly with any Office product valid XHTML instead of using some Office product (X)HTML for the Internet should create with valid (X)HTML editor. FrontPage 2000 is not a proper HTML-editor because it use a Windows character set and doesn't encode special characters at the way how they should be encoded in the Internet usage (for example "ä" should be encoded &auml; etc.), when the text can't be read correctly with Mac browsers. According to an e-main FP 2002 support relative well character entities.

At least some versions of FrontPage work also in some other respects. I found the following encoding from a Web-page:

<style fprolloverstyle>
A:hover {color: red; font-weight: bold}
</style>

That creates an ordinary a:hover effect. The fprolloverstyleattribute is completely unnecessary "FPHTML" encoding. That attribute is not for some browser because the information is relevant only for the editor. That kind of information should be inside comments. The code lacks type="text/css", which should set in valid code for the STYLE element. Mentioning of a certain style could be expressed with a standard way for example at the way below:

<!-- fprolloverstyle -->
<style type="text/css">
A:hover {color: red; font-weight: bold;}
</style>

In general informative encoding is not harmful for any browser but it is just inappropriate encoding. It is worth to remark that fprolloverstyle doesn't use at the sight of HTML 4.01 a valid attribute syntax. Some old HTML-specifications support compact attributes like <DL compact> but starting from HTML 4.x the syntax should be always attribute="value" (quotes are not always necessary). The format <style fpstyle="rolloverstyle"> would me at some level appropriate. In the pages, which had that attribute Mozilla 0.9 rendered the first page incorrectly. Presumably new Mozilla browsers get randomly confused the ending point to the end-tag. The seem to require two part. Indeed when I visited second time in that page I didn't had that problem. The problem might be related with some other issue..

I can't however recommend to use any HTML-editor of Microsoft's, which is older than FrontPage 2002. With the newest FrontPage and Macromedia Dreamweaver can create XHTML and those editors can regard as recommendable WYSIWYG editors. I have used HTML-Kit, which can be created standard HTML 4.0/HTML 4.01 or XHTML 1.0.

Adobe GoLive

At the same way Adobe GoLive creates editor specific encoding. The main difference is just that only products of Adobe understand the code and no parts of it is for browsers. I mention Adobe's codes[S] in a note page.

I have found some Web-pages created by Adobe GoLive, which had approximately encoding, which was unnecessary for browsers - the quantity of the unnecessary code for the Internet is about as big as in the MSHTML of MS Office applications. It would be smart if product of Adobe would have an option to remove editor-specific encoding before pages has been sent into the Internet. I don't regard editors of Adobe as appropriate editors.

Is there any application, which can remove the unnecessary Adobe GoLive specific encoding and create from nonstandard markup language of Adobe ordinary HTML or XHTML?

[Top]
[Top]