Re: [whatwg] DOMTokenList enable

[Ms2ger]

On 08/01/2012 11:07 PM, Erik Arvidsson wrote:

Most JS libraries has a way to add or remove a class name based on a
boolean parameter.

I'm suggesting we add a way to do this to DOMTokenList. The semantics
would be the same as the following pure JS implementation.

DOMTokenList.prototype.enable = function(name, value) {
   value ? this.add(name) : this.remove(name);
};


I filed  to track 
this proposal.


HTH
Ms2ger

[whatwg] DOMTokenList enable

[Erik Arvidsson]

Most JS libraries has a way to add or remove a class name based on a
boolean parameter.

I'm suggesting we add a way to do this to DOMTokenList. The semantics
would be the same as the following pure JS implementation.

DOMTokenList.prototype.enable = function(name, value) {
  value ? this.add(name) : this.remove(name);
};

-- 
erik

Re: [whatwg] alt and title attribute exception

[Steve Faulkner]

Hi Henri,

you wrote:
"Firefox for Android (at least on the Nightly channel) displays the
content of the title attribute on XKCD comics (up to a length limit
which can often be too limiting) upon tap and hold:
http://hsivonen.iki.fi/screen/xkcd-firefox-for-android.png";

that's useful data, too bad about the truncation issue, as I pointed out in
my recent email to the list, that is an issue for both alt/title fallback
on some desktop browsers.

philip wrote:

" it seems unwise to recommend using the title attribute to convey
important information."

The title attribute has sever limitations in its utiltity, if one goal is
to provide accessible content, I detailed some some cases where it should
and should not be used [1]

"Indeed. In addition to image considerations, I think
http://www.whatwg.org/specs/web-apps/current-work/#footnotes is bad
advice."

I agree and have detailed the reasons why [2]

[1] using the HTML title attribute
http://www.paciellogroup.com/blog/2010/11/using-the-html-title-attribute/
[2] http://www.w3.org/html/wg/wiki/ChangeProposals/notitle_annotations

regards
Stevef


> --
>
> Message: 5
> Date: Wed, 1 Aug 2012 15:56:23 +0300
> From: Henri Sivonen 
> To: whatwg 
> Subject: Re: [whatwg] alt and title attribute exception
> Message-ID:
>  cfbqewrvgipvs...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Tue, Jul 31, 2012 at 12:18 PM, Philip J?genstedt 
> wrote:
> > When this was last discussed in the HTML WG (January 2012) I opened a bug
> > (MOBILE-275) for Opera Mobile to expose the title attribute in our
> > long-click menu, arguing that one could not enjoy XKCD without it. I
> meant
> > to report back to the HTML WG but forgot, so here it is. Unfortunately,
> the
> > bug was rejected... quoting the project management:
> >
> > "Sure it is nice to have, but noone else has it so we will not put our
> > effort into this"
>
> Firefox for Android (at least on the Nightly channel) displays the
> content of the title attribute on XKCD comics (up to a length limit
> which can often be too limiting) upon tap and hold:
> http://hsivonen.iki.fi/screen/xkcd-firefox-for-android.png
>
> Not to suggest that XKCD's title usage is OK but just to correct the
> "noone else" bit.
>
> > it seems unwise to recommend using the title attribute to convey
> important information.
>
> Indeed. In addition to image considerations, I think
> http://www.whatwg.org/specs/web-apps/current-work/#footnotes is bad
> advice.
>
> --
> Henri Sivonen
> hsivo...@iki.fi
> http://hsivonen.iki.fi/
>
>
>

Re: [whatwg] alt and title attribute exception

[Steve Faulkner]

Hi leif,
you wrote:

> [I suppose 'the spec' means the W3 HTML5 spec?]

no, i believe we are discussing what's in  HTML living standard.

regards
SteveF

Philip Jägenstedt Wed Aug 1 05:05:15 PDT 2012:
> On Tue, 31 Jul 2012 14:03:02 +0200, Steve Faulkner wrote:
>
>> title has differing semantics to alt. In situations where alt it not
>> present on an img but title is, in webkit based browsers the title
>> attribute content is displayed on mouse hover and is also displayed in
>> place of the image when images are disabled or not available. This
>> implementation appears to contradict the must requirement in the spec.
>>
>> User agents must not present the contents of the alt attribute in the
>> same way as content of the title attribute.
>>
>> As there is no way visual distinction between title content being
>> displayed and of alt content in this case.
>
> To be very clear, you agree with the spec, think that WebKit is wrong and
> would not offer any applause if Opera were to use the title attribute to
> replace images when images are disabled and there is no alt attribute?

[I suppose 'the spec' means the W3 HTML5 spec?]

Question: I would be rather simple for Opera, would it not, to add some
CSS that makes the @title be used as @alt replacement when the @alt is
lacking?
-- 
leif halvard silli

Re: [whatwg] alt and title attribute exception

[Steve Faulkner]

Hi Philip,

you wrote:

"To be very clear, you agree with the spec, think that WebKit is wrong and
would not offer any applause if Opera were to use the title attribute to
replace images when images are disabled and there is no alt attribute?"

I don't have a strong view on the display of title content as fallback when
alt is absent. It would be preferable to disambigaute the source of the
text by (for example) prefixing the text with "title:". What browsers
provide as fallback in the absence of the appropriate content is a
different beast than the question of what we should promote as a conforming
markup pattern.

I do think that if browsers provide a single feature (title) to provide
tooltip text and image fallback text (which is what we are talking about),
coupled with giving authors the greenlight via the current conformance free
pass, it will lead to its use and misuse, which is why the must level
requirement on browsers not to display alt in the same way as title was
included in the first place AFAIK - To deter browsers from displaying alt
both as fallback and tooltip.I do not see a difference between alt being
displayed as both fallback and tooltip and title being displayed as both
fallback and tooltip. If someone can explain to me why one is good but the
other is not, I would be appreciative.


you wrote:

"Yes, the semantic difference is clear. What I wanted to add to this
discussion is confirmation that the title attribute is inaccessibly to
mobile browser users and likely to remain so. I don't know what conclusions
to draw or what the spec should say, but to me it seems unwise to use the
title attribute at all..."

Well this is what I brought up in the other fora that this issue is/was
debated. The (almost) complete lack of display of title in mobile browsers.

Henri's example of firefox on android is interesting , but of only limited
utility since the text is truncated, the same issue occurs (truncation) for
both alt and title on in various browsers, in some browsers the alt/title
is omitted completely if the text is longer than a certain value [1]

regards
SteveF

[1] http://www.paciellogroup.com/blog/misc/HTML5/alt-tests/screenshots.html

On 1 August 2012 13:05, Philip Jägenstedt  wrote:

> On Tue, 31 Jul 2012 14:03:02 +0200, Steve Faulkner <
> faulkner.st...@gmail.com> wrote:
>
>  title has differing semantics to alt. In situations where alt it not
>> present on an img but title is, in webkit based browsers the title
>> attribute content is displayed on mouse hover and is also displayed in
>> place of the image when images are disabled or not available. This
>> implementation appears to contradict the must requirement in the spec.
>>
>> User agents must not present the contents of the alt attribute in the same
>>
>>> way as content of the title attribute.
>>>
>>>
>> As there is no way visual distinction between title content being
>> displayed
>> and of alt content in this case.
>>
>
> To be very clear, you agree with the spec, think that WebKit is wrong and
> would not offer any applause if Opera were to use the title attribute to
> replace images when images are disabled and there is no alt attribute?
>
>  you wrote:
>>
>>  but I'm confused -- is falling back to title a Good Thing that people
>>> want
>>>
>> browsers to implement, or is it just a quirk that some legacy browser had?
>>
>> Given that there is a semantic distinction in the spec between what alt
>> content is and what title content is and a swathe of normative
>> requirements/advice based on this distinction it would appear unwise to
>> promote the use of title as fallback without providing normative
>> requirements on provision of a method to distinguish between the two.
>>
>> *Note:* in terms of the accessible name calculation for an img element, if
>>
>> the image does not have aria-label or an aria-labelledby or an alt
>> attribute, but does have a title attribute, then the title attribute is
>> used as the accessible name. From an accessibility API perspective, no
>> distinction is indicated as to the source of the accessible name (apart
>> from in the Mac AX API).
>>
>> The last point is another reason why making the title attribute on images
>> (without alt) conforming is that the semantics, for all users, are
>> ambiguous.
>>
>
> Yes, the semantic difference is clear. What I wanted to add to this
> discussion is confirmation that the title attribute is inaccessibly to
> mobile browser users and likely to remain so. I don't know what conclusions
> to draw or what the spec should say, but to me it seems unwise to use the
> title attribute at all...
>
>
> --
> Philip Jägenstedt
> Core Developer
> Opera Software
>

Re: [whatwg] allowfullscreen vs sandbox="allow-fullscreen", and mimicking for pointer lock

[Vincent Scheib]

Thank you Adam, ROC, Anne. I commented on issue.


On Wed, Aug 1, 2012 at 2:05 AM, Anne van Kesteren  wrote:

> On Wed, Aug 1, 2012 at 11:04 AM, Anne van Kesteren 
> wrote:
> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=17838
> >
> > I did not want to define new HTML features in a separate draft.
>
> So Vincent, if you want to argue for a different design, that bug
> would be the place I think. I do not really care either way, I just
> went with what roc came up with.
>
>
> --
> http://annevankesteren.nl/
>

Re: [whatwg] alt and title attribute exception

[Leif Halvard Silli]

Philip Jägenstedt Wed Aug 1 05:05:15 PDT 2012:
> On Tue, 31 Jul 2012 14:03:02 +0200, Steve Faulkner wrote:
> 
>> title has differing semantics to alt. In situations where alt it not
>> present on an img but title is, in webkit based browsers the title
>> attribute content is displayed on mouse hover and is also displayed in
>> place of the image when images are disabled or not available. This
>> implementation appears to contradict the must requirement in the spec.
>>
>> User agents must not present the contents of the alt attribute in the  
>> same way as content of the title attribute.
>>
>> As there is no way visual distinction between title content being  
>> displayed and of alt content in this case.
> 
> To be very clear, you agree with the spec, think that WebKit is wrong and  
> would not offer any applause if Opera were to use the title attribute to  
> replace images when images are disabled and there is no alt attribute?

[I suppose 'the spec' means the W3 HTML5 spec?] 

Question: I would be rather simple for Opera, would it not, to add some 
CSS that makes the @title be used as @alt replacement when the @alt is 
lacking?
-- 
leif halvard silli

Re: [whatwg] alt and title attribute exception

[Philip Jägenstedt]

On Wed, 01 Aug 2012 14:56:23 +0200, Henri Sivonen  wrote:

On Tue, Jul 31, 2012 at 12:18 PM, Philip Jägenstedt   
wrote:
When this was last discussed in the HTML WG (January 2012) I opened a  
bug

(MOBILE-275) for Opera Mobile to expose the title attribute in our
long-click menu, arguing that one could not enjoy XKCD without it. I  
meant
to report back to the HTML WG but forgot, so here it is. Unfortunately,  
the

bug was rejected... quoting the project management:

"Sure it is nice to have, but noone else has it so we will not put our
effort into this"


Firefox for Android (at least on the Nightly channel) displays the
content of the title attribute on XKCD comics (up to a length limit
which can often be too limiting) upon tap and hold:
http://hsivonen.iki.fi/screen/xkcd-firefox-for-android.png

Not to suggest that XKCD's title usage is OK but just to correct the
"noone else" bit.


Thanks for pointing this out, either we did poor research or this is a new  
feature. In any case, I'll forward this information to our internal bug.  
Opera's context menus are a bit smaller than that, so I don't think adding  
a few paragraphs of text at the top of them would work.


it seems unwise to recommend using the title attribute to convey  
important information.


Indeed. In addition to image considerations, I think
http://www.whatwg.org/specs/web-apps/current-work/#footnotes is bad
advice.


Yeah, that looks like a pretty bad idea, even for sighted users on desktop  
browsers, unless you also add span[title] { border-bottom: 1px dotted  
black; } or similar to your CSS to make it more discoverable. Removing  
that advice seems like a good idea.


--
Philip Jägenstedt
Core Developer
Opera Software

Re: [whatwg] alt and title attribute exception

[Henri Sivonen]

On Tue, Jul 31, 2012 at 12:18 PM, Philip Jägenstedt  wrote:
> When this was last discussed in the HTML WG (January 2012) I opened a bug
> (MOBILE-275) for Opera Mobile to expose the title attribute in our
> long-click menu, arguing that one could not enjoy XKCD without it. I meant
> to report back to the HTML WG but forgot, so here it is. Unfortunately, the
> bug was rejected... quoting the project management:
>
> "Sure it is nice to have, but noone else has it so we will not put our
> effort into this"

Firefox for Android (at least on the Nightly channel) displays the
content of the title attribute on XKCD comics (up to a length limit
which can often be too limiting) upon tap and hold:
http://hsivonen.iki.fi/screen/xkcd-firefox-for-android.png

Not to suggest that XKCD's title usage is OK but just to correct the
"noone else" bit.

> it seems unwise to recommend using the title attribute to convey important 
> information.

Indeed. In addition to image considerations, I think
http://www.whatwg.org/specs/web-apps/current-work/#footnotes is bad
advice.

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [whatwg] alt and title attribute exception

[Philip Jägenstedt]

On Tue, 31 Jul 2012 14:03:02 +0200, Steve Faulkner  
 wrote:



title has differing semantics to alt. In situations where alt it not
present on an img but title is, in webkit based browsers the title
attribute content is displayed on mouse hover and is also displayed in
place of the image when images are disabled or not available. This
implementation appears to contradict the must requirement in the spec.

User agents must not present the contents of the alt attribute in the  
same

way as content of the title attribute.



As there is no way visual distinction between title content being  
displayed

and of alt content in this case.


To be very clear, you agree with the spec, think that WebKit is wrong and  
would not offer any applause if Opera were to use the title attribute to  
replace images when images are disabled and there is no alt attribute?



you wrote:

but I'm confused -- is falling back to title a Good Thing that people  
want
browsers to implement, or is it just a quirk that some legacy browser  
had?


Given that there is a semantic distinction in the spec between what alt
content is and what title content is and a swathe of normative
requirements/advice based on this distinction it would appear unwise to
promote the use of title as fallback without providing normative
requirements on provision of a method to distinguish between the two.

*Note:* in terms of the accessible name calculation for an img element,  
if

the image does not have aria-label or an aria-labelledby or an alt
attribute, but does have a title attribute, then the title attribute is
used as the accessible name. From an accessibility API perspective, no
distinction is indicated as to the source of the accessible name (apart
from in the Mac AX API).

The last point is another reason why making the title attribute on images
(without alt) conforming is that the semantics, for all users, are
ambiguous.


Yes, the semantic difference is clear. What I wanted to add to this  
discussion is confirmation that the title attribute is inaccessibly to  
mobile browser users and likely to remain so. I don't know what  
conclusions to draw or what the spec should say, but to me it seems unwise  
to use the title attribute at all...


--
Philip Jägenstedt
Core Developer
Opera Software

Re: [whatwg] alt="" and the exception

[Nils Dagsson Moskopp]

"Jukka K. Korpela"  schrieb am Wed, 01 Aug 2012
11:53:41 +0300:

> 2012-08-01 10:56, Ian Hickson wrote:
> 
> > […]
> >
> > The problem is that some generators -- e.g. software that converts
> > word processor documents to HTML -- are in a position where they
> > sometimes cannot possibly comply to the requirement. Image
> > recognition and context analysis simply isn't good enough yet to
> > handle this case.
> 
> So what about the poor human then?

He/she/it most likely has the supernormal powers of instrospection,
image recognition and asking superiours for clarification of intent.

-- 
Nils Dagsson Moskopp // erlehmann

Re: [whatwg] allowfullscreen vs sandbox="allow-fullscreen", and mimicking for pointer lock

[Anne van Kesteren]

On Wed, Aug 1, 2012 at 11:04 AM, Anne van Kesteren  wrote:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17838
>
> I did not want to define new HTML features in a separate draft.

So Vincent, if you want to argue for a different design, that bug
would be the place I think. I do not really care either way, I just
went with what roc came up with.


-- 
http://annevankesteren.nl/

Re: [whatwg] allowfullscreen vs sandbox="allow-fullscreen", and mimicking for pointer lock

[Anne van Kesteren]

On Wed, Aug 1, 2012 at 12:33 AM, Adam Barth  wrote:
> Main frame: a.html
>   -> 
> -> 
>
> Can c.html go full screen?  Where is that specified?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17838

I did not want to define new HTML features in a separate draft.


-- 
http://annevankesteren.nl/

Re: [whatwg] alt="" and the exception

[Jukka K. Korpela]

2012-08-01 10:56, Ian Hickson wrote:


Only generators are in a position where they might have to
include images for which they lack the ability to provide alt texts.


A simple counter-example to that: A human employee who has been told to 
add some images to a web page, without having been told why and with no 
instructions on alt texts.



On Wed, 25 Jul 2012, Jukka K. Korpela wrote:


Quite possibly. We cannot prevent people from writing and selling buggy
software. A generator may produce valid code, or invalid code. We should
not change the definition of valid just to match some generator
behavior.


The problem is that some generators -- e.g. software that converts word
processor documents to HTML -- are in a position where they sometimes
cannot possibly comply to the requirement. Image recognition and context
analysis simply isn't good enough yet to handle this case.


So what about the poor human then?

And when there’s an argument of impossibility, in some sense, something 
judged to be an error, on good grounds, it’s still an error. A markup 
error is not a mortal sin, and there is no real punishment for it, 
though it may have some negative effects.



It's unfortunate to force such vendors into a position of
having to defend their one validation error when there's nothing they can
do about it,


Silencing the error does not make the markup any better. This is an 
example of the "validation as quality assurance" fallacy that we should 
fight against, not support. When a document has been converted to HTML 
format without due attention to alt texts for images, it has not been 
converted properly. There is no reason to try please vendors of 
converters by tweaking the rules and the checkers/validators to accept 
automatic conversion results that just aren't good.


And they *can* do a lot about it. They can initiate a user dialog, 
prompting for a person to provide alt text. Whether it is economically 
feasible is a different issue. If you don't require generators to do 
that, why would you require the poor human employee to write just 
something into the alt attribute? (Making him type nonsense, mostly, of 
course.)



According to normal accessibility principles, a generically informative
alt attribute is better than no alt attribute, which just says "here's
an image and we're not telling you anything about it, probably because a
lazy author didn't give the issue any thought".


That's what the absence of an alt="" attribute means.


That's the problem indeed. A generically informative alt attribute means 
something else. (What it means depends on its formulation.)



Even alt="unknown image" or alt="unknown image named foobar.jpg" is
better than lack of alt attribute (or alt="").


On the contrary; alt="unknown image" is equivalent to unknown
image


Or rather just the text "unknown image". Whether it makes sense depends 
on the context, as usual with alt attributes. In an image gallery (a 
typical case), it makes perfect sense.



and would be fine alt="" text for an image of text that says
"unknown image"


That's a bit too theoretical, isn't it? On similar grounds, you might 
argue that _any_ alt text is a fine text for an image containing that 
text, and nothing else.


Yucca

Re: [whatwg] alt="" and the exception

[Ian Hickson]

On Tue, 24 Jul 2012, Jukka K. Korpela wrote:
> 2012-07-24 21:58, Ian Hickson wrote:
> > On Tue, 24 Jul 2012, Edward O'Connor wrote:
> > > 
> > > The spec currently disallows conformance checkers from reporting 
> > >  elements without alt="" attributes as an error when  > > name=generator> is present[1].
> > 
> > I've adjusted the text to make it clearer that validators can report 
> > the error in this case, just that they are discouraged from doing so.
> 
> This is an improvement, but I think Edward O'Connor's points still 
> apply. Just saying that the page was generated by a generator has no 
> logical relationship to the issue of alt texts.

Yes, it does. Only generators are in a position where they might have to 
include images for which they lack the ability to provide alt texts.


> I think it would be better to keep the alt attribute always required but
> recommend that conformance checkers have an option of switching off errors
> related to this, due to situations where automatically generated markup
> contains a large number of img elements without alt attributes. Such
> situations can be *understandable* for practical reasons, but this does not
> make the markup good and recommendable.

On Wed, 25 Jul 2012, Henri Sivonen wrote:
> 
> The big question is whether that would be enough to solve the problem of 
> generators generating bogus alts in order to pass validation. I predict 
> generator writers would want the generator output to pass validation 
> with the default settings and, therefore, what you suggest wouldn't fix 
> the problem that the spec is trying to fix.

I agree with Henri here.


On Wed, 25 Jul 2012, Jukka K. Korpela wrote:
> 
> Quite possibly. We cannot prevent people from writing and selling buggy 
> software. A generator may produce valid code, or invalid code. We should 
> not change the definition of valid just to match some generator 
> behavior.

The problem is that some generators -- e.g. software that converts word 
processor documents to HTML -- are in a position where they sometimes 
cannot possibly comply to the requirement. Image recognition and context 
analysis simply isn't good enough yet to handle this case.


> After all, what's the point of using validation if you use a generator? 

People use validators to spot-check things all the time.


> You would in effect be testing the generator, something that its vendor 
> should have done. We should not be concerned about helping generator 
> vendors to advertize their products as producing valid code (code that 
> passes validation) when they in fact produce code that violates 
> established good practices of HTML.

Yes and no. It's unfortunate to force such vendors into a position of 
having to defend their one validation error when there's nothing they can 
do about it, and when the validation error in question is one they can so 
easily silence (without improving their conformance, and potentially 
harming the semantics at the same time).


> According to normal accessibility principles, a generically informative 
> alt attribute is better than no alt attribute, which just says "here's 
> an image and we're not telling you anything about it, probably because a 
> lazy author didn't give the issue any thought".

That's what the absence of an alt="" attribute means.


> Even alt="unknown image" or alt="unknown image named foobar.jpg" is 
> better than lack of alt attribute (or alt="").

On the contrary; alt="unknown image" is equivalent to unknown 
image and would be fine alt="" text for an image of text that says 
"unknown image" or of an icon that represents an unknown image, but would 
be quite incorrect alt="" text for an image whose contents are unknown at 
the time of publication.


On Wed, 25 Jul 2012, Leif Halvard Silli wrote:
> 
> How about simply introducing a @generator attribute:
> 
>  

In the past I have argued against this, on the basis that it is highly 
likely to be abused and actually make things worse. (The idea has been 
brought up numerous times over the past few years, in many forms.)

However, a few years of experience with the  "generator" idea have 
not led Henri and Mike (validator authors) to feel that the problem has 
been suitably addressed, and Mike is now implementing alternatives, so 
clearly it is time for me to revisit that. :-)

We briefly brainstormed some ideas on #whatwg earlier tonight, and one 
name in particular that I think could work is the absurdly long

   

This has several key characteristics that I think are good:

 - it's long, so people aren't going to want to type it out
 - it's long, so it will stick out in copy-and-paste scenarios
 - it's emminently searchable (long unique term) and so will likely lead 
   to good documentation if it's adopted
 - the "generator" part implies that it's for use by generators, and may 
   discourage authors from using it
 - the "unable" and "required" parts make it obvious that using this 
   attribute is an act of last resort