W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Re: 3.1 Introduction (Draft), review of

From: Robert Burns <rob@robburns.com>
Date: Tue, 17 Jul 2007 13:27:20 -0500
Message-Id: <93027871-CA51-44F1-BC1C-0826E68FD379@robburns.com>
To: HTML WG <public-html@w3.org>

On Jul 17, 2007, at 7:12 AM, Philip Taylor wrote:

>
> Robert Burns wrote:
>> 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.
>
> http://www.w3.org/TR/xhtml1/#guidelines already gives that advice:
>
>     "Include a space before the trailing / and > of empty elements,  
> e.g. <br />, <hr /> and <img src="karen.jpg" alt="Karen" />. Also,  
> use the minimized tag syntax for empty elements, e.g. <br /> ..."
>
>     "Given an empty instance of an element whose content model is  
> not EMPTY (for example, an empty title or paragraph) do not use the  
> minimized form (e.g. use <p> </p> and not <p />)."
>
> The point of the examples is that people half follow that advice,  
> but then they get confused between real XML and HTML-that-looks- 
> like-XML, and they forget the distinction between empty content  
> model vs empty content, and they end up writing buggy HTML.  
> Advising authors (whether in this document or elsewhere) to write  
> HTML-that-looks-like-XML will only increase that confusion and  
> result in more broken HTML documents.

That's a very good point. I agree that authors will still be confused  
by this. However, I think it really is isolated to this one  
particular area. And its here because of the two reasons I listed  
before:

1) in an text/html serialization: elements with an empty content  
model must not (or is it only should not) be closed (e.g.,  
<head><title>atitle</title><link><meta></head>)
2) in an xml serialization: those same elements must be closed  
(i..e., either <head><title>atitle</title><link></link><meta></meta></ 
head> </link> or <head><title>atitle</title><link /><meta /></head>)

Again, it is why I originally suggested the introductory section of  
this chapter may not be the place to raise these issues at all. The  
discussion of syntax, serializations,  and how to build an element  
syntactically should come in an earlier chapter. This introductory  
section can make reference to that section, but should mostly focus  
on elements abstractly: as elements that are comprised of attributes  
and content (independent of how serialization accomplishes that).

Take care,
Rob
Received on Tuesday, 17 July 2007 18:27:31 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:47 UTC