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

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

"The Preserve Space data category does not apply to HTML documents in HTML syntax."

? 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?

 

> 

> 

>> 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 or do you mean the WP3’s part with Cocomore? And what do you mean by “what default processing to expect”?

 

[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.