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.

> >
>
> >
>
> >> That raises some questions:
>
> >> - do the mappings
>
> >> 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.

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

Best,

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