Color of disabled radio buttons

[RogerF]

Hello,
In IE 6x, I want to have the color of disabled radio buttons NOT be
grey. I want the color to be white background with black bullets (if
the radio button is chosen), basically just like a regular enabled
radio button. (This is javascript/html).

The disabled radio button is causing confusion since when it is
actually physically printed, on some printers all the disabled radio
buttons are appearing as black, so it's impossible to discern on the
physically print out which radio button was actually chosen!

Again this is for IE (NOT for FF, Opera, or any other browser).

Can I do it using style sheet? Or some type attribute?

Thanks in advance,
Roger

 

[Scott Sauyet]

In IE 6x, I want to have the color of disabled radio buttons NOT be
grey. I want the color to be white background with black bullets (if
the radio button is chosen), basically just like a regular enabled
radio button. (This is javascript/html).

I almost dismissed this as not relevant to the group. But one
technique comes to mind if this is a site that won't run without
Javascript (not that I'd recommend building a site that way, mind
you.)

Although I'm not certain, I'd be surprised if you could style these
disabled elements with plain CSS.

But you might be able to essentially disable otherwise enabled radio
buttons via Javascript by attaching event listeners that, when a new
radio button is selected, immediately select the previously chosen
one. There might be a flicker, but this would stop them from actually
changing values. Then you could style them however you want, within
the limitations that apply to styling any form elements.

I'm not saying this is a great solution. I would suggest you
reexamine the requirement to make sure this is really what you want to
do. But it sounds at least plausible.

 

[RobG]

Hello,
In IE 6x, I want to have the color of disabled radio buttons NOT be
grey. I want the color to be white background with black bullets (if
the radio button is chosen), basically just like a regular enabled
radio button. (This is javascript/html).

The disabled radio button is causing confusion since when it is
actually physically printed, on some printers all the disabled radio
buttons are appearing as black, so it's impossible to discern on the
physically print out which radio button was actually chosen!

Again this is for IE (NOT for FF, Opera, or any other browser).

Can I do it using style sheet? Or some type attribute?

Yes, to both, in browsers that support attribute selectors (dunno if
any version of IE does that).

e.g. to hide disabled inputs without screwing up layout you could
apply the following to a print media stylesheet:

<style type="text/css">

input[disabled] {
visibility: hidden;
}

</style>

<input type="radio" name="R">One<br>
<input type="radio" name="R">Two<br>
<input type="radio" name="R" disabled>Three<br>
<input type="radio" name="R">Four<br>
<input type="radio" name="R">Five<br>


Doesn't work in IE 6, probably doesn't work in later versions either.
You may have to use a script solution to do the same thing, e.g.

1. Put a "Print Version" button in the page
2. When clicked, open the page in a new window
3. Set the style of disabled radios to whatever suits
using script directly (i.e. set the DOM element property,
don't use a style rule)

I used visibility:hidden because it's widely supported and gives a
reasonable result - the radio button is hidden so it doesn't look
selected and the layout is unaffected.

 

[Jukka K. Korpela]

Hello,
In IE 6x, I want to have the color of disabled radio buttons NOT be
grey.

[...]
input[disabled] { [...]
Doesn't work in IE 6,

So why bother mentioning it?

You may have to use a script solution to do the same thing, e.g.

1. Put a "Print Version" button in the page

Why? The question was not limited to printing. It was mentioned that the
motivation was related to printing, though the question is rather obscure -
if filled-in forms need to be printed, there is something wrong in the
design. (Much better to have form data submitted to processing that then
generates a nicely printable page with all the relevant information. Works
better since form fields often print badly.)

Besides, what would happen if a user printed the page in the normal way,
using the browser's print button?

3. Set the style of disabled radios to whatever suits
using script directly (i.e. set the DOM element property,
don't use a style rule)

Styling of form fields is limited in many ways, especially in older
browsers.

So why don't you change the element itself to not disabled, during printing?
IE recognizes some nonstandard HTML attributes for such purposes. They could
be used as follows:

<body onbeforeprint="printModifications(false)"
onafterprint="printModifications(true)">

And you would need just simple function - at the extreme, in the case of a
single disabled radio button, say with id="dis", the function could be
really simple:

function printModifications(disabledStatus) {
document.getElementById('dis').disabled = disabledStatus; }

This does not depend on CSS at all.

 

[Thomas 'PointedEars' Lahn]

<body onbeforeprint="printModifications(false)"
onafterprint="printModifications(true)">

Since those attributes are, as you say, nonstandard, the resulting markup
would be not Valid. Therefore, after feature testing them, the
corresponding script properties should be set instead, perhaps using the
standards-compliant `onload' attribute. Untested:

<script type="text/javascript">
function printModifications(disabledStatus)
{
/* "foo" is the name of the radio button (group) */
var rbtns = document.forms[...].elements["foo"];

if (rbtns)
{
if (typeof rbtns[0] != "undefined"
&& typeof rbtns[0].type == "string"
&& rbtns[0].type.toLowerCase() == "radio")
{
/* radio button group */
for (var i = rbtns.length; i--
{
rbtns.disabled = !!disabledStatus;
}
}
else if (typeof rbtns.type == "string"
&& rbtns.type.toLowerCase() == "radio")
{
/* single radio button -- unusual and not accessible */
rbtns.disabled = !!disabledStatus;
}
}
}

function setPrintListeners()
{
var b = document.body;
if (typeof b.onbeforeprint != "undefined"
&& typeof b.onafterprint != "undefined")
{
b.onbeforeprint = function () {
printModifications();
};

b.onafterprint = function () {
printModifications(true);
};
}
}
</script>
</head>

[...]
function printModifications(disabledStatus) {
document.getElementById('dis').disabled = disabledStatus; }

This will seldom suffice. Radio buttons are herd animals ;-)


PointedEars

 

[SAM]

Le 5/20/10 2:13 AM, RogerF a écrit :

Hello,
In IE 6x, I want to have the color of disabled radio buttons NOT be
grey. I want the color to be white background with black bullets (if
the radio button is chosen), basically just like a regular enabled
radio button. (This is javascript/html).

The disabled radio button is causing confusion since when it is
actually physically printed, on some printers all the disabled radio
buttons are appearing as black, so it's impossible to discern on the
physically print out which radio button was actually chosen!

Again this is for IE (NOT for FF, Opera, or any other browser).

Can I do it using style sheet? Or some type attribute?

if in IE, the css
input[disabled] { color: #ccc; background: #fff }
doesn't work,
can't you give a class to the disabled radio-buttons
and fix a print css for that class
.disabl { display: none }
or
.disabl { filter: alpha(opacity=30); }
maybe ?

(opacity on radio-buttons is of no effect in my Fx, Opera, Safari)

 

[Jukka K. Korpela]

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. - There's no reason to capitalize the word "valid".

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

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?

 

[David Mark]

It depends on the DTD, and the issue has no impact on the functionality
or appearance of the page. - There's no reason to capitalize the word
"valid".


Admittedly, it might be cleaner to do as you suggest, defining the event
handler purely in JavaScript, 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.

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?

Well, the automatic rejection of them in the name of "Unobtrusive
Javascript" has no basis in reality. Generally speaking, it would be a
bad idea to abuse them (e.g. repeat them over and over in the markup).
But a well placed event handler attribute can often be the most elegant
and maintainable solution (isn't it funny how moving things completely
out of a file is seen as making them easier to find?) Form submit
events come to mind. Use an event attribute and your validation will
not have to wait until the DOM is completely loaded (or "ready").
Having the bit that calls the validation function right there in the
FORM itself is very handy for maintenance (i.e. there's no need to
wonder about which function (if any) is attached to the form).

One should _always_ use the onload attribute of the body though (rather
than window.onload or one of those silly DOM ready scripts). There's no
standard for the window object, but body onload works in literally
everything that supports scripting.

The other non-argument I hear in relation to this is that it helps with
caching to move script out of the document. That's also
over-generalized nonsense (a common trend in this business). If a
script is specific to a single document and doesn't often change
independently of the document, leave it in the document. It's easier to
maintain as it's right there in the file.

For example, this document closes with a long inline script:-

http://www.cinsoft.net/mylib-examples.html

....and the typical parroting neophyte will cringe at that as
"obtrusive", hard to keep up and wasteful of bandwidth. It's certainly
none of those things. The first term has no real meaning in this
context, it's much easier to find in the document than in some other
file (which file was that?), it is specific to the document (will never
be reused in others) and virtually never changes. And when it does
change, it is typically to add a new function for a new example, which
necessitates changing the document. Glad I don't have to go looking for
it. And users should be glad that I saved them an HTTP request.

 

[Thomas 'PointedEars' Lahn]

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

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"

would produce a false positive then. But you are dealing with host objects
here, so anything may happen on assignment. In particular, you could be
trying to augment a host object with a property without knowing it. That is
known to be error-prone, and failure to do so cannot be considered a bug in
the DOM implementation as the ECMAScript Specification explicitly allows it
for host objects.

So not only make the additional feature tests -- if taken seriously, so no
simple type-converting tests -- make the Web application (which I think is a
good umbrella term for describing such documents) less efficient and more
error-prone than it needs to be, but also you are restricting yourself to
only a small subset of known DOM implementations, often needlessly. Neither
happens or is implicitly required with event-handler attributes.

That is not to say that there are not useful applications for doing what you
suggest. (I think I have showed one here.) However, most implementations
of the design pattern simply neglect the aforementioned facts ("it works in
$FAVORITE_BROWSERS, so …") and, more important, the possibility of
interoperable event delegation.

This is most visible with (mis)uses of the `click' event, which does bubble
in all known DOM implementations since the concept was introduced with
Netscape Navigator 3.0 in 1996 CE. Still, there is enough code out there
that inefficiently determines fitting descendants (sometimes *hundreds*) by
use of (a) CSS(-like) query syntax, adds a `click' listener to *each* of
them (one that often uses a closure with a host object on top of that, a
pattern known to leak memory in most MSHTML versions) when it could have
added just *one* listener that makes the distinction to a *common ancestor*
to which the event must bubble up, for the comparably unlikely case that the
user causes the event to be created and dispatched to such a descendant.


HTH

PointedEars

 

[RobG]

Hello,
In IE 6x, I want to have the color of disabled radio buttons NOT be
grey.

[...]
    input[disabled] { [...]
Doesn't work in IE 6,

So why bother mentioning it?

Because the OP might be interested to know. The information will be
useful when evaluating the benefits of upgrading to a more modern
browser (IE or otherwise) that does support it, should the OP wish.

Why? The question was not limited to printing.

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.

It was mentioned that the
motivation was related to printing,

Yes, so not surprising if a solution related to printing is offered.

though the question is rather obscure -

Not at all, it is very clear to me.

if filled-in forms need to be printed, there is something wrong in the
design. (Much better to have form data submitted to processing that then
generates a nicely printable page with all the relevant information. Works
better since form fields often print badly.)

Fine, suggest it then. The OP is now able to explore solutions and
make a more informed decision.


[...]

Styling of form fields is limited in many ways, especially in older
browsers.

It would help the OP to evaluate solutions if your provide a more
information about which browsers you are referring to.

So why don't you change the element itself to not disabled, during printing?

What I think of that idea is irrelevant, it's the OP who asked for
advice. Perhaps you don't see the contradiction in criticising a
suggestion for being printing-specific, then offering a printing-
specific suggestion.

IE recognizes some nonstandard HTML attributes for such purposes. They could
be used as follows:

<body onbeforeprint="printModifications(false)"
      onafterprint="printModifications(true)">

If it is advantageous to warn about support for modification of an
input element's style object as suggested earlier, then the same
warning seems appropriate here too.

 

[David Mark]

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.




... or, in this case, JScript ...


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.

 

[Evertjan.]

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?

 

[Jukka K. Korpela]

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.

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.

 

[David Mark]

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


No they won't. Test it.


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


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.

 

[David Mark]

RobG wrote on 21 mei 2010 in comp.lang.javascript:


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.

 

[Thomas 'PointedEars' Lahn]

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

I seriously doubt that.

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?

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.

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

 

[Thomas 'PointedEars' Lahn]

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

 

[Jukka K. Korpela]

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.

 

[David Mark]

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

 

[Scott Sauyet]

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?