Re: [whatwg] Definition of alt= attribute

[Ian Hickson]

On Sat, 21 Jan 2006, Anne van Kesteren wrote:
>
> Quoting Alexey Feldgendler <[EMAIL PROTECTED]>:
> > I'm not speaking about  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  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

[Anne van Kesteren]

Quoting Alexey Feldgendler <[EMAIL PROTECTED]>:
I'm not speaking about  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  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

Re: [whatwg]

[Daniel Veditz]

Alexey Feldgendler wrote:
> Daniel Veditz <[EMAIL PROTECTED]> wrote:
> 
>> Can't you say the same about cookies? Many people are up in arms about
>> "tracking" and browsers do provide blocking tools, yet the vast majority
>> of people leave them on and very few sites bother to use the old way of
>> tracking state by passing it as URL query parameters.
> 
> That's because on most sites you're unable to log in with cookies
> disabled. On the other hand, a user who has disabled ping="" doesn't
> lose anything.

The sites which really care won't use ping, just as some force you to
enable cookies. Sites could even measure how many people disable ping if
they're worried.

Re: [whatwg] The element and "display: meta"

[Sander Tekelenburg]

At 09:12 -0500 UTC, on 2006-01-17, Matthew Raymond wrote:

> Sander Tekelenburg wrote:
>> At 15:26 -0500 UTC, on 2006-01-10, Matthew Raymond wrote:

[...]

>So what you're saying is that "display: meta" will basically mean
> "not presented in the body".

Well, in the sense that in most browsing situations that would probably be
the consequence of presenting something as meta data, yes.

Remember that the idea is that authors/users can tell a browser to present
certain data in a manner that is consistent across sites. In today's browsers
I think that indeed would only be possible by presenting it outside of the
body, because each site's body is unique and thus cannot offer such
consistency.

> This is not a presentation. It's the
> exclusion of a presentation. It would be like me saying "everything
> outside of that telephone both" is a location. It's not. The "telephone
> both" is a location. "Everything outside" is the entire universe minus
> the telephone both.

Well, I suppose we could choose to instead define a value "chrome" for the
display property. But I think that name doesn't convey the purpose as well.

Also, it just might be that in the future we'll see a browser that works in
ways none of us envision today, allowing it to offer such cross-site
consistent presentation in the body. I'd rather define a value that makes its
purpose clear, than one that assumes a certain environment.

[...]

> What you're talking about is a CSS property value that lets the
> user agent vendor determine the presentation and functionality.

No. Just the presentation.

[...]

>>>   This can be done with new HTML markup.
>>
>> I don't see how. Surely you're not proposing that HTML should start dealing
>> with presentation again?
>
>No. I'm suggesting markup that tells the user agent that certain
> content is intended as list for commands and/or navigation. The user
> agents may do as they see fit with this information.

Ah, I see. Yes, I would agree with that. But I see display:meta as
[1] an addition to that - a way to define in more detail how the user agent
should present it
[2] something that can be useful for more than just navigation menus

[...]

> What happens when you style a non- element as "display: meta"?

The user-agent presents that element's data as if it were meta data.

This might sound like allowing a potential mess, but I think it doesn't have
to. Suppose a user-agent would use a seperate browser window for
display:meta. It could render any content there as it can today; it could be
made easy to find for the user (through a key combination, a menu item,
whatever) and it could ensure consistent presentation across sites by
applying the same dedicated Style Sheet to it always.

[...]

>>>   This, of course, will do nothing for HTML5-compliant browsers that
>>>don't support "display: meta" at all.
>>
>> True. But given that authors cannot rely on CSS support anyway that seems
>> irrelevant to me.
>
>Huh? In that situation, HTML markup would provide a solution, whereas
> CSS would not.

Well, yes, but limited by the fact that HTML only affects structure and
meaning/functionality. CSS can offer additional 'solutions', by affecting
presentation.

[...]

>>> As a result, you essentially
>>>have a CSS property that gives  semantics to other HTML elements.
>>
>> No :) CSS doesn't affect semantics, just presentation.
>
>So you're pretty much making my case for me...

I don't think so. If I understand you correctly, you're saying HTML could
define that user-agents may present NAV in a way that is consistent across
sites, which would in effect result in allowing them to present NAV outside
of the body.

I agree with the semantics/functionality of that, but I think it isn't
complete enough. It's a bit like HTML not specifying what font size must be
used for some element, leaving that up to the user-agent. It's entirely
correct for HTML to not deal with font size, but we *do* want to give authors
and users a mechanism to affect it. Regard display:meta in that light -
offering authors and users a mechanism to affect a presentation, instead of
leaving it entirely up to the user-agent.

So I think we need both. The HTML you propose, and display:meta to give
authors and users a mechanism to affect its presentation. (See also the
conclusion at the end of this message.)

[...]

>> Some apply to block level elements only, some to positioned elements,
>> etc. A CSS spec would only have to define to what sort of elements
>> display:meta applies. Markup languages don't need to be aware of that.
>
>But CSS allows you do define which elements are presented as block or
> inline, so I don't see your point. The properties in that particular
> case are being defined as specific to certain CSS "display" property
> values, not specific elements.

That's true. Thus any element could be set to display:meta, just like any
element can be set to any other value of the display property. I still don't
see how that would

Re: [whatwg]

[Alexey Feldgendler]

On Fri, 20 Jan 2006 23:04:52 +0600, Daniel Veditz <[EMAIL PROTECTED]>  
wrote:


- If people don't want this feature, you'll have to provide a switch to  
turn it off.


- If it can be switched off, websites will use the old, hidden ways to  
track users.



Can't you say the same about cookies? Many people are up in arms about
"tracking" and browsers do provide blocking tools, yet the vast majority
of people leave them on and very few sites bother to use the old way of
tracking state by passing it as URL query parameters.


That's because on most sites you're unable to log in with cookies  
disabled. On the other hand, a user who has disabled ping="" doesn't lose  
anything.




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

Re: [whatwg]

[Daniel Veditz]

Thomas Much wrote:
> - If people don't want this feature, you'll have to provide a switch to turn
> it off.
> 
> - If it can be switched off, websites will use the old, hidden ways to track
> users.

Can't you say the same about cookies? Many people are up in arms about
"tracking" and browsers do provide blocking tools, yet the vast majority
of people leave them on and very few sites bother to use the old way of
tracking state by passing it as URL query parameters.

Re: [whatwg] Definition of alt= attribute

[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

[Henri Sivonen]

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


Without the "alt" attribute  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.)


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.


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

Re: [whatwg] Definition of alt= attribute

[Matthew Paul Thomas]

On 20 Jan, 2006, at 1:18 AM, Alexey Feldgendler wrote:

...
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.

...


Gecko used to do that 
, but no longer does 
because it didn't work for the many cases of  and 
the like. (I can't find where the latter decision was made, but IIRC 
Ian Hickson was the one who made it.)


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

[whatwg] [WF2] Label with empty for attribute

[Simon Pieters]

Hi,

It is not defined what should happen when a label has an empty for="" 
attribute. Consider the following example:


  foo

Is the label element part of the .labels DOM attribute for the input? What 
should the label's .control DOM attribute return?


Regards,
Simon Pieters

Re: [whatwg] Definition of alt= attribute

[Matthew Paul Thomas]

On 19 Jan, 2006, at 1:53 AM, Lachlan Hunt wrote:


Matthew Paul Thomas wrote:


I can think of no reason for 




Ah, of course, I had forgotten about . It would 
have been more obvious to make alt= compulsory where type="image", and 
prohibited otherwise.



(

Why would a form element need alternate content?
...


For non-interactive UAs, rather than non-graphical ones.
*   
*   
I'm not saying it's a *good* idea, just that it would have made more 
sense than allowing alt= for non-image s. :-)


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

Re: [whatwg] Definition of alt= attribute

[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  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
 element. If you find yourself using  a lot, it's
probably because you're not making proper use of CSS, or because you're
using  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  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  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]

[Alexey Feldgendler]

On Fri, 20 Jan 2006 16:52:16 +0600, Thomas Much <[EMAIL PROTECTED]> wrote:


There are two options that lead to the same question:
- If people don't want this feature, you'll have to provide a switch to  
turn it off.
- If it can be switched off, websites will use the old, hidden ways to  
track users.


I think that websites will use the old methods of tracking anyway because  
they can't be sure that the user agent supports ping="".



--
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

[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  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
 element. If you find yourself using  a lot, it's
probably because you're not making proper use of CSS, or because you're
using  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]

[Thomas Much]

am 20.01.2006 0:18 Uhr schrieb James Graham unter [EMAIL PROTECTED]:

> I believe that even browsers significantly more popular than
> iCab allow for this. Yet the vast majority of people leave the feature on.

Maybe because they don't know about referrer security problems and even if
they do they don't know how to turn it off? (How many users know
about:config?)

People felt safe using Firefox, and now someone tells them there's happening
something behind the scenes, "someone's tracking you."  Look at the comments
on MozillaZine and on . Even
if the ping attribute is a clean, open standard for something that has
happend in the dark so far, people are afraid of it. This could become a
marketing problem indeed.

There are two options that lead to the same question:

- If people don't want this feature, you'll have to provide a switch to turn
it off.

- If it can be switched off, websites will use the old, hidden ways to track
users.

What's the benefit of the ping attribute then?

bye, Thomas