Re: Question on "phrasing content" definition

Am 16.05.13 16:55, schrieb Yves Savourel:
>>> , 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.
> But we cannot "not say anything" for Elements Within Text.

Sorry, I wasn't clear: we say that they are within-text=no - like in XML.

> If an ITS processor processes a document without any explicit rules, it has to fall back on defaults.
> If we don't say anything the value can be anything the processor choose, and it's impossible to have tests and interoperability.
>
> Actually there is a discrepancy in the current specification:
>
> In the Position, Default, etc. table (http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20.html#datacategories-defaults-etc) we say:
>
> A= [[
> For XML content: withinText="no". For HTML5 phrasing content: withinText="yes".
> ]]
>
> In the Element Within Text section (http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20.html#elements-within-text) we say:
>
> B= [[
> The default is that elements are not within text. For HTML5 phrasing content the default is withinText="yes".
> ]]
>
> Text A says nothing about HTML5 elements that are not part of phrasing content, but text B does those same elements have a "no" default.

Good point - agree, we should add the "no" default for all HTML5 
elements that are not explicitly listed.

>
> I think text B is needed.

+1.

> And we need to list possible exceptions to "yes" for the elements in the phrasing content.


We have the "script" special case since that is clear. For everything 
else I'd be as conservative as possible and not list too much, to avoid 
ambiguity.

Best,

Felix

Received on Thursday, 16 May 2013 15:09:31 UTC