This is a review of the HTML 4.0 draft as announced July 8th, 1997, in several formats. More exactly, these comments are based on the PostScript version. In December 18th, 1997, HTML 4.0 was approved as W3C recommendation. There was a large number of changes from the draft discussed here, but most of the remarks presented here still apply (in the author's opinion).
The HTML 4.0 draft, as compared with HTML 3.2, contains additions and changes of varying nature. Instead of being an all-inclusive attempt to define an improved version of HTML, the hypertext markup language for the World Wide Web, it appears to be the product of evolution by mutations and vendor-driven selection. Thus, a large set of individual changes have been applied to HTML 3.2, rather independently of each other.
These changes are rather miscellaneous and partially in conflict with each other, pragmatically speaking. They include
There are very few observable attempts to improve HTML as a logical, structured hypertext language. Most notably, there is a relatively generic and powerful generalization of the old IMG element, in fashionable object-oriented clothes (OBJECT element). This, together with the multilingual support, might be important enough to justify further refinement and acceptance of the draft, despite serious drawbacks elsewhere.
The basic structuring elements are the same as in HTML 3.2. In fact, very little has happened in this crucial area since the dawn of HTML. In particular, instead of introducing the logical sectioning (something like the one proposed in the ISO HTML draft), the HTML 4.0 draft goes to the opposite direction: it waters down the good old recommendation to use heading elements consistently, without skipping levels, by drawing away from it as follows: "Some people consider skipping heading levels to be bad practice." And as regards to the few new structural elements proposed, ACRONYM is badly designed, Q is introduced as a text-level counterpart of BLOCKQUOTE instead of reconsidering the idea of text level vs block level markup, and INS and DEL elements look rather homeless without their natural companion, an element indicating changed text.
The conclusion is that the next step should be to define a relatively small set of additions to HTML 3.2 by picking up from the HTML 4.0 draft the OBJECT element, the language support, the INS and DEL elements, added named character entities, and possibly some more. After approval of such additions, future work on HTML development should concentrate on the creation of better structured language, with features like fully nestable sections, rich markup for different kinds of emphasis, tables with columns specified structurally, and basic mathematical markup.
In printed form, the HTML 4.0 draft is about 265 printed pages long, and it still contains empty parts to be added later. Compared with the about 77 pages of HTML 2.0, this exhibits an intolerable trend. The future HTML specifications should be strictly divided into the normative part and the informative part. (They should be clearly marked up using e.g. the idea of "generic colors" presented later in these comments.) The normative part may contain statements which are either clarifications or suggestions only, without being binding, but they should be flagged as such clearly and uniformly (using a uniform notation). On the other hand, the normative part should be explicit enough instead of relying on intuitive interpretation of names of elements and attributes, for example.
This part will present some general comments which apply to the draft as a whole or to phenomena occurring in several locations in the document. First some relatively technical notes on the draft are made, then some more fundamental issues are addressed.
The structure of element descriptions is not explained in the draft, although there seems to be a common pattern: heading, SGML declarations, omissibility of start and end tags (explained in prose), descriptions of attribute, short description of semantics, and possibly examples and notes. The semantic definition should be more prominent and explicit and should appear right under the heading. A heading should not be regarded as a substitute for definition. Neither should the semantic definition refer to vague in ordinary language; a definition like "The THEAD element defines the head" doesn't really define anything, since the draft does not say what a table head is in HTML. And an excerpt from a DTD (if included into the specification) should be ignored when considering whether the specification is explicit enough. Notice that the draft itself says that "DTD comments for HTML do have not normative value". (Perhaps this grammatically strange formulation reflects some uncertainty? ;-)
Whether the SGML declarations are needed inside (on interspersed with) the text at all is debatable. A reader who can make use of them could consult the DTD (without taking trouble of checking whether the declarations have been copied correctly from there!). For other readers, a prose description of the syntactic rules would be needed. (Providing a link to the SGML definition, i.e. a part of the DTD, would be quite OK, of course.)
Several examples exhibit "clickism", which is to be considered as a bad habit of referring to device and program dependent features. Less severe but still annoying is "hereism", which occurs as early as in an example in the discussion of the TITLE element and the title attribute. (If nothing better can be invented, even "There is a photo - -" would be better. It would not annoy so much eg. in a printed copy of a document containing a link to a photo.)
Some examples seriously suffer from another deficiency: they are not examples at all but sketchy schemes for writing an example. Even more seriously, this occurs especially with new features proposed. For example, "examples" on multilingualism do not actually contain several languages, and "examples" on THEAD and TFOOT do not contain actual headers and footers but metatext like "header information".
There are several fragments of illegal HTML, labelled as ILLEGAL EXAMPLE. Obviously, the purpose is to illustrate a prohibition. However, incorrect examples, no matter how clearly flagged as such, often affect people's minds in the wrong way. Nobody is perfect, and we tend to forget things; even worse, we migh remember an HTML construct but forget the context, such as being an illegal example. Therefore, illegal examples should be removed. On the other hand, prohibitions (such as "Links and anchors defined by the A element may not be nested") can and often should be explained further e.g. by rephrasing them ("That is, an A element may not contain another A element, directly or indirectly") and followed by a positive suggestion, if possible (such as "On the other hand, you can write a dual-purpose A element which has both a name and an href attribute").
The (printed version of the) draft contains phrases like "These examples illustrate the rendering of - -", without being really accompanied with an illustration (at least in the PostScript version of the draft). Moreover, illustrating renderings in an HTML specification should usually be avoided, since it tends to suggest that the given rendering is the rendering and not just one of myriads of possibilities.
Some notes in the draft are neither explanatory nor recommendations to HTML authors or user agent implementors but rather excuses. For example, the final note under the heading "Titles: the TITLE element and the title attribute" should be just a note in the files and minds of HTML specification developers. Now it looks half an excuse (without really saying any excuse), half a promise (without giving any promise which would be of some importance to HTML authors or software implementors). Moreover, it appears in very peculiar place, since encoding phonemic and prosodic information is a much wider question than providing a new attribute to be used in conjunction with the TITLE element or title attributes. The speech synthesis issues for normal text in the document body are more important!
The draft lacks elements for mathematical expressions, although a relatively good proposal for them was made already in the HTML 3.0 working draft. Assumably the idea is to leave such things to he handled using separate XML based solutions like MathML. In practice, this seems to involve highly complicated markup which requires a few dozens of elements in order to mark up a simple second degree equation. But the more fundamental problem is in the very approach.
Knowing how difficult process the development of the HTML language has been, it seems temptating to isolate problematic areas so that they will be handled separately, in separate specifications, by separate groups of people, creating separate DTDs. This operation, if successful, will kill the patient: HTML as a common language, which can be expected to be supported by a wide range of user agents - HTML as the language for the World Wide Web. No matter how useful XML might be for specialized areas where it could be used to define additional languages which supplement the basic structuring mechanisms of HTML, it will be most harmful to the Web if it will be used to explain away the needs for improving HTML itself. (Analogously, would it be wise to stop developing better versions of a high-level programming language, saying that people can write their own specifications for doing in assembly language what cannot be done in the current version of the high-level language?)
Instead of everyone or every group defining their own languages, with no reasonable expectations on portability, we should - in addition to defining things like basic mathematical markup for HTML - consider adding some generic mechanisms which I will call generic colors. The idea is that an author often wishes to mark up some parts of the document as having some special role which cannot be expressed in normal HTML. (It might be role which is common enough to be included into HTML in some later version.) For instance, an author might wish to mark up some parts as normative and some others as explanatory, or, in a description of the features of some language, flag some of them as deprecated. Specifying e.g. some specific colors for the purpose in a style sheet is far from being a generic and structured solution. And what the author, or rather the communicative process, really needs is some way of distinguishing things. If physical colors are used, it should be up to the reader to select them.
One solution would be to introduce a generic markup for "generic coloring". For example, it could be something like
<MARK KIND="Normative specification" COLOR=1>which would indicate the start of an element which is characterized by the value of the KIND attribute and is to be presented generic color number 1. Each implementation would be required to provide some minimum number (say, seven) different "generic colors". They could be physically presented as background colors, text colors, text fonts, tones of voice, in some uniform way which distinguishes texts from each other and from normal text. Binding generic colors to physical presentations should be user-configurable, preferably dynamically so that the values of KIND attributes are displayed to give a hint about the author's intentions. (In some cases, it might make sense to change the colors from user's defaults to reflect the particular purpose for which the markup is used.)
A language like HTML should provide a lot of continuity. Even if changes are generally accepted and rapidly implemented in browsers, there will be quite a many copies of old browsers around. We should not expect people to install new versions of browsers every month. Continuity has been a goal in the sense that old constructs have been preserved, perhaps even too long. But there is more. First, a browser should be required to inform when it encounters a document in an HTML version which it does not know or when there is some gross incompatibility with the DOCTYPE declaration and the actual HTML code. Such a report could be e.g. just a small blinking text which announces that the document seems to contain markup which is not suppored by the browser. But when users cannot see any such reports (even upon special request), they will not be able to realize that what they see may lack essential information or be presented in a manner which radically differs from the intended structure of the document.
Continuity also requires that authors are well aware of the changes from one (approved) version of HTML to another. This applies in particular to deletions and semantic changes which can make old documents nonconforming or semantically invalid. There is no official comparison of differences between HTML 2.0 and HTML 3.2; so it is no surprise that some inofficial comparisons are incorrect. Notice that in addition to new features, HTML 3.2 has some definite deviations from HTML 2.0. This will be an even bigger problem with HTML 4.0, unless the specification itself provides the (adequate) information. In fact, the development process should consist of defining changes to a base document rather than writing yet another HTML specification whose structure greatly differs from previous specifications. That way a specification of changes would be born naturally, and it would prevent the phenomenon that when something is written from scratch, essential information might be left out. Naturally, it would be just a matter of technical editing process to create a standalone specification of the new HTML version by combining the old one and the changes.
This process should be started in the creation of HTML 4.0. This means that a proposal for additions (and eventually other changes) to HTML 3.2 should be prepared, carefully selecting the really useful new features presented in the draft. Even for the public discussion, it would be better to have a relatively short document of proposed changes than a large document (where the changes haven't even been marked). The structure of the HTML 3.2 specification might be non-optimal, but there is nothing very wrong with it, and for continuity reasons we should not deviate from it without a very good reason.
The following comments refer to the single-document version of the draft, made available in PostScript form, since for the purposes of presenting comments such a form is superior to hypertext.
The structure of the HTML 4.0 draft as a mixture of various material (ranging from strictly formal and normative rules to vague informal notes) and as a large collection of sections without explicit upper level structure makes it rather difficult to present comments. (The single-document version contains two tables of contents with no explicit relation to each other. Here the first table of contents is used, partly because it seems to cover the entire material.) In the following, the division into sections (as visible in the table of contents) is used, using headings in the section as headings for related comments here.
For easier reference, all section headings (excluding the tables of content) are included here even if no substantial remarks are presented.
Although detailed, these comments try to avoid discussing minor details and errors of editorial or presentational nature. Such things should be dealt with at a later stage of the standardization process. Thus, any apparently very detailed remark here should be interpreted as a note discussing a detail of fundamental importance.
In the abstract, the characterization of HTML as "the publishing language of the World Wide Web" is technically correct, yet surprisingly strange. It deviates from previous practice of calling it "a simple markup language used to create hypertext documents that are portable from one platform to another". (Naturally, we should not stick to old wordings. But is the original idea so widely accepted and applied now that it needs not be mentioned?) Moreover, the abstract emphasizes accessibility to users with disabilities in a manner which is incompatible with the small scale of improvements in that respect. The phrase "great strides towards the internationalization" is in disproportion with the fact that the proposed multilingual features, although mostly necessary, only provide a basic general framework for supporting various languages. (The specification does not even require support to any particular language, even English!)
The statement that HTML 4.0 replaces HTML 3.2 leaves the status of HTML 2.0 open. Although HTML 3.2 contains a statement about its replacing HTML 2.0, it in fact postulates HTML 2.0 as its base document (by leaving essential things unspecified, forcing readers to refer to HTML 2.0).
This section is obviously nonnormative. As regards to its content and the structure of the specification, please notice that the draft lacks the kind of reference material which is probably what HTML authors would most often use: a summary of all elements in alphabetic (or thematic) order, with short syntactic and semantic descriptions, including possible attributes. Naturally, such a reference need not be part of the normative specification, but preferably it should be prepared or at least approved by the same authority.
The section is marked as "being written". It is debatable whether such a section is needed at all in the specification. Introductory material is definitely needed, but quite different introductions are needed for different readers. Thus, they are best written by people and organizations which are involved in practical support to HTML authoring and which can adapt their material to various local and personal needs.
The subsection on interoperability takes it for granted that interoperability requires providers to develop "different versions of documents". This is contrary to the essential design principles and part of the common strawman arguments against "purists".
Fundamentally, Web interoperability requires that documents be marked up in a consistent structural manner and that browsers and other user agents display or otherwise use the documents in a manner appropriate to the user's situation. The obvious implication should be that the HTML language should evolve to allow more consistent, structural, and universal markup - that is, to be richer in expressing structure.
Multilingual support should be labeled as such, or as language-specific support, not as "internationalization". (Typically, multilingualism is important for national documents, whereas most international documents use just English.)
There are definite improvements to the possibilities of providing wider accessibility to visually impaired, but the results should not be exaggerated. The draft does not even make the ALT attribute of an IMG element mandatory, and it shows a lot of understanding as regards to the common misuse of BLOCKQUOTE for indentation or the use of tables for layout. Most importantly, encouraging the use of style sheets (in a context where that must mean author's style sheets) implies that authors will attempt to control presentation to a much wider extent than nowadays. Far from improving accessibility, author's style sheets seduce authors to design their documents for some very particular presentation environment.
The note on tables says that the "new" table model is "based on" RFC 1942. A comment in the DTD seems to claim that HTML 4.0 tables conform to RFC 1942. The exact relation should be made clear, and any differences should be listed carefully (in an informal annex). On the other hand, RFC 1942 is relatively strongly presentation-oriented. Instead of allowing the author specify the logical properties and class of a table (such as being a numerical table), it requires the author specify presentational attributes (such as alignment on some particular character). Thus, perhaps tables should be left as they are in HTML 3.2, until some essential improvement can be agreed on.
The OBJECT element being one of the most important features, it should be referred to under a more appropriate title than "compound objects".
The remark on "Ease of use" has great confidence on "powerful HTML authoring tools" which will "flourish". Currently most such tools produce grossly invalid and nonportable HTML. Suggesting that they will make eg. the creation of forms easier implies that forms be designed in the WYSIWYG manner. Such an approach implies that forms need not be designed as structural and logical constructs but as visual products. Quite apart from these fundamental things, the proposed constructs related to forms are unnecessarily complicated.
This section is probably intended to give recommendations on document design, despite the fact that the first statement mentions "implementation" as well.
In a sense, the section looks like a parody. First it refers to the widely propagated idea of separating structure and presentation and to the "roots" of HTML which involve specification of structural markup, then proceeds to the idea of replacing presentational features by style sheets "as HTML matures". Ultimately, it views the separation as a technical aspect in document design, not as fundamental separation of document design and document rendering - the jobs of the author (and languages and tools for authoring) and the user (and browsers and other tools for utilizing documents). This seems to imply the view that replacing a simple attribute like ALIGN=CENTER by a STYLE attribute containing corresponding instruction in a language external to HTML is a great improvement.
Similarly, the notes on universal accessibility emphasize accessibility to people with disabilities in a manner which seems to present this as an obligation to add some features to documents, not as a principle of overall design. To do some injustice to the draft - quoting something slightly out of context - it says that it only recommends that designers consider alternate renderings in their design.
And finally, these design recommendations suggest that designers help user agents render tables more quickly, obviously by giving presentational attributes. It might occasionally be useful to do so with large tables, although it is debatable whether such a feature should be included into HTML. But it is certainly wrong to suggest the use of such facilities as one of the three principles under the title "Designing documents with HTML 4.0". (The natural way to pay attention to eventual performance issues is to keep tables in reasonable size, dividing them into pieces if needed, and to refrain from using tables for layout.)
This tutorial appears to be very useful especially for those who only need to know SGML for the purpose of understanding HTML DTDs. It deserves careful study and comments. It is mostly skipped here since this section does not belong to the normative part. Naturally, there should be an appropriate normative statement somewhere, defining HTML 4.0 as an SGML application.
However, the tutorial contains some statements which may be regarded as recommendations on HTML usage or on terminology related to HTML. The note about elements not being tags can be misleading, since it suggests that a phrase like "the P tag" is incorrect; in fact, there is hardly any reason to think so, provided that the phrase is used (as it usually is used) to refer to the construct <P>, which actually is a tag.
Another note seems to recommend the use of lower case letters for (assumed) compression performance reasons. Such reasons can hardly be so important that they should be presented in an HTML specification, still less in any introduction to SGML.
Information about the reasons behind the notions "block level" and "inline" do not really belong to an SGML tutorial even in an HTML context. It explains the rationale behind making HTML 4.0 (and, consequently, its DTD) what it is, not how the DTD is to be read.
The definition of "conforming user agent" is vague. Perhaps the verb "observe" has a suitable meaning in some forms of the English language, but in international contexts it is better to say eg. "satisfies - - conditions" than "observes - - conditions". In fact, the simple definition of the term in HTML 2.0 specification is much better: "A user agent that conforms to this specification in its processing of the Internet Media Type 'text/html'." Notice in particular that the draft proposes that conforming user agents be required to "try to render the content of any element is does not recognize" and to ignore unrecognized attributes. These requirements are a definite change to the old policy and would encourage people to use vendor-specific or otherwise nonstandard markup.
The concept of "deprecated" features is useful in itself, and the definition probably needs no improvement. However, the way in which the concept is used in the draft is very confusing and contradicts the definition. There is a large number of features which are not in HTML 3.2 and which are now proposed for inclusion into HTML 4.0, simultaneously declaring them as deprecated. The only conceivable reason to this is to say to browser vendors that they must support some features introduced by other vendors in the past and now standardized, although they are not recommended to authors. Of course, most authors will not see this fine point. Giving examples, even if indicated as deprecated, will be taken as an encouragement or at least acceptance.
And what is the point of requiring support to features which have not previously been accepted to public standards and which cannot be recommended to authors? Such policy would just slow down browser development by requiring new browsers to implement support to old hacks if they wish to claim conformance to HTML 4.0.
As regards to "obsolete" elements, HTML 3.2 declared XMP, PLAINTEXT, and LISTING as obsolete but still described them. They were obsolete even in very early HTML drafts prior to HTML 2.0. On the other hand, some features of HTML 2.0 were simply dropped away from HTML 3.2 instead of marking them as obsolete. The HTML 4.0 is more sensible, but to avoid any confusing idea of those elements still belonging to HTML 4.0, too, in some obsolete way, it is better to remove the deletion of "obsolete" from the definitions section and simple say in the change history that those elements have been entirely removed.
The remark that HTML files are usually given the extension ".html" or ".htm" looks relatively odd. What is the message? Web users have probably noticed that before they start reading any HTML documents. What may really puzzle them is which one should they use and how does the recognition of HTML files really take place. (Basically, an HTML specification is not suitable for answering such questions, but it might contain a reference to some reliable information.) And if there is a heading "Document names", one would expect it to answer important practical questions (eg. which characters are allowed in document names).
This section is obviously intended to be informative. It is in some respects insufficient or even misleading. On the other hand, it contains some normative information (most importantly the RFC references), which should be clearly marked as such.
The term "fragment URL" is technically incorrect. Both RFC 1738 and especially RFC 1808 refer to the construct of the form #fragment (so that the wording about the URL specification not offering a mechanism to refer to a location is not quite accurate), but they specifically say that it is not part of a URL.
Consequently, the specification of HTML should make it clear that in contexts where the syntax allows a URL, it may have a fragment identifier appended. This together with the RFC references should be presented as normative information.
The wording "In addition to HTTP URLs, authors might want to include MAILTO URLs - -" is misleading, since it might be read so that it suggests that only the schemes http: and mailto: can be used.
The statement that "User agents may support MAILTO URL extensions that are not yet Internet standards - -" is a strange way of encourageing the use of nonstandard features which may cause a lot of trouble. (User agents may support whatever they like, but mentioning something specific in this respect in an HTML specification is actually regarded as some sort of acceptance and encouragement.) Simultaneously it seems to claim that the ?Subject extension will be an Internet standard. There is little reason why it should, since forms are more suitable for initiating messages with the subject field (or other fields) predefined or prefilled.
Currently there seems to be the requirement that a user agent map characters to Unicode correctly for any encoding it recognizes but no requirement on such recognition. (The ISO 8859-1 is definitely suggested to be among them, but it is hard to find a definite requirement on that.) It is not even clear what recognition means here. Does it mean that the name of an encoding is recognized in the process described in the draft (eg. by picking up an HTTP "charset" parameter in a "Content-Type" field) or that such a name is actually recognized as being one of those supported by a user agent? Probably the latter, since otherwise user agents were required to support all encodings, which would be somewhat unrealistic.
There seems to be an important but quiet change. Previously ISO 8859-1 was defined as the default encoding, and HTTP 1.0 recommended servers to omit the "charset" attribute altogether when ISO 8859-1 was used. The changes might be worth doing, but they should be made more explicitly and emphatically. (There is work in progress on defining ISO 8859-0, and such a character set an encoding might become standard in the European Union. So it might well be best to remove the special role of ISO 8859-1.)
Notice that there seems to be no requirement on user agents specifying in their documentation which encodings they support or on reporting that they have encountered an unrecognized encoding. The problem, mentioned in the draft, that using "heuristics" (actually, wild guesses) "may lead to an unreadable presentation" would be relieved if browsers were required to report it to the user. The same applies to the situation that encoding is actually specified for a document and the name of the encoding is correctly extracted by a browser; in such situations, a browser should be required to report that, irrespective of whether they display the document applying some other encoding. Notice that in many cases the result of applying an incorrect encoding is not unreadable, just wrong. For instance, if a document has been encoded in some variant of ISO 8859 and it is displayed using another variant, the result might well be that most characters look as intended while some national characters are replaced by some other characters. (The reader might not even realize that he gets some words wrong.)
Referring to 'the Cyrillic letter "I"' is strange. What it probably means is the Cyrillic letter which is in some sense the counterpart of the Latin letter "I" but looks quite different. Does the HTML version of the draft refer to the Cyrillic letter meant here in the manner suggested in this part of the draft? - Moreover, the phrase 'the Chinese character meaning "water"' is hardly unambiguous; the Chinese probably has several characters used to denote water.
The draft refers to RFC 2045 for information about "charset" values. However, that RFC does not seem to define those values. It only defines generic syntax involving parameter=value and mentions charset as one possible parameter, without defining its value set. The registry of charset values is kept by IANA, in accordance with RFC 1345.
The recommendation to encode any instance of " by quot; is new, and it is unnatural for languages where that character is used as the normal quotation mark. Moreover, the question why " was left out from HTML 3.2 has never been answered satisfactory in the public. Two quite different reasons have been given: simple mistake, and the reason that " is somehow reserved for SGML reasons. See http://www.w3.org/MarkUp/Wilbur/ on one hand and http://d1.ph.gla.ac.uk/%7eflavell/iso8859/iso8859-pointers.html#quot on the other. Although this issue need not be discussed in the HTML 4.0 specification itself, it needs to be clarified before " can be accepted. (If " is really reserved, the natural solution would be to introduce "e; for the " character. Browsers might still recognize " the same way they have done, but authors should use the new mnemonic.)
This section is obviously partly normative (eg. syntax of color values), partly informative in the sense of giving recommendations (mostly on color usage). As regards to the latter, it is illogical to say that the use of HTML elements and attributes for colors is deprecated and then proceed to giving advice on using them. (Moreover, the advice is debatable. For instance, referring to "common conventions" is vague; most people will either not understand it at all or take it as referring to color usage in some currently popular browsers with their default settings.)
Referring to CSS1 specification for normative information about the definition of a pixel deviates from the normal and natural practice of not implying any particular style sheet specification system in the specification of the HTML language. Something along the lines of the HTML 3.2 specification wording in this context should be applied.
The wording that authors should include a DOCTYPE declaration "resembling" something is too indefinite. Authors often use incorrect DOCTYPE declarations, and the draft wording seems to say that it does not matter. Moreover, such declarations might be included by software, not by authors. Consequently, the specification should simply require that an HTML document contain a DOCTYPE declaration corresponding to the version of HTML used, then list (as the draft does) the variants that may be used for HTML 4.0.
This section refers to "strict" HTML 4.0, but the draft does not contain a DTD for strict HTML 4.0. Notice that "strict" is a misleading word here. It is meaningful and usual to say speak about strict conformance to a DTD, although strictly speaking it simply means conformance, But strictness is not a meaningful property of a DTD. "Structured" would be better. (Or perhaps "Puristic".)
Illogically, the draft says that an HTML document, except for the DOCTYPE declaration, "should be enclosed by the HTML element". This seems to confuse tags and elements in a manner against which the draft warns elsewhere. By definition, an HTML document, except for the DOCTYPE declaration, is an HTML element. The description of "a typical HTML document" seems to imply that a document should contain explicit HTML tags. The DTD does not seem to imply this. This problem seems to be caused by the finesses of SGML as well as the introduction of frames. Hopefully the problem will disappear due to removal of frames.
In the description of the META element, there are several examples which assume some particular user agent behavior, possibly according to some specification external to the HTML specification. They should be clearly flagged as being such. Otherwise they will easily be taken as part of the HTML specification. This applies eg. to page "refresh", search engine treatment of name="keywords", and PICS.
On the other hand, the provision of meta data should be standardized (in HTML specification) as regards to some minimal information concerning the document. Such a standard should also fix the way in which the information is given in an HTML document, instead of a multitude of different ways. It should also recommend user agent behavior on the display of the basic meta data by default or by explicit user request. Otherwise authors will have to provide the same information both as meta data and as part of the document body, which is illogical, unsystematic, and error-prone. The profile system is acceptable as an addition to such standardized basic system, not as a replacement for it.
The draft discusses the title attribute in conjunction with the TITLE element. Although semantically understandable, this breaks the structure of HTML and probably makes the specification hard to read, still harder to use as reference material. More importantly, the meaning of the title attribute is too vaguely defined. Although the definition is above the average, just saying that the attribute "offers advisory information about the element for which it is set" is not sufficient. For example, the draft contains a LINK element with with title="The manual in Dutch". Does the attribute really offer advisory information about the LINK element? Shouldn't we rather say that in a LINK (or A or OBJECT) element, the title attribute provides such information about the linked resource which is relevant in the referring context? (Notice that if the attribute provided information about the linked resource per se, it would be natural to write its value in Dutch in our example.)
In the draft, the DIV element is defined as a block element as in HTML 3.2 but now with text level (inline) SPAN element as its counterpart. The draft says that "user agents generally place a line break before and after DIV elements", while HTML 3.2 specification says that DIV terminates an open P element (and the draft says the same) but emphasizes that user agents are not expected to render paragraph breaks before and after a DIV element. This sounds really confusing. The natural selection would be to introduce a new element which is a pure grouper with no implications on line or paragraph breaks or inline vs. block whatsoever. (For compatibility, DIV might be preserved as a deprecated element with the old meaning.) - As regards to the example on using SPAN, it is unclear what it is intended for. Attaching class names to names of fields in a record might perhaps be useful, but it would probably be more useful to have class names for the fields themselves.
The heading elements have been part of HTML since the early days. Very little has happened around them, although the system is logically unsatisfactory. Instead of allowing the natural way of dividing a document into sections, subsections, etc, HTML just allows the author designate some phrases as headings of different levels. This implicitly contains structuring provided that some rules are obeyed, such as not skipping header levels. The draft actually removes the old recommendation on structured usage of headings by calling it just some people's matter of taste.
The ISO HTML draft, despite its serious shortcomings, provides a better solution in this respect: true sectioning mechanism. (Naturally, the old heading system should be supported and legal, although possibly deprecated, during a long transition period.) Although it would be important to add even better structuring facilities, such as optional introductory, summary, and conclusions elements within a section, even a simple sectioning along the principles suggested in the ISO HTML draft would be a definite improvement.
The HTML 4.0 draft now suggests the use of DIV for associating a heading with the corresponding section; this may help to achieve some presentational control, but it cannot serve the same fundamental purposes as true sectioning. (A user agent could be expected to use true sectioning information in a meaningful way, but it would be inappropriate to deal with all DIV elements as indicating sectioning.)
Structurally it would be better to have a uniform system with just one kind of nestable section element (which might be named SEC, for example) specifying a section, subsection, or corresponding lower level part so that a heading element (which might be named H) is required within it. (Perhaps even sectioning elements without headings might be allowed, and this might lead to a natural way of replacing the P element, simultaneously prodiving a subparagraph mechanism.) The heading element would be in a position similar to the HDL, SUM, CONCL, etc elements proposed below. That is, a heading would be just one constituent (although perhaps a required one) of a section structure, instead of being something which implicitly defines a section. Naturally, user agents would interpret the heading elements according to the level of nesting the sectioning elements.
The uniform system outlined above would imply that it is much easier to embed an HTML document to another, no matter whether such embedding is done using editors, authoring tools, servers, or user agents. Sections could be written so that they are not dependent on the level of nesting into which they will be embedded - no need to change H2 elements to H3 elements when making a document part of another document which already uses H2 elements for higher-level headings. This would make it simpler to maintain the same information in various forms and contexts.
Admittedly, the change would complicate some operations, preventing e.g. the extraction of all second-level elements from a file using a very simple method (which picks up all H2 elements). On the other hand, by that very implicitness, HTML code to be included into various contexts could be written or generated more easily and more naturally.
Probably the original reason for the simple (simplistic) system of headings with no section markup was to make browsers simpler: a browser can process each heading element in a context-free manner, just mapping the heading level to some particular font size and style, for example. At the present stage, CSS1 requirements already make the internal functions of browsers rather complicated. Moreover, adding simple bookkeeping (of nesting levels of sections) to browsers would not slow things down in any significant amount. Browsers might, of course, apply a more complicated, two-pass strategy which first counts the maximum depth of section nesting, then selects the presentation of headings of various levels appropriately. But that's just one possible implementation.
The role of the headings of sections, subsections, etc, is different from the heading of the entire document. Currently there is neither a recommendation nor established practice on the presentation of the document heading. Some authors use H1, reserving H2 for first level sections etc, whereas others use H1 for both, possibly attaching ALIGN=CENTER to the document heading. And several authors seem to feel compelled to try to control the presentation of the document heading otherwise, to make it more distinguished. This illustrates how the quest for presentation control reflects (in addition to misunderstanding of the nature of Web publishing, of course) the lack of suitable structured modes of expression. There should be a simple and single method for marking up the document heading and a simple and single method for marking up the sectioning, subsectioning, etc, and attaching headings to such parts. Probably the best way is to introduce a new element for the former purpose. (This naturally raises the question what the TITLE element would be for. A very good question indeed. More than often, novice authors get very annoyed when they see that their title text is not displayed. It is useful to be able to provide two different document headings, "internal" and "external", but not very wise to force authors to write both of them even if their texts are identical.)
Typically, H5 and H6 elements are abused to affect text font size, assuming the common but grossly illogical browser behavior of presenting in a font smaller than normal text. Since a well structured document can hardly contain more than four sectioning levels - division into several files should be applied to very large documents - the H5 and H6 elements should be declared deprecated.
The ADDRESS element is homeless, as the draft implicitly admits by excusing as follows: "For lack of a better place, we include the definition of the ADDRESS here." Since document author information is part of basic metadata, it should be expressed as metadata in a standardized format (with fields for first and last name, postal address, E- mail address, home page address, telephone, etc, and free text field for any additional information). If this can be achieved so that browsers will be able to display that data in a user-specified form, either as part of the document or separately, the ADDRESS element should be declared deprecated.
In most cases, text in a language other than the overall language in a document is some kind of quotation. (There are other possibilities, such as providing the same information on a page in several languages, but it is usually more advisable to make them separate HTML documents.) The text and examples in the draft are somewhat contradictory in this respect. There is real danger that the lang attribute will be used as a replacement for the logical elements for various quotations (BLOCKQUOTE, Q, CITE), not in conjunction with them.
The statement that the default language is "unknown" needs to be reformulated. Is the string "unknown" expected to be a language code as specified by RFC 1766, as the formulation (especially the use of quotes) suggests? In that case, it would be natural to specify the default value in the DTD, too. Or should the statement simply say that in the absence of any language specification, a user agent should assume that the language is unknown? What that means is an interesting question; probably it is assumed to disable all hyphenation (except where explicitly allowed) and some vanilla (but exactly which?) presentation of things like quotation marks. Notice that the current formulation could easily be understood so that in the absence of a lang attribute, "unknown" language is assumed for an element, while in fact the language information is inherited (as explain in the draft, but later.)
The wording in the subsection Inheritance of language codes seems to imply that a user agent may have a default value (which is some particular language, not "unknown"). While this might possibly be useful, it contradicts the idea of default language being unknown.
Most authors of documents written in (normal) English will probably assume that they need not provide any language information. The HTML 4.0 specification should explicitly recommend authors to provide language code for all documents, including those written in English. The natural way to do this is to include a lang attribute for the HTML or BODY element. (It is not really the job of Web servers to provide such information.) The draft contains a recommendation in this direction but only in the annex Performance, Implementation, and Design Notes and without explicitly suggesting the use of the lang attribute for all documents.
The exclusion of computer languages is in a sense understandable due to the urgency of support to human languages, but in the future mechanisms should be developed for expressing that part of a document is written in a particular computer language. The reasons for this are partly quite similar to the situations where information about human language can be used, partly specific to computer languages. For instance, if a document contains sample programs in some language, the reader might benefit a lot from the ability to see them formatted according to his personal preferences as regards to font usage, indentation, bolding or coloring keywords, etc. (Naturally, HTML should simply provide a generic mechanism for indicating the language so that an appropriate browser function or plugin, if available, could be automatically invoked by a browser.)
A simple way to include computer languages would be to define that lang attribute values beginning with "comp" refer to various computer languages (including command languages, programming languages, hypertext markup languages, etc). First people might start using just lang="comp" to have the element interpreted as being in some generic or unknown computer language, typically representing in a monospaced font (which might, however, be different from other monospaced fonts used in the display of documents). Later a method should be fixed how specific computer language names are defined and registered, similarly to the registration of Internet media types or charset values. In fact, even before such standardization people would probably use several values like "comp-C", "comp-Fortran-90", "comp-HTML", etc, in similar ways.
The example under the heading Inheritance of language codes is not really an example. Despite the lang attributes, all text there is in English. A real example could include, for example, a quotation from a book in French and some Latin terms within English text.
In the discussion of bidirectionality, the text refers e.g. to HEBREW2 as being Hebrew text, even referring to the "H" in it. Obviously there should be some text which is really in Hebrew. Similarly, examples on support for character directionality and joining should contain real Arabic characters and not just their names in Latin letters. One cannot really present examples of implementing multilinguality without giving honestly multilingual examples. (If this requires the use of images when working under HTML 3.2, so be it.)
The definition of white space is, as in previous HTML specifications, vague and implicit. Instead of giving a list of examples ("such as - -"), the specification should explicitly define the concept of white space in HTML context. In particular, it should clearly say whether no-break space is white space or not.
The draft mentions the PRE element as the only exception from the rules of whitespace handling. Both previous specifications and established and useful practice suggest that TEXTAREA should be treated similarly.
The set of phrasal elements is almost the same as in HTML 3.2, especially since the Q element is for some reason not classified as phrasal. Notice that the wording of the meaning of CITE is still unclear, as in previous HTML specifications, which have very often been misunderstood in this respect. Although there is less room for misunderstanding, if the Q element is included, the wording should definitely say that the CITE element is used to mark up an expression (such as a book title or code number for a standard) which constitutes a reference (citation) to an external source.
The proposed ACRONYM element is debatable. If it is intended to mean that the enclosed text is an abbreviation formed from the initials of a sequence of words, this should be defined explicitly in the specification. It should be empasized that the pronunciation of such an expression can not be deduced from the use of ACRONYM. The statement that "acronyms are generally spoken by pronouncing the individual letters separately" is either incorrect or irrelevant, depending on the interpretation of the words "acronym" and "generally". On the other hand, this means that the usefulness of ACRONYM would be limited to spell checkers, and for such use a more general element is needed, such as an element for any proper name. (Admittedly, browsers could utilize ACRONYM markup so that they somehow allow the reader see the value of the title attribute, giving the expansion. Notice that the draft neither requires nor even recommends that. Moreover, since a title attribute is allowed almost everywhere, authors and browsers could use such a technique irrespective of the introduction of an ACRONYM element.)
As regards to speech synthesis in general, the approach suggested in a note in the draft is unsatisfactory. Dictionaries are not sufficient. There are cases where an explicit indication of the pronunciation of a word is needed. To take a trivial example, the English word record has different pronunciations (and different word divisions) depending on its meaning. Therefore, at a later stage of HTML development, some way of specifying the pronunciation of an individual occurrence of a word should be provided. (This might be an attribute which takes a string of IPA characters as value.)
There is definite need for new phrasal (or in fact structural) markup. There are several reasons for the common use of font level markup, but one of them is that the available repertoire of phrasal markup is unsatisfactory. (The probably counterargument against adding new structural markup is that everyone should use XML. That kind of thinking would require separate discussion (see some notes above). Here it assumed that definite, well-defined, widely known and supported markup is needed for the basic structuring of Web documents. Extensibility in particular areas of application can be useful as an addition to that, not as a replacement.)
According to HTML 2.0 and HTML 3.2 specifications, the EM element denotes emphasis, but this is defined rather vaguely: "basic emphasis typically rendered in an italic font". (Obviously, the word "basic" here is to be read as opposing "strong" emphasis expressed by STRONG.) Ignoring the fact that the HTML 4.0 draft is even more laconic ("indicates emphasis"), the fundamental question is what does it mean and imply that something is emphasized. There can be several essentially different reasons to emphasize, or rather different emphases. For example, emphasizing a key word or phrase in a paragraph is quite different from emphasizing an entire paragraph (such as a summary). Using the same kind of rendering for both (whatever that might be in each browser) is unsatisfactory. For example, using bolded font might be quite suitable for emphasizing an important word, while for an entire paragraph some special background color or a red bar in the margin might be much better.
Consequently, we need different elements for different kinds of emphasis or, more properly expressed, essential structural elements which would replace EM and STRONG. (Obviously, for compatibility reasons the generic EM and STRONG elements should be preserved for the time being, but in the future they would convey the idea of emphasizing something without really knowing why.) In fact, HTML 3.2 introduced DFN for defining occurrence - something which was most probably marked up using EM by a structuralist author in HTML 2.0. Unfortunately DFN is not supported adequately by popular browsers, but it is definitely an example of the direction to take.
Further replacements for EM might be something like the following:
The OPP element is <EM>logical</EM> markup as opposite to <EM>physical</EM> markup such as the I element or the <EM>pseudo-logical</EM> EM element.
Notice that for several emphasizing elements outlined above, the typical renderings of EM or STRONG might not be optimal. For instance, it seldom makes sense to have a long paragraph displayed or printed in bold face just because it is an important summary. Such text is hard to read, and any method which catches the reader's attention and makes it clear that this is a summary is sufficient. It could be distinctive background color, a vertical line in the margin, or a short musical prelude. The point is that each of the emphasizing elements might have its own presentation.
Current HTML has two elements for emphasis of different strength, yet no element for deemphasis. Some people use the SMALL element or the FONT element with size attribute, but this is illogical. Still less should we use H5 and H6 elements for deemphasis, as many authors seem to do! Moreover, expressing deemphasis with font size change is just one possibility, which might even be technically not available in several situations. Even if it can be done, it might not make sense. A good browser customization sets normal text font size to something which is conveniently legible, yet not larger than required for that. This means that anything significantly smaller might be illegible to the user. Thus, deemphasis might more suitably be expressed by using (perhaps in addition to small decrease in font size) smaller vertical space between lines, a different font, a different background color, some indentation, some drop in the volume of synthesized speech, or perhaps making the deemphasized text into a footnote. Naturally, some of these presentational methods are applicable only if the deemphasized text is a whole paragraph (or more). Demphasis within paragraphs might be expressed simply by putting the text into some kind of parentheses or brackets.
Since emphasis is actually a set of rather different things, for which different elements were proposed above, doesn't this apply to deemphasis, too? To some extent, yes. Probably the most usual kinds of deemphasis would be covered by the following new elements:
The semantics of nesting has never been discussed in HTML specifications and drafts, except very marginally. For example, the only thing that the HTML 3.2 specification says about nested text elements is the following:
User agents should do their best to respect nested emphasis, e.g.So it does not really specify the semantics but gives a vague recommendation about rendering. It describes the B and I elements as emphasis, probably supporting the popular idea of STRONG and EM being just snobbish words for B and I. Semantically, it seems to imply that the effect of nesting is additive (cumulative). But is this really so in general, and should additiveness be interpreted with respect to the logical meaning or with respect to rendering?This has some <B>bold and <I>italic text</I></B>.
For example, assume that we have a STRONG element which contains an EM element. Which one of the following interpretations should be applied?
The draft contains the Q element, which is a text level counterpart of the BLOCKQUOTE element. An element for designating quotations is definitely needed. However, instead of prodiving two quotation elements, we should reconsider the idea of having text level and block level markup as a fundamental division. (Notice that style sheets have already made this division somewhat irrelevant.) Essentially, block level markup is something which involves some kind of paragraph breaks. Isn't this a presentational feature, not structural property? Moreover, the simple idea of something being a quotation need not be mixed up with paragraph division. The quoted text itself may or may not consist of paragraphs, and this should be indicated separately, using the normal markup for that.
Generally, the division into block and text level elements provides superficial structurality only. Perhaps there are some elements which might reasonably be restricted so that may not contain some specific "higher level" structures. But the current restrictions are excessive. There is, for example, no logical reason why an emphasis could not be applied to a sequence of paragraphs. The presentation of such emphasis might differ from emphasizing a few words, but this should not be of fundamental importance in the design of the HTML language.
Now, returning to the issue
of marking up quotations,
a logical solution
would be the following. The Q element is
introduced so that it may appear either as a text level or as block level
element. By itself, it does imply paragraph breaks. For compatibility,
BLOCKQUOTE is preserved (as a deprecated element) and defined so that
<BLOCKQUOTE>quotedtext</BLOCKQUOTE>
is equivalent to
<P><Q>quotedtext</Q></P>
Deprecation BLOCKQUOTE would be wise for the additional reason that it
is so commonly misused as a mechanism to affect layout (indentation).
Notice that the draft encourages such misuse by describing
indentation as the normal rendering (which is an oversimplification)
and by recommending that user agents not insert quotation marks due to
the widespread use of BLOCKQUOTE for indentation. (It is not clear
how speech-based user agents should behave according to such
philosophy.) When the draft then says that the usage of BLOCKQUOTE
to indent text is deprecated in favor of style sheets, it will hardly
be taken seriously.
The concept of quotation should be clarified. Otherwise many people will be tempted to mark up phrases which are direct borrowings from other languages (like force majeure) as quotations. (If desired, the language of such phrases can be indicated using a SPAN element with the lang attribute.) Thus, a quotation should be described as a direct (or perhaps slightly edited for technical reason) quotation of text from some source, normally so that the source is explicitly mentioned.
There is important phenomenon of using words in a quotation-like manner without really presenting quotations: presenting words and phrases as linguistic objects. Linguistic objects need not be anything more complicated than the word "cat" (which is definitely different from any cat). In printed texts, there are three common ways to indicate them:
As regards to HTML, such "quoting" of words deserves an element of its own. Otherwise there will be confusion, since some people will use Q, some others will use physical markup (according own their own presentational preferences), and some people will think they should use the lang attribute (which might cause different rendering when the linguistic objects are from another language than the surrounding text!). Perhaps some people will even think that the SAMP element is suitable (it was clearly suggested for this purpose in HTML 2.0!).
An important related problem is how to mark up extracts of computer code (such as commands, scripts, or program code) and man-machine interaction which takes place textually. To take a simple HTML related example, how should we mark up the word "alt" when writing about the alt attribute in HTML? The most obvious solution is to use the CODE element, regarding it as a (small) fragment of computer code. Strangely, the HTML 4.0 draft uses the SAMP element, using the class attribute and a style sheet to affect the rendering, although it clearly defines SAMP to be used for "sample output from programs, scripts, etc". (This is a typical although mild example of illogical markup to which CSS1 leads. Could we expect normal authors to behave better than W3C?) One might say that when one refers e.g. to the alt attribute in normal text, "alt" acts as a linguistic object: we are referring to a word or phrase in a language.
The natural solution would be to deprecate the CODE element in favor of using any suitable element with a suitable lang attribute referring to the particular language (or perhaps a computer language in the generic sense). This would, however, require that the language support be extended that way.
When quoting a text, one should normally cite the source; in many situations, this is even compulsory by law. But the meaning of the proposed cite attribute of BLOCKQUOTE and Q is vague. First, should it imply that the quotation was actually taken from the resource to which the URL points? Or does it suffice that the resource contains a copy of a document from which the quotation was taken? Moreover, should the URL point to the source document in general or should it try to pinpoint (using a fragment identifier, for example) the location where the quoted text appears there? Last but not least, should the cite attribute appear instead of a tradional designation of the source or in addition to it? The example suggests the former. However, there is no requirement that browsers should show the cite attribute in any visible way. And there is no obvious way they could do that in general. The BLOCKQUOTE example in the draft is a quotation from a book. The normal method - which might be regarded as legally obligatory in some cases at least - is to specify to book by its title and author and possibly some additional bibliographic data. Providing a link to a copy of the book on the Web can be very useful, but it should not be regarded as a substitute for a normal citation.
There could be a structured element, to be used within a quotation element only, for specifying the source in textual formal, as a normal citation. This needs some elaboration so that a suitable format can be developed which is reasonably simple, yet rich enough to express the most basic information. It would be natural to specify the URL of a copy of the source there and not in the quotation element.
The SUB and SUP elements are currently quite controversial. The draft seems to take the position that they are to be used for presentation issues only. Whether that would imply a definite change from HTML 3.2 is debatable. In any case, the specification should explicitly state whether SUP should be used for mathematical exponents or not. (Currently it is often used that way, and there is some pressure to do so, due to the lack of mathematical notations in HTML.)
Hyphenation is an important but difficult problem. It is often suggested that authors should be able to indicate hyphenation points. This is, however, just a minor and exceptional ingredient in any reasonable solution of the hyphenation problem. Moreover, it is generally not powerful enough, since word division may involve changes in the spelling of the word.
The soft hyphen has often been assumed to be an invisible hyphenation indicator according to ISO 8859-1. However, in fact the soft hyphen is a visible character. Naturally HTML specification may define some specific semantics for that character, and the HTML 4.0 is the first attempt to do so. Technically it is possible to define that it is treated as a "discretionary hyphen". (Whether it is wise to do so is debatable. There are several solutions which would be more natural and of more use, e.g. defining a special element like <WBR>, possibly with an attribute which allows the author make some word division points more preferrable than others, or introducing a new attribute to be used as in the following: <SPAN hyp="rec-ord">record</SPAN>.) The following points should be observed: The current wording seems to prohibit the use of the soft hyphen as such in an HTML file, which is exceptional, since obviously any other ISO 8859-1 character may appear as such. The current wording is obscure when it says that "the plain hyphen should be interpreted by a user agent as just another character". This seems to prohibit word division in compound words where the components are separated with a normal hyphen. It is normal to regard such word division as acceptable, even as one of the most recommendable word division points. The treatment of soft hyphens within preformatted text (where it might well appear in its original use specified in ISO 8859-1) should be specified; the current wording seems to imply that it should be removed when the document is rendered!
Elements for marking document changes are definitely needed. The draft contains INS and DEL elements but no element to specify a change in the sense of replacing some text by a new version of that text. The explanations refer to marking changes, however. It seems that the idea is to indicate a change by having the old text withing DEL and the new text within INS. This is theoretically illogical, since completely deleting something, inserting something completely new, and changing something (perhaps just a little) are three different kinds of editing text. It is also practically very inconvenient, since the normal way of indicating changed texts is to use something like a change bar in the margin, and this cannot be done without knowing what has been changed. (Recognizing adjacent INS and DEL elements would be a clumsy solution and not a correct solution, since there is no guarantee that they actually belong together indicating a change, instead of something completely deleted and something completely new inserted just accidentally appearing one after the other!)
Thus, an element indicating change (replacement) is needed, too. It could be named CHG, for example. In addition to an attribute pointing to information about the reason for the change, there should be another (optional) attribute (like OLD) pointing to a document containing the previous version of the text. This would allow user agents to provide some simple way of accessing the old text, perhaps displaying it in another window for comparison.
In addition to insertions, deletions and changes by the document author, a document or part of it can be submitted to an editorial process. The draft provides no obvious way of distinguishing them from other changes. Naturally, one could use the cite attribute to refer to a document explaining that the changes have been editorial, but this would be very clumsy for normal editorial things. A partial solution to this would be to extend the URL concept to allow "inline resources", i.e. a scheme which specifies that the rest of the URL is not an address of a resource but a literal resource, a piece of text (using some suitable literal notation and encodings). But such a solution, although desirable, would not allow a simple, uniform treatment of the most basic and usual kinds of change.
Perhaps there should be an attribute, with a set of keywords as possible values, indicating the nature of the changes in rough terms. Referring to a reason, in the sense of providing the URL of an explanation, plays a different role; it cannot form the basis of selecting different renderings for different changes. For example, in manuals it is often practically very important to distinguish between changes which try to improve the description of a program and changes which reflect changes in the program itself. Those keyword values might indicate document changes due to changes in the reality described (such as changes in a manual of a program due to changes in the program itself), improvement of the wording or structure of the document (by author), error correction (by author), editorial changes (for journalistic reasons), and changes in quoted text (such as omitting irrelevant parts or adding explanatory words) when including quotations. This would allow each user to define suitable presentation styles for those kinds of changes that are important for him to distinguish (in general or in some particular situation).
The date and time format defined in the draft is extremely theoretical. Despite being formally an ISO standard, it is rarely used in the world, except by some extravagant enthusiasts. It also deviates from well-established Internet usage defined in RFCs and referred to even in the HTML 4.0 draft in other contexts, such as the syntax if HTTP headers. - User agents should be encouraged to allow readers see the change timestamps, upon reader's request, and perhaps in a time format defined by the reader or by the browser settings. And authors should be discouraged from writing stupid INS elements like the one now given as an example in the draft. It should be explicitly said that the contents of an INS element should be simply the inserted text. It should not contain an explanation of the insertion (the cite attribute exists for such purposes), still less consist only of such an explanation!
It would be quite appropriate to deprecate DIR and MENU in favor of UL, if browsers were clever enough to analyze UL elements is display them in directory list or multicolumn or some other format, selected on the basis of the list as a whole. But au contraire, most user agents are not able to use a simple directory list or multicolumn format even if explicitly instructed to do so (by the use of DIR or MENU)! Even more absurdly, both specifications and browser makers seem to be much more anxious to work on tiny details like numbering style of list elements.
The key question should be the following: How should a list presentation format be selected? Should it depend on the nature of the list or author's or user's preferences? Exactly how? Such problems should be solved before simply throwing DIR and MENU away.
The draft lacks elements for list headers. This is serious, since it is now impossible to express lists in a structured way. There is currently no way to indicate logically that a piece of text is a list header or an explanation (or a legend) of a list. (Notice that these are two separate concepts.) Thus the reader has to spend his time in finding out the structure which should be expressed in HTML and in the visible presentation in the first place. A simple solution would be to introduce an element for a list header (as in the HTML 3.0 proposal). An even simpler solution would be to modify the syntax of list elements so that at least text elements (to be interpreted as the list header) were allowed within a list element before the elements for items in the list.
More fundamentally, defining lists as block level elements which cannot appear within a paragraph is unnatural. As David Perrell has said so clearly,
A list rarely if ever stands alone as a concept. A list is usually an appendage to a paragraph, not a separate entity. To give a list equal space above and below is not a reasonable presentation.This is actually related more to the paragraph (P) element than the list elements. Originally there was an (empty) P element used as a paragraph separator. This idea never got into any official specifications, but it still survives in its way. The "convenient" principle that an end P tag is omissible has a very high price. It implies that paragraphs are not nestable and cannot contain block level elements. This serious restriction is often circumvented by using lists instead of paragraph structuring, since lists are nestable. That solution is neither logical nor practical; as the size of list elements grows, typical list presentation becomes inconvenient.
The optimal solution would be to simplify and unify the basic structuring elements in HTML. This means some kind of true sectioning. The uniform concept of nestable sections with optional elements for headings, summaries, etc, would make separate elements for lists unnecessary. For example, a simple section containing a set of sections containing just text could, depending on user preferences and other factors, be presented as a list of items (numbered or not) or as a sequence of paragraphs or as a table containing the subsections in a sort of multicolumn format.
Definition lists deserve special discussion. A definition list is in a sense comparable to a table with two columns. Another view, a more logical one, is to regard it as a simple list of items, each of which is an ordered pair consisting of a definiendum and a definiens. The question arises why the inner structure has no logical markup by itself. If I only wish to present one definition somewhere in my document, should I write a definition list containing just that? That would mean that I accept that it is typically rendered in a strange way, and I cannot embed my definition into a normal paragraph, for instance.
Since HTML 3.2 we have a separate element, DFN, for designating something as a defining occurrence. But there is no way to indicate what part of the document constitutes the definition. And it seems that little attention has been paid to the relationship between definition lists and DFN. It would be natural to assume that normally a DT element is displayed in a manner similar to DFN or that at least some special presentation is used for DT due to its very nature. But the HTML 4.0 draft seems to assume that this is not the case: the example uses explicit EM element to mark up the terms within DT elements!
Designating definitions as definitions clearly and in a uniform manner is important for the purpose of suitable (and user-customizable) rendering of such crucial things in documents. But it is even more important for search engines and user-friendly tools in browsers. If a document would use the same basic markup for all definitions (indicating clearly the term to be defined and its definition), search engines could extract the definitions easily. Notice that very often people wish to find definitions for terms, not just any information related to term. Moreover, a document which is clearly marked-up in this respect would allow a browser to present a list of definitions to the user. This would be much more sensible than explicit links to definitions from all occurrences of terms in a document.
An obvious solution would be that there is one recommended way of presenting a definition: a DT element followed by a DD element. This could be rendered in a more or less distinctive manner, depending on the browser and on user settings. The DFN element would be deprecated but interpreted as if there were a DT element with no associated DD element. And the DL element (containing DT and DD elements) could still be used for the purpose of grouping definitions together, perhaps with some effect on layout. Alternatively, completely new names could be introduced for elements related to defining. A practical reason for that would be the widespead misuse or incorrect use of DL, DT, and DD.
It is probably impossible to define a suitable structured table model in a short period of time, still less to gain acceptance to it. Therefore, if a new version of HTML is to be defined within a few months, there are three practical options:
However, for the purpose of future work on tables, the following notes are made here:
Essentially, a table differs from a nested list (a list with lists as elements) only by the sublists beings structurally similar. (Astonishingly, this essential feature seems to be neglected in HTML table specifications and proposals; there is even no requirement on rows having the same number of elements!) Thus, a logically designed table model would provide a method for specifying, in addition to the data in a table, the logical structure of each row. (Naturally, this would make useful syntax checks possible.) This may or may not involve specifying visible or audible row or column headings for a table.
The very table structure should indicate whether a column contains, say, integers, numbers with decimal point, images, words or short phrases, or text paragraphs, for instance. The repertoire of such alternatives can be difficult to define so that it meets practical needs, but such a job would be necessary for a structured table model. The current trend of adding enhancements to presentational attributes inevitably leads to unmanageable complexity, in addition to encourageing the use of tables for mere layout. It should be left to browsers and readers to define a suitable presentation by mapping each of the column types into some way of rendering (such as aligning integers to the right in a visual presentation).
As an example of unnecessary complications caused by unstructured table models, consider the COLS attribute proposed in the draft. It is proposed as an efficiency enhancement. It is questionable whether it helps a browser to know the number columns beforehand, since it does not know anything about the space and format needed for the columns. Knowing just the number of columns isn't that much! If one wants to allow fast formatting of tables, so that rendering may begin before reading the entire table, then the beginning of a table element should specify the number of columns implicitly via the structure specifications for each column (as outlined above). For further optimization a browser would need information from which it can compute suitable widths for columns, for instance in the form of "sample elements" (written to reflect largest possible real elements). But it is debatable whether such optimization is really needed at all.
The draft, after introducing the COLS attribute (as something new when compared with HTML 2.0), the recommends authors to avoid it, using COL and COLGROUP elements instead. (This might be somewhat half-hearted, since the draft itself uses COLS in an example.)
On the other hand, the draft appears self-contradictory in this respect. Under the title Anchors with the id attribute it says that the attribute is used to position an anchor at the start tag of an element! (Moreover, the example, or rather the sketch, given there associates the name "section2" with the heading of a section, not with the section as a whole, which is normally a more meaningful association.) An example uses the wording "location of anchor one", followed by a statement which speaks of zone. The draft also mentions empty A elements, suggesting that they should be avoided, but due to the behavior of some browsers, not for the logical reason that referring to an empty zone seldom makes sense!
Since the draft contains the important type attribute for the LINK element and for the OBJECT element, the question arises why there is no such attribute for the A element. The draft says, referring to some attributes related "internationalization", that 'armed with this additional knowledge, user agents should be able to avoid presenting "garbage" to the user'. Obviously, information about the media type would play a crucial role here. Logically, a browser needs to know the media type in order to know what to do with the resource (e.g. displaying an image in some format or launching an application which can handle resources of that type). Even if the resource is accessed via the HTTP protocol and it is served with content type information, a type attribute in the HTML construct for the link would allow the browser check that the types match. Such type information would also be useful in a variety of other ways, such as allowing search robots to classify and characterize documents on the basis of the types of links they contain.
Notice that the draft contains a charset attribute for the A element, thus providing a tool for expressing some of the information which could be expressed within a type attribute. It would be important to replace it by the type attribute. Moreover, the use of this attribute should be strongly encouraged (in all A, LINK, and OBJECT elements).
The semantic definition of the type attribute should be clarified. Notice that the draft very vaguely says that type and media attributes for LINK are "header style information". The DTD fragment oddly says that it is an advisory Internet content type. (And notice that a reference to RFC 2045 elsewhere in the DTD is just a comment, and consequently has no normative value. Moreover, it is practically somewhat misleading, since the media types are defined in RFC 2046.) The definition of the type attribute should something like the following: "The value of a type attribute specifies an Internet media type (content type) for the resource referred to. It consists of a top-level media type and a subtype, optionally followed by parameters which may specify properties such as character encoding (charset parameter). The Internet media type shall be specified according to RFC 2046 and related specifications. Use of the type attribute is strongly encouraged. In the absence of a type attribute, user agents will have to deduce the media type from sources external to the HTML file or even guess it."
The standardization of (basic) link types (REL and REV values) would be crucial for the development of the Web as a reasonably organized forum for hypertext publishing. The draft lists some values without making any requirement on or even suggestion to supporting them. Authors "may use" some "recognized" link types which are claimed to have "conventional interpretations". The content of list could be discussed a lot, but it is sufficiently useful to be publicly approved in the following sense:
The draft does not actually define the meaning of the OBJECT element. The structure of element specifications is especially annoying here, After a long discussion of the attributes, the text just starts explaining: "Most user agents contain mechanisms for rendering common data types - -". The very meaning of the OBJECT element is left implicit.
The principle that the content of an OBJECT element is a replacement for the object specified in the OBJECT tag is not emphasized. In fact, it is expressed in a relatively indirect way, as a requirement on browser behavior. The principle itself is debatable. It does not sound natural, does it? Obviously we need something better than the simple ALT attribute of the IMG element, but the idea of nesting OBJECT elements in order to specify alternatives is weird.
Moreover, the philosophy behind the OBJECT element seems to be that of graceful degradation, implying the idea that a more "advanced" form of presentation (such as animation) always should have precedence over less "advanced" (such as static images, which in turn have text as substitute). Although things might be that way in some cases, the principle is far from being universal. Even if I can view animations, I may have different very good reasons not to view them in situations where there are other alternatives.
In fact, an "advanced" object seldom has good replacements. This seems to apply at least to the examples in the draft, since they provide "alternatives" like the text "An animated clock" (thus confusing the title of an animation with a replacement for it) or "The Earth as seen from space" or, even worse, "This user agent cannot render Python apps" and the nerdish "You're missing a really cool poem viewer ...".
If an object has meaningful replacements or, rather, if there are alternative presentations of some message, then the natural method would be to provide some sort of menu from which the user (or in some cases the user agent) can select. This could be done using a simple list construct with links inside. If, however, we would like to have some sort of autoselection so that the user sees a presentation of the message embedded into the document, then something like OBJECT element could be used. But this requires that there is some structured mechanism for specifying that a set of OBJECT elements is to be treated that way. Since embedded objects can appear one after another, mere sequentiality is not enough.
The draft uses nesting of OBJECT elements to indicate alternatives. Even if there are reasons to suggest some order of preference, nesting emphasizes it too much. A natural solution would be to have a specific element, let us call it ALT, for specifying that the objects within it are alternatives to each other. (Selection among them would be affected by their textual order, which would be taken as the author's recommended order of preference, and by user settings which may specify e.g. that several image formats are accepted but in a particular order of preference.) Within such an element, anything following the OBJECT elements would be interpreted as the alternative to be taken when none of the objects is selected for presentation. (Admittedly, having that alternative, which is typically textual, in a symmetric position with respect to the others would be more natural.) This means something like the following:
<ALT>
<OBJECT TYPE="image/png" DATA="myhorse.png">
<OBJECT TYPE="image/gif" DATA="myhorse.gif">
<OBJECT TYPE="application/postscript" DATA="myhorse.ps">
My horse is a handsome black stallion.
</ALT>
Perhaps some better structure could be developed than the one above. The basic point here is that it should be a list, possibly an ordered ordered list, not a nest.
The difference between a description of an image and a substitute for it is crucial, of course. The old controversy about the use of the alt attribute of the IMG element revolves around the problem that there are cases where it seems necessary to use that attribute for the description, while the intended use is for substitutes. This problem should be removed from HTML by providing suitable methods for both purposes. Basically, the type and title attributes of an OBJECT element, when used appropriately, mostly serve the needs of describing images and other objects. Therefore, any construct corresponding to the alt attribute (such as the content of an OBJECT element according to the draft) should be regarded strictly as a substitute for the object. It should be something which is meaningful and useful even if (and especially if!) there is no way to access to the object itself. The draft does not say this clearly, and its examples seem to imply just the opposite.
In addition to the inherent problems described above, there are other serious problems in the design of the OBJECT element in the draft:
The draft contains an example of including an HTML file into another HTML document by making use of the OBJECT element. This sounds like a nice way of including an inclusion facility as a byproduct of a general-purpose element. However, since the semantics of the OBJECT element is vaguely defined, we must just assume that the example in the draft really means the following:
.html)
or the HTTP headers are used to determined the media type
It would seem very natural to assume that using an OBJECT element with type="text/plain" is a way to include a plain text file as if its content appeared in the document within a PRE element. The draft should either say that this is so or warn against this obvious interpretation.
The draft contains a rather complicated description under the heading How to specify alternate text. Contrary to what that heading suggests, the text contains, after some guidelines to authors, recommendations to (or requirements on?) browsers. Instead of clearing things up, the recommendations are confusing. First, why recommend anything new as regards to IMG and APPLET elements which should not be used in new documents (assuming that a suitable OBJECT element is available)? Second, by suggesting that the value of a title attribute be used as alternate text one messes up the ideas of description and substitution. Recommending (or requiring?) that browsers extract text from GIF images is hopefully just a strange joke. (If an author, instead of writing a decent heading element, embeds an image containing a heading text, without providing an alt attribute, should a browser really act as a text scanner to decipher the words?)
In short, style sheets are not wonderful.
<P type="text/css" style="font-size: 12 pt; color: fuschia">is just a perverse way of writing a FONT tag, although the FONT tag is more structured in the sense of not specifying font size using physical measures. (The example also exhibits, as minor perversions, an incorrect spelling of a color name and a reference to an unregistered Internet media type.)
The HR element is present among elements for physical markup, and it is described as a presentational element. It should be described as an element for change of topic, which can be rendered as a horizontal rule. If true sectioning is introduced into HTML, the HR element should be declared deprecated.
Frames are an expensive plastic imitation of windowing, to be used in environments where true windowing is readily in use. They are tårta på tårta (Swedish saying, 'cake on cake') and make windowing clumsier.
Graphical browsers typically allow the user to select, when following a link, whether the document is loaded into the current window or a new one. A normal link (with no target indication) works fine for that purpose. Browsers should be improved so that they support viewing two (or more) documents at a time so that links from one document to another can be followed smoothly (using an existing window for a document instead of opening a new one). For instance, one of the documents could be an index page for a site. There is no need to add any special framing features to HTML documents or the HTML language for the purpose.
Forms handling has been rather primitive in HTML. For instance, there is no way to check input data before submitting it. And there is no way (within HTML) to make a form really interactive in the sense that the form changes when it is being filled (so that e.g. selecting an option causes some of the input fields to be omitted due to their being irrelevant).
Perhaps this is as things should be, leaving advanced interaction to be handled by various scripts. This causes restrictions and incompatibilities, since there is really nothing an author of a form may assume about the support to various scripting methods. Thus, if this approach is selected (or kept), it would be desirable to require support for at least one scripting language in all browsers conforming to HTML specifications. (Such requirements would be quite normal, comparable to requirements on supporting at least one specific character encoding.)
Alternatively, the HTML forms concept could be enriched by providing HTML methods expressions for things like requirements on input values. We already have expressions for single-line text input and multi-line text input as well as selection from a fixed set of alternatives. Adding more complicated requirements like numerical input field (which must provide a value within a given range) would not be anything drastically new. If expressed in HTML, such requirements could be reflected in the presentation of forms. For example, a browser might be configured to display numerical input fields in a distinguised color (by user option), and the user would have a clear visual hint about a field requiring numerical input. Naturally, it would take a lot of work and time to define such a forms concept and agree on it.
The draft makes the forms concept more complicated, but mostly not in the useful direction outlined above. On the contrary, there are even some features which have been designed to allow authors (not readers) have more control over the presentation of various fields. For example, the BUTTON element, by allowing "richer presentational possibilities", makes it more and more difficult to readers to recognize the various parts of forms as being what they are.
In current HTML, forms suffer from being unstructured: an author cannot indicate that some text is a title or an explanation for a text input field, for example. The draft proposes methods especially designed for forms. The question arises: shouldn't we use more generic structuring methods instead?
In particular, assuming that true sectioning were introduced to HTML, it would be natural to interpret a sectioning construct within a FORM element as constituting a field, or perhaps fieldset. The heading of such a section would be interpreted as the label for the field; browsers might indicate this structure in some suitable manner Any other content except form field elements would be interpreted as an explanation of the field (to be displayed only upon special information request from the user, perhaps).
The draft contains several complications to the forms concept due to focusing. Perhaps one reason to this is that some browsers do not automatically focus on the first input field of a form. The proposed cure is, however, much worse than the disease. An author should simply put the fields of a form in the natural order, i.e. the order in which they are to be filled, and expect browsers do their job accordingly. (As regards to changing forms dynamically, see remarks above. In this respect, the solution proposed in the draft complicates HTML but without solving the problem: it leaves the dynamics to be handled by scripts.)
An example in the draft uses an action attribute with a mailto URL. Since a widely used browser family fails to conform to specifications in this respect, with very harmful results, it is unwise to present such an example without a warning. Moreover, using a mailto URL for sending the content of a form by E-mail isn't very advanced, especially if the encoding of the content is x-www-form-urlencoded (as in the example).
Another example (related to FIELDSET and LEGEND elements) contains a form for submitting very personal information, including medical history. Taking into account that in many countries such information is strongly regarded as confidential data to be especially protected (see e.g. EU directive 95/46/EC), it should be emphasized that such data must not be submitted unencrypted in an open network (which is the typical way of submission on the Web).
Especially for small tasks which (currently) need to be implemented with scripts, it would be crucial to know which language to use to achieve reasonable accessibility. And probably most uses of scripting are made in order to do rather small tasks.
The idea of embedding scripts into HTML documents may have some technical benefits, such as avoid separate transmissions of small files, but it seems to have made several people confuse scripts with HTML things and scripting languages with HTML. Moreover, the text under the heading Syntax of script content (and under Commenting out scripts) eloquently shows what practical problems arise when languages are mixed this way.
The natural solution would be to associate scripts with HTML documents so that the HTML document only gives the URL for the script file (and its media type). Thus, the SCRIPT element should be simplified so that it has empty content and must refer to the script using a src attribute.
The semantics of the SCRIPT element is vaguely described. For example, exactly what is the difference between having a SCRIPT element in the head part and having it in the body part? An when the draft says that a script is executed "when the document loads, or at some other time such as when a link is activated", shouldn't it say things a bit more specifically?
It needs more justification than the draft gives to make it reasonable to include the repertoire of "intrinsic events" into HTML. The examples given are not very illustrative. For example, as regards to checking the contents of numerical input field, HTML based constructs should be developed instead of every author writing his own code in this own favorite scripting language (which may or may not be supported by various user agents). Most of the other examples are too generic to give any idea of why an event handling is needed and whether there could be a more HTML like solution to the problem (if there was a problem before creating one with scripting).
As regards to designing documents for user agents that don't support scripting, the draft seems to based on "all or none" thinking: either a user agent supports scripting in any language, or it does not support scripting at all. The formulation in the draft is somewhat obscure, but it seems that the NOSCRIPT element be rendered by such user agents which do not support client-side scripts at all. However, the meaningful processing would be that a NOSCRIPT element be rendered if the particular scripting language (or perhaps the particular script?) used in the corresponding SCRIPT element is not supported by the browser.
Obviously, this raises the question why such situations are not handled be regarding the scripts as objects instead of introducing a new kind of element. The object approach would allow the specification of alternative presentation using the general tools for that as well as the specification of alternative scripts in different languages to accomplish the desired task.
SGML reference information for HTML is normative of course, but its basic content, apart from some syntactic details, is (or should be) contained in the specification, so it is not commented here. Howeverm notice that additional character entities are a good thing to include into HTML, but they should also be specified in the specification itself, in an SGML-free compact tabular form.
The rest of the material consists of more or less technical annexes, the last of which is unwritten. The appendix which lists changes between HTML 3.2 and HTML 4.0 is far from being exhaustive. For example, it does not even mention a large number new attributes. On the other hand, it repeats information such as motivation for some changes which does not belong here.
The appendix Performance, Implementation, and Design Notes is a strange collection of mixed notes. For example, it "informatively" describes search engine and robot behavior without citing anything or referring to relevant recommendations or guides. It also presents a long explanation of the adopted table model, reflecting an even more presentation-oriented way of thinking than the model itself.
Jukka Korpela