W3C home > Mailing lists > Public > public-i18n-core@w3.org > January to March 2009

RE: Can we have @lang back in XHTML Family?

From: Richard Ishida <ishida@w3.org>
Date: Tue, 27 Jan 2009 18:15:15 -0000
To: "'Dominique Hazael-Massieux'" <dom@w3.org>
Cc: <public-xhtml2@w3.org>, <public-i18n-core@w3.org>, <fd@w3.org>
Message-ID: <01e801c980ab$351373c0$9f3a5b40$@org>

> From: Dominique Hazael-Massieux [mailto:dom@w3.org]
> Sent: 27 January 2009 16:52
...
> > The idea that it might be possible to introduce lang to XHTML 1.1 etc was
> > interesting, but I think that the problem would be that, if people don't
> > continue to use both attributes, xml processors would have to also be
> > changed to recognise that lang is equivalent to xml:lang (eg. so that the
> > XPath lang() function would still work in XSLT or XQuery).
> 
> I think the premises is that if you serve your content as text/html,
> you're not expected to have it designed to work seamlessly with XML
> tools.

I actually assumed that the contrary is true.  I think that the general perception amongst authors is that the main advantage of using XHTML rather than HTML is precisely for compatibility with the XML world.  This is also why HTML5 will have an XML serialisation.

> 
> For the people interested in having their languages annotations properly
> read by XML tools, the best practice would still be to have both lang
> and xml:lang; for those only interested in getting their pages properly
> parsed by browsers, the lang attribute should suffice.

See my comment below.


> > I can't say what level of acceptance the idea would have with the HTML5
> > folks, but it seems to me that moving text/html processors to accept
> > xml:lang as equivalent to lang would be more effective, and perhaps easier.
> 
> But that seems like something that wouldn't have effects before years,
> at the very earliest; not mentioning that this would also need to be
> outreached to assistive technology vendors, etc.
> 
> In the meantime, we're going to leave out in the cold Web authors that
> will need to choose between being valid (using their XHTML format of
> choice), or provide effective language annotations.

HTML5 support is already creeping into browsers, eg. the <meta charset="..."/> tag seems to be widely supported [1], but I can see a point here.  It would allow people currently using XHTML to write meaningful language attributes immediately after the switch was flicked to allow serving as text/html.  On the other hand, since (and as long as) HTML agents don't recognise xml:lang, it must be clear to people that just changing your server to serve legacy XHTML files as text/html is not sufficient if you care about language declarations - the legacy pages out there would have to be edited too.  Anyway, there does seem to be a good case for including lang in XHTML, in order to enable recognition of XHTML language information by text/html processors.

So maybe there is a short-term strategy (add lang to XHTML and warn people about the need to be careful with legacy content if switching the mime-type) and a longer-term solution, based around developments in HTML5, that makes HTML processors recognise xml:lang as equivalent to lang, so that in the future designers won't have to duplicate language information.

RI


[1] http://www.w3.org/International/tests/results/results-html5-charset 
Received on Tuesday, 27 January 2009 18:15:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 January 2009 18:15:17 GMT