CSS <button> Reset: Vertical Label Position? - css

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

Related

View inherited CSS properties for hovered element

I have encountered an annoying problem while trying to debug some CSS in Chrome. I am rather new to CSS, and using Chrome's "Computed" window in the CSS developer tools has been very handy in figuring out where CSS properties I'm trying to assign are being overwritten later down the chain. (Please feel free to correct any incorrect terminology so I can be on the same page).
Here's an example of how it helped me successfully change the color for an active jQuery UI Tab:
http://1drv.ms/1yJzyec (don't have enough rep points yet to post a picture. This goes to my OneDrive.)
I need to use this approach to figure out what's going wrong with my CSS for a hovered or focused element. Here's the problem: as soon as I click into Chrome's developer tools to see the chain of inheritance for a specified element, it is no longer hovered/focused because I've clicked into the developer tools, preventing me from seeing the inheritance.
Are there any other tools out there that can help me dissect an HTML element's CSS inheritance chain in real-time?
Thanks!
Using Chrome developer tools, you can force the element to be in the hovered state.
Click on the Toggle Element State icon (dash-bordered box with pointer) to show this.

:active pseudo-class not triggered for input[type=button] on IE 9

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.

:empty pseudoclass when adding dynamic content

I have read in this sitepoint page and quirksmode page about the new :empty pseudoclass.
Sitepoint said that even when there is dynamic content appended, the empty style will still take effect. It is noted that firefox was the one who behaves this way.
Quirksmode said that it discards the empty state when it it filled in with some elements or text. the demo on this site works in my browser (chrome 19). So i assumed only firefox would be buggy.
However I have this piece of code in my plugin, which dynamically fills up a list with items, it doesn't seem to work, here's a fiddle which appends list items, even if you click the button, the items won't appear until you try to debug it in the console (they magically appear when you click the <li> in the element tree).
Why is this happening, and is there a work around to "force-discard" the empty style?
I know there are other ways to do what I am doing in the fiddle (and currently doing one of these "other ways"), but the :empty method is a lot easier.
UPDATE:
added a remove item button. when the last item is removed, the list should disappear - still doesn't work. hmmm.. i'll try to check in another browser.
FIX
Temporary fix/alternative to using :empty and display:none is to have the element have zero width, height, borders, margins, and paddings. additionally, position:absolute to remove it from the flow.
The fiddle you provided works for me with FF10 and IE9. It only fails in Chrome (18+)
Not sure why this happens, as the quirksmode page works in Chrome as well..
For the force-discard it seems to be do-able by setting almost any css property with code..
example at http://jsfiddle.net/gaby/YprUV/9/
Update
Ok, i found this Chrome bug report that is about :empty selector misbehaving when used with display:none
It is marked as fixed, but perhaps we should re-oopen it..
Here is a test that does not use display:none (it just changes the background color) and it works just fine.. http://jsfiddle.net/YprUV/11/

Verify what css hover state is activated

I have a site where the background-image jumps up on hover state and I can't for the life of me find the specific css that does this.
I'm able to get to the "offending" link and give it a border and change the padding and margin. The problem is that firebug and chrome inspect does not show me what happens on the hover state.
So I want a way to see what additions to the normal css state happens on :hover.
Any pointers?
(P.S. IE 8 doesn't have this issue - ie no jumping of background image)
Try using the Inspect function in FireBug to focus in on the element in question. It will show you all related CSS, including any CSS that is related to :hover. You can also see in this way what changes happen to the elements CSS (and any other DOM attribute) when you hover your mouse.
In case the changes are coming from some JavaScript, try out the Visual Event bookmarklet. Activating it on the page will let you see all events that are tied to the element in question.

Button Text dissapears using overflow:visible within IE7

In Internet Explorer, there is unnecessary padding that occurs to the left and right within the button when the button name is large. As a result of this, the known solution is to add "width: auto" and "overflow:visible" to the button style, but doing so will inadvertently make the text in the button disappear when the user scrolls the page down and then back up.
I would very much like to use the style I've included so the padding stays removed, but more importantly resolve the issue with the button text disappearing. It's really an odd one!
I've created this DEMO page for you to test the code where it's happening: http://jsbin.com/uhuze3
Note: You'll need IE7 to see the issue, so for those who don't have it, I create this video for you to see the issue. http://screencast.com/t/MTg0NzY2Zj
I was able to resolve this and improve the code a bit.
You can see the code here:
http://jsbin.com/uhuze3/4
This was the old code:
http://jsbin.com/uhuze3
Edit by Johnny5 :
It seem to be the combinaison of "height" and "line-height" that correct the bug.

Resources