Prev: IE9--the end of the line for browser sniffers?
Next: A question about new Object()
From: David Mark on 21 May 2010 09:33
Thomas 'PointedEars' Lahn wrote:
> Jukka K. Korpela wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Jukka K. Korpela wrote:
>>>> <body onbeforeprint="printModifications(false)"
>>>> onafterprint="printModifications(true)">
>>> Since those attributes are, as you say, nonstandard, the resulting
>>> markup would be not Valid.
>> It depends on the DTD, and the issue has no impact on the functionality or
>> appearance of the page.
>
> While it is theoretically possible for such a document to pass Validation by
> use of a fitting DOCTYPE declaration, if you use a DOCTYPE declaration that
> does not fit a specific subset of combinations of system and public
> identifiers, MSHTML and other layout engines will use Compatibility/Quirks
> Mode. You do not want that to happen to you, both with regard to rendering
> and DOM scripting. Besides, one does not know what is going to happen in
> the future with either the target environments, the Web application, or
> MSHTML. So this approach should be avoided.
>
>> - There's no reason to capitalize the word "valid".
>
> Yes, there is: <http://validator.w3.org/>
>
>>> Therefore, after feature testing them, the corresponding script
>>> properties should be set instead, perhaps using the standards-compliant
>>> `onload' attribute.
>> Admittedly, it might be cleaner to do as you suggest, defining the event
>> handler purely in JavaScript,
>
> ... or, in this case, JScript ...
>
>> for two reasons. If your markup otherwise complies to HTML recommendations
>> by the W3C, you can then use their DTD when you validate your page. And
>> you avoid the (small) potential risk that some other browser starts
>> recognizing the currently IE-specific attributes, handling them in
>> somewhat different ways that you are not prepared to.
>
> Exactly.
>
>> While at this, I start wondering whether event attributes (in HTML) should
>> be generally replaced by JavaScript code that assigns event handlers to
>> elements. I would expect browsers that do not support the latter way have
>> lost all practical significance long ago, so is it just by habit that
>> people use event attributes?
>
> No, there are good reasons for not usually doing that. David has mentioned
> some. I would like to emphasize one or two things he indicated, what I have
> said often enough here and elsewhere:
>
> If you replace *standards-compliant* intrinsic event-handler attributes with
> event-handler properties, you will have to face the fact that the latter are
> proprietary and do not need to be supported (in the way one would expect).
> You can test for methods of W3C DOM Level 2+ Events and alternatively the
> MSHTML DOM, and use those instead if the feature test turns out successful,
> but none of those needs to be supported either.
>
> It is also not possible to reliably determine for all event-handler
> properties whether they are supported or not: Some DOM implementations let
> supported event-handler properties have the `undefined' value until set
> instead of `null'. So the otherwise reasonable test
>
> typeof obj.on… != "undefined"
>

Well, at least for elements, it is possible to teat for DOM0 support
(and it isn't a huge stretch to then infer DOM2 support for that event,
provided the addEventListener method exists). See the section on
detecting events:-

http://www.cinsoft.net/host.html

Granted, the isEventSupported function does some less than ideal
pigeonholing in that it requires that browsers like those described
above support setAttribute. As we all (except for the authors of
jQuery, Dojo, etc.) know older versions of IE (and IE8 Compatibility
View) treat attributes like properties (and vice versa), which makes
them unable to use that part of the test. It is only a happy
coincidence that they don't get that far (they are not deficient as above).

So, my advice is to use it only to detect proprietary events (i.e. don't
bother detecting click as there is a remote possibility of a false
negative). For example, I recently used it to detect
beforeactivate/beforedeactivate for some code in an editor that needed
those events (and by another happy coincidence) only needed to run for
IE. Another application would be for a drag and drop application to
detect touchstart/end and then check for mousemove (if the former
exists, but not the latter, use the touch events instead of the usual
suspects). Granted, I don't advise such drag and drop applications in
most cases (best to leave the touch events to the browsers' default
actions). But I did have a support client who queried about something
like that and isEventSupported was the key to providing an answer.

As an aside, it's hard to believe my "quick question" service doesn't
have about a thousand users by now (of course, then I'd have to hire a
real staff). Barely into double digits after mentioning it here and on
LinkedIn a few times. But then I haven't advertised it on my site yet
(last I heard they had to put down my graphics designer, so the whole
marketing effort is at a standstill). The above is indicative of the
sort of information I provide, which often cannot be found elsewhere
(except here when I feel like it). That's why I didn't go into great
detail explaining the various primers on my site. Verbose explanations
are for paying clients. :)

I often hear clients had spent hours scratching their head and searching
the Web for answers and then I put the matter to bed in thirty seconds.
I'm sure the typical JS-intensive project would submit a question every
hour if I let them. For the record, more than one or two a day would
likely result in a premium increase (from the standard $100(US) per
month). Yes, I said $100(US) per _month_ to have access to my advice
24/7 with answers guaranteed in 24 hours. What are all of you
greenhorns out there waiting for? :) StackOverflow is not your friend
and you can't always find everything here (a common complaint often
heard in this group). There is now an alternative/supplement for all
but the most destitute. ;)
From: Evertjan. on 21 May 2010 10:38
RobG wrote on 21 mei 2010 in comp.lang.javascript:

> The OP stated that the issue is that disabled radio buttons, when
> printed, look like selected radio buttons. So I offered a printing-
> oriented solution, it could be adapted to other scenarios.

After serious testing,
both in colour and in b/w,
on HP and Cannon printers,
even on my old Epson matrix printer,
I have come to the conclusion
that ALL radio buttons act disabled when printed.

So why bother what they look like?

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
From: Jukka K. Korpela on 21 May 2010 12:36
Thomas 'PointedEars' Lahn wrote:

> While it is theoretically possible for such a document to pass
> Validation by use of a fitting DOCTYPE declaration,¨

It's just as practical and just as theoretical as using any other document
type definition.

> if you use a
> DOCTYPE declaration that does not fit a specific subset of
> combinations of system and public identifiers, MSHTML and other
> layout engines will use Compatibility/Quirks Mode.

No they won't. Test it.

>> - There's no reason to capitalize the word "valid".
>
> Yes, there is: <http://validator.w3.org/>

That site contains a lot of nonsense, but it does not capitalize the word
"valid", except at the start of a sentence.

> It is also not possible to reliably determine for all event-handler
> properties whether they are supported or not

Well, with event attributes, we have _no_ way of doing that, do we? Just
because some attribute is "standard" (i.e., defined in W3C recommendations)
doesn't guarantee it's supported. It's a longstanding tradition that
browsers do not even seriously try to implement "standards" completely. But
empirical information about support to event attributes might be sufficient
in practice.

It's of course somewhat _easier_ to write event attributes than to do the
corresponding things in a script, when you just wish to assign an event
handler to a particular element. On the other hand, to someone learning
these things, it might be easier to learn just the latter approach. But if
that area is not sufficiently "standardardized", then I see the merits of
playing with event attributes as well.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

From: David Mark on 21 May 2010 12:42
Jukka K. Korpela wrote:
> Thomas 'PointedEars' Lahn wrote:
>
>> While it is theoretically possible for such a document to pass
>> Validation by use of a fitting DOCTYPE declaration,¨
>
> It's just as practical and just as theoretical as using any other
> document type definition.
>
>> if you use a
>> DOCTYPE declaration that does not fit a specific subset of
>> combinations of system and public identifiers, MSHTML and other
>> layout engines will use Compatibility/Quirks Mode.
>
> No they won't. Test it.
>
>>> - There's no reason to capitalize the word "valid".
>>
>> Yes, there is: <http://validator.w3.org/>
>
> That site contains a lot of nonsense, but it does not capitalize the
> word "valid", except at the start of a sentence.
>
>> It is also not possible to reliably determine for all event-handler
>> properties whether they are supported or not
>
> Well, with event attributes, we have _no_ way of doing that, do we? Just
> because some attribute is "standard" (i.e., defined in W3C
> recommendations) doesn't guarantee it's supported. It's a longstanding
> tradition that browsers do not even seriously try to implement
> "standards" completely. But empirical information about support to event
> attributes might be sufficient in practice.
>

If a browser does not support the attributes, it's surely not going to
support the corresponding DOM properties. And with attributes, the
degradation is inherent.
From: David Mark on 21 May 2010 12:43
Evertjan. wrote:
> RobG wrote on 21 mei 2010 in comp.lang.javascript:
>
>> The OP stated that the issue is that disabled radio buttons, when
>> printed, look like selected radio buttons. So I offered a printing-
>> oriented solution, it could be adapted to other scenarios.
>
> After serious testing,
> both in colour and in b/w,
> on HP and Cannon printers,
> even on my old Epson matrix printer,
> I have come to the conclusion
> that ALL radio buttons act disabled when printed.
>
> So why bother what they look like?
>

I think the OP was worried about using too much ink on rendering the
shadowy disabled controls.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: IE9--the end of the line for browser sniffers?
Next: A question about new Object()