So a draft standard that's implemented in the current beta (alpha?) versions of Chrome and Firefox. So the end for the hack is nigh ... in about 5 years, I guess.
This isn't really true anymore. All the major browser vendors push out new releases pretty frequently. Even Apple and Microsoft tend to put out a new release at least every six months or so. And because of the ubiquity of software / OS updates, these tend to get deployed to the majority of users fairly rapidly.
For example, consider a feature like arrow function support in JavaScript: http://caniuse.com/#feat=arrow-functions
Click "usage relative" to scale by the relative popularity of different browser versions.
Despite only being standardised and implemented in browsers last year, arrow functions are already supported in the large majority of deployed web clients, including Edge, Firefox, Chrome and Safari, both desktop and mobile.
Nowadays, new features, particularly relatively small and uncontroversial ones like display: flex-root, can get implemented across browsers very quickly.
A lot of people still have to support IE10/11, including myself - until browser support is mostly on evergreen browsers & browsers keep up to date on implementing the new standards, ability to use the standards hinges upon a couple of years buffer in some cases.
As I already said: browser support is mostly on evergreen browsers, and browsers do keep up to date implementing the new standards. The stats make this very clear. To say otherwise is to promote a view of the world that is ten years out of date.
IE10/11 are at about ~4% global usage. Less than Opera Mini. And a large number of those users will have access to another browser. We've found many enterprises keep IE around to access legacy services, but let people install Chrome in order to access things that need a modern browser.
The days when it was worth supporting IE for new development work has long since passed. Company policies that mandate doing so should be challenged as a waste of time and money.
it doesn't mean anything for a business. for all you know 50% of users visiting a specific website could still be using IE10/11. global numbers were always irrelevant.
4% is a high number in this context. If I cause a problem for 4% of my users, I will be spending the next week answering support issues and nothing else. When it is two orders of magnitude less, then we can talk.
Yeah: 4% of users of my site means like 40,000 people :/. For websites that sell things, I always think of it in terms of "if you could do some more engineering work and get 4% more revenue, would you?". I do not understand people who feel like 4% is some tiny number.
But that revenue isn't free. It has a cost in terms of time and effort in engineering the IE support, and then maintaining it. This is time and effort that could be better spent enhancing the site in other ways. For example, ~20% of the US population has a disability[1]. Investing effort in improving accessibility would be more sensible, economically speaking, than maintaining IE support, but I still see developers spending hours working around IE CSS bugs, while doing almost nothing to improve accessibility.
I'd imagine the 20% of the US population that has a disability translates into rather less than 4% of potential users of the average website helped by any particular engineering solution...
(apart from basic common-sense design principles like not having tiny buttons or a layout so sensitive it breaks if people bump the text size up)
Most of the people in that 20% likely have a disability that keeps them from working or walking but not from using a computer in a normal fashion.
That said, you are responding to my incredulity, and I take disabilities sufficiently at least sufficiently seriously that a blind person presents every year at the conference we have been running for our ecosystem and we get tons of praise for our support of their issues.
In some cases, I will even argue that supporting old browsers is related to accessibility: if you are making a product such as a communications tool, one where many if not most users don't directly pay you for their use as you make money from a subset of users, people on older browsers are often people with older computers, who have lower income and less ability to arbitrarily plunk down money to upgrade their technology.
Just as we legally mandate people consider the needs of the disabled, I personally think we might be in need of some regulation that demands we also consider the needs of the poor and disconnected: there are tons of users (by which I mean "entire percentage points, by number competitive with blind people as a group of users but with less sympathy from the public") using older versions of browsers because they were stranded by Apple on an older iPod or iPhone with an out-of-date version of MobileSafari, or who would have to pay for a new version of Windows to even be able to use Chrome, or whose only access to a computer is a shared facility where the computers run something they have no control over. When we build websites that don't let them use our service, we essentially are building an implicit class hierarchy.
Me challenging them is what got me not supporting IE9 :) .
Global usage is not the number that matters for businesses though - it's userbase percentage, and unfortunately that number for IE is quite higher than I'd like (over 10%).
Floats remain useful for their original purpose: floating an inset piece of content inside a wider textual context e.g. an illustration picture or a pull quote. And for that you might still need a clearfix-type workaround.
Yes, and further to this - genuine question - Why would you use float-based layouts over flexbox for reasons other than backwards compatibility?
About the only reason I can think of off the top of my head is that you / your team already fully grok floats, they are sufficiently powerful for your use case, and you don't want to invest the time to learn flexbox to achieve the same outcome as you could already achieve.
In this case, flexbox actually is a bit awkward - one is often forced to pair flexbox with calc in this sort of situation. If the content, including text, is too long, it pushes the right container down a level unless the width is fixed to an appropriate size - this is doable with calc (for fluid layout) if one has control over the size of the left container, but otherwise it may be difficult to obtain the desired UI with flexbox.
I really like flexbox, but its still missing functionality and somewhat misleading in its options. Everything is row-column based, but you can select between row or column, but in the column option, only justify-content will position content vertically. If you want something like forcing an element to be in the middle vertically, and have an element above it, you can't do that. align-self only works on rows. I really don't understand why they didn't make it work vertically if you have column mode.
In this case, I needed two children elements, one would be centered vertically in the column, and the other would be at the top of the column, but they would not effect each others position. I could only make one where the two elements were next to each other, or they effected each others positions, so the centered element was not actually centered. I ended up putting in three elements, the bottom one the same size as the top, but hidden, so the center element would stick between the two.
Do you have an example that would accomplish that? As in, one element centered vertically to the parent flexbox, and its sibling attached to the top of the column, but not effecting each others position?
Is there any reason to not use flexboxes nowadays? I've still been using floats, inline-block, etc. so my websites are compatible with older browsers, but I would rather just switch to using all of the new CSS properties.
There are a couple of bugs with IE and older versions of the stock (deprecated) Android browser using flexbox, but I think they're all handled easily enough. Also, they don't work with IE9 - God forbid you're still supporting that browser.
Do you think Gov.uk should be supporting that 0.25% of users, seems like it's probably a waste of resources. Can't you just settle for graceful degradation? Is there some DDA angle (supporting screenreaders) or other mitigation that's not obvious?
It’s not about percentages, it’s about numbers. We don’t actually go out of our way to support it on pages and we don’t tell other departments to test in it, but if you’re building a pattern library it makes sense to do the hard work up front. In terms of graceful degradation, yep. In our current patterns project we’ve dropped all JS for IE7 beyond the HTML5shim.
Like 5% of our traffic comes from IE 6-8.... Thank god for jQuery. And, I can't recall the percentage, but a surprisingly large amount from the stock Android browser (not Chrome, the one that ships on really old phones).
We have internal support for IE9. Our non-internal traffic for it is almost non-existent. We were getting a small portion of traffic from the stock Android browser as well, but we were finally able to convince them to drop support for it.
We're also on the cusp of CSS grids being available in all major browsers, and – considering people have started upgrading much faster – it should be supported for >95% of users within the next year.
I'm not really a front-end kind of person, but whenever I've written any CSS this has, I think, literally always bitten me. I try to read about it and understand it 'properly' every time, but clearly I never do.
Why is the unhacked behaviour desirable? If I put a thing in a thing, surely I want it to stay in the thing?!
Because the original purpose of floats is not layout (where you want the thing to stay in the other thing) it's typographic floats, like pull quotes or info boxes or pictures. In that case, even if your float is in a paragraph you don't want to "expand" the paragraph past the end of the float if the float is longer than the paragraph, you want the following paragraph to be laid out around the float instead.
That floats were press-ganged into layout does not mean their basic behaviour is bad, it just means they were used for something that was never intended (due to a lack of actual layout tools in CSS until CSS3) and they were not very good at it.
And note that the lack of layout tools was not limited to "applicative" layouts, most papers are laid out in multiple text columns yet that fairly simple and common layout was not supported either until CSS3.
Oh, I see what happened. I have a minimum font size which makes the first paragraph tall enough so that it wraps all the way around the image -- so the clearfix is effectively redundant with my font sizes. The image clears it up, thanks!
I don't like the idea that this is tacked onto the "display" property. "display" is for the outer display properties of the div, but this flow-root is for the inside.
You cannot have a div that is both `display: inline-block` and `display: flow-root` at the same time, for example.
> I don't like the idea that this is tacked onto the "display" property. "display" is for the outer display properties of the div
That's really not true[0], "display: flex", "display: grid" or "display: table" are all inner display properties, which is why inline-flex, inline-grid or inline-table exist ("display: flex" sets the outer display mode to "block" and the inner one to "flex", "display: inline-flex" sets the outer display mode to "inline" and the inner one to "flex").
Which is why CSS3 split display properties between outer display (block, inline or run-in) and inner display (flow, flow-root, table, flex, grid or ruby), which can be specified independently e.g. `display: inline flow-root`.
Furthermore `display: inline-block flow-root` makes no sense
1. `inline-block` is specifically a "legacy" display property which impacts both inner and outer display (and thus is not compatible with a separate inner display property)
2. `inline-block` already means `inline flow-root` so `display: inline-block flow-root` would expand to `display: inline flow-root flow-root`
[0] and has not been since CSS2 and display: table, possibly CSS1's display: list-item
It is already that, it's been that pretty much all along, but for most of its history you couldn't set the inner and outer variants separately, you had to use "precomposed" values like inline-table. AFAIK you can't set the inner and outer display types via separate properties.
Furthermore there are values which have more complex interactions/natures than just inner/outer e.g. "contents" (which removes the element's box but leaves the descendants — including pseudo-elements), "list-item" (which can be combined with any outer type but only the flow or flow-root inner types, and generates an internal pseudo-element), or the "internal values" which only make sense within wider display context (table and ruby).
There was, briefly, in Display Level 3 drafts, display-inline and display-outside properties, with display being a shorthand additionally supporting legacy values (like inline-block). It's now expected to be in Level 4[1].
I do agree, we still need to wait for all older browser to implement this (especially think of all the mobile browsers nowadays).
If making a polyfill is the solution, we risk ending up with a bigger polyfill file than the actual CSS implementation in the browser. If that is the case we can better do styling with JS.
I've never had to use the clearfix hack (that's probably a lie, but I can't recall a time in my career where I didn't just use the display: table; width: 100%; method)
It wasn't supported until IE8. For those of us who had to support IE6 till well after its sell-by date, prop-based clearing was an important tool in the toolbox.
`float` should not be used for layouts, but for placement an image inside text ( e.g ), which is it's purpose.
Nowadays I don't use floats anymore. Flexbox is the current layout recommendation and I encourage you not to create legacy CSS stylesheet layouts with float.
I've seen enough comments about using floats for layout that I think some people need to read the article. The example in the article is not using float for layout. It is using it for the original purpose, floating an element to the side for other elements to flow around. The problem shown is when the floated element is taller than the resulting containing parent. Which is a common problem and a valid use of float.
To make a child element the same height as the parent, you can set the parent container to position: relative, and in the child element, set it to position: absolute; top: 0; bottom: 0. The downside of this trick is that the child element is now absolutely positioned and no longer behaves the same. Alternatively, you can use flexbox to do this, if using it is an option.
My favorite use of this is making a resizable box that always maintains the same aspect ratio. Padding % is out of the element's width. So width: 100%, padding-top: 50% will make a block that is 2:1 that resizes automatically.
80 comments
[ 3.0 ms ] story [ 193 ms ] threadIt looks like the difference may be some legacy IE6 thing.
In ancient times some browsers required setting a width or height as well.
For example, consider a feature like arrow function support in JavaScript: http://caniuse.com/#feat=arrow-functions Click "usage relative" to scale by the relative popularity of different browser versions.
Despite only being standardised and implemented in browsers last year, arrow functions are already supported in the large majority of deployed web clients, including Edge, Firefox, Chrome and Safari, both desktop and mobile.
Nowadays, new features, particularly relatively small and uncontroversial ones like display: flex-root, can get implemented across browsers very quickly.
It still is largely true unfortunately.
IE10/11 are at about ~4% global usage. Less than Opera Mini. And a large number of those users will have access to another browser. We've found many enterprises keep IE around to access legacy services, but let people install Chrome in order to access things that need a modern browser.
The days when it was worth supporting IE for new development work has long since passed. Company policies that mandate doing so should be challenged as a waste of time and money.
it doesn't mean anything for a business. for all you know 50% of users visiting a specific website could still be using IE10/11. global numbers were always irrelevant.
[1] http://www.census.gov/newsroom/releases/archives/facts_for_f...
That said, you are responding to my incredulity, and I take disabilities sufficiently at least sufficiently seriously that a blind person presents every year at the conference we have been running for our ecosystem and we get tons of praise for our support of their issues.
In some cases, I will even argue that supporting old browsers is related to accessibility: if you are making a product such as a communications tool, one where many if not most users don't directly pay you for their use as you make money from a subset of users, people on older browsers are often people with older computers, who have lower income and less ability to arbitrarily plunk down money to upgrade their technology.
Just as we legally mandate people consider the needs of the disabled, I personally think we might be in need of some regulation that demands we also consider the needs of the poor and disconnected: there are tons of users (by which I mean "entire percentage points, by number competitive with blind people as a group of users but with less sympathy from the public") using older versions of browsers because they were stranded by Apple on an older iPod or iPhone with an out-of-date version of MobileSafari, or who would have to pay for a new version of Windows to even be able to use Chrome, or whose only access to a computer is a shared facility where the computers run something they have no control over. When we build websites that don't let them use our service, we essentially are building an implicit class hierarchy.
Global usage is not the number that matters for businesses though - it's userbase percentage, and unfortunately that number for IE is quite higher than I'd like (over 10%).
About the only reason I can think of off the top of my head is that you / your team already fully grok floats, they are sufficiently powerful for your use case, and you don't want to invest the time to learn flexbox to achieve the same outcome as you could already achieve.
http://susy.oddbird.net/
Our support schedule is at https://www.gov.uk/service-manual/technology/designing-for-d...
The linked article uses an image floated left, with text wrapping around it. Curious to know how you'd [sanely] accomplish the same result in flexbox?
Floats aren't just for structural layout. Even with 100% browser support for Flexbox, I'll still be floating some things.
In fact floats aren't for structural layout at all, they were used for it because there were no structural layout tools available at the time.
Why is the unhacked behaviour desirable? If I put a thing in a thing, surely I want it to stay in the thing?!
Here's a demo: http://codepen.io/anon/pen/ggGgWb
Here's the "clearfixed" version which is nonsensical: http://codepen.io/anon/pen/xgXgry
That floats were press-ganged into layout does not mean their basic behaviour is bad, it just means they were used for something that was never intended (due to a lack of actual layout tools in CSS until CSS3) and they were not very good at it.
And note that the lack of layout tools was not limited to "applicative" layouts, most papers are laid out in multiple text columns yet that fairly simple and common layout was not supported either until CSS3.
You cannot have a div that is both `display: inline-block` and `display: flow-root` at the same time, for example.
That's really not true[0], "display: flex", "display: grid" or "display: table" are all inner display properties, which is why inline-flex, inline-grid or inline-table exist ("display: flex" sets the outer display mode to "block" and the inner one to "flex", "display: inline-flex" sets the outer display mode to "inline" and the inner one to "flex").
Which is why CSS3 split display properties between outer display (block, inline or run-in) and inner display (flow, flow-root, table, flex, grid or ruby), which can be specified independently e.g. `display: inline flow-root`.
Furthermore `display: inline-block flow-root` makes no sense
1. `inline-block` is specifically a "legacy" display property which impacts both inner and outer display (and thus is not compatible with a separate inner display property)
2. `inline-block` already means `inline flow-root` so `display: inline-block flow-root` would expand to `display: inline flow-root flow-root`
[0] and has not been since CSS2 and display: table, possibly CSS1's display: list-item
Furthermore there are values which have more complex interactions/natures than just inner/outer e.g. "contents" (which removes the element's box but leaves the descendants — including pseudo-elements), "list-item" (which can be combined with any outer type but only the flow or flow-root inner types, and generates an internal pseudo-element), or the "internal values" which only make sense within wider display context (table and ruby).
[1]: https://lists.w3.org/Archives/Public/www-style/2014Sep/0399....
(Obviously: starting from date supporting old browsers costs more than supporting them brings in, which depends on your product and your customers)
Not until all browswers support it.
If making a polyfill is the solution, we risk ending up with a bigger polyfill file than the actual CSS implementation in the browser. If that is the case we can better do styling with JS.
I've never had to use the clearfix hack (that's probably a lie, but I can't recall a time in my career where I didn't just use the display: table; width: 100%; method)
Nowadays I don't use floats anymore. Flexbox is the current layout recommendation and I encourage you not to create legacy CSS stylesheet layouts with float.
'Some people, when confronted with a layout problem, think "I know, I'll use floats." Now they have two problems.'
I've had difficulties implementing similar things in the past.