- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 13 Sep 2013 19:20:57 +0000 (UTC)
- To: Peter Occil <poccil14@gmail.com>
- Cc: WHATWG <whatwg@whatwg.org>
On Thu, 1 Aug 2013, Peter Occil wrote: > > Many of these cases occur in the normative portion of the tree > construction stage. Most of them involve checking whether an element > (as opposed to a tag token) has a certain name: > > Accordingly, these cases are ambiguous: > > * If foster parenting is enabled and target is a table, tbody, tfoot, > thead, or tr element > > * Let last template be the last template element in the stack of open > elements, if any. > > [...] > > * Pop elements from the stack of open elements until a template element > has been popped from the stack. > > * If there is a template element on the stack of open elements, ignore > the token. > > * If the second element on the stack of open elements is not a body > element, [...] or if there is a template element on the stack of open > elements, then ignore the token. All of these hyperlink to the definition of the element and that definition is of an element in the HTML namespace, as the spec says: # Except where otherwise stated, all elements defined or mentioned in this # specification are in the HTML namespace ("http://www.w3.org/1999/xhtml") : For example, button elements are elements with the element type button, : meaning they have the local name "button" and (implicitly as defined : above) the HTML namespace. Why do you think the cases above are ambigious, but the following, for instance, are not? # The section element represents a generic section of a document or # application. # If the target of the click event is an img element [...] # A form control is disabled if its disabled attribute is set, or if it is # a descendant of a fieldset element whose disabled attribute is set and # is not a descendant of that fieldset element's first legend element # child, if any. > Moreover, where needed, a shortcut is to use "an HTML so-and-so element" > rather than "a so-and-so element in the HTML namespace". (This can > apply similarly to SVG and MathML.) I don't understand why this is necessary. I think it would be misleading because it would make authors question why other parts of the spec don't specify the namespace. I've added a redundant note to the parser intro about this, but it's redundant -- it just references the terminology section and repeats the same point again. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 13 September 2013 19:21:23 UTC