Prev: IE9--the end of the line for browser sniffers?
Next: A question about new Object()
From: Thomas 'PointedEars' Lahn on 21 May 2010 13:50
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.

I seriously doubt that.

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

Well, the "DOCTYPE switch", as it has come to be called, is a reality.
So which declaration should I test where, exactly?

>>> - There's no reason to capitalize the word "valid".
>> Yes, there is: <http://validator.w3.org/>
>
> That site contains a lot of nonsense,

IYHO.

> but it does not capitalize the word "valid", except at the start of a
> sentence.

Not anymore.

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

No, we don't. But why would we need to?

> Just because some attribute is "standard" (i.e., defined in W3C
> recommendations) doesn't guarantee it's supported.

Name one. In particular, name one standards-compliant event-handler
attribute that is not supported, and the user agent it is not supported by.

> It's a longstanding tradition that browsers do not even seriously try to
> implement "standards" completely.

That is patently untrue (where have you been the last years?). Vendors are
*competing* to provide a more standards-compliant, yet faster browser with
the next release while continuing to provide old and new proprietary
features.

In addition, there is no point in putting `standards' in quotes here (except
when quoting it). W3C Recommendations are widely regarded Web standards.
In particular, RFC 2854 documented the transfer of the further development
of HTML from the IETF/IESG to the W3C almost ten years ago.

> But empirical information about support to event attributes might be
> sufficient in practice.

It is. In the unlikely event that a standards-compliant attribute is not
supported, one can expect it to be ignored by a tag-soup parser. However,
that does not justify using proprietary or user-defined attributes.

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

ISTM you miss the point. The problem are proprietary event-handler
attributes, not standards-compliant ones, and the misuse of DOM scripting to
add event listeners inefficiently.


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
From: Thomas 'PointedEars' Lahn on 21 May 2010 14:07
David Mark wrote:

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

I think they worried more that the user could not tell disabled from checked
enabled radiobuttons, and I think that is a valid concern. However, not
requiring the user to print out the original form is a better solution to
this problem.


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
From: Jukka K. Korpela on 21 May 2010 14:19
Thomas 'PointedEars' Lahn wrote:

>>> 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.
>
> Well, the "DOCTYPE switch", as it has come to be called, is a reality.
> So which declaration should I test where, exactly?

You made a claim, you test it. Specifically, you made a general claim, so to
prove it empirically, you would have to test all the possible DOCTYPE
declarations except a small finite number. But you don't need to spend an
infinite time, really; if you do actual testing, you will disprove your
statement.

In other respects (too), this is getting far too off-topic here, and not
very constructive any more.

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

From: David Mark on 21 May 2010 15:03
Thomas 'PointedEars' Lahn wrote:
> David Mark wrote:
>
>> 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.
>
> I think they worried more that the user could not tell disabled from checked
> enabled radiobuttons, and I think that is a valid concern. However, not
> requiring the user to print out the original form is a better solution to
> this problem.
>

I couldn't agree more. I typically hide forms for print media. It's
the results after submission that should be sent to the printer (and
styled appropriately).
From: Scott Sauyet on 21 May 2010 15:21
"Evertjan." wrote:
> 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.

Ahh, but you haven't heard of the new project sponsored by Adobe and
Amazon to embed a web-enabled chip in every printed page? Or how
about Apple's upcoming iPrint application, expected to be available in
8pt and 16pt versions this year, with up to 64pt due soon?

:-)

--
Scott
First  |  Prev  | 
Pages: 1 2 3 4
Prev: IE9--the end of the line for browser sniffers?
Next: A question about new Object()