I'm not a front-end guy, hell, I'm barely even a developer these days. This could be the best thing for CSS ever and I wouldn't be able to recognize it, so I'm not dissing the authors.
But I have to ask: isn't any "solution" that requires IE 11+ practically useless to the point of being fictional for at least the next decade?
It certainly can make business sense to use technologies that aren't yet supported by 100% of browsers in the wild.
• Websites that are mobile-only
• Things that aren't websites but use HTML5 for UI (e.g. many native mobile and desktop apps do this, browser extensions, 'installable web apps' for Chrome etc.)
• Websites for whom the IE audience is such a minority that it's worth either (a) blocking them out and asking them to upgrade, or (b) maintaining a minimal-effort fallback stylesheet for IE users so they can at least access a low-fi version of the site – in return for the gains in performance and UI quality that the vast majority of users get, and for incalculable benefits in developer happiness and productivity.
I do front-end for a newspaper website and I have to offer some support right down to IE7, but it's a realistic guideline (some support – content basically visible, with warnings displayed to those users suggesting they upgrade). If we were to restrict ourselves to browser features supported by 100% of our users, this would be a lowest-common-denominator approach led by the most low-tech 5% of our users, which would give us a big competitive disadvantage. I use new browser features all the time, and fallbacks for IE users. I haven't used Flexbox yet, but I wouldn't hold back if it meant we could implement something good for a large proportion of our users (especially since that proportion is likely to be made up of the users who are responsible for most of our revenue).
It's actually not as bad as you think. IE updates are now being released as critical so they're being included in OS updates.
That means that most IE users will be upgrading to the latest IE of whatever OS they're using. So when Window XP is officially abandoned (scheduled for spring 2014), it won't be long until most IE users are on the latest version.
Third party support businesses stand to make a pretty profit off of Microsoft ditching support for XP. I'm afraid XP will live on for quite some time after it's officially unsupported.
The medical field is perhaps one of the largest supporters of these ancient systems. I can't tell you how many times I've heard my medical friends say they use EMR and documentation software that ONLY works in IE6. You think those underfunded nursing homes and second rate hospitals are going to spend thousands updating their systems?
So, they better make arrangements to get Chrome or Firefox installed along side of IE6. The reality is that IE6 support is not going to happen. It's not worth the extra cost of development.
You are assuming that most people will abandon XP when it is officially abandoned, I'm not sure that lack of official support will convince users to embark on a disruptive upgrade to Windows 8.
I know my company would never support a browser that wasn't even supported by its maker, and I'm sure a lot of companies wouldn't either.
If you have "customers" you'll probably drop IE8 support quickly in 2014. If you just have "visitors", and if those visitors are international, it might take longer.
Windows XP users maybe aren't the best clients of your product or the clients who will pay for it. Nobody with ancient stuff can pretend to have the whole tech advancements.
Windows XP users aren't able to install many, many things nowadays, what make you think they will be shocked to know they're really can see the majority of the websites well.
The other day i was demoing a friend my old macbook (2002) and all the major websites were simply, broken. We didn't have any "omg look". It's normal to experiment this before they enter your website.
Back when I worked for a company selling expensive software and services to large companies and government agencies, I quickly learnt that there is zero correlation between how much a department is willing to spend on hardware and how much they are willing to spend on software running on those computers. Signing off on a $20000 software license while refusing to replace an ancient 19" lcd screens is perfectly normal as hardware and software normally come from two different budgets and procured entirely differently.
I said maybe. Maybe they're not. Maybe they're just not fit to use a "revolutionary product" that requieres dozens of lines of JS that requieres modern browsers or worst anything else.
And thus MS snatches defeat from the jaws of victory once more.
Locking browser upgrades to OS upgrades without huge a technical justification. With XP maybe there was a case that it was too hard to support all the changes needed but Vista to Windows 7/8? This was a business decision not a technical one.
There is 0 technical justification, just some exec decision. Thanks to that and crappy XP security (by design , there is no other word), you have these huge botnets that will be here for years.
Companies need to understand that XP , and IE on XP is a threat to their business, their data and using Microsoft products will damage them sooner or later, and i'm not even talking about MSFT racketeering ,sorry license policy.
FWIW modern flexbox techniques also work in IE 10, you just need the right polyfill since that browser uses a slightly older version of flexbox syntax. For examples:
I was bothered by the support list at the end of the page... as jimmcslim also points out, it should be supported by IE10, and perhaps IE8 and 9 with heavy tweeking (I haven't looked at it). For a new site which would be OK to not support the older versions of the current desktop browsers, flexbox is usable.
Lots of people use web technologies for other things than "the open web" where browser compatibility is an issue. It could be internal apps, mobile sites, embedded WebViews, etc. For us, flexbox indeed "solves" the problem of CSS layout.
I wish there was a JS-shim that could be used to deliver flexbox (or any cutting edge CSS) to older browsers so I could begin implementing it now instead of waiting some unspecified amount of time before it becomes acceptable.
Unfortunately, the Holy Grail layout works like crap in mobile. In the most recent Chrome and Firefox for Android, the pinch-to-zoom gesture either doesn't work at all, or the whole div is resized as an image without text reflow (i.e. cropping text lines to the left and right). Also there seems to be a forced minimum width, under which the web pace can't be made smaller; this is awful for navigating long pages, or when the default font size is too big.
Changing the phone orientation does reflow the text, so I assume that the problem is with how these browsers resize the web page under pinch-and-zoom in a way that the CSS doesn't detect. The funny thing is that the same browsers on desktop work like a breeze when resizing text with the wheelmouse, or resizing the window. Why does it not work the same on the phone?
The worst thing is that the layout seems to be spreading like fire. I'm forced to read most major modern websites at fixed font size.
Resizing-as-image rather than resizing-as-text is how mobile browsers have always worked. At least, ever since the iPhone, which the other OSs copied the browser model of. The zoom behavior you are describing happens on every page in those browsers, and has nothing to do with flexbox or the holy grail layout.
If you want to change text size without cropping text, in Chrome for Android, go to Settings > Accessibility and drag the “Text scaling” slider. And in Firefox for Android, go to Settings and open “Text size”. It’s not as convenient as pinch-to-zoom, but it’s worth adjusting that slider for the current page if you’ll be reading it for a while.
Testing in Chrome 29 - pinch to zoom is disabled but are you sure that's not a deliberate choice in this specific case rather than a flaw with flexbox?
I don't know if it's a flaw with flexbox, but with the way sites are adopting it. The recommended layout from A list apart and Solved by flexbox both exhibit these problems, as well as multiple mainstream news sites.
I'm quite happy with the modern flexbox syntax. I did a lot of work with XUL and xulrunner years ago - it was slick having things automatically flow into place, but the syntax (and syntax of the derivative box-flex CSS properties), but it seemed to require very heavy markup to get things "right".
Flexie [1] appears to provide a polyfill version of flexbox. Has anyone used it in a major production site? What was your experience? There were a few polyfill-type projects for the older syntax, but I never got them to work very well for anything but the most basic layouts.
Flexie provides a polyfill for the outdated syntax `display:box`. The library's creator (@doctyper) is working on a new polyfill for the new syntax `display:flex`, but as far as I know it's still in development.
Flexbox (or something similar) should have been the first thing to go into CSS spec. Colors, fonts, margins and what-not are way less important than the ability to align elements.
Alignin things vertically is still brainded, but at least now it's possible. Instead of setting properties for the parent element, we should be able to just say .vertically-and-horizontally-centered {align: center center;} and be done with it.
The issue with css is it conflates two very separate concerns - one of styling, and one of layout. Sure, both are presentation related, but they are differently related.
CSS used to work well for styling, and is terrible for layout. I hope flexbox is the silver bullet - it seems to be tho, so my fingers are crossed.
Agree. It just should have happened a LONG time ago, these issues have bene present for a very long time and even since the beginning, the hack was to use <tables> for layouts
would be easily, but you need to uncomment that last rule before it "works", and that is just ugly. And when that last rule is uncommented, viewport now has scrollbar for some reason that I did not have motivation to investigate.
Like chii said, that's because CSS is a language for styling, not for layouts.
The extra scrollbar is due to fact that you've set height to 100% but you still have padding on the body tag. Also, unrelatedly, you should remove the space between the body tag and the div tag to avoid font-specific horizontal offsets.
The problem I've encountered with these kind of solutions are that they're never universally applicable so you have to know a list of solutions and what situations they can be applied. I wish I could remember a inline-block + vertical alignment specific example but two others would be:
`margin: 0 auto;` to center horizontally requires knowing the width, and it must be smaller than its parent container. If its not then use: `position: absolute; left: 50%; margin-left: - <width / 2>%`, and make sure parent has a height and position relative.
`text-indent: -999em` to hide text (which is admittedly not the best technique) was the cause of our 3d css transform animation running really slow.
With dedicated properties to solve these issues you'd hope they could be universally applied and reasoned about.
"Feel free to open an issue or submit pull request on Github."
Why does the link to the project on GitHub open in a new browser tab? Is there some reason this behavior is foisted on folks who would rather have the content open in the same tab? (Spoiler alert: I'm one of those folks.)
And, now that I take a closer look, it seems that every non-internal link on the page behaves the same way, spawning new tabs willy-nilly.
Looks like a useful project. I'm just legitimately curious why people do this.
I use Google Analytics to track where users are clicking, specifically, when users click on external links that aren't otherwise tracked by the GA tracking code.
The problem is that if you click on a link that opens a new page, the functionality in the click handler may or may not run depending on how long it takes to redirect the request. That means that if I'm tracking clicks, I very well may be losing a good deal of data.
The alternative is to hijack the click event, wait for say 100ms, and then load the new page via JavaScript, but that also break the open in a new tab functionality.
In other words, there are no good options to track external click events via Google Analytics and still give users complete control over where the links go.
The best option I could come up with is to always open external links in a new tab, because that way the click handling code always has time to run. If you're curious as to what I'm doing, here is the code:
https://github.com/philipwalton/solved-by-flexbox/blob/maste...
Anyway, it has nothing to do with wanting users to stay on my site. But I can't speak for why other people do this.
Thanks for the detailed explanation. My unsolicited two cents is that forcing this behavior on site visitors isn't worth whatever value you get from the analytics data.
Perhaps I'm in the minority here, but I find this behavior to be offensive enough that I immediately stop reading and move on. Trading user experience for analytics data is not a good trade.
I also find forcing a new window/tab annoying and it makes sense not to when you're targeting a technical audience. However, I've just as often heard complaints from less-technical users who don't reflexively cmd/ctrl-click on links and for whom opening new windows in tabs is a feature, so even though forcing a new window can be annoying it's often a decision made to improve UX.
Less-technical users don't need to know how to cmd/ctrl-click on links because even less-technical users know how to use the Back button. If they don't want to use the Back button and instead want to open links in new tabs, there are multiple mechanisms available to them (whether they know about them or not).
The reverse is not true: if you don't want to open a link in a new tab, but that behavior is being forced on you, there is no way to avoid it.
Regardless of the motive, this behavior is not a UX improvement.
In fact - opening a new tab BREAKS the back button. I've seen my father baffled when a new tab opened and he can't work out how to get back. (his tab bar has 300 open tabs as he never closes them).
So - opening in a new tab is a disaster for non-technical users and an annoyance for technical ones.
There might be some middle-ground where it's a good idea but I wouldn't bank on it.
I can confirm that many users of my father's generation (including him) are completely baffled by tabs. My grandfather, however, seems to have no problem. I don't know if that means anything.
When you open a new tab in Dolphin browser for Android, pressing the back button deletes it. Why shouldn't this be the default behavior for desktop browsers?
If you're in the minority I'm in the same one. This kind of design is rude, and the author's explanation about how he decided to be rude to his readers so that it would be more convenient for him to spy on them (tracking, analytics) tells me everything I need to know about him.
> The alternative is to hijack the click event, wait for say 100ms, and then load the new page via JavaScript, but that also break the open in a new tab functionality.
How does it break the open in new tab functionality? You can detect if the user was Cmd/Ctrl-clicking, or using the middle mouse button. I've done this on many sites and it works fine.
The best option I could come up with is to always open external links in a new tab, because that way the click handling code always has time to run.
Ugh. That's awful.
The alternative is to hijack the click event, wait for say 100ms, and then load the new page via JavaScript, but that also break the open in a new tab functionality.
Is this true? ISTM that if you just have:
<!doctype html>
<p>Here's a <a href="http://www.google.com">link</a>.</p>
<script src="http://code.jquery.com/jquery-1.9.1.js"></script>
<script>
$('a').not('[href*="mysite.com"]').click(function() {
alert('do some analytics stuff');
// only after that's done do we let the navigation proceed
});
</script>
Your analytics stuff still gets done, and open in new tab still works. (As written, the analytics doesn't run when opening in a new tab, but ISTM you can just capture some mouse events to work in that case as well.)
i think opening in a new tab for an external link is completely reasonable (i don't care about GA tracking, but if that was one of the reasons, its also a reasonable reason).
Unless your computer is too slow to handle many tabs, having more tabs is almost always better!
I agree and don't like to be forced to open external links in the same tab. I've actually written a tampermonkey script to override the default behavior of HN and SO for this reason.
But I hesitate to make this comment as this debate can approach the intensity of the "vim/emacs" debate in its religious fervor.
I don't think 'be forced' means what you think it means.
If a site defaults its links to "same tab" then I can easily override that behaviour and open them in new tabs if I choose (just by using a different mouse button or holding down a key when I click)
If a site defaults links to "new tab", can you tell me the simplest way I can override that behaviour?
In hopes that when you close that new tab you will return to their site and spend more time taking a second look. That increases the likelihood of you trying their product and boosts page visitation time in analytics.
I'm aware that the malodorous motive you mentioned is often the reason behind this user-hostile behavior. I was hoping that wasn't the case here, and instead perhaps some cog in the publishing process was spuriously doing this automatically. Naïve of me, perhaps.
Why does the link to the project on GitHub open in a new browser tab?
I know the developer has given a very good explanation about this, and there are still others complaining...
Curious to know whether it was just the link to the Github project which irked you (and others) or links to other external sites such as W3C/Bugzilla/CanIUse/etc are considered "valid" to open in new tabs?
I am excited by the prospects of flexbox, but disappointed by it as well. Maybe someone can correct me here, but when I started using flexbox it seemed to me like another case of the W3C being a day late and a dollar short.
I mean, something like flexbox should have been the very first thing added to CSS, but here we are in 2013 and we can maybe, sort of use it, as long as we don't care about a vast number of people using IE. But even then, let's say you want to do something like have a resizable canvas or WebGL context. You know, like you can get with absolutely any other application toolkit. Now maybe I totally missed how to do this in my hours and hours of frustration, and if so the person who corrects me will have my undying gratitude. But how was it that the first thing I thought to do was to see if I can have a resizable canvas with other elements controls (ie a drawing application, or something else), and yet this sort of thing did not occur to the W3C in the years they spent working on the spec. Do those people develop applications or is it all just about creating documents that are slightly dynamic?
And so now I'll probably have to wait until 2020 and the flexbox spec revision or something else until I can have contexts to draw to that will resize to fit their container, without going through all sorts of contortions to manually size then.
Probably worth mentioning that there is also the CSS Grid Layout Module [1], which has (according to Can I use...) much less support (9.65% [2]) vs Flexbox (79.32% [3]). A quick survey suggests that Flexbox should be used 'in the small' whilst grid is for 'in the large', but Solved by Flexbox seems to suggest that it is equally competent as a solution for whole page grid layout. Is the CSS Grid Layout module a dead end?
CSS Grid Layout is definitely not a dead end, it just didn't have enough support to showcase (yet).
As for the difference, Flexbox is for one-dimensional layout and Grids are for two-dimensional layout.
Grids will eventually be able to do what you now need a flexbox within a flexbox to do, and much more. They'll be especially helpful for layouts that need to be dramatically different across media breakpoints.
That would be a pretty major departure from how layout works now, but is IMNHO better than the half-working "css columns" stuff we have now (not to mention the mess that is fload, absolute vs fixed positioning etc). And it's based on a lot of earlier work from layout in the DTP world - in a good way. It makes sense -- if you want to do "fancy" layout in the browser at all.
And since modern browsers can't really display text properly (say, do some basic hyphenation) -- we're pretty much forced to do layout via css -- even if all we want do to is present some text for reading.
It's beyond me why no browser will render a page like:
<html>
<h1>A heading</h1>
<p>A paragraph or two</p>
<h2>Maybe a subhead</h2>
<p> ... </p>
</html>
In a way that's actually pleasant to read. I'd even accept going back to the horrible standard rendering if any css was included -- just do the right thing by default.
(Actually, a small enough tablet does a better job than most desktop browsers, but that is purely by accident -- and they still have pretty awful default colours (white on black -- too high contrast) -- and are much too hard to customize reasonably for the average users).
edit: As some of the other comments have mentioned, css is ok for styling -- but pretty bad at layout. I'd welcome both these specs -- and maybe a (stronger?) recommendation regarding how to hyphenate/space text (eg. along the lines of how (La)TeX does it).
The grid usage for flex just really remind me of the early days where everyone used table,td,tr for layout. You can just set the width/height with percentage and everything would scale. The only thing is that it not wrap-able like with div blocks, but that's what div was invented for.
It still burns that HTML Tables had this simple layout issue almost solved. CSS v1 could have just codified that behavior, and worked on improving it later. This is just emphasized by the "holy grail" example of the 3 column layout. That is a decade of lost productivity thanks to the people who said "tables for layout is stupid"[1].
It is too bad that GiveUpAndUseTables[2] is no longer working, because I would still send it to people.
The thing that's less often remembered is that tables had their own, completely different set of quirks which had to be learned and worked around, such that people eventually internalized all of it and figured that since they were no longer conscious of the problems, there must not be any and so "tables are so much easier".
Yes. The timer was set to 47 mins for you to attempt your pure CSS layout, and would count down to your inevitable failure. Someone also built an opposing "Use CSS" timer, but I cannot find that one.
display: table-cell, table-row, table sounds like it would be quite viable for an entire sites layout. I've never tried it but I'm tempted to blanket style all section tags as tables, article tags as rows, divs as cells - or some variant of that. Still, the use of existing tags is perhaps a silly limitation when we can choose to use a non-strict html spec.
Anyone know of examples of this, like a boilerplate called fuck-me-just-use-tables?
This is a very nice resource — the use of Autoprefixer and the SUIT/Montage class names is welcome as well.
I see a lot of impact in flexbox for progressively enhanced designs — designs that in their most basic form have simplified or single-column layouts — where most of the layout is handled by supported browsers. Do you imagine it's better to make a clean break and just depend on pollyfills/float-base `.no-flex` backup styles though?
I have never seen this before. At 100% zoom it seems fine, this screenshot is at 150% zoom and after scrolling a few lines.
I'm aware that this is probably a browser bug just as much as to blame your CSS. But I have never seen a webpage do this with just CSS!
Somehow it doesn't seem to clear the screen buffer anymore, when I clicked the link on HN (not into a new tab) it even shone through the HN frontpage on the background. The previous page. What did you do?? :) (also that sounds like a cross-domain content leak waiting to happen, but that's Opera's problem).
It's very contemporary glitch art, with the juxtaposed perspective demo screenshots shining through in the back, beautiful, but not very hack-free ;-)
Well, true. But all scenarios should be solvable via specificity alone.
I feel this is similar to saying there's absolutely nothing wrong with Goto if used correctly. The problem is when people use Goto because they don't understand other structural mechanisms.
As I said, it's just a nit that they can consider it or ignore it as they please. If this were just some web page, I would never even care. But since they encouraged me to open my DOM inspector and look at the code, I wanted them to know that I cringed when I saw the !important. That's it.
In classes that are supposed to be global helpers/modifiers, it makes absolute sense to use `!important`. For example, if I have the utility class `.u-hidden`, that selector has very low specificity. But if want to be damn sure that anything I put that class on gets hidden. There's no way to use specificity in this case because it's generalized for use on any website.
This is a common pattern seen in most well architected CSS libraries today.
Well, in that case, I retract the comment. The work you've done in demonstrating Flexbox is too valuable to suffer pedantic and (as you point out, ultimately not even necessary) points about !important.
Flexbox is brilliant in theory but the support is so poor that it's still basically unusable in production. Pity, because it would make like much easier.
At the top of the site, you should see a red banner saying “Your browser does not support Flexbox. Parts of this site may not appear as expected.” But it’s easy to overlook. Ironically, the banner is easy to overlook because the broken styles make the banner the same width as the rest of the page, making it blend in. The styles are so broken you don’t even see the warning message about the styles being broken.
Open the site in Chrome and it should look normal.
But I have to ask: isn't any "solution" that requires IE 11+ practically useless to the point of being fictional for at least the next decade?