Prev: /Job/ need: Javascript developer in San Francisco downtown,
Next: The Most Challenging Interview Question
From: RobG on 9 May 2010 20:29
On May 10, 9:37 am, David Mark <dmark.cins...(a)gmail.com> wrote:
> David Mark wrote:
> > RobG wrote:
> >> On May 10, 7:39 am, David Mark <dmark.cins...(a)gmail.com> wrote:
> >>> nick wrote:
> >>>> On May 9, 6:46 am, SAM wrote:
> >>>>> Le 5/9/10 8:49 AM, nick a écrit :
> >>>>> [...]
> >>>>>> I'm working on another Chrome extension. I want to pop the dropdown
> >>>>>> open when the user clicks its containing <label>.
> >>>>> <label onmouseover="dropDown(this)" for="select_1">
> >>>>> blah blah ... ... :
> >>>>> <select id="select_1"
> >>>>> onclick="dropUp(this); doThat(this)">
> >>>>> ... ...
> >>>>> </label>
> >>>> AFAIK you don't need the 'for' attribute if the control is inside of
> >>>> the label :)
> >> According to the W3C HTML specification, yes. But you presume all
> >> browsers follow the spec.
>
> >>> You don't, but you should avoid that construct for compatibility reasons.
> >> You do if the browser is IE 6, and maybe others.
>
> > As mentioned, best to avoid that construct altogether (that's what I
> > do). Then you can remain blissfully unaware of such idiosyncrasies (as
> > I am). ;)
>
> And actually, that's not quite accurate. The fact that IE6 ignores the
> implications of that construct is an example of the incompatibilities I
> advised to avoid. Without the - for - attribute, IE6 just doesn't make
> the connection.

Yes, problem is that practices develop to avoid incompatibilities,
then after a while someone asks "why do we do that?" and everyone has
forgotten the answer. I don't know if there's any way to design around
that other than to fully document the code. Seems to be human nature.

Another example is getting the value of a select element - most modern
browsers will give the correct answer where the type is select-one and
all options have a value attribute given:

alert( selectElement.value );

but some ancient browser didn't (Navigator 4 or 5?), so we persist
with the clumsy:

alert( selectElement.options[selectElement.selectedIndex].value )

and even then some browsers still get it wrong if the option has no
value attribute, so there's the tiresome "if there's no value, get the
text" loop.

Then some bright spark asks "Why don't we use selectElement.value?
Works in all the (very small number of modern) browsers I tested
in...".

And then there is type select-multiple to contend with, which HTML 5
doesn't fix.


--
Rob
From: David Mark on 9 May 2010 20:43
RobG wrote:
> On May 10, 9:37 am, David Mark <dmark.cins...(a)gmail.com> wrote:
>> David Mark wrote:
>>> RobG wrote:
>>>> On May 10, 7:39 am, David Mark <dmark.cins...(a)gmail.com> wrote:
>>>>> nick wrote:
>>>>>> On May 9, 6:46 am, SAM wrote:
>>>>>>> Le 5/9/10 8:49 AM, nick a �crit :
>>>>>>> [...]
>>>>>>>> I'm working on another Chrome extension. I want to pop the dropdown
>>>>>>>> open when the user clicks its containing <label>.
>>>>>>> <label onmouseover="dropDown(this)" for="select_1">
>>>>>>> blah blah ... ... :
>>>>>>> <select id="select_1"
>>>>>>> onclick="dropUp(this); doThat(this)">
>>>>>>> ... ...
>>>>>>> </label>
>>>>>> AFAIK you don't need the 'for' attribute if the control is inside of
>>>>>> the label :)
>>>> According to the W3C HTML specification, yes. But you presume all
>>>> browsers follow the spec.
>>>>> You don't, but you should avoid that construct for compatibility reasons.
>>>> You do if the browser is IE 6, and maybe others.
>>> As mentioned, best to avoid that construct altogether (that's what I
>>> do). Then you can remain blissfully unaware of such idiosyncrasies (as
>>> I am). ;)
>> And actually, that's not quite accurate. The fact that IE6 ignores the
>> implications of that construct is an example of the incompatibilities I
>> advised to avoid. Without the - for - attribute, IE6 just doesn't make
>> the connection.
>
> Yes, problem is that practices develop to avoid incompatibilities,
> then after a while someone asks "why do we do that?" and everyone has
> forgotten the answer.

The only answer for this one is that some browsers can't deal with that
construct. As for which browsers specifically; you are right, I
couldn't remember. Could be lots of them of course.

> I don't know if there's any way to design around
> that other than to fully document the code. Seems to be human nature.

Just use something like jQuery. It makes all browsers look exactly
alike. :) Well, except for IE6, IE7, IE8 in its default Compatibility
View, older versions of FF, Opera, Safari, etc. Er, scratch that.
Don't use jQuery. :(

>
> Another example is getting the value of a select element - most modern
> browsers will give the correct answer where the type is select-one and
> all options have a value attribute given:
>
> alert( selectElement.value );
>
> but some ancient browser didn't (Navigator 4 or 5?), so we persist
> with the clumsy:

I don't think there was any NN5 (didn't it get canceled?) And I don't
think the issue is relegated to NN4 either, but am not sure.

>
> alert( selectElement.options[selectElement.selectedIndex].value )

It is a good candidate for a wrapper function.

>
> and even then some browsers still get it wrong if the option has no
> value attribute, so there's the tiresome "if there's no value, get the
> text" loop.

Yes, that is irritating (and I've seen many examples of "major" scripts
getting it wrong). Best to use values. ;)

>
> Then some bright spark asks "Why don't we use selectElement.value?
> Works in all the (very small number of modern) browsers I tested
> in...".

Sure, why not use complicated CSS3 queries? The libraries that call QSA
will likely get them right (some feat) in a handful of the latest
browsers. Of course, their fallback code likely won't so compatibility
goes out the window. I can't understand how the developers can ignore
the tons of users who browse from work (businesses aren't known to be
quick to upgrade software, particularly browsers). It's like their only
goal is to make shiny demos that "work" in the very latest browsers (the
ones they profess to "care" about anyway). How most of the world
figured it was a good idea to buy in to such thoughtless designs is
beyond me.

>
> And then there is type select-multiple to contend with, which HTML 5
> doesn't fix.
>

As far as I am concerned, HTML5 does not yet exist. I see people using
its doctype and wonder what they are thinking. Perhaps that they are on
the cutting edge? Maybe they just want to add another "skill" to their
resumes (at the expense of their clients).
From: David Mark on 9 May 2010 22:44
nick wrote:
> On May 9, 7:22 pm, RobG <rg...(a)iinet.net.au> wrote:
>> On May 10, 7:39 am, David Mark <dmark.cins...(a)gmail.com> wrote:
>>
>>> nick wrote:
>
>>>> AFAIK you don't need the 'for' attribute if the control is inside of
>>>> the label :)
>
>> According to the W3C HTML specification, yes. But you presume all
>> browsers follow the spec.
>
> I've done it this way as long as I can remember, even back in the IE6
> days... I probably looked at the W3C page, did it the simplest way and
> assumed IE was just silently doing its thing.
>
> How can you guys tell whether IE6 has associated the label with the
> control? Did it do anything noticeable, or are you testing it in a
> screen reader or something?

Click the label. Does the associated control focus? ;)
From: nick on 9 May 2010 22:55
On May 9, 10:44 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
> nick wrote:

> > How can you guys tell whether IE6 has associated the label with the
> > control? Did it do anything noticeable, or are you testing it in a
> > screen reader or something?

> Click the label.  Does the associated control focus?  ;)

Heh, wow. All this time I thought IE6 just didn't focus controls for
labels at all. The more you know.
From: SAM on 10 May 2010 04:37
Le 5/9/10 11:39 PM, David Mark a �crit :
> nick wrote:
>> On May 9, 6:46 am, SAM wrote:
>>> Le 5/9/10 8:49 AM, nick a �crit :
>>> [...]
>>>> I'm working on another Chrome extension. I want to pop the dropdown
>>>> open when the user clicks its containing <label>.
>>> <label onmouseover="dropDown(this)" for="select_1">
>>> blah blah ... ... :
>>> <select id="select_1"
>>> onclick="dropUp(this); doThat(this)">
>>> ... ...
>>> </label>
>> AFAIK you don't need the 'for' attribute if the control is inside of
>> the label :)
>
> You don't, but you should avoid that construct for compatibility reasons.

And the label has not to be the container of the form element,
but it may, so if ...

Clicking the label gives focus to its associated element,
the 1st step of the demand is reached.

The for attribute allows to know which DOM element will be then used.
(with gEBI, at least for others than IE)

The problem I met is that curious way that IE (6 in my tests) gives or
kept focus to this or that (the select, the submit-button ...) when
clicking here or there.

--
sm
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: /Job/ need: Javascript developer in San Francisco downtown,
Next: The Most Challenging Interview Question