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

Hi Felix,

 

De: Felix Sasaki [mailto:fsasaki@w3.org] 
Enviado el: martes, 16 de abril de 2013 13:36
Para: Pablo Nieto Caride
CC: 'Yves Savourel'; public-multilingualweb-lt@w3.org; 'Karl Fritsche'
Asunto: Re: [ACTION-487][ISSUE-97][ISSUE--118] HTML5 Defaults

 

Hi Pablo,

Am 16.04.13 10:26, schrieb Pablo Nieto Caride:

Hi Felix, Yves, all,

 

-----Mensaje original-----
De: Felix Sasaki [mailto:fsasaki@w3.org] 
Enviado el: lunes, 15 de abril de 2013 19:55
Para: Yves Savourel
CC: public-multilingualweb-lt@w3.org; Karl Fritsche
Asunto: Re: [ACTION-487][ISSUE-97][ISSUE--118] HTML5 Defaults

 

Hi Yves, all,

 

Am 15.04.13 19:28, schrieb Yves Savourel:

> Hi Felix, all,

> 

>>> - I'm not sure for if we should specify those defaults for Domain 

>>> and Text Analysis

>> I would specify no defaults here - in general we should only have 

>> defaults if we are 100% sure about the purpose of the markup in HTML5.

>> That would also resolve the concern you expressed below.

> Works for me.

> 

> 

 

[PNC]: I woudn’t specify defaults with domain either, I don’t see the point.

 

>> I would also specify no defaults for Directionality, since this is in 

>> flux for HTML5 (like Ruby).

> I'd be happy about that too.

> It seems strange, but I suppose until HTML5 is still in flux for this it's ok.

> 

> 

>> For preserve space we say in the ITS2 draft "The Preserve Space data 

>> category does not apply to HTML documents in HTML syntax."

> Hmm. I know the main reason for this is because XML and HTML5 have different way of defining what is a whitespace (e.g. form-feed is a whitespace in HTML5 not in XML), and HTML5 has many way to set an element with whitespace properties (e.g. with CSS). But in practice a filter will very likely have to extract pre and textarea as if they had xml:space='preserve'. Moreover, once extracted the content is likely not in an HTML5 document anymore, but in another format, likely XML (e.g. XLIFF, TMX) where the specifics of HTML5 whitepace will go to the drain.

> 

> Since we have no expected standard behavior for Preserve Space in HTML5, I guess nothing prevent someone to make pre and textarea act like xml:space='preserve' is set.

 

Hmm. Wouldn't it be cleaner to rephrase

    

? I don't know how, but we want the HTML5 defaults to be normative, right? That means: the data category applies to HTML5, no?

 

[PNC]: I can see how you can process the data category with XHTML, but how would you process it locally with HTML5?


You wouldn't. There is just a mismatch between the statement
"The Preserve Space data category does not apply to HTML documents in HTML syntax."
and the fact that we are defining defaults for "preserve space". I don't argue for any new mechanisms, we just should resolve the mismatch.

[PNC]: I see now, then what Yves specifies on the wiki makes sense.

 

> 

> 

>> That raises some questions:

>> - do the mappings

>>  <http://www.w3.org/International/multilingualweb/lt/wiki/HTML5_Defaults> http://www.w3.org/International/multilingualweb/lt/wiki/HTML5_Defaults

>> only apply to HTML5 content in HTML5 syntax?

>> - what do we say to people who want to apply the mappings for HTML4 / 3.2 / XHTML?

> I would say we only have to address the XHTML serialization for of HTML5 (it's called XHTML5 I think)?

> HTML before 5 are out of scope.

 

Agree in terms of testing and normative language - sorry for being 

unclear: do we want to give any recommendations wrt to people processing 

HTML that is "before" HTML5? After all, of an ITS processor encounters 

the "title" attribute at a "p" element" in the HTML namespace, the 

processor may not know whether the "p" element comes from an HTML5 

document or from XHTML. And people may want to have processing chains like

1) create content in a CMS in HTML4

2) convert that to HTML5

3) process it in a localization workflow

I think this is what Linguaserve did actually. Having some advice here 

about what default processing to expect in 3) might be useful also for 

content creators working with 1) - no?

 

[PNC]: Felix, In WP4 the original content of the Spanish Tax Agency is HTML4, they are migrating it to HTML5, which is what we finally process, do you mean this


Yes, that is what I meant.
[PNC]: Ok



or do you mean the WP3’s part with Cocomore? And what do you mean by “what default processing to expect”?


By default processing I mean this:
Imagine in 1) you have HTML4 content with an "img" element. "img" has an "alt" attribute. With current ITS2, you would need a global rule like
<its:translateRule selector="//h:img/@alt" translate="yes"/>
to express that "alt is transltable. If we assume the "alt" attribute to be translatable by default, content creators working with 1) don't need to create such a global rule.



[PNC]: I understand, you’re completely right, now the content creator are adding automatically those kinds of rules, but certainly with the new defaults that wouldn’t be necessary, we must specify that somewhere.



Best,

Felix


[PNC]: Thank you. 

Cheers,

Pablo.

 

[PNC]: Yves, wrt Translate defaults, directly and indirectly translatable attributes are by default translate=”yes”, and the rest if not overridden are translate=”no” by default, am I correct?

 

Best,

 

Felix

 

Cheers,

Pablo.