- From: Robert Burns <rob@robburns.com>
- Date: Tue, 17 Jul 2007 00:28:18 -0500
- To: Robert Burns <rob@robburns.com>
- Cc: Philip Taylor <philip@zaynar.demon.co.uk>, public-html@w3.org
On Jul 16, 2007, at 10:00 PM, Robert Burns wrote: > > > On Jul 16, 2007, at 9:44 PM, Philip Taylor wrote: > >> >> Robert Burns wrote: >>> First, I think there's a danger of going into too much detail >>> regarding optional tags. The only things I think might need to be >>> in an introductory section (maybe) are: >>> 1) that empty elements must have their closing tag omitted unless >>> an author uses the xml-style self-closing tag (e.g., <link />). >>> 2) that empty elements must be closed when using the xml >>> serialization: i..e., either (<link></link> or <link />) >>> So to avoid this confusion and simplify things, it may make sense >>> to always recommend (or as far as this introduction goes, just >>> gloss- over the difference so that authors use) the self-closing >>> tag for empty elements. >> >> Teaching authors about XML-style self-closing tags is also a cause >> of confusion. > > > Just to clarify, when I wrote "empty elements", I meant canonically > empty elements (i.e., elements required to be empty). Yes, I agree > that encouraging the shortcut everywhere be a bad thing for the > text/html serialization. I don't think any of your following > examples relate to that. What I meant to say here is that none of the examples relate to the elements with empty content models and that the examples you listed are specifically elements that do not have empty content models. I think we if advised authors to use the self-closing tag on elements with empty content models (and highlighted how the chapter shows those at the beginning of each section/subsection), that would be a simple guideline to follow (for an introductory section). Getting into more detail than that right there (e.g., discussing differences between xml and non-xml serializations) would be counter-productive. > >> It's fairly easy to find examples, many of which are likely to >> result in unexpected DOMs after parsing: >> [...] >> Take care, Rob
Received on Tuesday, 17 July 2007 05:28:29 UTC