- From: Richard Ishida <ishida@w3.org>
- Date: Thu, 02 Jun 2011 09:00:19 +0100
- 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, RI 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) http://www.w3.org/International/ http://rishida.net/
Received on Thursday, 2 June 2011 08:04:05 UTC