W3C home > Mailing lists > Public > public-multilingualweb-lt@w3.org > April 2013

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

From: Yves Savourel <ysavourel@enlaso.com>
Date: Wed, 17 Apr 2013 13:45:47 -0600
To: <public-multilingualweb-lt@w3.org>
Message-ID: <004501ce3ba4$286a3f10$793ebd30$@com>
Hi Felix, Jirka, Karl, all,

I've tried to summarize my thoughts on the HTML5 defaults:


When an ITS processor processes an HTML5 file the behavior for some basic data category is defined.

We already have this in the specification for Id Value (See the notes at http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20.html#idvalue-definition), as well as for Language Information:
(See the notes at http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20.html#langinfo-definition).

So it should be the same for other data categories:

We've decided to not define defaults for Terminology, Text Analysis, Domain, Preserve Space and Directionality. Either the possible matching elements/attributes were too vaguely defined, or too different to be a sure match, or the HTML5 is not stable yet.

But there are two data categories that are rather basic for which it would be good to have defaults: Translate and Element Within Text.

Element Within Text is relatively easy and I think we are all OK with the "phrasing elements" (http://www.w3.org/TR/html5/dom.html#phrasing-content-1). Since there is no inheritance for this data category, there is no issue with global rules vs local ones, etc.

For Translate: The definition is not stable in HTML5 yet, but because it's important to us, we've decided to simply come up with our own defaults.

You can see the list of defaults; here:
http://www.w3.org/International/multilingualweb/lt/wiki/HTML5_Defaults

I think it's important to make the distinction between translatable value that can be consumed as it, and the ones that require a secondary parsing (CSS, JavaScript, etc.). Initially I was making them very distinct as 'directly' and 'indirectly' translatable. But maybe it's simpler to see them all as translatable, and simply have a mention about the "special" content.

The next problem is that the HTML5 translate mechanism doesn't match exactly ITS's translate. its:translate does not applies to the attributes, while html:translate applies to only the 'translatable' attributes.
I think the only way to resolve this is to state it in the specification.

The problem after that is the question of how we can implement those defaults.

Jirka's clever global rules (http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2013Apr/0096.html) take into account the local markup, so they work both for defaults and defaults overridden by local markup (even when on an ancestor).

But I'm not sure they can work when there are user-defined global rules. An ITS processor usually would apply the global rules, then look at the local markup, overriding global rules. Since the defaults we want to have the lowest precedence, if you use global rules to set them you should do this first. this set every nodes. So user-defined global rules applied afterward would have to override every nodes (not just a parent) to be working as expected from the defaults viewpoint. 
Maybe that's resolved by the precedence discussion (http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2013Apr/0110.html), but I'm not sure I understand how.

We also have to provide a way for the implementers of local rules only to have working defaults too.

So, I think that we should just describe the default behavior and not try to provide a way to implement it with global rules. and the implementers will do whatever they think is best in their application to come up with the behavior.

As for the question about backward compatibility with HTML 4.x, etc.
I'd say they are out of scope.

And for XHTML?
Is there a reason we can't we just apply the same defaults?
What do we say for (xml:)id and (xml:)lang?


BTW: The specification has several "synatx" instead of "syntax".

cheers,
-yves
Received on Wednesday, 17 April 2013 19:46:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:32:07 UTC