Yes. But I haven't submitted it because:
1. IETF guidelines say the TOC goes after Status and Abstract,
and
2. Convention says Terms goes right after Intro, not at
the end.
#1 is up to you. I'm fixing #2. I'll have another .tar.gz in a few
minutes incorporating the latest typos and editorial changes.
> It's not on www.w3.org yet. I put it at
> <URL:http://www.crl.com/~jenglish/html-spec.txt>
> in case anyone is looking for a copy. ]
That's still linked from the HTML page I maintain.
>[ BTWII: I've been toying with a LaTeX filter too,
> and have a (IMHO) nicer-looking PostScript version
> partially ready; let me know if you're interested. ]
Sure! What's the URL?
Anything not metioned here was incorporated as requested:
>2.2.1. Data Characters, p. 8:
>
>| Note that the terminating semicolon is only necessary when the
>| character following the reference would otherwise be recognized
>| as markup:
> ^^^^^^
>
>Should read "would otherwise be recognized as part of the entity name".
> ^^^^^^^^^^^^^^^^^^^^^^^
Same difference. I'll pass on this one.
>4.7 Phrase Markup, p. 24, 2nd paragraph:
>
>| User agents must render highlighted phrases distinctly from
> ^^^^
>| plain text. Additionally, <EM> content must be rendered as
>| distinct from <STRONG> content, and <B> content must rendered as
> ^^^^
>| distinct from <I> content.
>
>
>The "must"s here make "lynx -dump" and other HTML-to-plaintext
>formatters nonconforming HTML user agents. Was this intended?
Er... well... yes. There used to be a distinction between HTML level 0
and level 1 for this, but it went away. By the way: doesn't lynx
do _em_ and *strong* ???
>4.7.1 Idiomatic Elements.
>
>[ Question: why isn't <DFN> in the DTD? ]
See the archives -- long time ago. Mosaic 2.4 didn't grok, as I
recall. A related thread is begins with:
http://www.acl.lanl.gov/HTML/html-archive.messages/58.html
whither <u>...</u>?
Corprew Reed
.. though I can't find specific discussion of <DFN> in there. But
I remember testing it and finding spotty support at the time.
>6.4. Fragment Identifiers, p. 31, 2nd paragraph:
>
>| The meaning of fragment identifiers depends on the media type of
>| the resource containing the head anchor. For `text/html'
>| resources, it refers to the <A> element with a NAME attribute
>| whose value is the same as the fragment identifier. The matching
> ^^^^^^^^^^^^
>| is case sensitive. [...]
> ^^^^^^^^^^^^^^^^^
>
>If %HTML.Recommended; is on, then NAME attributes are IDs,
>so in this case the matching should *not* be case-sensitive.
>This could cause problems:
>
> <A HREF="#foo"> ... <A NAME=foo>
>
>will *only* work if HTML.Recommended is *off*. I've seen
>lots of documents that use lowercase anchor names; are they
>going to have forward-compatibility problems?
Err... good catch. I'm changing the DTD -- getting rid of %linkName.
When SGML IDs are introduced, the name of the attribute will
change to ID.
By the way... Roy Fielding suggested getting rid of the METHODS
attribute of the A and LINK element. I'm game for it. In fact,
I can imagine getting rid of URN and TITLE too. Any thoughts?
>9. Terms.
>
>Under "element", "end-tag", "markup", and "start-tag",
>the term "descriptive markup" should be "generic markup"
>according to the official SGML terminology.
>
>(FWIW, I happen to like "descriptive" better. It seems
>more, er, descriptive.)
BZZZT. I quote from the holy script:
4.306 start-tag: Descriptive markup that identifies
the start of an element and specifies its generic
identifier and attributes.
Dan