Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Color of disabled radio buttons

Reply
Thread Tools

Color of disabled radio buttons

 
 
RogerF
Guest
Posts: n/a
 
      05-20-2010
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
 
Reply With Quote
 
 
 
 
Scott Sauyet
Guest
Posts: n/a
 
      05-20-2010
On May 19, 8:13*pm, RogerF <(E-Mail Removed)> wrote:
> 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.

--
Scott
 
Reply With Quote
 
 
 
 
RobG
Guest
Posts: n/a
 
      05-20-2010
On May 20, 10:13*am, RogerF <(E-Mail Removed)> wrote:
> 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.


--
Rob
 
Reply With Quote
 
Jukka K. Korpela
Guest
Posts: n/a
 
      05-20-2010
RobG wrote:

> On May 20, 10:13 am, RogerF <(E-Mail Removed)> wrote:
>> 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.

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

 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      05-20-2010
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. 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[i].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>

<body onload="setPrintListeners()">

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


This will seldom suffice. Radio buttons are herd animals


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
 
Reply With Quote
 
SAM
Guest
Posts: n/a
 
      05-20-2010
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)
--
sm
 
Reply With Quote
 
Jukka K. Korpela
Guest
Posts: n/a
 
      05-21-2010
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. - 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?

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

 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      05-21-2010
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. - 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?
>


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.
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      05-21-2010
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"

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
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
 
Reply With Quote
 
RobG
Guest
Posts: n/a
 
      05-21-2010
On May 21, 12:08*am, "Jukka K. Korpela" <(E-Mail Removed)> wrote:
> RobG wrote:
> > On May 20, 10:13 am, RogerF <(E-Mail Removed)> wrote:
> >> 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.

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


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.


[...]
> > * 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.


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.


--
Rob
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Changing font color from current font color to black color Kamaljeet Saini Ruby 0 02-13-2009 04:58 PM
Disabled radio buttons and checkboxes are hard to see BillE ASP .Net 2 11-13-2007 01:12 PM
Created Radio Buttons displaying as if they were conventional buttons Dr. Leff Javascript 3 10-15-2007 09:47 PM
Created Radio Buttons displaying as if they were conventional buttons Dr. Leff Javascript 3 10-15-2007 05:18 AM
ASP.NET Reset Radio Button in a group of Radio Buttons Scott D Johnson ASP .Net 1 09-27-2006 10:38 PM



Advertisments