|
Thanks. Dear god, I'm apparently so out of HTML/CSS, it ain't funny.
|
# ? Mar 8, 2021 21:05 |
|
|
# ? May 15, 2024 17:25 |
|
If you only need a layout where everything goes in one direction (think HTML tables with colspans), then you can do it with flexbox (less complicated) without needing grid stuff. You only really need CSS grids when you've got arbitrarily arranged elements you want to lay out without getting into pixel size stuff.
|
# ? Mar 9, 2021 03:38 |
|
You should learn to use both grid and flexbox and use whichever makes the most sense for what you want to achieve. They also work well together. I found these cheat sheets very useful: https://css-tricks.com/snippets/css/a-guide-to-flexbox/ https://css-tricks.com/snippets/css/complete-guide-grid/
|
# ? Mar 9, 2021 04:56 |
|
Roadie posted:If you only need a layout where everything goes in one direction (think HTML tables with colspans), then you can do it with flexbox (less complicated) without needing grid stuff. You only really need CSS grids when you've got arbitrarily arranged elements you want to lay out without getting into pixel size stuff. Flexbox seems maybe as easy to use as table but doesn't seem able to link the width of stuff in a new row with the width of stuff from the previous row. For example, I don't think you could do this layout with Flexbox: code:
Edit: also looks like if you use grid to represent actual tabular data then to add a row you have to also edit the grid template? roomforthetuna fucked around with this message at 06:12 on Mar 9, 2021 |
# ? Mar 9, 2021 06:07 |
|
You can nest flexboxes. It wont have the *authorizing* rigidity of the row and column sizing that tables have, but if you need that, you have tables. The particular example above would be three for boxes. Main row one with three cells, and two column ones in the first and last of those cells main flex box cells.
|
# ? Mar 9, 2021 15:04 |
|
Just going to state the obvious in case it's been missed. If you're actually displaying tabular data, like a list or something, then you should just use plain old tables.
|
# ? Mar 9, 2021 15:16 |
|
go play outside Skyler posted:Just going to state the obvious in case it's been missed. If you're actually displaying tabular data, like a list or something, then you should just use plain old tables. Okay Gramps. I'll just get in my time machine and go back to the 90s.... (I completely agree, btw)
|
# ? Mar 9, 2021 17:45 |
|
roomforthetuna posted:I don't see how flexbox maps to a table with colspans (based on the flexbox cheat sheet just linked). HTML code:
Roadie fucked around with this message at 01:08 on Mar 10, 2021 |
# ? Mar 10, 2021 01:05 |
|
Roadie posted:Being able to set arbitrary flex values is what I mean by the analogy to colspan. You can have a set of elements with flex: 1; and then one with flex: 2; to take up double the size in the flex direction. Your rendition of my "doesn't work" example happens to work if the contents are literally the word "corner" in every corner, but it doesn't work if the top left corner is "corner\on two lines" and the top right corner is "corner", and you wanted those horizontal lines to be aligned, which is what I meant. Sorry it wasn't that clear. I specifically use this layout on a website to make some header content that looks like a horizontal band across the middle row, with an overlaid segment, kind of like a belt and belt-buckle. Having the side columns arrange their heights independently breaks the 'belt'. I used a table because I made the website like 20 years ago, not sure if it would be 'cleaner' as a css grid (maybe a little because the components could be ordered more logically rather than having the 'buckle' content first [given the top left cell is empty]), but I don't really see any firm reason to not use a table for layout.
|
# ? Mar 10, 2021 04:37 |
|
roomforthetuna posted:but I don't really see any firm reason to not use a table for layout. There are tons of reasons. With flexbox and grid, it’s easier to re-order elements, it’s easier to program responsive sizes, your markup is more semantically correct, and there’s far less boilerplate in your template files.
|
# ? Mar 10, 2021 05:02 |
|
fsif posted:There are tons of reasons. With flexbox and grid, it’s easier to re-order elements, it’s easier to program responsive sizes, your markup is more semantically correct, and there’s far less boilerplate in your template files. Tables do responsive sizes really well by default, css typically requires you to painstakingly tune it to do responsive sizes or it'll do something awful by default. More semantically correct seems like just opinionated bullshit. How is a table semantically incorrect? It's no more semantically incorrect than a grid being used as a general layout arranger, not as a grid. Table and grid are semantically exactly the same thing in a layout context. Flexbox is more semantically correct, I'll grant, but if it doesn't do the layout you want then that's not worth anything. Ease of re-ordering elements is a weird red herring that css people seem really into. How often do you actually go "oh well I want to keep all this content and in the same general layout but put the parts in a different order now"? In over 20 years of doing web things that has never been an issue, and even if it had, copy-pasting a block of text from one place to another is far easier than bollocking around with weird css attributes that you applied 2 years ago and have forgotten what they refer to. Edit: an actual reason to use new CSS poo poo though, is that if you do that people will think you're good at this stuff, whereas if you use a table for the exact same outcome, people will think you're a grognard dinosaur.
|
# ? Mar 10, 2021 05:36 |
|
roomforthetuna posted:Your rendition of my "doesn't work" example happens to work if the contents are literally the word "corner" in every corner, but it doesn't work if the top left corner is "corner\on two lines" and the top right corner is "corner", and you wanted those horizontal lines to be aligned, which is what I meant. Sorry it wasn't that clear. I don't really understand what you're trying to describe here, but you can probably do it with flexbox. code:
roomforthetuna posted:Tables do responsive sizes really well by default Huh? Tables are awful to try and do layout in for responsive sizes, because as soon as the screen is too small nothing fits and as soon as the screen is too big you've got a ton of whitespace between everything. roomforthetuna posted:Ease of re-ordering elements is a weird red herring that css people seem really into. How often do you actually go "oh well I want to keep all this content and in the same general layout but put the parts in a different order now"? Often. Very often, actually. The simplest example is laying out UI elements in columns that then become a single continuous top-to-bottom layout on mobile. Roadie fucked around with this message at 06:52 on Mar 10, 2021 |
# ? Mar 10, 2021 06:17 |
|
Roadie posted:I don't really understand what you're trying to describe here, but you can probably do it with flexbox. I mean like if the top left corner has an amount of content that happens to wrap in the available space and take up two lines because you've got actual content in there, not specially shaped loving images and buttons that have to be a precise size or nothing works, like how modern design always is. And the top right corner has an amount of content that happens to not wrap and so does not take up two lines. And you want the bottoms of both of those sections to be at the same vertical position or it looks poo poo. And you don't know the wrap constraints in advance because you haven't painstakingly measured everything to the pixel for every possible language combination, so you can't just loving go "well obviously one of them is flex: 2 and the other one is flex 1 lol". And also if you widen the window such that the top left segment now fits on one line, you want that band to reduce to the height of one line, or if narrowed maybe it goes to three lines, so you can't just go "well we'll just make it big enough to accommodate the most lines it will ever be". Why yes, I *do* work with designers who give me specs that lay things out like the flexbox but actually have requirements like this so the designs are invalid when the strings change and then have to explain all the actual real constraints to people who don't listen, every goddamn day.
|
# ? Mar 10, 2021 07:09 |
|
roomforthetuna posted:Edit: an actual reason to use new CSS poo poo though, is that if you do that people will think you're good at this stuff, whereas if you use a table for the exact same outcome, people will think you're a grognard dinosaur. Listen, I hate to be so blunt, but you don’t fundamentally understand the flexbox and grid specs and you don’t appear to have much experience in the way of developing a contemporary web layout. Tables are a horrible tool for responsive layouts. The columns don’t wrap. If you’re dead set on using tables for a responsive design, you literally need to make a new table—complete with duplicate content—for any new configuration of columns. Even in the pre-flexbox days, developers moved past tables and hacked things together with utility libraries like bootstrap and used floats and clearfixes. A table is semantically incorrect for layouts because it signifies tabular data. The markup of a grid and a table look nothing alike. You can almost certainly make whatever layout you’ve devised via a table in flexbox. Items being re-ordered on a different device size happens on every site/app of moderate size I’ve developed for at least the past five years. Much smarter minds than either of us have spent years creating these specs for the express purpose of addressing the shortcomings of the old specs. The idea that you’ve outsmarted them with a seven cell table is absurd on its face (and, again, incorrect). Listen to your designers.
|
# ? Mar 10, 2021 07:52 |
|
Personally, I'll take a layout done with tables that actually meets the requirements over something done with flexbox that doesn't. I mean, conceptually, I agree with the idea that modern CSS should be able to replace tables effectively. But then I see repeated failed attempts at replicating a pretty straightforward table-based layout and I get a bit suspicious as to whether it actually delivers on that idea.
|
# ? Mar 10, 2021 10:25 |
|
Jabor posted:Personally, I'll take a layout done with tables that actually meets the requirements over something done with flexbox that doesn't. It definitely replaces tables effectively. But if you see a HTML table in your mind's eye, then perhaps the modern (for the past couple decades... ) version doesn't look exactly like that, just like a car doesn't look exactly like what you want when you're used to horses. But it's the car you should be using when you're delivering transport services and the product designer shouldn't need to specify "don't use horses".
|
# ? Mar 10, 2021 12:03 |
|
Anyone have a good course or video they can recommend on css grids?
|
# ? Mar 10, 2021 13:46 |
|
People like this one alot https://www.leveluptutorials.com/tutorials/modern-css-layouts/css-grid-basic-terminology
|
# ? Mar 10, 2021 13:48 |
|
Ola posted:It definitely replaces tables effectively. But if you see a HTML table in your mind's eye, then perhaps the modern (for the past couple decades... ) version doesn't look exactly like that, just like a car doesn't look exactly like what you want when you're used to horses. But it's the car you should be using when you're delivering transport services and the product designer shouldn't need to specify "don't use horses". Are you suggesting that I need to change my product design because the new-fangled supposed-to-replace-the-old-way-entirely doesn't actually support the product design I have in mind? If it doesn't support the product design I have in mind, while the old one does, why should I switch to it? Because the old way offends someone's sensibilities if they peer under the hood to see how it works?
|
# ? Mar 10, 2021 13:53 |
|
Jabor posted:Are you suggesting that I need to change my product design because the new-fangled supposed-to-replace-the-old-way-entirely doesn't actually support the product design I have in mind? Tables are for tabular data, using them for anything else these days is pointlessly painful and incompatible with anything more than landscape desktop. Semantic HTML aside, the part where you mention that "I'll take a layout done with tables that actually meets the requirements" is basically the pain point here, because getting a layout done with tables that works on _more than one exact device type_ is nearly impossible without ludicrous amounts of unnecessary effort, content duplication (sometimes more than quadrupling your response size), etc. Tables have a lot of weird overriding qualities and gotchas that make them unfun and unfeasible to really use in any non-trivial layout. You could make the argument that a forum might be a two column table consisting of username and post content, but blarghalahrbrgh
|
# ? Mar 10, 2021 13:58 |
|
Whoever balks at tables no matter the context should have their dev license revoked. Or at least be required to have a giant, easily visible "L" attached to their monitor. E: but yeah, don't do layout with tables. If the requirement can only be met by using the tables, the "L" sign needs to go onto that print-designer-who-pretends-to-be-a-web-designer's monitor. gbut fucked around with this message at 14:09 on Mar 10, 2021 |
# ? Mar 10, 2021 14:04 |
gbut posted:Whoever balks at tables no matter the context should have their dev license revoked. Or at least be required to have a giant, easily visible "L" attached to their monitor. Hurts my soul to see people defending tables. We finally got decent solutions for layout in CSS after years of suffering
|
|
# ? Mar 10, 2021 14:27 |
|
Jabor posted:Are you suggesting that I need to change my product design because the new-fangled supposed-to-replace-the-old-way-entirely doesn't actually support the product design I have in mind? If your product design specifically asks for a table, go ahead. But in my experience, designers don't specify HTML elements, they specify design. It's my job to figure out how to implement it. Btw, if I was in charge of design AND implementation, I'd struggle to come up with anything that really needed tables for layout. A page layout is not a table. Look at print newspapers. They might have X columns on each page, but they have an arbitrary amount of "rows" in each column, because they're not rows. Each article is not a cell in an X,Y coordinate system. Using tables for layout is also hell on accessibility, it makes it harder to navigate with screen readers, which reads tables expecting tabular data where they can read the column header for every cell etc. Again, if your product design is cool with that, go ahead. But you've surfed past thousands of sites that have successfully used proper layout elements without noticing, there are heaps and heaps of tooling and tutorials to help you learn it.
|
# ? Mar 10, 2021 14:39 |
|
lunar detritus posted:Hurts my soul to see people defending tables. We finally got decent solutions for layout in CSS after years of suffering I don't know dude. If you want me to not use tables on that tabular data, I don't know.... (Use tags for semantics, or use display type if you hate the tag, but they are useful in established cases) After decades in this industry I've come to conclusions that there are two types of people who hate tables: - people who had to use them for layout, old types like me. They carry the original trauma - younger devs who think tablea are as obsolete as the blink element, who inherited the trauma without actually ever experiencing its origin. One might say that tables caused intergenerational trauma, and those things are really hard to address without some professional help.
|
# ? Mar 10, 2021 15:06 |
|
Theres alot of talk about tables so I actually have a question for them that i'd like to ask you guys. My "main" project is a backend form system developed in nodejs express & pug. Alot of the forms were originally envisioned as tables, which It ranslated over: Now as has been stated, this is horrid for mobile technologies and requires a landscape desktop. Is there a better way I should be attacking this useability wise? it won't be publically exposed so not worried about accesability. The other question I have is I have one form that has about 200 fields on it. I'm wondering if something like that is a good idea or does node have a risk of timing out if someone takes forever to subnit the form? Thanks
|
# ? Mar 10, 2021 15:09 |
|
Empress Brosephine posted:or does node have a risk of timing out if someone takes forever to subnit the form? Can you explain this? Do you mean a CSRF/XSRF token epxiring if someone sits on the same page without moving for hours? 200 fields is nothing, no.
|
# ? Mar 10, 2021 15:13 |
|
smackfu posted:Anyone have a good course or video they can recommend on css grids? http://cssgridgarden.com/ roomforthetuna posted:Jesus, no, not that! That is like the exact opposite of what I was describing. sounds like you need a grid
|
# ? Mar 10, 2021 15:19 |
|
Biowarfare posted:Can you explain this? Do you mean a CSRF/XSRF token epxiring if someone sits on the same page without moving for hours? Yeah basically that. I have bad memories of websites timing out if you sat on a form for too long and didn't hit submit; or you'd hit submit and it'd all be gone. The client wants a way to save the forms and continue to keep working on them, but it wasnt apart of the original ccontract and that seems like alot of work for a little feature. Thanks
|
# ? Mar 10, 2021 15:32 |
|
If you have a reasonably modern single page app you can just lazily serialize/deserialize the state or store of the tables into localStorage periodically; this doesn't take much more time other than some json.stringify(). Clear the localstorage key on a successful submit and receiving a hard 200 OK from the server or something. If you have legacy code you can just lazily use something like https://github.com/kugaevsky/jquery-phoenix/
|
# ? Mar 10, 2021 15:33 |
|
I don't have any front end framework on the project, so I don't have access to any kind of state mangement or even conditional forms, but I didn't know about Phoenix, maybe that's the way I should go. I've never used jquery though but i'm guessing it's not that crazy to implement. Thanks!
|
# ? Mar 10, 2021 15:43 |
|
If you're not already using jquery then something like https://github.com/appleple/form-storage might be better. Don't add it if you don't already use jq If it isn't very sensitive data, you can always escape and re-print it back out into the form regardless of validity, or set a very high CSRF token expiration time, who knows, depends on risk model.
|
# ? Mar 10, 2021 15:50 |
|
I'd probably also question the necessity of a mobile version in the first place. That doesn't look like the type of form I'd ever sit in bed and lazily complete. If your client insists that there's some use case where they're maybe out in the field and need to complete the form on a phone, I'd maybe see if it was feasible to have a condensed version with fewer fields that could be completed later on a desktop. Can't imagine completing a form with 200 fields on my phone.
|
# ? Mar 10, 2021 15:59 |
|
yeah this absolutely looks like something i'd hit tab through
|
# ? Mar 10, 2021 16:00 |
|
Nah it's just analytical data, nothing personal. I don't even do much validation on it either because its just getting stored in a database and then printed via some weird npm print thing I found. I'll look into that appleple thing though, that seems to be perfect. thank you so much, as always
|
# ? Mar 10, 2021 16:00 |
|
fsif posted:I'd probably also question the necessity of a mobile version in the first place. That doesn't look like the type of form I'd ever sit in bed and lazily complete. I expect 0 people to do it mobile because theres also alot of very long open ended questions that I have set up like this: image hosting websites But knowing my luck they're going to say that someone couldn't use it on theri phone to write a 2000 word essay
|
# ? Mar 10, 2021 16:01 |
|
There's a surprising number of people who use a mobile device as their only computer. But I agree, there's no point in trying to make a mobile-friendly variant of something like that, just give them a full size version and let them scroll and enlarge if they insist on it.
|
# ? Mar 10, 2021 16:49 |
|
Empress Brosephine posted:Now as has been stated, this is horrid for mobile technologies and requires a landscape desktop. Is there a better way I should be attacking this useability wise? it won't be publically exposed so not worried about accesability. If it's not publicly exposed and will only be used in a certain setting on certain hardware, then I would develop it with that setting and hardware in mind.
|
# ? Mar 10, 2021 16:56 |
|
Jabor posted:I mean, conceptually, I agree with the idea that modern CSS should be able to replace tables effectively. But then I see repeated failed attempts at replicating a pretty straightforward table-based layout and I get a bit suspicious as to whether it actually delivers on that idea. I don't think I've ever seen a table that couldn't be replicated with CSS Grid, and trivially at that. But I'd be very curious to see an example to the contrary. With the exception of borders. I don't think CSS has a good answer for what you can do with border-collapse on a table.
|
# ? Mar 10, 2021 16:59 |
|
Biowarfare posted:If you're not already using jquery then something like https://github.com/appleple/form-storage might be better. Don't add it if you don't already use jq This works and it rocks, thank you so so much. That was way easier than I expected. Another quick question; instead of writing about 200 if statements to see if a field is empty or not using lodash, can I do it using a switch case? so right now i have: code:
code:
|
# ? Mar 10, 2021 18:38 |
|
|
# ? May 15, 2024 17:25 |
|
Empress Brosephine posted:Theres alot of talk about tables so I actually have a question for them that i'd like to ask you guys. The simple first-pass version, before you get to redesign stuff, would be to turn each of those rows into a div that has flex-direction: row; at desktop size and flex-direction: column; at anything smaller than that, plus input labels that are only visible at the smaller size. (You'll also need to mess around with flex values on the cell divs and other flexbox stuff based on viewport stuff. This shorthand reference is pretty good for that.) That'll give you something at least borderline usable at all screen sizes because you've got cards on small screens and rows on big screens. Bigger redesign stuff would depend really heavily on your users' use cases (and beware of the XY problem if you ask them about it), but if it was me I'd look at switching away from a table layout to full-width cards, which can be just as keyboard-usable as long as you set things up right and which give you room to set up UI elements for validation on each card. Roadie fucked around with this message at 19:30 on Mar 10, 2021 |
# ? Mar 10, 2021 19:22 |