Re: [ACTION-487][ISSUE-97][ISSUE--118] HTML5 Defaults

Hi Jirka, Yves, all,

Am 17.04.13 22:18, schrieb Jirka Kosek:
> Hi Yves,
>
> thanks for excellent summary!

Indeed.

>
>> I think it's important to make the distinction between translatable
>> value that can be consumed as it, and the ones that require a
>> secondary parsing (CSS, JavaScript, etc.). Initially I was making
>> them very distinct as 'directly' and 'indirectly' translatable. But
>> maybe it's simpler to see them all as translatable, and simply have a
>> mention about the "special" content.
> I think that we don't need treat CSS/Javascript in the special way. It's
> edge case and there is no need to waste resources on it. In the worst
> case blocks of code will be translated as units. It will work, but it
> will be very inefficient. But implementations are free to provide
> proprietary mechanism which will further parse CSS/Javascript. If this
> became common we can think about standardizing this for ITS 3.0.
>
>> The next problem is that the HTML5 translate mechanism doesn't match
>> exactly ITS's translate. its:translate does not applies to the
>> attributes, while html:translate applies to only the 'translatable'
>> attributes. I think the only way to resolve this is to state it in
>> the specification.
> Agreed.

I disagree: we are trying to state the relation between ITS2 and HTML5. 
ITS2 within a few months will be a standard. HTML5 will take at least 
one more year. We cannot state in ITS2 a relation between ITS2 and a 
moving target.

By "moving target" in HTML5 I mean the HTML5 "translate" related 
mechanisms itself, e.g. the relation between elements and attributes. 
What will we do with ITS2 if e.g. the relation between "title" 
attributes and translatable elements changes? We will have three ways to 
express "Translate":

- format independent: without further ITS information, a "title" 
attribute is not translatable
- ITS2 HTML5 translate version April 2013, related to HTML5 spec version 
X: if the corresponding element is translatable, a "title" attribute is 
translatable as well.
- HTML5 recommendation: we don't know anything about "title".

For "elements within text" the situation is different. The list of 
inline elements in HTML is much more stable, like the definitions of @id 
(relevant for "id value" and @lang (relevant for "language information") 
in HTML5. And if there is a change it will probably just be an addition 
of a new inline element, but not a new category of elements.


Like with the differentiation between translatable values that can be 
consumed vs. the "directly consumed" values, I think the HTML5 specific 
"translate" definition in ITS should wait. We might regret it to 
hardwire this now.


>> So, I think that we should just describe the default behavior and not
>> try to provide a way to implement it with global rules. and the
>> implementers will do whatever they think is best in their application
>> to come up with the behavior.
> As I already said we can describe defaults in prose or formally using
> rules. I have no preference in this, so having textual definition only
> is fine for me.
>
>> As for the question about backward compatibility with HTML 4.x, etc.
>> I'd say they are out of scope.
> HTML4 doesn't provide translate attribute nor it provides its-* attributes.
>
>> And for XHTML? Is there a reason we can't we just apply the same
>> defaults? What do we say for (xml:)id and (xml:)lang?
> We should say same as for id and lang in HTML.


So when an ITS processors processing "within text", not having any 
"within text" rules or inlne markup, consumes a DOM and sees a "span" 
element in the HTML namespace - what "within text" property should it 
assume?

Best,

Felix

>
>     Jirka
>

Received on Thursday, 18 April 2013 22:20:05 UTC