This question already has answers here:
Flex / Grid layouts not working on button or fieldset elements
(3 answers)
Closed 6 years ago.
I'm looking to use Flexbox to align an svg and the text within a button and all is working well in Chrome and Safari, but in Firefox there seems to be a problem.
This codepen should demonstrate the problem live.
Please note that I am pulling in https://github.com/mastastealth/sass-flex-mixin/blob/master/_flex.scss as an external CSS sheet in the codepen.
http://codepen.io/dominicchapman/pen/EgNgoq
SCSS as follows:
.Button {
border: 0 none;
height: 32px;
padding: 0 16px;
font-size: 14px;
background-color: orange;
color: white;
.Icon {
fill: white;
}
&:hover, &:active {
background: red;
}
}
.Button__icon {
#include inline-flex;
#include align-items(center);
.Icon {
margin-right: 11px;
height:16px;
width:6px
}
}
Any help would be greatly appreciated. Thanks in advance.
The problem is that Firefox does not fully support flexbox in <button> elements.
It's strange because the child boxes are blockified, and that's why you see the contents in different lines. However, the button does not seem to establish a flex formatting context. All flex properties are ignored.
I would understand not supporting flexbox on buttons, but IMO this strange mix is nonsense. However, mozilla people didn't see any problem.
Luckily they reconsidered and bug 984869 was reopened. But no work is actively been done on it.
Related
This question already has answers here:
Is there a reason why CSS doesn't support ids and classes, starting from numbers?
(8 answers)
Closed 8 years ago.
I have this html;
<div class="1"><br/>hi</div>
<div class="2"><br/>hi</div>
<div class="3"><br/>hi</div>
<div class="4"><br/>hi</div>
and then I added normal CSS formatting to the divs;
div{
height: 100px;
width: 100px;
border-radius: 100%;
margin: 20px;
display: inline-block;
text-align: center;
}
and then i wanted each div to be a different colour so I used the classes like this;
.1{
background-color: pink;
}
.2{
background-color: red;
}
.3{
background-color: orange;
}
.4{
background-color: yellow;
}
I am writing this in dreamweaver and when i click on the divs the little class thing tells me that they are coloured and the code is working, but when i preview in a browser the colours are not showing up and I just get the div part of the CSS.
it's probably very obvious but I can't think of why this is happening.
Thanks :)
Please avoid using classes with number at the beginning. It will fail for sure.
You can use for example cl1, cl2, cl3, etc.
Friends,
My question is why Firefox adds additional pixel (padding) below the box if I use display: inline-block?
Let's see what we have here: http://jsfiddle.net/xbU5s/9/
HTML - Two perfectly same elements.
<div class="wrap">
<section class="ib">Hello world</section>
<section class="il">Hello world</section>
</div>
CSS - Everything is the same, but our first section is inline-block and second one is inline.
.wrap { font-size: 0; }
.ib { display: inline-block; }
.il { display: inline; margin-left: 10px; }
section {
background: #000; border-radius: 3px; color: #fff; font-size: 11px; font-family: Sans-serif;
padding: 3px 5px;
}
And here's our 1px padding:
display: inline-block; vs display: inline;
Is is just rendering glitch (cause it's only happens in firefox) or I'm misinformed about inline-block's behavior?
Perhaps the answer is already explained here in old post
I will like to clear the difference..
If the element is with style display:inline the style restricts the object in line-height.
But, when block comes with inline the behavior of the same changes.
It is inline but with block it will expand to the possible height or width available.
For a change. select the text in both the box, you will see the second box is selecting out of the box. that is overflow of line-height which is restricted by inline but with inline-block it will grow with overflow caused by padding + line-height
I think this will clear most of the doubts, please refer the old post for more details.
This question already has answers here:
Why do the :before and :after pseudo-elements require a 'content' property?
(5 answers)
Closed 7 years ago.
I have a button and on a :hover I would like an after element to show. But I can't see it. Is it possible to have an :after element on a button?
.button {
cursor: pointer;
height: 30px;
}
.button-primary {
border: none;
}
.button-primary:hover:after {
display: block;
position: relative;
top: 3px;
right: 3px;
width: 100px;
height: 5px;
}
<button class="button button-primary">My button</button>
This should now work on all up to date browsers.
To get it to work, you need to add content:""; in your after.
Yes you can use it – as long as you as don't need to support some very old browsers, e.g. MS IE 7 or lower. I don't know of any other browser that doesn't understand pseudo elements on empty HTML tags. In fact I already used it in several production sites without any problems.
It seems there is some magic around the <button>element that I don't understand.
Consider this markup:
<button class="button">Some Text</button>
<div class="button">Some Text</div>
And this CSS:
.button{
background: darkgrey;
height: 40px;
border: 2px solid grey;
width: 100%;
box-sizing: border-box;
font-size: 14px;
font-family: helvetica;
text-align: center;
margin-bottom: 20px;
/*I'm aware I could use this to center it*/
/*line-height: 40px;*/
}
What makes the text in the button element vertically centered? Webkit seems to predefine a -webkit-box-align with a value of center for the <button> element. If I set that to initial the text is no longer aligned to the center. But that doesn't seem to be the full magic, since on the other hand I had no luck centering the text on the div using the -webkit-box-align property.
Here is a fiddle: http://jsfiddle.net/cburgdorf/G5Dgz/
I know this is a couple of years old, but I'll add my thoughts after some investigation in to issue while writing a reset stylesheet for a project.
NOTE** This is based on looking through the Firefox source because it was the easiest to obtain and read through. However, based on similar behaviour in other browsers the implementation is probably similar.
Firstly, the main issue here is that <button> elements - atleast in Firefox - are built with an internal element between the <button> tag and it's children. In Firefox it's called moz-button-content and isn't something that can be reached with CSS and has been set to display block without inheriting the height of the button, you can see this style declaration in the useragent stylesheet:
From "source/layout/style/res/forms.css"
*|*::-moz-button-content {
display: block;
/* Please keep the Multicol/Flex/Grid/Align sections below in sync with
::-moz-scrolled-content in ua.css and ::-moz-fieldset-content above. */
/* Multicol container */
-moz-column-count: inherit;
-moz-column-width: inherit;
-moz-column-gap: inherit;
-moz-column-rule: inherit;
-moz-column-fill: inherit;
/* Flex container */
flex-direction: inherit;
flex-wrap: inherit;
/* -webkit-box container (aliased from -webkit versions to -moz versions) */
-moz-box-orient: inherit;
-moz-box-direction: inherit;
-moz-box-pack: inherit;
-moz-box-align: inherit;
/* Grid container */
grid-auto-columns: inherit;
grid-auto-rows: inherit;
grid-auto-flow: inherit;
grid-column-gap: inherit;
grid-row-gap: inherit;
grid-template-areas: inherit;
grid-template-columns: inherit;
grid-template-rows: inherit;
/* CSS Align */
align-content: inherit;
align-items: inherit;
justify-content: inherit;
justify-items: inherit;
}
Because you can't affect any of the styles on this element, you are forced to add you styling on the <button> tags. This leads into the second issue - The browser is hard coded to vertically position the content of the button.
From "source/layout/forms/nsHTMLButtonControlFrame.cpp"
// Center child in the block-direction in the button
// (technically, inside of the button's focus-padding area)
nscoord extraSpace =
buttonContentBox.BSize(wm) - contentsDesiredSize.BSize(wm);
childPos.B(wm) = std::max(0, extraSpace / 2);
// Adjust childPos.B() to be in terms of the button's frame-rect:
childPos.B(wm) += clbp.BStart(wm);
nsSize containerSize = (buttonContentBox + clbp.Size(wm)).GetPhysicalSize(wm);
// Place the child
FinishReflowChild(aFirstKid, aPresContext, contentsDesiredSize,
&contentsReflowInput, wm, childPos, containerSize,
ReflowChildFlags::Default);
Given these two issues you can start to see how the button force the content to be centered, consider:
<button> tag
+------------------------+ ^
| button extra space | |
| | |
+------------------------+ |
|| ::moz-button-content || | button height
|| display: block; || |
+------------------------+ |
| | |
| button extra space | |
+------------------------+ v
If you give the button a height - like the 48px from your fiddle, the text will be centered because the moz-button-content element is display block and will only have the height of the content (most likely the line-height of the content by default) and when put next to another element you get this behaviour:
* {
box-sizing: border-box;
margin: 0;
border: 0;
padding: 0;
font-family: san-serif;
background: none;
font-size: 1em;
line-height:1;
vertical-align: baseline;
}
button, a {
height: 3em;
}
button {
background: red;
}
a {
display:inline-block;
background: green;
}
<button>Button content</button>
<a>Link Content</a>
This bug and this bug in the Firefox issue tracker was about a close as I could find to any actually documented bug. But the threads give the impression that despite this not appearing in any actual spec, the browsers have just implemented it this way "because the other browsers are doing it that way"
There is a work-around to the issue if you actually want to change the default behaviour, but it doesn't completely solve the problem and YMMV depending on your implementation.
If you insert a wrapper <span> with display: block as the only child of the button and put all your content inside it you can use it to skip over the moz-button-content element.
You will need to make this <span> element have height: inherit so it correctly fills the height of the button and then add your normal button styling to the <span> instead, you will get basically behaviour you want.
* {
box-sizing: border-box;
margin: 0;
border: 0;
padding: 0;
font-family: san-serif;
background: none;
font-size: 1em;
line-height:1;
vertical-align: baseline;
}
button, a {
height: 3em;
}
button {
background: red;
}
button::-moz-focus-inner {
border: 0;
padding: 0;
outline: 0;
}
button > span {
display: block;
height: inherit;
}
a {
display:inline-block;
background: green;
}
button.styled > span , a.styled{
padding: 10px;
background: yellow;
}
<button><span>Button content</span></button>
<a><span>Link Content<span></a><br/>
<button class="styled"><span>Button content</span></button>
<a class="styled"><span>Link Content<span></a>
It's also worth mentioning the appearance CSS4 rule (Not yet available):
While this is not a viable option (as of the 5th January) yet. There is a proposal to redefine the appearance rule in the CSS4 draft that might actually do the right thing an remove all assumptions made by the browser. I only mention it for completeness because it may become useful in the future.
UPDATE - 30/08/2016
You should actually use a <span> instead of a <div>, as div's aren't valid children for <button> elements. I have updated the answer to reflect this.
You could use padding.
For example
padding: 20px 10px;
I think that the only reason for this behaviour is that Google Chrome or browsers in general will take the default styles from your operating system.
For example, if you compare the button or scrollbar on Google Chrome run in windows 7 and windows 8:
In windows 7, the button will have a horizontal gradient line in the center of your button
In windows 8, the scrollbar are able to fade in and fadeout on click
This is just my opinion but hope that it can give you some ideas :)
You can use display:table-cell;
vertical-align: middle; as an alternate method.
On Mozilla Firefox I got the -moz-appearance property :
-moz-appareance: button;
In the HTML5 draft, there is a Rendering section, but doesn't details the placement :S
Button elements by default centers child elements vertically. It isn't done in a conventional CSS way, and therefor isn't trivial to override.
The best solution I have found is setting the button to flex column.
button {
height: 100px;
display: flex;
flex-direction: column;
}
span {
height: 20px;
width: 100px;
background-color: blue;
display: block;
}
<button>
<span></span>
</button>
Some answers suggested adding an inner wrapper, and setting it's height to inherit. This might not work for elements that have their height calculated dynamically.
In case you need to get rid of this behavior you can just add span as a child of button. Works better than trying to trick all the browsers.
I've created a template for WebSVN (see it in action here) and have worked hard to make it use web standards and validate. It looks great in most browsers, but as I feared, IE 6 and IE 7 can't quite hack it. In my case, the problem is that they refuse to render the unordered list for my navigation horizontally — they both display each <li> on a separate line and overflow the allotted vertical space. (IE 8 behaves correctly, and looks very close to Firefox and Safari, which was a pleasant surprise.)
I haven't been able to find a suitable solution on Google or SO. I would prefer a CSS fix, rather than JavaScript or something similar, although that's not entirely off the table. (Also, I don't care about the PNG transparency issue in IE 6 — it doesn't hurt readability at all, and IE 7 and 8 both handle it perfectly.)
Edit: Here are relevant snippets of HTML and CSS:
HTML
<ul id="links">
<li class="diff">Compare with Previous</li>
<li class="rev">Changes</li>
<li class="log">View Log</li>
<li class="download">Download</li>
<li class="svn">SVN</li>
<li class="rss">RSS feed</li>
</ul>
CSS
#links {
padding: 0;
margin: 0;
text-align: center;
background: url(images/bg-gray-light.png) repeat-x 0 top;
border-bottom: solid 1px #a1a5a9;
}
#links li {
font-size: 110%;
display: inline-block;
padding: 5px 5px 4px;
white-space: nowrap;
}
Edit: Now that I've found a solution, the linked page won't (shouldn't?) misbehave any more in this situation, but will continue to be publicly available.
It turns out that IE 6 and 7 don't implement inline-block as expected. Looks like I found a good solution, though... Using the following CSS works for those browsers, and preserves the correct formatting in newer browsers:
#links {
padding: 0 0 4px;
margin: 0;
text-align: center;
background: url(images/bg-gray-light.png) repeat-x 0 top;
border-bottom: solid 1px #a1a5a9;
}
#links li {
font-size: 110%;
display: inline-block;
padding: 5px 5px 0;
white-space: nowrap;
}
* html #links li {
display: inline;
}
I despise IE hacks.... I'm strongly considering including Pushup in my template.
It works fine for me in IE8 with compatability mode.
The only potential problem I can see is you don't specify margins on the list items. Try setting margin:0 and see if that helps.
Assigning float:left to the li elements should work, IIRC.