CSS Grid Generator
cssgrid-generator.netlify.com
cssgrid-generator.netlify.com
CSS was such a mess for so long because of the complete lack of a consistent easy-to-understand layout mechanism. This has spawned the creation of countless workarounds and javascript gizmos, JUST SO you could stick something on a webpage where you want to go and have it behave in a sane way under resize and different browsers.
I welcome CSS grid, it reminds me of the sane layout managers we're used to from writing desktop applications. It makes me wonder why we had to wait so long for this functionality to be part of the CSS standard.
As for the generator, I think it's nice. Most folks will get the hang of banging out arbitrary css grid layouts very quickly. This tool will accelerate that for many.
<table border="0" cellpadding="0" cellspacing="0"><tr><td>...
<code>(SUB X Y) </code>subtract<br>http://okcancel.com/comic/98.html
... When people realized that you could, painfully, use CSS for layout and dump layout tables altogether.
Html shouldn't consider layouting, that's for css to do.
In addition, the attributes you show are now obsolete and non-conforming: https://html.spec.whatwg.org/dev/obsolete.html#non-conformin...
Besides, HTML does allow precise positioning, but nobody really needs it. What everybody needs is a high-level language that fits the domain: fluid 2D interactive layout. CSS is simply not a good attempt to solve it. It's not even bad per se, because a similar model works quite well with XSL-FO. But XSL-FO is always an intermediate step: you take a custom document format (some XML), transform it with XSLT into XSL-FO, and then process XSL-FO to produce a PDF. The HTML lacks this transform step and tries to bolt-on CSS model directly to what must be a custom XML format and this is why it's so awkward.
It was promising, but it was mired in over-engineered complexity, the w3c docs looked like a nightmarish "design by committee" mess. I believe the intention was never to actually have to see XML let alone write it by hand. Along with the jetpacks of the year 2000, we were promised magical CASE tools that would handle the details. That fizzled out. Instead XML just became a means for encoding configuration that people typed in by hand, sometimes aided by a crappy intellisense-guided schema. We all grew to hate it.
CSS was a great idea on the surface. Compact, not too complex looking: hook into elements by type, class or id, and style them as needed. But for many years it was a half-measure. Browsers behaved differently, and layout was counter-intuitive.
And THAT is what I just can't understand. We had models for how layout on user interfaces should work for many years on desktop applications. CSS just didn't care, it was poor for newspaper-like layout and poor for web-app layout.
CSS grid is such a refreshing step in the right direction, but why so long in coming?
And anyway, how long did we have to use browsers before people realized it's not exactly a piece of A5 paper?
\hspace*{0.75cm}
The history of it was written up by Igalia here:
https://blogs.igalia.com/mrego/2017/03/16/css-grid-layout-is...
Hiding under the pseudonym 'table'.
I wonder if the 'using table for layout is bad' principle of the web should have been reevaluated in the context of SPA web apps in the same way that, for example, 'separate markup, behavior and styles' was.
I know all these things are still controversial and no consensus has been reached, but I'd suggest that this might have been a good idea if we'd started trying it 5ish years ago, in some usecases. Without doubt, css grid is better, but as you suggest we've always had the means to do the job with 'table' right there.
- Clicking multiple times in a box causes an unreadable mess
- If the code gets too long the "Please may I have some code" model disappears off the page, including the only way to close it ("Done" button). Clicking outside the model doesn't close it nor does the escape key.
- If you set rows or columns to -1 it generates a display artifact which remains indefinitely.
- "What does this project do?" model cannot be closed or read fully (outside page limits).
I'm on Chrome retail latest (74.0.3729.169) with 125% Windows DPI.
To clarify, that's when the colours run out - until then things clear correctly.
Should software accomodate those settings or is that up to the user? What's the HN consensus oh that?
So another way to phase the question: "Should a user need to change a Windows' default setting for my site to work correctly?"
Adding support for different zoom levels is not the same as just making a website responsive (there are differences in behaviour if I remember correctly).
UI development has always been developing for the most common denominator and then the best you can make it for the most amount of users.
If the user has a manual zoom in the browser, there's not much you can do from a developer perspective.
You can achieve some flexibility in layout for device, resolution and pixel ratio constraints using CSS media queries, it just depends how granular you want to go and how much time it takes to implement all the use cases from a business perspective (from experience)
Almost all Macbooks DPI is > 100%.
Majority of the new mid-high end windows laptop DPI > 100%.
I don't think that matters developing web apps. Unless you are confusing with Ctrl/CMD + Plus font size increase.
https://developer.mozilla.org/en-US/docs/Web/CSS/gap#Browser...
However when you want the table to collapse vertically instead of staying horizontal on mobile, trying to overwrite the browser defaults of these elements with CSS is a pain and not recommended. Using grid just makes it easier to change the display in CSS.
You could argue that using CSS display:table works too, but display:grid just brings a lot of other niceties for controlling how you want the page to look.
No developer worth his salt has ever used tables for layout since some time in the 2000s. The guy who first thought up such a thing, David Siegel, wrote an article in 1999 titled, "The Web is Dead and I Killed it" about how he killed the web because of it and regrets it all.
One comment though: The generated code contains nested selectors, which are not valid CSS.
The real power of grid is the features you speak of plus the alignment features. With this editor you have a long way to go to create useful responsive layouts with niceties such as implicit grids.
I am coming to the conclusion that you don't need a tool to make a grid for you, that knowing how to write the CSS is where it is at.
The problem is that CSS Grid is a new mindset, if you have been brought up to think in terms of things like '960 pixel wide' grids or how print newspapers do grids then you are not going to fully get it.
I also do not like it how this example perpetuates the div element. According to the specification the 'div' element is not to be used except for in a last resort.
The CSS Grid way of working means there is no need for div wrappers. Centering and aligning content can be done without the div. Again this requires new thinking and people used to slapping divs everywhere with a multitude of class attributes are still thinking they are working with a framework.
If you look at the code for the page rather than the generated code there are a few off-spec 'crimes' that are not needed with CSS Grid. The 'main' element should be in the 'body' as a direct descendent, with this page it nested inside a section that is nested inside a div. This is then styled with flex layout rather than CSS Grid. The page uses complicated calc hacks rather than CSS Grid. The document structure is also quite wrong, the side panel is not an 'aside' outside of the 'main' content.
For this page I would go with '1fr auto' to define the columns. The sidepanel would then take the space it needs and the grid take up the rest. No 'calc' sums needed in the CSS.
Now if you type 'auto' in one of the columns (instead of 1fr) then you get some patronising message saying "Must use real CSS units, goofball". The thing is that for CSS Grid, 'auto' is what you want to be typing once or twice in every project, not being able to use 'auto' (because apparently only goofballs do it) indicates to me that this is quite a beginner project with a lot more work needed.
CSS Grid enables you to strip out all presentational markup from a page, it can be pure content using the HTML5 content sectioning elements. This is a fundamentally different way of working than the hacks of the past. If you wish to further bloat hacky HTML then this tool will help you do it, it won't challenge ingrained attitudes and get people to the promised land of concise, unbloated HTML that separates the concerns.
https://developer.mozilla.org/en-US/docs/Tools/Page_Inspecto...
To put my question another way, I'm trying to figure out where people really need help while creating Grid layouts. Whether we need tools to deeply inspect existing layouts, or whether we just need tools to quickly generate layouts (like Sarah's tool).
Disclosure: I work on Chrome DevTools.
Every good dev I've ever worked with uses generators of some sort or another. There are entire languages dedicated to code generation and scaffolding apps (Cargo, Rails, Yeoman etc.. Yeoman even has generator generators for making new generators). If you're not using them then you're missing a massively useful productivity hack.
I do use rails generators; if possible I’d never want to touch webpack config.
However I would not use css grid generators because I’d prefer the understanding and precision of hand coding css grid specifically.
In my experience teaching web dev to complete beginners, everyone has been able to create reasonable layouts with CSS Grid.
That's an improvement over flexbox which shines and is meant for 1D layouts but requires heavy pushing and shoving for more difficult 2D layouts.
I was thinking I was about to applaud a flex-box wizard that masterfully did ordering and more, but instead I see tags that I'm seriously not sure about. Are they compatible with the rest of my flex-box related site with Bootstrap all over the place? Are they compatible with my child elements and positioning?
Too many questions for this day and age. I don't think enough people are familiar with those particular tags that get generated, but if thats the "new way" lets revisit this in 2021
[1]: https://css-tricks.com/snippets/css/complete-guide-grid/