Solved By Flexbox – Cleaner, hack-free CSS
philipwalton.github.io
philipwalton.github.io
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?
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.
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.
At least Vista uptake was relatively small.
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.
StatCounter[1]: XP 20.58%, Vista 5.21%
Among gamers, XP and Vista are about equally unpopular.
Steam[2]: XP32 6.83%, XP64 0.35%, Vista32 5.18, Vista64 2.32%
There are signs that the rate of decline is slowing: http://gs.statcounter.com/#os-ww-quarterly-200803-201303 I think our best bet is that residual users switch to a better browser on XP.
XP is currently on 20%, but IE8 is at 8.5%: http://gs.statcounter.com/#browser_version_partially_combine...
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.
Check the weekend/weekday variation in IE8 usage. It plummets at weekends to a negligible amount.
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.
Sadly the apps we build for them for the public see very little actual IE8 use...
I'm hopeful 2014 death of XP comes true, but I won't be surprised if actual death doesnt happen until 2015
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?
http://www.browserstack.com/screenshots/78ef12e58dd1ba200600...
• 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).
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.
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?
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.
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.
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.
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.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Foo</title>
<style>
html {height: 100%;}
body {height: 100%;}
.mid {display: inline-block; vertical-align: middle;}
/*body:before {content: ''; height: 100%; display: inline-block; vertical-align: middle;}*/
</style>
</head>
<body>
<div class="mid">vertically aligned</div>
</body>
</html>
Like chii said, that's because CSS is a language for styling, not for layouts.
`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.
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.
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.
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.
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.
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?
Unless your computer is too slow to handle many tabs, having more tabs is almost always better!
But I hesitate to make this comment as this debate can approach the intensity of the "vim/emacs" debate in its religious fervor.
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?
Just use greasemonkey or tampermonkey and a script like this:
var a = document.getElementsByTagName("a");
for (i=0;i<a.length;i++) {
if (a[i].target="_blank") {
a[i].target="_self"
}
}
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.
Still, the 100ms delay isn't ideal, and the open in a new tab paradigm greatly simplifies things.
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>
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 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.
Progress, ladies and gentlemen. Progress.
[1] http://www.w3.org/TR/2013/WD-css3-grid-layout-20130910/ [2] http://caniuse.com/#search=grid [3] http://caniuse.com/#feat=flexbox
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.
Hope that helps!
http://dev.w3.org/csswg/css-regions/
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>
(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 is too bad that GiveUpAndUseTables[2] is no longer working, because I would still send it to people.
Anyone know of examples of this, like a boilerplate called fuck-me-just-use-tables?
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?
http://i.imgur.com/mGRDWdp.jpg
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 ;-)
One nit, though: would you be able to restructure the examples to avoid use of the !important CSS directive? Seeing that made me cringe.
The problem is when people use `!important` because they don't understand CSS specificity.
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.
BTW, I am the they you were referring to :)
Thanks again for the work!
Open the site in Chrome and it should look normal.