I'm trying to style an input[type="button"] and it seems that when I click on the label IE (9 in my case; I don't care for lower versions) doesn't apply the :active style. Everything works beautifully on Chrome and Firefox and also in IE if I click outside of the label. I had no luck in finding any clues to what might be the problem.
A <button> doesn't have this problem, so I guess there's something special about the other button's label, but what? And is there any workaround?
The problem is demonstrated at http://jsfiddle.net/Kmved/1/
Interesting find there. To answer the first question, "why?": unfortunately, the CSS spec leaves the semantics of :active entirely up to the browser vendor:
CSS does not define which elements may be in the above states, or how
the states are entered and left. Scripting may change whether elements
react to user events or not, and different devices and UAs may have
different ways of pointing to, or activating elements.
Now I would consider this a bug in IE (and expect it to be fixed in IE10 perhaps), but the letter of the law says that this is perfectly acceptable and tough luck to you.
To answer the second question (workaround?): well, you said it yourself. Use a <button> instead; as a bonus you get the option of placing any type of content inside the button in addition to simple text.
Related
I want to completely reset a button's inherited CSS so it behaves exactly like any other inline-block element. However, I've run into a problem where the text of a button is forever stuck vertically-centered.
In the fiddle (and screenshot) below, the button and div have the exact same styles according to the Chrome Developer Console, yet the button's text is vertically-centered, while the div's is not:
http://jsfiddle.net/rgthree/vT3a7/
Anyone know of the property or selector that will completely reset a button, specifically including its label position?
Answer
There's no way in any browser other than Chrome ~25. I reached out to the Chromium project about the it not working in Chrome 27 (see the #winterblood answer & comments). They said this:
The issue is that we now use margin:auto on the anonymous block inside the button to do the centering inside the button in order to get safe-centering. So, unfortunately, there's no way to style it from CSS. That you were able to control this behavior before was really implementation detail leaking out.
So, the true answer is that you cannot style this in any browser, except for Chrome ~25 where -webkit-box-align was inadvertently exposed to, as #winterblood answered.
For webkit you need to override -webkit-box-align with a value of baseline or start.
I have had no luck implementing this in Firefox yet (from a very brief look at it).
Preamble: This is a somewhat 'academic' question. I'm looking for an explanation and intelligent conjecture, not a practical solution (there is no real problem to "solve").
So, I notice that if I make a :hover selector set its display property to none, it has no discernible effect in Chrome (v23). In fact, no other properties in the selector are applied. It's as if the entire selector is ignored.
e.g.
<div class="myElement">Hover over this. Nothing happens!</div>
...
.myElement:hover {
display:none;
color:red;
}
(Check out the jsFiddle of this)
Obviously, since an element with display:none cannot be hovered, the element is instantly no longer becomes selected by the :hover selector, so loses the display:none property (and becomes eligible for selection again).
The paradoxical nature of this rule leads me to wonder why (for example) the display property doesn't toggle rapidly (every frame, or mouse move) as it does in other browsers (ie9, firefox). Although I think I prefer Chrome's implementation, I wonder why the other properties (e.g. color:red) aren't applied.
The question: is there some official documented reason why Chrome chooses to bail on this silly selector, or is this some kind of bug?
The question: is there some official documented reason why Chrome chooses to bail on this silly selector, or is this some kind of bug?
After looking at the render events that occur when you hover the link, it looks like Chrome actually renders this change in display (I originally thought Chrome was ignoring it for performance reasons). In 1.65s, it captured 11360 events recalculating style and layout because of this change in display.
So why don't you see a flicker? Chrome is rendering the change at such a fast rate you won't see the change (or the browser just doesn't render it). When you switch to visibility: hidden, you see that flickr because the item is still in the render tree, just hidden (plus, it's slower, a lot less render events are firing).
I wonder why the other properties (e.g. color:red) aren't applied.
It's cascading, so the display: none is applied, then the red color. The same reason why you never see the hover state is the same reason why you don't see the color change.
Hope that helps!
I think display:none and hover at same time is causing the confusion to the browser. It works with visibility:hidden though.
display:block;
visibility:hidden;
color:red;
you can check it here: http://jsfiddle.net/MnZyx/2/
Is there a way, using either CSS or JavaScript, to get rid of the native Apple styling applied to focused DOM elements (e.g. the blue glow) in OS X or iOS)?
I've checked around online and I can't find anything relating to this subject. I'm about ready to give up hope on this, because I'm thinking since it's part of the OS itself (not just in the browsers) that it can't really be overwritten or avoided in any way.
I'm also interested in restyling Apple OS browsers' native scrollbars without using Javascript replacements, but with a solution that will work in all browsers. I'm vagely convinced that it's the same problem (part of the OS itself and thus not able to be styled by the browser) but I just thought I'd check.
Alternatively, I could use the -webkit-scrollbar pseudo elements CSS offers, but that'll only work in Chrome, Safari, and other webkit browsers, right?
Thanks for any help! <3
Using outline:none; on the element in question works great.
For more info, see the question " How to remove the border highlight on an input text element " as posted by the user j08691 in the comments on my question.
Note: I've tried searching on google, but couldn't find what I was looking for.
Browsers have some default styles they use for rendering form elements, which is different from browser to browser. Is there a way to reset all of the native browser styles for form elements like select, radios, checkbox etc, to make a consistent look across browsers?
I've made a quick example:
form elements http://grab.by/grabs/34db87ee1ad93e031cc72808feb2c8e7.png
As can see the form elements are rendered slightly differently. What I would like, is some styles, that can reset them, to look alike, for IE, Firefox and Webkit.
So how do you do this? A link to a css stylesheet with all the needed styles would be fantastic.
Short answer: you can't.
Long answer: you can, but expect pain.
I've hacked together nice looking Radio buttons, Checkboxes and Selects with 'sleight of hand' javascript + css. Basically, just after an input is loaded I hide it and replace it with labels / divs with events bound to them to make them act like they're the right inputs, and css to make them look that way. The events also update the underlying input so that the correct values are submitted with the rest of the form. If my script barfs or JS is off, the user gets the normal controls.
It wasn't that fun but the result is passable.
I do not look forward to seeing the mess IE makes of it though :)
I had inspiration from:
http://sourceforge.net/projects/selectreplace/?showfeed=code
This is an old question now but adding the CSS rule -webkit-appearance:none may help remove default Webkit styling, e.g. pill shaped buttons on Mobile Safari.
I'm trying to learn CSS. I've taken great pains to get everything right. My pages all validate and they look correct on Firefox and mostly correct on Chrome. However IE is all over the place. In relation to Firefox, the following is wrong in IE (in order of importance):
the main body box is pushed below where the left boxes end
the upper-right drop-down stuff (mouse over "Settings") is totally off in the weeds (it's off in Chrome also but in a different way)
"Recipes" tab is supposed to have no visible bottom border
search button is askew in relation to search box
logged out version: the upper-right login elements are askew
Logged in,
Logged out,
CSS,
Links, functionality, etc. are not guaranteed to work on these pages. It's just static snapshots to show layout.
Can anyone point me in the right direction for whatever I'm doing wrong?
You need to Reset your CSS (Dean, above recommends Eric Meyer's Reset CSS). I prefer Yui Reset CSS (I actually like their own Reset / Fonts / Grids CSS). As part of doing this you also need to use Standards Mode.
Finally, you need to be aware that some things will differ in browsers no matter what. So if you run into this situation, it's either work around it, or live with it.
What version of IE are you running? Sounds like most of your issues may be caused by the IE Box Model Bug.
I never start a new website design in css without putting Eric Meyer's Reset CSS in first.
It resets all the differences in all the browsers, so that you've got a even playing field to start from.
From there-out, everything should be the same in all browsers.