Re: [whatwg] Definition of alt= attribute

2006-01-24 Thread dolphinling

Henri Sivonen wrote:

On Jan 23, 2006, at 18:43, dolphinling wrote:

Second, it could force authoring tools to produce invalid documents  
if the author did not provide any alt text. However, those  documents 
would be non-conformant anyway, so this is not a huge  problem.



It is. Authoring tools are judged by taking a page authored using the  
tool and running it through the W3C Validator or, presumably in the  
future, through an HTML5 conformance checker. Authoring tool makers  who 
are capable of making their tool produce syntactically conforming  
documents will want to do so and minimize the chance that the users  of 
their software tarnish the reputation of the tool in the eyes of  people 
who use an automated test as a litmus test of authoring tool  bogosity. 
(People who test tools that way will outnumber the people  who make a 
more profound analysis due to the validate, validate,  validate 
propaganda.)


File - Save

If you save this page as is, it will be non-valid for the following 
reasons:


You did not specify alternate text for one or more images.

The page will display properly, but will be less accessible to some 
users and will fail automated validation tests.


[Fix errors]  [Save anyway]


...The point being that that would only be a problem to authoring tools 
that didn't do something about it--and frankly, I'd expect an authoring 
tool to give a dialog like that anyway, even if they weren't concerned 
about market share.


--
dolphinling
http://dolphinling.net/


Re: [whatwg] Definition of alt= attribute

2006-01-24 Thread Henri Sivonen

On Jan 24, 2006, at 13:06, dolphinling wrote:


File - Save

If you save this page as is, it will be non-valid for the  
following reasons:


You did not specify alternate text for one or more images.

The page will display properly, but will be less accessible to some  
users and will fail automated validation tests.


[Fix errors]  [Save anyway]


mpt is going to be thrilled. :-)

...The point being that that would only be a problem to authoring  
tools that didn't do something about it--and frankly, I'd expect an  
authoring tool to give a dialog like that anyway, even if they  
weren't concerned about market share.


I don't. And I

--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/




Re: [whatwg] Definition of alt= attribute

2006-01-24 Thread Matthew Paul Thomas

On 24 Jan, 2006, at 5:43 AM, dolphinling wrote:


Matthew Paul Thomas wrote:


Bizarre but serious conclusion: alt= should be optional for img in 
documents where a meta name=generator... element is present.


How about Authoring tools MUST only provide alternate text that the 
author explicitly requests,


That would seem to prevent, for example, Microsoft FrontPage from 
generating the obvious alt text for an Image Composer image that 
consisted only of text sprites. (And since Microsoft continue to 
misimplement the existing spec for alt=, it wouldn't be a good idea to 
trust them to interpret explicitly requests the way you want.)


and especially MUST NOT provide alt= unless the author specifically 
says that the alternate content is empty. Authoring tools SHOULD make 
it obvious to the author what the meaning of alt= is, for example with 
the string What text should be used if the image cannot be 
displayed?


http://slick-net.com/space/stamps/

That example of awful alt= text was apparently made with vi. Would vi 
be violating your SHOULD, for not making the meaning of alt= obvious?



...
Problems with this approach include the following: First, it could be 
interpreted as disallowing pseudo-AI. This could be fixed with a note 
saying This should not be interpreted as disallowing pseudo-AI in 
authoring tools, but even a pseudo-intelligent authoring tool MUST NOT 
assume an empty alt text.


I think that text fails the wtf? test. Does it cover the Image 
Composer example above? Nobody would be able to tell.


Second, it could force authoring tools to produce invalid documents if 
the author did not provide any alt text. However, those documents 
would be non-conformant anyway, so this is not a huge problem.

...


It would be a problem as long as generates valid HTML is considered a 
feature separate from conformance, since software can guarantee the 
former but not the latter. And I don't think anything in an HTML 5 spec 
could prevent validity from being seen as a feature. That's why I 
propose the meta name=generator... exception for compulsory alt=.


--
Matthew Paul Thomas
http://mpt.net.nz/



Re: [whatwg] Definition of alt= attribute

2006-01-21 Thread Alexey Feldgendler
On Sat, 21 Jan 2006 17:25:12 +0600, Matthew Raymond  
[EMAIL PROTECTED] wrote:



   Hmm... Is img ever non-presentational? Radical thought: Deprecate
img.


Why? Aren't there semantic images?

Maybe instead deprecate img for presentational images, leaving it only  
for semantic images (with non-empty alt required).



--
Opera M2 8.5 on Debian Linux 2.6.12-1-k7
* Origin: X-Man's Station [ICQ: 115226275] [EMAIL PROTECTED]


Re: [whatwg] Definition of alt= attribute

2006-01-21 Thread Matthew Raymond
Alexey Feldgendler wrote:
 On Sat, 21 Jan 2006 17:25:12 +0600, Matthew Raymond  
 [EMAIL PROTECTED] wrote:
 
Hmm... Is img ever non-presentational? Radical thought: Deprecate
 img.
 
 Why? Aren't there semantic images?

   Might be. As Anne suggests, a picture of a product might be a good
example. It was more of a question than a serious suggestion.

 Maybe instead deprecate img for presentational images, leaving it only  
 for semantic images (with non-empty alt required).

   Sounds like a good idea. We should probably also consider how
object fits into this, though. Can it completely replace img??? It
certainly has better support for fallback content.


Re: [whatwg] Definition of alt= attribute

2006-01-21 Thread Matthew Raymond
Anne van Kesteren wrote:
 Quoting Matthew Raymond [EMAIL PROTECTED]:
   Hmm... Is img ever non-presentational? Radical thought: Deprecate
 img.
 
 A company logo?

   You could make an argument that trademarks have semantic value, but
it's kinda weak, because you can identify the company by name as well.
Here's some markup:

| h1 style=content: url(logo.png)Company Name/h1

   (Not sure I got the CSS right, but you get the idea.)

 A picture of a new product some review is about?

   Much better example. That probably is semantic, yes.

   However, is there any situation where object couldn't be used
instead of img?


Re: [whatwg] Definition of alt= attribute

2006-01-21 Thread Alexey Feldgendler
On Sat, 21 Jan 2006 18:11:29 +0600, Matthew Raymond  
[EMAIL PROTECTED] wrote:



Maybe instead deprecate img for presentational images, leaving it only
for semantic images (with non-empty alt required).



   Sounds like a good idea. We should probably also consider how
object fits into this, though. Can it completely replace img??? It
certainly has better support for fallback content.


img has one feature that object lacks: to automatically derive its  
dimensions from the downloaded external content. In all other means I  
should say that object looks like a decent replacement for img.



--
Opera M2 8.5 on Debian Linux 2.6.12-1-k7
* Origin: X-Man's Station [ICQ: 115226275] [EMAIL PROTECTED]


Re: [whatwg] Definition of alt= attribute

2006-01-21 Thread James Graham

Henri Sivonen wrote:

On Jan 19, 2006, at 14:05, Anne van Kesteren wrote:


Without the alt attribute img becomes meaningless for devices
(and people) who can not interpreted images.


Good intention, yes, but let's consider the practice:

Suppose there is an authoring tool that has a design goal of always 
outputting conforming (to the extent conformance is machine-assessable) 
documents. This tool allows the user to insert images.


Allowing images to be inserted without prompting for more information 
and also enforcing the presence of a human-supplied alt attribute would 
mean that the tool would have to refuse to save the document until the 
alt texts have been supplied. Refusing to save is not good. Therefore, 
the tool would have to present a document-modal dialog prompting for the 
alt text upon inserting the image.


Sure, some people might even enter some text, but people who just want 
to get on with it would hit return with an empty text box. 
Alternatively, the tool makers could give up the requirement of 
human-supplied alt text and just generate an empty alt text by default 
without asking. (Considering that the tool itself--not just the author 
using it--will be judged by seeing if the output passes an automated 
conformance check, it is likely that the requirement of correct output 
will not be dropped because of the alt issue.)


People seem to have passed this point by. the current specification of 
alt as required makes it almost impossible to design a conforming HTML 
editor that doesn't mess up the semantics of the attribute. Since many 
(the majority?) of HTML pages are produced using some form of graphical 
editor (often implemented using contentEditable or some other HTML+js 
solution as part of a CMS), the spec should at least consider the needs 
of editors as well as UAs.




Re: [whatwg] Definition of alt= attribute

2006-01-21 Thread Jonny Axelsson

On Sat, 21 Jan 2006 13:54:34 +0100, James Graham [EMAIL PROTECTED] wrote:

Henri Sivonen wrote:


Alternatively, the tool makers could give up the requirement of  
human-supplied alt text and just generate an empty alt text by default  
without asking. (Considering that the tool itself--not just the author  
using it--will be judged by seeing if the output passes an automated  
conformance check, it is likely that the requirement of correct output  
will not be dropped because of the alt issue.)


People seem to have passed this point by. the current specification of  
alt as required makes it almost impossible to design a conforming HTML  
editor that doesn't mess up the semantics of the attribute. Since many  
(the majority?) of HTML pages are produced using some form of graphical  
editor (often implemented using contentEditable or some other HTML+js  
solution as part of a CMS), the spec should at least consider the needs  
of editors as well as UAs.


As I have stated before [1], 'spacer' is arguably the element with the  
most semantic information (namely that this element is used for layout  
hacks only and can be ignored for every other purposes), losing  
information when replaced with img src=./spacer.png alt= because the  
UA now doesn't *know* that the image is useless, but can assume so based  
on factors like URL, image dimensions, content, and above all the  
specified empty 'alt' attribute. Going from 'img' to 'object' loses more  
information, to be exact the very 'alt' attribute to separate the useful  
from the useless.


Obviously I don't want the 'spacer' element back, 'spacer' is obsolete  
with CSS if not before. But the loss of information is real. If a UA wants  
to do a best attempt for an 'object' in a context where the object itself  
can't be rendered the UA will know next to nothing about the object. Yes,  
'object' has fallback (which 'img' too could have had if it hadn't been  
defined to be EMPTY) so there is little dispute what to render, but it  
doesn't know what it has missed. Depending on the object and the fallback  
the fact that the preferred content wasn't rendered can be anything from  
inconsequential to critical.


The danger with making an aspect of a markup language mandatory, like the  
mandatory 'alt' attribute for 'img' and the mandatory 'title' element in  
'head' is that the editor/author will need to use filler content that may  
reduce the quality of the attribute/element in question. With 'alt' this  
has the consequence 'alt=' means either that this image has no alternate  
representation (and presumably semantic content) or that it has been  
automatically been filled in to make the document validate. It is fairly  
acceptable, but it would have been better that no 'alt' attribute at all  
had been used in the latter case.



Another datum that is lost from 'img' to 'object' is that the embedded  
object is supposed to be an image, and not e.g. an embedded HTML document,  
an applet or a video. In theory the content type could have given that  
information (text/*, image/*, audio/*...), but the 'type' attribute is  
optional, and in any case the non-informative application type is very  
common.


In this aspect (and not that many other) I like SMIL. In addition to 'ref'  
(the general 'object') it has 'animation', 'audio', 'img' (like HTML),  
'text', 'textstream', and 'video'.


[1] http://my.opera.com/jax/blog/show.dml/83408

--
Jonny Axelsson, Core Technology, Opera Software ASA


Re: [whatwg] Definition of alt= attribute

2006-01-21 Thread Simon Pieters

Hi,

From: Ian Hickson [EMAIL PROTECTED]

I've considered making alt= and omitting alt be conformant equivalents.
I haven't really thought much about it yet though.


Lynx shows the file name if alt= is ommitted. IIRC, HTML 4.0 previously 
recommended that UA's should use the file name if alt is ommitted, so to 
avoid HTML 4.0 compliant UA's using the file name when we want it to be 
empty, I think it is reasonable to require alt when src is present (and vice 
versa).


Using the file name when the alt attribute is ommitted might make sense in 
some cases, such as:


  a href=/img src=home.gif/a

...but not in others, such as:

  img src=spacer.gif

Regards,
Simon Pieters




Re: [whatwg] Definition of alt= attribute

2006-01-20 Thread Matthew Raymond
Alexey Feldgendler wrote:
 This sounds reasonable. I guess I should change my statement:
 
 The alt attrubute should be made optional, and when it's omitted, the UA  
 should try to obtain some useful information from the file name or by  
 other means.

   I'm not sure I agree. If you look at what you might use img for,
it's almost always presentational, and could therefore be done with CSS.
The more semantic the image, the more necessary alternate content
becomes, thus making the |alt| attribute necessary for a truly semantic
img element. If you find yourself using img alt= a lot, it's
probably because you're not making proper use of CSS, or because you're
using img elements to achieve a presentational effect that is
currently not possible with just CSS 2.1 (yet may likely be possible in
CSS 3).


Re: [whatwg] Definition of alt= attribute

2006-01-20 Thread Alexey Feldgendler
On Fri, 20 Jan 2006 16:55:43 +0600, Matthew Raymond  
[EMAIL PROTECTED] wrote:



This sounds reasonable. I guess I should change my statement:

The alt attrubute should be made optional, and when it's omitted, the UA
should try to obtain some useful information from the file name or by
other means.



   I'm not sure I agree. If you look at what you might use img for,
it's almost always presentational, and could therefore be done with CSS.
The more semantic the image, the more necessary alternate content
becomes, thus making the |alt| attribute necessary for a truly semantic
img element. If you find yourself using img alt= a lot, it's
probably because you're not making proper use of CSS, or because you're
using img elements to achieve a presentational effect that is
currently not possible with just CSS 2.1 (yet may likely be possible in
CSS 3).


I'm not speaking about img with specified but empty alt -- this one is  
certainly presentational, and it's OK to require explicit alt= for this  
case. I'm speaking about img with totally omitted alt, which is  
currently invalid. I propose to allow it and have the user agent derive  
some information from the image URL. This will better reflect the real  
world situation: many authors actually omit alt (which results in an  
invalid page) when they actually should have written it.



--
Opera M2 8.5 on Debian Linux 2.6.12-1-k7
* Origin: X-Man's Station [ICQ: 115226275] [EMAIL PROTECTED]


Re: [whatwg] Definition of alt= attribute

2006-01-20 Thread Alexey Feldgendler

On Fri, 20 Jan 2006 21:13:40 +0600, Henri Sivonen [EMAIL PROTECTED] wrote:

The bottom line is that requiring the presence of the alt attribute  
leads to a situation where UAs cannot tell whether the alt text is empty  
because the image is purely decorative or because the author did not  
bother to think about it.


IMO, this leaves the people who don't see the images worse off compared  
to a scenario where an empty alt text signified a purely decorative  
image and a missing alt attribute signified that the author did not  
bother to provide a textual alternative.


Thanks, you expressed what I was trying to say much better than I did.


--
Opera M2 8.5 on Debian Linux 2.6.12-1-k7
* Origin: X-Man's Station [ICQ: 115226275] [EMAIL PROTECTED]


Re: [whatwg] Definition of alt= attribute

2006-01-20 Thread Anne van Kesteren

Quoting Alexey Feldgendler [EMAIL PROTECTED]:
I'm not speaking about img with specified but empty alt -- this one 
is  certainly presentational, and it's OK to require explicit alt= 
for this  case. I'm speaking about img with totally omitted alt, 
which is  currently invalid. I propose to allow it and have the user 
agent derive  some information from the image URL. This will better 
reflect the real  world situation: many authors actually omit alt 
(which results in an  invalid page) when they actually should have 
written it.


HTML5 is not about making the world valid.


--
Anne van Kesteren
http://annevankesteren.nl/



Re: [whatwg] Definition of alt= attribute

2006-01-20 Thread Ian Hickson
On Sat, 21 Jan 2006, Anne van Kesteren wrote:

 Quoting Alexey Feldgendler [EMAIL PROTECTED]:
  I'm not speaking about img with specified but empty alt -- this one is
  certainly presentational, and it's OK to require explicit alt= for this
  case. I'm speaking about img with totally omitted alt, which is  currently
  invalid. I propose to allow it and have the user agent derive  some
  information from the image URL. This will better reflect the real  world
  situation: many authors actually omit alt (which results in an  invalid
  page) when they actually should have written it.
 
 HTML5 is not about making the world valid.

No, but it _is_ about making authoring easier and being realistic.

I've considered making alt= and omitting alt be conformant equivalents. 
I haven't really thought much about it yet though.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


Re: [whatwg] Definition of alt= attribute

2006-01-19 Thread Alexey Feldgendler
On Wed, 18 Jan 2006 18:43:42 +0600, Matthew Paul Thomas  
[EMAIL PROTECTED] wrote:


In HTML 4 alt= is an attribute for img, applet, and input. I can  
think of no reason for input alt= to exist (form alt= would make  
slightly more sense, for non-interactive UAs), and Web Applications 1.0  
currently includes an applets HTMLCollection but no applet element,  
so I've tweaked the text to refer to img elements exclusively. If  
applet is introduced, alt= should be put in a Common attributes  
section, and occurrences of image changed to item.


lipDo not provide alternate text for an image when it is used for  
formatting, decoration, illustration, or linking to a solely graphical  
resource. Instead, use codealt=/code. For example, a portrait of  
someone should usually have codealt=/code, unless either their  
physical appearance or the artwork itself is highly relevant and not  
described elsewhere in the document./p/li

/ul


I wonder why alt is a required attribute for IMG in HTML while an empty  
value is allowed. There are several arguments for making it optional:


1. Many authors still don't specify alt or specify alt= just to make the  
page validate. There's not much sense in requiring an alt when there is a  
way to not specify it (alt=), though it is a spec violation.


2. Empty attributes aren't very XPath friendly (actually, XPath isn't well  
equipped to work with empty attributes).


3. If other elements, such as APPLET, also get the alt attribute, it would  
have to be optional to maintain backward compatibility. It would be  
inconsistent to require alt for IMG and have it optional for APPLET.


Basing on the above points, I propose to relax the requirements and  
defined alt as an optional attribute.



--
Opera M2 8.5 on Debian Linux 2.6.12-1-k7
* Origin: X-Man's Station [ICQ: 115226275] [EMAIL PROTECTED]


Re: [whatwg] Definition of alt= attribute

2006-01-19 Thread Alexey Feldgendler
On Thu, 19 Jan 2006 16:44:29 +0600, Anne van Kesteren  
[EMAIL PROTECTED] wrote:


I wonder why alt is a required attribute for IMG in HTML while an  
empty  value is allowed.


Because an empty value means that there is no alternate text and no  
attribute at
all means that alternate text is missing. (Which is clearly not what you  
want.)


The same could be said about title=, for example:

An empty value means that there is no title, and no attribute at all  
means that the title is missing. But HTML doesn't declare the title  
attribute as required.



--
Opera M2 8.5 on Debian Linux 2.6.12-1-k7
* Origin: X-Man's Station [ICQ: 115226275] [EMAIL PROTECTED]


Re: [whatwg] Definition of alt= attribute

2006-01-19 Thread Jim Ley
On 1/19/06, Anne van Kesteren [EMAIL PROTECTED] wrote:
 Quoting Alexey Feldgendler [EMAIL PROTECTED]:
  I wonder why alt is a required attribute for IMG in HTML while an
  empty  value is allowed.

 Because an empty value means that there is no alternate text and no
 attribute at
 all means that alternate text is missing. (Which is clearly not what
 you want.)

I think Alexey's point is that in a correctly authored page no alt
attribute could perfectly reasonably mean the attribute is empty, this
is a good argument, but one that falls down in reality because so few
pages are correctly authored so those groups needing good ALT are left
at a disservice unless authors co-operate by specifically giving ALT
an empty value.

Jim.


Re: [whatwg] Definition of alt= attribute

2006-01-19 Thread Alexey Feldgendler
On Thu, 19 Jan 2006 18:05:30 +0600, Anne van Kesteren  
[EMAIL PROTECTED] wrote:


That is because the title attribute is not important for the element  
its
_contents_. Without the alt attribute img becomes meaningless for  
devices
(and people) who can not interpreted images. Now I guess that in some  
way no
alt could have been designed to mean that there is no alternative  
content,
but that's not how it is. I believe UAs are free to make up alternate  
content
in such situations. By for example trying to get information from the  
file

name...


This sounds reasonable. I guess I should change my statement:

The alt attrubute should be made optional, and when it's omitted, the UA  
should try to obtain some useful information from the file name or by  
other means.



--
Opera M2 8.5 on Debian Linux 2.6.12-1-k7
* Origin: X-Man's Station [ICQ: 115226275] [EMAIL PROTECTED]