- 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.
Is this for real? Is there any other scenario where 100% is not the default?
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).
Is there any data on that? I am interested how many people use different % DPI on desktop, what % of the people use scaled font sizes on iOS and Android.
There's plenty of resources out there for 'Browser Stats'. it would really depend on the projects target audience. I have not personally seen any numbers on DPI%, but I wouldn't be surprised if they exist.
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)
It’s an accessibility feature, so just like it’s proper to develop with screen readers in mind, and it is proper to have a readable contrast level, it is proper to support scaling.
It sadly doesn't solve the problem with literally all and every grid generator out there - no proper support for spans and areas. The biggest power of grid is the free-form layouting it provides - it just gets lost in these simplistic editors.
I consider your comment to be constructive feedback.
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.
A grid generator I created back when grid first came out has support for areas. Not spans, but that's because this only focuses on the container and not the children.
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.
Tables are totally fine if what you're visualising is data that belongs in a table. Tables for layouts are not semantically correct and breaks a lot of expected behaviour for people with assisting technology.
Html shouldn't consider layouting, that's for css to do.
I often hear this argument but I haven't been able to grasp its meaning. Is SVG a document format or an application container? I'd say it's definitely not the latter. But it does allow for precise positioning, right? The same goes for PDF or XPS or any such thing, starting from PostScript.
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.
I remember in the late 90's when XML was hot stuff and there was of xsl and it's simpler cousin, xslt, and a capable mechanism for keeping everything "honest", the xml-schema. For whatever reasons, that never took off.
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 shouldwork 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?
I think this is related to the sibling comment, i.e. the document vs application container question.
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.
display: table isn't bad for layout (it's fine, and a perfectly reasonable approach, but please use table-layout: fixed); the table element is bad for layout, because it's an accessibility nightmare (and accessibility tools end up with weird heuristics to determine whether a table is there for tabular data or layout).
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).
I am a dev so I would not use a generator. A tool which gives me instant feedback on the code I write is much more useful. So Firefox CSS Grid and Flexbox inspectors are extremely useful.
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.
what the heck are these grid tags in the generated code?
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
All I needed for my grids was display: table with row wrapping. I got magazine layouts instead with worse vertical alignment of cell content. CSS Grid is cool and does previously impossible things, but I wish the industry fixed old techniques (where is 'gap' in flexbox?), instead of jumping on the next big thing.
Is there a reason to use a CSS grid and not a <table>? Seems like web devs have been crying about a missing feature for a long time when it's already existed. But I only know the basics of web development and don't know best practices, so I don't know why devs would be insisting on using CSS to create a grid when an HTML table works just fine.
The main reason is mobile responsiveness. With <table>, you need to conform to all the table related elements like <tr>, <td>, etc, which is fine on desktop.
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.
Tables are inflexible and inaccessible. Cells cannot be moved or resized without considerable effect on other cells.
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.
I'm surprised to see this big of a reaction. I created something with nearly identical features (only missing the ability to specify gaps) right when grid was released. There was some interest, but not a ton.
As usual with these tools, they're very useful (probably) but almost unusable by anyone with bad contrast vision. Please up the contrast on all the various borders and controls like the arrows on the various number selectors. I can barely use them and I don't think my contrast perception is actually all that bad, this must just be a big black square to someone with properly bad contrast perception.
53 comments
[ 2.9 ms ] story [ 115 ms ] thread- 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.
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://jhpratt.github.io/grid
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.
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...
And anyway, how long did we have to use browsers before people realized it's not exactly a piece of A5 paper?
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?
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.
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.
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/
One comment though: The generated code contains nested selectors, which are not valid CSS.
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.
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.