- From: Edward Lass <elass@goer.state.ny.us>
- Date: Mon, 18 Oct 2004 16:40:19 +0000
- To: <www-html@w3.org>
- Cc: <risto.kankkunen@iki.fi>
No, nothing similar has been suggested. I once asked a what-if about embedding
type="application/xhtml+xml" as a resource, although the conclusion was that
XSLT was more appropriate. A number of people question the <object/> element,
given Microsoft's implementation of it -- although I haven't even seen that on
this mailing list.
To respond to your points (forgive me for going out of order) --
>> 3. The recursive nature of the mechanism is hard to parse and not explicit
I don't agree.
One of your examples is this:
<alt>
<!-- Try to show a video clip -->
<object
src="holiday.mpeg"
type="video/mpeg"
</
<!-- Or show a still image and audio -->
<div>
<object src="holiday.jpeg" type="image/jpeg" />
<object src="holiday-narration.mp3" type="audio/mp3" />
</div>
<!-- Or show an image and some text -->
<div>
<object src="holiday.jpeg" type="image/jpeg" />
<p>Our holiday started on Sunday, the 1st of August. ...</p>
</div>
<!-- Or show just a place holder -->
<p>(holiday picture here)</p>
</alt>
Now this is how one could do it under the current WD:
<!-- Try to show a video clip -->
<object src="holiday.mpeg" type="video/mpeg">
<!-- Else, show a still image and audio -->
<object src="holiday.jpeg" type="image/jpeg">
<!-- If the image doesn't work, show just a place holder -->
<p>(holiday picture here)</p>
</object>
<object src="holiday-narration.mp3" type="audio/mp3">
<!-- If the audio doesn't work, show text -->
<p>Our holiday started on Sunday, the 1st of August. ...</p>
</object>
</object>
I actually don't have much of a programming background, so I have no particular
love for recursion. :) But the basic if-then-else style makes a lot of sense.
In the proposal above, the user agent has to look inside the <div/> element,
and if it reports that it can accept JPEG but not MP3, it has to reject that
block altogether and go to the next one?
>> 2. It introduces an attribute that totally overrides the semantics of any
>> element, opening possibilities for misuse and misunderstanding
This is an interesting point.
It seems to be assumed that authors would mark up their embedded resources in a
semantically accurate way. If the history of the Web is any indication (and it
is), then we can conclude that this is an invalid assumption. Especially
important is to make sure that the WYSIWIGs can interpret an author's
intention.
I think the Embedding Module has tremendous semantic potential, but is there
any way to address that potential for abuse?
>> 1. It provides alternative representations only for remote resources
In theory, HTTP Content Negotiation and XML encoding information should already
make sure that the user agent can handle everything that an XHTML page throws
at it.
In practice, when I look at the W3C HTML Home Page in Firefox for Windows,
Masayasu Ishikawa's name in Japanese appears as a series of question marks.
However, from the example:
<!-- in Cyrillic letters -->
<p xml:lang="ru">
? ???? ????????!
</p>
<!-- Latin transliteration -->
<p xml:lang="ru">
S dnem rozhden'ja!
</p>
Obviously the xml:lang attribute doesn't include encoding or font information,
so a user agent couldn't be expected to reject the Cyrillic letters...
The alternatives in the Embedding Module, the Object Module, and the Scripting
Module aren't intended to accept or reject encoding or font information, so I
would say that there's a distinction between this proposal and what's handled
so far. Is this problem common enough that a scripting solution is inadequate?
Probably not.
In sum, #2 raises a very interesting point - but as for #1 and #3, I would not
do things differently.
- Ed.
>>> Risto Kankkunen <risto.kankkunen@iki.fi> 10/16/04 08:37AM >>>
[I haven't had the chance to read the earlier drafts of follow the
mailing list discussions. I apologize, if what I say has been
considered already.]
XHMTL 2.0 Draft from 22nd of July defines a new method for specifying
alternative representations of content by using the "src" attribute
in almost any element.
http://w3.org/TR/2004/WD-xhtml2-20040722/mod-embedding.html#s_embeddingmodule
I feel that approach has a number of problems:
1. It provides alternative representations only for remote resources
2. It introduces an attribute that totally overrides the semantics of
any element, opening possibilities for misuse and misunderstanding
3. The recursive nature of the mechanism is hard to parse and not
explicit
What I would like to see instead is an explicit element, tentatively
called "<alt>" here but the name is not relevant, for denoting
alternative representations of local or remote resources. Each of the
childs of the element represent a possible alternative in decreasing
order of preference. The user agent should pick the first one available
and matching user's preferences and discard the others.
I feel this approach is much more straightforward and explicit and
it also frees the content of "<object>" for its real content, be it
"<param>" or whatever. Furthermore, the "<alt>" tag provides a nice
place to add attributes in the future that further control how the
alternatives are evaluated.
Any comments?
Below are some examples of the same contents represented in these two
approaches:
This example is from
http://w3.org/TR/2004/WD-xhtml2-20040722/mod-object.html#s_objectmodule_xref_4
<!-- First, try the applet -->
<object
src="http://www.example.com/TheEarth.class"
type="application/x-java-applet">
<!-- Else, try the video -->
<object
src="TheEarth.mpeg"
type="video/mpeg"
xml:base="http://www.example.com/">
<!-- Else, try the image -->
<object
src="TheEarth.png"
type="image/png"
xml:base="http://www.example.com/">
<!-- Else process the alternate text -->
The <strong>Earth</strong> as seen from space.
</object>
</object>
</object>
Using the "<alt>" element, we would have:
<alt>
<!-- First, try the applet -->
<object
src="http://www.example.com/TheEarth.class"
type="application/x-java-applet"
/>
<!-- Else, try the video -->
<object
src="TheEarth.mpeg"
type="video/mpeg"
xml:base="http://www.example.com/"
/>
<!-- Else, try the image -->
<object
src="TheEarth.png"
type="image/png"
xml:base="http://www.example.com/"
/>
<!-- Else process the alternate text -->
The <strong>Earth</strong> as seen from space.
</alt>
This example is from
http://w3.org/TR/2004/WD-xhtml2-20040722/mod-embedding.html#s_embeddingmodule
<p src="holiday.png" type="image/png">
<span src="holiday.gif" type="image/gif">
An image of us on holiday.
</span>
</p>
Using "<alt>", we get quite simply:
<alt>
<object src="holiday.png" type="image/png" />
<object src="holiday.gif" type="image/gif" />
<span>An image of us on holiday.</span>
</alt>
Another example from the same section. I think this is a good example of
the confusing nature of the "src" attribute. With a couple more
attributes thrown in to the "<table>" tag you would easily miss the
"src" attribute and fail to understand what is happening:
<table src="temperature-graph.png" type="image/png">
<caption>Average monthly temperature over the last 20 years
</caption>
<tr>
<th>Jan</th><th>Feb</th><th>Mar</th>
<th>Apr</th><th>May</th><th>Jun</th>
<th>Jul</th><th>Aug</th><th>Sep</th>
<th>Oct</th><th>Nov</th><th>Dec</th>
</tr>
<tr>
<td> 4</td><td> 2</td><td> 7</td>
<td> 9</td><td>13</td><td>16</td>
<td>17</td><td>17</td><td>14</td>
<td>11</td><td> 7</td><td> 4</td>
</tr>
</table>
With "<alt>" element, we get:
<alt>
<object src="temperature-graph.png" type="image/png" />
<table>
<caption>Average monthly temperature over the last 20 years
</caption>
<tr>
<th>Jan</th><th>Feb</th><th>Mar</th>
<th>Apr</th><th>May</th><th>Jun</th>
<th>Jul</th><th>Aug</th><th>Sep</th>
<th>Oct</th><th>Nov</th><th>Dec</th>
</tr>
<tr>
<td> 4</td><td> 2</td><td> 7</td>
<td> 9</td><td>13</td><td>16</td>
<td>17</td><td>17</td><td>14</td>
<td>11</td><td> 7</td><td> 4</td>
</tr>
</table>
</alt>
If the author of the document would prefer a table presentation and only
show the graph if the agent doesn't support tables, s/he could easily
just simply reverse the elements inside "<alt>". With the mechanism
proposed in the draft that is not possible.
Here is an example that cannot be represented at all with the approach
proposed in the draft, but which is important in the international World
Wide Web. The user agent could choose the first alternative, if it has
available the Cyrillic fonts needed (and the user has set preference to
accept Russian). Failing that, the agent could show a vector drawing of
the phrase, if it supports the content type. Or it can show a version of
the phrase using just Latin characters. Finally, if the user doesn't
want to see Russian, the agent can select the last alternative, an
English translation of the phrase.
<alt>
<!-- in Cyrillic letters -->
<p xml:lang="ru">
? ???? ????????!
</p>
<!-- vector image rendering -->
<object
xml:lang="ru"
src="happybirthday.svg"
type="image/svg+xml"
/>
<!-- Latin transliteration -->
<p xml:lang="ru">
S dnem rozhden'ja!
</p>
<!-- English translation -->
<p xml:lang="en" encoding="">
Happy birthday! (in Russian)
</p>
</alt>
Finally as an additional possibility, the "<alt>" mechanism could allow
for more complex combinations of alternative resources:
<alt>
<!-- Try to show a video clip -->
<object
src="holiday.mpeg"
type="video/mpeg"
</
<!-- Or show a still image and audio -->
<div>
<object src="holiday.jpeg" type="image/jpeg" />
<object src="holiday-narration.mp3" type="audio/mp3" />
</div>
<!-- Or show an image and some text -->
<div>
<object src="holiday.jpeg" type="image/jpeg" />
<p>Our holiday started on Sunday, the 1st of August. ...</p>
</div>
<!-- Or show just a place holder -->
<p>(holiday picture here)</p>
</alt>
Here the agent would first try to show the video clip. Failing that, the
agent would then try to get BOTH the image and audio files. If either
of them fails, the agent would continue to the third alternative.
The mechanism proposed in the draft considers each resource on its own,
but the "<alt>" syntax gives a natural way to group related resources,
so that they are either all shown, or none of them are shown.
Regards,
Risto Kankkunen
Received on Tuesday, 19 October 2004 17:04:09 UTC