Re: My humble comments on the HTML 4.0 draft

On Tue, 8 Jul 1997, Russell Steven Shawn O'Connor wrote:

> 1. First over all I like it. :-)

Thanks. Any suggestions you have for making it easier to understand
will be most welcome.

> 2. Question which is better
> 
> <HEAD>
> <TITLE>Foobar</TITLE>
> <meta http-equiv=Content-language content=en-CA>
> ...
> 
> or
> 
> 
> <HEAD lang=en-CA>
> <TITLE>Foobar</TITLE>
> ...

I suspect that as currently specified its better to place the
lang attribute on the HTML start tag rather than on HEAD.
The spec tries to distinguish the character encoding used for
the document from the language. For the character encoding, you
use the charset parameter on the content type, e.g.

  Content-Type: text/html; charset=euc-jp         /* in HTTP */

/* and in the HEAD */

 <META http-equiv="Content-Type" Content="text/html; 
    charset=euc-jp">

The HTTP Content-language header says something different.
It lists the langauges used in the document as a basis
for selecting a document that matches the user's preferred
language. We therefore recommend the document uses the
lang attribute to specify the language for each part of
the document. The simplest course is to place it on the
HTML start tag e.g.

    <HTML lang=fr>

> I was going to suggest a Content-language example in the Meta element
> section, but if there are already enough examples or the 2nd method from
> above is preferred, then maybe it doesn't matter.

I now think that this might help to clarify the distinction between
language/encoding and the role of language for content negotiation
versus its use for hyphenation, speech synthesis etc.

> 3. Your Link example seems strange and wrong to me.
> ...
> 
> This uses rel="Prev"  Is "Prev" different form "Previous"?  I
> think this last way is correct.  Where is there official
> documentation of the use of LINK elements?  This is the way
> I've been using LINK: 
> 
> -- From my source (ff5.html) --
> <LINK REL=next REV=previous HREF="ff6.html">
> <LINK REL=previous REV=next HREF="ff4.html">
> <LINK REL=TOC HREF="ffindex.html">
> -- --
> 
> Anyhow, I'm very confused now.

My apologies. The Tuesday draft failed to include the most upto
date version of the revelant file in which this was cleared up.
Basically, both "previous" and "prev" are used and are essentially
interchangeable.

> 4. Lynx supports <![ IGNORE [ foo ]]>.  I think it would be nice
> if this was in the specs.  Or is it implicitly there because HTML
> is an SGML application? 

This part if the spec is inadequate. Currently very few HTML user
agents support SGML marked sections. The spec ought to come clear
about this.

> 5. Why is Applet Deprecated, but IMG is not?
The members of the W3C HTML working group feel that APPLET is a
special case of the more general OBJECT tag, dedicated to one
media type - Java. The suggestion is that APPLET be phased out
in favor of OBJECT over a period of time. If/when that occurs
APPLET may then be obsoleted in future versions of HTML. IMG on
the other hand seems so firmly entrenched that it will stay around
for a long long time and can be considered as a sugared syntax 
for OBJECT for use with images.

> 6. Why is U (Underline) Deprecated, but others like TT and B are not?
U is not supported as widely as say B or TT. Furthermore, its
conventional in the Web to used underlining for styling hypertext
links, and in any case many people view underlining as bad
typography - a hang over from type writers - and problematic for
the wide range of fonts people want to use today.

B, I and TT are very widely used and firmly entrenched to the point
that they are just forms of emphasis with accepted renderings
for GUI based browsers. There isn't really much difference  between
I/B and EM/STRONG in this respect. Speech renderers have not
problems is providing appropriate renderings for them.

> 7. Should <A NAME=foo> be deprecated? (replaced by <SPAN ID=foo>)
> It seems odd to have 2 completely different ways of marking link
> endpoints in a document.. And obviously the ID method is better
> because validators can check for name collisions. 

In the long run, I would like to phase out the use of the NAME
attribute to define anchors. The <A>..</A> element would remain
reasonable though since it denotes an anchor.

> 8. Is DOCTYPE case sensitive?

I need to check on this.

> 9. I'm a little concerned about all these onclick event etc.  Just
> as style sheets have been separated from the HTML because it is
> screen (layout) oriented, Shouldn't these be pulled out as well? 
> Put into something else?  How can texted based browsers possibly
> deal with them. 

My original hope was for a cleaner separation between HTML and
scripting. In most cases, scripting usally assumes that the
document is being viewed on a GUI browser. There are exceptions,
e.g. for verifying form fields where onchange is meaningful.
Declarative representations for document components makes sense
but market forces have led us away from this.
 
> 10. Performance, Implementation, and Design Notes When I load this
> section I get a whole bunch of Javascript errors.  I'm running
> Netscape 4.0 under NT. Anyone else have this problem? 

This appears to be a problem with NS 4.0. Its fine with NS 3.0.

> That's all I noticed for now.  Some of my answers may be buried in
> the Specs.  I didn't go over it all that carefully.  If I missed
> something obvious I'm sorry. 

Thanks for the input.

Regards,

-- Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
phone: +44 122 578 2521 (office) +44 385 320 444 (gsm mobile)
World Wide Web Consortium (on assignment from HP Labs)

Received on Wednesday, 9 July 1997 11:39:21 UTC