Color of disabled radio buttons
in [JavaScript]
|
From: SAM on 20 May 2010 14:08 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
From: Jukka K. Korpela on 20 May 2010 22:58 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/
From: David Mark on 21 May 2010 03:03 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. ;)
From: Thomas 'PointedEars' Lahn on 21 May 2010 06:57 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
From: RobG on 21 May 2010 08:20 On May 21, 12:08 am, "Jukka K. Korpela" <jkorp...(a)cs.tut.fi> wrote: > RobG wrote: > > On May 20, 10:13 am, RogerF <rfren...(a)gmail.com> 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
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() |