Re: The a element (content and semantic model)

On Wed, 10 Jun 2009, Leif Halvard Silli wrote:
> 
> These two examples are valid:
> 
> <p id=anchor><a href=#anchor-B>text</a></p>
> <a href=#anchor><p><span id=anchor>text</span></p></a>
> 
> But these, semantically identical, examples are invalid. Why?
> 
> <a id=anchor><p><a href=#anchor>text</a></p></a>
> <a href=#anchor><p><a id=anchor><span>text</span></a></p></a>

An <a> element without an href="" is a placeholder for an <a> _with_ an 
href="" attribute, so the above two examples would be placeholders for:

  <a id=anchor href="x"><p><a href=#anchor>text</a></p></a>
  <a href=#anchor><p><a id=anchor href="x"><span>text</span></a></p></a>

...and nested links are non-conforming for sanity's sake.


> The content model description locks out "interactive content" descendants[1]:
> 
>    "Content model: Transparent, but there
>     must be no interactive content descendant."
> 
> However, the definition of "interactive content" [2] does not state that
> anchor elements without the href attribute are considered "interactive
> content". (Probably because they are not.)

<a> elements are always interactive content.


> The draft says that an anchor elements without the href attribute[1]:
> 
>    "_represents_ a placeholder for where a link might
>     otherwise have been placed, if it had been relevant"
> 
> The draft points to a definition of  "represents"  [3]:
> 
>    "In the absence of style-layer rules to the contrary
>     (e.g. author style sheets), user agents are expected
>     to render an element so that it conveys to the user
>     the meaning that the element _represents_, as
>     described by this specification."
> 
> This directly contradicts how things works: Unless <a> contains the href 
> attribute, then user agents are _not_ expected to convey to users that 
> the element represents a potential link. (Exception that confirms the 
> rule: some user agents do not discern properly between anchor elements 
> with and without the href attribute w.r.t. CSS selectors, when in quirks 
> mode.) Only if the text had been speaking about anchor elements _with_ 
> the href attribute would the "represents" definition apply to <a> 
> without href! For example, the VIM editor will colour the content of <a 
> href>content</a> blue. But if I remove the four letter word "href", then 
> it won't. Firefox, Opera, Safari behave similar. But IE apparently not.

For CSS-based UAs, the definition of "represents" is overriden by actual 
rules, so if there's a contradiction it's between the CSS and the 
definition of the <a> element. But in practice, a placeholder is presented 
as normal text, so I don't think it's really a contradiction.


> The content model also points to a definition of "transparent" which 
> says that transparent elements must not contain [4]:
> 
>    "... content that would not be conformant if all transparent
>     elements in the tree were replaced, in their parent element,
>     by the children in the "transparent" part of their content
>     model, retaining order."
> 
> In other words, if you remove the anchor elements, the code should still 
> be valid. Thus, the <a> element do not allow you to insert something 
> that otherwise would be invalid.

Right, the restriction on interactive content is a separate restriction.


> None of this is IMHO able to justify that anchor elements cannot be 
> nested. It does, though, justify that an anchor element with the href 
> attribute cannot be nested into another anchor element with the href 
> attribute.

We can't really allow nested <a> elements, because the parsing of <a> 
elements in text/html is wacky, and so it wouldn't be reliably possible to 
do it anyway.

Even if that wasn't the case (e.g. in XML), if we allowed nested <a> 
except when they have href="", then it's much more likely that someone 
will one day modify the doc to add href="" attributes and thus 
unintentionally break conformance (and have confusing nested links).


> However, as a matter of fact, when testing in Live DOM viewer, it turns 
> out that nesting of <a> elements are more or less impossible regardless 
> of whether they are interactive (= have @href) or not. But is that the 
> way it should be?

We can't really do much to change the way parsing happens.


> The draft is adjusted to
> * give better reasons for why nesting of a elements are not permitted. (E.g.
> it could say that "for the purpose of the definition of the content model, all
> anchor elements, regardless of presence of href, are considered interactive.)

The definition of "interactive content" now lists "a" explicitly.


> * give due focus to <a> elements that play the role of fragment 
> identifiers. (The current flaws in the draft are due to over-focus on 
> the interactive version of the a element.)

<a> elements are no different than any other elements in this respect in 
HTML5.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 8 July 2009 00:24:21 UTC