[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> </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