Flexbox and Grids: your layout’s best friends
aerolab.co
aerolab.co
CSS is almost as bad as PHP when it comes to naming. Most flex related properties are prefixed with flex-; but some aren't (align-items, etc) so you now have tons of non prefixed properties that actually only work within a very specific context (vertical-align, etc) and there are no compilers to tell you which combinations don't make sense or whether you have redundant properties.
IE11 has tons of bugs with flexbox; I had to remove a flexbox layout earlier because of that crappy browser (it ignores explicit/inline width/height set on flex children).
Otherwise it's a great tool if used sparingly (heavily nested flexbox elements with lots of special properties start to become a bit hard to follow)
But I agree with your points. Despite its flaws, it is probably the best thing out there for creating visual layouts from code.
Best IDE ever. Better than emacs. And I've loved emacs for a couple years, and Vim for 10 years before that. Webstorm even comes with a Vim plugin.
IntelliJ is really rocking it. Webstorm for webdev, Cursive for clojure (https://cursive-ide.com/), PyCharm for python (https://www.jetbrains.com/pycharm/)... every one of those IDEs feels amazing out of the box.
It sounds dumb, but just try it. You'll get hooked on Webstorm and never want to go back. Example: press shift twice. It pops up a "Search Everywhere" box, and you can type filenames, symbol names, actions (Rename, etc)... it's basically helm M-x, but way better.
You won't ever feel like "CSS names are bad!" because you won't ever need to remember anything. Want to center something? Just type "align" and usually webstorm pops up autocomplete with the right thing. And that's true in every context: https://i.imgur.com/jCAAesF.png
All of these IDEs are specializations of IntelliJ IDEA (https://www.jetbrains.com/idea/download/#section=mac). They specialize it for web and call it WebStorm, for Python and call it PyCharm, etc. But all the plugins and settings work in all the IDEs, so really the underlying awesomeness is IDEA.
At this point I trust IDEA enough to know that if I open any codebase, I can start navigating it right away. Doesn't matter if it's C++, ocaml, or VueJS. Typing shift-shift will always let me jump to definitions.
Yeah it costs money, but $13/mo is super reasonble. Dropbox was similarly impactful on my life, and that was $10/mo.
>Just type "align" and usually webstorm pops up autocomplete with the right thing
VS Code does both of these things, and is FOSS
It's not so much that it has X feature or Y widget, but rather that the whole ecosystem feels cohesive. With emacs you sort of cobble together your configurations until you're happy with it, and that's very powerful -- it's why it's so successful. But there's something to be said for having "awesomeness out of the box". It's why Spacemacs was so popular.
I hear you about FOSS. I was reeeeally hesitant to throw my time into yet another closed source clusterfuck. I grew up as a gamedev, and back in 2000 that meant you had to use Visual Studio. All of my VS skills are now completely obsolete. And whenever I ran into VS issues, I couldn't debug it since it was closed source.
Two things convinced me IDEA is probably worthwhile:
1. They're partially open source. https://github.com/JetBrains/intellij-community You can build that from source and run it, so you can at least see how most of the system is architected. You won't be able to extend some of the closed-source plugins, but you get some of the benefits of FOSS.
2. Their tooling is their primary business model. When Microsoft lost their VS monopoly, Microsoft didn't die. JetBrains' sole focus is making the tooling ecosystem work; they're the Adobe of tooling.
FWIW Cursive is a bit sluggish to start, but after it's done indexing it feels like the best Lisp development environment ever made.
[1]: https://plugins.jetbrains.com/plugin/4986-ocaml-support
Amusingly someone made a plugin for pg's Arc 3.1 code back in '08: https://i.imgur.com/Xe7mvIB.png
If IDEA doesn't support a particular language, it's pretty easy to fork an existing plugin and throw together some lexer rules.
But I can not praise its abilities as you do. My experience has been mixed. Sure it's cool when it works well, but then its bugs are all the more painful. You expect intelligence and you get the opposite.
Take this bug I reported two years ago: https://youtrack.jetbrains.com/issue/WEB-19183
It thinks "y" is a global if I put "x.y = ..." anywhere in my code. Genius!
Also, It's lacking in its support for Vue Js. I get lots of red squiggles all over my code for perfectly valid Vue props, and PostCSS within single-page Vue component also is weak (no $variables support).
git clone https://github.com/vuejs/vue-hackernews-2.0 && cd vue-hack* && yarn && webstorm .
shift-shift "Item" should show https://i.imgur.com/AV1bbXG.png
And `this.$store.` should show the proper completions:
It's possible that I've been getting along without the features that some other editor provides. Does VSCode have better Vue integration?
Here is Webstorm complaining about in a legit Vue v-for statement in a .vue single-page component.
And second image is what it does when I try to use PostCSS variables.
Vue's tooling is context aware. It knows when you're within a <style scoped> tag. I see that there's a PostCSS plugin: https://i.imgur.com/JTPlIEk.png
Theoretically, the tooling should be able to use that plugin's lexer rules. PostCSS already registers itself as a language (pcss) so Vue's tooling logic should be: "are we within a <style scoped> tag? search for PostCSS tooling; if if none found, use vanilla CSS."
It already does this for <style lang="scss">, so postcss should definitely work. The logic happens in https://github.com/JetBrains/intellij-plugins/tree/master/vu... if you want to explore it.
But it's flawed. PostCSS is itself a host for plugins. So a WebStorm PostCSS plugin would need to allow user to select the PostCSS plugins that they are using.
Case in point: I use postcss-simple-vars but the WebStorm plugin assumes I use postcss-custom-properties. And so it fails me.
Yeah for a repro you just just need to do this: https://imgur.com/a/N2S2r
And you can see the warning when you hover over choices in the second image.
I'll try repro'ing it.
I think we should open a ticket in the appropriate place though. There's a good chance that a plugin maintainer can look into this and fix it quickly. It's such a clear example of brokenness, and should be pretty easy to fix.
I'm not quite sure where to raise the issue though. And I'm falling asleep, so that's all for now.
https://youtrack.jetbrains.com/issues/WEB?q=vue
So I figure it'll get fixed some day... probably after I move to another framework.
Meanwhile, after launch, the IDE grabs focus about six times while loading. Symbol navigation sometimes picks up random unrelated functions from ignored folders instead of the one sitting right beside the file, because it has the same name. Want autocomplete for that vertical-align's value? It just throws up every possible value for any CSS property.
Pretty bad when code editors running in a browser engine are getting more usable than your paid product.
Symbol navigation sometimes picks up random unrelated functions from ignored folders instead of the one sitting right beside the file, because it has the same name.
Even after excluding a directory? If you have autogenerated build folders (e.g. dist/, out/, etc) you have to mark them as Excluded: https://i.imgur.com/E2uXJzu.png
Odd. I haven't noticed that, but I'll watch out for it.
Hope they'll get their shit together, it used to be a pretty great IDE before these annoyances started piling up.
well thats not quiet true, in purescript you can write type-safe CSS checked at compile time
https://pursuit.purescript.org/packages/purescript-css/3.3.0...
I've also been very frustrated by CSS due to 1) its lack warnings and debug errors as mentioned above, and 2) that so many properties have side-effects (like setting an element to display:flex changes the auto value of min-width for all its children[1]).
I've started working on something to help with this, but it's a long way off (and it may not work at all).
So I use Susy grid system (2) and absolutely love it.
If I remember correctly that is intentional because properties like align-items are going to be added to non-flex containers in the future. Look up Box Alignment.
It took browsermakers 1O OR SO YEARS! to agree on complete flexbox spec and completely implement it.
People who were in touch with w3c process whom I knew, tell that at some times a whole meetings were spent arguing over a nothing more than a naming convention for single CSS property, or whether flexbox will be able to align element position on integers
"flex-basis" - defines mysterious "main width" (WTF is wrong with just width?)
"flex-grow" and "flex-shrink" - grow and shrink relative to what?
How to define flexible margins? Like I want left margin to be twice larger than right one and all this to be flexible:
|---m:2*-------|--1*---|--m:1*-|
Effectively flexbox breaks CSS box model that postulates only width/height to define box dimensions.
Why I cannot say just this:
{ width: 1fr;
margin-left: 2fr;
margin-right: 1fr; }
Where 'fr' are flex units introduced in CSS Grid https://developer.mozilla.org/en-US/docs/Web/CSS/flex_value
Why two specifications define the same entity (flex weight) by two different mechanisms - by property and by unit?
CSS looks like Christmas tree where each passer-by (Google and Microsoft here) adds its own shiny stuff ...
Is this what we name as modularity of CSS?
There should be N-- and preferably only N --obvious ways to do it.
This
{ width:100px;
margin-left:1fr }
So the block is attached to the right side of its container. And so you don't need all those aligns - flex units can do alignment in more flexible ways.
That's obvious indeed.
But those flex-shrink/grow ...
Consider this:
<p>Foo <input style="width:1fr /> bar.</p>
Here is an illustration of the idea of flex units:
Your example can be accomplished like this:
<div class="columns">
<div class="column is-half">m:2*</div>
<div class="column">1*</div>
<div class="column">m:*1</div>
</div>
Check this: https://sciter.com/images/wt-langs.png You see the same HTML markup there but in different languages. Text in most of European languages is longer.
This is HTML/CSS Sciter UI that uses flex units and flow property: https://sciter.com/docs/flex-flow/flex-layout.htm
That last part (use of actual content) is what you cannot reproduce using % units in principle.
Hope you've been well. Your 4chan board was hilariously cool.
Your items get distributed along the main axis, using their flex-basis.
When all elements are layed out, flexbox will evaluate how much space is left, or how much overlap there is.
This total remaining space will be distributed among all flex items proportionally to their flex-grow value. A flex-grow value of 2 means "grow twice as much as your siblings if there's spare room" (0 will prevent an element from growing at all, even if there is space left).
So if 3 elements with flex-grow 1--1--2 and 100px basis each where to fill a 400px box, the remaining 100px would be distributed 25--25--50.
Flex-shrink works the other way round. The same 400px-box example with flex-basis 200px and shrink 1--1--2 would result in 150--150--100px wide elements.
That's the thing - nobody knows exactly how it works. Except few developers who actually tried to implement the spec.
Nobody knows why do we need separate flex-shrink and flex-grow. Nobody knows why these are properties and not units so they can be used not just for width/height but for padding, margin, border-width, top/left/bottom/right, size, etc.
Nobody knows why 'flex' is a value of 'display' property and not of some other property orthogonal to display like 'flow' or 'layout'. So we can write something like this:
td.some {
display:table-cell;
flow: horizontal; // a.k.a. flex/row
}
Really, flexbox is the worst CSS module ever published and accepted by W3C.
That's either plain nonsense or trivially true of all css, depending on your definitions.
Flexbox really isn't all that confusing or hard, and it does more than table layouts ever did.
Separate flex-grow and flex-shrink are needed for the same reason there's a min-width and a max-width property. flex-shrink defines if the element is allowed to shrink, and how much it does when needed. flex-grow defines if the element is allowed to grow, and how much when needed. The reason they are unitless values is because they are used to calculate ratios.
I agree that there have been some dubious design decisions, but if you really need to do a table cell with a flex-flowing content you can always stick a wrapper div in the cell.
"you can always stick a wrapper div in the cell" Nice, tag soup forever.
This _is_ how it works, i just didnt have the source at hand and wanted to just exolain the broad mechanism
<table style="width:75%"> // Total width of all three
<tr>
<th width="50%">LeftMargin</th>
<th width="25%">Main</th>
<th width="25%">RightMargin</th>
</tr>
</table>
In the same 10 years (http://www.w3.org/TR/css-flexbox-1/) we were trying to come up with something that can be used instead. And have got that ugly flexbox.
And still... were are my col/rowspans?
Something is terribly wrong with the process.
So we've come somewhere but there is further to go and maybe we didn't need to go in so many circles.
Here's the live HTML I uploaded for testing: http://momentstudio.co.nz/temp/test.html
This page we're on now also runs mostly on tables.
Depends what you'd expect, I suppose. These days, I'd expect the columns to switch to a vertical stacking layout when viewed at a mobile width. I guess maybe it's not "broken", per se, but it's not responsive and certainly pretty limited in how it can be used.
table { display:block; }
.responsive { display: block }
@media(min-size: 768px) { . responsive { display: table }}
The only thing got wrong is that it took a bit long, but current CSS layout techniques are totally awesome today.
How does that not translate into "Just do all your work twice!"?
Since those fallbacks only require a handful of lines of CSS, it only takes a few minutes to get the compatibility to almost-perfect, and you can get a better design in front of most of your users very quickly. To me at least it's a solid mix of design freedom and development speed.
What's actually going to happen is that most people will layer JavaScript frameworks on top of HTML and then we're going to complain about the huge performance and memory overhead of JavaScript heavy websites.
https://www.youtube.com/watch?v=Dz9BzY21Zks&list=PLQkVA6z3dF...
Highly recommended for anyone who's not familiar and wants a quick introduction -- each video is just a few minutes long. :)
As far as I can see it it is currently scored at ~75%: https://caniuse.com/#search=grid
If you can do your layout without flex boxes why do you need to create second version with them at all?
That's one way of looking at it. I prefer to see it as writing features that only certain users will benefit from. In the case of layout, I tend to give users with older browsers a much more basic, linear flow (just making the semantic HTML work really), and then add in more complex layout using what tech is available. That's not really doing the same work twice in my opinion.
MS Edge 16 was released two weeks ago, and already supports the latest CSS Grid spec (allegedly, I haven't tried it myself).
---
As for the remaining 21%, depending on your target audience you might not care enough about UC Browser for Android, Samsung Internet, Opera Mini, Android Browser, and even IE11, which btw is no longer the default browser for Windows (Edge is).
Especially if you're building a new product, by the time it becomes big enough that browser compatibility starts to matter, it will probably be a non-issue for CSS grid.
[1] [2] [3]
[4] [5] [6]Anyone been able to accomplish this with CSS-Grid or Flexbox?
There is also of course the order property, which with some cleverness can re-order elements from 1, 2, 3, 4, 5, 6 to 1, 4, 2, 5, 3, 6. You'd have to get awful clever with it though to figure out how to do this right, so still might rely on JS.
You can't simulate the way items can extend into other rows easily with CSS Grids, but the default behavior for children of a display:grid element is to flow horizontally into cells until they have to start wrapping.
Flexbox only deals with a single row at a time, whereas masonry doesn't really have a notion of a row (given the 4th item in each column can be at very different places, depending on the sizes of the items above). Grid requires you to bind things to an actual grid, so you still can't do masonry (for similar reasons). The closest you can do is using multicol, but that's then top-to-bottom then left-to-right instead of left-to-right then top-to-bottom.
Note that this is mostly thinking about unequal height items (which is the common case of masonry); equal height you can do with floats yet alone more recent layout modes.
As for number of layout modes, it depends on how you count. Roughly: block, inline, table, positioned, flexbox, and grid. Multicol doesn't actually introduce a new layout mode, it just functions in a similar way to fragmentation when doing layout for printed media, just fragmenting across columns instead of across pages.
My point is just that, as described, your problem is woefully underspecified.
flex-wrap: wrap;You either have to go all the way back to supporting IE11 and ignore everything not supported by 2013 microsoft to capture another shrinking single digit percentage of possible users until they progressively die of old age or ignore Microsoft stuff.
Alternatively start providing a slightly degraded interface with fewer features and a banner. Our website works best with a modern browser with links to up to date edge, firefox, and chrome at top of page. Preferably with a notice regarding dropping support for internet exploder sometime next year.
What? Do you know how many people that is?
For one party maybe the actual user percentage is 0.2% maybe for another its 20%.
The trade offs are going to differ.
I noticed this when Mozilla recently resigned their add-ons site and starting using CSS Grid support sniffing to determine weather to show the real site or the gimped mobile site. As it is all browsers without CSS Grid are forced to use the mobile site.
It's super annoying.
Where are people drawing the line? Bootstrap 3 still supports legacy browsers but version 4 and other popular frameworks like bulma use flexbox.
Maybe some consumer sites aimed at smartphone-wielding younger audiences can now get away with dropping IE completely. Maybe some sites aimed at very small businesses too.
If you're aiming at older individuals or at medium to large organisations, not a chance.
This is especially nice since none of us have a Windows machine at work or at home ;-)
Except for IE11, basically all browsers that don't support Grid are outdated mobile browsers (pre-iOS 10.3 versions of Mobile Safari, Android Browser in older Android, and browsers that are based on Android Browser and have high usage in developing countries, like UC Browser)
It's centered on grids but it has 15th Century analogies. ;)
[0] https://www.w3.org/TR/2011/WD-css3-grid-layout-20110407/
And I used flex boxes within grids to fine tune layout and it's really awesome and simple. Verbose, but simpler than using frameworks like BS, Semantic or Materialize for layouts.
A tip: Strangely Safari tend to need flex-basis value everywhere
Most of the Safari issues should have been fixed in Safari 11, FYI. (The implementation of flexbox was largely copied over from Blink.)
I'd love to try out Grid on the Web side of my app, but it's hard to justify if it'd mean I have to maintain a separate Flexbox-based layout for the React Native side anyways.
even if it doesn't cover specific edge cases, its simplicity pays off.
So basically, write two versions of your layout: the old way, and the new way. Flexbox and grids aren't ready for production yet.
Wow, is that becoming common these days, using web browser engines to run UIs on specialized devices? Sounds a little off in the context of industrial tools, where I'm thinking embedded systems and relatively low-performance SOCs.
Grid support is much spottier, but can be safely used in production depending upon your supported browsers.