[whatwg] Various messages about significant inline content

Ian Hickson ian at hixie.ch
Wed Oct 31 02:36:04 PDT 2007


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>&nbsp;</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.   `._.-(,_..'--(,_..'`-.;.'



More information about the whatwg mailing list