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

+1

This description is really sound, and makes a lot of sense given the 
recent forth and back discussion with HTML5 defaults. The mentioned 
disadvantages or drawbacks are very well compensated with the advantages.

Cheers -- Jörg

On Apr 17, 2013 at 11:10 (CEST), Felix Sasaki wrote:
> + 1 for this proposal.
>
> It has three drawbacks:
>
> 1) Global rules are different than "real" defaults in terms of precedence.
> 2) If we go this way we won't be able to speficy "how to work with
> translate in HTML5" for "local only" implementations.
> 3) we will have a disalignment with the behaviour of HTML5 "translate"
> implementations in browsers.
>
> Nevertheless the proposal has the advantages that there is a clear
> separation between how ITS "translate" behaves, that is, as it does
> currently, and how it should behave then applied to HTML content. And
> also that we don't need to introduce new concepts like "indirectly
> translatable". In the case of HTML processing you will need the rules
> file, and we can say, to accomodate for 3), that a global HTML
> implementation MUST process that rules file.
>
> Another advantage would be for ITS2 that above approach keeps the door
> open to re-think the HTML processing, once we have gained implementation
> experience with ITS2, and once the HTML5 "translate" definition is stable.
>
> Felix
>
> Am 17.04.13 08:54, schrieb Jirka Kosek:
>> On 16.4.2013 23:48, Yves Savourel wrote:
>>
>>> For example, a tool using just the defaults should be able to know
>>> that, both @value and @onclick become "translatable" again in the
>>> following code when p has translate='yes' (and @type remains
>>> un-affected).
>>>
>>> <!doctype html>
>>> <html lang="en" translate="no">
>>> <head>
>>>    <meta charset="utf-8">
>>>    <title>Example</title>
>>> </head>
>>> <body>
>>>   <p translate="yes">Text with <input type="button"
>>> onclick="alert('Hello Felix!')" value="a button"></p>
>>>   </body>
>>> </html>
>>>
>>> I guess, the question is also how the ITS processors are suppose to
>>> work with HTML5+translate vs the normal ITS translate. If it doesn't
>>> take things like @onclick into account it's not really working.
>> Hi,
>>
>> probably I'm missing something fundamental, but what's the real problem
>> here? IMHO it's possible to create ITS rules which will mimick HTML5
>> defaults in the same way as ITS processing is defined for many other
>> formats. For example if value on input attribute should be translateable
>> then following rules will do the trick:
>>
>> <!-- By default value is translateable -->
>> <its:translateRule
>> selector="//h:input[not(ancestor-or-self::*[@translate])]/@value"
>> translate="yes"/>
>>
>> <!-- If the closest @translate attribute is yes then it is
>> translateable -->
>> <its:translateRule
>> selector="//h:input[ancestor-or-self::*[@translate][1]/@translate='yes']/@value"
>>
>> translate="yes"/>
>>
>> <!-- If the closest @translate attribute is no then it is not
>> translateable -->
>> <its:translateRule
>> selector="//h:input[ancestor-or-self::*[@translate][1]/@translate='no']/@value"
>>
>> translate="no"/>
>>
>> Yes, similar rules for HTML5 will take some length but they can easily
>> cover behaviour described in HTML5.
>>
>>                     Jirka
>>

Received on Wednesday, 17 April 2013 09:45:47 UTC