Re: HTML 4.0 comments

"Ian B. Jacobs" <ij@w3.org> says:

> Thank you for your careful reading of the spec - where were you during
> the final editing process!

Sorry, it was the end of the semester.

> Therefore, we won't be able to take your comments into account
> unless we prepare a more substantial revision of the language.

Which is sure to happen eventually.  That's what I expected.

> > 9.1 White space
> > 
> >         authors should not rely on user agents to render white space
> >         immediately after a start tag or immediately before an end tag.
> > 
> >     What about the converse?  Should authors also not rely on user
> >     agents *not* to render whitespace immediately after a start tag?
> 
> It is my opinion that the sentence in the spec subsumes the converse.

Please confirm my understanding of your opinion:

<li>foo
<li>
foo
<li> foo

The first two items must be rendered the same, because SGML requires
a newline immediately after a start tag to be ignored, but the third
item may or may not be rendered the same as the first two, because HTML
imposes no requirements on the handling of other kinds of white space
immediately after a start tag.

> > 11.4.2 Categorizing cells
> > 
> >         In order to determine, for example, the costs of meals on 25
> >         August, the user agent must know which table cells refer to
> >         "Meals" (all of them)
> >         ^^^^^^^^^^^^^^^^^^^^^
> > 
> >     No, only cells in the Meals column refer to meals.  Maybe you meant
> >     "which table cells refer to "Expenses" (specifically, Meals)".
> 
> No, I believe "Meals" (all of them) is correct, although perhaps
> somewhat vague.

Not all the cells in the table refer to meals.  My suggested fix
followed the example of '"Dates" (specifically, 25 August)' later in the
sentence.  Whoever wrote the example might want to take a look at it.

> > 17.11.2 Access keys
> > 
> >         accesskey = character [CN]
> > 
> >     How is this case neutral?  Doesn't it have to be either case
> >     sensitive or case insensitive?  Am I allowed to have one control
> >     with an accesskey of "C" and another with an access key of "c"?  (I
> >     vote no.)
> 
> A "character" refers to a single character of the document character
> set.  Since "c" and "C" differ in the document character set, there is
> no case involved.

But it is an issue.  As an author, I need to decide whether to say
accesskey="c" or accesskey="C", and the spec doesn't provide much
assistance, or indicate whether it matters.  One thought I had was
that accesskey="c" might mean Meta-C while accesskey="C" might mean
Meta-Shift-C.

Document characters do not equal keystrokes, and my first guess at how
to map the one to the other was to ask "Which keystroke do I normally
use to produce that document character?" and then add a standard
modifier to it, like Alt, Cmd, or Meta.  It didn't occur to me that
there is another sensible mapping, which may be the one the author had
in mind, which is to ask "Which key has that document character printed
on it?" and add the standard modifier to that key.

I think the spec should say a little more on the issue of how the
document character maps to a keystroke, specifically regarding case.

> >     The examples use 'Content-Disposition: attachment' in the
> >     subparts, rather than 'Content-Disposition: file'.  Are both
> >     correct?  Is one preferred?
>
> This material has been taken from RFC 1867. If the RFC doesn't specify
> this, the HTML 4.0 Recommendation won't either.

17.13.4 Form content types

        The file name may be specified with the "filename" parameter of
        the 'Content-Disposition: form-data' header, or, in the case of
        multiple files, in a 'Content-Disposition: file' header of the
        subpart.

The string ": file" does not appear in RFC 1867, so the above sentence
probably meant to say "'Content-Disposition: attachment' header of the
subpart."

By the way, I forgot to say this in the original comments:  HTML 4.0
comes as a relief--the cleanliness that was lost on the way from 2.0
to 3.2 has been restored, even while the power of the language has
increased.  Nice job!

AMC

Received on Sunday, 28 December 1997 23:54:06 UTC