#792 enhancement
Christopher Thomas

Element#Show cannot override CSS styles

Reported by Christopher Thomas | September 10th, 2009 @ 01:13 PM | in 1.7


There was a previous bug I fixed in prototype in the same way, but this is to fix those issues when in the stylesheet you set a default display: none style to an element and now you cannot use Element.show() to display it, because the CSS style will never be overriden.

In the API docs, it says that this is because the CSS style cannot be overriden, but this is bogus. It can be, as long as you let the programmer decide what show means.

The problem is that Prototype doesnt want to decide what "show" means, considering that show can mean display: block, inline-block, inline, etc. Prototype doesnt want to get involved in the details and this is the correct decision.

But it still leaves the problem intact, a problem that is really easy to solve.

You simply allow the user to decide what show means.

Element.show() -> display = "";
Element.show("block") -> display = "block";
Element.show("inline-block") -> display = "inline-block";

by simply adding a parameter to show, that allows you to override WHAT will happen when show is called, you solve the problem caused by not being able to override the stylesheet.

The fix, which I tested just now, works fine, is very simple.


line: 1594 "show: function(element) {"

change that method, to this instead

show: function(element,override) {



Then your prototype will allow you to override the stylesheet.

Why isnt this already in prototype??? The solution was so easy, you guys made the same mistake with setOpacity and the solution was staring you in the face.

please apply this fix to prototype, thanks!

Comments and changes to this ticket

  • Christopher Thomas

    Christopher Thomas September 10th, 2009 @ 01:14 PM

    grrr, it mangled my method

    show: function(element,override) { if(!override) override = "";

    element = $(element); element.style.display = override; return element; }

  • Tobie Langel

    Tobie Langel September 10th, 2009 @ 03:38 PM

    • Milestone set to 1.7
    • State changed from “new” to “enhancement”
    • Tag changed from element, override, show, stylesheet to needs:patch, section:dom
    • Assigned user set to “Tobie Langel”


    That's an elegant solution to this problem.

    Thank you for suggesting it.

  • T.J. Crowder

    T.J. Crowder November 16th, 2009 @ 04:50 PM

    • Assigned user cleared.

    [responsible:none bulk edit command]

  • Dan Dean

    Dan Dean February 22nd, 2010 @ 07:46 PM

    This should work alongside a solution to #177.

  • bubbatls

    bubbatls April 23rd, 2010 @ 01:05 PM

    Personnaly, I always use this for 'block', so I suggest the default value to be 'block'.
    because giving parameters does not allow anymore such simple code:

    Another solution would be to determine what is the default display of the tag :
    div, p , ... should be block
    span, a, ... should be inline

    Thus only bad people who use bad tag for bad style will have to code like this :

  • Christopher Thomas

    Christopher Thomas April 23rd, 2010 @ 01:21 PM

    I think you misunderstand the intentions of what I meant.

    if in your stylesheet a div node is display:none, then if you want to show that element, in prototype can you do this element.show() which if you read the code, actually does this: display="" so it REMOVES the display attribute, therefore defaulting to the CSS style, which normally, will be display:block, because div are block level elements, but if your element is by default hidden (display: none), it means your element gets hidden BY DEFAULT.

    .hideme{ display: none; } div class='hideme'

    element.show() -> display: none // should be display: block
    element.hide() -> display: none

    so in this circumstance, prototype has like a gimbal lock, you're basically forced to manually override the style yourself and go back to the old way of doing things.

    this is the same problem that prototype has when dealing with opacity.

    .hideme{ opacity: 0; } div class="hideme"

    element.opacity(0) -> opacity: 0; // should be opacity: 1
    element.opacity(1) -> opacity: 0;

    For prototype, opacity: 1 is exactly the same as saying opacity="" or removeAttribute("opacity") in that, removing the attribute, or setting it to blank, says default to normal, which in some cases, means 100% opaque, but if your stylesheet defaults to saying opacity:0, doing element->setOpacity(1) actually does opacity:0 which is NOT what I wanted to happen.

    It's the whole attitude that exists in the prototype development team that doesnt exist in jquery team for example that the default value is the same as an empty value and this isnt true if you put CSS styles which alter the default value to being something other than the default without with no css style applied. if I put an opacity of 1 in jquery, I get 1, exactly 1, I wanted 1 and I got it, in prototype, I get "" or in this case, defaults to what the style says the opacity should be, 0, 0.4, 0.6, whatever.

    ACKNOWLEDGEMENT: I realise that prototype team are trying to solve a problem with Internet Explorer by removing the opacity attribute, because there is a font rendering problem, however, as I stated before, the prototype team have got it 100% wrong on this issue, because it's crossing over the line between whose responsiblity is what. I suggested a similar way to override this by allowing me to say FORCE opacity: 1 to be opacity: 1 regardless and I got told that this was not a good solution, go figure??

    So my solution is about making it possible for me to override prototypes decision and tell prototype what I WANT to do, rather than prototype assume what I want to do.

    So you have the wrong idea, it's not about using display:inline for div's or block for anchor tags, but what prototype does by DEFAULT.

    does that help ?

  • Tobie Langel

    Tobie Langel April 23rd, 2010 @ 07:01 PM

    • Assigned user set to “Tobie Langel”
  • Christopher Thomas

    Christopher Thomas August 2nd, 2010 @ 05:23 PM

    • Importance changed from “” to “”

    Tobie: this issue is finally resolved in 1.7? I see it's marked for 1.7 milestone, I hope so, because it's a bug bear of mine, it causes me to work twice as hard to do something jquery does more efficiently.

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

The Prototype JavaScript library.

Shared Ticket Bins

Referenced by