[HN Gopher] My First CSS
___________________________________________________________________
My First CSS
Author : nhardy
Score : 281 points
Date : 2021-07-26 04:12 UTC (18 hours ago)
(HTM) web link (engineering.kablamo.com.au)
(TXT) w3m dump (engineering.kablamo.com.au)
| greggman3 wrote:
| For me those rules are not the fundamentals. There's more you
| need to know to actually get CSS to work (and I still usually
| have to guess and google and try random things to get it to work
| because my knowledge is lacking)
|
| In particular trying to get content of some flexbox to fill the
| space provided by the flexbox itself, especially in a single non-
| scrolling app like page where you're trying to constrain
| everything to fitting in the window. Like the rule that you have
| to set min-width to 0 or something to get the desired behavior.
|
| https://makandracards.com/makandra/66994-css-flex-and-min-wi...
|
| That's not the only gotcha
|
| I suppose you could argue that's not fundamental but to me, basic
| layout that most standard native UI toolkits would provide is an
| essential feature and yet to achieve it in CSS requires knowing a
| few obscure tricks
|
| I wish someone would write some other UI language that would
| translate into CSS so I could write full window
| frame left side right side
| toolbar content
|
| And it would generate the correct CSS to make it work
|
| To put it another way, imagine you want to repo the Keynote UI or
| Numbers UI in a webpage. Those are basic app UIs and yet they
| just slightly less than straight forward in CSS. I'm not saying
| they are hard, only that most people will have to goole some non-
| intuitive tricks to get things to work which is a different
| experience than trying to do them in a native UI kit where it's
| more likely fairly clear how to achieve it.
| oleh wrote:
| Have a look at autolayout.js! Here's a link to a previous
| discussion on this site:
| https://news.ycombinator.com/item?id=21997622
| cuddlecake wrote:
| > Like the rule that you have to set min-width to 0 or
| something to get the desired behavior.
|
| Thank you, you're my savior. This is exactly the problem I had
| on Friday and now I can finally solve it.
| deergomoo wrote:
| > Like the rule that you have to set min-width to 0 or
| something to get the desired behavior
|
| I understand why this is the case (mostly thanks to a patient
| HN commenter who explained it to me), but holy hell it annoys
| me how unintuitive it is. You have to set _min_ -width to stop
| a flex child being too _big_? Get out of here with that
| nonsense.
|
| The common wisdom seems to be that 1D layouts should use flex
| and 2D should use grid, but I don't think I agree with that.
| These days, I only ever use flex for layouts that should
| actually be flexible. Even if it's a single dimension, if it's
| fixed-widths it's straight to grid for me now, and my life is
| measurably better for it.
| dmz73 wrote:
| I think there is a very easy fix to most HTML/CSS problems when
| building GUI on the web - use HTML5 canvas. HTML is not a good
| match for GUI and CSS is not a good match for...anything. HTML5
| canvas brings you to where Windows/X was 25 years ago so
| instead of trying to build GUI using TUI, just use the damn GUI
| already. Sure, the whole lot of tooling is missing but some
| copy/paste/fix from either Windows or X should produce better
| result than S*T ton of HTML/CSS/JS that is currently there
| attempting (and failing) to emulate Windows/X GUI.
| KronisLV wrote:
| That's not really a fix, though. Flutter is trying to use
| this approach and if you go to their demo sites you will
| notice things feeling slightly off:
| https://gallery.flutter.dev
|
| Some of the notable drawbacks: - you can no
| longer select text on the page, anywhere - right click
| doesn't work like you'd expect it to, either, since you're
| looking at a canvas - currently the download sizes are
| absurdly large, since you need to pack a large amount of
| functionality in .js/.wasm (over 10 MB, actually) - for
| simpler pages, the performance overhead will be very
| noticeable, just try zooming in or out in those pages (i got
| <2 fps while zooming on a decent desktop computer) -
| essentially all of the former accessibility benefits of DOM
| are now gone and screen reader support needs to be developed
| anew, assuming that they'll even support your canvas based
| solution - furthermore, learning about websites by
| inspecting source to see how they did it is no longer
| possible; and you can no longer crawl these sites in any sort
| of an automated manner, which may be a good/bad thing
| depending on how you look at it
|
| I'd say that most GUIs should be simple enough to work well
| with DOM, instead of throwing away decades of progress while
| chasing niche goals. HTML and CSS are great for displaying
| all sorts of documents and personally i think that the web
| should not stray too far from that - utilitarian interfaces
| that are simple and easy to understand, rather than sci-fi
| ones like portrayed here: https://www.saji8k.com/kit-
| fui/movie/
| adwn wrote:
| > _Some of the notable drawbacks: [...]_
|
| Wow, that's really, really bad. Thanks for calling
| attention to that.
|
| > _currently the download sizes are absurdly large, since
| you need to pack a large amount of functionality in .js
| /.wasm (over 10 MB, actually)_
|
| Just wait till someone uses this to build their desktop-
| only Electron app.
| robin_reala wrote:
| If you don't use the DOM you need to reimplement your own
| accessibility tree and bind that into the access APIs. Or
| choose to be specifically illegal in a bunch of important
| markets, and potentially illegal in the US.
|
| I'll just stick with the easy paths.
| blacktriangle wrote:
| Canvas doesn't bring you do Windows/X11, Canvas brings you to
| a basic VESA driver where you're plotting pixels manually.
| You think the JS framework churn is bad now when all of those
| frameworks are just layers over HTML, just imagine the world
| we're looking at if everybody is writing their own full GUI
| framework to work with canvas. At least with JS framework
| hell everything is guarenteed to have the same output format
| that we can then interact with with our common set of HTML
| tools, with Canvas all bets are off.
|
| I get where you're coming from, I really do. HTML5 and CSS
| are just bad tools for doing GUIs. But there is so much
| infrastructure built up around them that just overrules any
| advanage we would get hand rolling a GUI directly rendered to
| canvas.
| adwn wrote:
| > _HTML5 and CSS are just bad tools for doing GUIs_
|
| Is there something better? With Qt Widgets, the poster
| child for cross-platform GUI toolkits, I also frequently
| have problems with getting the layout to behave the way I
| want.
| blacktriangle wrote:
| Android dev is better, iOS dev is better, heck even Tk
| layouts are better.
| adwn wrote:
| > _Android_
|
| Not cross-platform.
|
| > _iOS_
|
| Not cross-platform.
|
| > _Tk_
|
| Decreasing mind-share for 2 decades+, not something I'd
| start a new project with.
| blacktriangle wrote:
| Cross-platform and being a good tool are orthogonal
| concepts. We use HTML/CSS for GUIs IN SPITE OF their
| general unsuitableness because the value of easy
| distribution wins over developer sanity.
| adwn wrote:
| > _Cross-platform and being a good tool are orthogonal
| concepts._
|
| I agree, but when I need to develop some software for
| Windows and Linux, a great toolkit for Android or iOS is
| of no use to me. Similarly, I won't use a Linux-only or
| Windows-only toolkit, as awesome as it may be, because
| I'm not going to build two different GUI layers.
| martyalain wrote:
| It's what I do with a small language I'm working on, for
| instance
|
| http://lambdaway.free.fr/lambdawalks/?view=splash2
| martyalain wrote:
| More can be seen on the lambdatalk language in
| http://lambdaway.free.fr/lambdawalks/?view=coding
| worble wrote:
| It's not quite the same, but CSS grid does make creating those
| kind of high level layouts much, much easier with `grid-
| template-areas`: .header { grid-
| area: hd; } .footer { grid-area:
| ft; } .content { grid-area: main;
| } .sidebar { grid-area: sd; }
| .wrapper { display: grid; grid-
| template-columns: repeat(9, 1fr); grid-auto-rows:
| minmax(100px, auto); grid-template-areas:
| "hd hd hd hd hd hd hd hd hd" "sd sd sd
| main main main main main main" ". . . ft ft
| ft ft ft ft"; }
|
| Way more declarative, in my opinion.
|
| For fitting it all in one page, you can make the containing
| grid 100vh and ensure content takes all the extra free space,
| see this pen (from Mozilla) for an example:
| https://codepen.io/miriamsuzanne/pen/JjPeQYP?editors=0100
|
| https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_La...
| hmwhy wrote:
| Based on the way the article is written, I assume that software
| engineering was not new to the author when he first started
| writing CSS. It seems strange to me to write an article like this
| because it's just an indication that the author chose to dive in
| without understanding the fundamentals first.
|
| I'm honestly just trying to understand how articles like this get
| promoted to the front page of Hacker News more and more often. I
| imagine that writing an article about [insert related field of
| mathematics] before diving into [insert field of physics] every
| week would not land me on the front page of Hacker News every
| week.
|
| Edit: "basic field" -> "related field".
| brundolf wrote:
| > it's just an indication that the author chose to dive in
| without understanding the fundamentals first
|
| You'd be surprised how many otherwise-competent engineers don't
| take CSS seriously enough to seek out the fundamentals, and
| instead spend their days avoiding it as much as possible and
| cursing it when they can't
| pjerem wrote:
| I totally avoid CSS at work because it's just an insane
| whack-a-mole spaghetti based upon our own SASS framework
| written by a few designers that had to learn CSS without any
| mentoring (since they are in their own << design >> team),
| and don't understand the consequences of what they do.
|
| So yes, I totally spend my days avoiding it. Not because I
| hate CSS (I love it in some way, and I miss writing elegant
| stylesheets) but because CSS is a delicate tool that is hard
| to be maintained by more than a few people.
| brundolf wrote:
| I'll agree that it's a delicate tool. Similar to Lisp, CSS
| is very elegant in the right hands but also heavily reliant
| on the devs sticking to strong conventions and principles.
| On solo projects, or projects with just a couple of devs,
| it can be wonderful. But it does tend to have trouble
| scaling.
|
| Which is why, even though I don't love them, I respect the
| usefulness of things like CSS Modules that impose more
| scoping and constraint over CSS codebases. For bigger teams
| they do tend to be necessary.
| hn_acc_2 wrote:
| There is a stigma amongst "real programmers" against "web
| developers". So a "real programmer" will never become adept
| at CSS because it doesn't appeal to their ego
| FindMySocks wrote:
| The question then comes, where would one go to learn the
| fundamentals-and what are they now?
|
| Being someone who was ahead of the game in css 15 years ago,
| but not having touched it since - where would one go to
| understand the new fundamentals and options available?
| dwd wrote:
| Once upon a time Eric A Meyer's CSS: The Definitive Guide was
| the book to own.
|
| These days, as mentioned in the OP, MDN is the best point of
| call for checking syntax or learning how to implement
| something new the right way.
| pramodbiligiri wrote:
| This is a great recent book from an experienced practitioner
| - https://learningwebdesign.com/
|
| Her explanation of positioning, responsive design and the
| links to other resources she provides inside are all good.
| brundolf wrote:
| The OP is a good outline of the most important stuff. This is
| my favorite comprehensive introduction to flexbox:
| https://css-tricks.com/snippets/css/a-guide-to-flexbox/
|
| And then follow it up with this one if you want to go a
| little deeper: https://css-tricks.com/flex-grow-is-weird/
|
| Personally, I think flexbox is the single most versatile and
| important tool to be familiar with. You can create nearly any
| layout with it, in such a way that it's very naturally
| responsive almost by default.
| [deleted]
| hmwhy wrote:
| Maybe I am wrong, but I would assume that the most sensible
| place to start with is the MDN Web Docs[0] in this case
| instead of looking for blog posts.
|
| Throwing out blanket statements is dangerous for new comers,
| which seems to be the target audience of this article
| according to its title. For example, collapsing margin isn't
| always bad and unpredictable, it just seems that way if you
| didn't take the time to understand the fundamentals behind
| and go for "what works".
|
| That's not too different to telling CS students to not worry
| about learning the memory and time complexities of different
| algorithms and just use [insert "best" algorithm] because it
| works most of the time.
|
| [0] https://developer.mozilla.org/en-US/docs/Learn/CSS.
| dmitriid wrote:
| I would go for https://every-layout.dev/
|
| These are actual practical usable fundamentals.
|
| Complement that with http://inclusive-components.design/
| n0w wrote:
| I definitely find `box-sizing: border-box` fits my mental model
| much better.
|
| I rarely find a need to think about `positioning` though and I
| think the article doesn't give enough credit for `display: flex`
| and `display: grid`. I tend to reach for `display: flex` as a
| default and find it much more intuitive. Whether it's easier for
| a beginner is a different question though.
| candiddevmike wrote:
| To me, CSS is probably the most "artistic" kind of work I do, so
| a good CSS writing session involves being in the right artistic
| headspace. The work is a lot like shaping clay--a little padding
| here, some flexbox there. I use classes scoped to components and
| avoid global styles, lessens the blast radius. I also leverage
| CSS variables in lieu of SASS and friends to keep things vanilla.
| Once it's done, like playing with clay, I couldn't really
| describe the process of getting to the final product, it just
| materializes over the iterations.
| qwertox wrote:
| > box-sizing: border-box
|
| I feel ashamed not knowing about this option. _content-box_ has
| caused me so many troubles over and over again, and I didn 't
| know it had such an easy solution.
| petepete wrote:
| I always thought I knew CSS quite well but only found out about
| border box quite recently too.
|
| My CSS knowledge has improved substantially since subscribing
| to Kevin Powell's YouTube channel.
|
| https://www.kevinpowell.co/
| anyfactor wrote:
| > Everything is a rectangle.
|
| I remember a time when everything was a table.
| goto11 wrote:
| Tables are rectangles, and so are rows and cells.
| icedchai wrote:
| Me too. And for a good 10+ years after CSS became popular, it
| was still simpler to lay things out in tables.
| milross wrote:
| Looking at the site, I'd say that some of the information are
| well described. Still, a lot of people get confused on the box
| model might as well on the flex box, grid and manipulating
| transitions and animations.
| bibble wrote:
| Why don't <button>'s default to: "cursor: pointer;"?
| frosted-flakes wrote:
| Only links get the pointer cursor. Buttons are not links.
| lwigo wrote:
| I think the answer has to do with calls to action and the
| assumption users make that the cursor hand is a link to another
| web page or another part of the site, while not all buttons are
| hyperlinks. Probably not as much of an argument in these days,
| though, especially as most sites are single page applications
| where basically every button does indeed do some sort of
| reroute, target blank (new tab), or network call at the very
| least.
|
| Also, to be pedantic, not all buttons are entirely clickable,
| only small portions of them.
|
| Edit: Interesting that HN doesn't use the cursor hand for reply
| / updating. ;)
| frosted-flakes wrote:
| HN barely even uses CSS. It's all tables, straight out of
| 1999.
| pramodbiligiri wrote:
| This is a great list! For someone starting out with modern CSS
| I'd add: a working knowledge of Flexbox, and media queries to
| enable responsive design.
| nazrulmum10 wrote:
| I think these are most of the guiding principles that I wish I
| understood a lot sooner than I actually did. I spent a lot of
| time fumbling around, tweaking CSS back and forth, and not really
| understanding why things weren't behaving as expected.
| locallost wrote:
| I've known those things listed for 15 years now, and they did not
| help with the wack-a-mole problem. Especially not when working
| with multiple people.
|
| The only thing I've found to actually work is to keep things as
| simple as possible when it comes to your actual stylesheet. Any
| kind of complexity including some core CSS properties (e.g. the C
| for cascading) I avoid. My second box .foo is only slightly
| different so I will adapt it based on its parent .bar leads to
| misery. Eventually you will need .baz .bar .foo. Or .bar
| .foo:not(.shoot-me) and all of that will be burried in 100+K of
| code done by people that left the project 2 years ago. Hence
| wack-a-mole. So I try to do myself a favor and just avoid any
| kind of CSS logic. The complexity will be moved to the template,
| so not really gone, but at least you can make a change and not
| worry about something else breaking. And at the very least, if it
| gets complicated, you can write a test to check if your html code
| contains proper classes.
| themodelplumber wrote:
| I'm baffled that you were able to serve up such an eloquent
| slice of pain without even mentioning !important?
| routerl wrote:
| I'm impressed by the phrase "eloquent slice of pain", and
| have felt the !important pain.
|
| Thanks for the catharsis.
| city41 wrote:
| I've also found atomic css, such as Tailwind, largely
| eliminates this problem. Yeah, a controversial opinion, but
| regardless of how you feel about utility classes, they do avoid
| this problem.
| steve_adams_86 wrote:
| I used to be a bit of a CSS purist and I thought things like
| tailwind created a mess where some thoughtful and strategic
| thinking could prevent it. In reality, preventing the mess
| costs a lot of time and energy. I'd rather have ugly markup
| and get things done than have nice CSS. Our users don't give
| a single shit how nice our CSS is.
|
| I'm on a team of 4 competent people who touch front end code,
| and despite our experience with it CSS is more of a recurring
| pain than anything else. We plan to make a slow migration to
| tailwind, essentially building new things with it and keeping
| our bespoke CSS in maintenance mode until it's replaced or
| retired. I'm looking forward to our ugly markup.
| _def wrote:
| I worked some years as a full stack web dev, and css was mostly
| what blew up my time needed. I recently built a small landing
| page and now I officially gave up on CSS. I just don't want it to
| be a part of my professional life anymore. I guess I lack some
| fundamental design and layout concepts but I don't want to fix
| this. I might as well run a bakery.
| busymom0 wrote:
| I once inherited a project where the previous "webbed" had forced
| a lot of css formatting using "!important". I wanted to pull out
| my hair because of how unpredictable everything was.
| ldd wrote:
| Learning flexbox is when CSS started clicking for me. I may abuse
| `display: flex` everyone once in a while, but it can truly be
| used for a lot of ideas.
| Toutouxc wrote:
| I often use flexbox for tiny things like vertically aligning a
| checkbox and a label and I still don't know whether this is the
| correct "scope". Like, can I have tens or hundreds of flexbox
| containers on the page? Does flexbox even take significant time
| to process, compared to some other css constructs?
| Trufa wrote:
| I love abusing flexbox.
| high_byte wrote:
| Front Ender sounds like a Minecraft boss
| hnarayanan wrote:
| I had the same thought! A site called "Front Enderman" for
| Minecraft-themed CSS tutorials.
| kilodeca wrote:
| > CSS can be hard to grasp when you're starting out. It can seem
| like magic wizardry and you can very easily find yourself playing
| whack-a-mole adjusting one property only to have something else
| break.
|
| Only if you learned from the wrong source.
| ojkelly wrote:
| like w3schools back in the days before MDN and YouTube existed.
| itsArtur wrote:
| Do you mind sharing the good source?
| ojkelly wrote:
| MDN is the best reference to keep on hand to check how
| something works. https://developer.mozilla.org/en-
| US/docs/Web/CSS
|
| and web.dev has a pretty decent walk through for learning css
| https://web.dev/learn/css/
| [deleted]
| croes wrote:
| >CSS can be hard to grasp when you're starting out
|
| The browser differences especially for the box model were the
| bigger problem.
| robertwt7 wrote:
| The article is well written, good reminder for all of us who
| works with css.
|
| I still remember learning all of those things years ago. However,
| because I don't use vanilla css, I mostly always have to re-
| google them again.
|
| Actually, for the past few years my css in both professional and
| side projects has always used tailwind in React (except for react
| native), 95% of the layout are flexboxes and grids.
| ipnon wrote:
| CSS is a lot like the underground infrastructure of NYC. Most of
| it was happenstance, a lot of it is undocumented or no longer
| remembered, you ignore the advice of authorities at your own
| peril, and no matter what you're trying to do it's going to
| involve a lot of digging.
| Brajeshwar wrote:
| We used to loved CSS Quirks Mode (or Strict Mode).
|
| https://www.quirksmode.org/css/quirksmode.html
| Brajeshwar wrote:
| I tend to believe that someone who can do magic CSS is about the
| ability to weave it with Mathematics and patterns. Other than
| that, the way you use CSS as it evolves become more and more
| syntactic sugar.
|
| Once you are comfortable with CSS, try to dig a tad deeper into
| design philosophies and patterns. Work with established designers
| who understand that spacing is not just margins/padding of a
| designated number but a rhythm across screens of varying shapes
| and sizes.
|
| For instance, understand the reasoning why a good designer will
| tell you that the typographic scale for desktops will be major-
| third, while for the smaller mobile phones, it will have to be
| minor-third.
|
| Advance topics to research and have peace with CSS are vertical
| rhythm for spacings, modular scaling for typography, and the
| Cicada Principle, etc.
|
| Here is an anecdote to illustrate the above;
|
| There was a "Careers Page" redesign for one of the biggest banks
| in the world - after about 10+ years of their old one. When I
| landed in London, they already had a "Senior front-end developer"
| mid-way into the project. I went as a replacement for one of my
| team who had a family emergency. I haven't written much code in
| years.
|
| They had engaged a brilliant designer and had a wall plastered
| with some of the most beautiful glossy print-outs. Everyone,
| including the client, loved it. Unfortunately, the struggle was
| -- the front-end output had irregular margins (pixel mismatch),
| fix another but breaks the other, etc.
|
| I saw that they had screen rulers that try to match the design
| with what comes out on the screen.
|
| I requested the designer to spend few hours explaining his
| reasoning behind the spacing and asked him the rhythms (similar
| to musical notes) that he has used, the scaling of the font
| sizes. This was when I realized the designer was brilliant, but
| the engineers would not understand or appreciate his effort.
|
| I wrote out the Sass functions and mixins and steadily replaced
| many hacked in numbers and values. Introduced Design Tokens, a
| simple style guide, etc.
|
| The website is still there and will likely last another 10+
| years. I'm also sure many of you might have stumbled on it or
| have applied to jobs with it. :-)
| lelanthran wrote:
| > Advance topics to research and have pace with CSS are
| vertical rhythm for spacings, modular scaling for typography,
| and the Cicada Principle, etc.
|
| Do you have some links? Because the first DDG result for all
| those concepts together is _your_ comment on this page.
| Brajeshwar wrote:
| I did some quick search, and found few ones. You can search
| for similar ones -- these are beaten topics and have been
| discussed, blogged, done in length.
|
| - More Meaningful Typography from List Apart,
| https://alistapart.com/article/more-meaningful-typography/
|
| - Responsive typography with Modular Scale: Create meaningful
| proportions in your design using SASS,
| https://www.bugsnag.com/blog/responsive-typography-with-
| modu...
|
| - How to Establish a Modular Typographic Scale,
| https://webdesign.tutsplus.com/articles/how-to-establish-
| a-m...
|
| - https://www.modularscale.com is a tool to define your scale
|
| - The Cicada Principle, revisited with CSS variables from an
| industry Design + Engineering guru/goddess,
| https://lea.verou.me/2020/07/the-cicada-principle-
| revisited-...
|
| - https://utopia.fyi/blog have some good articles, more
| modern and relevant to the new CSS such as Clamps.
|
| I had fun with Cicada - beautiful background patterns, which
| you yourself cannot predict. I was looking for my
| presentation on "Design with Mathematics, and Patterns" (or
| something in that line) but I think I may have lost it like
| many other open source files from before Github.
| MonaroVXR wrote:
| I want to see it, I'm just curious.
| nikhila01 wrote:
| I was curious too. Probably https://careers.jpmorgan.com
| based on his LinkedIn and the fact that he said "Careers Page
| redesign for one of the biggest banks in the world."
| panta82 wrote:
| But that's just a basic page with some stock photos...
| Donckele wrote:
| On his personal about page: https://cv.brajeshwar.com/ you
| can see it was jpmorgon for https://careers.jpmorgan.com/ If
| you do check that page and some more pages you'll note there
| are (on latest iphone) serious design issues. Ironic that its
| a career page since they definitely need some work done on
| that web design. Usually you can ignore "minor" issues but
| when its a bank such as jomorgan, a "leading" digital company
| such as razorfish and such glowing HN comments from the
| actual people involved you really have to wonder about the
| state of things.
| Brajeshwar wrote:
| True, very true. You should have been there with the
| limitations we had with an arcane CMS they inherited. Every
| front-end code was not even allowed to interact directly
| with the back-end. We wrote routines for it to be sucked
| in, chewed up and spit out. What you see is the final by-
| product of that gimmickry. I'd still say, really good work
| by the team with such restraints and limitations -- no real
| data, all mocks. And yes, I had 45 days to execute and walk
| out.
| codetrotter wrote:
| > the typographic scale for desktops will be major-third, while
| for the smaller mobile phones, it will have to be minor-third
|
| I tried to google major-third and minor-third with various
| keywords but couldn't find anything relevant. Could you expand
| on this and explain what it means?
|
| Edit: Never mind, I found some. Here:
|
| - https://medium.com/sketch-app-sources/exploring-
| responsive-t...
|
| - https://spec.fm/specifics/type-scale
|
| - https://designcode.io/typographic-scales
|
| - https://type-scale.com/
| bmuon wrote:
| This makes me very happy.
|
| As a frontend engineer who started 15 years ago, learning the box
| model required a lot of knowledge of the internals of the
| browser. The times of having to know things like quirks mode,
| abusing overflow hidden [1], how to break the behavior of float,
| etc are long gone. This is great both for us having to struggle
| less, and for the newer generations to be able to tackle harder
| problems than just layout and build cooler stuff.
|
| [1]: https://css-tricks.com/clearfix-a-lesson-in-web-
| development-...
| sodimel wrote:
| > A key way I think about building visual UI components is that
| basically everything can be broken down into a bunch of
| rectangles on a page.
|
| I created this tiny script[1] in order to be able to view all the
| rectangles that makes a website, a little while ago. Here's a
| demo[2].
|
| [1]:
| https://gist.github.com/corentinbettiol/85a8938175f89a15ac35...
|
| [2]: https://up.l3m.in/file/1597168094-tilt.webm
| hypertele-Xii wrote:
| I just add this to the CSS: * { border: dotted
| red; }
| donatzsky wrote:
| You should generally use outline instead of border for this,
| since it doesn't affect the size of the element.
| hypertele-Xii wrote:
| The screen isn't print and web pages aren't pixel perfect,
| so that's entirely irrelevant.
| chadlavi wrote:
| the only thing IE ever got right was treating box-sizing: border-
| box as the default. I work with CSS all the time and have no idea
| after all these years why anyone would want to base it on content
| size if they plan to use any padding at all.
| brundolf wrote:
| These are good concrete concepts to use as a foundation.
|
| I would add a general principle that I think is really important:
| let the layout engine do as much work for you as possible. Which
| is to say, tell it as little as possible.
|
| If you want that <div> to be narrower, you probably don't want to
| set it to a narrower `width`, you want to step back and
| understand where its current width is coming from, and determine
| how that flow can be shifted upstream to achieve the desired
| result. CSS is a language of constraints; use them to guide the
| layout like water, instead of hammering it into place like wooden
| planks.
|
| When you do the latter, that's how you end up in a quagmire of
| competing constraints where the sum behavior is impossible to
| predict, and changing that behavior is infuriating (and often
| involves `important!`s). That's the kind of situation most people
| are talking about when they say they hate CSS. For some, it's all
| they've ever known.
| madeofpalk wrote:
| > you want to step back and understand where its current width
| is coming from
|
| This touches on my key insight with CSS (and programming in
| general), in that if you have a problem with your page layout,
| that probably probably exists in the code you're already
| written, so adding _more_ code on top will only make things
| more difficult.
|
| Step back, understand exactly why the layout is acting why it
| is, and address that problem rather than just monkey patching a
| hack on top.
| blacktriangle wrote:
| The problem there is that you're now refactoring a bunch of
| code that is working on the other 99% of your pages. This
| model is great, but in CSS when doing this in order to fix
| your current problem, you are almost guarenteed to break
| other layouts elsewhere, and very very few people are using
| automated view testing to see if layouts break.
|
| I think this is the core reason why functional CSS is
| growing, because by separating out your layouts from each
| other, one can actually approach CSS refactoring this way
| without worrying about breaking other pages.
| bzzzt wrote:
| The reason lots of developers hate CSS is not because they
| ended up in a "quagmire of constraints", but in a quagmire of
| previous developer's constraint...
| themodelplumber wrote:
| A div? Narrower? Why? Oh because the text is cut off and
| scrolls sideways instead of running down the page, even though
| you can't see a horizontal scrollbar?
|
| Ah, well _that_ width is dictated by some image code at the
| bottom of the page text. The image was cropped incorrectly
| because the designer was on vacation and they had to use some
| random online crop tool during our cloud software outage. We
| fixed it with some additional markup and inline CSS, but the
| inline CSS was stripped during an upgrade to the latest inline
| HTML editor we use here.
|
| Anyway, the graphic was supposed to be a flourished section
| break that was center-aligned, and instead it is now a white
| bar that is currently even longer than the anchor text that is
| also overlapping the background imagery.
|
| If you remove the graphic, be careful because it reveals
| this...other problem, also with the CSS.
|
| You know you can scroll to the left and right really easily if
| you hold down shift?
| robin_reala wrote:
| > You know you can scroll to the left and right really easily
| if you hold down shift?
|
| On macOS, but not by default on Windows. On the other hand,
| Chrome has adopted this as default behaviour even on Windows,
| so I guess Edge has got it now too.
| extra88 wrote:
| > You know you can scroll to the left and right really easily
| if you hold down shift?
|
| _You_ can scroll left and right easily, not everyone can.
| Avoiding the need to scroll in two directions makes content
| more usable to everyone but there 's also a WCAG criterion
| about it.
|
| https://www.w3.org/WAI/WCAG21/Understanding/reflow
| burnished wrote:
| That line was tongue in cheek, I believe. Nice of you to
| share that link though.
| robertoandred wrote:
| You should be setting image widths/max-widths in CSS to avoid
| layout problems due to unknowns like intrinsic image
| dimensions.
| brundolf wrote:
| I'll link (plug) an article I wrote where I look at a case
| study that's similar to what you describe and use it to talk
| about my broader philosophy: https://css-tricks.com/css-is-
| awesome/
|
| I wrote this a good few years ago and the writing style isn't
| great looking back, but I stand by the ideas :)
| hypertele-Xii wrote:
| All the problems you just listed are everywhere else but the
| CSS.
| blacktriangle wrote:
| All the problems he listed are very real, and its important
| that a technology fit in our actual working model, not just
| some theoretical model.
|
| Take his example of the images being off thus screwing up
| your widths because you chose to inherent the image width
| as a constraint. Now imagine a very realistic scenario
| where you are reusing that style across multiple pages, and
| each page has a different image. Now you need to confirm
| this works for all existing and future possible images,
| good luck with that.
|
| Point being, isolating element styles from each other where
| possible is a big win for maintainability and reliability.
| berkes wrote:
| The problems may be real, but _blaming_ CSS for them is
| both unfair and unconstructive.
|
| You want CSS to _solve_ this problem that other tools and
| workflows introduce? `article .content img { width: auto;
| display: block; max-width: 100%; }`. This is not _the_
| solution, but one of many possible.
|
| > ... step back and understand where its current width is
| coming from, and determine how that flow can be shifted
| upstream to achieve the desired result.
|
| Step back here is seeing that large images in certain
| containers push the container out and that you want to
| avoid this.
|
| If you want CSS to avoid the problems you list, in the
| first place: that is just unconstructive: The tooling,
| holiday schedule, poor migrations, and broken upgrades
| are causing the issues, the constructive solution would
| be to fix those. And if you cannot, to look at how CSS
| can help you with them.
|
| > Now you need to confirm this works for all existing and
| future possible images, good luck with that.
|
| This is not hard at all. It is what both the C in CSS and
| classes and inheritance solve for you. `img.leader` vs
| `img.aside` vs `article p.teaser img` vs `article img`
| etceteras.
| blacktriangle wrote:
| Expecting CSS to solve people on holiday is not the
| point, but expecting a technology to protect me from the
| much more general problem of other developers and content
| generators making mistakes is something I think you can
| blame on CSS.
|
| Going back to brundolf's point, he's arguing that you
| should try and take advantage of relative constraints as
| much as possible as CSS lets you do that. I'm arguing the
| opposite, and so are you in your last line, that the
| solution is to hardcode those images and decouple the two
| components.
|
| You can say don't blame CSS as it gives you a multitude
| of options for how to deal with the situation, but the
| counterargument is that good tools lead you to a "pit of
| success" where the correct way is obvious, and CSS is
| more like a "tiny little bridge out of Moria of success"
| where you're just asking to fall to your doom.
| hypertele-Xii wrote:
| CSS is not a technology designed nor intended to protect
| you from anything. It's a technology that enables
| _professionals_ to style web pages.
|
| And it's simple enough that even amateurs can accomplish
| much.
| blacktriangle wrote:
| CSS is designed for professionals is the biggest ret-con
| I've ever heard. How much effort have developers spent
| adding basic functionality like scoping, modularity, and
| variables, features that are table stakes for any
| "professional" system? CSS was very much designed for
| amatures at the expense of professionals.
|
| Second, to call CSS simple is insane. How many ways are
| there to create a positioning root? How many ways to
| create a stacking context. How many different things can
| using '%' as a unit mean in different context? CSS is
| incredibly complex. CSS tries to shove these important
| concepts implicitly away from the developers notice, only
| to ultimately make life worse for both amatures and pros.
| kwhitefoot wrote:
| > You know you can scroll to the left and right really easily
| if you hold down shift?
|
| On a touch interface?
| codetrotter wrote:
| On a touch interface you drag sideways to scroll.
|
| That being said it's very annoying to read anything that
| needs to be scrolled sideways. So if I come across it I
| zoom out and if it's too small to read then I navigate away
| from the site.
| ofrzeta wrote:
| That's good advice. It's also a kind of zen-like approach
| (forgive me if I am not referring to it by the book). In the
| past I used to fight CSS by setting all kinds of attributes
| until it looked half-decent. Now I feel much better by cutting
| back and lettings the layout engine do its work as you said.
| Turns out to work better on mobile, too. (Ok let's forget about
| the dirty media query hacks to shift the last pixels. Move them
| to a dirty.css and enjoy your other clean stylesheets).
| [deleted]
___________________________________________________________________
(page generated 2021-07-26 23:02 UTC)