W3C home > Mailing lists > Public > public-html@w3.org > June 2009

The a element (content and semantic model)

From: Leif Halvard Silli <lhs@malform.no>
Date: Wed, 10 Jun 2009 04:52:36 +0200
Message-ID: <4A2F1FF4.1010901@malform.no>
To: HTMLWG <public-html@w3.org>
Review:

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>

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.)

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.

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.

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.

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?

Proposals: 

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.)
* 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.)

[1] 
http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-a-element
[2] 
http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#interactive-content-0
[3] 
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-xhtml-syntax.html#represents
[4] 
http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#transparent
-- 
leif halvard silli
Received on Wednesday, 10 June 2009 02:53:14 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:04 UTC