- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 31 Oct 2007 09:36:04 +0000 (UTC)
On Thu, 9 Mar 2006, Henri Sivonen wrote: > > It seems to me that the WA 1.0 spec presents requirements on document > conformance that are very different from each other in spirit in a > seemingly arbitrary way. > > On one hand, some elements are required to have significant inline > content or are barred from having traditional flow content while, on the > other hand, the requirements on attribute occurrence are very lax and > sectional elements are not required to have any content at all. These > requirements seem very inconsistent in spirit to me. Agreed. I have dropped the concept of significant inline content, replacing it with a blanket "should" statement, which will probably need to be cleaned up in due course. > To make document conformance a more useful concept for the purpose of catching > author errors, I suggest that the following attributes be made required: > > href and rel on link Done. > href on base Done (unless target is there instead). > name and content on meta (other than the encoding decl) Exactly one of name, http-equiv, and charset must be present, and content must be present if name or http-equiv is present. > src on img Done. > code, height and width on applet These are not the attributes you are looking for. > name and value on param Done. > To allow user agents see whether the author provided the empty string as > the alternative text of whether the author just didn't care, I suggest > that the alt attribute on img be made optional. The above-mentioned > elements are useless without the listed attributes. The img element is > not useless without alt, so editors have an incentive to allow authors > to insert img elements without alternative text but do not have an > incentive to allow useless link elements, for example. alt="" is now optional. > Since sectional elements are document-oriented rather than Web > application-oriented, it seems to me it would make sense to require them > to contain one or more block elements as opposed to zero or more. They SHOULD not be empty but it's not a MUST. > On the other hand, I have doubts about the requirement of significant > inline content. When the W3C said that paragraphs mustn't be empty, > various applications started emitting <p> </p>. If the WHAT WG says > that paragraphs must contend significant inline content, are the > developers of those applications suddenly going to decide not to allow > them to paragraphs to be saved or are they going to come up with an even > more crufty work-around to comply with the machine-checkable > requirements of the spec? I'm convinced; gone is that MUST requirement. (It should probably still give warnings in a lint-level conformance checker, though.) On Fri, 10 Mar 2006, Henri Sivonen wrote: > > Anyway, adding the base URL via a script seems like a bad idea that does > not deserve to be optimized for, and the meta element is usually meant > for data mining tools that do not execute scripts. I see the point with > the link element, although a link without a rel and a href still > intuitively feels wrong. Agreed on those. > > * It should be possible to have a group of pages that have a similar > > structure, with elements annotated as necessary. For example, a menu > > list could be the same on each page, but with the currently loaded > > page simply not having the "href" attribute on its link, or some such. > > Well, I suppose an <a> without a href could make sense for styling in > such a case. Still seems wrong somehow. I don't really see why <a> without href="" is wrong, especially given the strong use case of having a placeholder in menu structures. > > * It should always be clear from a semantic point of view whether the > > content is a single "paragraph", or whether it is a group of > > paragraphs. > > Yes, changing flow to exclusive or of block and inline seems reasonable. Agreed. > > Exceptions: <base target> may mean that <base> should have either href > > or target. > > The current draft does not even have target. How would the target map to > XHTML where the base element is not allowed? <base target>. On Mon, 20 Nov 2006, Henri Sivonen wrote: > > I think form controls should count as significant inline content. On Wed, 15 Nov 2006, Henri Sivonen wrote: > > Is it really intentional that the <map> element counts as significant > inline content? On Wed, 15 Nov 2006, Henri Sivonen wrote: > > Map seems to be a block-level element, so I guess the question is > implicitly answered. > > However, should <area> and <param> count as significant inline content? > I think not. All three of these questions are now inapplicable. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 31 October 2007 02:36:04 UTC