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)
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.
It also has 6000+ unresolved issues reported, a lot of them open for 3-4 years with little hope of getting fixed. They keep rolling out half-baked support for the trendiest new JS frameworks, while basic parts of the IDE are falling apart every day. (For example, when opening the mentioned "Search Everywhere" dialog, sometimes it just doesn't receive focus. Good luck with that productivity.)
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.
Yeah, the unresolved bug reports are pretty annoying. I ran into similar problems trying to get Live Edit working with AngularJS.
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.
This usually happens from node_modules, marked as a library folder, so it's indexed and might even be relevant, but it shouldn't really be a better match than the one in the source. And it's not even consistent.
Hope they'll get their shit together, it used to be a pretty great IDE before these annoyances started piling up.
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.
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).
VSCode is indeed awesome for Vue. It supports pretty much any lang in any block properly, due to its support for embedded language contexts. If you have template lang="pug" and pug grammar plugin, it just picks it up. Also Vetur extension adds a lot of autocompletes and typescript support.
Aha! I see. Do you happen to have a repo I can clone to reproduce the problem? I'm interested in fixing that.
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."
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.
It's gonna be a little while before I can scrape together the time to look at this. This week is gonna be a doozy. Sorry.
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.
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.
I've been using WebStorm (and IntelliJ IDEA) for the past couple years and love it. I have no intention of swapping to any other IDE unless I really have to. Can definitely speak to the extreme convenience of instantly finding usages/definitions, "intellisense" of func params, plugin architecture, super customizable settings, built-in language support and linting/evaluation, refactoring assistance, live templates... Just a godsend, to be frank.
Is there a reason you wouldn't just use IntelliJ and install the plugins you need? I used to use separate IDEs pycharm and phpstorm, but then I needed IntelliJ for some Java dev and realized I could just install PHP and Python plugins instead and from then on only needed one IDE (IntelliJ Ultimate). I havent been able to do this with C#, .Net but for everything else it seems to work.
Mm, good point. WebStorm performance is good, but IDEA is noticeably slower. I haven't used PyCharm yet, so it's possible performance could be a pain point there. I find myself firing up Webstorm instead of IDEA due to slower IDEA indexing.
FWIW Cursive is a bit sluggish to start, but after it's done indexing it feels like the best Lisp development environment ever made.
I liked PyCharm's feature list but the index-the-world behaviour definitely like it going back to the pre-SSD era. Not a show-stopper for my biggest project but the cost for everything else definitely left me hesitant to switch.
Sorry, this may be a silly question, but is it possible for PyCharm (and other IntelliJ IDE products) to define a specific working folder / path for the file index-the-world feature to stay within or does it always permeate through the entire computers hard drives, just in case?
It works similarly to git. You define a project root, and then exclude subdirectory trees as needed. I believe there's a way to add additional directories outside the root if needed.
I had the same experience with a Vim plugin called Jedi. It was great, but typing "pdb." would freeze Vim for 5 seconds. IDEs can definitely try to do too much.
I just assumed the naming thing was for properties shared between grid and flexbox (such as align-items). It is still pretty frustrating to remember that kind of stuff though.
> Most flex related properties are prefixed with flex-; but some aren't (align-items, etc)
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.
>CSS is almost as bad as PHP when it comes to naming
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
I`m using flexbox heavily on 10mill+ pw site for 2 years now. we had a lot of issues at first but after learning the quirks those faded out. nothing came up in the last 6 months.
Does it tell you that align-items by itself doesn’t make sense regardless of the value, of the element isn’t otherwise set to use display: flex or grid?
I don't know the answer, but I'd be surprised if it did.
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).
There's a good reason to limit yourself to 12 columns: the layout is consistent across all common screen sizes, whether it's tiny mobile screens or huge desktop screens. If you have sizes like 1.374fr, you lose a lot of that automatic layout functionality.
Bulma, as any other grid systems based on % units, is quite limited in real life.
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.
Check screenshots above. There is a block having 4-columns layout. Each column there a) is flexible and b) uses min-content constraint. So widths of columns are unknown upfront - determined by actual content in grid cells.
That last part (use of actual content) is what you cannot reproduce using % units in principle.
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:
At the moment there is no way to define flexible content flow inside table-cell's and list-item's as display:flex is mutually exclusive with display:table-cell.
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.
"flex-shrink defines if the element is allowed to shrink"
Rhetorical question: Shrink from what? From defined flex-base or from defined width? What is the behavior when they are different?
"you can always stick a wrapper div in the cell"
Nice, tag soup forever.
Man, you could almost have done this back in pre-CSS days with tables, if you didn't mind setting the total width of the whole thing including margins instead of just the inner width.
<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>
Exactly. 10 years we were told how dangerous are tables.
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.
> What's broken with table layouts on mobile? I just tested my code above on Safari on iOS 10 and it displayed as expected.
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.
It's been 20 years and we STILL don't have tables with a fixed header in the HTML spec. We deserve a better standards body -- or an entirely new layout system.
has clear and obvious physical meaning: solid block with the spring of strength 1 on the left of it.
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.
>If you wish to fully support all browsers (yay!) then I’d highly recommend using feature queries to provide an alternative layout for browsers that don’t support Grids or have an older syntax.
How does that not translate into "Just do all your work twice!"?
Since CSS grids are mostly used for the global page layout, the ideal use case is using it to design complex pages that would be very annoying to make with other techniques, and on older browsers fall back to a much simpler design with flexbox or floats.
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.
If you have a good reason for complex pages your solution is only viable once the share of old browsers has dropped below, say, 5% to 10%, depending on your niche.
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.
I agree that flexbox and grids complement each other, but I doubt that grids are ready for product. I mean it is nice that all major browsers have a decent support in the newest versions, but production ready includes for me that older browsers (without support or major bugs) are not common anymore (~ <5%).
Re: CSS Grid, caniuse.com seems to be out of date here.
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.
Many companies use IE11 as default since Edge breaks some pages used internally. So if enterprise customers are important I would pay attention to IE11 compatability.
You don't have to make pages that look identical in every browser. Make something that works for everyone and then use newer browser features to make it as good an experience as possible depending what features are available. CSS even has the "@supports" feature for doing it - https://developer.mozilla.org/en-US/docs/Web/CSS/%40supports
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.
Depends how you do the job, if you initially design for mobile you can use the mobile layout for everyone that does not support grids, and add grids for the traditional desktop layout. Since grid layouts are created as a list of elements, this workflow is actually pretty efficient.
I was able to finally start using grid in production for a new project a couple of weeks ago. It made page layout a breeze and my html and scss are so much tidier and easier to read. Flexbox still has its place as the article points out, but abusing it to do 2-dimensional layout didn't feel any better than doing the same with older techniques.
Yes, but before grid was available people did some funky things to build responsive grids (like using a flexbox column containing flexbox rows or using a lot of repetitive media queries).
Yeah - they do solve different problems. We recently switched our production app to using both (from strictly bourbon/neat grids) and it's made life so much simplier.
No, you can't, because the position of each item depends on all the previous items.
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.
Thanks for the rundown. That’s unfortunate. This might be another case where browsers will eventually implement yet another layout method (how many are we up to now with floats, tables, columns, flex box, grid?) as soon as these layouts are replaced by something new.
Masonry is something somewhat fundamentally unique given it relies on how things flow across both dimensions in a specific way; there's been some vague talk about extending Grid to support it (but nobody's actively working on things like that for now, even subgrids have gone a bit quiet), but probably more practically we'll stick to doing complex layout modes with a limited scope in JS (and hopefully soonish with Houdini and avoid much of the costs associated with current ways of doing layout in JS), given solving things like Masonry in a general way is hard (and relatively unclear that the gain is much for the amount of work involved).
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.
I too would like to know! I have yet to find a way display flex rows that are different heights and that align left to right. It seems the only options are to align by column, or use Masonry.js which seems like overkill. Even Bootstrap 4 only supports column layout.
Anyone been able to accomplish this with CSS-Grid or Flexbox?
From what I can tell, it hasn't been done with Flexbox alone. To get the order right, you have to specify a fixed height for each element, making it non-responsive at best. I am wondering if grid somehow helps.
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.
Most everything with CSS Grid is broken on Edge 15, which is what most Edge users are running. Thus Grid is not something you should be putting in production.
The same site says virtually nobody, aprox 2-3% is using edge.
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.
It also doesn't work in the Firefox fork I use. But that's probably an even smaller market share.
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.
Its a lot of people but how many of them are your customers? How much additional developer time are you going to spend to support them. Are you building a less interesting experience for 98% of your customers in order to support the 2%?
For one party maybe the actual user percentage is 0.2% maybe for another its 20%.
You're making the error of assuming that all web applications in production have the same user base and constraints as yours. For example, I work on an application that is a companion app to some larger domain applications that themselves only work on newer versions of Chrome and Firefox. I defacto don't have to support IE, as none of my users can use it. Additionally if you make a developer focused tool like bug reporting, APM, or log aggregation, you can probably ignore IE, if you don't target Windows devs.
I had the chance to see Rachel Andrew speak at laracon. Great presentation and got me excited about flexbox and grid. I'm still wondering is the browser support wide enough to implement this in production for the average site?
With only 70% browser support, you're going to have to have a pretty strong reason to believe your audience is different (or not to care) to justify using Grids
Grids are most useful in wider viewports (tablets and laptop/desktop browsers).
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)
But then the question becomes: can you (sanely) gracefully downgrade on those small screens (hopefully without making an entire early 00s separate "mobile" site)?
Has everyone decided to drop ie? For tech related sites that might make sense but I think not supporting ie means turning off support to the users who are older in some cases but more likely to buy.
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.
Every website is different. I work for a Fortune 150 company, but the site I work on is so narrow in focus that we have the luxury of deciding that the amount of people using IE/Edge (very very few based on our server stats) is not worth the development/QA efforts to support them.
This is especially nice since none of us have a Windows machine at work or at home ;-)
The article does not really say what to use if something does not support grids? should your fallback be flex box? Also IE 11 does not support the @support.
Be careful using CSS Grid - IE11 supports only an old version[0] of the spec, and thus is missing many major CSS Grid features like repeat(), grid-gap and span.
Recently used CSS Grids for layout control and Bootstrap v4 for element styling. Grids are insanely easy to use and do a really good job of separating content and presentation.
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.
When using conditionnal arrival of dom object (I mean like using ngIf in Angular or simply using switching display none/block on some block) flexbox layout seem very difficult to anticipate. For that kind of things I still prefer using inline-block, that is more predictable.
A tip: Strangely Safari tend to need flex-basis value everywhere
Is anyone aware of any attempts/plans to bring CSS-grid style layout to React Native? Either officially or through some library/plugin.
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.
The standard is excellent, and has been rolled out much more effectively than previous standards (much more smoothly than flexbox, to cite a recent example).
The women involved in this project kicked ass, and continue to do so. What's to feel conflicted about?
> If you wish to fully support all browsers (yay!) then I’d highly recommend using feature queries to provide an alternative layout for browsers that don’t support Grids or have an older syntax.
So basically, write two versions of your layout: the old way, and the new way. Flexbox and grids aren't ready for production yet.
Well, it depends on context. More and more, web tools are being used in a way where you can control what browser they're running in. Not just Electron, but also when making UIs for things like industrial tools, where you control not just the browser, but the hardware it runs on.
> Not just Electron, but also when making UIs for things like industrial tools, where you control not just the browser, but the hardware it runs on.
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.
Sorry. I realise that I combined words that will sound frightening to some. I mean non safety critical systems in an industrial environment. For example, mobile robot health and KPI monitoring.
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)