Re: [XHTML2] Specifying alternative resources/content

>>> It's great that you pointed out this real-life problem you are 
>>> having, because it's just one of those things that "<alt>" could 
>>> fix.
> 
> I'm a bit worried by your tone, Risto, because it comes across as if 
> you're trying to "disprove" me. I was making an observation that 
> definitely does agree with that part of your premise (whether or not 
> it agrees with your solution).

I'm sorry, if it sounded like that, but I was really grateful that you
pointed out that incident. I think it is far more interesting to look at
real world scenarios than to look at my artificial examples.

> Well, I am suggesting caution against a "Christmas tree" attitude, 
> i.e., cautioning against hanging every possible ornament on XHTML. A 
> markup language can't be all things to all people.

I understand that. But it's not that I'm proposing something new and
complicated here. I'm proposing for a simpler and more powerful
alternative to the current proposal. The current approach seems to
revolve around the concept whether some extrenal resource is accessible
(since the content negotiation in the current form can be handled with
HTTP Content negotiation like you and the XHTML FAQ point out). Is this
the #1 problem in WWW?

If we go along the current proposal and then find out we need someting
more versatile, we are at dead end. We have to make up new syntax and
then we have partially overlapping functionality for doing the same
thing. Whereas using "<alt>" now we get much more flexibility and room
for improvement adding some controlling attributes to "<alt>" later on,
if needed.

I understand that people might disagree which notation is more elegant.
But I hope that it is accepted that the "<alt>" syntax lends itself
naturally to express constructs that cannot be done with the draft
proposal. And this versatility comes for free. Here's a JavaScript
implementation of the "<alt>" element processing:

   // Input: DOM <alt> element
   // Returns: Render tree
   function handleALT(element) {
       // Try out all the children in succession
       for (var e = element.firstChild(); e; e = e.nextSibling()) {
           var render = handleElement(e);
           // Could we render the child element without error?
           if (render)
               return render;
       }

       render null;
   }

Implementing the draft mechanism is not easier (I'd say it's harder),
since any element handler needs to check for "src" attribute, (at least
for "<object>") peek for possible "<param>" elements and discard other
content, and on failure, skip those "<param>" elements and render the
rest. And the end result is not as flexible.

> I suspect by the time XHTML2 is matured, non-Latin fonts will be much
> more commonplace.

I think I'm not going to download 36 MB of CJK fonts (that are freely
available to anyone who wants to use them right now) before I can read
those characters. I'd like to show my preference by not installing the
fonts and give the browser the ability to pick an alternative spelling
that I might be actually able to read, maybe even pronounce.

> (But does device independence preclude us from assuming this?)

I think the need for for customized and alternative content only grows,
not just because better support for Unicode, but because more varying
devices have user agents, and because of the modularization of XHTML/XML
  in the form of specialized sub-languages (e.g. MathML).

>> It's also interesting to see, that you don't think multilanguage 
>> documents are common...
> 
> I never said that, nor do I agree with it.

OK, I read too much into your comment "Is this problem common
enough[...]". I apologize.


Regards,
Risto Kankkunen

Received on Tuesday, 19 October 2004 19:54:29 UTC