Previous page

Sections of page:

Next page

6. Help for HTML ALL menu

Common

I have tables and a plug-ins menu, which list HTML (Hyper Text M arkup Language) elements and attributes from first HTML versions to XHTML 1.1. This page is a help page both to the plug-ins menu and tables.

I read about the history of first HTML-documents from the HTML Home Page of W3C. You can find HTML-history also from Brian Wilson's (Blooberry) Index DOT Html and Tag Library of Z-net (most of the Tag Library is written by Brian Wilson, but the Tag Library is a shortened version and it has many crucial holes; I recommend to read the Index DOT Html instead).

Document types

The history of HTML doesn't know at all HTML 1.0, because first internet document don't have an official specification or a DTD (Document Type Definition) file. Indeed Dan Connolly made a DTD for HTML in 1992 HTML-documents from the year 1992 are draft documents and I call these documents as pre-HTML. The element table to pre-HTML base on elements, which are in the DTD of Dan and which are used in the directory, which handles first HTML documents. All version of HTML from the draft of Dan Connolly to HTML 4.01 base on SGML (S tandard Generalized M arkup Language).

First Internet documents have few elements and attributes to describe the structure of the document. In addition to structural elements, some elements were semantic (for example STRONG) and in the DTD of Dan was not at all presentational element, but in W3C has used B and I in the site, which handles first Internet documents (they can be understood also partial semantic). Fist Intenet documents didn't have images and font definitions, because documents should be platform independent:

It is required that HTML be a common language between all platforms. This implies no device-specific markup, or anything which requires control over fonts or colors, for example. This is in keeping with the SGML ideal.

The HTML 2.0 (1994-1996) has the first official document type definition file. It has even full (html.dtd) and strict (html-s.dtd) versions of DTD. It can be regarded as proper base on future versions of HTML. HTML 2.0 documents were still relatively simple, but they had the ability to use images. I have much pages, which element structure is in the BODY-part of the document almost like in HTML 2.0 documents.

Next widely used HTML version is HTML 3.2 has not a wide specification. This document type has only extensions to HTML 2.0 as we can see from the this cite:

HTML 3.2 adds widely deployed features such as tables, applets and text flow around images, while providing full backwards compatibility with the existing standard HTML 2.0.

HTML 3.2 (1996-1997) doesn't brought basic level new designing model. Indeed many authors have evaluated the document structure upon complex multilevel nested tables. In my mind this is misuse of tables and an artificial, unnatural "new designing model" after HTML 2.0. I have some pages, which are done at this way, because I don't thought designing very deeply. If table are not nested and the structure remains relative simple, the basic structure is reasonable build on tables. In strictly thought this is also misuse of table elements (they are originally intended to render tabular data, not be the base of the whole structure of the page). If we tolerate some level misuse of elements, HTML 3.2 brought an alternative structure and layout model after HTML 2.0 (HTML 3.2 is however not a really layout language).

HTML 3.2 was only an intermediate document type and intended only as a temporary solution, which should be replaced with a better designing model. This fact can be seen studying the HTML 3.0 Draft from 1995. The draft base on the work of Dave Raggett from 1993. HTML 3.0 has many attributes, which are neither in HTML 2.0 nor in HTML 3.2, but which are core and internationalization attributes in HTML 4.01 and XHTML 1.0.

According to the draft, the presentation could be done with style sheets. In HTML 3.0 the original idea to use style sheets was a light version of DSSSL (Document S tyle S emantics and S pecification Language, but this aim never fulfilled. DSSSL might be today in practise a theoretical solution (the HTML 3.0 Draft reserved also the possibility to use some other style sheet language). CSS replaced DSSSL in HTML documents. Even if CSS1 () released 17 December 1996, HTML 3.2 just reserved the element STYLE in order to use in the future as a placeholder for style info. Browsers designers were not ready to use widely CSS, which means that the usage of HTML 3.2 almost totally destroyed the original idea of HTML, because it added much presentational elements and attributes!

The HTML 3.0 Draft had much future oriented proposals: supporting of style sheets (including printed media), mathematical markup, internationalization, fixed banners (without frames) and footnotes. Some of the features are supported in the next major version of HTML, but not all. HTML 3.0 Draft just rejected even if it was a fine proposal. HTML 3.2 is not an official version of the HTML 3.0 Draft - it is far from it! HTML 3.2 is rather a bad replacement of the HTML 3.0 Draft.

Compared to HTML 3.2 the HTML 4.0 (published on 18 December 1997 and revised 24 April 1998; Last changes are made in 1999, when became the version 4.01) brought a new designing model, which base on separate the presentation from the content of the document. HTML 4.0 continued some of the main aims of the HTML 3.0 Draft and it can be regarded the descendant of the HTML 3.0 Draft rather than the HTML 3.2.

The XHTML 1.0 (2000) is the XML 1.0 (Extensible M arkup Language) version of HTML 4.01. XHTML 1.0 is today the recommendation of W3C and for example this page is a XHTML 1.0 document. HTML 4.01 and XHTML 1.0 have following common important main aims:

• Separating contents from presentation with style sheets, in this case with Cascading Style sheets (most important attributes are listed in %coreattrs;).
• Supporting of multi-lingual text including the possibility to set the text direction (attributes are listed %i18n;). This is called as Internationalization.
• Better Access for People with Disabilities by giving alternative presentation to non-visual (aural) browsers and tactile devices. This is in fact the consequence of the first principle, because CSS offers the possibility to tailor the presentation to different devices (for example to computer monitors, printers, aural browsers and tactile devices). Also separating presentation from content and structure serves this purpose, because people don't need to misuse elements trying to create artificial solutions. Documents, which are looking good on the screen, but which base on misuse of elements, might be nonsense to aural browsers.

Compared to the HTML 3.0 Draft, the usage of style sheets has been evaluated further, because in principle HTML 4.0 and XHTML 1.0 don't need those presentational attributes, which are in the HTML 3.0 Draft. To set the text direction and to support certain special medias (especially aural and tactile medias) are new compared to the HTML 3.0 Draft. HTML 3.0 Draft had however the idea of different medias, because DSSSL was intended to give alternative rendering to printers. The tactile and aural medias are just extensions of the media principle. HTML 4.01 and XHTML 1.0 don't fulfil the mathematical markup and some other features of the HTML 3.0 Draft.

The HTML 4.01 and XHTML 1.0 have two main document types, Strict and Transitional with associated DTD-files, strict.dtd and loose.dtd or transitional.dtd (XHTML).

Strict document types don't include certain presentational elements and attributes, because the presentation should be defined primary with CSS (in addition they don't include some non-presentational attributes and elements). These document types are not however really worth of the name strict. They are rather compromises between transitional types and the strict principle to express the presentation only with CSS. Strict document types have for example B and I elements and some presentational attributes to table elements. If they would have been really strict, they would not include them.

The transitional document types of HTML 4.01 and XHTML 1.0 have all elements, which belongs to HTML 3.2 except some obsolete elements.

HTML 4.01 and XHTML 1.0 have also a DTD-file for framesets (frameset.dtd), but it is not full DTD-file, because elements are listed comprehensive in the transitional DTD-file. Framesets can be understand as a sub-document type of the transitional document type.

The advance of XHTML 1.0 compared to HTML 4.01 is the fact that it gives the possibility of transformations between other XML-based languages. At this mean XHTML 1.0 brought a new designing model.

The XHTML 1.1 is a working draft. XHTML 1.1 base on the Modularization of XHTML™, which means diving the specification into smaller modules (the modularization is a framework to other XHTML version too, not only to the XHTML 1.1). XHTML 1.1 will have one basic document type and additional modules, which can be used, if necessary. The Internationalization principle is developed further.

In principle XHTML 1.1 gives the possibility to finish the main aims of the HTML 3.0 Draft, which included a proposal to support large quantity of mathematical elements. SUB and SUP are in the draft some of them. XML has the MathML 1.01 (Mathematical M arkup Language) specification. If that language is used with an additional namespace or module with XHTML, main aims of the HTML 3.0 Draft are fulfilled.

I made a "Tour" from HTML 1.0 to XHTML 1.1.

Parameter entity references and declarations

In official DTD-files is described, which is the order the correct order of elements, element behaviors and fixed, required and implied attributes. DTD-files are however quite difficult to read, because they use grouped element and attributes list, so called parameter entity references, which refer to certain parameter entity definitions (declarations). Parameter entity definitions are called also DTD macros. For example the entity reference %coreattrs; refer to the following parameter entity declaration:

DTD-macros can be nested. One parameter entity can refer to other parameter entities. I use only those DTD-macros, which are used in official DTD-files, but I don't use nested parameter entity references. I use following generic HTML 4.01 /XHTML 1.0 DTD-macros:
%i18n;, %coreattrs;, %events; and %reserved;.
Note. The HTML 3.0 Draft use also some of these DTD-macros and I use with it the entity reference %attrs; ([common +]attr[ibute]s > attrs).
%attrs; = lang, id, class. These attributes are parts of %i18n; and %coreattrs;. This DTD-macro used also in HTML 4.01 and XHTML 1.0 DTD-files, where it has wider content (it includes also %events;).

• %i18n; (i[nternationalizatio]n > i18n) = internationalization attributes to human languages. (X)HTML versions and WML support them at the following ways:
  • HTML 2.0: no support.
  • HTML 3.0 Draft: lang (look at %Language% from the Index DOT Html from Brian Wilson).
  • HTML 3.2: no support.
  • HTML 4.0: lang, dir (the direction of the language).
  • XHTML 1.0: lang, dir, xml:lang (xml:lang is the language code as per the XML 1.0 specification).
  • XHTML Basic™: xml:lang.
  • XHTML 1.1: xml:lang, dir (in the Modularization of XHTML the attribute dir needs the Bi-directional Text Module).
  • WML 1.2 and WML 2.0: xml:lang.
  Note 1. Today only MS IE 5.x supports these, but AOL has promised, that Netscape 6.x will support them also. I discussed with Opera Software, which promised to support them in future releases of Opera.
  Note 2. The classification Language attributes of Blooberry adds them the attribute language, which is MS IE specific attribute to most elements. Other browsers use it only with the element SCRIPT to express the used scripting language and I explain the usage of that attribute among %events;.

• %coreattrs; (core + attr[ibute]s > coreattrs) = core attributes. Core attributes are other generic attributes than language attributes, which can be used to almost all elements. (X)HTML versions and WML support following core attributes:
  
  • HTML 2.0: not, but the attribute title belongs to some elements, but it is not a generic attribute and then an actual core attribute. I don't count it as a core attribute to these document types.
  • HTML 3.0 Draft: id and class. The attribute class is intended to create sub-classes of elements. The attribute title belongs to some elements, but it is not a generic attribute and then an actual core attribute. I don't count it as a core attribute to this document type.
  • HTML 3.2: not, but the attribute title belongs to some elements, but it is not a generic attribute and then an actual core attribute. I don't count it as a core attribute to this document type.
  • HTML 4.01 and XHTML 1.0: class, id, style and title.
  • XHTML Basic™: class, id and title.
  • XHTML 1.1: class, id, style and title. The attribute style is in the Modularization of XHTML in the attribute collection Common (Attribute Collections) as separate attribute, which needs an own module (Style Attribute Module; I have comments to it). The collection Common corresponds in HTML 4.01 and HTML 1.0 %attrs; (= %i18n; + %coreattrs; + %events;).
  • WML 1.2: id and class.
  • WML 2.0: the same as in HTML 4.01 and XHTML 1.0.
  Note 1. The classification of Core attributes (%Core%) by Blooberry is different. MS IE 4.0+ support for example accesskey and tabindex to most elements and they are to those MS browsers core attributes. If I have listed %coreattrs;, you must check the exact contents from the Brian.
  Note 2 (title). In many cases the attribute title has no effect. If some element can have other core attributes, I have mentioned only the entity reference.
  Note 3 (style and class).
  Many browsers, which support primary HTML 3.2 support however also style and class, which are used only in the style sheet implementation (MS IE 3.02, Opera 3.51). You can look at the page Definition methods, how to use the attribute style and embedded or external style sheets.
  Note 4 (id). The attribute id gives unique identifiers to page anchors (it is alternative to the name attribute), style sheets and scripting languages. The same id attribute can be used at the same time to all of them. Each id attribute must have in the same page unique name. You must however remember following rules:
  • According to the CSS1 specification the first character can't be the underscore (_), for example id="_id_name" but according to CSS2 can. Both according to CSS1 and CSS2 the first character can't be a number, for example id="1idname" (this concerns also the attribute class). Many browsers support them more or less incorrectly (a model)
  • In JavaScript the hyphen (-) is not allowed. This doesn't work in JavaScript: id="id-name". But works in CSS. If you want to use the id attribute at the same time to JavaScript and CSS, you should avoid using underscores and not using at all hyphens (both can be used in page anchors).
  • Some browsers don't accept the usage of the element A without the content and this doesn't work: <a name="Anchor"></a> (indeed using content create problems with Netscape 4.x series if CSS is used).
  • In XHTML the attribute name can't be the only page anchor, if the purpose is that XHTML could work also in some XML-browser, which doesn't read ordinary HTML or your intention is that transformations between different XML-languages work easily. If you use in HTML-Tidy with the option convert to XHTML, the application creates automatic also the attribute id with the same value as name. Then each anchor could look like this: <a name="events" id="events"></a> ( I have comments to it in the notes of Name Identification module).
  • If you want always avoid conflicts and use readable identifiers, mix uppercase and lowercase characters (for example id="idUsage").
  • If you want to avoid all problems define also a class. An example of a anchor could look out like this:
    <a name="FirstAnchor" id="FirstAnchor" class="NoUnderline">The content.</a>.
    The needed CSS-rule is following:
    a.NoUnderline {text-decoration:none}.
    Complex? Don't blame me but browser designers and W3C! If you don't care all matters, which I have informed, leave something off as I have done! I some pages I use just the id attribute! (I know that all browsers don't support it, but the content needs anyway quite a new browser.)

• %events; ([intrinsic +]events > events) = attributes, which concerns only scripting languages: onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup.
  Note 1. Scripting languages use the element SCRIPT to embed or link scripting to external *.js files. Different scripting language (JavaScript, JScript, ECMAScript) versions support them at different level. The element might have the advisory attribute language to tell, which language and version is used (for example language="JavaScript1.2"). According to HTML 4.01 and XHTML 1.0 authors should use also the attribute type (for example type="text/javascript"). Newest versions of each languages should support all of them. Here is a list of implementations in previous versions:
  • JavaScript 1.0/ JScript 1.0 (MS IE 3.02, Netscape 2.0x): onclick, onmouseover (external *.js files are not supported).
  • JavaScript 1.1 (Netscape 3.x, Opera 3.51-3.6x): previous + onmouseout (external *.js files are supported).
  • Also some page/dependency events and form events (the classification is from Brian Wilson) belong to the official recommendations. According to HTML 4.01/ XHTML 1.0 one of them can be used also to the element AREA. Following attributes are supported in all JavaScript/JScript versions:
    Page/dependency events:
    onload, onunload (BODY | FRAMESET (tr.))
    Form + AREA events:
    onblur, onfocus (A | AREA | BUTTON | INPUT | LABEL | SELECT | TEXTAREA)
    onchange (INPUT | SELECT | TEXTAREA)
    onselect (INPUT | TEXTAREA)
    onreset, onsubmit (FORM)
    
  • Netscape 3.+ and MS Internet Explorer 4.01+ support also many page/dependency event attributes, which are not listed in the HTML 4.01 and XHTML 1.0 recommendations:
    onAbort, onError (JavaScript. 1.1, NN 3.x)
    onBeforeUnload (IE 4.01+), onMove (NN 4.x), onResize (IE 4.01+, NN 4.x), onScroll (IE 4.01+), onStop (IE 5.0) (JavaScript/JScript 1.2+)
  Note 2. All standard events are listed in XHTML 1.1 in Intrinsic Events Module. In the classification of Event handlers (%Events%) by Brian Wilson only Generic events belong under the parameter entity reference %events;. I have listed above other events, which belong to the official recommendations. Marquee Events (IE 4.01+), Editing Events (IE 5.x), Data Binding Events (IE 5.x), Misc Events (IE 5.x) are totally proprietary classifications.

• %reserved; = attributes, which are reserved for possible future use, but which are not used in HTML 4.01: datafld, dataformatas, datasrc. They are not added to new XHTML specifications. The element TABLE has datapagesize, which is added to XHTML 1.1.
  Note 1. Brian Wilson classify these attributes as %Data%, because MS IE browsers (4.x+) use attributes, which belong to this classification. I don't however exchange the the name of the original classification, because my intention is that the reader of my table could find the same parameter entity references from the HTML 4.01 and XHTML 1.0 DTD-files. Because reserved attributes (except the attribute datapagesize) are not used in future specifications, I regard supporting of them proprietary.

Elements are listed at the same principle and I use some entity references. In this case I don't expand these three HTML 4.01 entity references:

• %inline; = %fontstyle; | %phrase; | %special; | %formctrl; | #PCDATA
  • %fontstyle; = TT | I | B | U (tr.) | S (tr.) | STRIKE (tr.) | BIG | SMALL
  • %phrase; = EM | STRONG | DFN | CODE | SAMP | KBD | VAR | CITE | ABBR | ACRONYM
  • %special;, which have following elements:
    • non-replaced text elements: A | FONT (tr.) | Q | SUB | SUP | SPAN | BDO
    • replaced elements: IMG | APPLET (tr.) | OBJECT | MAP | IFRAME (tr.)
    • special elements: BASEFONT (tr.) | BR | SCRIPT
    Note 1. Because this classification is a collection of different kinds of elements, it has some problems.
    Note 2. Some proprietary elements (MARQUEE and BLINK) can have only non-replaced text elements + BR.
  • %formctrl; = INPUT | SELECT | TEXTAREA | LABEL | BUTTON
  • #PCDATA (Parsed Character Data) = text and white spaces without any formatting code.
    Note 1. Character entities () should be used for accented and certain special characters such as & and >. It doesn't mean the same as plain text in *.txt files, which is CDATA (Character Data) and where entities are not converted into certain characters but everything is handled literal.
    Note 2. In DTD-files #PCDATA has a specific meaning (I give two samples of Finnish texts):

    The following means #PCATA encoding:
    Tämä on <em>#PCDATA</em> koodausta
    The following is not #PCDATA encoding:
    T&auml;m&auml; ei ole <em>#PCDATA</em> koodausta

    In general also the latter means PCDATA as opposite to CDATA, if the parser reads <em>#PCDATA</em> as an element markup.
• %block; = P | DL | DIV | CENTER (tr.) | NOSCRIPT | NOFRAMES (tr.) | BLOCKQUOTE | FORM | ISINDEX (tr.) | HR | TABLE | FIELDSET | ADDRESS |%preformatted; | %heading; | %list;
  • %preformatted; = PRE
  • %heading; = H1 | H2 | H3 | H4 | H5 | H6
  • %list; = UL | OL | DIR (tr.) | MENU (tr.)
• %flow; = (%inline; | %block;).
  Note. This means the contents of elements. INS and DEL are special elements, which has this behavior.

In most cases where HTML 4.01 use %inline;, %block; and %flow;, XHTML use %Inline, %Block and %Flow, which have following contents:

• %Inline; = #PCDATA | %inline; | %misc;
  • %inline; = a | %special; | %fontstyle; | %phrase; | %inline.forms
    • %fontstyle; = tt | i | b | u (tr.) | s (tr.) | strike (tr.) | big | small
    • %phrase; = em | strong | dfn | code | samp | q | sub | sup| kbd | var | cite | abbr | acronym
    • %special; = a | img | applet (tr.) | object | font (tr.) | basefont (tr.) | br | map | span | bdo | iframe (tr.)
      Note. This classification is more consistent than the corresponding HTML 4.01 reference, because this entity reference doesn't have the element script, which is together with the element noscript classified under the reference %misc;. The content of the %phrase; is also fully consistent.
    • %inline.forms = input | select | textarea | label | button
  • %misc; = ins | del | script | noscript
    Note. These can occur at block or inline level. Ins and del have flow behavior. Script and noscript doesn't affect anything to the layout. These elements are classified both under %Inline; and %Block; and %Flow;, because they can be used different ways.
• %Block; = %block; | form | %misc;
  • %block; = p | %heading; | div | %lists; | %blocktext; | isindex (tr.) | fieldset | table
    • %heading; = h1 | h2 | h3 | h4 | h5 | h6
    • %lists; = ul | ol | dl | dir (tr.) | menu (tr.)
    • %blocktext; = pre | hr | blockquote | address | center (tr.) | noframes (tr.)
• %Flow; = #PCDATA | %block; | form | %inline; | %misc;

In addition I use the followings DTD-macros, which content is following (some of them are mine; In some cases I have marked as (tr.) (= transitional) elements, which belong only to transitional document types (in the HTML 4.01 specification they are primary listed as deprecated)):

• %pre.content; =
  strict: %Inline; -(img| object | big | small | sub | sup)
  transitional: (#PCDATA | a | br | span | bdo | map | tt | i | b | u | s | %phrase; | %inline.forms;)*
• %a.content; = (#PCDATA | %special; | %fontstyle; | %phrase; | %inline.forms; | %misc;)*
• %applet.content; = (#PCDATA | param | %block; | form | %inline; | %misc;)*
• %map.content; = ((%block; | form | %misc;)+ | area+)
• %object.content; = (#PCDATA | param | %block; | form | %inline; | %misc;)*
• %fieldset.content; = (#PCDATA | legend | %block; | form | %inline; | %misc;)
• %form.content;
  strict = (%block; | %misc;)*
  transitional = (#PCDATA | %block; | %inline; | %misc;)*
• %button.content; = (#PCDATA | p | h1-h6 | div | %lists; | %blocktext; | table | br | span | bdo | object | applet (tr.) | img | map | %fontstyle; | %phrase; | %misc;)*

HTML 2.0 and HTML 3.2 DTD-files have also a historical entity references, which I use in this document:

• %literal; = The encoding is handled literal. The HTML 3.2 specification say this way:

  historical, non-conforming parsing mode where the only markup signal is the end tag in full

  Elements XMP, LISTING and PLAINTEXT belongs to this category. Even the HTML 3.2 specification regards them as obsolete tags, but they are partially supported also in newest browsers (IE 5.5, Opera 4.02 and NN 6.0 23.8.2000).
  LISTING is not supported in NN 6.0. MS IE 5.5 and Opera 4.02 render it with a monospaced font face (normally as Courier) and it behaves in MS IE 5.5 like PRE and Opera like DIV.
  All new browsers don't read the possible termination tag to PLAINTEXT as end-tag but read is literal. Everything after the start-tag is read literal including </BODY> and </HTML>. In fact the browser changes the parsing mode from PCDATA to CDATA.
  The termination tag works in XMP, but NN 6.0 doesn't render common entities () at all. MS IE 5.5 renders them literal. XMP behaves in Opera 4.02 like LISTING.
  Note. In some older browsers the situation is different and the implementation is overall inconsistent. Even if PLAINTEXT works at the same way in newest browsers, I recommend, that you forgot all of them in to the chambers of HTML history. Indeed you can even use CSS with them, because CSS2 itself doesn't limit, which elements can get it (this matter depends on user agents and used markup languages).

I expand other entity references. DTD-file have special encoding to express the correct usage of element and I use the same system in this page.

In HTML 4.01 DTD-files the content is marked after the name of the element (for example <!ELEMENT BODY) after - - marks, if both start- and end tags are required. In HTML some element can be omitted or the end tag can be omitted. In previous case the element is marked O O (both start and end-tag can be omitted) or - O (the end tag can be omitted). Some elements are called as empty elements, because they can't have any content between start- and end-tags and the end tag must be omitted (marked as - O EMPTY). Because in XTHML is the existing recommendation and it doesn't allow to omit end tags, I recommend to use always, when possible end-tags and mark empty elements with the termination mark /, for example <br />. You can read some instructions how to read DTD-files from the page Help for TM WAPPush. You find more comprehensive information from W3C.

Detailed element classifications

Elements have two basic behavior types, inline and block. Normal block elements create a rectangular box and line break before and after them. Depending of elements they can have both block and inline-level child-elements or only inline-level child-elements. Ordinary inline-level elements don't create rectangular boxes around them and they don't create line breaks. They behave like a phase in a line. They can have only inline-level child-elements.

Some elements mix these behaviors. The behavior type is called as flow. The DTD-files says about elements DEL and INS, that these can occur at block or inline level. Depending on situation, they behave like normal block or inline elements.

HTML 4.01 specification has poor explanations. The specification doesn't always tell the expected behavior of each elements. In the DTD-files classifications block, inline and flow are not enough. In fact some elements should be classified as inline-block or inline-flow elements (I have derived the classification inline-block from the CSS2 specification, which have display:inline-table; Table itself is a block-level element, but this property creates to it inline resemble flow; Into CSS3 is added diplay:inline-block to get proper presentation especially to some form elements). These kind of elements are:

• OBJECT, MAP and BUTTON, which according to DTD-files can have block-level child-elements. The natural behavior of these elements is inline. They don't behave like DEL and INS, which behave in some situations like normal block-level elements. Because these elements can have both inline-level and block-level elements as their child-elements, they are inline-flow elements. In principle these elements need some block-level parent-element (BUTTON has normally FORM as it parent-element).
• OPTION and OPTIONGROUP, which create line breaks like normal block-level elements. Because these elements require the inline-level parent element SELECT, which doesn't have any other contents, they have the behavior inline-block.

The DTD-files try to classify all elements into three behavior type. In my mind used element classifications are not fully consistent:

1. Especially the group %special; in HTML 4.01 has in the loose.dtd for example following elements: A,, APPLET, FONT, | BASEFONT, SCRIPT. The element SCRIPT doesn't affect to the layout. Elements A and FONT have the same kind of behavior as normal inline-level element like B. The element BASEFONT affects wider than inline-level elements and its effect range is the same kind of elements DEL and INS, which have the flow behavior. This classification creates internal conflicts, because BASEFONT in intended to set before other elements unlike normal inline elements, which are intended to use inside some block-level element. According to advice, the DTD-files should be this kind:
   -- (BASEFONT?, (%flow;)* +(INS | DEL)
   
   Indeed just this matter creates the internal conflict with the official DTD. This matter is solved in strict document types by deleting the whole element from the document type. We must also remember that in some browsers it behaves like an element container and we must ask, if the whole element is defined incorrectly (look at a note).
2. The element NOSCRIPT is classified with the entity reference %block; even if it should be rather %flow;. This matter is fixed in the XHTML 1.0 specification, which is at this point more consistent than HTML 4.01. It classify this element under the reference %misc;, which is common to %Inline;, %Block; and %Flow;. I have classified NOSCRIPT according to the XHTML 1.0 DTD.
3. IMG, APPLET, OBJECT, MAP and IFRAME are replaced elements. Some of them can have also block-level contents. Also some form elements (for example BUTTON), which are listed as %inline; can have block-level contents and the behavior resemble replaced inline elements. They create floating rectangular boxes. In fact they should have an own classification.

Comment. Many authors use FONT at the same way as BASEFONT even if according to the specification it should behave like an ordinary inline-level element. Even if most browsers allow to that element the flow behavior, I recommend to use it according to the specification.

It is however possible to create some sub-classifications in the base of them. Concerning the page layout HTML-elements can be classified into sub-classed at the following way:

• Block-block = such block-level elements, which need common or certain block-level child-elements (for example UL, OL, TABLE and in the strict document type the element BLOCKQUOTE has normally a block-level element as its child-element).
• Inline-inline = normal inline-level elements, which can have only inline-level content (for example I, B and SPAN + A excluding nested anchor elements; from form elements LABEL and LEGEND have this kind of behavior).
• Flow = such elements, which behavior is like normal inline-level or block-level elements (INS, DEL).
• Block-inline = such block-level elements, which can have only inline-level child-elements (CAPTION, DT, H1-H6, P and in the strict document type ADDRESS).
• Block-flow = such block-level elements, which can have both block or inline-level content (DD, DIV, FIELDSET, FORM (excluding nested forms), LI, TD, TH and in the transitional document type BLOCKQUOTE, CENTER and IFRAME).
• Inline-flow = such inline-level elements, which natural behavior is inline, but which can have also block-level content (OBJECT, MAP and BUTTON and in the transitional document type APPLET).
• Inline-block = such inline-level elements, which natural behavior resemble block-level elements. Some of them are child-elements of some inline-level element (OPTION and OPTIONGROUP), but TEXTAREA has a block parent. These elements behave like the replaced inline level element IMG.
• Block-empty = block-level empty elements (HR and in the transitional document type ISINDEX).
• Inline-empty = inline-level empty elements (BR and IMG and from form elements INPUT; even if AREA is not classified to them it resembles them). Indeed we must ask, if we should classify them into two sub-classes:
  • Inline-block-empty = such empty inline-level elements, which natural behavior resemble block-level element (IMG, INPUT).
  • Inline-empty-empty = such empty inline-level element, which can't have any content (BR).
• Flow-empty = an empty element, which affecting range cover block and inline-level elements. BASEFONT is this kind of element even if it is classified in the loose.dtd as an inline-level element (it is used like an inline-level element, but it affects wider; Indeed in some browsers it behave like an element container - look at a note).

This classification is not without problems, because inline-level elements can be classified also as replaced (for example IMG) and non-replaced elements (for example STRONG). Concerning replaced element, the behavior resemble floating block level elements (they are created with the CSS-property float) both empty and non-empty elements.

If we think about the visual rendering of elements, they have only three basic alternatives: block, inline and inline-block. CSS3 will support all of them with the display property. The behaviour of some elements, which have the flow behavior or flow content is different in individual situations. Just this matter makes classificiations problematic.

Official recommendations and other help pages

• DTD-files:
  • HTML 4.01 Transitional
  • XHTML 1.0 Transitional
• HTML 4.01 Specification
• Extensible Markup Language (XML) 1.0 (W3C Recommendation 10-February-1998)
• XHTML 1.0 (A Reformulation of HTML 4 in XML 1.0 W3C Recommendation 26 January 2000)
• XHTML 1.1 - Module-based XHTML (W3C Working Draft 5 January 2000)
• Modularization of XHTML (W3C Working Draft4 October 2000)
• Cascading Style Sheets, level 1
• Cascading Style Sheets, level 2 CSS2 Specification
• The Tag Library of Znet (it list also proprietary elements and attributes, but have crucial holes)
• Index DOT Html (extremely comprehensive listing of HTML elements and attributes)
• HTML Home Page (includes links to the history of the early HTML-versions)
• HTML 4.0 DTD (alphabetic listing of HTML 4.0 elements by Norman Walsh)
• webreview.com
• Webstandards

Color keyword values

Topics

• Widely known color names and web safe colors
• Netscape 140 named colors
  • Repeated color names
• A chart of web safe colors
• Non-web-safe colors in the Windows palette
• Other pages

Widely known color names and web safe colors

Most browsers support 16 color keyword values. They can be regarded as standard colors in the Windows platform, because they base on 16 first color in the Windows color palette. However only half of them belong to web safe colors, which are common to Windows and Mac browsers. Instead of 256 standard VGA-palette, this palette has only 216 colors.

I have defined colors as hexadecimal values. All CSS-capable browsers should be able to render following colors if they have enough big color depth (I have marked web safe colors as + ... +):

Netscape 140 named colors

Netscape 140 named colors. Colors, which are marked as *...* belong to those 16 widely supported color names, which don't belong to web safe colors. Colors, which are marked with +...+ means those widely supported color names, which belong to the web safe palette (other web safe colors are listed later). Color names, which don't have these marks are supported in Netscape browsers and newer Microsoft Internet Explorer browsers, but not in all versions of Opera (at least Opera 5.1x series supports them). All colors are defined as hexadecimal values in order that all CSS-capable browsers, which have enough big color depth could render these colors:

I recommend that you would not non-web-safe named colors except in the Intranet. Use instead of them nearest web safe colors. For example use instead of darkorchid (#9932CC - rgb(153, 050, 204)) the nearest corresponding web safe color values (#9933CC - rgb(153, 051, 204); in CSS also the shortened format #93C is valid).

Repeated color names

Some color values have two names and they are at that mean listed twice in the 140 color name list. Aqua and cyan are same colors (rgb(000, 255, 255)) like fuchsia and magenta (rgb(255, 000, 255)). Use rather aqua and fuchsia than cyan or magenta. The 140 colors might have other double colors.

A chart of web safe colors

Web safe colors use RGB-values (00)0, (0)51, 102, 153, 204 and 255. Corresponding percentage values are 0%, 20%, 40%, 60%, 80% and 100% and corresponding hexadecimal values are combinations of 00, 33, 66, 99, CC and FF (for example #003366). I tried to create also a list of those 40 colors, which in Windows 95 or 98 don't belong to web safe colors, but I don't get the necessary information.

I have defined colors as hexadecimal values with HTML elements and attributes. Colors are classified according to the RGB-values with three digits. In this case they are listed first. I have also added possible named colors (colors, which are marked as +...+ belong to 16 common used color names). Almost all browsers should be able to render following colors:

Non-web-safe colors in the Windows palette

In addition to RGB-values (00)0 (0%) and 255 (100%), the Windows 256 palette use also RGB-values 128 (50%) and 192 (75%), which are as hexadecimal values 80 and C0 (for example #808000). At least following colors in the windows 16 colors palette are not web safe colors (I can't however inform, what are those other 32 colors in the Windows 256 colors palette, which are not web safe colors):

Other pages

Zoran.net lists 140 named colors with their NAMES (can be referenced in web-pages by those names), HEX values, RGB values and absolute rgb values. It lists names however separate (for example it lists the first color alice blue, but I have listed color names together aliceblue). You can find more information about named colors and web safe colors from the Internet (when you search information about them, use search words web+safe+colors or named+colors).