3 ms·
The first 2 are ersatz "layout systems" that were practiced before flexbox and grid. <table>s and the float property can be used alongside Grid. The easiest (a
by cantSpellSober 3y ago
The first 2 are ersatz "layout systems" that were practiced before flexbox and grid. <table>s and the float property can be used alongside Grid.
The easiest (and default) layout system (flow) is never mentioned
https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layout/Normal_Flow https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layou...
- chatmasta 3y agoThat's a useful MDN page, and it's even the third page of the "CSS Layout" section of "Learn Web Development." And yet, how many people reading these comments have ever seen that page? I'll admit that I hadn't seen it! Sometimes it's nice to read the docs of your tools from the top down, rather than relying on whatever local section of documentation Google sends you when you're solving a specific problem. There are a lot of great docs! (If you use Git every day, when was the last time you browsed the Git manual? How about JavaScript? CSS?)
- pests 3y agoWhen has it became normalized to not read docs and be almost proud of it? I harp on this a lot, but computer engineering will never be treated seriously if we continue acting like documentaton or manuals are too good for us. Its like if when designing a bridge no one read the spec sheet on the bolts. If I ever hear a bridge or structural engineer going "huh, TIL" about a fact found in the manual of a tool or item he uses every day I'm running
- chatmasta 3y agoWell, it's not so much that people don't read docs, but that they don't keep reading them. Most people probably read (or at least skim) the manual cover-to-cover when learning a new tool. But once you're actively using it, the main interaction with its docs is when you land on a specific page to solve your immediate problem. I'm advocating for periodically reading the docs of your most commonly used tools, as if you were a new user. You'll pickup something new nearly every time you do that.
- pests 3y ago> I'm advocating for periodically reading the docs of your most commonly used tools, as if you were a new user. You'll pickup something new nearly every time you do that. Strongly agree.
- julianeon 3y agoYou're talking about docs here as if they're like a textbook on Calculus. Thorough, constant and unquestionably effective. Online docs are nothing like this. First, they can change as frequently as every few weeks, so there's no point in studying them exhaustively if they'll be useless after the next update. Second, they're often inferior to Google's answers on the topic, especially if you're using your question as the search query. Third, even if they are current and the best text resource available, they may still be bad. Halfhearted explanations or even whole pages saying "content should go here." Often worse than simply asking for an explanation in a Slack or a Discord. I don't think that would be true of an engineer with a physical tool, but it's often true of software tools.
- pests 3y agoIf there is an update to the docs, that might mean there was an update to the tool you used. Why not learn the new features of your tool? You can also pin your docs to a version just like your dependencies, no reason for online-only. You can still google things as needed, I just don't see the problem with spending a few minutes familiarizing ourselves with the changelog. Even if they do change every few weeks, we have diffs don't we? I do agree a lot of docs and manuals are not production ready.
- SJC_Hacker 3y agoBecause people work with many different tech stacks. E.g., HTML CSS C++ CMake Python Javascript PostgreSQL Docker Then next year, its something different. And you just need to solve that one problem that one time. You simply don't have the time.