Escaping in LESS, either through e or ~ works pretty well in most of the cases. However, the declaration display: -webkit-box; doesn't show in the resulting CSS, even after using e or ~.
All other declarations of that class is present but display: -webkit-box;
What am I missing?
display: -moz-box / -webkit-box
Per MDN
This property is a non-standard extension. There was an old draft of the CSS3 Flexbox specification that defined a box-flex property, but that draft has since been superseded.
They also state:
Warning: This is a property for controlling parts of the XUL box model. It does not match either the old CSS Flexible Box Layout Module drafts for 'box-flex' (which were based on this property) or the behavior of '-webkit-box-flex' (which is based on those drafts).
Basically, don't use it...it has almost no browser support (except older versions of Firefox)
Related
I've used to vertically center block-elements like this:
.parent {
display: table-cell;
vertical-align: middle;
display: -webkit-box;
display: -ms-flexbox;
display: flex;
-webkit-box-align: center;
-ms-flex-align: center;
-ms-grid-row-align: center;
align-items: center;
}
When I need IE9 and lower support. Using css-tables as a fall-back for older IE-s of course. I don't need flex for anything else. But recently I started to ask myself: why do I even need flex here? Css-table is a robust solution supported by virtually every browser in this planet and according to this Ben Frain's article it's even faster. Isn't css-table enough here? When asking people about this I got answers like "flex is more modern" etc. That's fine and I do understand, that there are things that are only possible with flex, but it isn't really an answer here. We're talking about simplest centering block-elements.
So i have two questions:
Do i have to use flex in the case like this?
If "yes" - why?
There's a reason we moved from using tables in HTML as a layouting tool.
It's not semantic. When we think of a table we think of a representation of data.
MDN explains it well.
Prior to the creation of CSS, HTML elements were often used as
a method for page layout. This usage has been discouraged since HTML
4, and the element should not be used for layout purposes.
However, HTML emails are an exception where tables are still commonly
used for layout purposes. The reason for this is poor CSS support in
popular email clients.
So unless you're designing e-mail layouts do not use table elements or css table properties for layouting.
You can still use it if you need fallback hacks like in your example, but other than that use modern appropriate methods , be it grids ,flex , floats or whatever.
I was refactoring some code and decided to change the usual style="display:none" to use the HTML5 hidden attribute, in order to hide a button. Only to find that it is not compatible with bootstrap's btn class. That said, I will keep using the style display attribute but I wonder if this is a bug that should be reported or simply a feature that everyone should be aware of.
The corresponding jsfiddle can be found here
The HTML5 specification already warns developers about this:
Note: Because this attribute is typically implemented using CSS, it's also possible to override it using CSS. For instance, a rule that applies 'display: block' to all elements will cancel the effects of the hidden attribute. Authors therefore have to take care when writing their style sheets to make sure that the attribute is still styled as expected.
— The HTML5 Specification - 7.1 The hidden attribute
The problem you're having is that Bootstrap's .btn selector specifically defines display: inline-block, which overrides the hidden attribute's display: none.
This means that specificity is going to be an issue. This is a rare case of where !important may be desirable. I'd personally implement the following style rule:
[hidden] {
display: none !important;
}
This ensures that all elements with a hidden attribute will be set to not display, regardless of specificity. This is doubly good in that this will make the hidden attribute effective on any browser which supports the [att] selector notation (which is any browser which supports CSS2).
Working JSFiddle demo.
Try adding this to your css:
*[hidden] { display: none !important; }
for example; https://fiddle.jshell.net/bh8h5tya/
It's not hidden because bootstrap applies display: inline-block on the class .btn
Bootstrap provides the following .hidden class that you can use to show/hide elements. Try using that.
.hidden {
display: none !important;
}
The webpage is http://www.parentcenterhub.org/region6-aboutus/ It is displaying correctly on all browsers except IE9. The CSS is:
#primary { display: -webkit-box;
display: -moz-box;
display: -ms-flexbox;
display: -webkit-flex;
display: flex; }
The conditional css for ie 7 and ie 8 is:
.ie8 .content-area1{
width: 70%;
display: inline-block; }
.ie7 .content-area1{
width: 70%;
display: inline-block; }
There is no conditional css file for IE9. So, please suggest the code which I can put in style.css so that the page also displays correctly for IE9. Please help.
IE9 and doesn't support flexbox (see here for full browser support details), so you'll need to use something like your IE7/8 alternative layout for IE9.
You can work without having a conditional CSS for IE9 in one of several ways:
Use CSS's override mechanisms. Simply specify display:inline-block above display:flex (etc) inside the same selector, and every browser will pick the last defined option that they support. So if flex is below inline-block, IE9 will use inline-block because it doesn't understand flex, and others will use flex because they do know it and it's below inline-block. Sure, this doesn't deal with setting the width, but we've got half the problem solved without any browser-specific code at all (in fact, this would work for IE7/8 too, so you can reduce your specific code for them as well). width might be solvable with a similar trick by specifying a default value using a measurement unit not support in older browsers like rem or vmin or something, and then overridding it with % for the older browsers, but whether that would work for you would depend on your actual layout.
Use a library such as Modernizr, which will add feature support flags that you can use in the form of class names on your <body> tag. For example, it will add a flexbox class for browsers that support it, and a no-flexblox class for those that don't. This means you can write CSS code that targets browsers that support the feature or not -- eg:
.flexbox #primary {
display:flex; //etc...
}
.no-flexbox #primary {
display:inline-block;
width:70%;
}
Use a browser hack. I really don't like suggesting this, but it is an option. There are CSS hacks that specifically target IE9 if you really want to use them. I won't repeat them here though as I don't think it's the best option. If you want to use them, Google will tell you what you need to know.
Use an IE9-specific class just as you are currently for IE7 and IE8. You're doing it already, so it doesn't seem like it should be too much of a stretch.
Just use inline-block across the board. If the inline-block layout works, why not just use that. Flexbox is great, but if you need IE7/8/9 support, you're not going to be able to use it consistently, so....?
Personally, I'd go with the Modernizr solution. It solves this problem very neatly, and can also deal with most other cases where you might consider having browser-specific styles due to missing features.
I want to use flexbox for an app, and want all elements to be set do display: flex. Is that possible? if yes, how? I have alread set body { display: flex }, but it still does not apply to all body elements.
(I took my comments and turned them into an answer)
The universal selector would do the trick:
body * { display: flex; }
(Note that I've scoped it to only include elements within the body)
The universal selector can lead to (negligible, tiny, almost immeasurable) performance issues, but it's by far the simplest way of doing what you asked (given that the display property isn't inherited). The other option (a selector consisting of a massive list of all HTML) elements would take quite a long time to download and parse, too! As for best practise, I don't think either of them is a particularly awesome idea, but I don't know the details of your implementation.
The display property isn't inherited because it would wreak havoc! For example, the <a> element is an inline element. If it inherited display: block; from it's parent elements, all links would be full width and cause a line break (like a p, h1 or div). The inheritance bit of the (rather complicated) CSS2 spec is here: http://w3.org/TR/CSS2/cascade.html#inheritance
body { display: flex; } it will not work because it means apply flex to body.
instead
{display: flex;} it means apply flex to all element(selectors) in page. however I faced issue if using live server because it will apply flex to element also which is automatically applied to code editor(mine is vs code).
you can use this method
anyelement,.anyclass,#anyelement {display:flex;} adding comma after selectors means apply flex to all element which is written.
I need to know what value/ css would be set when I use display: initial on non CSS3 compliant browsers ?
I'm hiding the class using display:none & need to show back, for which I intend to use display: initial (I dont want to use display:block if previously it was display:inline) but the hidden element must be shown on all browsers.
What happens by CSS 2.1 rules on error handling as well as in practice is that the declaration display: initial is ignored, without affecting the rest of the style sheet. The display property thus gets its value from other rules. In the absence of any setting on it in any style sheet (including browser default style sheet), the initial value inline is used.
The “fallback” code in the edit of your question means that the value of display would be inline in browsers that support the value inline, and block in other browsers. This does not sound safe.
The value initial does not mean “the previous value set in a style sheet” or anything like that, as the question seems to postulate. Instead, it means the value that is designated as the property’s initial value in CSS specifications. For display, this is inline.
Ok, I found that providing a fallback would be a safer option. So I use like below:
{
display: block;// just as fallback
display: initial;
}
there is "run-in" value for display property explained in W3C Schools page
EDIT:
run-in value is supported by Internet Explorer, and interpret the element whether it is block-level or inline-level.
I made an example jsFiddle Example .