Color of disabled radio buttons

Discussion in 'Javascript' started by RogerF, May 20, 2010.

  1. RogerF

    RogerF Guest

    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
     
    RogerF, May 20, 2010
    #1
    1. Advertising

  2. RogerF

    Scott Sauyet Guest

    On May 19, 8:13 pm, RogerF <> 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
     
    Scott Sauyet, May 20, 2010
    #2
    1. Advertising

  3. RogerF

    RobG Guest

    On May 20, 10:13 am, RogerF <> 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
     
    RobG, May 20, 2010
    #3
  4. RobG wrote:

    > On May 20, 10:13 am, RogerF <> 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/
     
    Jukka K. Korpela, May 20, 2010
    #4
  5. 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.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
     
    Thomas 'PointedEars' Lahn, May 20, 2010
    #5
  6. RogerF

    SAM Guest

    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
     
    SAM, May 20, 2010
    #6
  7. 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/
     
    Jukka K. Korpela, May 21, 2010
    #7
  8. RogerF

    David Mark Guest

    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. ;)
     
    David Mark, May 21, 2010
    #8
  9. 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
     
    Thomas 'PointedEars' Lahn, May 21, 2010
    #9
  10. RogerF

    RobG Guest

    On May 21, 12:08 am, "Jukka K. Korpela" <> wrote:
    > RobG wrote:
    > > On May 20, 10:13 am, RogerF <> 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
     
    RobG, May 21, 2010
    #10
  11. RogerF

    David Mark Guest

    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. ;)
     
    David Mark, May 21, 2010
    #11
  12. RogerF

    Evertjan. Guest

    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)
     
    Evertjan., May 21, 2010
    #12
  13. 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/
     
    Jukka K. Korpela, May 21, 2010
    #13
  14. RogerF

    David Mark Guest

    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.
     
    David Mark, May 21, 2010
    #14
  15. RogerF

    David Mark Guest

    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.
     
    David Mark, May 21, 2010
    #15
  16. 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
     
    Thomas 'PointedEars' Lahn, May 21, 2010
    #16
  17. 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
     
    Thomas 'PointedEars' Lahn, May 21, 2010
    #17
  18. 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/
     
    Jukka K. Korpela, May 21, 2010
    #18
  19. RogerF

    David Mark Guest

    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).
     
    David Mark, May 21, 2010
    #19
  20. RogerF

    Scott Sauyet Guest

    "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
     
    Scott Sauyet, May 21, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Scott D Johnson
    Replies:
    1
    Views:
    1,131
    Scott D Johnson
    Sep 27, 2006
  2. BillE
    Replies:
    2
    Views:
    497
    BillE
    Nov 13, 2007
  3. Kamaljeet Saini
    Replies:
    0
    Views:
    483
    Kamaljeet Saini
    Feb 13, 2009
  4. Dr. Leff
    Replies:
    3
    Views:
    330
    David Mark
    Oct 15, 2007
  5. Dr. Leff
    Replies:
    3
    Views:
    251
    David Mark
    Oct 15, 2007
Loading...

Share This Page