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

No answers to your thoughts Felix (still thinking)

But meanwhile I've updated the page:
http://www.w3.org/International/multilingualweb/lt/wiki/HTML5_Defaults

-ys

-----Original Message-----
From: Felix Sasaki [mailto:fsasaki@w3.org] 
Sent: Monday, April 15, 2013 11:55 AM
To: Yves Savourel
Cc: public-multilingualweb-lt@w3.org; Karl Fritsche
Subject: 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.
>
>
>> 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?

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

Best,

Felix

Received on Monday, 15 April 2013 20:00:46 UTC