W3C home > Mailing lists > Public > public-webfonts-wg@w3.org > June 2011

Re: I18n-ISSUE-5: Use of attributes for human readable text [WOFF]

From: Richard Ishida <ishida@w3.org>
Date: Thu, 02 Jun 2011 09:00:19 +0100
Message-ID: <4DE74313.2070805@w3.org>
To: Chris Lilley <chris@w3.org>
CC: www-font@w3.org, public-i18n-core@w3.org, WebFonts WG <public-webfonts-wg@w3.org>
Thank you for your explanation.  The i18n WG would still prefer to use 
elements rather than attributes for this information, but we will not 
raise a formal objection against your decision.

For the i18n WG,

On 06/04/2011 14:32, Chris Lilley wrote:
> Hello ,
> Richard Ishida wrote:
> http://lists.w3.org/Archives/Public/www-font/2010OctDec/0104.html
>> In the schema description, various items that contain human readable
>> text are stored as attribute values. We normally recommend that you
>> don't do this (see http://www.w3.org/TR/xml-i18n-bp/#DevAttributes)
>> because of potential translation and annotation difficulties (eg.
>> markup of bidi text). In several cases these attributes are the only
>> content on empty elements.
>> See also the comment we will raise about localization of other
>> elements, such as credit. Making the name attribute of the credit
>> element into an element would allow for localizations of the name
>> text, which is currently not possible.
>> We would suggest converting the attributes to element content. In
>> most cases, this does not seem to cause any significant increase in
>> the size of the markup.
> The WebFonts WG has discussed this and evaluated both the positive and
> negative impact on current authoring tools and deployed content.
> We looked at the impact of changing attribute content to element
> content, which would make all deployed content invalid. This was felt
> to be too high a price to pay.
> We also looked at the impact of allowing both the attribute and the
> element content (for backwards compatibility, although this also
> requires specifying which of the two sources of information has
> precedence when both are supplied).  This was felt to be clumsy but
> workable, if need be; but the positive benefit did not seem to be
> worth the extra complexity for these specific attributes.
> While sympathetic to the general principle, in practice the examples
> we looked at (such as @name on credit, vendor and licensee) would
> contain a proper name which is not translated anyway.
> Once example we could think of where this would help would be a
> Japanese name with Ruby markup to indicate the pronunciation in the
> case of a name using rare characters. This use case, while valid, fell
> quite far from the benefit/complexity trade off. If complex markup is
> required, a link to an HTML page which can contain more complex
> formatting and styling would be a better approach.
> The metadata in WOFF is intended to be a simple and small description,
> primarily to ensure that the license information for a deployed font
> is clear. it is not intended to be a full page description language
> rivalling HTML, PDF or XSL-FO in its expressive power. url attributes
> are provided for linking to further details, including cases where
> more precise formatting or structuring is required.
> The WebFonts WG therefore regretfully rejects this particular comment,
> on the grounds of too much disruption of existing content for too
> little gain, and hopes that the I18n WG can accept this resolution of
> their comment.
> Tracker, this relates to
> I18n-ISSUE-5: Use of attributes for human readable text [WOFF]
> ACTION-78: Respond on Use of attributes for human readable text
> (sorry for the pollution, issue and action prefixes on font WG tracks seem to have stopped working)

Richard Ishida
Internationalization Activity Lead
W3C (World Wide Web Consortium)

Received on Thursday, 2 June 2011 08:00:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:15 UTC