From laura.lee.carlson at gmail.com  Thu Aug  7 16:58:28 2008
From: laura.lee.carlson at gmail.com (Laura Carlson)
Date: Thu, 7 Aug 2008 18:58:28 -0500
Subject: [html4all] Blog Post: This Week in HTML 5 - Episode 1 By Mark
	Pilgrim
Message-ID: <1c8dbcaa0808071658v737924c8g75d81e0466f204f9@mail.gmail.com>

This Week in HTML 5 - Episode 1
By Mark Pilgrim
"Welcome to a new semi-regular column, 'This Week in HTML 5,' where
I'll try to summarize the major activity in the ongoing standards
process in the WHATWG and W3C HTML Working Group..."
http://blog.whatwg.org/this-week-in-html5-episode-1

-- 
Laura L. Carlson


From rob at robburns.com  Sat Aug 16 02:08:12 2008
From: rob at robburns.com (Robert J Burns)
Date: Sat, 16 Aug 2008 12:08:12 +0300
Subject: [html4all] Object element support
Message-ID: <F2AC1F9A-0D5A-4DA5-B37B-28BECB27F1F3@robburns.com>

Hell 4all,

In another email, Leif raised the issue of OBJECT element support.  
I've brought the conversation here to the public list for this topic.  
I think the object element support is further along than most  
appreciate. Last year I had put together some informal test pages to  
see where the current state of support is:

* Test of sane default presentation of OBJECT element with no  
attributes [1] (the closest to commonly available IMG use)
* Test of sane default presentation of OBJECT element with height and  
width set explicitly [[2] (not necessary for IMG, but not really a  
large burden for authoring with OBJECT)

My sense is that the second form (providing explicit pixel dimensions  
either through the OBJECT height and width attribute or through CSS)  
works in all current browsers, and probably goes back some distance  
for historical browsers too (please correct me on that assumption if  
I'm wrong).

Safari (even in its current form) has a problem with Quicktime handled  
content that requires another otherwise needless complication from  
authors (the addition of one parameter element with name/value pair  
set to the same URL as the object element's data attribute). Maciej  
says its a QuickTIme bug (Steve Jobs would be so proud of an Apple  
employee passing the buck like that :-), but all the other browsers  
handle this fine without the extra markup. Unfortunately I didn't  
provide an example of this last document for testing, but I don't  
think it breaks anything in other browsers and it definitely works in  
Safari with the extra parameter element markup (the sample video and  
audio files have been deleted from the archives I think).

Take care,
Rob

[1]: <http://lists.w3.org/Archives/Public/www-archive/2007Aug/att-0027/TestObject.html 
 >
[2]: <http://lists.w3.org/Archives/Public/www-archive/2007Aug/att-0035/TestObjecttWMeasurments.html 
 >




From lhs at malform.no  Tue Aug 19 03:35:33 2008
From: lhs at malform.no (Leif Halvard Silli)
Date: Tue, 19 Aug 2008 12:35:33 +0200
Subject: [html4all] Object element support
In-Reply-To: <F2AC1F9A-0D5A-4DA5-B37B-28BECB27F1F3@robburns.com>
References: <F2AC1F9A-0D5A-4DA5-B37B-28BECB27F1F3@robburns.com>
Message-ID: <48AAA1F5.80501@malform.no>

Robert J Burns 2008-08-16 11.08:

> [...] I think the object element support is further along than
> most appreciate. Last year I had put together some informal
> test pages to see where the current state of support is: [...]


> [1]: <http://lists.w3.org/Archives/Public/www-archive/2007Aug/att-0027/TestObject.html 
> [2]: <http://lists.w3.org/Archives/Public/www-archive/2007Aug/att-0035/TestObjecttWMeasurments.html 


All debates about OBJECT tend to start/end in a debate about how 
to technially get it to work cross browser. But, actually, I think 
there are some conceptional problems to be solved first.

The most obvious problem with OBJECT is not technical. It is 
semantical. For instance: Does OBJECT have a method for offering 
both a long and a short text equivalent?

Once  the semantical problems are solved, perhaps it would be 
simpler to get cross browser /technical/ support? As the the 
problem now partly is to understand what we need OBJECT to do. 
E.g. Microsoft has a problem understanding that thing: [1. The 
IE-blog.]

	"<OBJECT> is not parsed in a cross-browser compatible way 
(parsing stops at the OBJECT, whereas other browsers continue 
parsing all the fallback content and make it available. No support 
for this parsing behavior is planned for IE8; I'll take this 
opportunity to ask for real-world scenarios that can help me 
prioritize this feature."

Some of your tests demonstrate how to use OBJECT with images, and 
many have recommended OBJECT to be used even for plain images. For 
a semantical comparison of those tests, let's look at an IMG with 
@alt and @longdesc.

It strikes me that  @alt and @longdesc represents *augementative* 
authoring. The reader, if he wants, can opt for the more full 
description in @longdesc. He is served a minimum, but can opt for 
more if he wants.  [2. See Jukka Korpela]

Whereas the OBJECT element, in its current shape and form, 
represents the concept of 'graceful degradation'. Or if you wish; 
The YGWYG = You Get What You Get principle.

As Joshue has said, it is *important* to be able to hide things 
for screen readers. But this is close to impossile with the OBJECT.

Examples: To use

	<object data=image >Alt text</object>

does not, unlike the @alt, close to guarantee that the text 
equivalent is short. And if you do

	<object data=image >Short<object>Long</object></object>

then how is the user able to (a) know that the long text exists, 
or to (b) select the long text if he knows it exists? [I don't 
know, are screen reader software in general able to, technically 
select the different nested OBJECTs?

	Ideas and proposals:

I would like to know what the community think about this:

	<object><img src=src alt=alt longdesc=#nextObject >
		<object id=nextObject>[markup]Long
	[/markup]</object></object>

The image would be displayed by default in all browsers (it works 
fine, even in IE6). However, even the long text will by default 
(in current User Agents) be displayed. I think such a method could 
replace the proposed <ALT> element. [3. HTML 5 Wiki.] Because, the 
proposed ALT element is also, by default, visible, though most 
authors would of course hide it. (Hiding the second OBJECT is 
difficult in IE6, but there are workarounds, such as wrapping.)

I also think @longdesc could be allowed as a boolean. And that it 
should be allowed in the OBJECT element. The meaning, as a 
boolean, should be that the next OBJECT contains a long text 
equivalent. (How @longdesc as boolean should work, needs to be 
fleshed out more.) I think @longdesc is the most important thing 
to ask for if we really want OBJECT to be used. For example then 
one could do this:

	<object><video src=video >
	<object longdesc=nextObject >Short text equivalent
	<object id=nextObject >[markup]Long.
	[/markup]</object></object></object>

In the prolongment of this proposal, I could imagine that all 
elements for replaced content (video, audio, img) could contain 
short text equivalents directly, like this:

	<replaced src=src>Short text equivalent.
	</replaced>

For example <video src=src>Short</video>. And that the presence of 
a boolean @longdesc would indicate the presence of an OBJECT with 
fallback content. For example like this:

	<video src=src longdesc >Short text equivalent.
	<object>[markup]Long.
	[/markup]</objecet></video>

Longdesc should continue to take URLs, for long equivalents which 
requires HTTP.

[1] See "Known issues we are not planning to change in IE8" in the 
official Internet Explorer blog.
<http://blogs.msdn.com/ie/archive/2008/04/10/html-and-dom-standards-compliance-in-ie8-beta-1.aspx>
[2] Jukka Korpela on augmentative authoring: 
<http://www.cs.tut.fi/~jkorpela/html/augm.html>
[3] A Better alt, in the ESW Wiki:
<http://esw.w3.org/topic/HTML/ABetterAlt>
-- 
leif halvard silli


From jason at jasonjgw.net  Tue Aug 19 04:00:32 2008
From: jason at jasonjgw.net (Jason White)
Date: Tue, 19 Aug 2008 21:00:32 +1000
Subject: [html4all] Object element support
In-Reply-To: <48AAA1F5.80501@malform.no>
References: <F2AC1F9A-0D5A-4DA5-B37B-28BECB27F1F3@robburns.com>
	<48AAA1F5.80501@malform.no>
Message-ID: <20080819110032.GA19723@jdc.jasonjgw.net>

On Tue, Aug 19, 2008 at 12:35:33PM +0200, Leif Halvard Silli wrote:
 
> The most obvious problem with OBJECT is not technical. It is 
> semantical. For instance: Does OBJECT have a method for offering 
> both a long and a short text equivalent?

The distinction between "long" and "short" text alternatives is really an
artifact of the poor design of the HTML IMG element. In XHTML 2.0, for
instance, we have:
<p src="image">Paragraph serving as an alternative.</p>

Of course, if the author so desires, the alternative can include a link
referring to additional information. This is true of OBJECT as well:

<object data="image"><p>An image. <a href="description.html">See this
description for full details.</a></object>

Some might argue that this isn't sufficient, since the user agent can't tell
that the link refers to a textual alternative, and therefore cannot handle it
specially. Whether this is a problem or not is debatable; I am not arguing the
matter either way in this post. However, assuming that this is considered a
problem worth addressing, I can think of several alternative solutions:

a. To define the semantics of @title on OBJECT as serving the purpose of
providing a short alternative.

b. To use a suitable Aria role on the anchor (<a>) element, or to define a
value of @role for this purpose in HTML. This assumes that @role finds its way
into HTML, of course.

c. To define <a rel="alternative"> so that the link can be identified as a
long alternative to the object.

Doubtless there are other options. The fundamental question, though, is how
important an issue this really is, and whether it is sufficiently significant
to be defined in the spec, or whether it would be unlikely to be used by
accessible user agents even if a mechanism were available.



From lhs at malform.no  Tue Aug 19 04:45:11 2008
From: lhs at malform.no (Leif Halvard Silli)
Date: Tue, 19 Aug 2008 13:45:11 +0200
Subject: [html4all] Object element support
In-Reply-To: <20080819110032.GA19723@jdc.jasonjgw.net>
References: <F2AC1F9A-0D5A-4DA5-B37B-28BECB27F1F3@robburns.com>	<48AAA1F5.80501@malform.no>
	<20080819110032.GA19723@jdc.jasonjgw.net>
Message-ID: <48AAB247.7020902@malform.no>

Jason White 2008-08-19 13.00:

> Tue, Aug 19, 2008 at 12:35:33PM +0200, Leif Halvard Silli:
> 
>> The most obvious problem with OBJECT is not technical. It is
>>  semantical. For instance: Does OBJECT have a method for
>> offering both a long and a short text equivalent?
> 
> The distinction between "long" and "short" text alternatives is
> really an artifact of the poor design of the HTML IMG element.
> In XHTML 2.0, for instance, we have: <p src="image">Paragraph
> serving as an alternative.</p>

That might be. But if so, then it seems to that it is a bug which 
has turned out to become a feature.

> Of course, if the author so desires, the alternative can
> include a link referring to additional information. This is
> true of OBJECT as well:
> 
> <object data="image"><p>An image. <a
> href="description.html">See this description for full
> details.</a></object>


That to me is not different from

	<p><img src=src alt="" />
	Short.
         <a href=longDescription >Long.
	</a></p>

 

(But then, why would be need @longdesc?)

> Some might argue that this isn't sufficient, since the user
> agent can't tell that the link refers to a textual alternative,
> and therefore cannot handle it specially. Whether this is a


It at least doesn't qualify as augmentative authoring!

> problem or not is debatable; I am not arguing the matter either
> way in this post. However, assuming that this is considered a 
> problem worth addressing, I can think of several alternative
> solutions:
> 
> a. To define the semantics of @title on OBJECT as serving the
> purpose of providing a short alternative.

Why would that be better than adding @longdesc to OBJECT?

> b. To use a suitable Aria role on the anchor (<a>) element, or
> to define a value of @role for this purpose in HTML. This
> assumes that @role finds its way into HTML, of course.

Does Aria offer differenciation between short and long description?

> c. To define <a rel="alternative"> so that the link can be
> identified as a long alternative to the object.


For use inside Object? Like this:

	<object image=data>Short.
	<a href=long rel=alternative>Link
	</a></object>

 

Then you are also saying that the first fallback is naturally short.

However, what about this:

	<object image=data>Short.
	<a href=#long rel=alternative>Link
	<object id=long>Long.
	</a></object>

  Do you say that the presence of that link should be what makes 
Internet Explorer "open up" the next Object?

> Doubtless there are other options. The fundamental question,
> though, is how important an issue this really is, and whether
> it is sufficiently significant to be defined in the spec, or
> whether it would be unlikely to be used by accessible user
> agents even if a mechanism were available.

By "this" I suppose you mean "being able to offer a short and a 
long description". As Gregory has said: Sometimes you need a short 
glimpse, other times you want to go into detail. I think this 
without doubt is needed.

Do you not agree that if one provides a short and a long 
description, then one should be able to author/read which is short 
and which is long? A boolean @longesc would say "the first is 
short".
-- 
leif halvard silli


From jason at jasonjgw.net  Tue Aug 19 18:03:26 2008
From: jason at jasonjgw.net (Jason White)
Date: Wed, 20 Aug 2008 11:03:26 +1000
Subject: [html4all] Object element support
In-Reply-To: <48AAB247.7020902@malform.no>
References: <F2AC1F9A-0D5A-4DA5-B37B-28BECB27F1F3@robburns.com>
	<48AAA1F5.80501@malform.no>
	<20080819110032.GA19723@jdc.jasonjgw.net>
	<48AAB247.7020902@malform.no>
Message-ID: <20080820010326.GA7419@jdc.jasonjgw.net>

On Tue, Aug 19, 2008 at 01:45:11PM +0200, Leif Halvard Silli wrote:
 
> That might be. But if so, then it seems to that it is a bug which 
> has turned out to become a feature.

I'm not persuaded that it is a feature. Personally, I don't care about the
distinction between "short" and "long" alternatives, but only that there is an
alternative that adequately substitutes for the image.
> 
> > Of course, if the author so desires, the alternative can
> > include a link referring to additional information. This is
> > true of OBJECT as well:
> > 
> > <object data="image"><p>An image. <a
> > href="description.html">See this description for full
> > details.</a></object>
> 
> 
> That to me is not different from
> 
> 	<p><img src=src alt="" />
> 	Short.
>          <a href=longDescription >Long.
> 	</a></p>
> 
>  
> 
> (But then, why would be need @longdesc?)

The two cases are very different. In the OBJECT case, the fact that the link
is contained in the OBJECT element establishes that it is part of the
alternative to the image. In your IMG example, the link is not, and cannot be,
included in the IMG element without the use of @longdesc. Hence, the image and
the link are semantically unrelated so far as the markup is concerned,
whereas, by definition, the content of the OBJECT element serves as an
alternative to the resource referred to in @data.
 
> > However, assuming that this is considered a 
> > problem worth addressing, I can think of several alternative
> > solutions:
> > 
> > a. To define the semantics of @title on OBJECT as serving the
> > purpose of providing a short alternative.
> 
> Why would that be better than adding @longdesc to OBJECT?

OBJECT already supports block-level content. The only reason for creating
@longdesc in the first place was that IMG didn't support inline or block-level
content. Since OBJECT doesn't have this design shortcoming, there is no need
for @longdesc, and including it would create a lot of confusion regarding how
to treat block-level content vs. the resource referred to by @longdesc.
> 
> > c. To define <a rel="alternative"> so that the link can be
> > identified as a long alternative to the object.
> 
> 
> For use inside Object? Like this:
> 
> 	<object image=data>Short.
> 	<a href=long rel=alternative>Link
> 	</a></object>
> 
>  
> 
> Then you are also saying that the first fallback is naturally short.

No, this is precisely what I am not saying. The fallback can be inline or
block-level, and as long as the author wishes it to be. However, if the author
wants to provide only a brief alternative in the text as a substitute for the
image, and more detail separately which the user can access, then it is
possible to do so by means of a link.

The IMG element forces a distinction between "short" and "long" alternatives.
OBJECT has the advantage, in its design, of not doing so. If I want to provide
a table as an alternative to a chart, I can do so without having to create a
separate page and using a link or @longdesc, provided that I use OBJECT rather
than IMG.

This is an advantage of OBJECT over IMG, and has long been acknowledged as
such.



From rob at robburns.com  Wed Aug 20 02:08:06 2008
From: rob at robburns.com (Robert J Burns)
Date: Wed, 20 Aug 2008 12:08:06 +0300
Subject: [html4all] Object element support
In-Reply-To: <20080820010326.GA7419@jdc.jasonjgw.net>
References: <F2AC1F9A-0D5A-4DA5-B37B-28BECB27F1F3@robburns.com>
	<48AAA1F5.80501@malform.no>
	<20080819110032.GA19723@jdc.jasonjgw.net>
	<48AAB247.7020902@malform.no>
	<20080820010326.GA7419@jdc.jasonjgw.net>
Message-ID: <559339D8-BDD7-4DF2-9F4F-F9A397FF771A@robburns.com>

Hi Jason, Leif and all,

On Aug 20, 2008, at 4:03 AM, Jason White wrote:

> On Tue, Aug 19, 2008 at 01:45:11PM +0200, Leif Halvard Silli wrote:
>
>> That might be. But if so, then it seems to that it is a bug which
>> has turned out to become a feature.
>
> I'm not persuaded that it is a feature. Personally, I don't care  
> about the
> distinction between "short" and "long" alternatives, but only that  
> there is an
> alternative that adequately substitutes for the image.
>>
>>> Of course, if the author so desires, the alternative can
>>> include a link referring to additional information. This is
>>> true of OBJECT as well:
>>>
>>> <object data="image"><p>An image. <a
>>> href="description.html">See this description for full
>>> details.</a></object>
>>
>>
>> That to me is not different from
>>
>> 	<p><img src=src alt="" />
>> 	Short.
>>         <a href=longDescription >Long.
>> 	</a></p>
>>
>>
>>
>> (But then, why would be need @longdesc?)
>
> The two cases are very different. In the OBJECT case, the fact that  
> the link
> is contained in the OBJECT element establishes that it is part of the
> alternative to the image. In your IMG example, the link is not, and  
> cannot be,
> included in the IMG element without the use of @longdesc. Hence, the  
> image and
> the link are semantically unrelated so far as the markup is concerned,
> whereas, by definition, the content of the OBJECT element serves as an
> alternative to the resource referred to in @data.
>
>>> However, assuming that this is considered a
>>> problem worth addressing, I can think of several alternative
>>> solutions:
>>>
>>> a. To define the semantics of @title on OBJECT as serving the
>>> purpose of providing a short alternative.
>>
>> Why would that be better than adding @longdesc to OBJECT?
>
> OBJECT already supports block-level content. The only reason for  
> creating
> @longdesc in the first place was that IMG didn't support inline or  
> block-level
> content. Since OBJECT doesn't have this design shortcoming, there is  
> no need
> for @longdesc, and including it would create a lot of confusion  
> regarding how
> to treat block-level content vs. the resource referred to by  
> @longdesc.
>>
>>> c. To define <a rel="alternative"> so that the link can be
>>> identified as a long alternative to the object.
>>
>>
>> For use inside Object? Like this:
>>
>> 	<object image=data>Short.
>> 	<a href=long rel=alternative>Link
>> 	</a></object>
>>
>>
>>
>> Then you are also saying that the first fallback is naturally short.
>
> No, this is precisely what I am not saying. The fallback can be  
> inline or
> block-level, and as long as the author wishes it to be. However, if  
> the author
> wants to provide only a brief alternative in the text as a  
> substitute for the
> image, and more detail separately which the user can access, then it  
> is
> possible to do so by means of a link.
>
> The IMG element forces a distinction between "short" and "long"  
> alternatives.
> OBJECT has the advantage, in its design, of not doing so. If I want  
> to provide
> a table as an alternative to a chart, I can do so without having to  
> create a
> separate page and using a link or @longdesc, provided that I use  
> OBJECT rather
> than IMG.
>
> This is an advantage of OBJECT over IMG, and has long been  
> acknowledged as
> such.

I really think we should get away from the short / long distinction. I  
would prefer to say that the IMG element forces a distinction between  
plaint text (and fairly easy to author) and rich markup text (and a  
little more cumbersome to author). On the other hand, OBJECT (and  
XHTML2 IMG) does not force this distinction. The length doesn't  
matter. The alt text should be whatever length is needed to serve as  
the alternate for the embedded media.

However, I think longdesc (and to a certain extent aria-describedby)  
provides another function that is useful beyond solving the problems  
of the text/html IMG element. That is providing a form of text  
equivalent for non-text media that is different from the alt text  
(that within the contents of the element or the value of the alt  
attribute). That is it can serve as a way to provide a description of  
the media that supplements the alt text. This is a distinction that I  
think is at the heart of this controversy over Flickr and alt text.

As an example I ran across this blog page[1]. About midway down the  
page is a photograph marked up with a figure and a caption (actually  
with div elements but used in the same way as HTML5 proposes) and the  
caption includes the text:

"Coal power plant. Coal is still dominant energy source for  
electricity production in US. <br>Click on picture for full size."

The photo is marked up with alt=''

The picture is of a coal power plant silhouetted along a waterway with  
the dusk sunset (or dawn sunrise) in the background. The plant is  
spewing smoke and steam into the air and we can see the conveyor that  
delivers coal to the plant.

My contention is that the description I just gave in the previous  
paragraph would be suitably referenced from the longdesc attribute  
(whether from IMG, OBJECT or any other embedding element). I feel that  
such text is not necessarily suitable for the alt attribute or as the  
contents of an OBJECT element because the reader loses nothing by  
missing the photograph and simply reading the caption. However, it  
would be a valuable service to users unable to consume the image to  
provide such a description in referenced by the longdesc attribute.

So to me such text does not qualify as alt text and does not have the  
same urgent status as the alt text and so should not be treated the  
same by HTML5. For example, we shouldn't necessarily require such text  
when it isn't integral to comprehending the document/page. Instead we  
should have alt text and we should have another mechanism for further  
text equivalent (especially for photographs) that is available (but  
not required) for those authors who go beyond the bare minimum of  
requirements. I note also that this example is contrary to Ian's claim  
that if the text is needed it should be provided to everyone in the  
caption. Those of us looking at the photograph do not want to read  
that description. So there are three types of text here: 1) alt text;  
2) caption text; and 3) descriptive text equivalent. But we've been  
trying to make these three types of text fit into two categories which  
contributes to the confusion of authors regarding suitable alt text.

I'm curious to here others thoughts on this.

Take care,
Rob

[1]: <http://interestingenergyfacts.blogspot.com/> 


From lhs at malform.no  Wed Aug 20 04:13:54 2008
From: lhs at malform.no (Leif Halvard Silli)
Date: Wed, 20 Aug 2008 13:13:54 +0200
Subject: [html4all] Object element support
In-Reply-To: <20080820010326.GA7419@jdc.jasonjgw.net>
References: <F2AC1F9A-0D5A-4DA5-B37B-28BECB27F1F3@robburns.com>	<48AAA1F5.80501@malform.no>	<20080819110032.GA19723@jdc.jasonjgw.net>	<48AAB247.7020902@malform.no>
	<20080820010326.GA7419@jdc.jasonjgw.net>
Message-ID: <48ABFC72.4090703@malform.no>

Jason White 2008-08-20 03.03:

> On Tue, Aug 19, 2008 at 01:45:11PM +0200, Leif Halvard Silli wrote:
>  
>> That might be. But if so, then it seems to that it is a bug which 
>> has turned out to become a feature.
> 
> I'm not persuaded that it is a feature. Personally, I don't care about the
> distinction between "short" and "long" alternatives, but only that there is an
> alternative that adequately substitutes for the image.


Rob's reply had me thinking that what I dubbed as short vs long, 
should perhaps rather be seen as "plain text, likely quite short" 
versus "markup, optionally long".

The thing is: You have some preknowledge about what the @alt text 
is - its quality. You, in fact, also know that the @longdesc 
resource is adequate for non-sighted readers, because its purpose 
is to cater for those who can't access the image as image - for 
whatever reaason (technical or otherwise).

Wheras for OBJECT, how do you know for whom the alternative(s) 
is/are made? There is no such guarantee.

 
>> > Of course, if the author so desires, the alternative can
>> > include a link referring to additional information. This is
>> > true of OBJECT as well:
>> > 
>> > <object data="image"><p>An image. <a
>> > href="description.html">See this description for full
>> > details.</a></object>
>> 
>> 
>> That to me is not different from
>> 
>> 	<p><img src=src alt="" />
>> 	Short.
>>          <a href=longDescription >Long.
>> 	</a></p>
>> 
>> (But then, why would be need @longdesc?)
> 
> The two cases are very different. In the OBJECT case, the fact that the link
> is contained in the OBJECT element establishes that it is part of the
> alternative to the image. In your IMG example, the link is not, and cannot be,
> included in the IMG element without the use of @longdesc. Hence, the image and
> the link are semantically unrelated so far as the markup is concerned,
> whereas, by definition, the content of the OBJECT element serves as an
> alternative to the resource referred to in @data.


I don't subscribe to "semantically unrelated" - how can you know 
that? However, I agree that there is nothing which 
formally/technically binds the link to the precedign IMG, and thus 
neither is the target of the link formally connected to the IMG.

  

As for your interpretation of the link within the OBJECT, I 
disagree there as well. Because, what make the nested OBJECT 
related to the parent OBJECT, is the fact that it is nested, and 
the fact that  nested OBJECTs are defined in HTML 4 as being 
alternatives.

>> > However, assuming that this is considered a 
>> > problem worth addressing, I can think of several alternative
>> > solutions:
>> > 
>> > a. To define the semantics of @title on OBJECT as serving the
>> > purpose of providing a short alternative.
>> 
>> Why would that be better than adding @longdesc to OBJECT?
> 
> OBJECT already supports block-level content. The only reason for creating
> @longdesc in the first place was that IMG didn't support inline or block-level
> content. Since OBJECT doesn't have this design shortcoming, there is no need
> for @longdesc, and including it would create a lot of confusion regarding how
> to treat block-level content vs. the resource referred to by @longdesc.

But @title also has defined meanings. I know of no other case were 
@title isn't supposed to be some kind of a title. (And, if, as you 
say, there is no need for short vs long, there would be no need 
for it either.)

I am lost with regarod to your point about "confusion".

Also, @longdesc /is/ a link. That is why proposed it.

>> > c. To define <a rel="alternative"> so that the link can be
>> > identified as a long alternative to the object.
>> 
>> 
>> For use inside Object? Like this:
>> 
>> 	<object image=data>Short.
>> 	<a href=long rel=alternative>Link
>> 	</a></object>
>> 
>> Then you are also saying that the first fallback is naturally short.
> 
> No, this is precisely what I am not saying. 


Sorry, 'you are saying' was supposed to mean 'one are saying'.

> The fallback can be inline or
> block-level, and as long as the author wishes it to be. However, if the author
> wants to provide only a brief alternative in the text as a substitute for the
> image, and more detail separately which the user can access, then it is
> possible to do so by means of a link.
> 
> The IMG element forces a distinction between "short" and "long" alternatives.
> OBJECT has the advantage, in its design, of not doing so. If I want to provide
> a table as an alternative to a chart, I can do so without having to create a
> separate page and using a link or @longdesc, provided that I use OBJECT rather
> than IMG.
> 
> This is an advantage of OBJECT over IMG, and has long been acknowledged as
> such.

There is no disagreement between us regarding the advantage of 
being able to insert mark-up as fallback in the OBJECT.

But as you know, limitatations are not always bad. They can 
sometime force us to do some good things which otherwise perhaps 
would not have come naturally - make us creative. So, e.g. if I 
run an IMG without an @alt in the validator, then it cries. 
Whereas if I insert an OBJECT without a fallback, then there is no 
cries, not even a warning. And I can even let a flash movie fall 
back to QuickTime instead of text. And still no cries.

Clearly, if the question of fallback was linked to @role rather 
than the kind of element - IMG or OBJECT in this case, then the 
validator could prompt for the addition of textual fallback 
(markup or plain text - how about MathML, screen readers ... ?).

But even then, there would have to be rules for what to place 
there. And how to place it. And how the user should get/select/be 
served /his/ fallback. (How do you place a link to the textual 
fallback in a QuickTime movie?) Today, following the rule of 
'graceful degradation', an OBJECT with a movie would contain 
"advanced movie format" in the first OBJECT, and a "not so 
advanced movie format" would come in the second OBJECT. Then 
perhaps you'd find plain text/markup in the third level. But 
perhaps the text level fallback should come in the second level?

Also, here is a nuisance: What should happen if the OBJECT is a 
movie, and the fallback is markup in the form of an IMG element, 
and then - in adddition, a second OBJECT has textual fallback?

	<object data=movie.mov >
	<img src=src alt=alt >
	<object><p>mark-up
	</p></object></object>

We would then get two conflicting fallback-regimes: That of the 
IMG and that of the OBJECT. It cold  at least end up very 
confusing. Perhaps the screen reader would read the @alt, and miss 
the presence of "a better alt" in the nested OBJECT? What should 
the rules for the use of IMG inside OBJECT be?

The combination of IMG, @alt, @longdesc, is like a microformat 
that has developed over time, with quite firm rules. OBJECT might 
be superior. But this has not been put into practise. As massive 
jump to OBJECT could have lead to a drop in accessibility due to 
lack of actual, practical advice and tradition (that authors are 
aware of) for how to use it.
-- 
leif halvard silli


From lhs at malform.no  Wed Aug 20 04:21:48 2008
From: lhs at malform.no (Leif Halvard Silli)
Date: Wed, 20 Aug 2008 13:21:48 +0200
Subject: [html4all] Object element support
In-Reply-To: <559339D8-BDD7-4DF2-9F4F-F9A397FF771A@robburns.com>
References: <F2AC1F9A-0D5A-4DA5-B37B-28BECB27F1F3@robburns.com>	<48AAA1F5.80501@malform.no>	<20080819110032.GA19723@jdc.jasonjgw.net>	<48AAB247.7020902@malform.no>	<20080820010326.GA7419@jdc.jasonjgw.net>
	<559339D8-BDD7-4DF2-9F4F-F9A397FF771A@robburns.com>
Message-ID: <48ABFE4C.2000107@malform.no>

Robert J Burns 2008-08-20 11.08:
     [...]

>> This is an advantage of OBJECT over IMG, and has long been 
>> acknowledged as such.

> 
> I really think we should get away from the short / long distinction. I  
> would prefer to say that the IMG element forces a distinction between  
> plaint text (and fairly easy to author) and rich markup text (and a  
> little more cumbersome to author). On the other hand, OBJECT (and  
> XHTML2 IMG) does not force this distinction. The length doesn't  
> matter. The alt text should be whatever length is needed to serve as  
> the alternate for the embedded media.

Forced or not, is it good for the reader to be able to know there 
is a distinction?

OBJECT doesn't force /any/ distinction. And has no minimum 
requirements. The fallback for a movie need not be neither plain 
text nor markup - it could be a slide show.
-- 
leif halvard silli



From rob at robburns.com  Wed Aug 20 04:46:07 2008
From: rob at robburns.com (Robert J Burns)
Date: Wed, 20 Aug 2008 14:46:07 +0300
Subject: [html4all] Object element support
In-Reply-To: <48ABFC72.4090703@malform.no>
References: <F2AC1F9A-0D5A-4DA5-B37B-28BECB27F1F3@robburns.com>	<48AAA1F5.80501@malform.no>	<20080819110032.GA19723@jdc.jasonjgw.net>	<48AAB247.7020902@malform.no>
	<20080820010326.GA7419@jdc.jasonjgw.net>
	<48ABFC72.4090703@malform.no>
Message-ID: <342A4D0B-1D95-45CC-9216-92651ABB49EA@robburns.com>

Hi Leif,

On Aug 20, 2008, at 2:13 PM, Leif Halvard Silli wrote:

> Jason White 2008-08-20 03.03:
>
>> On Tue, Aug 19, 2008 at 01:45:11PM +0200, Leif Halvard Silli wrote:
>>
>>> That might be. But if so, then it seems to that it is a bug which
>>> has turned out to become a feature.
>>
>> I'm not persuaded that it is a feature. Personally, I don't care  
>> about the
>> distinction between "short" and "long" alternatives, but only that  
>> there is an
>> alternative that adequately substitutes for the image.
>
>
> Rob's reply had me thinking that what I dubbed as short vs long,
> should perhaps rather be seen as "plain text, likely quite short"
> versus "markup, optionally long".

Even this doesn't get to the distinction that I'm trying to make. Take  
XHTML2 as an example. In XHTML2 all embedded media elements include  
the possibility of rich markup text in their own element contents (no  
need for an alt attribute). However, there is still a need for a  
separate kind of text equivalent (usually facilitated by the longdesc  
attribute) that is for description that is not alt text. In other  
words in XHTML2 (if it included a longdesc or aria:describedby  
attribute) could provide 1) alt text as a replacement for in- 
consumable non-text media and 2) a textual description for a more  
detailed subject or visual description of that media not necessarily  
as integral to the comprehension of the document as the alt text.

Now in this example, either can be long or short and either can be  
plain text or marked up text. The distinction is not about that, but  
rather how integral is this equivalent text to comprehending the  
document. I hope that helps clear up the distinction I'm trying to  
make. I think making a document truly accessible involves adding  
either or both of these text equivalents.

>
>
> The thing is: You have some preknowledge about what the @alt text
> is - its quality. You, in fact, also know that the @longdesc
> resource is adequate for non-sighted readers, because its purpose
> is to cater for those who can't access the image as image - for
> whatever reaason (technical or otherwise).
>
> Wheras for OBJECT, how do you know for whom the alternative(s)
> is/are made? There is no such guarantee.
>
>
>>>> Of course, if the author so desires, the alternative can
>>>> include a link referring to additional information. This is
>>>> true of OBJECT as well:
>>>>
>>>> <object data="image"><p>An image. <a
>>>> href="description.html">See this description for full
>>>> details.</a></object>
>>>
>>>
>>> That to me is not different from
>>>
>>> 	<p><img src=src alt="" />
>>> 	Short.
>>>         <a href=longDescription >Long.
>>> 	</a></p>
>>>
>>> (But then, why would be need @longdesc?)
>>
>> The two cases are very different. In the OBJECT case, the fact that  
>> the link
>> is contained in the OBJECT element establishes that it is part of the
>> alternative to the image. In your IMG example, the link is not, and  
>> cannot be,
>> included in the IMG element without the use of @longdesc. Hence,  
>> the image and
>> the link are semantically unrelated so far as the markup is  
>> concerned,
>> whereas, by definition, the content of the OBJECT element serves as  
>> an
>> alternative to the resource referred to in @data.
>
>
> I don't subscribe to "semantically unrelated" - how can you know
> that? However, I agree that there is nothing which
> formally/technically binds the link to the precedign IMG, and thus
> neither is the target of the link formally connected to the IMG.
>
>
>
> As for your interpretation of the link within the OBJECT, I
> disagree there as well. Because, what make the nested OBJECT
> related to the parent OBJECT, is the fact that it is nested, and
> the fact that  nested OBJECTs are defined in HTML 4 as being
> alternatives.
>
>>>> However, assuming that this is considered a
>>>> problem worth addressing, I can think of several alternative
>>>> solutions:
>>>>
>>>> a. To define the semantics of @title on OBJECT as serving the
>>>> purpose of providing a short alternative.
>>>
>>> Why would that be better than adding @longdesc to OBJECT?
>>
>> OBJECT already supports block-level content. The only reason for  
>> creating
>> @longdesc in the first place was that IMG didn't support inline or  
>> block-level
>> content. Since OBJECT doesn't have this design shortcoming, there  
>> is no need
>> for @longdesc, and including it would create a lot of confusion  
>> regarding how
>> to treat block-level content vs. the resource referred to by  
>> @longdesc.
>
> But @title also has defined meanings. I know of no other case were
> @title isn't supposed to be some kind of a title. (And, if, as you
> say, there is no need for short vs long, there would be no need
> for it either.)
>
> I am lost with regarod to your point about "confusion".
>
> Also, @longdesc /is/ a link. That is why proposed it.
>
>>>> c. To define <a rel="alternative"> so that the link can be
>>>> identified as a long alternative to the object.
>>>
>>>
>>> For use inside Object? Like this:
>>>
>>> 	<object image=data>Short.
>>> 	<a href=long rel=alternative>Link
>>> 	</a></object>
>>>
>>> Then you are also saying that the first fallback is naturally short.
>>
>> No, this is precisely what I am not saying.
>
>
> Sorry, 'you are saying' was supposed to mean 'one are saying'.
>
>> The fallback can be inline or
>> block-level, and as long as the author wishes it to be. However, if  
>> the author
>> wants to provide only a brief alternative in the text as a  
>> substitute for the
>> image, and more detail separately which the user can access, then  
>> it is
>> possible to do so by means of a link.
>>
>> The IMG element forces a distinction between "short" and "long"  
>> alternatives.
>> OBJECT has the advantage, in its design, of not doing so. If I want  
>> to provide
>> a table as an alternative to a chart, I can do so without having to  
>> create a
>> separate page and using a link or @longdesc, provided that I use  
>> OBJECT rather
>> than IMG.
>>
>> This is an advantage of OBJECT over IMG, and has long been  
>> acknowledged as
>> such.
>
> There is no disagreement between us regarding the advantage of
> being able to insert mark-up as fallback in the OBJECT.
>
> But as you know, limitatations are not always bad. They can
> sometime force us to do some good things which otherwise perhaps
> would not have come naturally - make us creative. So, e.g. if I
> run an IMG without an @alt in the validator, then it cries.
> Whereas if I insert an OBJECT without a fallback, then there is no
> cries, not even a warning. And I can even let a flash movie fall
> back to QuickTime instead of text. And still no cries.
>
> Clearly, if the question of fallback was linked to @role rather
> than the kind of element - IMG or OBJECT in this case, then the
> validator could prompt for the addition of textual fallback
> (markup or plain text - how about MathML, screen readers ... ?).
>
> But even then, there would have to be rules for what to place
> there. And how to place it. And how the user should get/select/be
> served /his/ fallback. (How do you place a link to the textual
> fallback in a QuickTime movie?) Today, following the rule of
> 'graceful degradation', an OBJECT with a movie would contain
> "advanced movie format" in the first OBJECT, and a "not so
> advanced movie format" would come in the second OBJECT. Then
> perhaps you'd find plain text/markup in the third level. But
> perhaps the text level fallback should come in the second level?
>
> Also, here is a nuisance: What should happen if the OBJECT is a
> movie, and the fallback is markup in the form of an IMG element,
> and then - in adddition, a second OBJECT has textual fallback?
>
> 	<object data=movie.mov >
> 	<img src=src alt=alt >
> 	<object><p>mark-up
> 	</p></object></object>
>
> We would then get two conflicting fallback-regimes: That of the
> IMG and that of the OBJECT. It cold  at least end up very
> confusing. Perhaps the screen reader would read the @alt, and miss
> the presence of "a better alt" in the nested OBJECT? What should
> the rules for the use of IMG inside OBJECT be?
>
> The combination of IMG, @alt, @longdesc, is like a microformat
> that has developed over time, with quite firm rules. OBJECT might
> be superior. But this has not been put into practise. As massive
> jump to OBJECT could have lead to a drop in accessibility due to
> lack of actual, practical advice and tradition (that authors are
> aware of) for how to use it.

I think you raise some good points here, especially regarding the  
OBJECT element's fallback and validator/conformance checking. Your  
example convinces me that we should require some significant text  
within the object element when the role keyword prescribes it.  
Otherwise we do lose the accessibility awareness raising benefits of  
the alt attribute.

However, I don't think the use of the OBJECT element is as complicated  
as you're making it out here. In other words the fallback semantics  
are very well defined. So in your example:

> 	<object data=movie.mov >
> 	<img src=src alt=alt >
> 	<object><p>mark-up
> 	</p></object></object>


the IMG element element does not serve as another fallback level.  
Rather both the IMG and the second OBJECT together form the fallback  
for the initial OBJECT. Their can only be one fallback level once the  
contents of an object includes anything other than an OBJECT or a  
PARAM element. Your construction doesn't cause a validator flag, but I  
think if definitely should. Or perhaps even two validator flags, one  
because an OBJECT is included in the ultimate text fallback and also  
because the IMG (another non-text media element) is included in the  
ultimate text fallback of the OBJECT element. So the way OBJECT is  
supposed to work (and maybe you're saying that the HTML 4.01  
recommendation doesn't make this clear enough) is that the OBJECT  
element can only contain 1) any number of PARAM child elements  
followed by one OBJECT element or 2) any number of PARM elements  
followed by FLOW content (but no OBJECT element).

I'll have to take a look at HTML 4.01 to see if this is explicit, but  
HTML5 should definitely make this clear.

Take care,
Rob


From lhs at malform.no  Wed Aug 20 05:35:13 2008
From: lhs at malform.no (Leif Halvard Silli)
Date: Wed, 20 Aug 2008 14:35:13 +0200
Subject: [html4all] Object element support
In-Reply-To: <342A4D0B-1D95-45CC-9216-92651ABB49EA@robburns.com>
References: <F2AC1F9A-0D5A-4DA5-B37B-28BECB27F1F3@robburns.com>	<48AAA1F5.80501@malform.no>	<20080819110032.GA19723@jdc.jasonjgw.net>	<48AAB247.7020902@malform.no>	<20080820010326.GA7419@jdc.jasonjgw.net>	<48ABFC72.4090703@malform.no>
	<342A4D0B-1D95-45CC-9216-92651ABB49EA@robburns.com>
Message-ID: <48AC0F81.7060908@malform.no>

Robert J Burns 2008-08-20 13.46:

> Hi Leif,
> 
> On Aug 20, 2008, at 2:13 PM, Leif Halvard Silli wrote:
> 
>> Jason White 2008-08-20 03.03:
>>
>>> On Tue, Aug 19, 2008 at 01:45:11PM +0200, Leif Halvard Silli wrote:
>>>
>>>> That might be. But if so, then it seems to that it is a bug which
>>>> has turned out to become a feature.
>>>
>>> I'm not persuaded that it is a feature. Personally, I don't care  
>>> about the
>>> distinction between "short" and "long" alternatives, but only that  
>>> there is an
>>> alternative that adequately substitutes for the image.
>>
>>
>> Rob's reply had me thinking that what I dubbed as short vs long,
>> should perhaps rather be seen as "plain text, likely quite short"
>> versus "markup, optionally long".
> 
> Even this doesn't get to the distinction that I'm trying to make. Take  
> XHTML2 as an example. In XHTML2 all embedded media elements include  
> the possibility of rich markup text in their own element contents (no  
> need for an alt attribute). However, there is still a need for a  
> separate kind of text equivalent (usually facilitated by the longdesc  
> attribute) that is for description that is not alt text. In other  


Are you saying that @longdesc is used more or less as I proposed 
in XHTML 2? Or, at least, that they have extended its use there?

> words in XHTML2 (if it included a longdesc or aria:describedby  
> attribute) could provide 1) alt text as a replacement for in- 
> consumable non-text media and 2) a textual description for a more  
> detailed subject or visual description of that media not necessarily  
> as integral to the comprehension of the document as the alt text.
> 
> Now in this example, either can be long or short and either can be  
> plain text or marked up text. The distinction is not about that, but  
> rather how integral is this equivalent text to comprehending the  
> document. I hope that helps clear up the distinction I'm trying to  
> make. I think making a document truly accessible involves adding  
> either or both of these text equivalents.


If you say that e.g. OBJECT should have a rquirement of a textual 
fallabk, in a validate-able way, then we are en route.

[... snipped my OBJECT fallback problem description ... ]

> I think you raise some good points here, especially regarding the  
> OBJECT element's fallback and validator/conformance checking. Your  
> example convinces me that we should require some significant text  
> within the object element when the role keyword prescribes it.  
> Otherwise we do lose the accessibility awareness raising benefits of  
> the alt attribute.


Good to know.

 
> However, I don't think the use of the OBJECT element is as complicated  
> as you're making it out here. In other words the fallback semantics  
> are very well defined. So in your example:
> 
>> 	<object data=movie.mov >
>> 	<img src=src alt=alt >
>> 	<object><p>mark-up
>> 	</p></object></object>
> 
> 
> the IMG element element does not serve as another fallback level.  
> Rather both the IMG and the second OBJECT together form the fallback  
> for the initial OBJECT. Their can only be one fallback level once the  
> contents of an object includes anything other than an OBJECT or a  
> PARAM element. 



Hm. So, in that case, the nested OBJECT would instantiate an 
independent, /new/ OBJECT with its own fallback treatment, 
independent form the top-level OBJECt, then I guess:

  	<object data=one-movie.mov >
	<!-- all this is fallback for 'one movie': -->
  	<img src=src alt='Fallback for IMG, as part of
         fallback for one-movie.' >
  	<object  data=another-movie.mov >
	Fallback for 'another movie', which again is
         fallback for one-movie.
         <!-- end of fallback for 'one movie' -->
  	</p></object></object>

But this, then -- again -- illustrates how the fallback of OBJECT 
isn't geared at screen readers, as the fallback itself can contain 
both text and movies, simultanously.

> Your construction doesn't cause a validator flag, but I  
> think if definitely should. Or perhaps even two validator flags, one  
> because an OBJECT is included in the ultimate text fallback and also  
> because the IMG (another non-text media element) is included in the  
> ultimate text fallback of the OBJECT element. So the way OBJECT is  
> supposed to work (and maybe you're saying that the HTML 4.01  
> recommendation doesn't make this clear enough) is that the OBJECT  
> element can only contain 1) any number of PARAM child elements  
> followed by one OBJECT element or 2) any number of PARM elements  
> followed by FLOW content (but no OBJECT element).
> 
> I'll have to take a look at HTML 4.01 to see if this is explicit, but  
> HTML5 should definitely make this clear.

Must give this more thought. But I feel what you say suppports 
what I've said about how OBJECT is lacking an actual description 
of how it, in the "real world", is going to be used. There is to 
much high level "it is superior" thinking going on, without 
looking at the details of how it should be used, is my view.
-- 
leif halvard silli


From rob at robburns.com  Wed Aug 20 15:49:28 2008
From: rob at robburns.com (Robert J Burns)
Date: Thu, 21 Aug 2008 01:49:28 +0300
Subject: [html4all] Object element support
In-Reply-To: <48AC0F81.7060908@malform.no>
References: <F2AC1F9A-0D5A-4DA5-B37B-28BECB27F1F3@robburns.com>	<48AAA1F5.80501@malform.no>	<20080819110032.GA19723@jdc.jasonjgw.net>	<48AAB247.7020902@malform.no>	<20080820010326.GA7419@jdc.jasonjgw.net>	<48ABFC72.4090703@malform.no>
	<342A4D0B-1D95-45CC-9216-92651ABB49EA@robburns.com>
	<48AC0F81.7060908@malform.no>
Message-ID: <AD0C728B-4A67-47DA-8E54-8F4F7243A4CD@robburns.com>

Hi Leif,

On Aug 20, 2008, at 3:35 PM, Leif Halvard Silli wrote:

> Robert J Burns 2008-08-20 13.46:
>>
>> On Aug 20, 2008, at 2:13 PM, Leif Halvard Silli wrote:
>>
>> However, I don't think the use of the OBJECT element is as  
>> complicated
>> as you're making it out here. In other words the fallback semantics
>> are very well defined. So in your example:
>>
>>> 	<object data=movie.mov >
>>> 	<img src=src alt=alt >
>>> 	<object><p>mark-up
>>> 	</p></object></object>
>>
>>
>> the IMG element element does not serve as another fallback level.
>> Rather both the IMG and the second OBJECT together form the fallback
>> for the initial OBJECT. Their can only be one fallback level once the
>> contents of an object includes anything other than an OBJECT or a
>> PARAM element.
>
>
>
> Hm. So, in that case, the nested OBJECT would instantiate an
> independent, /new/ OBJECT with its own fallback treatment,
> independent form the top-level OBJECt, then I guess:
>
>  	<object data=one-movie.mov >
> 	<!-- all this is fallback for 'one movie': -->
>  	<img src=src alt='Fallback for IMG, as part of
>         fallback for one-movie.' >
>  	<object  data=another-movie.mov >
> 	Fallback for 'another movie', which again is
>         fallback for one-movie.
>         <!-- end of fallback for 'one movie' -->
>  	</p></object></object>
>
> But this, then -- again -- illustrates how the fallback of OBJECT
> isn't geared at screen readers, as the fallback itself can contain
> both text and movies, simultanously.

Well it is still geared at screen readers as long as each bit of  
embedded non-text media has some text fallback. In your example  
everything is covered in terms of alt text / text equivalents.

>
>
>> Your construction doesn't cause a validator flag, but I
>> think if definitely should. Or perhaps even two validator flags, one
>> because an OBJECT is included in the ultimate text fallback and also
>> because the IMG (another non-text media element) is included in the
>> ultimate text fallback of the OBJECT element. So the way OBJECT is
>> supposed to work (and maybe you're saying that the HTML 4.01
>> recommendation doesn't make this clear enough) is that the OBJECT
>> element can only contain 1) any number of PARAM child elements
>> followed by one OBJECT element or 2) any number of PARM elements
>> followed by FLOW content (but no OBJECT element).
>>
>> I'll have to take a look at HTML 4.01 to see if this is explicit, but
>> HTML5 should definitely make this clear.
>
> Must give this more thought. But I feel what you say suppports
> what I've said about how OBJECT is lacking an actual description
> of how it, in the "real world", is going to be used. There is to
> much high level "it is superior" thinking going on, without
> looking at the details of how it should be used, is my view.

Yeah, I think you're partially right. I took a look at the HTML 4.01  
prose[1] and DTD[2] and the DTD fails to give unambiguous normative  
guidance on precisely how this should work. The prose on the other  
hand do explain it, but there could still be some ambiguities that I'm  
missing. It doesn't have the normative language that the HTML5 draft  
should include. It should be made clear that every object element  
should include an ultimate fallback object element containing FLOW  
content minus any other embedded non-text media elements. (IMG,  
CANVAS, APPLET, EMBED, VIDEO, AUDIO, OBJECT).

I think your example is still a bit unorthodox however, since normally  
the content model should be (PARAM* , OBJECT) or (PARAM* , (&flow;)* -  
[embedded media elements]). In other words either object fallback or  
flow fallback with no embedding. I think the conformance checker  
should check for this. And in cases other than role='decorative', the  
conformance checker should throw errors for missing text fallback (or  
throw warning for role='photo').

BTW, further reflection on your earlier quote form the Microsoft IE  
Blog[3], leaves me a little stunned if this is actually true. Does  
anyone have IE (any version) handy to test this? As Leif quoted earlier:

"<OBJECT> is not parsed in a cross-browser compatible way (parsing  
stops at the OBJECT, whereas other browsers continue parsing all the  
fallback content and make it available. No support for this parsing  
behavior is planned for IE8; I'll take this opportunity to ask for  
real-world scenarios that can help me prioritize this feature."
I find it hard to believe that the content of the OBJECT element are  
not parsed. Is it simply thrown away? Is it added to the DOM as plain  
text? Or does it mean that the more sophisticated fallback mechanism  
enabled by the OBJECT element is not supported so that IE simply  
handles only the first embedded content and ignores the remaining  
content. Does IE have a DOM browser like the other browsers? I guess  
you could always view it at Hixie's DOM viewer[4]. If the tree of  
OBJECT elements is shown properly nested with the fallback text in a  
text node within the second object than the IE blog entry is incorrect.

Take care,
Rob

[1]: <http://www.w3.org/TR/html4/struct/objects.html>
[2]: <http://www.w3.org/TR/html4/sgml/dtd.html>
[3]: See "Known issues we are not planning to change in IE8" in the  
official Internet Explorer blog. <http://blogs.msdn.com/ie/archive/2008/04/10/html-and-dom-standards-compliance-in-ie8-beta-1.aspx 
 >
[4]: <http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cobject%20data%3D'http%3A%2F%2Flists.w3.org%2FArchives%2FPublic%2Fwww-archive%2F2007Aug%2Fatt-0027%2FTestVideo.3gp'%20%3E%0A%20%20%20%20%20%3Cobject%20data%3D'http%3A%2F%2Flists.w3.org%2FArchives%2FPublic%2Fwww-archive%2F2007Aug%2Fatt-0026%2Fimage.gif'%20%3Esome%20fallback%3C%2Fobject%3E%0A%3C%2Fobject%3E 
 >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://wilbur.bytowninternet.com/pipermail/list_html4all.org/attachments/20080821/6600323a/attachment.html 

From lhs at malform.no  Wed Aug 20 20:15:47 2008
From: lhs at malform.no (Leif Halvard Silli)
Date: Thu, 21 Aug 2008 05:15:47 +0200
Subject: [html4all] Object element support
In-Reply-To: <AD0C728B-4A67-47DA-8E54-8F4F7243A4CD@robburns.com>
References: <F2AC1F9A-0D5A-4DA5-B37B-28BECB27F1F3@robburns.com>	<48AAA1F5.80501@malform.no>	<20080819110032.GA19723@jdc.jasonjgw.net>	<48AAB247.7020902@malform.no>	<20080820010326.GA7419@jdc.jasonjgw.net>	<48ABFC72.4090703@malform.no>	<342A4D0B-1D95-45CC-9216-92651ABB49EA@robburns.com>	<48AC0F81.7060908@malform.no>
	<AD0C728B-4A67-47DA-8E54-8F4F7243A4CD@robburns.com>
Message-ID: <48ACDDE3.3060306@malform.no>

Robert J Burns 2008-08-21 00.49:

> On Aug 20, 2008, at 3:35 PM, Leif Halvard Silli wrote:


>>      <object data=one-movie.mov >
>>     <!-- all this is fallback for 'one movie': -->
>>      <img src=src alt='Fallback for IMG, as part of
>>         fallback for one-movie.' >
>>      <object  data=another-movie.mov >
>>     Fallback for 'another movie', which again is
>>         fallback for one-movie.
>>         <!-- end of fallback for 'one movie' -->
>>      </p></object></object>
>>
>> But this, then -- again -- illustrates how the fallback of OBJECT
>> isn't geared at screen readers, as the fallback itself can contain
>> both text and movies, simultanously.
> 
> Well it is still geared at screen readers as long as each bit of 
> embedded non-text media has some text fallback. In your example 
> everything is covered in terms of alt text / text equivalents.


So you don't hink a validator should OK this?

>> Must give this more thought. But I feel what you say suppports
>> what I've said about how OBJECT is lacking an actual description
>> of how it, in the "real world", is going to be used. There is to
>> much high level "it is superior" thinking going on, without
>> looking at the details of how it should be used, is my view.
> 
> Yeah, I think you're partially right. I took a look at the HTML 4.01 
> prose[1] and DTD[2] and the DTD fails to give unambiguous normative 
> guidance on precisely how this should work. The prose on the other hand 
> do explain it, but there could still be some ambiguities that I'm 
> missing. It doesn't have the normative language that the HTML5 draft 
> should include. It should be made clear that every object element should 
> include an ultimate fallback object element containing FLOW content 
> minus any other embedded non-text media elements. (IMG, CANVAS, APPLET, 
> EMBED, VIDEO, AUDIO, OBJECT).
>

> I think your example is still a bit unorthodox however, since normally 
> the content model should be (PARAM* , OBJECT) or (PARAM* , (&flow;)* - 
> [embedded media elements]). 


HTML 4 does not preclue the inclusion of IMG amongst the flow 
elemements. In fact, IMG is also flow. As is OBJECT itself. (As 
you yourself note .)

> In other words either object fallback or 
> flow fallback with no embedding. I think the conformance checker should 
> check for this. And in cases other than role='decorative', the 
> conformance checker should throw errors for missing text fallback (or 
> throw warning for role='photo').


Perhaps a warning if the flow contains an IMG. But not an error, 
unless the fallback of the IMG itself is used wrong. Why shouldn't 
embedded not-text elements be permitted,  provided they contain 
fallback themselves?

I also wonder whether <objeect type="text/html" .... > should be 
equal to the requirement of text fallback?

> BTW, further reflection on your earlier quote form the Microsoft IE 
> Blog[3], leaves me a little stunned if this is actually true. Does 
> anyone have IE (any version) handy to test this? As Leif quoted earlier:
> 
> "<OBJECT> is not parsed in a cross-browser compatible way (parsing stops 
> at the OBJECT, whereas other browsers continue parsing all the fallback 
> content and make it available. No support for this parsing behavior is 
> planned for IE8; I'll take this opportunity to ask for real-world 
> scenarios that can help me prioritize this feature."

 >

> I find it hard to believe that the content of the OBJECT element are not 
> parsed. Is it simply thrown away? Is it added to the DOM as plain text? 
> Or does it mean that the more sophisticated fallback mechanism enabled 
> by the OBJECT element is not supported so that IE simply handles only 
> the first embedded content and ignores the remaining content. Does IE 
> have a DOM browser like the other browsers? I guess you could always 
> view it at Hixie's DOM viewer[4]. If the tree of OBJECT elements is 
> shown properly nested with the fallback text in a text node within the 
> second object than the IE blog entry is incorrect


IN IE 6 the statement seems correct. And after having installed 
IE8beta, it seems you are right in that it is not correct for IE8 
... (Have not tried IE7, and do not trust the IE7 emulation of 
IE8.) However, a better test case than yours is this (since in 
your test, in IE8beta1, the GIF would actually be displayed):

<object data="data:application/x-unknown,ERROR" >
<object type="image/gif" data="object-ie8.gif" >
some fallback</object></object

Either they were wrong, or we misunderstands the issue ... I 
wonder if they mean that if an OBJECT with an working 
data="attribute" URI is found, then then the other nested OBJECTS 
and the rest of the fallback content is ignored.
-- 
leif halvard silli


From rob at robburns.com  Thu Aug 21 02:11:51 2008
From: rob at robburns.com (Robert J Burns)
Date: Thu, 21 Aug 2008 12:11:51 +0300
Subject: [html4all] Object element support
In-Reply-To: <48ACDDE3.3060306@malform.no>
References: <F2AC1F9A-0D5A-4DA5-B37B-28BECB27F1F3@robburns.com>	<48AAA1F5.80501@malform.no>	<20080819110032.GA19723@jdc.jasonjgw.net>	<48AAB247.7020902@malform.no>	<20080820010326.GA7419@jdc.jasonjgw.net>	<48ABFC72.4090703@malform.no>	<342A4D0B-1D95-45CC-9216-92651ABB49EA@robburns.com>	<48AC0F81.7060908@malform.no>
	<AD0C728B-4A67-47DA-8E54-8F4F7243A4CD@robburns.com>
	<48ACDDE3.3060306@malform.no>
Message-ID: <3B79E5D2-AD51-4C90-8185-6CE8C9E8BBFE@robburns.com>

Hi Leif,

On Aug 21, 2008, at 6:15 AM, Leif Halvard Silli wrote:

> Robert J Burns 2008-08-21 00.49:
>
>> On Aug 20, 2008, at 3:35 PM, Leif Halvard Silli wrote:
>
>
>>>     <object data=one-movie.mov >
>>>    <!-- all this is fallback for 'one movie': -->
>>>     <img src=src alt='Fallback for IMG, as part of
>>>        fallback for one-movie.' >
>>>     <object  data=another-movie.mov >
>>>    Fallback for 'another movie', which again is
>>>        fallback for one-movie.
>>>        <!-- end of fallback for 'one movie' -->
>>>     </p></object></object>
>>>
>>> But this, then -- again -- illustrates how the fallback of OBJECT
>>> isn't geared at screen readers, as the fallback itself can contain
>>> both text and movies, simultanously.
>>
>> Well it is still geared at screen readers as long as each bit of
>> embedded non-text media has some text fallback. In your example
>> everything is covered in terms of alt text / text equivalents.
>
>
> So you don't hink a validator should OK this?

No, I think the validator should throw an error for the IMG element.  
However, I'm saying everything is covered in terms of UA conformance.  
That is even though a document is in error following your example, the  
UA could still produce intelligible output for the user (I'm only  
saying in error for HTML5, though I think the prose of HTML4 also  
imply this is an error). It could be make to work, but I think it adds  
needless complications to permit it in document conformance.

>>> Must give this more thought. But I feel what you say suppports
>>> what I've said about how OBJECT is lacking an actual description
>>> of how it, in the "real world", is going to be used. There is to
>>> much high level "it is superior" thinking going on, without
>>> looking at the details of how it should be used, is my view.
>>
>> Yeah, I think you're partially right. I took a look at the HTML 4.01
>> prose[1] and DTD[2] and the DTD fails to give unambiguous normative
>> guidance on precisely how this should work. The prose on the other  
>> hand
>> do explain it, but there could still be some ambiguities that I'm
>> missing. It doesn't have the normative language that the HTML5 draft
>> should include. It should be made clear that every object element  
>> should
>> include an ultimate fallback object element containing FLOW content
>> minus any other embedded non-text media elements. (IMG, CANVAS,  
>> APPLET,
>> EMBED, VIDEO, AUDIO, OBJECT).
>>
>
>> I think your example is still a bit unorthodox however, since  
>> normally
>> the content model should be (PARAM* , OBJECT) or (PARAM* ,  
>> (&flow;)* -
>> [embedded media elements]).
>
>
> HTML 4 does not preclue the inclusion of IMG amongst the flow
> elemements. In fact, IMG is also flow. As is OBJECT itself. (As
> you yourself note .)

It doesn't in the DTD, but I think the prose imply this is non- 
conforming. Again, I think the prose implies this is non-conforming,  
but it is not stated clearly enough for my taste.

>> In other words either object fallback or
>> flow fallback with no embedding. I think the conformance checker  
>> should
>> check for this. And in cases other than role='decorative', the
>> conformance checker should throw errors for missing text fallback (or
>> throw warning for role='photo').
>
>
> Perhaps a warning if the flow contains an IMG. But not an error,
> unless the fallback of the IMG itself is used wrong. Why shouldn't
> embedded not-text elements be permitted,  provided they contain
> fallback themselves?
>
> I also wonder whether <objeect type="text/html" .... > should be
> equal to the requirement of text fallback?

or 'text/plain', or even 'text/rtf'. For these I think the validator  
should throw warnings only. After all text/plain could even be ascii  
art (just as one example) and still require either object alt text or  
longdesc. Also since the author of the present document may have no  
control over the accessibility of the embedded documents, the author  
may need to include the appropriate alt text and other text  
equivalents in the primary document.

>
>
>> BTW, further reflection on your earlier quote form the Microsoft IE
>> Blog[3], leaves me a little stunned if this is actually true. Does
>> anyone have IE (any version) handy to test this? As Leif quoted  
>> earlier:
>>
>> "<OBJECT> is not parsed in a cross-browser compatible way (parsing  
>> stops
>> at the OBJECT, whereas other browsers continue parsing all the  
>> fallback
>> content and make it available. No support for this parsing behavior  
>> is
>> planned for IE8; I'll take this opportunity to ask for real-world
>> scenarios that can help me prioritize this feature."
>
>>
>
>> I find it hard to believe that the content of the OBJECT element  
>> are not
>> parsed. Is it simply thrown away? Is it added to the DOM as plain  
>> text?
>> Or does it mean that the more sophisticated fallback mechanism  
>> enabled
>> by the OBJECT element is not supported so that IE simply handles only
>> the first embedded content and ignores the remaining content. Does IE
>> have a DOM browser like the other browsers? I guess you could always
>> view it at Hixie's DOM viewer[4]. If the tree of OBJECT elements is
>> shown properly nested with the fallback text in a text node within  
>> the
>> second object than the IE blog entry is incorrect
>
>
> IN IE 6 the statement seems correct. And after having installed
> IE8beta, it seems you are right in that it is not correct for IE8
> ... (Have not tried IE7, and do not trust the IE7 emulation of
> IE8.) However, a better test case than yours is this (since in
> your test, in IE8beta1, the GIF would actually be displayed):
>
> <object data="data:application/x-unknown,ERROR" >
> <object type="image/gif" data="object-ie8.gif" >
> some fallback</object></object
>
> Either they were wrong, or we misunderstands the issue ... I
> wonder if they mean that if an OBJECT with an working
> data="attribute" URI is found, then then the other nested OBJECTS
> and the rest of the fallback content is ignored.

Well, if an object is reached that IE can handle natively or through a  
plugin handler, then that is what the HTML4.01 recommendation expects.  
The issue is if you view the DOM, do you see the descendant nodes  
there. If so then a sophisticated add-on or screen reader (something  
like Fire Vox for example, though it is for Firefox) can get to the  
fallback for accessibility reasons. In other words the DOM should look  
something like:

HTML
	? HEAD
	? BODY
		? OBJECT data="data:application/x-unknown,ERROR"
			? #text:
			? OBJECT type="image/gif" data="object-ie8.gif"
				? #text: some fallback

If that's all there in IE, and IE selects the first supported or  
enabled mime type in hierarchical order, then that's all we would  
expect (since IE has no aural/braille features of its own).

Take care,
Rob

From rob at robburns.com  Thu Aug 21 02:21:51 2008
From: rob at robburns.com (Robert J Burns)
Date: Thu, 21 Aug 2008 12:21:51 +0300
Subject: [html4all] Object element support
In-Reply-To: <3B79E5D2-AD51-4C90-8185-6CE8C9E8BBFE@robburns.com>
References: <F2AC1F9A-0D5A-4DA5-B37B-28BECB27F1F3@robburns.com>	<48AAA1F5.80501@malform.no>	<20080819110032.GA19723@jdc.jasonjgw.net>	<48AAB247.7020902@malform.no>	<20080820010326.GA7419@jdc.jasonjgw.net>	<48ABFC72.4090703@malform.no>	<342A4D0B-1D95-45CC-9216-92651ABB49EA@robburns.com>	<48AC0F81.7060908@malform.no>
	<AD0C728B-4A67-47DA-8E54-8F4F7243A4CD@robburns.com>
	<48ACDDE3.3060306@malform.no>
	<3B79E5D2-AD51-4C90-8185-6CE8C9E8BBFE@robburns.com>
Message-ID: <04873D9F-6390-4054-92C6-377F8A7BB5AF@robburns.com>

Hi Leif,

On Aug 21, 2008, at 12:11 PM, Robert J Burns wrote:
> On Aug 21, 2008, at 6:15 AM, Leif Halvard Silli wrote:
>>
>> IN IE 6 the statement seems correct. And after having installed
>> IE8beta, it seems you are right in that it is not correct for IE8
>> ... (Have not tried IE7, and do not trust the IE7 emulation of
>> IE8.) However, a better test case than yours is this (since in
>> your test, in IE8beta1, the GIF would actually be displayed):
>>
>> <object data="data:application/x-unknown,ERROR" >
>> <object type="image/gif" data="object-ie8.gif" >
>> some fallback</object></object
>>
>> Either they were wrong, or we misunderstands the issue ... I
>> wonder if they mean that if an OBJECT with an working
>> data="attribute" URI is found, then then the other nested OBJECTS
>> and the rest of the fallback content is ignored.
>
> Well, if an object is reached that IE can handle natively or through a
> plugin handler, then that is what the HTML4.01 recommendation expects.
> The issue is if you view the DOM, do you see the descendant nodes
> there. If so then a sophisticated add-on or screen reader (something
> like Fire Vox for example, though it is for Firefox) can get to the
> fallback for accessibility reasons. In other words the DOM should look
> something like:
>
> HTML
> 	? HEAD
> 	? BODY
> 		? OBJECT data="data:application/x-unknown,ERROR"
> 			? #text:
> 			? OBJECT type="image/gif" data="object-ie8.gif"
> 				? #text: some fallback
>
> If that's all there in IE, and IE selects the first supported or
> enabled mime type in hierarchical order, then that's all we would
> expect (since IE has no aural/braille features of its own).

It occurs to me that the IE blogger may have simply been saying that  
they don't support alterante fallback in a different way. For example  
if the first file is application/xhtml+xml, and the resource is  
available, IE may instead resort to downloading it rather than falling  
back to the next OBJECT. Or maybe they do not support more than two  
fallbacks. Or maybe they're just saying that they don't offer user  
options to disable certain types of content (like for accessibility  
reasons). It is difficult to figure out what they could mean there[1].

Take care,
Rob

[1]: See "Known issues we are not planning to change in IE8" in the  
official Internet Explorer blog on the OBJECT element. <http://blogs.msdn.com/ie/archive/2008/04/10/html-and-dom-standards-compliance-in-ie8-beta-1.aspx 
 >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://wilbur.bytowninternet.com/pipermail/list_html4all.org/attachments/20080821/de25d37d/attachment.html 

From faulkner.steve at gmail.com  Thu Aug 21 03:51:13 2008
From: faulkner.steve at gmail.com (Steven Faulkner)
Date: Thu, 21 Aug 2008 11:51:13 +0100
Subject: [html4all] Fwd: some reflections on @alt usage
In-Reply-To: <55687cf80808210307j8e49ebbj87558c9c0bded49c@mail.gmail.com>
References: <5F228EF6-8B10-4DAC-B5E6-401C7B471404@IEEE.org>
	<Pine.LNX.4.62.0808041021170.13400@hixie.dreamhostps.com>
	<809E8F77-85DF-4366-AED3-62F7FD8F2F83@ieee.org>
	<Pine.LNX.4.62.0808192112530.14795@hixie.dreamhostps.com>
	<F02B51A9-F034-4681-A3DC-95E4EEDD136B@ieee.org>
	<Pine.LNX.4.62.0808201812240.19930@hixie.dreamhostps.com>
	<55687cf80808210307j8e49ebbj87558c9c0bded49c@mail.gmail.com>
Message-ID: <55687cf80808210351u3ede90a1r8926ea56e9c9a41e@mail.gmail.com>

for those that may be interested: the beat goes on...
Is it worth it? propabaly not.

---------- Forwarded message ----------
From: Steven Faulkner <faulkner.steve at gmail.com>
Date: 2008/8/21
Subject: Re: some reflections on @alt usage
To: Ian Hickson <ian at hixie.ch>
Cc: Al Gilman <Alfred.S.Gilman at ieee.org>, W3C WAI-XTECH <wai-xtech at w3.org>


hi ian,


>There are two problems with this. One is that the descriptive
>identification of the non-text content would almost certainly be provided
>anyway, e.g. as the image caption, for all users, and thus including it in
>the alt="" attribute would be redundant, leading to "stuttering" (that is,
>content repetition).


Can you provide the the research to back up the claim that descriptive
identification would almost certainly be provided elsewhere?

The caption for such an image does not necessarily suffice  as the
text alternative, much more descriptive information can be provided
for disabled users who cannot view the image or have a vision
impairment that renders image blurred. Who are you to decide that this
information is not worthy of inclusion by mandating that the alt must
be of the form {}.


In the example below the alt provides descriptive information that may
be useful to visually impaired users. It provides information that
would be obvious to a sighted user but could not be ascertained by a
vison impaired user unless they asked someone to describe it to them.
That is the point of a textual alternative, to provide information to
a disabled user that cannot access the information themselves.

<figure>
<img src="/commons/a/a7/Rorschach1.jpg" alt="a black vertically
symmetrical shape, which contains 4 small white areas and 9 smaller
black blotches seperated from the main body of the shape.">
<legend>A black outline of the first of the ten cards
in the Rorschach inkblot test.</legend>
</figure>


> The following:
>
>   <p>What do you see in the following image?</p>
>   <p><img src=test.jpeg alt="A colour blindness test."></p>
>
> ...is semantically equivalent, for users without images, to the following:
>
>   <p>What do you see in the following image?</p>
>   <p>A colour blindness test.</p>
>
> Which is not at all equivalent.


WCAG does not mandate that the text alternative must be an
'equivalent', it accepts that this is not always possible, in which
case a description is the recommended text alternative.


> Could you give an example of such a page where one would have an image
> that cannot be described when the page is written but where the image
> nonetheless has enough associated data that the user would get confused?
>


examples:
http://www.flickr.com/photos/
http://www.flickr.com/photos/tags/australia/
http://www.flickr.com/explore/interesting/7days/



> Joshue has provided extremely useful usability studies that we have used
> to help guide the design of HTML5. However, with all due respect to
> Joshue, sometimes even his opinions contradict the evidence he provides.
> That is why it is more important to base our decisions on actual objective
> research. (I say this without meaning any ill will to Joshue at all, I am
> very thankful for all the research he has done for us so far.)


What josh provided was one set of videos, this in way way can be
considered a basis for any decisions, the study is in  no way
'scientific' or objective


> That is why it is more important to base our decisions on actual objective
> research.


All the decisions appear to be made by you, so the use of 'our' seems
incorrect here.

where is this 'objective research'??



> Asking me to speak to other experts is still an argument based on
> authority and not an argument based on research.



At the risk of repeating myself where is this research you have used ?


Talking about arguments based on research rather authority is
hypocritical as these issues are decided by you on the authority that
you have over the what goes into the HTML5 spec. You don't let lack of
research get in your way. So really it ends up that unless your
authority is circumscribed by the authority of the W3C, all the
decisions about what goes into the spec will continue to be made by
you, not by the HTML working group.

Under the present situation, the only hope for any input into the spec
without you calling the shots is at 'last call' when W3C member
organisations can formally object and stop the spec becoming a
candidate recommendation. I for one will be working with disability
organisations who are members of the W3C to this end.

As you are in control, the eventualities of the outcomes are down to you.

so be it.

stevef.


From rob at robburns.com  Thu Aug 21 10:48:56 2008
From: rob at robburns.com (Robert J Burns)
Date: Thu, 21 Aug 2008 20:48:56 +0300
Subject: [html4all] Unified approach to media elements
Message-ID: <2CF08A63-E093-450A-809D-3BC4B22BAECC@robburns.com>

Hi Gregory and all,

I was looking at your recent page to add caption, legend, help/hint  
elements to HTML5[1]. I had been considering the same problem of hint/ 
help with a bit of a different perspective, though also inspired by  
XForms hint element[2]. On that wiki page, I also propose applying the  
separation of concerns to the concept of a tooltip which gets  
conflated in its semantic and presentational forms. In this way, CSS  
would afford authors the ability to control what content gets floated  
above the document in the visual presentation (e.g., causing the title  
attribute contents to float above an element when the pointer hovers  
over that element). On the other hand this provides eliminates the  
incentive authors have to misuse elements and attributes so that the  
'title attribute or the 'hint' element retain their intended uses.

Take care,
Rob

[1]: <http://esw.w3.org/topic/PF/XTech/HTML5/MediaSpecificElements>
[2]: <http://esw.w3.org/topic/HTML/TooltipSemanticsAndPresentation>


From rob at robburns.com  Thu Aug 21 13:41:52 2008
From: rob at robburns.com (Robert J Burns)
Date: Thu, 21 Aug 2008 23:41:52 +0300
Subject: [html4all] role attribute keywords for embedded media
Message-ID: <4FDA1F29-D5C3-489B-ABE8-FB9F5EC12D68@robburns.com>

Hello 4all,

After recent discussions with Leif and Gregory regarding role keywords  
for embedded media, I've added some lists of keywords to the wiki page  
Gregory started. For reference, it includes the list of W3C XHTML role  
attribute recommendation, role keywords used by Mac OS X's  
accessibility APIs (if anyone has lists from other APIs ? like  
Windows, Solaris or KDE ? that would be of interest). Then I included  
a list of keywords that arose out of our discussions on the topic. I  
think the list is fairly comprehensive though I would welcome further  
additions and tweaks. It is also a very manageable list for authoring  
tools, conformance checkers and even hand-coding authors. As the  
discussion has continued on this proposal, I think one of the great  
advantages to this role approach is it would really help guide authors  
on inputting alt text that genuinely met the requirements for creating  
accessible content.

Take care,
Rob

[1]: <http://esw.w3.org/topic/PF/XTech/HTML5/RoleAttribute#head-35490581f69f2d7a9157e4ba18f3a20a18956cac 
 >

From lhs at malform.no  Thu Aug 21 20:25:43 2008
From: lhs at malform.no (Leif Halvard Silli)
Date: Fri, 22 Aug 2008 05:25:43 +0200
Subject: [html4all] role attribute keywords for embedded media
In-Reply-To: <4FDA1F29-D5C3-489B-ABE8-FB9F5EC12D68@robburns.com>
References: <4FDA1F29-D5C3-489B-ABE8-FB9F5EC12D68@robburns.com>
Message-ID: <48AE31B7.4060604@malform.no>

Robert J Burns 2008-08-21 22.41:

> After recent discussions with Leif and Gregory regarding role keywords  
> for embedded media, I've added some lists of keywords to the wiki page  
> Gregory started. [...] [1]


Excellent.

> I think one of the great advantages to this role approach is it
> would really help guide authors on inputting alt text that
> genuinely met the requirements for creating accessible content.


And in that regard, for what the Wiki page call 'layout or 
spacer', how about role="space" instead, to signify images which 
represent space, and therefore a space character as fallback?

Btw, is role=richtext smart? And where is role=text in the Wiki?

You link "richtext" to the fallback requirements, it could seem. 
But I think @role is linked to the very element. To explain why I 
think it is bad, consider XHTML 2, where e.g. an H2 element could 
contain an textimage, with the same text in the fallback.

	<h2 src=image>A little heading.</h2>

What role would that H2-image play then? Richtext? I guess no. But 
the moment I emphasized one word in the heading, then it should?

Richtext would also be easy to misunderstand, as many simply 
consider any format where bold, italics etc is /possible/ as rich 
text. I think role=text would be good enough.

But perhaps, instead, there should be a role to signify that 
something is embedded?

> [1]: <http://esw.w3.org/topic/PF/XTech/HTML5/RoleAttribute#head-35490581f69f2d7a9157e4ba18f3a20a18956cac>

-- 
leif halvard silli


From lhs at malform.no  Thu Aug 21 20:36:51 2008
From: lhs at malform.no (Leif Halvard Silli)
Date: Fri, 22 Aug 2008 05:36:51 +0200
Subject: [html4all] Object element support
In-Reply-To: <3B79E5D2-AD51-4C90-8185-6CE8C9E8BBFE@robburns.com>
References: <F2AC1F9A-0D5A-4DA5-B37B-28BECB27F1F3@robburns.com>	<48AAA1F5.80501@malform.no>	<20080819110032.GA19723@jdc.jasonjgw.net>	<48AAB247.7020902@malform.no>	<20080820010326.GA7419@jdc.jasonjgw.net>	<48ABFC72.4090703@malform.no>	<342A4D0B-1D95-45CC-9216-92651ABB49EA@robburns.com>	<48AC0F81.7060908@malform.no>	<AD0C728B-4A67-47DA-8E54-8F4F7243A4CD@robburns.com>	<48ACDDE3.3060306@malform.no>
	<3B79E5D2-AD51-4C90-8185-6CE8C9E8BBFE@robburns.com>
Message-ID: <48AE3453.2020506@malform.no>

Robert J Burns 2008-08-21 11.11:

> On Aug 21, 2008, at 6:15 AM, Leif Halvard Silli wrote:


>>>>     <object data=one-movie.mov >
>>>>    <!-- all this is fallback for 'one movie': -->
>>>>     <img src=src alt='Fallback for IMG, as part of
>>>>        fallback for one-movie.' >
>>>>     <object  data=another-movie.mov >
>>>>    Fallback for 'another movie', which again is
>>>>        fallback for one-movie.
>>>>        <!-- end of fallback for 'one movie' -->
>>>>     </p></object></object>


>> So you don't hink a validator should OK this?
> 
> No, I think the validator should throw an error for the IMG element.  
> However, I'm saying everything is covered in terms of UA conformance.  
> That is even though a document is in error following your example, the  
> UA could still produce intelligible output for the user (I'm only  
> saying in error for HTML5, though I think the prose of HTML4 also  
> imply this is an error). It could be make to work, but I think it adds  
> needless complications to permit it in document conformance.


So, if I want to offer some flash to those that enjoy flash, but a 
nice mark-up with some images as fallback for the other readers, 
then this would not be good enough, you say. Because then the 
screen readers would get some IMG elements.

I can't agree to this. I think the fallback must be judged 
independently from very OBJECT element.
-- 
leif halvard silli



From rob at robburns.com  Fri Aug 22 03:57:59 2008
From: rob at robburns.com (Robert J Burns)
Date: Fri, 22 Aug 2008 13:57:59 +0300
Subject: [html4all] role attribute keywords for embedded media
In-Reply-To: <48AE31B7.4060604@malform.no>
References: <4FDA1F29-D5C3-489B-ABE8-FB9F5EC12D68@robburns.com>
	<48AE31B7.4060604@malform.no>
Message-ID: <2305DC0B-E597-4294-A9CE-98609271F8FD@robburns.com>

Hi Leif,

On Aug 22, 2008, at 6:25 AM, Leif Halvard Silli wrote:

> Robert J Burns 2008-08-21 22.41:
>
>> After recent discussions with Leif and Gregory regarding role  
>> keywords
>> for embedded media, I've added some lists of keywords to the wiki  
>> page
>> Gregory started. [...] [1]
>
>
> Excellent.
>
>> I think one of the great advantages to this role approach is it
>> would really help guide authors on inputting alt text that
>> genuinely met the requirements for creating accessible content.
>
>
> And in that regard, for what the Wiki page call 'layout or
> spacer', how about role="space" instead, to signify images which
> represent space, and therefore a space character as fallback?
>
> Btw, is role=richtext smart? And where is role=text in the Wiki?
>
> You link "richtext" to the fallback requirements, it could seem.
> But I think @role is linked to the very element. To explain why I
> think it is bad, consider XHTML 2, where e.g. an H2 element could
> contain an textimage, with the same text in the fallback.
>
> 	<h2 src=image>A little heading.</h2>
>
> What role would that H2-image play then? Richtext? I guess no. But
> the moment I emphasized one word in the heading, then it should?
>
> Richtext would also be easy to misunderstand, as many simply
> consider any format where bold, italics etc is /possible/ as rich
> text. I think role=text would be good enough.

Yeah, I can see how that might cause confusion. I was not referring to  
rich text in the markup. I never use that phrase in that way because  
it is too closely linked to the non-semantics of rich text from things  
like the rich text format (RTF). Rather I was more referring to the  
styled text of the image so that even in your example from XHTML2, the  
phrase "A little heading" might be richly styled with a font that the  
author is not able to share with users and is unable to rely on its  
presence in the users environment. Even that I consider rich text.  
However, I'll change it just to text, because its shorter and its use  
should be detailed in the recommendation anyway.

Take care,
Rob

>
>
>> [1]: <http://esw.w3.org/topic/PF/XTech/HTML5/RoleAttribute#head-35490581f69f2d7a9157e4ba18f3a20a18956cac 
>> >
>


From rob at robburns.com  Fri Aug 22 04:05:56 2008
From: rob at robburns.com (Robert J Burns)
Date: Fri, 22 Aug 2008 14:05:56 +0300
Subject: [html4all] Object element support
In-Reply-To: <48AE3453.2020506@malform.no>
References: <F2AC1F9A-0D5A-4DA5-B37B-28BECB27F1F3@robburns.com>	<48AAA1F5.80501@malform.no>	<20080819110032.GA19723@jdc.jasonjgw.net>	<48AAB247.7020902@malform.no>	<20080820010326.GA7419@jdc.jasonjgw.net>	<48ABFC72.4090703@malform.no>	<342A4D0B-1D95-45CC-9216-92651ABB49EA@robburns.com>	<48AC0F81.7060908@malform.no>	<AD0C728B-4A67-47DA-8E54-8F4F7243A4CD@robburns.com>	<48ACDDE3.3060306@malform.no>
	<3B79E5D2-AD51-4C90-8185-6CE8C9E8BBFE@robburns.com>
	<48AE3453.2020506@malform.no>
Message-ID: <2389286B-5007-409F-A991-252692A19AA0@robburns.com>

Hi Leif,

On Aug 22, 2008, at 6:36 AM, Leif Halvard Silli wrote:

> Robert J Burns 2008-08-21 11.11:
>
>> On Aug 21, 2008, at 6:15 AM, Leif Halvard Silli wrote:
>
>
>>>>>    <object data=one-movie.mov >
>>>>>   <!-- all this is fallback for 'one movie': -->
>>>>>    <img src=src alt='Fallback for IMG, as part of
>>>>>       fallback for one-movie.' >
>>>>>    <object  data=another-movie.mov >
>>>>>   Fallback for 'another movie', which again is
>>>>>       fallback for one-movie.
>>>>>       <!-- end of fallback for 'one movie' -->
>>>>>    </p></object></object>
>
>
>>> So you don't hink a validator should OK this?
>>
>> No, I think the validator should throw an error for the IMG element.
>> However, I'm saying everything is covered in terms of UA conformance.
>> That is even though a document is in error following your example,  
>> the
>> UA could still produce intelligible output for the user (I'm only
>> saying in error for HTML5, though I think the prose of HTML4 also
>> imply this is an error). It could be make to work, but I think it  
>> adds
>> needless complications to permit it in document conformance.
>
>
> So, if I want to offer some flash to those that enjoy flash, but a
> nice mark-up with some images as fallback for the other readers,
> then this would not be good enough, you say. Because then the
> screen readers would get some IMG elements.
>
> I can't agree to this. I think the fallback must be judged
> independently from very OBJECT element.

That is a use case I had not considered (multi media like flash  
falling back to multi media HTML). I agree it should be permitted.  
However, then I'm left wondering what you meant by your original  
OBJECT element objections. It seems your example should be both  
document conforming and is also handled properly even in HTML4.01.

If we make longdesc available on OBJECT (or even make it a global  
attribute), then OBJECT has everything needed to replace IMG (at least  
in present and future browsers with IE8). The contents of the OBJECT  
element contain the alt text for the embedded media and other  
description can be referenced by the longdesc attribute (or contained  
in the embedded media internally as I've suggested elsewhere)[1].i

Take care,
Rob

[1]: <http://esw.w3.org/topic/HTML/UANormAndDOMForMediaPropeties>


From lhs at malform.no  Fri Aug 22 07:44:06 2008
From: lhs at malform.no (Leif Halvard Silli)
Date: Fri, 22 Aug 2008 16:44:06 +0200
Subject: [html4all] role attribute keywords for embedded media
In-Reply-To: <2305DC0B-E597-4294-A9CE-98609271F8FD@robburns.com>
References: <4FDA1F29-D5C3-489B-ABE8-FB9F5EC12D68@robburns.com>	<48AE31B7.4060604@malform.no>
	<2305DC0B-E597-4294-A9CE-98609271F8FD@robburns.com>
Message-ID: <48AED0B6.7070000@malform.no>

Robert J Burns 2008-08-22 12.57:

>> And in that regard, for what the Wiki page call 'layout or
>> spacer', how about role="space" instead, to signify images which
>> represent space, and therefore a space character as fallback?

What did you think about this? You see, I think that many authors 
would not understand what kind  of @alt a role="spacer" or 
role="layout" woud require. Many would think that they should have 
alt="". But my view is that they, for safety, should have alt=" " 
and not alt="".

    [...]

>> Richtext would also be easy to misunderstand, as many simply
>> consider any format where bold, italics etc is /possible/ as rich
>> text. I think role=text would be good enough.


> However, I'll change it just to text, because its shorter and its use  
> should be detailed in the recommendation anyway.


Agree.

>>> [1]: <http://esw.w3.org/topic/PF/XTech/HTML5/RoleAttribute#head-35490581f69f2d7a9157e4ba18f3a20a18956cac 

Leif Halvard Silli


From rob at robburns.com  Fri Aug 22 07:53:34 2008
From: rob at robburns.com (Robert J Burns)
Date: Fri, 22 Aug 2008 17:53:34 +0300
Subject: [html4all] role attribute keywords for embedded media
In-Reply-To: <48AED0B6.7070000@malform.no>
References: <4FDA1F29-D5C3-489B-ABE8-FB9F5EC12D68@robburns.com>	<48AE31B7.4060604@malform.no>
	<2305DC0B-E597-4294-A9CE-98609271F8FD@robburns.com>
	<48AED0B6.7070000@malform.no>
Message-ID: <B616E807-E3E7-47A3-9B2A-9E9750B872C9@robburns.com>

Hi Leif,

Re: role for embedded media [1]

On Aug 22, 2008, at 5:44 PM, Leif Halvard Silli wrote:

> Robert J Burns 2008-08-22 12.57:
>
>>> And in that regard, for what the Wiki page call 'layout or
>>> spacer', how about role="space" instead, to signify images which
>>> represent space, and therefore a space character as fallback?
>
> What did you think about this? You see, I think that many authors
> would not understand what kind  of @alt a role="spacer" or
> role="layout" woud require. Many would think that they should have
> alt="". But my view is that they, for safety, should have alt=" "
> and not alt="".

I'm not sure I recognize the use case for it. I guess you're saying  
some use spacers just as they would a U+0020 space? Or perhaps the way  
XMl/HTML attribute values replace sequences of other whitespace values  
with a single U+0020? I guess that could make sense. To me this would  
just be needed for legacy UA processing. An HTML5 UA could simply read  
the 'space' keyword and then know to replace the image with a U+0020  
space. Though that does suggest we would need a separate 'space'  
keyword and leave 'decorative' for frills and flourishes and the like.  
What about layout v. space or layout v. decorative? Do we still need  
three separate keywords (layout, space, decor)?

Take care,
Rob

[1]: <http://esw.w3.org/topic/PF/XTech/HTML5/RoleAttribute#head-35490581f69f2d7a9157e4ba18f3a20a18956cac 
  


From lhs at malform.no  Fri Aug 22 10:48:06 2008
From: lhs at malform.no (Leif Halvard Silli)
Date: Fri, 22 Aug 2008 19:48:06 +0200
Subject: [html4all] role attribute keywords for embedded media
In-Reply-To: <B616E807-E3E7-47A3-9B2A-9E9750B872C9@robburns.com>
References: <4FDA1F29-D5C3-489B-ABE8-FB9F5EC12D68@robburns.com>	<48AE31B7.4060604@malform.no>	<2305DC0B-E597-4294-A9CE-98609271F8FD@robburns.com>	<48AED0B6.7070000@malform.no>
	<B616E807-E3E7-47A3-9B2A-9E9750B872C9@robburns.com>
Message-ID: <48AEFBD6.1020108@malform.no>

Robert J Burns 2008-08-22 16.53:

> Re: role for embedded media [1]
> 
> On Aug 22, 2008, at 5:44 PM, Leif Halvard Silli wrote:
>> Robert J Burns 2008-08-22 12.57:
>>
>>>> And in that regard, for what the Wiki page call 'layout or
>>>> spacer', how about role="space" instead, to signify images which
>>>> represent space, and therefore a space character as fallback?
>>
>> What did you think about this? You see, I think that many authors
>> would not understand what kind  of @alt a role="spacer" or
>> role="layout" woud require. Many would think that they should have
>> alt="". But my view is that they, for safety, should have alt=" "
>> and not alt="".
> 
> I'm not sure I recognize the use case for it. I guess you're saying  
> some use spacers just as they would a U+0020 space? Or perhaps the way  
> XMl/HTML attribute values replace sequences of other whitespace values  
> with a single U+0020? I guess that could make sense. To me this would  


Yes, I had in mind that several space(r)s would just become one. 
Often alt="" would be fine, but alt=" " would be safer, so words 
would not be concatenated if embedded elements with decorative or 
layout purposes was all that separated them.

> just be needed for legacy UA processing. An HTML5 UA could simply read  
> the 'space' keyword and then know to replace the image with a U+0020  
> space. Though that does suggest we would need a separate 'space'  
> keyword and leave 'decorative' for frills and flourishes and the like.  
> What about layout v. space or layout v. decorative? Do we still need  
> three separate keywords (layout, space, decor)?


Is 'decor' a new proposal, instead of 'decorative'? I agree that 
'decorative' is not so good, as it is an adjective. The other 
roles appears to be substantives. I would prefer 'decor' or 
'decoration'.

My thought would be to have only have two: "space" and "decor" (or 
"layout" and "decor").

One could have had only one role, as well, role=decor, and say 
that authors had to choose between alt="" and alt=" ". But then 
there would be no way programmatically validate whether the @alt 
had been used correctly or not.

 
> [1]: <http://esw.w3.org/topic/PF/XTech/HTML5/RoleAttribute#head-35490581f69f2d7a9157e4ba18f3a20a18956cac 
-- 

leif halvard silli


From lhs at malform.no  Fri Aug 22 11:16:54 2008
From: lhs at malform.no (Leif Halvard Silli)
Date: Fri, 22 Aug 2008 20:16:54 +0200
Subject: [html4all] Object element support
In-Reply-To: <2389286B-5007-409F-A991-252692A19AA0@robburns.com>
References: <F2AC1F9A-0D5A-4DA5-B37B-28BECB27F1F3@robburns.com>	<48AAA1F5.80501@malform.no>	<20080819110032.GA19723@jdc.jasonjgw.net>	<48AAB247.7020902@malform.no>	<20080820010326.GA7419@jdc.jasonjgw.net>	<48ABFC72.4090703@malform.no>	<342A4D0B-1D95-45CC-9216-92651ABB49EA@robburns.com>	<48AC0F81.7060908@malform.no>	<AD0C728B-4A67-47DA-8E54-8F4F7243A4CD@robburns.com>	<48ACDDE3.3060306@malform.no>	<3B79E5D2-AD51-4C90-8185-6CE8C9E8BBFE@robburns.com>	<48AE3453.2020506@malform.no>
	<2389286B-5007-409F-A991-252692A19AA0@robburns.com>
Message-ID: <48AF0296.6000202@malform.no>

Robert J Burns 2008-08-22 13.05:

> On Aug 22, 2008, at 6:36 AM, Leif Halvard Silli wrote:


 >>>>>>    <object data=one-movie.mov >

>>>>>>   <!-- all this is fallback for 'one movie': -->
>>>>>>    <img src=src alt='Fallback for IMG, as part of
>>>>>>       fallback for one-movie.' >
>>>>>>    <object  data=another-movie.mov >
>>>>>>   Fallback for 'another movie', which again is
>>>>>>       fallback for one-movie.
>>>>>>       <!-- end of fallback for 'one movie' -->
>>>>>>    </p></object></object>
>>
>>
>>>> So you don't hink a validator should OK this?
>>>
>>> No, I think the validator should throw an error for the IMG element.

    [...]

>> So, if I want to offer some flash to those that enjoy flash, but a
>> nice mark-up with some images as fallback for the other readers,
>> then this would not be good enough, you say. Because then the
>> screen readers would get some IMG elements.

    [...]

> That is a use case I had not considered (multi media like flash  
> falling back to multi media HTML). I agree it should be permitted.  
> However, then I'm left wondering what you meant by your original  
> OBJECT element objections. It seems your example should be both  
> document conforming and is also handled properly even in HTML4.01.


Well, in a way it is linked to this use case. The question is: Is 
there a need for the distinction short vs. long fallback? As 
sighted, grasping an image is fast. Describing it in words might 
take longer time to read etc.

For the IMG, the @longdesc is place you can jump /to/. However, 
perhaps what is really needed is to be able to jump /over/? I.e. 
if - as Jason said - the fallback is always long. Consider this:

<p><object data="src" title="Complex Diagram">
<table summary="The ins and outs of this and that.">
<caption>Complex Diagram
<a href="#next-paragraph">Skip to next paragraph.</a>
</caption><tr><th [... etc ...]</table></object></p>
<p id="next">....</p>

So, perhaps, what I said about being able to jump to a long 
description, could be replaced with an advice to authors that they 
provide a way to "Skip over" the (long) fallback? Just as it is 
recommended to be able to skip over navigation and to main 
content? Or, perhaps simply adding a table summary would be 
enough? ;-)

(Seems like my view on this has developed.)

 
> If we make longdesc available on OBJECT (or even make it a global  
> attribute), then OBJECT has everything needed to replace IMG (at least  
> in present and future browsers with IE8). The contents of the OBJECT  
> element contain the alt text for the embedded media and other  
> description can be referenced by the longdesc attribute (or contained  
> in the embedded media internally as I've suggested elsewhere)[1].i


> [1]: <http://esw.w3.org/topic/HTML/UANormAndDOMForMediaPropeties>
-- 

Leif Halvard Silli


From rob at robburns.com  Sat Aug 23 02:21:54 2008
From: rob at robburns.com (Robert J Burns)
Date: Sat, 23 Aug 2008 12:21:54 +0300
Subject: [html4all] Object element support
In-Reply-To: <48AF0296.6000202@malform.no>
References: <F2AC1F9A-0D5A-4DA5-B37B-28BECB27F1F3@robburns.com>	<48AAA1F5.80501@malform.no>	<20080819110032.GA19723@jdc.jasonjgw.net>	<48AAB247.7020902@malform.no>	<20080820010326.GA7419@jdc.jasonjgw.net>	<48ABFC72.4090703@malform.no>	<342A4D0B-1D95-45CC-9216-92651ABB49EA@robburns.com>	<48AC0F81.7060908@malform.no>	<AD0C728B-4A67-47DA-8E54-8F4F7243A4CD@robburns.com>	<48ACDDE3.3060306@malform.no>	<3B79E5D2-AD51-4C90-8185-6CE8C9E8BBFE@robburns.com>	<48AE3453.2020506@malform.no>
	<2389286B-5007-409F-A991-252692A19AA0@robburns.com>
	<48AF0296.6000202@malform.no>
Message-ID: <5D27059D-4841-4D49-AFD3-CAA6166DE8C9@robburns.com>

HI Leif,

On Aug 22, 2008, at 9:16 PM, Leif Halvard Silli wrote:

> Robert J Burns 2008-08-22 13.05:
>
>> On Aug 22, 2008, at 6:36 AM, Leif Halvard Silli wrote:
>
>
>>>>>>>   <object data=one-movie.mov >
>
>>>>>>>  <!-- all this is fallback for 'one movie': -->
>>>>>>>   <img src=src alt='Fallback for IMG, as part of
>>>>>>>      fallback for one-movie.' >
>>>>>>>   <object  data=another-movie.mov >
>>>>>>>  Fallback for 'another movie', which again is
>>>>>>>      fallback for one-movie.
>>>>>>>      <!-- end of fallback for 'one movie' -->
>>>>>>>   </p></object></object>
>>>
>>>
>>>>> So you don't hink a validator should OK this?
>>>>
>>>> No, I think the validator should throw an error for the IMG  
>>>> element.
>
>    [...]
>
>>> So, if I want to offer some flash to those that enjoy flash, but a
>>> nice mark-up with some images as fallback for the other readers,
>>> then this would not be good enough, you say. Because then the
>>> screen readers would get some IMG elements.
>
>    [...]
>
>> That is a use case I had not considered (multi media like flash
>> falling back to multi media HTML). I agree it should be permitted.
>> However, then I'm left wondering what you meant by your original
>> OBJECT element objections. It seems your example should be both
>> document conforming and is also handled properly even in HTML4.01.
>
>
> Well, in a way it is linked to this use case. The question is: Is
> there a need for the distinction short vs. long fallback? As
> sighted, grasping an image is fast. Describing it in words might
> take longer time to read etc.

Again, I want to discourage this distinction between short and long (I  
know I sound like a broken record if anyone remembers those). When  
we're talking about OBJECT and other elements that can contain markup  
as alt text, the distinction of short and long is not so important  
(with the alt attribute it is important since there's really no way to  
even separate thoughts into separate paragraphs so it needs to be  
fairly short). There is however an important difference served by the  
alt attribute (or the contents of an element) and longdesc (or another  
such attribute) even if it is not the length of the equivalent text.  
That important difference is that one mechanism is for alt text ? text  
that is to be replaced and serve as a seamless replacement for the  
embedded media ? and the other mechanism is for descriptive text  
equivalents ? text that is a subject or visual description of the  
embedded media not necessarily suitable to replacing the media in the  
present document.

Once both the alt text and the descriptive text equivalent (like that  
referenced by the longdesc attribute) can contain markup, then there  
is no need to arbitrarily limit the length of the content (whatever  
length the author requires is appropriate). UAs can provide users with  
navigation capabilities to skip paragraphs or move to the next heading  
element, etc. However, the need for separate mechanisms for alt text  
and descriptive text still remains.

> For the IMG, the @longdesc is place you can jump /to/. However,
> perhaps what is really needed is to be able to jump /over/? I.e.
> if - as Jason said - the fallback is always long. Consider this:
>
> <p><object data="src" title="Complex Diagram">
> <table summary="The ins and outs of this and that.">
> <caption>Complex Diagram
> <a href="#next-paragraph">Skip to next paragraph.</a>
> </caption><tr><th [... etc ...]</table></object></p>
> <p id="next">....</p>
>
> So, perhaps, what I said about being able to jump to a long
> description, could be replaced with an advice to authors that they
> provide a way to "Skip over" the (long) fallback? Just as it is
> recommended to be able to skip over navigation and to main
> content? Or, perhaps simply adding a table summary would be
> enough? ;-)
>
> (Seems like my view on this has developed.)

To me adding the longdesc attribute (or a new textdesc attribute) to  
all embedded media elements serves the needs of providing a  
descriptive text equivalent (as opposed to an alt text equivalent).  
The markup itself then provides a means for users to skip over, skim  
and otherwise navigate the content.

Take care,
Rob

From jason at jasonjgw.net  Sat Aug 23 03:14:46 2008
From: jason at jasonjgw.net (Jason White)
Date: Sat, 23 Aug 2008 20:14:46 +1000
Subject: [html4all] Object element support
In-Reply-To: <5D27059D-4841-4D49-AFD3-CAA6166DE8C9@robburns.com>
References: <48ABFC72.4090703@malform.no>
	<342A4D0B-1D95-45CC-9216-92651ABB49EA@robburns.com>
	<48AC0F81.7060908@malform.no>
	<AD0C728B-4A67-47DA-8E54-8F4F7243A4CD@robburns.com>
	<48ACDDE3.3060306@malform.no>
	<3B79E5D2-AD51-4C90-8185-6CE8C9E8BBFE@robburns.com>
	<48AE3453.2020506@malform.no>
	<2389286B-5007-409F-A991-252692A19AA0@robburns.com>
	<48AF0296.6000202@malform.no>
	<5D27059D-4841-4D49-AFD3-CAA6166DE8C9@robburns.com>
Message-ID: <20080823101446.GA16357@jdc.jasonjgw.net>

On Sat, Aug 23, 2008 at 12:21:54PM +0300, Robert J Burns wrote:
> That important difference is that one mechanism is for alt text ? text  
> that is to be replaced and serve as a seamless replacement for the  
> embedded media ? and the other mechanism is for descriptive text  
> equivalents ? text that is a subject or visual description of the  
> embedded media not necessarily suitable to replacing the media in the  
> present document.

An alternative approach, which I favour, is to collapse this distinction by
holding that there is only one alternative needed, namely, whatever can serve
as a seamless substitute for the embedded media. Either this substitute is
adequate to fulfill the purpose or convey the information served by the media
in the context of the content, or it is not.

In the first case, any additional description would be superfluous. In the
second case, the alternative needs to be more explanatory or descriptive, as
appropriate, so as more adequately to serve as a substitute for the embedded
media.

This is the premise on the basis of which WCAG 1.0 and 2.0 requirements are
defined.

I also disagree with the claim, introduced earlier in this thread, that there
are two categories of users, one of which would supposedly be served by the
seamless substitute, and the other of which would need, or benefit from, the
additional description. To the contrary, there is one category of users,
namely those whose delivery context precludes viewing or listening to the
embedded media, whether temporarily, as may be due to environmental or
technological circumstances, or permanently, in the case of the user's having
a disability. However, the circumstances giving rise to the need don't alter
the nature of that need, namely for a seamless and adequate substitute.

While I appreciate the thinking that underlies Rob's distinction, I don't find
it compelling and I don't think it should serve to influence markup language
design. Moreover, WCAG does not draw such a distinction, and I would argue
that it should not.

With apologies for entering the discussion purely to make a negative point, I
nonetheless hope this contrary view helps more than it hinders.

To explain a little further, I think it is a matter of style on the part of
the author whether to provide a seamless substitute "in place", or whether to
provide part of that substitute - a label or a brief explanation - in place,
and then to include a link to additional details that give the missing
explanatory or descriptive material.

I earlier argued that if the substitute is adequate, then additional
description is superfluous. It may be useful to provide such a description,
but it is not an accessibility requirement to do so - if it were, then the
supposed substitute would be inadequate as a genuine alternative to the media.



From rob at robburns.com  Sat Aug 23 05:13:08 2008
From: rob at robburns.com (Robert J Burns)
Date: Sat, 23 Aug 2008 15:13:08 +0300
Subject: [html4all] Object element support
In-Reply-To: <20080823101446.GA16357@jdc.jasonjgw.net>
References: <48ABFC72.4090703@malform.no>
	<342A4D0B-1D95-45CC-9216-92651ABB49EA@robburns.com>
	<48AC0F81.7060908@malform.no>
	<AD0C728B-4A67-47DA-8E54-8F4F7243A4CD@robburns.com>
	<48ACDDE3.3060306@malform.no>
	<3B79E5D2-AD51-4C90-8185-6CE8C9E8BBFE@robburns.com>
	<48AE3453.2020506@malform.no>
	<2389286B-5007-409F-A991-252692A19AA0@robburns.com>
	<48AF0296.6000202@malform.no>
	<5D27059D-4841-4D49-AFD3-CAA6166DE8C9@robburns.com>
	<20080823101446.GA16357@jdc.jasonjgw.net>
Message-ID: <3D3BBF9E-91F4-40C3-A636-D68451FCF4CC@robburns.com>

HI Jason,

I'm not sure you're saying anything that disagrees with what I'm  
proposing. Let me explain further.

On Aug 23, 2008, at 1:14 PM, Jason White wrote:

> On Sat, Aug 23, 2008 at 12:21:54PM +0300, Robert J Burns wrote:
>> That important difference is that one mechanism is for alt text ?  
>> text
>> that is to be replaced and serve as a seamless replacement for the
>> embedded media ? and the other mechanism is for descriptive text
>> equivalents ? text that is a subject or visual description of the
>> embedded media not necessarily suitable to replacing the media in the
>> present document.
>
> An alternative approach, which I favour, is to collapse this  
> distinction by
> holding that there is only one alternative needed, namely, whatever  
> can serve
> as a seamless substitute for the embedded media. Either this  
> substitute is
> adequate to fulfill the purpose or convey the information served by  
> the media
> in the context of the content, or it is not.

I agree 100%. This is what I would refer to (following WCAG) as alt  
text. In other words I agree that "there is only one alternative  
needed", however, there is a need for authors to provide other text  
equivalents (not alt text) for users who want more.

> In the first case, any additional description would be superfluous.  
> In the
> second case, the alternative needs to be more explanatory or  
> descriptive, as
> appropriate, so as more adequately to serve as a substitute for the  
> embedded
> media.
>
> This is the premise on the basis of which WCAG 1.0 and 2.0  
> requirements are
> defined.
>
> I also disagree with the claim, introduced earlier in this thread,  
> that there
> are two categories of users, one of which would supposedly be served  
> by the
> seamless substitute, and the other of which would need, or benefit  
> from, the
> additional description.

I did not introduce a claim that there are two categories of users.  
Rather what I'm saying is that there are two categories of text  
equivalents: one being a descriptive equivalent (as opposed to alt  
text equivalent) that any given user might or might not want to access  
at their discretion. I further feel that by collapsing these two text  
equivalents into one we encourage authors to pollute the alt text with  
descriptive text equivalents that are a distraction for the users who  
don't want that. It may be that this also implies reveals two  
categories of users ? those interested in descriptive equivalents and  
those who are not ? but that's not the focus of my proposal here.

> To the contrary, there is one category of users,
> namely those whose delivery context precludes viewing or listening  
> to the
> embedded media, whether temporarily, as may be due to environmental or
> technological circumstances, or permanently, in the case of the  
> user's having
> a disability. However, the circumstances giving rise to the need  
> don't alter
> the nature of that need, namely for a seamless and adequate  
> substitute.

Again, I agree 100%. This refers to what I, according to my reading of  
WCAG, call alt text.

> While I appreciate the thinking that underlies Rob's distinction, I  
> don't find
> it compelling and I don't think it should serve to influence markup  
> language
> design. Moreover, WCAG does not draw such a distinction, and I would  
> argue
> that it should not.

I read WCAG as indeed drawing such a distinction (see 'Techniques for  
checkpoint 1.1'[1] and 'Long descriptions for images'[2] for example),  
though it is not stated as clearly as I think it should be to help  
authors compose adequate alt text.

> With apologies for entering the discussion purely to make a negative  
> point, I
> nonetheless hope this contrary view helps more than it hinders.
>
> To explain a little further, I think it is a matter of style on the  
> part of
> the author whether to provide a seamless substitute "in place", or  
> whether to
> provide part of that substitute - a label or a brief explanation -  
> in place,
> and then to include a link to additional details that give the missing
> explanatory or descriptive material.
>
> I earlier argued that if the substitute is adequate, then additional
> description is superfluous. It may be useful to provide such a  
> description,
> but it is not an accessibility requirement to do so - if it were,  
> then the
> supposed substitute would be inadequate as a genuine alternative to  
> the media.

I know this is your view on descriptive equivalent text. However, I  
think other users hold different opinions regarding descriptive  
equivalent text. Some users want access to more text equivalent than  
should be expected within strictly alt replacement text. So while  
there may be authoring styles (as opposed to the use of the term  
'style' with regard to presentation) that handle this issue  
differently, it would be far better for users and author for HTML to  
provide specific mechanisms and specific advice on how to separate  
these text equivalents.

Again, consider the earlier example I provided[3] where the alt text  
and the descriptive text are clearly separate. In that example, I  
failed to notice that the referenced image (as the sole contents of an  
anchor element) should have likely had its alt set to "fullsize image  
of coal power plant" (though similar guidance appears later in the  
figure caption). In any event the role of the photograph in this  
example is not quite decorative, but it also does not serve the same  
integral purpose to the meaning of the document as of a bar graph or  
other images where the alt text is crucial. It is perhaps best  
described as illustrative or even tangential to the thrust of the  
article. The alt text could be:

"a coal power plant silhouetted along a waterway with the dusk sunset  
(or dawn sunrise) in the background. The plant is spewing smoke and  
steam into the air and we can see the conveyor that delivers coal to  
the plant."

but I'm not sure that such a text equivalent is really appropriate in  
this particular case. It is a good descriptive text equivalent, but  
"fullsize image of coal power plant" might be more appropriate as the  
alt text for this anchor element image.

My sense is that if authors consistently used these two mechanisms  
they way I'm suggesting, a user like you (Jason) would typically avoid  
the descriptive text equivalent and rely only on the alt text  
equivalent, while other users I've discussed this with would prefer to  
query the UA for the descriptive text equivalent when further curious  
about the media. My feeling is that these distinctions exist whether  
we acknowledge them or not. And I am very concerned the attempt to  
gloss over these distinctions contributes to the continued difficulty  
authors have in composing sufficient alt text.

Take care,
Rob

[1]: <http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-text-equivalent>
[2]: <http://www.w3.org/TR/WCAG10-HTML-TECHS/#long-descriptions>
[3]: my earlier email regarding the text equivalent distinctions <http://wilbur.bytowninternet.com/mailman/private/list_html4all.org/2008-August/000939.html 
 > regarding a random blog I ran across <http://interestingenergyfacts.blogspot.com/ 
 >

From lhs at malform.no  Sat Aug 23 05:44:58 2008
From: lhs at malform.no (Leif Halvard Silli)
Date: Sat, 23 Aug 2008 14:44:58 +0200
Subject: [html4all] Object element support
In-Reply-To: <20080823101446.GA16357@jdc.jasonjgw.net>
References: <48ABFC72.4090703@malform.no>	<342A4D0B-1D95-45CC-9216-92651ABB49EA@robburns.com>	<48AC0F81.7060908@malform.no>	<AD0C728B-4A67-47DA-8E54-8F4F7243A4CD@robburns.com>	<48ACDDE3.3060306@malform.no>	<3B79E5D2-AD51-4C90-8185-6CE8C9E8BBFE@robburns.com>	<48AE3453.2020506@malform.no>	<2389286B-5007-409F-A991-252692A19AA0@robburns.com>	<48AF0296.6000202@malform.no>	<5D27059D-4841-4D49-AFD3-CAA6166DE8C9@robburns.com>
	<20080823101446.GA16357@jdc.jasonjgw.net>
Message-ID: <48B0064A.7040504@malform.no>

Jason White 2008-08-23 12.14:

> On Sat, Aug 23, 2008 at 12:21:54PM +0300, Robert J Burns wrote:


> I also disagree with the claim, introduced earlier in this thread, that there
> are two categories of users, one of which would supposedly be served by the
> seamless substitute, and the other of which would need, or benefit from, the
> additional description. To the contrary, there is one category of users,
> namely those whose delivery context precludes viewing or listening to the
> embedded media, whether temporarily, as may be due to environmental or
> technological circumstances, or permanently, in the case of the user's having
> a disability. However, the circumstances giving rise to the need don't alter
> the nature of that need, namely for a seamless and adequate substitute.

I think you may have characterized the views I put forward, here. 
  I must admit that, having lead Rob astray, <smile> I begin to 
view things as you do. ;-)

> While I appreciate the thinking that underlies Rob's distinction, I don't find
> it compelling and I don't think it should serve to influence markup language
> design. Moreover, WCAG does not draw such a distinction, and I would argue
> that it should not.
> 
> With apologies for entering the discussion purely to make a negative point, I
> nonetheless hope this contrary view helps more than it hinders.


There is nothing to aplogy for! On the contrary!

 
> To explain a little further, I think it is a matter of style on the part of
> the author whether to provide a seamless substitute "in place", or whether to
> provide part of that substitute - a label or a brief explanation - in place,
> and then to include a link to additional details that give the missing
> explanatory or descriptive material.
> 
> I earlier argued that if the substitute is adequate, then additional
> description is superfluous. It may be useful to provide such a description,
> but it is not an accessibility requirement to do so - if it were, then the
> supposed substitute would be inadequate as a genuine alternative to the media.

Good point. It is also be much simpler if we operate with just one 
level of textual fallback.
-- 
leif halvard silli



From rob at robburns.com  Sat Aug 23 15:15:15 2008
From: rob at robburns.com (Robert J Burns)
Date: Sun, 24 Aug 2008 01:15:15 +0300
Subject: [html4all] distinguishing text equivalents: alt text and
	descriptive text
In-Reply-To: <3D3BBF9E-91F4-40C3-A636-D68451FCF4CC@robburns.com>
References: <48ABFC72.4090703@malform.no>
	<342A4D0B-1D95-45CC-9216-92651ABB49EA@robburns.com>
	<48AC0F81.7060908@malform.no>
	<AD0C728B-4A67-47DA-8E54-8F4F7243A4CD@robburns.com>
	<48ACDDE3.3060306@malform.no>
	<3B79E5D2-AD51-4C90-8185-6CE8C9E8BBFE@robburns.com>
	<48AE3453.2020506@malform.no>
	<2389286B-5007-409F-A991-252692A19AA0@robburns.com>
	<48AF0296.6000202@malform.no>
	<5D27059D-4841-4D49-AFD3-CAA6166DE8C9@robburns.com>
	<20080823101446.GA16357@jdc.jasonjgw.net>
	<3D3BBF9E-91F4-40C3-A636-D68451FCF4CC@robburns.com>
Message-ID: <C16F8788-AB2D-4AFB-8D22-76F261C119F2@robburns.com>

Hello 4all,

Incidentally, on my proposal that we separate text equivalents into  
two categories ? alt text and descriptive text ? my preferred way to  
handle the descriptive text is through the immanent metadata  
properties of the media files[1]. If we had HTML UAs that could  
retrieve and present such metadata properties to users upon user  
request, I think that would be idea. I'm not sure the existing  
metadata standards are sufficient for this purpose, but we might  
piggyback something on XMP metadata now part of Adobe[2]. My thinking  
is that since XMP places XML structured metadata into the media file  
format, we could add specific W3C named properties that used XHTML5 /  
XHTML2 syntax within the property.

The short-term approach I'm advocating is to extend the longdesc  
attribute (or another similar attribute like textdesc) to the other  
embedded media elements (e.g., OBJECT). It may be that this short term  
approach is unnecessary since it isn't a feature of the language  
authors have come to expect yet. However, so far Ian has rejected both  
longdesc and UAs providing user access to media metadata[3].

Take care,
Rob

[1]: <http://esw.w3.org/topic/HTML/UANormAndDOMForMediaPropeties>
[2]: <http://en.wikipedia.org/wiki/Extensible_Metadata_Platform>
[3]: <http://www.w3.org/Bugs/Public/show_bug.cgi?id=5755>

From lhs at malform.no  Sat Aug 23 18:05:09 2008
From: lhs at malform.no (Leif Halvard Silli)
Date: Sun, 24 Aug 2008 03:05:09 +0200
Subject: [html4all] @abbr, short TH fallback for screen readers
Message-ID: <48B0B3C5.7000501@malform.no>

HTML 4 has the @abbr for table cells, aimed at screen readers, 
primerely. It is sofar not included n HTML 5. Should it be kept?

With a reference to the discussion I, Rob and Jason lead about "short 
@alt" versus "@longdesc" etc,  I would describe @abbr as a "short text 
equivalent of of an table header cell".

Are there User Agents who support this attribute? Do you think it is 
worth keeping? It makes sense to me: For traversal of a table, it should 
be practical to be able to list abbreviated TH content rather than the 
full content.

Here are the HTML 4 code examples with @abbr:

    * <TH id="t3" abbr="Type">Type of Coffee</TH>
    * <TH scope="col" abbr="Name">Course Name</TH>
    * <TH scope="col" abbr="Tutor">Course Tutor</TH>

I was reminded about this issue when I saw Gez's table demonstration 
(for the cause of allowing @headers to point to data cells). [1] There 
Gez has used the ABBR element in 3 of the headings.  But as you can see 
from the code examples above, the @abbr and <ABBR> works differently.

The @abbr reminds me a lot about @label for <OPTION>. (Opera  only added 
support for <option @lable> in Opera 9.5.). Here is what HTML 4 says 
about <option @lable>:

    * label = text [CS]
      This attribute allows authors to specify a shorter label for an
      option than the content of the OPTION element. When specified,
      user agents should use the value of this attribute rather than the
      content of the OPTION element as the option label.


This is what the prose of HTML 4 says about @abbr (note that HTML 4 also 
see a use case for visual agents):

DTD

    * abbr        %Text;         #IMPLIED  -- abbreviation for header
      cell --

Prose:

    * abbr = text [CS]
      This attribute should be used to provide an abbreviated form of
      the cell's content, and may be rendered by user agents when
      appropriate in place of the cell's content. Abbreviated names
      should be short since user agents may render them repeatedly. For
      instance, speech synthesizers may render the abbreviated headers
      relating to a particular cell before rendering that cell's content.
    * The TH element defines a cell that contains header information.
      User agents have two pieces of header information available: the
      contents of the TH element and the value of the abbr attribute.
      User agents must render either the contents of the cell or the
      value of the abbr attribute. For visual media, the latter may be
      appropriate when there is insufficient space to render the full
      contents of the cell. For non-visual media abbr may be used as an
      abbreviation for table headers when these are rendered along with
      the contents of the cells to which they apply.
    * [non-visual UAs:] The abbr attribute specifies an abbreviated
      header for header cells so that user agents may render header
      information more rapidly.


[1] http://juicystudio.com/wcag/tables/complexdatatable.html
-- 
leif halvard silli


From jason at jasonjgw.net  Sat Aug 23 18:49:05 2008
From: jason at jasonjgw.net (Jason White)
Date: Sun, 24 Aug 2008 11:49:05 +1000
Subject: [html4all] @abbr, short TH fallback for screen readers
In-Reply-To: <48B0B3C5.7000501@malform.no>
References: <48B0B3C5.7000501@malform.no>
Message-ID: <20080824014905.GA7087@jdc.jasonjgw.net>

On Sun, Aug 24, 2008 at 03:05:09AM +0200, Leif Halvard Silli wrote:
 
> Are there User Agents who support this attribute? Do you think it is 
> worth keeping? It makes sense to me: For traversal of a table, it should 
> be practical to be able to list abbreviated TH content rather than the 
> full content.

There are cases in braille where tables cannot be formatted spatially if the
full headers are given, but a spatial layout is possible with abbreviated
headers. Usually, there is a "key" included which specifies the abbreviations
used and the corresponding full text.

I can envisage similar usages involving devices with small screens, or
enlarged fonts.

There is new XML to braille software available that might be able to support
this, given suitable style rules, but it definitely isn't a feature that can
be readily supported today, regrettably.

I expect screen readers could implement it given support from the relevant
accessibility APIs.

Arguably this doesn't belong in CSS or any other style language; it is part of
the content rather than the presentation.



From jason at jasonjgw.net  Sat Aug 23 19:10:01 2008
From: jason at jasonjgw.net (Jason White)
Date: Sun, 24 Aug 2008 12:10:01 +1000
Subject: [html4all] distinguishing text equivalents: alt text
	and	descriptive text
In-Reply-To: <C16F8788-AB2D-4AFB-8D22-76F261C119F2@robburns.com>
References: <AD0C728B-4A67-47DA-8E54-8F4F7243A4CD@robburns.com>
	<48ACDDE3.3060306@malform.no>
	<3B79E5D2-AD51-4C90-8185-6CE8C9E8BBFE@robburns.com>
	<48AE3453.2020506@malform.no>
	<2389286B-5007-409F-A991-252692A19AA0@robburns.com>
	<48AF0296.6000202@malform.no>
	<5D27059D-4841-4D49-AFD3-CAA6166DE8C9@robburns.com>
	<20080823101446.GA16357@jdc.jasonjgw.net>
	<3D3BBF9E-91F4-40C3-A636-D68451FCF4CC@robburns.com>
	<C16F8788-AB2D-4AFB-8D22-76F261C119F2@robburns.com>
Message-ID: <20080824021001.GA7253@jdc.jasonjgw.net>

On Sun, Aug 24, 2008 at 01:15:15AM +0300, Robert J Burns wrote:
 
> The short-term approach I'm advocating is to extend the longdesc  
> attribute (or another similar attribute like textdesc) to the other  
> embedded media elements (e.g., OBJECT). It may be that this short term  
> approach is unnecessary since it isn't a feature of the language  
> authors have come to expect yet. However, so far Ian has rejected both  
> longdesc and UAs providing user access to media metadata[3].

I'm against extending @longdesc to OBJECT and other media elements, but in
favour of retaining it for IMG.

I also think ua access to embedded metadata in media objects is valuable and
important.



From gez.lemon at gmail.com  Sun Aug 24 02:42:17 2008
From: gez.lemon at gmail.com (Gez Lemon)
Date: Sun, 24 Aug 2008 10:42:17 +0100
Subject: [html4all] @abbr, short TH fallback for screen readers
In-Reply-To: <48B0B3C5.7000501@malform.no>
References: <48B0B3C5.7000501@malform.no>
Message-ID: <e2a28a920808240242h2df92456qd7055cffc2afb013@mail.gmail.com>

Hi Leif,

2008/8/24 Leif Halvard Silli <lhs at malform.no>:
> HTML 4 has the @abbr for table cells, aimed at screen readers,
> primerely. It is sofar not included n HTML 5. Should it be kept?

I think it should definitely be kept.

> Are there User Agents who support this attribute?

JAWS and Window-Eyes support it. I'm not sure how far back support is,
but it's from at least Version 8 of JAWS, and at least version 5.5 of
Window-Eyes.

I've set up a test table [1] that uses abbreviations for the headers,
"Course Name" and "Course Tutor". In JAWS and Window-Eyes, the headers
are announced in full when the column headers are read themselves. But
when referenced as part of data (navigating from cell to cell in a
row, or querying the headers for the current cell), both JAWS and
Window-Eyes only announce the abbreviation.

Caveats:

1: Window-Eyes 5.5 doesn't announce the abbreviated version in Firefox
- just IE.

2: The verbosity settings for Window-Eyes must be explicitly set to
any of the header reading modes (it's off by default), apart from
RX/CY, where only the row number and column number would be announced.

[1] http://juicystudio.com/wcag/tables/abbrheader.html


Cheers,

Gez


-- 
_____________________________
Supplement your vitamins
http://juicystudio.com


From rob at robburns.com  Sun Aug 24 02:50:08 2008
From: rob at robburns.com (Robert J Burns)
Date: Sun, 24 Aug 2008 12:50:08 +0300
Subject: [html4all] @abbr, short TH fallback for screen readers
In-Reply-To: <48B0B3C5.7000501@malform.no>
References: <48B0B3C5.7000501@malform.no>
Message-ID: <5C79915C-5F2A-45BF-BC00-16B50C99075B@robburns.com>

Hi Leif,

Isn't it ironic the way Ian says he's trying to help users by reducing  
the verbosity of headers queries by forcing the reduced complexity of  
tables (actually making complex tables completely inaccessible) and  
thereby reducing the number of headers associated with a data cell,  
while at the same time he eliminates the abbr attribute which is  
designed to reduce verbosity in a information lossless way.

My view is that the abbr attribute is needed and that there's no  
reason to eliminate it. My understanding is also that it is fairly  
well supported by assistive tech UAs.

Take care,
Rob

On Aug 24, 2008, at 4:05 AM, Leif Halvard Silli wrote:

> HTML 4 has the @abbr for table cells, aimed at screen readers,
> primerely. It is sofar not included n HTML 5. Should it be kept?
>
> With a reference to the discussion I, Rob and Jason lead about "short
> @alt" versus "@longdesc" etc,  I would describe @abbr as a "short text
> equivalent of of an table header cell".
>
> Are there User Agents who support this attribute? Do you think it is
> worth keeping? It makes sense to me: For traversal of a table, it  
> should
> be practical to be able to list abbreviated TH content rather than the
> full content.
>
> Here are the HTML 4 code examples with @abbr:
>
>    * <TH id="t3" abbr="Type">Type of Coffee</TH>
>    * <TH scope="col" abbr="Name">Course Name</TH>
>    * <TH scope="col" abbr="Tutor">Course Tutor</TH>
>
> I was reminded about this issue when I saw Gez's table demonstration
> (for the cause of allowing @headers to point to data cells). [1] There
> Gez has used the ABBR element in 3 of the headings.  But as you can  
> see
> from the code examples above, the @abbr and <ABBR> works differently.
>
> The @abbr reminds me a lot about @label for <OPTION>. (Opera  only  
> added
> support for <option @lable> in Opera 9.5.). Here is what HTML 4 says
> about <option @lable>:
>
>    * label = text [CS]
>      This attribute allows authors to specify a shorter label for an
>      option than the content of the OPTION element. When specified,
>      user agents should use the value of this attribute rather than  
> the
>      content of the OPTION element as the option label.
>
>
> This is what the prose of HTML 4 says about @abbr (note that HTML 4  
> also
> see a use case for visual agents):
>
> DTD
>
>    * abbr        %Text;         #IMPLIED  -- abbreviation for header
>      cell --
>
> Prose:
>
>    * abbr = text [CS]
>      This attribute should be used to provide an abbreviated form of
>      the cell's content, and may be rendered by user agents when
>      appropriate in place of the cell's content. Abbreviated names
>      should be short since user agents may render them repeatedly. For
>      instance, speech synthesizers may render the abbreviated headers
>      relating to a particular cell before rendering that cell's  
> content.
>    * The TH element defines a cell that contains header information.
>      User agents have two pieces of header information available: the
>      contents of the TH element and the value of the abbr attribute.
>      User agents must render either the contents of the cell or the
>      value of the abbr attribute. For visual media, the latter may be
>      appropriate when there is insufficient space to render the full
>      contents of the cell. For non-visual media abbr may be used as an
>      abbreviation for table headers when these are rendered along with
>      the contents of the cells to which they apply.
>    * [non-visual UAs:] The abbr attribute specifies an abbreviated
>      header for header cells so that user agents may render header
>      information more rapidly.
>
>
> [1] http://juicystudio.com/wcag/tables/complexdatatable.html
> -- 
> leif halvard silli
>
> _______________________________________________
> List_HTML4all.org mailing list
> http://www.html4all.org/wiki
> Archives: http://html4all.org/mailman/private/list_html4all.org/



From rob at robburns.com  Sun Aug 24 03:31:54 2008
From: rob at robburns.com (Robert J Burns)
Date: Sun, 24 Aug 2008 13:31:54 +0300
Subject: [html4all] On HTML4 tables in general
In-Reply-To: <5C79915C-5F2A-45BF-BC00-16B50C99075B@robburns.com>
References: <48B0B3C5.7000501@malform.no>
	<5C79915C-5F2A-45BF-BC00-16B50C99075B@robburns.com>
Message-ID: <AD3B6E82-6924-49EB-9239-FCDF116369EC@robburns.com>

On the issue of tables in general and Ian's desire to deprecate HTML4  
table properties included:

  ? headers
  * summary
  ? abbr
  ? axis

Axis has some uses, but Ian contends it is seldom if ever used (at  
least correctly). I think axis too could be useful, but part of its  
failure is that it takes comma separated strings rather than space  
separated name. Taking space separated names would allow the axis  
attribute to participate in CSS attribute selectors. Philip Taylor  
(not retired) has suggested if axis is useful making a new attribute  
would be better than changing axis to space separate names. I tend to  
agree with that.

On the other hand scope I think has some ambiguity problems that ian  
is uninterested in addressing. I've started a wiki page discussing  
those problems[1]. In a nutshell I think the use of colgroup and  
rowgroup is ill-advised since it can potentially create a header  
association that completely conflicts with the visual association of  
headers. Also I think simply having the keywords 'vertical',  
'horizontal', and 'both' (default) in HTML5 would make for clearer  
authoring and better reflect the automatic header association algorithm.

Finally, HTML5 goes further than HTML4 in deprecating some  
presentational table attributes. While I'm generally in favor of  
moving the presentational stuff to CSS, Im not sure CSS has adequately  
addressed the use cases for these table attributes. Moreover, just as  
HTML5 retains width and height attributes for embedded media (though  
using CSS pixel units), the table presentational attributes are  
likewise for tables that are inherently visual (as their used in  
documents anyway).

Maintaining attributes within HTML for column width, vertical  
alignment, horizontal alignment and makes sense to me. CSS (much from  
Ian's insistence) has deprecated horizontal alignment on a string (as  
of CSS 2.1 CR). The vertical alignment in HTML works differently than  
vertical alignment in CSS. And the HTML width attribute also provides  
valuable control of column widths not possible with CSS.

Finally, I have also written a wiki page on the need to enhance tables  
and treat them as 2D structures rather than merely as one-dimensional  
hierarchies as with other HTML structures[2]. Without treating tables  
as 2d structures authors are forced to needless repeat attribute  
values and tables are more cumbersome to edit with DOM APIs.

Take care,
Rob

[1]: <http://esw.w3.org/topic/HTML/TableHeaderCellScope>
[2]: <http://esw.w3.org/topic/HTML/TablesAs2DStructures>

From lhs at malform.no  Sun Aug 24 16:12:02 2008
From: lhs at malform.no (Leif Halvard Silli)
Date: Mon, 25 Aug 2008 01:12:02 +0200
Subject: [html4all] If attribute X is dropped ... (@profile etc)
Message-ID: <48B1EAC2.5090002@malform.no>

If @profile is dropped, then simply breaking the HTML 5 standard, or 
using another standard is some of the things which the (until recently) 
Working Group Chair Dan see as possibilities [1]:
> Possibilities I see include:
> * GRDDL implementations add support for rel="profile" along with HTML 
> 5 concrete syntax.
> * GRDDL implementors don't change their code, so people who want to 
> use GRDDL with HTML 5 features such as <video> stick to XML-wf-happy 
> HTML 5 syntax and they use the head/@profile attribute anyway, despite 
> what the HTML 5 spec says.
> * People who want to use GRDDL stick to XHTML 1.x.
> * People who want to put data in their HTML documents use RDFa.
>
> I don't particularly care for the rel="profile" design, but one should 
> choose ones battles and I'm not inclined to choose this one. I'm 
> content for the market to choose.

When *he* mentions breaking the standard/using another one, then it is 
quite telling.

Compare what Ian told Laura recently [2]:

>> Use the tools/services and let them be nonconforming.
>

> It makes no sense for the specification to advise someone to not 
> conform to the specification. [...] If something is not allowed, then
> it should never be done.


When the (former) Working Group Chair is saying that "there is also the 
option to not be conforming to the standard", then I feel tempted to use 
Ian's words as argument for keeping @profile.

I hope you see some quite obvious links to the accessibility attributes 
in the above. Hence let us support @profile in the Working Group. (I had 
the impression from the Telcon minutes that the WG will be asked to make 
a decision on @profile soon.)

[1] http://www.w3.org/QA/2008/08/the_details_of_data_in_documen.html
[2] http://lists.w3.org/Archives/Public/public-html/2008Aug/0611.html
-- 
leif halvard silli


From lhs at malform.no  Sun Aug 24 18:00:53 2008
From: lhs at malform.no (Leif Halvard Silli)
Date: Mon, 25 Aug 2008 03:00:53 +0200
Subject: [html4all] @abbr, short TH fallback for screen readers
In-Reply-To: <e2a28a920808240242h2df92456qd7055cffc2afb013@mail.gmail.com>
References: <48B0B3C5.7000501@malform.no>
	<e2a28a920808240242h2df92456qd7055cffc2afb013@mail.gmail.com>
Message-ID: <48B20445.9060702@malform.no>

Gez Lemon 2008-08-24 11.42:

>> Are there User Agents who support this attribute?
> 
> JAWS and Window-Eyes support it. I'm not sure how far back support is,
> but it's from at least Version 8 of JAWS, and at least version 5.5 of
> Window-Eyes.

 >

> I've set up a test table [1] that uses abbreviations for the headers,
> "Course Name" and "Course Tutor". In JAWS and Window-Eyes, the headers
> are announced in full when the column headers are read themselves. But
> when referenced as part of data (navigating from cell to cell in a
> row, or querying the headers for the current cell), both JAWS and
> Window-Eyes only announce the abbreviation.

Hi Gez. Thanks for checking it!

I now see that @abbr is also mentioned at least in in WCAG 1 [1] 
and 2 [2]. (However WCAG 2.0 lacks any test case for it.)

> Caveats:
> 
> 1: Window-Eyes 5.5 doesn't announce the abbreviated version in Firefox
> - just IE.


I have the impression that it in general is safer to use IE than 
Firefox when it comes to the most well known sceen readers.

How do we go about for getting it into HTML 5 then? Raise it on 
the tracker? The issue belongs to the @summary issue! (WCAG 1.0 
links @abbr and @summary under the heading "Providing summary 
information". [3] ) Perhaps it can be included with that one?

Btw, just to try out an idea: XHTML 2.0 has <summary/> instead of 
@summary. So how about a <summary/> element with a double 
function: 1) providing a Table summary when used as direct child 
of TABLE, 2) providing a TH summary, when used as child of TH. 
(This said, as support for CSS improves, it might not be much 
advantage with a element vs an attribute. Via CSS one can soon 
show/hide content and attributes ad Lib.)

[1] http://www.w3.org/TR/WCAG10-TECHS/#tech-abbreviate-labels
[2] 
http://www.w3.org/TR/2005/WD-WCAG20-HTML-TECHS-20050630/#datatables_abbr
[3] http://www.w3.org/TR/WCAG10-HTML-TECHS/#table-summary-info
-- 
leif halvard silli


From faulkner.steve at gmail.com  Mon Aug 25 01:10:31 2008
From: faulkner.steve at gmail.com (Steven Faulkner)
Date: Mon, 25 Aug 2008 09:10:31 +0100
Subject: [html4all] If attribute X is dropped ... (@profile etc)
In-Reply-To: <48B1EAC2.5090002@malform.no>
References: <48B1EAC2.5090002@malform.no>
Message-ID: <55687cf80808250110g434fdc5en6ec53be216ecfd57@mail.gmail.com>

Hi leif, i picked up the same thing from what Dan said.

I have also been musing on the subject. If attributes are dropped in
HTML5 that are useful for accessibility, accessibility advocates will
be forced to either not recommend the use of HTML5 in cases where
these attributes are needed or forced to recommed the use of
non-conforming code in HTML5.

regards
stevef

2008/8/25 Leif Halvard Silli <lhs at malform.no>:
> If @profile is dropped, then simply breaking the HTML 5 standard, or
> using another standard is some of the things which the (until recently)
> Working Group Chair Dan see as possibilities [1]:
>> Possibilities I see include:
>> * GRDDL implementations add support for rel="profile" along with HTML
>> 5 concrete syntax.
>> * GRDDL implementors don't change their code, so people who want to
>> use GRDDL with HTML 5 features such as <video> stick to XML-wf-happy
>> HTML 5 syntax and they use the head/@profile attribute anyway, despite
>> what the HTML 5 spec says.
>> * People who want to use GRDDL stick to XHTML 1.x.
>> * People who want to put data in their HTML documents use RDFa.
>>
>> I don't particularly care for the rel="profile" design, but one should
>> choose ones battles and I'm not inclined to choose this one. I'm
>> content for the market to choose.
>
> When *he* mentions breaking the standard/using another one, then it is
> quite telling.
>
> Compare what Ian told Laura recently [2]:
>
>>> Use the tools/services and let them be nonconforming.
>>
>
>> It makes no sense for the specification to advise someone to not
>> conform to the specification. [...] If something is not allowed, then
>> it should never be done.
>
>
> When the (former) Working Group Chair is saying that "there is also the
> option to not be conforming to the standard", then I feel tempted to use
> Ian's words as argument for keeping @profile.
>
> I hope you see some quite obvious links to the accessibility attributes
> in the above. Hence let us support @profile in the Working Group. (I had
> the impression from the Telcon minutes that the WG will be asked to make
> a decision on @profile soon.)
>
> [1] http://www.w3.org/QA/2008/08/the_details_of_data_in_documen.html
> [2] http://lists.w3.org/Archives/Public/public-html/2008Aug/0611.html
> --
> leif halvard silli
>
> _______________________________________________
> List_HTML4all.org mailing list
> http://www.html4all.org/wiki
> Archives: http://html4all.org/mailman/private/list_html4all.org/
>



-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html


From laura.lee.carlson at gmail.com  Mon Aug 25 10:54:20 2008
From: laura.lee.carlson at gmail.com (Laura Carlson)
Date: Mon, 25 Aug 2008 12:54:20 -0500
Subject: [html4all] html5 Comment:The web, the noob, and the soup
Message-ID: <1c8dbcaa0808251054g4ba05aaat1edd133734d61331@mail.gmail.com>

For your info...
"The web, the noob, and the soup"
http://lists.w3.org/Archives/Public/public-html-comments/2008Aug/0005.html

Best Regards,
Laura
-- 
Laura L. Carlson


From rob at robburns.com  Tue Aug 26 13:13:31 2008
From: rob at robburns.com (Robert J Burns)
Date: Tue, 26 Aug 2008 23:13:31 +0300
Subject: [html4all] alt attribute applied to other elements
Message-ID: <B8656839-60C7-40DE-B28C-7DD4B5BCDF1B@robburns.com>

Hello 4all,

So Ian has basically returned the draft to the original state that  
raised so many objections. For images where the author doesn't want to  
provide alt text she need not provide alt text: or as Ian is so fond  
of calling the willful omission of alt text: "Images whose contents  
are not known". Except now in addition to requiring such images to be  
wrapped in a figure element with some text, he now also permits a  
title of the image to replace the alt text using either the title  
attribute or the a heading element.

Again his only goal seems to be to introduce a loophole so that  
basically alt does not show up in conformance checkers (since the  
conformance checker cannot possibly differentiate these cases from all  
others and therefore cannot flag any IMG omitting the alt attribute as  
an error). Ian's examples are: a webcam, automated embedding (again  
equality, fraternity and equal rights for machines!), and blind  
authors (let's not discriminate against the disabled here). The webcam  
is a misguided example. The important thing to describe with a webcam  
in its alt text is what the purpose of the webcam is (e.g., "The  
Eiffel Tower from the North" or "affixed to my forehead as I tour the  
World" if these are not provided in the caption, otherwise alt='').  
The other two examples are precisely the examples where I feel  
strongly the draft should not treat as conforming HTML. These examples  
constitute HTML that has been incompletely authored and the absence of  
the alt attribute can be an indication of that state. But there is no  
reason to also make it conforming.

All that aside:

There are two cases the HTML5 draft covers for alt that I feel should  
be handled by permitting (and even requiring) the alt attribute on  
elements other than IMG.

The HTML5 draft covers 10 worthwhile cases[1]. They are (with proposed  
role keywords[2] in parentheses):

  ? link  ? required
  ? charts, etc.(chart, diagram, geomap) ? required
  ? icons and logos (icon, logo) ? required
  ? text (text, mathexpr, musicscore) ? required
  ? Illustrative of the nearby text (illustrative) ? null required
  ? Decorative (decorative) ? null required
  ? image that is part of a larger sliced image ? ?
  ? image that is part of a larger sliced image with links ? ?
  ? either a key part or \the\ key part of the content ? required  
except now we're back to the not required if the author doesn't want  
to bother
  ? img hacks

The 11th situation[3] where authors think they know the audience for  
their HTML just doesn't need to be addressed. I already know I can  
send HTML to my mother even if its not conforming. I don't need Ian or  
HTML5 to OK that.

However, there are two other cases that I think suggest alt should be  
permitted elsewhere. The first case of a link (and I've brought this  
up before) is where the author provides alt text to describe where a  
link will take the user. To me this belongs on the A (anchor) element  
and not on the image. I think it is easier for authors to understand  
on the anchor than on the IMG. Also it may be that the IMG element  
needs descriptive of the image alt text while the link needs alt text  
descriptive of the link destination. Finally, I think it would be easy  
for conformance checkers to alert authors of the needed alt text  
whenever an anchor fails to contain significant text either in its  
contents or in its alt attribute.

The other case is that of image slices. Personally, I think client- 
side image maps might be a better technique than image slices for the  
use case, but when authors do use image slices I think we should  
require the element containing the slices (perhaps a DIV or a TABLE)  
also accept the alt attribute. I suppose for TABLE the summary  
attribute could be used (if we're keeping it), but the alt attribute  
would be better since it could be used automatically without querying  
like the summary attribute (and it could also be either a table or a  
div that contained the image slices).

Take care,
Rob

[1]: <http://www.whatwg.org/specs/web-apps/current-work/#alt>
[2]: <http://esw.w3.org/topic/PF/XTech/HTML5/RoleAttribute#head-610fd0a42b1d8af2253378db31d9d28bd22988b9 
 >
[3]: <http://www.whatwg.org/specs/web-apps/current-work/#an-image0>

From foliot at wats.ca  Tue Aug 26 13:46:59 2008
From: foliot at wats.ca (John Foliot)
Date: Tue, 26 Aug 2008 13:46:59 -0700
Subject: [html4all] @role values & comments (was RE: alt attribute applied
	to other elements)
In-Reply-To: <B8656839-60C7-40DE-B28C-7DD4B5BCDF1B@robburns.com>
Message-ID: <009f01c907bc$e2f6c900$b03142ab@stanford.edu>

Robert J Burns wrote:
 
> So Ian has basically returned the draft to the original state that
> raised so many objections. For images where the author doesn't want to
> provide alt text she need not provide alt text: or as Ian is so fond
> of calling the willful omission of alt text: "Images whose contents
> are not known". Except now in addition to requiring such images to be
> wrapped in a figure element with some text, he now also permits a
> title of the image to replace the alt text using either the title
> attribute or the a heading element.

Rob,

I think we need to also be pragmatic here: if an image has sufficient
textual information surrounding it, and that information is directly linked
to the image, but there is no "alt" value, we have to accept that sometimes
this is the best we are going to get.  It is not "deprecating" @alt, but
simply accepting that yep, sometimes we're gonna get nothing, and now at
least we have a spec that says that even when there is no alt value/content,
that there must be something else "specifically" on the page to be
conformant.  Water with the wine I'm afraid.


> 
> Again his only goal seems to be to introduce a loophole so that
> basically alt does not show up in conformance checkers (since the
> conformance checker cannot possibly differentiate these cases from all
> others and therefore cannot flag any IMG omitting the alt attribute as
> an error).

See my response to Ian's note.  I think we should still push for a mandatory
@alt for "code purity" but accept that oft time the value will be alt=""
(which does nothing but satisfy the conformance checker - certainly is of no
use to the non-sighted)


> 
> The HTML5 draft covers 10 worthwhile cases[1]. They are (with proposed
> role keywords[2] in parentheses):
> 
>   . link  - required
>   . charts, etc.(chart, diagram, geomap) - required
>   . icons and logos (icon, logo) - required
>   . text (text, mathexpr, musicscore) - required
>   . Illustrative of the nearby text (illustrative) - null required
>   . Decorative (decorative) - null required
>   . image that is part of a larger sliced image - ?
>   . image that is part of a larger sliced image with links - ?
>   . either a key part or \the\ key part of the content - required
> except now we're back to the not required if the author doesn't want
> to bother
>   . img hacks

Not to go too off track, but I really like those proposed @role values.  Is
this something collectively we should expand upon?Should we put forth a
formal proposal to "entrench" these values into the spec, or should they
simply remain external to HTML 5 but elsewhere defined? (As I recall, @role
values, at least back when I was looking at @role in context of XHTML2, can
be defined using RDF, so would these roles be something that would live
within WAI space?  I do not know - perhaps Chaals could shed some
light/thoughts?)

> 
> However, there are two other cases that I think suggest alt should be
> permitted elsewhere. The first case of a link (and I've brought this
> up before) is where the author provides alt text to describe where a
> link will take the user. To me this belongs on the A (anchor) element
> and not on the image. I think it is easier for authors to understand
> on the anchor than on the IMG. Also it may be that the IMG element
> needs descriptive of the image alt text while the link needs alt text
> descriptive of the link destination. Finally, I think it would be easy
> for conformance checkers to alert authors of the needed alt text
> whenever an anchor fails to contain significant text either in its
> contents or in its alt attribute.

Hmmm... I can see some possible value here.  Robert, how do you see this as
being different that providing @title to the anchor element?  @title is for
"advisory" information, which as I read it is what you are talking about.

> 
> The other case is that of image slices. Personally, I think client-
> side image maps might be a better technique than image slices for the
> use case, but when authors do use image slices I think we should
> require the element containing the slices (perhaps a DIV or a TABLE)
> also accept the alt attribute. I suppose for TABLE the summary
> attribute could be used (if we're keeping it), but the alt attribute
> would be better since it could be used automatically without querying
> like the summary attribute (and it could also be either a table or a
> div that contained the image slices).

Personally, I am less keen on this.  I think that we should be discouraging
"image slices" rather than promoting them and "enhancing" them.

JF





From rob at robburns.com  Tue Aug 26 14:31:13 2008
From: rob at robburns.com (Robert J Burns)
Date: Wed, 27 Aug 2008 00:31:13 +0300
Subject: [html4all] @role values & comments (was RE: alt attribute
	applied to other elements)
In-Reply-To: <009f01c907bc$e2f6c900$b03142ab@stanford.edu>
References: <009f01c907bc$e2f6c900$b03142ab@stanford.edu>
Message-ID: <4AF73985-115C-4572-A0AB-58A7D0AC58BC@robburns.com>

On Aug 26, 2008, at 11:46 PM, John Foliot wrote:

> Robert J Burns wrote:
>
>> So Ian has basically returned the draft to the original state that
>> raised so many objections. For images where the author doesn't want  
>> to
>> provide alt text she need not provide alt text: or as Ian is so fond
>> of calling the willful omission of alt text: "Images whose contents
>> are not known". Except now in addition to requiring such images to be
>> wrapped in a figure element with some text, he now also permits a
>> title of the image to replace the alt text using either the title
>> attribute or the a heading element.
>
> Rob,
>
> I think we need to also be pragmatic here: if an image has sufficient
> textual information surrounding it, and that information is directly  
> linked
> to the image, but there is no "alt" value, we have to accept that  
> sometimes
> this is the best we are going to get.  It is not "deprecating" @alt,  
> but
> simply accepting that yep, sometimes we're gonna get nothing, and  
> now at
> least we have a spec that says that even when there is no alt value/ 
> content,
> that there must be something else "specifically" on the page to be
> conformant.  Water with the wine I'm afraid.

Actually these are two different cases in the HTML5 draft. What you  
describe here is the case where I apply the 'illustrative' role  
keyword and what the draft calls "a graphical representation of some  
of the surrounding text"[1]. However, what I'm referring to here is  
the section on "A key part of the content" subsection "Images whose  
contents are not known"[2]. Certainly the former should be  
alt='' (though we could also require explicit describedby=IDREF  
association). However, the latter does not need to be permitted by  
HTML5. I don't think we want to encourage authors to include alt='' in  
this case because it will get confused with the legitimate alt=''  
cases, but we could just require authoring tools to leave off the alt  
attribute and generate non-conforming HTML5 due to author error.  
Obviously an author cannot complain about its authoring tools emitting  
non-compliant HTML if the tool gave the author every opportunity to  
conform (as ATAG recommends). Though I wouldn't' be surprised to se  
the WhatWG folks complain about that :-).


>
>> Again his only goal seems to be to introduce a loophole so that
>> basically alt does not show up in conformance checkers (since the
>> conformance checker cannot possibly differentiate these cases from  
>> all
>> others and therefore cannot flag any IMG omitting the alt attribute  
>> as
>> an error).
>
> See my response to Ian's note.  I think we should still push for a  
> mandatory
> @alt for "code purity" but accept that oft time the value will be  
> alt=""
> (which does nothing but satisfy the conformance checker - certainly  
> is of no
> use to the non-sighted)

I saw it. Nicely done.

>> The HTML5 draft covers 10 worthwhile cases[1]. They are (with  
>> proposed
>> role keywords[2] in parentheses):
>>
>>  . link  - required
>>  . charts, etc.(chart, diagram, geomap) - required
>>  . icons and logos (icon, logo) - required
>>  . text (text, mathexpr, musicscore) - required
>>  . Illustrative of the nearby text (illustrative) - null required
>>  . Decorative (decorative) - null required
>>  . image that is part of a larger sliced image - ?
>>  . image that is part of a larger sliced image with links - ?
>>  . either a key part or \the\ key part of the content - required
>> except now we're back to the not required if the author doesn't want
>> to bother
>>  . img hacks
>
> Not to go too off track, but I really like those proposed @role  
> values.  Is
> this something collectively we should expand upon?Should we put  
> forth a
> formal proposal to "entrench" these values into the spec, or should  
> they
> simply remain external to HTML 5 but elsewhere defined? (As I  
> recall, @role
> values, at least back when I was looking at @role in context of  
> XHTML2, can
> be defined using RDF, so would these roles be something that would  
> live
> within WAI space?  I do not know - perhaps Chaals could shed some
> light/thoughts?)

I imagine there's many ways to do this. In XML including XHTML (though  
not XHTML5) the role keywords are QNames so each namespace steward  
(such as ARIA, HTML, etc) can designate their own keywords. Ian is  
opposed to QNames because they're helpful for authors, user and spec  
writers other than him, so instead it would have to handled differently.

>> However, there are two other cases that I think suggest alt should be
>> permitted elsewhere. The first case of a link (and I've brought this
>> up before) is where the author provides alt text to describe where a
>> link will take the user. To me this belongs on the A (anchor) element
>> and not on the image. I think it is easier for authors to understand
>> on the anchor than on the IMG. Also it may be that the IMG element
>> needs descriptive of the image alt text while the link needs alt text
>> descriptive of the link destination. Finally, I think it would be  
>> easy
>> for conformance checkers to alert authors of the needed alt text
>> whenever an anchor fails to contain significant text either in its
>> contents or in its alt attribute.
>
> Hmmm... I can see some possible value here.  Robert, how do you see  
> this as
> being different that providing @title to the anchor element?  @title  
> is for
> "advisory" information, which as I read it is what you are talking  
> about.

Its not all that different from alt for the containing image, but I  
feel it is something that would help authors understand the purpose of  
the alt text (though it would have legacy UA issues). So I'm merely  
suggesting:

<a href='aURLRef' alt='privacy policy'  ><img src='aURLRef2' ></a>

instead of the current practice:

<a href='aURLRef' ><img src='aURLRef2' alt='privacy policy' ></a>

The legacy issues alone may make this undesirable, but I feel authors  
would better understand what to do in the first case. Either way I  
think we should get conformance checkers and authoring tools to  
provide clear and specific alt text guidance especially for this case,  
where an anchor contains only an IMG element.

Of course in XHTML2 (and we could do this for both serializations of  
HTML5 as well) the structure could instead be:

<img href='aURLRef'  src='aURLRef2' alt='privacy policy' />

which simplifies this all into a single img link (of course in XHTML 2  
the alt text appears in the element contents, but we cannot do that  
for text/html and Ian for some reason doesn't want that for XML  
serializations either). Since adding attributes to text/html is much  
easier than adding new elements it would be very desirable for HTML5  
to follow the XHTML2 lead of globalizing many attributes.

>> The other case is that of image slices. Personally, I think client-
>> side image maps might be a better technique than image slices for the
>> use case, but when authors do use image slices I think we should
>> require the element containing the slices (perhaps a DIV or a TABLE)
>> also accept the alt attribute. I suppose for TABLE the summary
>> attribute could be used (if we're keeping it), but the alt attribute
>> would be better since it could be used automatically without querying
>> like the summary attribute (and it could also be either a table or a
>> div that contained the image slices).
>
> Personally, I am less keen on this.  I think that we should be  
> discouraging
> "image slices" rather than promoting them and "enhancing" them.

I tend to agree with you about image slices. Ian has deleted the image  
slice sections from the latest draft, but the table of contents still  
has the sections listed.

Take care,
Rob


[1]: <http://www.whatwg.org/specs/web-apps/current-work/#a-graphical>
[2[: <http://www.whatwg.org/specs/web-apps/current-work/#a-key>



From rob at robburns.com  Wed Aug 27 16:04:38 2008
From: rob at robburns.com (Robert J Burns)
Date: Thu, 28 Aug 2008 02:04:38 +0300
Subject: [html4all] XHTML2 and alt
In-Reply-To: <48B5D288.4080903@malform.no>
References: <F1130EA5-A489-4051-9BCC-11AEE868A972@mac.com>	<48B49410.8010900@malform.no>
	<C5F517BB-B276-44C8-A6EB-4F0C85E9CDF7@robburns.com>
	<48B5D288.4080903@malform.no>
Message-ID: <5DAB0F8B-C7AC-44E3-8CC6-EBD1D0B49212@robburns.com>

Hi Leif,

[moving to public list]

On Aug 28, 2008, at 1:17 AM, Leif Halvard Silli wrote:

> Robert J Burns 2008-08-27 08.52:
>> Aug 27, 2008, at 2:38 AM, Leif Halvard Silli:
>
>>> [ ... @alt (not) in XHTML 2 ... ]
>
>
>>> So, do we prefer <IMG> with @alt over the OBJECT/XHTML 2 model,
>>> just because presence of @alt is checked in the HTML validator?
>>
>> Well, the primary purpose for my message was exploring whether the
>> same benefits could be gained for the OBJECT/XHTML2 case. I think one
>> drawback I overlooked is that the errors for text/html IMG can be
>> avoided with alt='' while the other case would require the user to
>> enter an actual value. This could lead to more bogus placeholder text
>> than in the alt= case.
>
>
> There is a danger taht OBJECT could lead to more bogus fallback
> than does @alt. Agree.
>
> There is also a conflict between using the fallback to explain how
> to e.g. load a failing video (think about <video> in HTML 5 in its
> current shape and form) and providing real, textual fallback.
>
> However, both kinds of fallback are, per se, valid use cases. How
> can both issues be provided for, simultaneously?

I don't think there's a conflict per se. The problem with both VIDEO  
and AUDIO is that Ian has arbitrarily decided to prohibit the use of  
the element's contents for textual fallback. The existence of ordered  
<source> elements within these elements does not prevent other textual  
fallback. After all the object element also has param elements that  
are very similar to source elements. In fact source elements are not  
really semantically different from <param name='source' value='URI' >  
(compared with <source src='uri'>.  Yet the object element also  
supports textual fallback after the param elements. I would like to  
see the object element also support the source element (along with the  
other audio and video element features). Yet all these elements could  
still support textual fallback.


>
> [...]
>
>>>> [...] accessibility benefits an <img>fallback</img> [...]
>>>>
>>>> Even with XML serializations and IMG with no alt, the conformance
>>>> checker can still provide warnings whenever the IMG element has no
>>>> significant text content.
>>>
>>> Yes, but that issue has been forgotten. Doesn't this show that
>>> that the @alt checking in the HTML 4 validator really is a syntax
>>> check, and not a accessibility check?
>>
>> I don't think the issue of accessibility has been forgotten in  
>> XHTML2. [...]
>
>
> Right. And, if we include the WCAG recommendations, we could say
> that even in HTML, it has not been forgotten, not even for the
> <OBJECT> element. But reality is that we discuss @alt over and
> over, but not <object>.

I agree, that object needs to be addressed too. Though I think the  
role and describedby attributes provide everything we need (along with  
the element's contents).

>
>
> [ ... ]
>
>
>>> Talking about Karl Dubost's private photo album that he mentioned
>>> in the HTMLwg: What would be best, today, for all his thousands of
>>> images: <img src=src alt=""> or <img src=src >?
>>
>> I think the best thing would be <img src='src'> and for Karl's page  
>> to
>> be non-conforming. Karl won't be put to death for his non-conforming
>> page. However, leaving the alt attribute missing allows Karl and
>> subsequent authors of the same document to discover and repair the
>> errors. Adding alt='' glosses over those errors and doesn't make the
>> page conforming (it only fools the machine and remains non- 
>> conforming).
>
>
> I did not know you were open to making @alt optional? ;-) Would
> you have had that idea, if it were not for HTML 5/Ian/WHATwg's
> idea that it should be possible to do so?
>
> The only difference between his and your idea is that he thinks
> <img src=src> should be valid. Whereas you think not.

Well, yes that's what I thought the whole debate was about. My view is  
that making alt required introduces authors to accessibility issues. I  
don't even see the downside.

> Yet, at the same time, even Ian says that lack of alt should be
> the symbol of something lacking. So how big is the difference?

Ian's approach completely removes HTML conformance checking as a  
mechanism to introduce authors to accessibility issues. Requiring  
accessibility within HTML5 does introduce authors to accessibility.

> (Btw, when Laura told Karl that he should be non-conforming, then
> I suppose she meant that he should use <img src=src alt="">, as
> this would be non-conforming as well.)

I understood her as meaning non-conforming in a machine verifiable  
way: in other words, with the alt attribute omitted.

> I for one, having read Ramans message etc, wonder if an /formally/
> optional alt is part of the solution. At the very least I agree
> with him that mixing validation with content/accessibilty checking
> is problematic.

What is the problem? I haven't heard anyone explain what the problem is.

>>> I think that - in effect - we are spreading the message that <img
>>> alt="" ...> would be better than no alt, and also better than <img
>>> alt="photo" ...>. I say this not because I think no alt should be
>>> permitted, but because, in effect, I think that all we are really
>>> defending is a syntax, and not accessibility.
>>
>> Personally, I want to defend the syntax for its accessibility  
>> benefits.
>
> Above you said Karl should have used <img src=src> = no alt.

Yes. To produce a non-conforming document that didn't simply add  
alt='' to pretend to be conforming. Both leaving off the alt attribute  
and using alt='' are non-conforming. The former provides a quick way  
for software to alert authors it is non-conforming while the latter  
does not.

>>> To link this to Rob's message: We should try to look at <img> more
>>> like we look at <object> and go on from there.
>>
>> The purpose of my message was to try to understand how <object> could
>> be conformance checked in a way that preserved the accessibility
>> awareness raising of having the alt attribute.
>
> Understood. Hence @role. Which I agree is the way to check if
> fallback is used and used correct for OBJECT and the like.

In an authoring tool, one can imagine the UI asking for alt text:

enter alt text: ________

buttons:
[cancel/later]
[decorative/none]
[illustrative of surrounding text]
[enter] {enter button enabled only when text if filled in}

This UI works for either <img alt='fallback'>, <img>fallback</img> or  
<object>fallbck</object>

cancel/later: <img>    <img></img> <object></object>
decorative/none: <img role='decor'> <img role='decor'></img> <object  
role='decor' ></object>
illustrative of surrounding text <img role='illustrative'> <img  
role='illustrative'></img> <object role='illustrative ></object>
enter <img alt='entered fallback'> <img> entered fallback </img>  
<object> entered fallback </object>

The authoring tool can further check the spelling and grammar of the  
text and alert the author if it appears to be bogus text and require  
further confirmation.

>
>
>> So I think we should get authoring tools and conformance checkers to
>> add much from WCAG, ARIA and other accessibility related
>> recommendations. We should also make sure the other embedding  
>> elements
>> retain accessibility capabilities so that <img alt= > is not the only
>> accessible embedding mechanism. Finally, I think we should be
>> strengthening the conformance norms for accessibility in HTML5 and  
>> not
>> weakening them. I've written about this before[1], but I think we
>> should recommend make conformance more stringent while recommending
>> conformance checkers allow authors to suppress error and warnings  
>> on a
>> per session basis (requiring that the suppression preference not be
>> stored persistently, but requires the author to suppress on each
>> launch of the application, or scan of a document). I don't think
>> anything more is required to satisfy the issues raised by the WhatWG
>> crowd.
>
> Very spesific rules for how validation should happen ..

That would help too. I've written on that before along with authoring  
tool norms. I'll try to find those previous emails.

Take care,
Rob


From lhs at malform.no  Wed Aug 27 17:20:54 2008
From: lhs at malform.no (Leif Halvard Silli)
Date: Thu, 28 Aug 2008 02:20:54 +0200
Subject: [html4all] XHTML2 and alt
In-Reply-To: <5DAB0F8B-C7AC-44E3-8CC6-EBD1D0B49212@robburns.com>
References: <F1130EA5-A489-4051-9BCC-11AEE868A972@mac.com>	<48B49410.8010900@malform.no>	<C5F517BB-B276-44C8-A6EB-4F0C85E9CDF7@robburns.com>	<48B5D288.4080903@malform.no>
	<5DAB0F8B-C7AC-44E3-8CC6-EBD1D0B49212@robburns.com>
Message-ID: <48B5EF66.2070001@malform.no>

Robert J Burns 2008-08-28 01.04:

> On Aug 28, 2008, at 1:17 AM, Leif Halvard Silli wrote:
>> Robert J Burns 2008-08-27 08.52:
>>> Aug 27, 2008, at 2:38 AM, Leif Halvard Silli:


>>>> [ ... @alt (not) in XHTML 2 ... ]


>>>> So, do we prefer <IMG> with @alt over the OBJECT/XHTML 2 model,
>>>> just because presence of @alt is checked in the HTML validator?

   [...]

>> There is also a conflict between using the fallback to explain how
>> to e.g. load a failing video (think about <video> in HTML 5 in its
>> current shape and form) and providing real, textual fallback.

   [...]

> I don't think there's a conflict per se. The problem with both VIDEO  
> and AUDIO is that Ian has arbitrarily decided to prohibit the use of  
> the element's contents for textual fallback. The existence of ordered  
> <source> elements within these elements does not prevent other textual  
> fallback. After all the object element also has param elements that  
> are very similar to source elements. In fact source elements are not  
> really semantically different from <param name='source' value='URI' >  
> (compared with <source src='uri'>.  Yet the object element also  
> supports textual fallback after the param elements. I would like to  
> see the object element also support the source element (along with the  
> other audio and video element features). Yet all these elements could  
> still support textual fallback.


I don't think you explained what I asked. This is my simple issue: 
If the fallback is supposed to play two roles, then the content 
needs to be authored so that the one purpose does not disturb the 
other - either that, or there needs to a mechanism that separate 
the two issues in a userselectable way.

>>>> Talking about Karl Dubost's private photo album that he mentioned
>>>> in the HTMLwg: What would be best, today, for all his thousands of
>>>> images: <img src=src alt=""> or <img src=src >?
>>>

>>> I think the best thing would be <img src='src'> and for
>>> Karl's page to be non-conforming. [...]


>> I did not know you were open to making @alt optional? ;-) Would
>> you have had that idea, if it were not for HTML 5/Ian/WHATwg's
>> idea that it should be possible to do so?
>>
>> The only difference between his and your idea is that he thinks
>> <img src=src> should be valid. Whereas you think not.
> 
> Well, yes that's what I thought the whole debate was about. My view is  
> that making alt required introduces authors to accessibility issues. I  
> don't even see the downside.


Very many sides of the @alt issue have been discussed 
simultaneously, recently. But, no, I did not know that being 
/syntactically/ invalid was one option for you or anyone else.

 
>> Yet, at the same time, even Ian says that lack of alt should be
>> the symbol of something lacking. So how big is the difference?
> 
> Ian's approach completely removes HTML conformance checking as a  
> mechanism to introduce authors to accessibility issues. Requiring  
> accessibility within HTML5 does introduce authors to accessibility.

At the same time, OBJECT, which is supposed to be superior to 
<img> accessibilitywise, can be completely empty without 
triggering any error.

All the @alt checking in HTML 4 does, is that it introduces the 
/idea/ that <img> can have fallback text.

For <object>, there is no (or less) need to introduce anyone to 
that idea. And, yes, both <object></object> and alt="" can be 
empty, and nothing happens, in the validator.

>> (Btw, when Laura told Karl that he should be non-conforming, then
>> I suppose she meant that he should use <img src=src alt="">, as
>> this would be non-conforming as well.)
> 
> I understood her as meaning non-conforming in a machine verifiable  
> way: in other words, with the alt attribute omitted.

Karl used the phrase "put alt text".

>> I for one, having read Ramans message etc, wonder if an /formally/
>> optional alt is part of the solution. At the very least I agree
>> with him that mixing validation with content/accessibilty checking
>> is problematic.
> 
> What is the problem? I haven't heard anyone explain what the problem is.

The problem is that authors do not manage to think about all 
things simultaneously. If ask for HTML syntax errors, then I do 
not want to be told about CSS errors or content/accessibilty errors.

In the case of @alt, the need for validation causes authors to do 
what you say they should not do: Adding empty alt="".

>>>> I think that - in effect - we are spreading the message that <img
>>>> alt="" ...> would be better than no alt, and also better than <img
>>>> alt="photo" ...>. I say this not because I think no alt should be
>>>> permitted, but because, in effect, I think that all we are really
>>>> defending is a syntax, and not accessibility.
>>>
>>> Personally, I want to defend the syntax for its accessibility  
>>> benefits.
>>
>> Above you said Karl should have used <img src=src> = no alt.
> 
> Yes. To produce a non-conforming document that didn't simply add  
> alt='' to pretend to be conforming. Both leaving off the alt attribute  
> and using alt='' are non-conforming. The former provides a quick way  
> for software to alert authors it is non-conforming while the latter  
> does not.


However, if we introduce @role, would it still matter with no alt 
vs. alt=""?

 
>> Understood. Hence @role. Which I agree is the way to check if
>> fallback is used and used correct for OBJECT and the like.
> 
> In an authoring tool, one can imagine the UI asking for alt text:
> 
> enter alt text: ________


It should ask for role before asking for alt text, in my view.

 
> buttons:
> [cancel/later]
> [decorative/none]
> [illustrative of surrounding text]
> [enter] {enter button enabled only when text if filled in}
> 
> This UI works for either <img alt='fallback'>, <img>fallback</img> or  
> <object>fallbck</object>


Good idea.
-- 
leif halvard silli


From rob at robburns.com  Thu Aug 28 06:17:31 2008
From: rob at robburns.com (Robert J Burns)
Date: Thu, 28 Aug 2008 16:17:31 +0300
Subject: [html4all] XHTML2 and alt
In-Reply-To: <48B5EF66.2070001@malform.no>
References: <F1130EA5-A489-4051-9BCC-11AEE868A972@mac.com>	<48B49410.8010900@malform.no>	<C5F517BB-B276-44C8-A6EB-4F0C85E9CDF7@robburns.com>	<48B5D288.4080903@malform.no>
	<5DAB0F8B-C7AC-44E3-8CC6-EBD1D0B49212@robburns.com>
	<48B5EF66.2070001@malform.no>
Message-ID: <ABA16F0F-5A4B-45A4-9635-BD2307DC56D2@robburns.com>


On Aug 28, 2008, at 3:20 AM, Leif Halvard Silli wrote:

> Robert J Burns 2008-08-28 01.04:
>
>> On Aug 28, 2008, at 1:17 AM, Leif Halvard Silli wrote:
>>> Robert J Burns 2008-08-27 08.52:
>>>> Aug 27, 2008, at 2:38 AM, Leif Halvard Silli:
>
>
>>>>> [ ... @alt (not) in XHTML 2 ... ]
>
>
>>>>> So, do we prefer <IMG> with @alt over the OBJECT/XHTML 2 model,
>>>>> just because presence of @alt is checked in the HTML validator?
>
>   [...]
>
>>> There is also a conflict between using the fallback to explain how
>>> to e.g. load a failing video (think about <video> in HTML 5 in its
>>> current shape and form) and providing real, textual fallback.
>
>   [...]
>
>> I don't think there's a conflict per se. The problem with both VIDEO
>> and AUDIO is that Ian has arbitrarily decided to prohibit the use of
>> the element's contents for textual fallback. The existence of ordered
>> <source> elements within these elements does not prevent other  
>> textual
>> fallback. After all the object element also has param elements that
>> are very similar to source elements. In fact source elements are not
>> really semantically different from <param name='source' value='URI' >
>> (compared with <source src='uri'>.  Yet the object element also
>> supports textual fallback after the param elements. I would like to
>> see the object element also support the source element (along with  
>> the
>> other audio and video element features). Yet all these elements could
>> still support textual fallback.
>
>
> I don't think you explained what I asked. This is my simple issue:
> If the fallback is supposed to play two roles, then the content
> needs to be authored so that the one purpose does not disturb the
> other - either that, or there needs to a mechanism that separate
> the two issues in a userselectable way.

I'm not sure I still understand the question. My thinking is that  
video (or audio), as the highest element in the hierarchy implies that  
the video is the first choice of the author. The source elements  
contained in the element serve as fallback to separate resources each  
serving as a video resource in the order the author prefers. The  
remaining contents of the video serve as the textual (or HTML)  
fallback for the video when none of the video is available, or not  
supported by the UA, or not desired by the user.

For example:

<video>
   <source src='uri1' >
   <source src='uri2' >
   <source src='uri'3 >
   <source src='uri4' >
   <p>Here's some text fallback with even other <img src='uri5'  
alt='image fallback'> non-text media including objects <object  
data='uri6'>some more fallback text</object>..
   </p>
   <source src='uri7' >
</video>

Does that address the question. The UA chooses the first suitable  
resource referenced by a source element in document tree order. If  
none are suitable, it turns to the other contents of the video element  
and renders that.


>>>>> Talking about Karl Dubost's private photo album that he mentioned
>>>>> in the HTMLwg: What would be best, today, for all his thousands of
>>>>> images: <img src=src alt=""> or <img src=src >?
>>>>
>
>>>> I think the best thing would be <img src='src'> and for
>>>> Karl's page to be non-conforming. [...]
>
>
>>> I did not know you were open to making @alt optional? ;-) Would
>>> you have had that idea, if it were not for HTML 5/Ian/WHATwg's
>>> idea that it should be possible to do so?
>>>
>>> The only difference between his and your idea is that he thinks
>>> <img src=src> should be valid. Whereas you think not.
>>
>> Well, yes that's what I thought the whole debate was about. My view  
>> is
>> that making alt required introduces authors to accessibility  
>> issues. I
>> don't even see the downside.
>
>
> Very many sides of the @alt issue have been discussed
> simultaneously, recently. But, no, I did not know that being
> /syntactically/ invalid was one option for you or anyone else.

This goes to the distinction introduced with XML between well-formed  
and invalid. I would not advocate authors ever produce ill-formed  
syntax (though HTML5 does support that). However, I do think that  
validity is of lower importance. It means the document is non- 
conforming, though well-formed. However, adding alt='' to an IMG  
element that should have replacement text is till non-conforming. The  
first case allows authors to easily discover their non-conformance  
problems with software. The latter non-conforming requires a careful  
read by a human of every embedded media element in the document. So  
certainly I prefer the former non-conforming to the latter non- 
conforming (with my authors hat on). But both are non-conforming and  
both are well-formed (but instead not valid).

>>> Yet, at the same time, even Ian says that lack of alt should be
>>> the symbol of something lacking. So how big is the difference?
>>
>> Ian's approach completely removes HTML conformance checking as a
>> mechanism to introduce authors to accessibility issues. Requiring
>> accessibility within HTML5 does introduce authors to accessibility.
>
> At the same time, OBJECT, which is supposed to be superior to
> <img> accessibilitywise, can be completely empty without
> triggering any error.
>
> All the @alt checking in HTML 4 does, is that it introduces the
> /idea/ that <img> can have fallback text.
>
> For <object>, there is no (or less) need to introduce anyone to
> that idea. And, yes, both <object></object> and alt="" can be
> empty, and nothing happens, in the validator.

Except with the role attribute keywords we can now introduce  
recommendations that text be present (and therefore conformance  
checker provide warnings ? but not errors ? when they do not have any  
text)

>>> (Btw, when Laura told Karl that he should be non-conforming, then
>>> I suppose she meant that he should use <img src=src alt="">, as
>>> this would be non-conforming as well.)
>>
>> I understood her as meaning non-conforming in a machine verifiable
>> way: in other words, with the alt attribute omitted.
>
> Karl used the phrase "put alt text".

OK.

>>> I for one, having read Ramans message etc, wonder if an /formally/
>>> optional alt is part of the solution. At the very least I agree
>>> with him that mixing validation with content/accessibilty checking
>>> is problematic.
>>
>> What is the problem? I haven't heard anyone explain what the  
>> problem is.
>
> The problem is that authors do not manage to think about all
> things simultaneously. If ask for HTML syntax errors, then I do
> not want to be told about CSS errors or content/accessibilty errors.
>
> In the case of @alt, the need for validation causes authors to do
> what you say they should not do: Adding empty alt="".

But with role, that will not necessarily help them avoid conformance  
checker messages (either errors, warning or suggestions). The key  
thing ? both for combining CSS, Accessibility, HTML, etc into one  
conformance tool and also prodding authors whenever fallback is  
missing ? is to provide conformance software that allows authors to  
filter, suppress, sort, arrange hierarchically all of the messages  
from the tool.

>
>
>>>>> I think that - in effect - we are spreading the message that <img
>>>>> alt="" ...> would be better than no alt, and also better than <img
>>>>> alt="photo" ...>. I say this not because I think no alt should be
>>>>> permitted, but because, in effect, I think that all we are really
>>>>> defending is a syntax, and not accessibility.
>>>>
>>>> Personally, I want to defend the syntax for its accessibility
>>>> benefits.
>>>
>>> Above you said Karl should have used <img src=src> = no alt.
>>
>> Yes. To produce a non-conforming document that didn't simply add
>> alt='' to pretend to be conforming. Both leaving off the alt  
>> attribute
>> and using alt='' are non-conforming. The former provides a quick way
>> for software to alert authors it is non-conforming while the latter
>> does not.
>
>
> However, if we introduce @role, would it still matter with no alt
> vs. alt=""?

I think it matters less. Plus it solves the problem of <img  
role='keyword' >fallback</img> and <object role='keyword' >fallback</ 
object>

>>> Understood. Hence @role. Which I agree is the way to check if
>>> fallback is used and used correct for OBJECT and the like.
>>
>> In an authoring tool, one can imagine the UI asking for alt text:
>>
>> enter alt text: ________
>
>
> It should ask for role before asking for alt text, in my view.

Yeah, after I did this it occurred to me of using radio buttons  
instead. Combining that with your suggestion:

Role:
             (?) decorative
             (?) illustrative of surrounding text
             (?) other {when other is enabled the following popup and  
input field appear}
                    [ popup: other roles enabled when the other radio  
button is selected ]
                 Alt text:  _________________
  {with a localized hint string depending on the role selected from  
the popup}

[cancel/later/defer] [enter]

with the resulting source:

defer | <img>    <img></img> <object></object> {where the cancel/defer  
button still adds the image but leaves it non-conforming in a machine  
discoverable way }
decorative | <img role='decor'> <img role='decor'></img> <object  
role='decor' ></object>
illustrative of surrounding text | <img role='illustrative'> <img  
role='illustrative'></img> <object role='illustrative ></object>
other role | <img role='<entered role>' alt='<entered fallback>'> <img  
role='<entered role>'  ><entered fallback> </img>
<object role='<entered role>' ><entered fallback></object>

>> This UI works for either <img alt='fallback'>, <img>fallback</img> or
>> <object>fallbck</object>
>
>
> Good idea.

Thanks.

Take care,
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://wilbur.bytowninternet.com/pipermail/list_html4all.org/attachments/20080828/d6b658fe/attachment-0001.html 

From lhs at malform.no  Thu Aug 28 08:33:35 2008
From: lhs at malform.no (Leif Halvard Silli)
Date: Thu, 28 Aug 2008 17:33:35 +0200
Subject: [html4all] XHTML2 and alt
In-Reply-To: <ABA16F0F-5A4B-45A4-9635-BD2307DC56D2@robburns.com>
References: <F1130EA5-A489-4051-9BCC-11AEE868A972@mac.com>	<48B49410.8010900@malform.no>	<C5F517BB-B276-44C8-A6EB-4F0C85E9CDF7@robburns.com>	<48B5D288.4080903@malform.no>	<5DAB0F8B-C7AC-44E3-8CC6-EBD1D0B49212@robburns.com>	<48B5EF66.2070001@malform.no>
	<ABA16F0F-5A4B-45A4-9635-BD2307DC56D2@robburns.com>
Message-ID: <48B6C54F.4040006@malform.no>

Robert J Burns 2008-08-28 15.17:

> Aug 28, 2008, at 3:20 AM, Leif Halvard Silli:


>> I don't think you explained what I asked. This is my simple issue:
>> If the fallback is supposed to play two roles, then the content
>> needs to be authored so that the one purpose does not disturb the
>> other - either that, or there needs to a mechanism that separate
>> the two issues in a userselectable way.
> 
> I'm not sure I still understand the question. My thinking is that video 
> (or audio), as the highest element in the hierarchy implies that the 
> video is the first choice of the author. The source elements contained 
> in the element serve as fallback to separate resources each serving as a 
> video resource in the order the author prefers. 


The <source> element is (planned as) a void element. If it had 
been planned as normal element, then one could have "technical 
fallback" inside the <source></source> element and textual 
fallback directly in the <video></video> element. See more below.

> The remaining contents 
> of the video serve as the textual (or HTML) fallback for the video when 
> none of the video is available, or not supported by the UA, or not 
> desired by the user.
> 
> For example:
> 
> <video>
>   <source src='uri1' >
>   <source src='uri2' >
>   <source src='uri'3 >
>   <source src='uri4' >
>   <p>Here's some text fallback with even other <img src='uri5' 
> alt='image fallback'> non-text media including objects <object 
> data='uri6'>some more fallback text</object>..
>   </p>
>   <source src='uri7' >
> </video>
> 
> Does that address the question. The UA chooses the first suitable 
> resource referenced by a source element in document tree order. If none 
> are suitable, it turns to the other contents of the video element and 
> renders that.


Why did you place the <source src=uri7 > after the fallback?

I don't see that this addressess my question. Because I don't see 
that you discern between technical fallback and media preferencial 
fallback.

But I think that this would:

<video>
<source src=format-a >Fallback: Info about how to see the 
video</source>
<source src=format-b >Fallback: Info about how to see the 
video</source>
<h1>Fallback: Transcript ...
<video>

For the <source src=format-a> and <source src=format-b >, the 
choice between the two would be dependent of what the User Agent 
supports - possibli in interecation with UA preferences that the 
user can regulate.

A text based browser or a screen reader could then go directly to 
the preferred media - the text fallback directly inside <video>.

Thoughts?

>>>>>> Talking about Karl Dubost's private photo album that he mentioned
>>>>>> in the HTMLwg: What would be best, today, for all his thousands of
>>>>>> images: <img src=src alt=""> or <img src=src >?
>>
>>>>> I think the best thing would be <img src='src'> and for
>>>>> Karl's page to be non-conforming. [...]
>>
>>>> I did not know you were open to making @alt optional? ;-) Would
>>>> you have had that idea, if it were not for HTML 5/Ian/WHATwg's
>>>> idea that it should be possible to do so?
>>>>
>>>> The only difference between his and your idea is that he thinks
>>>> <img src=src> should be valid. Whereas you think not.
>>>
>>> Well, yes that's what I thought the whole debate was about. My view is
>>> that making alt required introduces authors to accessibility issues. I
>>> don't even see the downside.
>>
>> Very many sides of the @alt issue have been discussed
>> simultaneously, recently. But, no, I did not know that being
>> /syntactically/ invalid was one option for you or anyone else.
> 
> This goes to the distinction introduced with XML between well-formed and 
> invalid. I would not advocate authors ever produce ill-formed syntax 
> (though HTML5 does support that). However, I do think that validity is 
> of lower importance. It means the document is non-conforming, though 
> well-formed. 


Basically, well-formed = correctly nested.

> However, adding alt='' to an IMG element that should have 
> replacement text is till non-conforming. The first case allows authors 
> to easily discover their non-conformance problems with software. The 
> latter non-conforming requires a careful read by a human of every 
> embedded media element in the document. So certainly I prefer the former 
> non-conforming to the latter non-conforming (with my authors hat on). 
> But both are non-conforming and both are well-formed (but instead not 
> valid).

But as long as <img> is void, lack of well-formedness is no 
problem. If <img> was non-void, however, well-formedness and 
validity would be the same thing, since omitting the end tag would 
make the document both un-well-formed and invalid. Thus it should 
be simpler for authors to handle.

At any rate, the somewhat hard to get difference between 
well-formed, valid and non-conforming does not favour that 
accessibilty is checked together with syntax checkign.

>> All the @alt checking in HTML 4 does, is that it introduces the
>> /idea/ that <img> can have fallback text.
>>
>> For <object>, there is no (or less) need to introduce anyone to
>> that idea. And, yes, both <object></object> and alt="" can be
>> empty, and nothing happens, in the validator.
> 
> Except with the role attribute keywords we can now introduce 
> recommendations that text be present (and therefore conformance checker 
> provide warnings ? but not errors ? when they do not have any text)

Of course. But I had not thought about that errors with regard to 
@role should only provide warnings. However, if evaluating @role 
instead was part of an content/accessibility check, then it could 
create errors.

>>>> (Btw, when Laura told Karl that he should be non-conforming, then
>>>> I suppose she meant that he should use <img src=src alt="">, as
>>>> this would be non-conforming as well.)
>>>
>>> I understood her as meaning non-conforming in a machine verifiable
>>> way: in other words, with the alt attribute omitted.
>>
>> Karl used the phrase "put alt text".
> 
> OK.


In that very exchange in the HTMLwg, I definitely felt there was a 
lack of presiction with regard to what kind of conformance etc one 
talked about.

>>> What is the problem? I haven't heard anyone explain what the problem is.
>>
>> The problem is that authors do not manage to think about all
>> things simultaneously. If ask for HTML syntax errors, then I do
>> not want to be told about CSS errors or content/accessibilty errors.
>>
>> In the case of @alt, the need for validation causes authors to do
>> what you say they should not do: Adding empty alt="".
> 
> But with role, that will not necessarily help them avoid conformance 
> checker messages (either errors, warning or suggestions). The key thing 
> ? both for combining CSS, Accessibility, HTML, etc into one conformance 
> tool and also prodding authors whenever fallback is missing ? is to 
> provide conformance software that allows authors to filter, suppress, 
> sort, arrange hierarchically all of the messages from the tool.


I suppose there is nothing which prevents anyone form making such 
"check-it-all" instrument.

My web browser, iCab, shows both CSS and HTML error 
simultaneously, and connect the errors to the file they appear in. 
Also, when I ask iCab to check the page in the W3 checker tools, 
then it does not only send it to the HTML checker, but also to 
other relevant checkers at W3.

>>>>>> I think that - in effect - we are spreading the message that <img
>>>>>> alt="" ...> would be better than no alt, and also better than <img
>>>>>> alt="photo" ...>. I say this not because I think no alt should be
>>>>>> permitted, but because, in effect, I think that all we are really
>>>>>> defending is a syntax, and not accessibility.
>>>>>
>>>>> Personally, I want to defend the syntax for its accessibility
>>>>> benefits.
>>>>
>>>> Above you said Karl should have used <img src=src> = no alt.
>>>
>>> Yes. To produce a non-conforming document that didn't simply add
>>> alt='' to pretend to be conforming. Both leaving off the alt attribute
>>> and using alt='' are non-conforming. The former provides a quick way
>>> for software to alert authors it is non-conforming while the latter
>>> does not.

The message that non-validity is less serious non-conformance, is 
difficult to sell.

>> However, if we introduce @role, would it still matter with no alt
>> vs. alt=""?
> 
> I think it matters less. Plus it solves the problem of <img 
> role='keyword' >fallback</img> and <object role='keyword' 
>  >fallback</object>

Yup.

>>> In an authoring tool, one can imagine the UI asking for alt text:


>> It should ask for role before asking for alt text, in my view.
> 
> Yeah, after I did this it occurred to me of using radio buttons instead. 
> Combining that with your suggestion:
> 
> Role:
>             (?) decorative
>             (?) illustrative of surrounding text
>             (?) other {when other is enabled the following popup and 
> input field appear}
>                    [ popup: other roles enabled when the other radio 
> button is selected ]
>                 Alt text:  _________________
>  {with a localized hint string depending on the role selected from the 
> popup}
> 
> [cancel/later/defer] [enter]
> 
> with the resulting source:
> 
> defer | <img>    <img></img> <object></object> {where the cancel/defer 
> button still adds the image but leaves it non-conforming in a machine 
> discoverable way }
> decorative | <img role='decor'> <img role='decor'></img> <object 
> role='decor' ></object>
> illustrative of surrounding text | <img role='illustrative'> <img 
> role='illustrative'></img> <object role='illustrative ></object>
> other role | <img role='<entered role>' alt='<entered fallback>'> <img 
> role='<entered role>'  ><entered fallback> </img>
> <object role='<entered role>' ><entered fallback></object>

I think there is much good here. But there are some fundamental 
problems we must solve first ...
-- 
leif halvard sillli


From laura.lee.carlson at gmail.com  Thu Aug 28 09:50:06 2008
From: laura.lee.carlson at gmail.com (Laura Carlson)
Date: Thu, 28 Aug 2008 11:50:06 -0500
Subject: [html4all] Interview: HTML 5 Editor Ian Hickson discusses features,
	pain points, adoption rate, and more
Message-ID: <1c8dbcaa0808280950r24b2b8f5k905d410af9092ca0@mail.gmail.com>

"In this interview, HTML 5 Editor Ian Hickson discusses his favorite
features, the features he thinks might be most contentious, the pain
points he expects HTML 5 will address, and much more. He also tells
what he would change in the original HTML spec if he could go back in
time."

http://blogs.techrepublic.com.com/programming-and-development/?p=718

Best Regards,
Laura
-- 
Laura L. Carlson


From rob at robburns.com  Thu Aug 28 13:03:57 2008
From: rob at robburns.com (Robert J Burns)
Date: Thu, 28 Aug 2008 23:03:57 +0300
Subject: [html4all] XHTML2 and alt
In-Reply-To: <48B6C54F.4040006@malform.no>
References: <F1130EA5-A489-4051-9BCC-11AEE868A972@mac.com>	<48B49410.8010900@malform.no>	<C5F517BB-B276-44C8-A6EB-4F0C85E9CDF7@robburns.com>	<48B5D288.4080903@malform.no>	<5DAB0F8B-C7AC-44E3-8CC6-EBD1D0B49212@robburns.com>	<48B5EF66.2070001@malform.no>
	<ABA16F0F-5A4B-45A4-9635-BD2307DC56D2@robburns.com>
	<48B6C54F.4040006@malform.no>
Message-ID: <DF97C29C-8394-49D2-B06B-EEAA6C36D6BC@robburns.com>

Hi Leif,

On the issue of technical fallback versus media preferential fallback  
versus textual fallback, I fear I'm not understanding you at all. In  
terms of instructions for adding plugins/handlers, I'm fine with the  
UA handling that in a localized fashion (especially since much non- 
text media is inherently internationalized).

On the issue of syntactic errors, I don't think leaving alt off of an  
attribute is a syntax error. It is invalid, but neither a syntax error  
nor a well-formedness error. Basically, I agree with what Al Gilman  
says[1]. A syntax error would be to add an atl attribute (intending to  
add the alt attribute).

Take care,
Rob

[1]: <http://lists.w3.org/Archives/Public/public-html/2008Aug/0871.html>

On Aug 28, 2008, at 6:33 PM, Leif Halvard Silli wrote:

> Robert J Burns 2008-08-28 15.17:
>
>> Aug 28, 2008, at 3:20 AM, Leif Halvard Silli:
>
>
>>> I don't think you explained what I asked. This is my simple issue:
>>> If the fallback is supposed to play two roles, then the content
>>> needs to be authored so that the one purpose does not disturb the
>>> other - either that, or there needs to a mechanism that separate
>>> the two issues in a userselectable way.
>>
>> I'm not sure I still understand the question. My thinking is that  
>> video
>> (or audio), as the highest element in the hierarchy implies that the
>> video is the first choice of the author. The source elements  
>> contained
>> in the element serve as fallback to separate resources each serving  
>> as a
>> video resource in the order the author prefers.
>
>
> The <source> element is (planned as) a void element. If it had
> been planned as normal element, then one could have "technical
> fallback" inside the <source></source> element and textual
> fallback directly in the <video></video> element. See more below.
>
>> The remaining contents
>> of the video serve as the textual (or HTML) fallback for the video  
>> when
>> none of the video is available, or not supported by the UA, or not
>> desired by the user.
>>
>> For example:
>>
>> <video>
>>  <source src='uri1' >
>>  <source src='uri2' >
>>  <source src='uri'3 >
>>  <source src='uri4' >
>>  <p>Here's some text fallback with even other <img src='uri5'
>> alt='image fallback'> non-text media including objects <object
>> data='uri6'>some more fallback text</object>..
>>  </p>
>>  <source src='uri7' >
>> </video>
>>
>> Does that address the question. The UA chooses the first suitable
>> resource referenced by a source element in document tree order. If  
>> none
>> are suitable, it turns to the other contents of the video element and
>> renders that.
>
>
> Why did you place the <source src=uri7 > after the fallback?
>
> I don't see that this addressess my question. Because I don't see
> that you discern between technical fallback and media preferencial
> fallback.
>
> But I think that this would:
>
> <video>
> <source src=format-a >Fallback: Info about how to see the
> video</source>
> <source src=format-b >Fallback: Info about how to see the
> video</source>
> <h1>Fallback: Transcript ...
> <video>
>
> For the <source src=format-a> and <source src=format-b >, the
> choice between the two would be dependent of what the User Agent
> supports - possibli in interecation with UA preferences that the
> user can regulate.
>
> A text based browser or a screen reader could then go directly to
> the preferred media - the text fallback directly inside <video>.
>
> Thoughts?
>
>>>>>>> Talking about Karl Dubost's private photo album that he  
>>>>>>> mentioned
>>>>>>> in the HTMLwg: What would be best, today, for all his  
>>>>>>> thousands of
>>>>>>> images: <img src=src alt=""> or <img src=src >?
>>>
>>>>>> I think the best thing would be <img src='src'> and for
>>>>>> Karl's page to be non-conforming. [...]
>>>
>>>>> I did not know you were open to making @alt optional? ;-) Would
>>>>> you have had that idea, if it were not for HTML 5/Ian/WHATwg's
>>>>> idea that it should be possible to do so?
>>>>>
>>>>> The only difference between his and your idea is that he thinks
>>>>> <img src=src> should be valid. Whereas you think not.
>>>>
>>>> Well, yes that's what I thought the whole debate was about. My  
>>>> view is
>>>> that making alt required introduces authors to accessibility  
>>>> issues. I
>>>> don't even see the downside.
>>>
>>> Very many sides of the @alt issue have been discussed
>>> simultaneously, recently. But, no, I did not know that being
>>> /syntactically/ invalid was one option for you or anyone else.
>>
>> This goes to the distinction introduced with XML between well- 
>> formed and
>> invalid. I would not advocate authors ever produce ill-formed syntax
>> (though HTML5 does support that). However, I do think that validity  
>> is
>> of lower importance. It means the document is non-conforming, though
>> well-formed.
>
>
> Basically, well-formed = correctly nested.
>
>> However, adding alt='' to an IMG element that should have
>> replacement text is till non-conforming. The first case allows  
>> authors
>> to easily discover their non-conformance problems with software. The
>> latter non-conforming requires a careful read by a human of every
>> embedded media element in the document. So certainly I prefer the  
>> former
>> non-conforming to the latter non-conforming (with my authors hat on).
>> But both are non-conforming and both are well-formed (but instead not
>> valid).
>
> But as long as <img> is void, lack of well-formedness is no
> problem. If <img> was non-void, however, well-formedness and
> validity would be the same thing, since omitting the end tag would
> make the document both un-well-formed and invalid. Thus it should
> be simpler for authors to handle.
>
> At any rate, the somewhat hard to get difference between
> well-formed, valid and non-conforming does not favour that
> accessibilty is checked together with syntax checkign.
>
>>> All the @alt checking in HTML 4 does, is that it introduces the
>>> /idea/ that <img> can have fallback text.
>>>
>>> For <object>, there is no (or less) need to introduce anyone to
>>> that idea. And, yes, both <object></object> and alt="" can be
>>> empty, and nothing happens, in the validator.
>>
>> Except with the role attribute keywords we can now introduce
>> recommendations that text be present (and therefore conformance  
>> checker
>> provide warnings ? but not errors ? when they do not have any text)
>
> Of course. But I had not thought about that errors with regard to
> @role should only provide warnings. However, if evaluating @role
> instead was part of an content/accessibility check, then it could
> create errors.
>
>>>>> (Btw, when Laura told Karl that he should be non-conforming, then
>>>>> I suppose she meant that he should use <img src=src alt="">, as
>>>>> this would be non-conforming as well.)
>>>>
>>>> I understood her as meaning non-conforming in a machine verifiable
>>>> way: in other words, with the alt attribute omitted.
>>>
>>> Karl used the phrase "put alt text".
>>
>> OK.
>
>
> In that very exchange in the HTMLwg, I definitely felt there was a
> lack of presiction with regard to what kind of conformance etc one
> talked about.
>
>>>> What is the problem? I haven't heard anyone explain what the  
>>>> problem is.
>>>
>>> The problem is that authors do not manage to think about all
>>> things simultaneously. If ask for HTML syntax errors, then I do
>>> not want to be told about CSS errors or content/accessibilty errors.
>>>
>>> In the case of @alt, the need for validation causes authors to do
>>> what you say they should not do: Adding empty alt="".
>>
>> But with role, that will not necessarily help them avoid conformance
>> checker messages (either errors, warning or suggestions). The key  
>> thing
>> ? both for combining CSS, Accessibility, HTML, etc into one  
>> conformance
>> tool and also prodding authors whenever fallback is missing ? is to
>> provide conformance software that allows authors to filter, suppress,
>> sort, arrange hierarchically all of the messages from the tool.
>
>
> I suppose there is nothing which prevents anyone form making such
> "check-it-all" instrument.
>
> My web browser, iCab, shows both CSS and HTML error
> simultaneously, and connect the errors to the file they appear in.
> Also, when I ask iCab to check the page in the W3 checker tools,
> then it does not only send it to the HTML checker, but also to
> other relevant checkers at W3.
>
>>>>>>> I think that - in effect - we are spreading the message that  
>>>>>>> <img
>>>>>>> alt="" ...> would be better than no alt, and also better than  
>>>>>>> <img
>>>>>>> alt="photo" ...>. I say this not because I think no alt should  
>>>>>>> be
>>>>>>> permitted, but because, in effect, I think that all we are  
>>>>>>> really
>>>>>>> defending is a syntax, and not accessibility.
>>>>>>
>>>>>> Personally, I want to defend the syntax for its accessibility
>>>>>> benefits.
>>>>>
>>>>> Above you said Karl should have used <img src=src> = no alt.
>>>>
>>>> Yes. To produce a non-conforming document that didn't simply add
>>>> alt='' to pretend to be conforming. Both leaving off the alt  
>>>> attribute
>>>> and using alt='' are non-conforming. The former provides a quick  
>>>> way
>>>> for software to alert authors it is non-conforming while the latter
>>>> does not.
>
> The message that non-validity is less serious non-conformance, is
> difficult to sell.
>
>>> However, if we introduce @role, would it still matter with no alt
>>> vs. alt=""?
>>
>> I think it matters less. Plus it solves the problem of <img
>> role='keyword' >fallback</img> and <object role='keyword'
>>> fallback</object>
>
> Yup.
>
>>>> In an authoring tool, one can imagine the UI asking for alt text:
>
>
>>> It should ask for role before asking for alt text, in my view.
>>
>> Yeah, after I did this it occurred to me of using radio buttons  
>> instead.
>> Combining that with your suggestion:
>>
>> Role:
>>            (?) decorative
>>            (?) illustrative of surrounding text
>>            (?) other {when other is enabled the following popup and
>> input field appear}
>>                   [ popup: other roles enabled when the other radio
>> button is selected ]
>>                Alt text:  _________________
>> {with a localized hint string depending on the role selected from the
>> popup}
>>
>> [cancel/later/defer] [enter]
>>
>> with the resulting source:
>>
>> defer | <img>    <img></img> <object></object> {where the cancel/ 
>> defer
>> button still adds the image but leaves it non-conforming in a machine
>> discoverable way }
>> decorative | <img role='decor'> <img role='decor'></img> <object
>> role='decor' ></object>
>> illustrative of surrounding text | <img role='illustrative'> <img
>> role='illustrative'></img> <object role='illustrative ></object>
>> other role | <img role='<entered role>' alt='<entered fallback>'>  
>> <img
>> role='<entered role>'  ><entered fallback> </img>
>> <object role='<entered role>' ><entered fallback></object>
>
> I think there is much good here. But there are some fundamental
> problems we must solve first ...
> -- 
> leif halvard sillli
>
> _______________________________________________
> List_HTML4all.org mailing list
> http://www.html4all.org/wiki
> Archives: http://html4all.org/mailman/private/list_html4all.org/



From lhs at malform.no  Thu Aug 28 14:27:59 2008
From: lhs at malform.no (Leif Halvard Silli)
Date: Thu, 28 Aug 2008 23:27:59 +0200
Subject: [html4all] XHTML2 and alt
In-Reply-To: <DF97C29C-8394-49D2-B06B-EEAA6C36D6BC@robburns.com>
References: <F1130EA5-A489-4051-9BCC-11AEE868A972@mac.com>	<48B49410.8010900@malform.no>	<C5F517BB-B276-44C8-A6EB-4F0C85E9CDF7@robburns.com>	<48B5D288.4080903@malform.no>	<5DAB0F8B-C7AC-44E3-8CC6-EBD1D0B49212@robburns.com>	<48B5EF66.2070001@malform.no>	<ABA16F0F-5A4B-45A4-9635-BD2307DC56D2@robburns.com>	<48B6C54F.4040006@malform.no>
	<DF97C29C-8394-49D2-B06B-EEAA6C36D6BC@robburns.com>
Message-ID: <48B7185F.2060604@malform.no>

Robert J Burns 2008-08-28 22.03:

> On the issue of technical fallback versus media preferential fallback  
> versus textual fallback, I fear I'm not understanding you at all. In  
> terms of instructions for adding plugins/handlers, I'm fine with the  
> UA handling that in a localized fashion (especially since much non- 
> text media is inherently internationalized).

Then read what HTML 5 talks about regarding what kind of fallback 
a user should receive in case it is an old UA which do not 
understand the video element. [For old UAs, there would, I guess, 
be no other way to use the fallback, so one would, in fact, have 
to use the fallback for two purposes.]

But fallback of OBJECT is often used in exactly the same way. 
Which indicates to there is a problem here.

Sure, the UA can explain about lack of video plug-ins and perhaps 
even also provide a direct link to download the video, and may be 
even offer the user to read the fallback. The user would then have 
to indicate that he do not want automatic fallback to the textual 
fallback. But nothing about such behaviour is specified. Which is 
why I try to discuss this.

> On the issue of syntactic errors, I don't think leaving alt off of an  
> attribute is a syntax error. It is invalid, but neither a syntax error  
> nor a well-formedness error.  Basically, I agree with what Al Gilman  

> says[1]. A syntax error would be to add an atl attribute (intending to  
> add the alt attribute).


> [1]: <http://lists.w3.org/Archives/Public/public-html/2008Aug/0871.html>

@alt is required in HTML 4. Many would, like Henri Sivonnen, link 
lack of a required attributes to syntax, especially when the 
attribute is both required *and* can be empty. But I can see that 
this might formally be incorrect.

Also Al links it to syntax, as the first thing he says is that 
lack of @alt would be non-conforming to <quote>The syntax, as well 
as the accessibility guidelines.</quote>

What he further says is that there is no syntactic link between 
"important but an alternative is unavailable" and the lack of 
@alt. If precense of a third attribute or e.g. use of <figure> 
would permit @alt to be dropped, then I guess he would say there 
were a syntactic link.

Hence I think he uses syntax as I have done.
-- 
leif halvard silli



From faulkner.steve at gmail.com  Fri Aug 29 03:33:09 2008
From: faulkner.steve at gmail.com (Steven Faulkner)
Date: Fri, 29 Aug 2008 11:33:09 +0100
Subject: [html4all] @headers issue resolved - allowing a td to be referenced
	by a header to be in the HTMl5 spec.
Message-ID: <55687cf80808290333g44ff1b3et5da6cd963e235e7d@mail.gmail.com>

At yesterdays HTML WG issue tracking telecon [1], the issue of headers
not being allowed to reference a td (in the current version of spec)
was discussed.

It was decided by the Chair (Chris Wilson) after discussion and
consideration of the pros and cons that the current spec should be
changed to allow headers to reference a td element.

 Chris "took action item assigned to josh and will figure out how to
ensure edit gets made in timely fashion" [1]

The action:
"rewrite spec to reinstate id/headers AND their functionality by
specifically stating that headers are allowed to reference a td.
Reword the current definition of the headers attribute so that each of
the space separated tokens must have the value of the ID value of a th
or td element." [2]

This means that the HTML5 spec will contain a method to mark up
complex and irregular data tables accessibly that is well supported by
current AT's.

It is also a positive sign that the W3C process is working within the HTML WG.


[1] http://www.w3.org/2008/08/28-html-wg-minutes.html
[2] http://www.w3.org/html/wg/tracker/actions/72
-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html


From rob at robburns.com  Fri Aug 29 08:27:07 2008
From: rob at robburns.com (Robert J Burns)
Date: Fri, 29 Aug 2008 18:27:07 +0300
Subject: [html4all] Interview: HTML 5 Editor Ian Hickson discusses
	features, pain points, adoption rate, and more
In-Reply-To: <1c8dbcaa0808280950r24b2b8f5k905d410af9092ca0@mail.gmail.com>
References: <1c8dbcaa0808280950r24b2b8f5k905d410af9092ca0@mail.gmail.com>
Message-ID: <AAC69C82-B2D9-4871-8F31-2D476BF82871@robburns.com>

Ian is a strange. From the interview:
<q>

If you could go back in time to the original HTML spec, what is one  
thing that you would change in it to make the Web a better place today?

Defining error handling from day one has got to be the most important  
change that I would ask Tim to make if I could speak to him then. I  
think we could have avoided a huge amount of the tag soup mess we have  
now if we had just defined simple error handling from the get-go.

</q>

Defining error handling from day one would not "avoid" tag soup, it  
just would make the handling of tag soup consistent.

To me, the most damaging decisions of HTML historically were:

  ? allowing P elements to be closed implicitly (we now cannot change  
their content model to allow lists, block quotes and inline tables)
  ? getting away from visual GUI editors (the first HTML editor was  
visual, but it only ran on NextSTEP)
  ? UAs deciding to not support SGML DTDs since that's what prevents  
us from changing anything about the content models

So, of the three, only the first relates to the language itself (and  
wouldn't be a problem except for the following two items). The other  
two are not due to the language. Also with the use of visual GUI  
editors and SGML adherent UAs, the need for error recovery would have  
been much less important.

Take care,
Rob

On Aug 28, 2008, at 7:50 PM, Laura Carlson wrote:

> "In this interview, HTML 5 Editor Ian Hickson discusses his favorite
> features, the features he thinks might be most contentious, the pain
> points he expects HTML 5 will address, and much more. He also tells
> what he would change in the original HTML spec if he could go back in
> time."
>
> http://blogs.techrepublic.com.com/programming-and-development/?p=718
>
> Best Regards,
> Laura
> -- 
> Laura L. Carlson
>
> _______________________________________________
> List_HTML4all.org mailing list
> http://www.html4all.org/wiki
> Archives: http://html4all.org/mailman/private/list_html4all.org/



From lhs at malform.no  Fri Aug 29 14:00:37 2008
From: lhs at malform.no (Leif Halvard Silli)
Date: Fri, 29 Aug 2008 23:00:37 +0200
Subject: [html4all] Interview: HTML 5 Editor Ian Hickson
 discusses	features, pain points, adoption rate, and more
In-Reply-To: <AAC69C82-B2D9-4871-8F31-2D476BF82871@robburns.com>
References: <1c8dbcaa0808280950r24b2b8f5k905d410af9092ca0@mail.gmail.com>
	<AAC69C82-B2D9-4871-8F31-2D476BF82871@robburns.com>
Message-ID: <48B86375.7030203@malform.no>

Robert J Burns 2008-08-29 17.27:

> Defining error handling from day one would not "avoid" tag soup, it  
> just would make the handling of tag soup consistent.


Allow me to disagree. For the record, the 'draconian error 
handeling' of XML is also 'error handeling'. Having such error 
handeling from day one, would  have had something to say.

However, I think that even a more "friendly" error handeling would 
have meant less tag soup. The point, in my view, is that the 
effect of errors should have be predictable.

 
> To me, the most damaging decisions of HTML historically were:
> 
>   ? allowing P elements to be closed implicitly (we now cannot change  
> their content model to allow lists, block quotes and inline tables)


Agree. That said: In quirks-mode both IE and Firefox *do* accept 
e.g. <table> inside the <p>. So, as <!doctype html> was chosen 
because it triggers strict mode, had we chosen something which 
triggered quirks-mode, we likely could have changed content model.

Hence, it seems to me this is more an effect of lack of defined 
error handeling than of the choise of implicit closing.

>   ? getting away from visual GUI editors (the first HTML editor was  
> visual, but it only ran on NextSTEP)


I would rather say that another shortcoming, from the start, was 
lack of microformats. Some WYSIWYG html editors of today are now 
trying to be socalled What-you-see-is-what-you-mean (WYSIWYM) 
editors. However, it is my view that this does not work unless you 
have defined very spesific formats. For instance, LyX, the WYSIWYM 
TeX editor, does not have a WYSIWYM mode for TeX, as such. You 
have to select very spesific document formats, such as letter, 
book, article and so on in order. Likewise I don't think WYSIWYM 
really works for HTML, unless you are spesific of the kind of 
document you are making. (I guess it is also a pity that we did 
not have CSS from the start.)

>   ? UAs deciding to not support SGML DTDs since that's what prevents  
> us from changing anything about the content models
> 
> So, of the three, only the first relates to the language itself (and  
> wouldn't be a problem except for the following two items). The other  
> two are not due to the language. Also with the use of visual GUI  
> editors and SGML adherent UAs, the need for error recovery would have  
> been much less important.

Leif Halvard Silli


From rob at robburns.com  Fri Aug 29 23:48:32 2008
From: rob at robburns.com (Robert J Burns)
Date: Sat, 30 Aug 2008 09:48:32 +0300
Subject: [html4all] Interview: HTML 5 Editor Ian Hickson
	discusses	features, pain points, adoption rate, and more
In-Reply-To: <48B86375.7030203@malform.no>
References: <1c8dbcaa0808280950r24b2b8f5k905d410af9092ca0@mail.gmail.com>
	<AAC69C82-B2D9-4871-8F31-2D476BF82871@robburns.com>
	<48B86375.7030203@malform.no>
Message-ID: <2A6DC3FC-CDBB-4ABF-A9D4-80271E1910D3@robburns.com>

HI Leif,

On Aug 30, 2008, at 12:00 AM, Leif Halvard Silli wrote:

> Robert J Burns 2008-08-29 17.27:
>
>> Defining error handling from day one would not "avoid" tag soup, it
>> just would make the handling of tag soup consistent.
>
>
> Allow me to disagree. For the record, the 'draconian error
> handeling' of XML is also 'error handeling'. Having such error
> handeling from day one, would  have had something to say.

Agree, Certainly draconian error handling for the original HTML would  
have reduced tag soup. However, considering the what Ian and the  
others in WhatWG have to say about XML and its draconian error  
handling, I don't really think that's what Ian meant.

> However, I think that even a more "friendly" error handeling would
> have meant less tag soup. The point, in my view, is that the
> effect of errors should have be predictable.

Certainly having predicable error handling results is a good thing.  
However, if by tag soup we mean syntax errors (including ill- 
formedness and invalid which is how I understand it), then I can't see  
how providing predictable results for errors would reduce errors. If  
anything, it reduces the incentive to produce valid and error-free  
code, because at least one incentive now is consistent handling by  
browsers.

>> To me, the most damaging decisions of HTML historically were:
>>
>>  ? allowing P elements to be closed implicitly (we now cannot change
>> their content model to allow lists, block quotes and inline tables)
>
>
> Agree. That said: In quirks-mode both IE and Firefox *do* accept
> e.g. <table> inside the <p>. So, as <!doctype html> was chosen
> because it triggers strict mode, had we chosen something which
> triggered quirks-mode, we likely could have changed content model.
>
> Hence, it seems to me this is more an effect of lack of defined
> error handeling than of the choise of implicit closing.

The use of table inside P in qurksmode is merely due to the Table  
element not causing the implicit close of P. Certainly if the original  
UL, DL, OL and TABLE elements didn't lead to an implicit P close tag  
(which would be the same as including them in the P element content  
model from the start), then we could add these to the P content model  
(or they would already be there). My point is that the original  
designers were too 'certain' that the P element could be implicitly  
closed: in other words, that they understood the proper content model  
for the element. Unlike the other implicit close tags (TR closes TR,  
LI closes LI, etc), the structure of a paragraph is not as clear cut.  
Even, if they understood the possibility of including Tables, lists,  
and block quotations within a paragraph, there are still other things  
that might be suitable in a paragraph that we cannot predict. And  
considering the close P tag is as short as a close tag gets, it hardly  
seems worth the subsequent trouble (even considering 1990 bandwidth  
constraints).

>>  ? getting away from visual GUI editors (the first HTML editor was
>> visual, but it only ran on NextSTEP)
>
>
> I would rather say that another shortcoming, from the start, was
> lack of microformats

Microformats specifically or semantic extensibility in general? I find  
the microformats methods to be particularly clumsy ways to extend HTML.

> Some WYSIWYG html editors of today are now
> trying to be socalled What-you-see-is-what-you-mean (WYSIWYM)
> editors. However, it is my view that this does not work unless you
> have defined very spesific formats. For instance, LyX, the WYSIWYM
> TeX editor, does not have a WYSIWYM mode for TeX, as such. You
> have to select very spesific document formats, such as letter,
> book, article and so on in order. Likewise I don't think WYSIWYM
> really works for HTML, unless you are spesific of the kind of
> document you are making. (I guess it is also a pity that we did
> not have CSS from the start.)

+1 on the lack of CSS.

It wasn't easy to envision the difference between semantics and  
presentation until we had a functional pure presentation mechanism. On  
the issue of WYSIWYM, I feel quite the opposite. Many of the editing  
tool problems today arise from trying to produce 1980s style WYSIWYG  
editors with an underlying structure that separates presentation from  
semantics (where we see implementors mistakenly trying to defend this  
separation by mapping bold to strong). Authors want to take advantage  
of this separation of concerns and the editing tools need to  
accommodate that.


>>  ? UAs deciding to not support SGML DTDs since that's what prevents
>> us from changing anything about the content models
>>
>> So, of the three, only the first relates to the language itself (and
>> wouldn't be a problem except for the following two items). The other
>> two are not due to the language. Also with the use of visual GUI
>> editors and SGML adherent UAs, the need for error recovery would have
>> been much less important.

Take care,
Rob

From lhs at malform.no  Sat Aug 30 04:07:51 2008
From: lhs at malform.no (Leif Halvard Silli)
Date: Sat, 30 Aug 2008 13:07:51 +0200
Subject: [html4all] Interview: HTML 5 Editor Ian
 Hickson	discusses	features, pain points, adoption rate, and more
In-Reply-To: <2A6DC3FC-CDBB-4ABF-A9D4-80271E1910D3@robburns.com>
References: <1c8dbcaa0808280950r24b2b8f5k905d410af9092ca0@mail.gmail.com>	<AAC69C82-B2D9-4871-8F31-2D476BF82871@robburns.com>	<48B86375.7030203@malform.no>
	<2A6DC3FC-CDBB-4ABF-A9D4-80271E1910D3@robburns.com>
Message-ID: <48B92A07.9070602@malform.no>

Robert J Burns 2008-08-30 08.48:

>> Allow me to disagree. For the record, the 'draconian error
>> handeling' of XML is also 'error handeling'. Having such error
>> handeling from day one, would  have had something to say.
> 
> Agree, Certainly draconian error handling for the original HTML would  
> have reduced tag soup. However, considering the what Ian and the  
> others in WhatWG have to say about XML and its draconian error  
> handling, I don't really think that's what Ian meant.


He only spoke generally. But XML, with its extreme error handeling 
- the 100% opposite of text/html, in a way says the same thing as 
Ian: "There should have been error handeling". :-)

 
>> However, I think that even a more "friendly" error handeling would
>> have meant less tag soup. The point, in my view, is that the
>> effect of errors should have be predictable.
> 
> Certainly having predicable error handling results is a good thing.  
> However, if by tag soup we mean syntax errors (including ill- 
> formedness and invalid which is how I understand it), then I can't see  
> how providing predictable results for errors would reduce errors. If  
> anything, it reduces the incentive to produce valid and error-free  
> code, because at least one incentive now is consistent handling by  
> browsers.


Had it been taken care of from the start, then we could have had a 
much more logical error handeling than we have to define now, when 
one has to take into account what the browsers already accept. 
Defining error handeling is a kind of negative defining of what is 
correct. Hence, I agree with Ian on this.

   [...]

> The use of table inside P in qurksmode is merely due to the Table  
> element not causing the implicit close of P. Certainly if the original  
> UL, DL, OL and TABLE elements didn't lead to an implicit P close tag  
> (which would be the same as including them in the P element content  
> model from the start), then we could add these to the P content model  
> (or they would already be there). My point is that the original  
> designers were too 'certain' that the P element could be implicitly  
> closed: in other words, that they understood the proper content model  
> for the element. Unlike the other implicit close tags (TR closes TR,  
> LI closes LI, etc), the structure of a paragraph is not as clear cut.  
> Even, if they understood the possibility of including Tables, lists,  
> and block quotations within a paragraph, there are still other things  
> that might be suitable in a paragraph that we cannot predict. And  
> considering the close P tag is as short as a close tag gets, it hardly  
> seems worth the subsequent trouble (even considering 1990 bandwidth  
> constraints).


I hope at least those elements you mention /are/ included in the 
<p> model, when HTML 5 is ready ...

 
>>>  ? getting away from visual GUI editors (the first HTML editor was
>>> visual, but it only ran on NextSTEP)
>>
>> I would rather say that another shortcoming, from the start, was
>> lack of microformats
> 
> Microformats specifically or semantic extensibility in general? I find  
> the microformats methods to be particularly clumsy ways to extend HTML.

Well, is microformats a way to extend or use HTML?

>> Some WYSIWYG html editors of today are now
>> trying to be socalled What-you-see-is-what-you-mean (WYSIWYM)
>> editors. However, it is my view that this does not work unless you
>> have defined very spesific formats. [...]


> It wasn't easy to envision the difference between semantics and  
> presentation until we had a functional pure presentation mechanism. On  
> the issue of WYSIWYM, I feel quite the opposite. Many of the editing  
> tool problems today arise from trying to produce 1980s style WYSIWYG  
> editors with an underlying structure that separates presentation from  
> semantics (where we see implementors mistakenly trying to defend this  
> separation by mapping bold to strong). Authors want to take advantage  
> of this separation of concerns and the editing tools need to  
> accommodate that.


On the general level, OK. But the editor must be targetted at the 
spesific document. Only then can WYSIWYM work, I think.
-- 
leif halvard silli


From rob at robburns.com  Sat Aug 30 08:34:11 2008
From: rob at robburns.com (Robert J Burns)
Date: Sat, 30 Aug 2008 18:34:11 +0300
Subject: [html4all] Interview: HTML 5 Editor Ian
	Hickson	discusses	features, pain points, adoption rate, and more
In-Reply-To: <48B92A07.9070602@malform.no>
References: <1c8dbcaa0808280950r24b2b8f5k905d410af9092ca0@mail.gmail.com>	<AAC69C82-B2D9-4871-8F31-2D476BF82871@robburns.com>	<48B86375.7030203@malform.no>
	<2A6DC3FC-CDBB-4ABF-A9D4-80271E1910D3@robburns.com>
	<48B92A07.9070602@malform.no>
Message-ID: <6563235C-A98D-491E-B3EE-7D08501A2726@robburns.com>

Hi Leif,

I'm afraid I'm understanding very little of your responses.

On Aug 30, 2008, at 2:07 PM, Leif Halvard Silli wrote:

> Robert J Burns 2008-08-30 08.48:
>
>>> Allow me to disagree. For the record, the 'draconian error
>>> handeling' of XML is also 'error handeling'. Having such error
>>> handeling from day one, would  have had something to say.
>>
>> Agree, Certainly draconian error handling for the original HTML would
>> have reduced tag soup. However, considering the what Ian and the
>> others in WhatWG have to say about XML and its draconian error
>> handling, I don't really think that's what Ian meant.
>
>
> He only spoke generally. But XML, with its extreme error handeling
> - the 100% opposite of text/html, in a way says the same thing as
> Ian: "There should have been error handeling". :-)

You think Ian is saying there should have been XML-style error  
handling from the beginning? I think that would have been great, but  
that's not the Ian I know.

>>> However, I think that even a more "friendly" error handeling would
>>> have meant less tag soup. The point, in my view, is that the
>>> effect of errors should have be predictable.
>>
>> Certainly having predicable error handling results is a good thing.
>> However, if by tag soup we mean syntax errors (including ill-
>> formedness and invalid which is how I understand it), then I can't  
>> see
>> how providing predictable results for errors would reduce errors. If
>> anything, it reduces the incentive to produce valid and error-free
>> code, because at least one incentive now is consistent handling by
>> browsers.
>
>
> Had it been taken care of from the start, then we could have had a
> much more logical error handeling than we have to define now, when
> one has to take into account what the browsers already accept.
> Defining error handeling is a kind of negative defining of what is
> correct. Hence, I agree with Ian on this.

You (and Ian) must be using 'tag soup' to mean something completely  
different than I defined it. Could you tell me how you're using the  
phrase 'tag soup'?

>   [...]
>
>> The use of table inside P in qurksmode is merely due to the Table
>> element not causing the implicit close of P. Certainly if the  
>> original
>> UL, DL, OL and TABLE elements didn't lead to an implicit P close tag
>> (which would be the same as including them in the P element content
>> model from the start), then we could add these to the P content model
>> (or they would already be there). My point is that the original
>> designers were too 'certain' that the P element could be implicitly
>> closed: in other words, that they understood the proper content model
>> for the element. Unlike the other implicit close tags (TR closes TR,
>> LI closes LI, etc), the structure of a paragraph is not as clear cut.
>> Even, if they understood the possibility of including Tables, lists,
>> and block quotations within a paragraph, there are still other things
>> that might be suitable in a paragraph that we cannot predict. And
>> considering the close P tag is as short as a close tag gets, it  
>> hardly
>> seems worth the subsequent trouble (even considering 1990 bandwidth
>> constraints).
>
>
> I hope at least those elements you mention /are/ included in the
> <p> model, when HTML 5 is ready ...

No, Leif. There won't be any tables, lists or block quotes in the HTML  
paragraph element. They were in the original WG draft lats year (only  
for the XML serialization), but they've now been removed (presumably  
because of Ian's impeccable research and logic).

>>>> ? getting away from visual GUI editors (the first HTML editor was
>>>> visual, but it only ran on NextSTEP)
>>>
>>> I would rather say that another shortcoming, from the start, was
>>> lack of microformats
>>
>> Microformats specifically or semantic extensibility in general? I  
>> find
>> the microformats methods to be particularly clumsy ways to extend  
>> HTML.
>
> Well, is microformats a way to extend or use HTML?

Yes, but not the only way. That's why I was asking you to clarify.

>>> Some WYSIWYG html editors of today are now
>>> trying to be socalled What-you-see-is-what-you-mean (WYSIWYM)
>>> editors. However, it is my view that this does not work unless you
>>> have defined very spesific formats. [...]
>
>
>> It wasn't easy to envision the difference between semantics and
>> presentation until we had a functional pure presentation mechanism.  
>> On
>> the issue of WYSIWYM, I feel quite the opposite. Many of the editing
>> tool problems today arise from trying to produce 1980s style WYSIWYG
>> editors with an underlying structure that separates presentation from
>> semantics (where we see implementors mistakenly trying to defend this
>> separation by mapping bold to strong). Authors want to take advantage
>> of this separation of concerns and the editing tools need to
>> accommodate that.
>
>
> On the general level, OK. But the editor must be targetted at the
> spesific document. Only then can WYSIWYM work, I think.



Again, I don't know what you're saying here. Editors do target  
specific documents.

Take care,
Rob

From lhs at malform.no  Sat Aug 30 11:05:20 2008
From: lhs at malform.no (Leif Halvard Silli)
Date: Sat, 30 Aug 2008 20:05:20 +0200
Subject: [html4all] Interview: HTML 5 Editor
 Ian	Hickson	discusses	features, pain points, adoption rate, and more
In-Reply-To: <6563235C-A98D-491E-B3EE-7D08501A2726@robburns.com>
References: <1c8dbcaa0808280950r24b2b8f5k905d410af9092ca0@mail.gmail.com>	<AAC69C82-B2D9-4871-8F31-2D476BF82871@robburns.com>	<48B86375.7030203@malform.no>	<2A6DC3FC-CDBB-4ABF-A9D4-80271E1910D3@robburns.com>	<48B92A07.9070602@malform.no>
	<6563235C-A98D-491E-B3EE-7D08501A2726@robburns.com>
Message-ID: <48B98BE0.6000603@malform.no>

Robert J Burns 2008-08-30 17.34:
    [...]

> You think Ian is saying there should have been XML-style error  
> handling from the beginning? 


HTML 5 is being defined taking into account history. But in the 
interview he speculated about the past. I imagine that he imagines 
that error handeling, if defined back then, could have differed 
from both XML and HTML 5.

> I think that would have been great, but that's not the Ian I know.


In danger of repeating: XML and Ian agree that HTML should have 
had error handeling from the start. They also agree that this 
would have created less (with XML, theoretically close to zero) 
tag soup. Both also try to answer the challenge from the past. But 
they solve this challenge from the past differently.

>>>> However, I think that even a more "friendly" error handeling would
>>>> have meant less tag soup. The point, in my view, is that the
>>>> effect of errors should have be predictable.

>>>

>>> Certainly having predicable error handling results is a good thing.
>>> However, if by tag soup we mean syntax errors (including ill-
>>> formedness and invalid which is how I understand it), then I can't  
>>> see how providing predictable results for errors would reduce errors.
>>> If anything, it reduces the incentive to produce valid and error-free
>>> code, because at least one incentive now is consistent handling by
>>> browsers.

>>

>> Had it been taken care of from the start, then we could have had a
>> much more logical error handeling than we have to define now, when
>> one has to take into account what the browsers already accept.
>> Defining error handeling is a kind of negative defining of what is
>> correct. Hence, I agree with Ian on this.
> 
> You (and Ian) must be using 'tag soup' to mean something completely  
> different than I defined it. Could you tell me how you're using the  
> phrase 'tag soup'?

XML style errorhandling is draconian, and hence predicable.

Ian's error handeling, as he dreamed it from the start, would not 
be draconian - I think.

Still, if all browsers were required to handle errors and 
exceptions "mildly", but in the same way, then they would not have 
had to invent this handeling by themselves. This would have lead 
to fewer errors being accepted. Unlike today, when some browser 
does it that way, another that way, a third that way - and as a 
result, each browser has to support all the different ways of 
handeling errors, in order to be compatible.

>> I hope at least those elements you mention /are/ included in the
>> <p> model, when HTML 5 is ready ...
> 
> No, Leif. There won't be any tables, lists or block quotes in the HTML  
> paragraph element. They were in the original WG draft lats year (only  
> for the XML serialization), but they've now been removed (presumably  
> because of Ian's impeccable research and logic).


This is of course steps in the wrong direction.

 
>> Well, is microformats a way to extend or use HTML?
> 
> Yes, but not the only way. That's why I was asking you to clarify.


I would call it "using HTML".

 
>> On the general level, OK. But the editor must be targetted at the
>> spesific document. Only then can WYSIWYM work, I think.
> 
> Again, I don't know what you're saying here. Editors do target  
> specific documents.

Specific /types/ of documents.
-- 
leif halvard silli


From rob at robburns.com  Sat Aug 30 12:43:41 2008
From: rob at robburns.com (Robert J Burns)
Date: Sat, 30 Aug 2008 22:43:41 +0300
Subject: [html4all] Interview: HTML 5 Editor
	Ian	Hickson	discusses	features, pain points, adoption rate, and more
In-Reply-To: <48B98BE0.6000603@malform.no>
References: <1c8dbcaa0808280950r24b2b8f5k905d410af9092ca0@mail.gmail.com>	<AAC69C82-B2D9-4871-8F31-2D476BF82871@robburns.com>	<48B86375.7030203@malform.no>	<2A6DC3FC-CDBB-4ABF-A9D4-80271E1910D3@robburns.com>	<48B92A07.9070602@malform.no>
	<6563235C-A98D-491E-B3EE-7D08501A2726@robburns.com>
	<48B98BE0.6000603@malform.no>
Message-ID: <EE69BECF-1416-4BF1-8236-D682119D8C1C@robburns.com>

Hi Leif,

On Aug 30, 2008, at 9:05 PM, Leif Halvard Silli wrote:

> Robert J Burns 2008-08-30 17.34:
>    [...]
>
>> You think Ian is saying there should have been XML-style error
>> handling from the beginning?
>
>
> HTML 5 is being defined taking into account history. But in the
> interview he speculated about the past. I imagine that he imagines
> that error handeling, if defined back then, could have differed
> from both XML and HTML 5.

True, it could differ. But the only error handling that would reduce  
'tag soup' as I'm using the term would be XML style draconian error  
handling. There are other benefits of defined error handling, but  
reducing 'tag soup' is not one of them unless it is draconian error  
handling (again I think you and Ian are using the phrase differently,  
but I haven't figured out how you're using it yet).

>> I think that would have been great, but that's not the Ian I know.
>
> In danger of repeating: XML and Ian agree that HTML should have
> had error handeling from the start. They also agree that this
> would have created less (with XML, theoretically close to zero)
> tag soup. Both also try to answer the challenge from the past. But
> they solve this challenge from the past differently.

Only XML style error handling reduces tag soup. Again, whatever other  
benefits it may have, Ian-style error handling does not reduce 'tag  
soup'.

>>>>> However, I think that even a more "friendly" error handeling would
>>>>> have meant less tag soup. The point, in my view, is that the
>>>>> effect of errors should have be predictable.
>
>>>>
>
>>>> Certainly having predicable error handling results is a good thing.
>>>> However, if by tag soup we mean syntax errors (including ill-
>>>> formedness and invalid which is how I understand it), then I can't
>>>> see how providing predictable results for errors would reduce  
>>>> errors.
>>>> If anything, it reduces the incentive to produce valid and error- 
>>>> free
>>>> code, because at least one incentive now is consistent handling by
>>>> browsers.
>
>>>
>
>>> Had it been taken care of from the start, then we could have had a
>>> much more logical error handeling than we have to define now, when
>>> one has to take into account what the browsers already accept.
>>> Defining error handeling is a kind of negative defining of what is
>>> correct. Hence, I agree with Ian on this.
>>
>> You (and Ian) must be using 'tag soup' to mean something completely
>> different than I defined it. Could you tell me how you're using the
>> phrase 'tag soup'?
>
> XML style errorhandling is draconian, and hence predicable.
>
> Ian's error handeling, as he dreamed it from the start, would not
> be draconian - I think.

So how could it cause a reduction in 'tag soup'?

> Still, if all browsers were required to handle errors and
> exceptions "mildly", but in the same way, then they would not have
> had to invent this handeling by themselves. This would have lead
> to fewer errors being accepted. Unlike today, when some browser
> does it that way, another that way, a third that way - and as a
> result, each browser has to support all the different ways of
> handeling errors, in order to be compatible.

So are you and Ian using the phrase 'tag soup' to describe the various  
ways browser handle errant HTML? The reason XML error handling reduces  
tag soup is that the author is made immediately aware of the errors  
(the soupiness of their tags) even without using a validator or  
conformance checker. Upon seeing their soup they fix it so that they  
can publish their documents. Ian-style error handling, masks the  
errors of the authors (and their authoring tools) from the authors.  
They do not know they are creating tag soup because they test it in  
their browser and it works. With standardized Ian-style error handling  
authors still can't see their errors upon testing in a browser. In  
fact they may test it in a dozen HTML5 browsers and still not see the  
soupiness of their tags. Perhaps you (and Ian) are saying that the  
errors are no longer tag soup because they are handled in a consistent  
manner? So then we have a new distinction (at least new to me):  
conforming documents and errant documents where errant documents can  
be broken down into those containing tag soup and those that don't.  
For example <object>fallback</object data='file.mpeg' > would be a tag  
soup errant document, but <b><i>some bold italics</b></i> would be an  
errant document, with no tag soup. I'm just honestly trying to  
understand how you're using the term tag soup here.

>>> I hope at least those elements you mention /are/ included in the
>>> <p> model, when HTML 5 is ready ...
>>
>> No, Leif. There won't be any tables, lists or block quotes in the  
>> HTML
>> paragraph element. They were in the original WG draft lats year (only
>> for the XML serialization), but they've now been removed (presumably
>> because of Ian's impeccable research and logic).
>
>
> This is of course steps in the wrong direction.

Like so many steps over the last 18 months.

>>> Well, is microformats a way to extend or use HTML?
>>
>> Yes, but not the only way. That's why I was asking you to clarify.
>
> I would call it "using HTML".

Yes, I would too. However, its also using HTML in a way that extends  
the expressiveness and semantics of HTML. If HTML (meaning here  
specifically text/html HTML) supported XML namespaces-like  
extensibility, then using those namespaces for extending HTML would  
also be using HTML. Again, I think the microformats approach is a much  
clumsier way to do extensibility because it stomps over other ways  
authors commonly use HTML.

>>> On the general level, OK. But the editor must be targetted at the
>>> spesific document. Only then can WYSIWYM work, I think.
>>
>> Again, I don't know what you're saying here. Editors do target
>> specific documents.
>
> Specific /types/ of documents.

I'm still not understanding you. Could you list some examples of the  
types of documents you are referring to. I'm thinking of an editor  
that targets specifically an HTML type document, or an XHTML type  
document. However, I can tell here you must be using type in a  
different way.

Take care,
Rob


From lhs at malform.no  Sat Aug 30 14:47:45 2008
From: lhs at malform.no (Leif Halvard Silli)
Date: Sat, 30 Aug 2008 23:47:45 +0200
Subject: [html4all] Interview: HTML 5
 Editor	Ian	Hickson	discusses	features, pain points, adoption rate, and more
In-Reply-To: <EE69BECF-1416-4BF1-8236-D682119D8C1C@robburns.com>
References: <1c8dbcaa0808280950r24b2b8f5k905d410af9092ca0@mail.gmail.com>	<AAC69C82-B2D9-4871-8F31-2D476BF82871@robburns.com>	<48B86375.7030203@malform.no>	<2A6DC3FC-CDBB-4ABF-A9D4-80271E1910D3@robburns.com>	<48B92A07.9070602@malform.no>	<6563235C-A98D-491E-B3EE-7D08501A2726@robburns.com>	<48B98BE0.6000603@malform.no>
	<EE69BECF-1416-4BF1-8236-D682119D8C1C@robburns.com>
Message-ID: <48B9C001.4050302@malform.no>

Robert J Burns 2008-08-30 21.43:


>> [...] error handeling, if defined back then, could have differed
>> from both XML and HTML 5.
> 
> True, it could differ. But the only error handling that would reduce  
> 'tag soup' as I'm using the term would be XML style draconian error  
> handling. There are other benefits of defined error handling, but  
> reducing 'tag soup' is not one of them unless it is draconian error  
> handling (again I think you and Ian are using the phrase differently,  
> but I haven't figured out how you're using it yet).


Syntax errors, you said. That's what I meant as well.

 
>>> I think that would have been great, but that's not the Ian I know.
>>
>> In danger of repeating: XML and Ian agree that HTML should have
>> had error handeling from the start. They also agree that this
>> would have created less (with XML, theoretically close to zero)
>> tag soup. Both also try to answer the challenge from the past. But
>> they solve this challenge from the past differently.
> 
> Only XML style error handling reduces tag soup. Again, whatever other  
> benefits it may have, Ian-style error handling does not reduce 'tag  
> soup'.

First you say "Only XML style error handeling ...". Then you say 
"Ian-style error handling does not ..." Above we agreed that "it 
could differ", from both Ian and XML handling.

Ian-style handling would not have been possible from the start, 
because so many errors have developed until now which we did not 
have from the start!

[...]

> So how could it cause a reduction in 'tag soup'?


Answer:

 
>> Still, if all browsers were required to handle errors and
>> exceptions "mildly", but in the same way, then they would not have
>> had to invent this handeling by themselves. This would have lead
>> to fewer errors being accepted. Unlike today, when some browser
>> does it that way, another that way, a third that way - and as a
>> result, each browser has to support all the different ways of
>> handeling errors, in order to be compatible.
> 
> So are you and Ian using the phrase 'tag soup' to describe the various  
> ways browser handle errant HTML? 


To say "treat something as tag soup" has become synonymous with 
"to parse something as text/html". This, again means parse html 
with the undefined error handeling that has developed over time.

This is not how I used the term, however.

What I said was that the fact that the UAs handle, bless, excuse 
or don't accept tag soup/syntax errors based on a largly common 
but undefined error handling rules, has let many more errors = 
much more tag soup to grow and develop than we would have seen if 
error handling had been defined from the start.

> The reason XML error handling reduces  
> tag soup is that the author is made immediately aware of the errors  
> (the soupiness of their tags) even without using a validator or  
> conformance checker. Upon seeing their soup they fix it so that they  
> can publish their documents. Ian-style error handling, masks the  
> errors of the authors (and their authoring tools) from the authors.  


Do you use 'Ian-style' as a synonym for "the different but 
somewahat similar error handling that all HTML UAs have had to 
develop on their own because it, until now, had not been defined"?

I don think I or anyone else see the problems clearer just because 
you attach name of Ian to it.

> They do not know they are creating tag soup because they test it in  
> their browser and it works. With standardized Ian-style error handling  
> authors still can't see their errors upon testing in a browser.


That very thing is nothing new. The only UA I have used which 
constantly warn about errors is iCab. And that's why I use it.

> In  
> fact they may test it in a dozen HTML5 browsers and still not see the  
> soupiness of their tags. Perhaps you (and Ian) are saying that the  
> errors are no longer tag soup because they are handled in a consistent  
> manner? 


Do I say that the errors are no longer errors because they now are 
handled in a consistent manner? No, of course not.

Again, Ian spoke historically: He predicted a there would have 
been less errors in the HTML code around the globe if error 
handling had been defined from the start.

Let's say we added error handling to HTML 4 *today*, then this 
would not have reduced the number of errors in existing code 
unless UAs as a result started to treat some errors in a way that 
made the designers annoyed. However, for the future, I have hope 
that it could stop the number of errors to grow.

As for HTML 5, yes, it appears to be the case that some things 
that were considered tag soup (aka 'errors') in HTML 4, will 
become "well done" in HTMl 5. But that is a completely other issue.

The crux seems to be that you think that only XML style handling 
can reduce the number of errors. There we disagree. But I may have 
failed to convince you about that ...

> So then we have a new distinction (at least new to me):  
> conforming documents and errant documents where errant documents can  
> be broken down into those containing tag soup and those that don't.  
> For example <object>fallback</object data='file.mpeg' > would be a tag  
> soup errant document, but <b><i>some bold italics</b></i> would be an  
> errant document, with no tag soup. I'm just honestly trying to  
> understand how you're using the term tag soup here.

Ah, yes, true, some link 'tag soup' to the use of <b> and <i> 
instead of <strong> and <em>. I've done so myself, I think. It is 
unclear to me what you mean here, though. If one take the stance 
that <b> and <i> will become forbidden i HTML 5, then using them 
even if they are forbidden, would be an error and thus tag soup, 
which needs defined error handling. The common error handling of 
old tags seems to be to accept them and respect their meaning.

>>>> I hope at least those elements you mention /are/ included in the
>>>> <p> model, when HTML 5 is ready ...
>>>
>>> No, Leif. There won't be any tables, lists or block quotes in the  
>>> HTML paragraph element. They were in the original WG draft lats 
>>> year (only for the XML serialization), but they've now been 
>>> removed (presumably because of Ian's impeccable research and logic).
>>
>> This is of course steps in the wrong direction.
> 
> Like so many steps over the last 18 months.

Indeed.

>>>> Well, is microformats a way to extend or use HTML?
>>>
>>> Yes, but not the only way. That's why I was asking you to clarify.
>>
>> I would call it "using HTML".
> 
> Yes, I would too. However, its also using HTML in a way that extends  
> the expressiveness and semantics of HTML. If HTML (meaning here  
> specifically text/html HTML) supported XML namespaces-like  
> extensibility, then using those namespaces for extending HTML would  
> also be using HTML. Again, I think the microformats approach is a much  
> clumsier way to do extensibility because it stomps over other ways  
> authors commonly use HTML.

OK. But as I said: In LyX you can e.g. opt to write a letter. And 
then you will only be able to add things to that letter which are 
tolerated by that template.

Unfortunately, when someone starts to write a HTML document, then 
it is not given what it should becp,e, what form it should have 
and so on. You have a lot of semantic elements ready to use. But 
how you combine them, is not obvious.

>>>> On the general level, OK. But the editor must be targetted at the
>>>> spesific document. Only then can WYSIWYM work, I think.
>>>
>>> Again, I don't know what you're saying here. Editors do target
>>> specific documents.
>>
>> Specific /types/ of documents.
> 
> I'm still not understanding you. Could you list some examples of the  
> types of documents you are referring to. I'm thinking of an editor  
> that targets specifically an HTML type document, or an XHTML type  
> document. However, I can tell here you must be using type in a  
> different way.

Yes,  I mentioned previously some types: Letter, Article, and so 
on. [Sorry, should explained better but ...] May I ask what course 
you mean that HTML editor should have taken? I don't think you 
meant that one should be hand coding instad of using WYSIWYG
-- 
leif halvard silli


From faulkner.steve at gmail.com  Sat Aug 30 21:00:35 2008
From: faulkner.steve at gmail.com (Steven Faulkner)
Date: Sun, 31 Aug 2008 05:00:35 +0100
Subject: [html4all] @headers issue resolved - allowing a td to be
	referenced by a header to be in the HTML5 spec.
Message-ID: <55687cf80808302100i6c9fafe6q3a663d714f1dff0d@mail.gmail.com>

A few further points in regards to this matter:

1.Allowing a header to reference a td does not preclude the use of an
algorithm which in the majority of cases may obviate the need for the
headers attribute. It merely recognises a mechanism that can provide
the required associations in cases where the algorithm cannot.

2. This issue arose from a bug post [1]. It was escalated to the
Chairs of the HTML WG by the editor "Reassigning to Mike for
arbitration." [2]
It has been decided by Chris Wilson as Chair that a header should be
allowed to reference a td.

So the question is whether the editor will abide by an arbitration
process that he invoked, or because he disagrees with the decision
choose to ignore it?

He has recognised the authority of the chairs to override his authority:

 "Sure, so long as I am editor, the chairs have the authority (and
responsibility) to override me if I make mistakes." [3]

In the case of @headers it would seem that the Chairs have decided the
editor has made a mistake in not allowing it.

But it appears to despite the editor sending the issue to arbitration
and publicly stating that the chairs have authority over what goes
into the spec. The editor will now  ignore the result of the process
he himself  set in motion:

"<Hixie> fwiw my plan with this tables stuff is to do exactly what i
was going to do anyway, which is to get to it when i get to it, and
when i get to it, read all the arguments and research, and come to a
conclusion based on that" [4]

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5822
[2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5822#c14
[3] http://lists.w3.org/Archives/Public/public-html/2008Aug/0599.html
[4] http://krijnhoetmer.nl/irc-logs/whatwg/20080829#l-1284


regards
stevef


From rob at robburns.com  Sun Aug 31 02:35:40 2008
From: rob at robburns.com (Robert J Burns)
Date: Sun, 31 Aug 2008 12:35:40 +0300
Subject: [html4all] Interview: HTML 5
	Editor	Ian	Hickson	discusses	features, pain points,
	adoption rate, and more
In-Reply-To: <48B9C001.4050302@malform.no>
References: <1c8dbcaa0808280950r24b2b8f5k905d410af9092ca0@mail.gmail.com>	<AAC69C82-B2D9-4871-8F31-2D476BF82871@robburns.com>	<48B86375.7030203@malform.no>	<2A6DC3FC-CDBB-4ABF-A9D4-80271E1910D3@robburns.com>	<48B92A07.9070602@malform.no>	<6563235C-A98D-491E-B3EE-7D08501A2726@robburns.com>	<48B98BE0.6000603@malform.no>
	<EE69BECF-1416-4BF1-8236-D682119D8C1C@robburns.com>
	<48B9C001.4050302@malform.no>
Message-ID: <278CEFD3-CB2B-4F7C-ADD0-580AE0199E59@robburns.com>

Hi Leif,

On Aug 31, 2008, at 12:47 AM, Leif Halvard Silli wrote:

> Robert J Burns 2008-08-30 21.43:
>
>
>>> [...] error handeling, if defined back then, could have differed
>>> from both XML and HTML 5.
>>
>>
> First you say "Only XML style error handeling ...". Then you say
> "Ian-style error handling does not ..." Above we agreed that "it
> could differ", from both Ian and XML handling.
>
> Ian-style handling would not have been possible from the start,
> because so many errors have developed until now which we did not
> have from the start!

By Ian-style handling, I'm simply referring to silent (or at least  
pretty quiet) error-recovery. That certainly could have been there  
from the start and in fact was there from very early on. The other  
thing Ian brings to the table now, is an attempt at unambiguously  
specifying the error-handling and hopefully an adoption across UAs of  
that silent error-recovery error-handling. My sense from your iCab  
example is you are talking about error-recovery that is not so silent.  
So perhaps every browser by default would provide some non-modal  
feedback whenever a page has errors. Agree that this is not Ian-style  
nor draconian, but I couldn't tell what you were referring to until  
you brought up iCab. My original point still remains though, that Ian- 
Style (nearly silent error recovery error handling) would not lead to  
less tag soup. Even without specifying the error-recovery, but  
requiring UAs to give the user obvious feedback for errant documents  
would have led to less tag soup, but I still don't see Ian supporting  
something like that.

> [...]
>
>> So how could it cause a reduction in 'tag soup'?
>
>
> Answer:
>
>
>>> Still, if all browsers were required to handle errors and
>>> exceptions "mildly", but in the same way, then they would not have
>>> had to invent this handeling by themselves. This would have lead
>>> to fewer errors being accepted. Unlike today, when some browser
>>> does it that way, another that way, a third that way - and as a
>>> result, each browser has to support all the different ways of
>>> handeling errors, in order to be compatible.
>>
>> So are you and Ian using the phrase 'tag soup' to describe the  
>> various
>> ways browser handle errant HTML?
>
>
> To say "treat something as tag soup" has become synonymous with
> "to parse something as text/html". This, again means parse html
> with the undefined error handeling that has developed over time.
>
> This is not how I used the term, however.

I'm not using it that way either.

> What I said was that the fact that the UAs handle, bless, excuse
> or don't accept tag soup/syntax errors based on a largly common
> but undefined error handling rules, has let many more errors =
> much more tag soup to grow and develop than we would have seen if
> error handling had been defined from the start.

Defining error handling does not do it per se. It is the immediate  
feedback that errors exist across all UAs that would reduce tag soup.  
Again, Ian's contention was that defining error-handling would reduce  
tag soup. However, if you fully define error-handling, but silently  
render the page, then there's no way tag soup will be reduced. So  
specifying error alerts reduces tag soup, but not error-recovery  
(which is what I understand Ian as saying when he says well specified  
error-handling).

>> The reason XML error handling reduces
>> tag soup is that the author is made immediately aware of the errors
>> (the soupiness of their tags) even without using a validator or
>> conformance checker. Upon seeing their soup they fix it so that they
>> can publish their documents. Ian-style error handling, masks the
>> errors of the authors (and their authoring tools) from the authors.
>
> Do you use 'Ian-style' as a synonym for "the different but
> somewahat similar error handling that all HTML UAs have had to
> develop on their own because it, until now, had not been defined"?

Yes, partially. I  am talking about well-defined but silent error  
recovery. For any one given browser the error-recovery is well  
defined. The key thing is that nearly all browsers are silent about  
errors (iCab being a notable exception).

> I don think I or anyone else see the problems clearer just because
> you attach name of Ian to it.

I'm not trying to obscure, I thought from the thread we had  
differentiated these terms.

>> They do not know they are creating tag soup because they test it in
>> their browser and it works. With standardized Ian-style error  
>> handling
>> authors still can't see their errors upon testing in a browser.
>
>
> That very thing is nothing new. The only UA I have used which
> constantly warn about errors is iCab. And that's why I use it.

Again, so its the error feedback that reduces tag soup (which might be  
one part of error-handling), but not error-handling itself: and  
certainly not the type of error handling Ian advocates.

>> In
>> fact they may test it in a dozen HTML5 browsers and still not see the
>> soupiness of their tags. Perhaps you (and Ian) are saying that the
>> errors are no longer tag soup because they are handled in a  
>> consistent
>> manner?
>
>
> Do I say that the errors are no longer errors because they now are
> handled in a consistent manner? No, of course not.
>
> Again, Ian spoke historically: He predicted a there would have
> been less errors in the HTML code around the globe if error
> handling had been defined from the start.

Which is wrong if the error handling doesn't specify obvious error  
notification to users.

> Let's say we added error handling to HTML 4 *today*, then this
> would not have reduced the number of errors in existing code
> unless UAs as a result started to treat some errors in a way that
> made the designers annoyed. However, for the future, I have hope
> that it could stop the number of errors to grow.

Even if we added such error handling to HTML1 (or 2) originally, it  
would not do any good if it didn't annoy authors (and even other users).

> As for HTML 5, yes, it appears to be the case that some things
> that were considered tag soup (aka 'errors') in HTML 4, will
> become "well done" in HTMl 5. But that is a completely other issue.

True, I'm not addressing that in this discussion.

> The crux seems to be that you think that only XML style handling
> can reduce the number of errors. There we disagree. But I may have
> failed to convince you about that ...

No, I agree that iCab style would also reduce tag soup. Again, my view  
is that iCab style error handling is also not something Ian would ever  
support. So going back to my original point, how can Ian say in that  
interview that specifying error handling (in a way that Ian would ever  
support) could ever reduce 'tag soup'.

>> So then we have a new distinction (at least new to me):
>> conforming documents and errant documents where errant documents can
>> be broken down into those containing tag soup and those that don't.
>> For example <object>fallback</object data='file.mpeg' > would be a  
>> tag
>> soup errant document, but <b><i>some bold italics</b></i> would be an
>> errant document, with no tag soup. I'm just honestly trying to
>> understand how you're using the term tag soup here.
>
> Ah, yes, true, some link 'tag soup' to the use of <b> and <i>
> instead of <strong> and <em>. I've done so myself, I think. It is
> unclear to me what you mean here, though. If one take the stance
> that <b> and <i> will become forbidden i HTML 5, then using them
> even if they are forbidden, would be an error and thus tag soup,
> which needs defined error handling. The common error handling of
> old tags seems to be to accept them and respect their meaning.

I'm not talking about distinguishing bold from strong emphasis or  
italics from emphasis. The example <b><i>some bold italics</b></i> is  
ill-formed HTML. It is precisely the type of tag soup that has  
proliferated due to silent error-recovery. Specifying that silent  
error-recovery from the start would have done nothing to reduce such  
errors. On the other hand, no browser had the 'genius' idea of  
applying error-recovery by looking for attributes on closing tags (at  
least not that I'm aware of) so today such errors do not persist,  
because the error is immediately apparent to the author testing in any  
major browser.

To sum up then, error notification (as part of error handling) reduces  
tag soup. However, error handling that is silent ? which is what I  
think Ian means ? does nothing to reduce 'tag soup'. Instead he's  
using the phrase as a sort of name drop. It doesn't even mean anything  
in that sentence, its just meant for the readers to go, "yes...  
mmmm... tag soup, bad. HTML5 must be good. This Ian, smart" On the  
other hand, perhaps Ian thinks if done from the start, XML style  
draconian error handling or iCab style clear notification error  
handling should have been used. But then I wonder why if it was  
possible then, why we can't transition to it now (hint: because  
Microsoft want to undermine W3C recommendations so that its horrible  
and proprietary formats continue to keep them on top).

Take care,
Rob

From jason at jasonjgw.net  Sun Aug 31 03:02:28 2008
From: jason at jasonjgw.net (Jason White)
Date: Sun, 31 Aug 2008 20:02:28 +1000
Subject: [html4all] Interview: HTML 5 Editor Ian Hickson
	discusses	features, pain points, adoption rate, and more
In-Reply-To: <278CEFD3-CB2B-4F7C-ADD0-580AE0199E59@robburns.com>
References: <1c8dbcaa0808280950r24b2b8f5k905d410af9092ca0@mail.gmail.com>
	<AAC69C82-B2D9-4871-8F31-2D476BF82871@robburns.com>
	<48B86375.7030203@malform.no>
	<2A6DC3FC-CDBB-4ABF-A9D4-80271E1910D3@robburns.com>
	<48B92A07.9070602@malform.no>
	<6563235C-A98D-491E-B3EE-7D08501A2726@robburns.com>
	<48B98BE0.6000603@malform.no>
	<EE69BECF-1416-4BF1-8236-D682119D8C1C@robburns.com>
	<48B9C001.4050302@malform.no>
	<278CEFD3-CB2B-4F7C-ADD0-580AE0199E59@robburns.com>
Message-ID: <20080831100228.GA5639@jdc.jasonjgw.net>

My main difficulty with "silent" error recovery, combined with specifying how
the recovery is to be performed, is that it will create a great incentive for
content authors to design errant documents which fail to conform to the spec,
but which are nonetheless processed predictably by conforming implementations.

This is why I have been largely silent, with occasional exceptions on this
list, about the ALT attribute controversy: even if ALT is a required attribute
of IMG and AREA as in HTML 4.01, if HTML 5 then defines error recovery
requirements applicable to a missing ALT attribute, this is tantamount, for
many practical purposes excluding validation, to not requiring ALT altogether.
Yet, one of the driving ideas of the HTML 5 effort has been precisely to
define and codify error recovery, with which doing so in this kind of case
would be entirely consistent. One can even imagine "validators" designed to
test for documents that won't be parsed or rendered predictably (by graphical
UAs) if the HTML 5 error handling requirements are implemented. Obviously,
this is distinct from testing for conformance to the spec, but I can foresee
my hypothesized lower standard of evaluation as becoming the norm, given the
incentive to write erroneous document instances referred to above. In effect,
the error handling becomes the de facto substitute for whatever the "real"
conformance requirements stated in the spec turn out to be.

"Draconian" is merely a pejorative term brought out by those for whom even XML
well-formedness constraints are too much to swallow.

Conversely, of course, if the treatment of non-conforming documents is
"unspecified" or "implementation-defined", there is more of an advantage to be
won by actually caring about conformance, again for many practical purposes of
interest to content authors; and of course, accessibility, among other
considerations, is likely to loose out even more in this retreat.



From rob at robburns.com  Sun Aug 31 04:20:12 2008
From: rob at robburns.com (Robert J Burns)
Date: Sun, 31 Aug 2008 14:20:12 +0300
Subject: [html4all] Interview: HTML 5 Editor Ian Hickson
	discusses	features, pain points, adoption rate, and more
In-Reply-To: <20080831100228.GA5639@jdc.jasonjgw.net>
References: <1c8dbcaa0808280950r24b2b8f5k905d410af9092ca0@mail.gmail.com>
	<AAC69C82-B2D9-4871-8F31-2D476BF82871@robburns.com>
	<48B86375.7030203@malform.no>
	<2A6DC3FC-CDBB-4ABF-A9D4-80271E1910D3@robburns.com>
	<48B92A07.9070602@malform.no>
	<6563235C-A98D-491E-B3EE-7D08501A2726@robburns.com>
	<48B98BE0.6000603@malform.no>
	<EE69BECF-1416-4BF1-8236-D682119D8C1C@robburns.com>
	<48B9C001.4050302@malform.no>
	<278CEFD3-CB2B-4F7C-ADD0-580AE0199E59@robburns.com>
	<20080831100228.GA5639@jdc.jasonjgw.net>
Message-ID: <78125D79-DD5B-4F75-89A3-291C84D0540F@robburns.com>

HI Jason,

On Aug 31, 2008, at 1:02 PM, Jason White wrote:

> My main difficulty with "silent" error recovery, combined with  
> specifying how
> the recovery is to be performed, is that it will create a great  
> incentive for
> content authors to design errant documents which fail to conform to  
> the spec,
> but which are nonetheless processed predictably by conforming  
> implementations.
>
> This is why I have been largely silent, with occasional exceptions  
> on this
> list, about the ALT attribute controversy: even if ALT is a required  
> attribute
> of IMG and AREA as in HTML 4.01, if HTML 5 then defines error recovery
> requirements applicable to a missing ALT attribute, this is  
> tantamount, for
> many practical purposes excluding validation, to not requiring ALT  
> altogether.
> Yet, one of the driving ideas of the HTML 5 effort has been  
> precisely to
> define and codify error recovery, with which doing so in this kind  
> of case
> would be entirely consistent. One can even imagine "validators"  
> designed to
> test for documents that won't be parsed or rendered predictably (by  
> graphical
> UAs) if the HTML 5 error handling requirements are implemented.  
> Obviously,
> this is distinct from testing for conformance to the spec, but I can  
> foresee
> my hypothesized lower standard of evaluation as becoming the norm,  
> given the
> incentive to write erroneous document instances referred to above.  
> In effect,
> the error handling becomes the de facto substitute for whatever the  
> "real"
> conformance requirements stated in the spec turn out to be.

This is also my concern. It also could explain how Ian could make the  
statement he made since for him too, perhaps he's redefining 'tag  
soup' to mean errors not handled by the error recovery. So many well- 
formedness errors are no longer 'tag soup' because they're processed  
with consistent error recovery. Hence we have reduced 'tag soup'  
because 'tag soup' now means only documents with errors that defy even  
the specified error recovery mechanisms (like my <object>fallback</ 
object data='amovie.mpeg' > example). That makes me think that the  
HTML5 recommendation should make it clear that not only should  
implementations follow the parsing algorithm we specify (assuming its  
not the abysmal one in the current draft), but that also  
implementations must not perform any other error recovery not  
specified by HTML5 (otherwise the 'tag soup' drifts onward).

>
>
> "Draconian" is merely a pejorative term brought out by those for  
> whom even XML
> well-formedness constraints are too much to swallow.

Yeah, I guess I should be more careful about using the term draconian.  
I do see it as a pejorative, but I'm also trying to own the term as  
they say. I guess 'strict' or 'fatal' error-handling would be the more  
neutral terms.

> Conversely, of course, if the treatment of non-conforming documents is
> "unspecified" or "implementation-defined", there is more of an  
> advantage to be
> won by actually caring about conformance, again for many practical  
> purposes of
> interest to content authors; and of course, accessibility, among other
> considerations, is likely to loose out even more in this retreat.

Indeed. So to me you've just explained how unspecified error recovery  
led to less 'tag soup' (as I use the phrase) than if error-recovery  
had been originally specified in the way Ian wants to do for HTML5.  
Since the lack of consistent error recovery across browsers led  
authors to turn to validation and the elimination of 'tag soup' to  
ensure consistent processing across browsers.

Take care,
Rob


From lhs at malform.no  Sun Aug 31 11:06:25 2008
From: lhs at malform.no (Leif Halvard Silli)
Date: Sun, 31 Aug 2008 20:06:25 +0200
Subject: [html4all] Interview: HTML
 5	Editor	Ian	Hickson	discusses	features, pain points, adoption rate,
 and more
In-Reply-To: <278CEFD3-CB2B-4F7C-ADD0-580AE0199E59@robburns.com>
References: <1c8dbcaa0808280950r24b2b8f5k905d410af9092ca0@mail.gmail.com>	<AAC69C82-B2D9-4871-8F31-2D476BF82871@robburns.com>	<48B86375.7030203@malform.no>	<2A6DC3FC-CDBB-4ABF-A9D4-80271E1910D3@robburns.com>	<48B92A07.9070602@malform.no>	<6563235C-A98D-491E-B3EE-7D08501A2726@robburns.com>	<48B98BE0.6000603@malform.no>	<EE69BECF-1416-4BF1-8236-D682119D8C1C@robburns.com>	<48B9C001.4050302@malform.no>
	<278CEFD3-CB2B-4F7C-ADD0-580AE0199E59@robburns.com>
Message-ID: <48BADDA1.8000008@malform.no>

Robert J Burns 2008-08-31 11.35:

> Aug 31, 2008, at 12:47 AM, Leif Halvard Silli:


>> Ian-style handling would not have been possible from the start,
>> because so many errors have developed until now which we did not
>> have from the start!
> 
> By Ian-style handling, I'm simply referring to silent (or at least  
> pretty quiet) error-recovery. That certainly could have been there  
> from the start and in fact was there from very early on. The other  
> thing Ian brings to the table now, is an attempt at unambiguously  
> specifying the error-handling and hopefully an adoption across UAs of  
> that silent error-recovery error-handling. My sense from your iCab  
> example is you are talking about error-recovery that is not so silent.  
> So perhaps every browser by default would provide some non-modal  
> feedback whenever a page has errors. Agree that this is not Ian-style  
> nor draconian, but I couldn't tell what you were referring to until  
> you brought up iCab. My original point still remains though, that Ian- 
> Style (nearly silent error recovery error handling) would not lead to  
> less tag soup. Even without specifying the error-recovery, but  
> requiring UAs to give the user obvious feedback for errant documents  
> would have led to less tag soup, but I still don't see Ian supporting  
> something like that.


The Error Log of iCab is simply that: An error log. As such, it is 
merely a tool that every iCab is shipped with. It merely logs all 
errors of a page, and has no effect on page display. For Firefox I 
have seen similar tool(s) as add-on. (I tried one that included 
the Tidy tool once.)

>> What I said was that the fact that the UAs handle, bless, excuse
>> or don't accept tag soup/syntax errors based on a largly common
>> but undefined error handling rules, has let many more errors =
>> much more tag soup to grow and develop than we would have seen if
>> error handling had been defined from the start.
> 
> Defining error handling does not do it per se. It is the immediate  
> feedback that errors exist across all UAs that would reduce tag soup.  
> Again, Ian's contention was that defining error-handling would reduce  
> tag soup. However, if you fully define error-handling, but silently  
> render the page, then there's no way tag soup will be reduced. So  
> specifying error alerts reduces tag soup, but not error-recovery  
> (which is what I understand Ian as saying when he says well specified  
> error-handling).

The  "Yellow screen of death" in XML is a bit too much. And 
perhaps one of the reasons why XHTML pages are served as text/HTML 
anyhow, effectively killing the XML benefit.

In CSS, error handling was cared for from the start. There, unless 
you do it correctly, the CSS command simply has no effect. A 
similar error handling in HTML would have been nice. Let us say 
that wrong nesting, e.g. <b><i>bold italic</b></i>, would lead UAs 
to silently ignore the those tags - treating them as comments.

Something like that could have been possible from the start. But 
it would be difficult to start with something like that now.

>> Do you use 'Ian-style' as a synonym for [...]


> Yes, partially. I  am talking about well-defined but silent error  
> recovery. [...]


>> I don think I or anyone else see the problems clearer just because
>> you attach [the] name of Ian to it.
> 
> I'm not trying to obscure, I thought from the thread we had  
> differentiated these terms.


OK. But it was not very helpful to me.

 
>> That very thing is nothing new. The only UA I have used which
>> constantly warn about errors is iCab. And that's why I use it.
> 
> Again, so its the error feedback that reduces tag soup (which might be  
> one part of error-handling), but not error-handling itself: and  
> certainly not the type of error handling Ian advocates.


Some kind of feedback, yes.

 
>> Again, Ian spoke historically: He predicted a there would have
>> been less errors in the HTML code around the globe if error
>> handling had been defined from the start.
> 
> Which is wrong if the error handling doesn't specify obvious error  
> notification to users.


I think the CSS inspired error handling I mentioned above would 
not hurt users much, even if it would hurt the author.

 
> Even if we added such error handling to HTML1 (or 2) originally, it  
> would not do any good if it didn't annoy authors (and even other users).

It would have to annoy authors in some way, yes.

>> The crux seems to be that you think that only XML style handling
>> can reduce the number of errors. There we disagree. But I may have
>> failed to convince you about that ...
> 
> No, I agree that iCab style would also reduce tag soup. Again, my view  
> is that iCab style error handling is also not something Ian would ever  
> support. So going back to my original point, how can Ian say in that  
> interview that specifying error handling (in a way that Ian would ever  
> support) could ever reduce 'tag soup'.


Because he spoke historically, I think he can.

 
>>> [...] For example <object>fallback</object data='file.mpeg' >   
>>> would be a tag soup errant document, but 
>>> <b><i>some bold italics</b></i> would be an
>>> errant document, with no tag soup. [...]
>>
>> Ah, yes, true, some link 'tag soup' to the use of <b> and <i>
>> instead of <strong> and <em>. [...]
> 
> I'm not talking about distinguishing bold from strong emphasis or  
> italics from emphasis. The example <b><i>some bold italics</b></i> is  
> ill-formed HTML. 


Ah, sorry, was too late in the night when I answered.

> It is precisely the type of tag soup that has  
> proliferated due to silent error-recovery. Specifying that silent  
> error-recovery from the start would have done nothing to reduce such  
> errors. On the other hand, no browser had the 'genius' idea of  
> applying error-recovery by looking for attributes on closing tags (at  
> least not that I'm aware of) so today such errors do not persist,  
> because the error is immediately apparent to the author testing in any  
> major browser.

I will not comment what he has inserted into HTML 5 - the example 
you mention might indeed be a bad example. We should not mix what 
he does with what could have been done.

> To sum up then, error notification (as part of error handling) reduces  
> tag soup. However, error handling that is silent ? which is what I  
> think Ian means ? does nothing to reduce 'tag soup'. Instead he's  
> using the phrase as a sort of name drop. It doesn't even mean anything  
> in that sentence, its just meant for the readers to go, "yes...  
> mmmm... tag soup, bad. HTML5 must be good. This Ian, smart" On the  
> other hand, perhaps Ian thinks if done from the start, XML style  
> draconian error handling or iCab style clear notification error  
> handling should have been used. But then I wonder why if it was  
> possible then, why we can't transition to it now (hint: because  
> Microsoft want to undermine W3C recommendations so that its horrible  
> and proprietary formats continue to keep them on top).

I guess we would have had a more diverse web - with both pure 
XHTML and text/HTML, if IE had supported XML.  As such, this new 
interest for HTML as HTML - which HTML 5 represent, might be seen 
as a result of XHTML failing its promised because of IE. Is that 
what you meant?

But it might also be that this new interest for text/HTML stems 
from a lack of belief in the answer XML gives to HTML's lack of 
error handeling.

But do not for second say that once we say no to Yellow Screen Of 
Death, then the natural answer is always equal to whatever Ian 
comes up with.
-- 
leif halvar silli


From lhs at malform.no  Sun Aug 31 11:56:03 2008
From: lhs at malform.no (Leif Halvard Silli)
Date: Sun, 31 Aug 2008 20:56:03 +0200
Subject: [html4all] Interview: HTML 5 Editor Ian
 Hickson	discusses	features, pain points, adoption rate, and more
In-Reply-To: <78125D79-DD5B-4F75-89A3-291C84D0540F@robburns.com>
References: <1c8dbcaa0808280950r24b2b8f5k905d410af9092ca0@mail.gmail.com>	<AAC69C82-B2D9-4871-8F31-2D476BF82871@robburns.com>	<48B86375.7030203@malform.no>	<2A6DC3FC-CDBB-4ABF-A9D4-80271E1910D3@robburns.com>	<48B92A07.9070602@malform.no>	<6563235C-A98D-491E-B3EE-7D08501A2726@robburns.com>	<48B98BE0.6000603@malform.no>	<EE69BECF-1416-4BF1-8236-D682119D8C1C@robburns.com>	<48B9C001.4050302@malform.no>	<278CEFD3-CB2B-4F7C-ADD0-580AE0199E59@robburns.com>	<20080831100228.GA5639@jdc.jasonjgw.net>
	<78125D79-DD5B-4F75-89A3-291C84D0540F@robburns.com>
Message-ID: <48BAE943.9010908@malform.no>

Robert J Burns 2008-08-31 13.20:

> On Aug 31, 2008, at 1:02 PM, Jason White wrote:
> 

>> My main difficulty with "silent" error recovery, combined
>> with specifying how the recovery is to be performed, is that
>> it will create a great incentive for content authors to
>> design errant documents which fail to conform to

>> the spec, but which are nonetheless processed predictably by
>> conforming implementations.


That it creats a "great incentive" to create non-conforming 
documents sounds like a stretch. For whom such incentive?

>> This is why I have been largely silent, with occasional
>> exceptions on this list, about the ALT attribute controversy:
>> even if ALT is a required attribute of IMG and AREA as in
>> HTML 4.01, if HTML 5 then defines errorrecovery requirements
>> applicable to a missing ALT attribute, this is tantamount,
>> for many practical purposes excluding validation, to not
>> requiring ALT altogether.


I don't get this. Firstly, does HTML 5 define error recovery for 
IMG-s lacking @alt? And what does that recovery look like?

 >> Yet, one of the driving

>> ideas of the HTML 5 effort has been precisely to define and
>> codify error recovery, with which doing so in this kind of
>> case would be entirely consistent. One can even imagine
>> "validators" designed to test for documents that won't be
>> parsed or rendered predictably (by

>> graphical UAs) if the HTML 5 error handling requirements are
>> implemented. Obviously, this is distinct from testing for
>> conformance to the spec, but I can

>> foresee my hypothesized lower standard of evaluation as
>> becoming the norm, given the incentive to write erroneous
>> document instances referred to above. In effect, the error
>> handling becomes the de facto substitute for whatever the

>> "real" conformance requirements stated in the spec turn out
>> to be.


One must pretty geeky in order to be wanting to make such documents.

> This is also my concern. It also could explain how Ian could make the  
> statement he made since for him too, perhaps he's redefining 'tag  
> soup' to mean errors not handled by the error recovery. So many well- 
> formedness errors are no longer 'tag soup' because they're processed  
> with consistent error recovery. Hence we have reduced 'tag soup'  
> because 'tag soup' now means only documents with errors that defy even  
> the specified error recovery mechanisms (like my <object>fallback</ 
> object data='amovie.mpeg' > example). That makes me think that the  
> HTML5 recommendation should make it clear that not only should  
> implementations follow the parsing algorithm we specify (assuming its  
> not the abysmal one in the current draft), but that also  
> implementations must not perform any other error recovery not  
> specified by HTML5 (otherwise the 'tag soup' drifts onward).


You said that <p> will *not* be allowed to contain <table> etc. 
Yet that seems like a modest wish compared with a wish to remove 
what Jason described as a driving idea behind HTML 5.

>> "Draconian" is merely a pejorative term brought out by those for  
>> whom even XML well-formedness constraints are too much to swallow.
> 
> Yeah, I guess I should be more careful about using the term draconian.  
> I do see it as a pejorative, but I'm also trying to own the term as  
> they say. I guess 'strict' or 'fatal' error-handling would be the more  
> neutral terms.

Not sure what is wors from "Ian-style" versus "draconian". And I 
don't think well-formedness is hard to swallow. It is *yellow 
screen of death* which is hard to swallow.

>> Conversely, of course, if the treatment of non-conforming
>> documents is "unspecified" or "implementation-defined", there
>> is more of an advantage to be won by actually caring about
>> conformance, again for many practical  purposes of interest
>> to content authors; and of course, accessibility, among other
>> considerations, is likely to loose out even more in this
>> retreat.


Here you are touching something: I do feel that "the HTML 5 way" 
is taking away incentive to "be good". (To be explained at a later 
point.) But when it comes to accessibility, it doesn't do anything 
good if a nesting error makes the entire document inaccessible. 
Also, even if I in my previous reply suggested that nesting errors 
should make the tags in question be treated as HTML comments, one 
could also say that "making sense" of pretty harmless nesting 
errors such as <strong><span>text</strong></span> would help 
accessiblity.

> Indeed. So to me you've just explained how unspecified error recovery  
> led to less 'tag soup' (as I use the phrase) than if error-recovery  
> had been originally specified in the way Ian wants to do for HTML5.  


We can neither know what Ian would have specified from the start 
nor what error handeling had looked like had it been specified 
from the start by those that specified HTML 1.

Do you and Jason think that either there must be no error handling 
or there must be todays XML-style error handling?

> Since the lack of consistent error recovery across browsers led  
> authors to turn to validation and the elimination of 'tag soup' to  
> ensure consistent processing across browsers.

This works as a pressure in as much that those browsers which do 
not support the standard will be punished for it and/or standards 
adherence attracts users to conforming User Agents.

I see an irony here: At least Firefox and Opera have used "better 
support for standards" as one of the main reasons to choose them. 
But now they are suddenly sawing the branch they sat on by trying 
to specify HTML to look more or less like IE has seen it.

But perhaps that picture was always too simple.
-- 
leif halvard silli