Re: Question on "phrasing content" definition

Am 16.05.13 15:14, schrieb Yves Savourel:
>>> After looking over the Phrasing elements again, I think there should
>>> be also other elements with nested, like code, iframe, noscript.
>> I wouldn't specify a default for "code" since it can be both
>> withn-text=nested or within-text=yes, the latter e.g. in
>> <p>the <code>return</code> key ...</p>. The defaults are only for
>> cases with no ambiguity.
> Well, we have to have a default. For XML it's within-text='no'

> , so we need to define something for HTML5.
> In the case of code I would say within-text='yes' too.

Hold on, there is a mismatch: for XML we say the default is XML 
vocabulary agnostic. We don't list element names. And esp. if there is 
ambiguity about whether an element is used inline or as a separate 
segment (like with "code"), I would not name it in a given list. I'd 
rather say: for HTML we have defaults for phrasing content and "script". 
For all other elements we don't say anything.

>>> Not sure how to handle most of the Interactive contents (,
>>> like button, select, keygen, ...
>> Then better let's define no defaults for these, and encourage users
>> to set within-text explicitly - which is the way to go anyway imo.
> I don't think we can not define a default: An ITS processor may be run without any explicit rules.
> I would say for HTML5 phrasing elements default to within-text='yes', and we list the exceptions, like <script>, <noscript>, <iframe>.
> We need to go through the elements are make decisions on the ambiguous cases.

I wouldn't go the "list elements by name" appraoch again, esp. since in 
HTML5.x new elements will appear. So anyway we must say "elements that 
are not part of phrasing content are by default within-text=no"  - that 
is like with XML. And we are having the HTML group here in the loop 
(putting them in the "to" field" of this mail again) to avoid oir own 
lists and just refer to HTML5.x.

> I think those changes do prevent us to publish the second last call.

I agree.

> But since they affect Tilde's schedule (I think) we should try to get them done asap.

+1 .

- Felix
> -ys

Received on Thursday, 16 May 2013 13:49:21 UTC