[HN Gopher] Things I wish I'd known about CSS
___________________________________________________________________
Things I wish I'd known about CSS
Author : harshamv22
Score : 680 points
Date : 2020-07-17 08:17 UTC (14 hours ago)
(HTM) web link (cssfordesigners.com)
(TXT) w3m dump (cssfordesigners.com)
| blue1 wrote:
| IIRC, _vertical_ margins collapse, horizontal margins do not
| nimrody wrote:
| That is correct (https://codepen.io/nimrody/pen/dyGgBxW)
| steve_adams_86 wrote:
| I've always thought of ch as a unit intended for monospaced fonts
| or languages with monospaced characters. Does anyone know of any
| other practical uses?
| memco wrote:
| I personally feel it's a good spacer between labels and form
| controls, icons and text and can also be useful for other
| inline-like elements that should have a natural spacing.
| Another possible use is in setting min and max widths for
| content areas where ideal line-length for comfort of reading is
| considered important.
| runarberg wrote:
| Yes. A good column width or grid card inline-sizes is between
| 30ch and 45ch, generally you don't want text to exceed 90ch.
|
| These numbers come from print design for magazine or journal
| layouts. In general the `ch` unit is perfect for defining the
| inline-size of text containers.
| ChrisMarshallNY wrote:
| That's useful.
|
| Some time ago, I wrote up a series about CSS. It's still quite
| relevant (but CSS has come quite a ways, since then).
|
| The thing I've found that is often misunderstood, is specificity.
| It's a fairly non-trivial concept:
| https://littlegreenviper.com/miscellany/stylist/introduction...
| bouncycastle wrote:
| These would be great interview questions!
|
| "So, you've been doing CSS since 1999. Please tell me how the
| width/height of a box is calculated?"
| Izkata wrote:
| Me: "In which browser?"
| bouncycastle wrote:
| Ahh, yes.. who remembers "Quirksmode"?
|
| Sadly, everything has to follow Webkit these days...
| aliswe wrote:
| A little secret opinion of mine is that I think the global usage
| of rem instead of px is a fad. The only real argument I've heard
| is that the mobile devices have their own definition of it, and
| will thus optimize in their own way, but then again I see that
| benefit as being nearly non-existant and definitely not
| demonstrated.
| interactivecode wrote:
| Most designs and typography are referenced of a basic unit, the
| body font size. Setting that size once and using rem makes it
| easier to build out and change.
| mellow2020 wrote:
| Using relative units makes it very easy to scale things. If you
| use pixels or other absolute units everywhere, you'd have to
| edit every instance of that, which can range from an annoying
| chore to being completely unfeasible.
|
| https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_...
| jFriedensreich wrote:
| strongly agree. this article sums the current state up
| perfectly: https://medium.com/hackernoon/rems-and-ems-and-why-
| you-proba...
| partyboat1586 wrote:
| I just use rem when it needs to be relative to the text size,
| px everywhere else. This way when you scale the text for
| accessibility you don't get any clipping.
| symmitchry wrote:
| When I read that section about rems and ems and ch and px it
| made me think of Python's "There should be one-- and preferably
| only one --obvious way to do it."
|
| CSS and front-end browser work drives me up the wall.
| rob74 wrote:
| It's a fad nowadays, but if you remember the bad old days when
| the "zoom" function in browsers was useless on most pages, that
| was because the browsers did it "by the book": they only zoomed
| elements with relative sizes, px units were always pixels. Then
| browser makers just gave up and reimplemented the zoom function
| to work with "broken" pages too (I think Chrome did it first
| and the rest followed suit). Of course the advent of Hi-DPI
| screens probably also played a part...
| runarberg wrote:
| The most relative units are calculated in turns of the font
| size of the root element (usually 1rem = 16px). I find it a lot
| easier to read and maintain units that are based on the font-
| size of the current element (e.g. `em`, `ex`, and `ch`). "This
| element has block margins 2 times the size of the font", as
| opposed to some magic absolute `px` or `rem`. Also if margins
| and paddings are defined relative to the font-size (e.g
| `padding: 1ex 1em;`) resizing the entire element with `font-
| size` is way more manageable.
| pansa2 wrote:
| > _If your CSS reset doesn't include this already, I'd suggest
| adding the following rule: ..._
|
| If I'm trying to build a site design from scratch (rather than
| using Bootstrap or similar), is a CSS Reset a good place to
| start? Is there one in particular that's recommended?
| themodelplumber wrote:
| It can be a very helpful start, but I'd review to make sure
| you're learning from it as well, rather than building onto
| something that could set you up for confusion later if you end
| up working without it. Here's one that's popular, lightweight,
| and helpful in my experience:
|
| https://necolas.github.io/normalize.css/
| LocalPCGuy wrote:
| I prefer a combination of reset/normalize, but because of
| that I agree with your statement re: learning from what you
| are using. Then you can make informed choices about how you
| are using those things.
| mikewhy wrote:
| Definitely review multiple, because I find normalize.css to
| be pretty useless as it doesn't set `box-sizing: border-
| box;`, or `img { max-width: 100%; }`
| earthboundkid wrote:
| Yes. There are different philosophies for how to write CSS, but
| assuming you're aiming at something like BEM (Block, Element,
| Modifier) style, it's typical to start with a reset of the raw
| elements into a standard form, and then follow that with the
| CSS for you class components, and finally some !important
| override utilities. Basically all the CSS philosophies agree
| that you should never use #id selectors at all and use of
| element selectors should be (mostly) limited to resets.
| rimliu wrote:
| Ignore all above is you are not keen to go the path of cargo-
| culting. Most of those philosophies were brought to you by
| people who were too lazy to learn CSS.
| LocalPCGuy wrote:
| Most are from very respected people to help others benefit
| from their knowledge and to avoid the pitfalls they ran
| into a various levels of scale. Do you need BEM for a
| brochure-ware site, no, styling by IDs and tags would
| probably work just fine. But a web app with 1000s of lines
| of code, while I don't specifically endorse BEM, some sort
| of pattern and methodology will save you a world of pain in
| the long run.
| chrisweekly wrote:
| If you're looking for world-class CSS knowledge, start with
| https://every-layout.dev; if you build UI for a living and
| haven't encountered axiomatic css and layout primitives, they're
| likely to change your world.
| icedchai wrote:
| Thanks for the recommendation! I'm mainly a back end developer.
| I can hack around with CSS, but have never been very good at
| it.
| Kiro wrote:
| The ; in your link sends me to about:blank#blocked.
| quietbritishjim wrote:
| For the benefit of others: https://every-layout.dev
| chrisweekly wrote:
| Thanks! Wish I'd caught it in time to fix my 1st comment.
| randompwd wrote:
| To save clicks, it's $100, just covers page layouts.
| chrisweekly wrote:
| That's a radically misleading comment. It covers much more
| than layout, and the free content on the site is incredibly
| helpful and compelling. The full version more than justifies
| its price. And they offer it for free to students or anyone
| else for whom the cost is a problem (relying on the honor
| system).
|
| It's far and away the best resource on CSS I've encountered
| in my 22-year career working with web technology for a
| living.
|
| No affiliation, just a grateful patron.
| randompwd wrote:
| not that the free thing is relevant but from https://every-
| layout.dev/blog/you-pay/ "The honour system is now closed"
|
| > That's a radically misleading comment. It covers much
| more than layout
|
| Given the site and all 3rd party reviews just mention
| layout, how is it misleading? Cant find TOC anywhere?
|
| Also, found working discount code 'BRANDEMIC' for 60% off
| in my travels should any1 bite the bullet.
|
| prev hn sub/182 comments:
| https://news.ycombinator.com/item?id=20196061
| Kiro wrote:
| > But that won't provide a great user experience, particularly
| for users who resize content at the browser level or zoom into
| content.
|
| What browsers zoom dynamically nowadays? When is this actually an
| issue?
| Kiro wrote:
| What I mean is that browsers used to zoom in a way where all
| the texts were automatically resized but nowadays the zoom
| works pixel-by-pixel, removing this issue.
| staycoolboy wrote:
| I love reading these articles because it is a win-win:
|
| 1. If I already know the tidbit, I give myself a pat on the back
|
| 2. If I don't know the tidbit, yay, I learned something.
|
| Someday I'll be 100% in the #1. What got me in this article "ch"
| size.
|
| Fact: the heigh/width calculation has changed over the years. It
| is likely this article captures the final method, let's hope so.
| JacobSeated wrote:
| Very good. I skimmed through it, since I am busy with some work.
|
| But, I still code most things by hand. I only use WYSIWYG when I
| really have to. Most often I find it faster and easier to create
| things with plain CSS.
| wruza wrote:
| Guys we need to talk. Are you capsbold serious? These are things
| that you learn in a first week of doing web development
| tutorials. I read this thread and it makes me think that I'm
| delusional because of a heat wave. Margins collapse? :focus
| exists? Me not getting a joke? I don't understand.
| stimpson_j_cat wrote:
| Yeah I thought this was going to be quirks with CSS Grid or
| something.
|
| The "CSS Zen Garden" from 1999 gets posted about every 3 months
| and makes it to the front page...
| runarberg wrote:
| I think you are point on. The two existing sibling comments
| have contradictory excuses for this:
|
| 1. _New developers might know this, but standards change fast,
| and it's hard to keep up_.
|
| 2. _You can't expect people new to the craft to know everything
| in the field_.
|
| I personally found this article sub-basic. You could probably
| learn more and better on MDN. I think CSS might be one of few
| areas on HN where a sub-par article doesn't get the
| constructive scrutiny it deserves in the top comments.
| ggregoire wrote:
| > These are things that you learn in a first week of doing web
| development tutorials.
|
| You meant CSS tutorials? Never read about "margins collapse" in
| web development tutorials.
|
| Web development tutorials I read (like 10 years ago) were
| usually about having a web server renders some data queried
| from a database into some basic HTML. And adding a form to
| create/edit rows in the database. Then perhaps adding some
| basic style like colors and paddings and some jQuery to
| validate the form. Finally moving that page from localhost to
| internet.
|
| Let's be honest, web development covers a very large area of
| knowledge and CSS is not the most interesting part (not saying
| CSS is not interesting!). I guess most people just skip the CSS
| documentation and learn it by inspecting other pages and
| copying rules, and searching "how to do X in CSS" and reading
| tutorials about their specific question.
| nanna wrote:
| I think you may be underestimating the fact that many people
| have been writing CSS for well over a decade now, and that it
| has evolved considerably since they first read a web
| development tutorial. If you've not been paying close attention
| (or not been able to), there are many things that will have
| passed you by.
|
| It's a blessing to learn css fresh today, in as much as it's a
| curse to still have practices from ten years ago still lodged
| in your memory.
| Izkata wrote:
| > and that it has evolved considerably
|
| GP is pointing out the parts that haven't changed at all, and
| are old (over two decades), simple, and common enough to be
| considered basic knowledge. I had the same reaction to those
| and one or two others.
|
| Now if this was someone relatively new to CSS I'd understand,
| but the opening paragraph establishes how long this person
| was around. Padding-vs-margin in particular was necessary
| knowledge to do good layouts back in those earlier days (less
| so now only due to flex and grid, which aren't on here).
| nanna wrote:
| > GP is pointing out the parts that haven't changed at all
|
| Doesn't read that way to me:
|
| > These are things that you learn in a first week of doing
| web development tutorials.
|
| Sure, padding vs margin isn't exactly new, however
| `display: inline-block`, ::before and ::after, rem, ch, and
| :nth-child() certainly weren't in the old html4/xhtml and
| css2 guidebook that got me into web development!
| nanna wrote:
| To add, I think another post by the same poster on this
| HN post proves the point that they're not dismissing
| individual parts, but rather disputing (or sorry but
| trolling) the article as a whole:
|
| > I think (hope, really) that gp is just one heavy "/s".
| The knowledge presented in the article is so basic that
| it is hard to believe that a person who does html for two
| years and six figures doesn't know these. As for the
| article, I fail to see any reason for it to exist beyond
| cheap media presence. Or maybe I should start a blog,
| because I'm not even halfway too.
| LocalPCGuy wrote:
| It's also good to remember that new devs make up something like
| 50% of the developer population each year (I forget the exact
| number, maybe it's every 2 years). So while this may be basic
| information to someone who's been doing this for at least a few
| years (and I'd argue it isn't, particularly since the site
| isn't aimed at Front End Devs, per se, but others who have to
| do front end development), it is valuable information for the
| target audience.
| c-smile wrote:
| I believe that focal point of CSS understanding is that horrible
| _display_ property. People just need to get that one as other
| stuff is relatively trivial.
|
| display:xxx on some elements defines three things ( sorry, that
| is terrible architectural mistake authors of CSS have made
| initially )
|
| 1. display defines "sibling requirement" how that element wants
| to be replaced among its neighbors. `div {display:inline-box}`
| tells container to treat that div a single glyph placed inline
| among other glyphs.
|
| 2. In some cases it also defines "layout manager" of element's
| content. E.g. display:table and display:inline-table tells the
| renderer that content shall be treated as table having tbody ,
| rows, cells, etc. Same thing for display:flexbox, grid, etc.
|
| 3. In some cases it defines other things like display:none;
| display:list-item; Note: there is still no display:inline-list-
| item ...
|
| Ideally we should have these instead:
|
| 1. display: inline | block; - and just these two.
|
| 2. flow: auto | text | table | vertical | horizontal | grid...; -
| defines layout manager of element's content.
|
| 3. visibility: visible | hidden | _none_ ; - Note:
| visibility:none instead of display: none;
| runarberg wrote:
| Don't forget `display: contents` in which the element is
| instructed not to generate a box at all (neither inline nor
| block; I guess like `display: none` without hiding the
| content).
|
| But I think the spec maintainers are aware of this and CSS
| Display Module 3[1] allows multi-keywords so you can do stuff
| like: display: block grid;
|
| or: display: run-in ruby;
|
| or even: display: inline flow-root list-item;
|
| 1: https://drafts.csswg.org/css-display/#the-display-properties
| c-smile wrote:
| That is not a fix - just a cosmetic change that does not
| solve anything.
|
| display/flow MUST BE [1] different properties as they define
| orthogonal concepts.
|
| We should be able to define them separately.
| main { display: block; flow:grid; } @media
| handheld and (width < 100mm) { main { flow:vertical;
| } }
|
| Yet _none_ from _display_ shall go to visibility:none (as in
| my Sciter [2]).
|
| I've seen too many times errors like this:
| main table { display:none; } main.full table {
| display:block; }
|
| Which is obviously wrong, <table> element should have
| display:table or display:inline-table;
|
| [1] https://tools.ietf.org/html/rfc2119 [2]
| https://sciter.com
| megous wrote:
| You can define those inisde/outside display styles separately,
| like `display: inline grid` or `display: block flex`
| xanathar wrote:
| Ends up to a page saying "The page you requested does not exist".
|
| ...which kinda reflects "things I wish about CSS", so 10/10.
| harshamv22 wrote:
| Its loading here. Try again :-)
| xanathar wrote:
| I know, I retried before and it worked.
|
| But "it works differently every time I try" wouldn't have
| made a good CSS joke. Oh, wait.
| zero_iq wrote:
| Page doesn't render correctly for me in Firefox/MacOS, so I had
| a similar thought... there's probably a couple of things he
| should add to his list! :D
| Wowfunhappy wrote:
| Same here (and same browser/OS), it seems like some font is
| missing?
| dzink wrote:
| 20 years ago knowing CSS's inheritance and tree traversal
| structure was critical to finish sites that worked flawlessly
| across all browsers. There was a lot of beauty in it, so much so
| that borrowed some ideas from CSS models for the architecture of
| the custom template system behind the CMS that powered CNN and a
| number of other large media sites with many sub-properties.
| leephillips wrote:
| I don't thnk the author's recommendation to include
| img { display: block; }
|
| in your reset is generally a good idea. It will break some common
| uses of images, for example to hold bits of math inline with the
| text when you are not using mathjax. If you want a displayed
| image, you should wrap it in a <figure> tag, which will give you
| a block element.
| chrismorgan wrote:
| If you wrap an image in a figure, but leave the image still
| inline, you'll probably get a few pixels of extra space at the
| bottom of the image due to line-height and vertical-align.
| People find that _really_ confusing. With how most people use
| images, I agree that `img { display: block; }` is what you want
| >99% of the time, and would rather people reverse it for the
| rare occasion when they want something else. (BTW, doesn't
| MathJax emit SVG? _Viz._ , not <img> anyway.)
| runarberg wrote:
| Something like this then: figure img {
| display: block; } figure figcaption img
| { display: inline; }
| leephillips wrote:
| I'm confused by your reply. Did your eye skip over the word
| "not" in my comment?
| chrismorgan wrote:
| Sorry, you are correct. Drop the final parenthetical, then,
| but I stand by the rest.
| leephillips wrote:
| Yes, your other point was something I hadn't thought
| about. I guess his advice would be good for some people,
| but I'm not sure about the 99%. It's not uncommon to use
| small images as text-like elements, and when you do that,
| if you have this reset, you will need to explicitly make
| them inline. Not a huge deal, but people tend to copy and
| paste their own CSS libraries between projects, and
| redefining basic default semantics of elements may create
| confusion and extra work down the line when things don't
| behave the way that any documentation you may consult
| assumes.
| chrismorgan wrote:
| I'm going to stick with the >99% figure. I think it _is_
| uncommon, rare even. Other than chat systems with custom
| emoji rendered as an img, I honestly can't think when I
| last saw a site with inline <img> tags. (I'd _guess_ it
| to be within the last month, maybe even the last week,
| but it wouldn't surprise me if it wasn't.) Twenty years
| ago, sure, but they've gone out of fashion stylistically
| as well as technically. Technically, I suspect
| background-image and icon fonts are both used more
| commonly for small iconography.
| leephillips wrote:
| It depends on what kind of sites you tend to visit, I
| guess. I see this several times per day. But I often
| visit pages with math on them. Before mathjax became
| standard, inline images was the only way to do it. And
| visit any Wikipedia page with math: they use mathML and
| have fallbacks, but the end result is, you are looking at
| inline images. Also, I often see such things as
| sparklines and similar things, also inline images. The
| >99% may be true of what you consume, but without data I
| am skeptical about the numbers.
|
| Also, some people use CMSs that substitute inline images
| for missing Unicode glyphs, and other things. If it's
| done well, you may not even notice. You don't know if the
| correct figure is 99% unless you have examined the source
| of a sample of sites.
| mikewhy wrote:
| Yep, this stood out to me too. Drives me absolutely nuts when
| an element you expect to be inline is now suddenly block.
|
| Especially because the author's reasoning is "it can cause
| confusion when trying to position them or add vertical
| margins", after just explaining that with inline-block "you can
| apply vertical margins to these".
| larrik wrote:
| > Notice how it's the odd-numbered rows with a background? Given
| our selector (p:nth-child(even)), we might expect the even-
| numbered rows to be highlighted instead.
|
| OR it counts rows from zero instead of 1, rather than all this
| about siblings...
| dhosek wrote:
| That was my thinking as well.
| [deleted]
| Brajeshwar wrote:
| Wow! This is cool.
|
| You got me at, "This was back in 1999, when we'd write things
| like <font size="4" color="#000000"> and DHTML was a thing."
|
| 'twas the time when understanding the CSS Box-model was the
| graduation opportunity to be part of the CSS-Pros.
| minikomi wrote:
| nth-child is really useful, and it's worth playing around to get
| a feel for how multipliers and offsets work:
|
| https://css-tricks.com/examples/nth-child-tester/
|
| eg. try 3n+1, 3n+2. 3n+3 and then different multipliers
| ex3ndr wrote:
| A lot of issues are simply solved by switching to flex.
| have_faith wrote:
| > block elements expand horizontally to take up a whole line
| (like a heading).
|
| Unless of course you set an input to display: block....
| runarberg wrote:
| Or anything for that matter with a non auto `width` other then
| `100%`.
| baxtr wrote:
| Side note: that's a great marketing headline!
| swyx wrote:
| for people who want to go deeper on stuff like the box model and
| specificity and selectors, i highly highly recommend Una Kravets
| and Adam Argyle's The CSS podcast https://pod.link/thecsspodcast
| - they are the two CSS devrels from google and they really break
| it down in depth while explaining things in an accessible way. no
| vested relationship, just a fan.
| jitendrac wrote:
| That is really useful.
|
| I have been writing small html front-ends since 2008-09.
| HTML5,CSS3 made many things easier like gradients, Round borders,
| and many things that now developer do takes as granted. I clearly
| remember, how boring and frustrating it was to slice borders and
| corners from photoshop psd.
|
| CSS3 and HTML5 made many good changes, but new css feature like
| grid, Flex-box all are still confusing. I have to look at the
| references every time I start new frontend work.
| dgb23 wrote:
| Have you ever taken some deliberate time to really ,,play" with
| those?
|
| My recommendation: take a calculator or spreadsheet and start
| with some simple cases and build up your knowledge in a
| exploratory manner. A few hours, a session for each feature
| (flex, grid).
|
| Its not only fun but also really helpful!
| jitendrac wrote:
| yes, I really did play with it multiple times. Its just
| sometimes I require more revisions.
| mellow2020 wrote:
| > Have you ever taken some deliberate time to really ,,play"
| with those?
|
| I know just the thing!
|
| https://flexboxfroggy.com/
|
| https://codepip.com/games/grid-garden/
| jitendrac wrote:
| Thanks, froggy was on front page of HN so I knew it for
| sure, grid garden is new one for me.
| IggleSniggle wrote:
| I felt the totally opposite about grid. I spent a little time
| learning it, and now EVERYTHING is easy (except for things that
| aren't, of course)
| jitendrac wrote:
| yes everything is easy now, except for things that aren't/
| gklefnbkon wrote:
| People really didn't know this? To be clear, I'm not criticizing
| anyone for not knowing this stuff, as nobody can be expected to
| know everything (and everyone was a beginner at one time). I'm
| just surprised that within this community, where a lot of us are
| employed to build websites, that the basics of CSS are still a
| mystery to so many of us. And I don't think that's the fault of
| any individual. But clearly our industry has a problem.
|
| Granted, if you spend most of your time on the backend, and only
| dabble in CSS a little bit, or you're new to web development,
| it's completely understandable to be fuzzy on the specifics of
| CSS. But that doesn't explain all the comments from designers and
| front end people. So what's going on?
|
| One possibility is that CSS is too difficult. Maybe? It certainly
| has it's flaws. And it was harder to use in the past. But I don't
| think there's a huge learning curve to understanding the
| difference between padding and margin, or between block and
| inline elements, is there? Don't we do that sort of thing in Word
| documents regularly?
|
| Another possibility, then, is that the mental model of a document
| doesn't match the designer's expectations. But I don't think this
| alone explains why so many of us struggle with CSS. It's true
| that many of us are trying to make applications on a platform
| meant for documents. It's also true that magazine-style page
| layouts aren't a natural fit for a Word-like model of document
| editing. But the features described in this article don't seem
| related to that discrepancy - I can't see how ignorance about nth
| child or rem units relates to the mental model of documents.
|
| Here's what I think is happening: We spend too much time building
| new tools and not enough time learning the tools we have. I've
| seen this with javascript as well. There were some recent posts
| here about vanilla javascript, and comments from React developers
| were surprised by some of the things JS could do on it's own. Now
| React has it's place of course, just like how CSS frameworks have
| their place. But I see a lot of people using these things as a
| boilerplate, instead of using them where appropriate. And thus,
| we don't take the time to learn how to do stuff with just HTML,
| CSS, and JS.
|
| And granted, I don't think everyone needs to know that, just like
| how not everyone needs to know assembly. But if not enough people
| understand what's going underneath the hood, then the default
| response to any limitation is "abstract more" and everything
| grows more and more bloated.
|
| I'm not sure how we solve this. I suspect the time pressures of
| our industries incentivize building things quickly, which leads
| to this problem. Another possibility is that the browsers take
| too long to adopt new standards, which leads people to seek out
| workarounds.
|
| Has anyone here thought about this? Any ideas on what we should
| do? I think the linked article is a good start. The explanations
| of CSS properties is very clear, and I like the examples.
| runarberg wrote:
| I think the industry has an attitude problem towards the front
| end stack. HTML and CSS is not what programmers do. Nobody
| takes the time to learn it, everybody neglects it, managers
| hand it over to their newest junior developer, project managers
| are happy as long as it looks shiny, bootcamps don't teach it
| properly, curriculums don't teach it properly. In the end we
| have a bunch of people that don't know anything about the
| craft, that accept poor craftsmanship as an industry standard.
|
| I had a conversation about this with my partner--who is a
| woodworker--this morning after reading this thread. I explained
| my perception of the status of front-end within our industry as
| such:
|
| It's as if woodworking and carpentry were synonymous. There are
| woodworkers that do cabinetry, but all of them learned
| carpentry. At most they took a single course on cabinetry, but
| that course probably used outdated methods, tools designed for
| carpentry, and the teacher them self has build a couple of
| chairs and a few tables in the past. Most of the people new to
| the field of cabinetry would come for bootcamps that last for
| maybe a month where they had to learn woodworking from scratch.
| Good furniture makers are only expected to be good at
| woodworking in general. Master carpenters are often expected to
| be able to finish--or at least manage--furniture projects at
| their job.
|
| You can imagine the sloppy craftsmanship you would see in the
| furniture building industry if that were the case. And yet, as
| tech workers, here we are.
| hellofunk wrote:
| Yikes. I've been earning 6 figures as of about two years ago
| doing mostly HTML and CSS UI design for a bank. And I still did
| not know about many of these! I guess they are things I wish _I
| 'd_ known about CSS! Better late than never I guess.
| ChrisRR wrote:
| Six figures? In the US?
|
| Sometimes I wonder why companies even pay developers so much in
| the US. I'm a specialised medical embedded software developer
| in the UK and I'm not even halfway to six figures, and will
| likely never hit it.
|
| It astounds me that companies don't hire twice as many non-US
| developers for the same price and get more work for their
| money. Note, I'm not talking about outsourcing to the absolute
| cheapest bottom of the barrel developers who cost 1/20 of the
| price and the quality reflects the price. Just equally skilled
| developers in non-US countries.
| pjc50 wrote:
| > Sometimes I wonder why companies even pay developers so
| much in the US.
|
| Presenteeism.
|
| The office "has to" be in Silicon Valley. The employees "have
| to" be in that office, in an open plan, so the manager can
| physically see them working. Therefore they have to be paid
| huge wages to compete against the other employers doing the
| same.
| amINeolib wrote:
| Maybe it's a stereotype, but my Engineering counterparts in
| Europe were apathetic/lazy.
|
| Might have been a few bad Apples.
| AdrianB1 wrote:
| When they are taxed to death on lower base wager, it is
| expected some to be apathetic. The saying is "they
| pretend to pay us, we pretend to work".
| bgroat wrote:
| Serious questions.
|
| Which countries would you suggest for this?
|
| Just the UK?
| benhurmarcel wrote:
| The only European countries where costs are as high as the
| US for tech salaries are basically Switzerland and Norway.
| In the rest of Europe you have access to a very qualified
| workforce for less money. But they also have more
| protection than in the US (fewer unpaid hours, more
| holidays, no cheap dismissal...).
| jfkebwjsbx wrote:
| All Europe?
| runawaybottle wrote:
| There is probably more to the story here. If you're only at
| about 50k, you're making $24 an hour. There's even cheaper
| labor than you. It's going to be a disgusting race to the
| bottom if we start paying everyone 20, 18, 15 ... dollars an
| hour.
|
| At this point in my life you would have to pay me around six
| figures for me to do CSS seriously on a daily basis (and it's
| likely I'll still burn out and leave). The cross browser and
| device testing alone is so tedious and stress inducing that I
| simply won't do the job below a certain price point (or I
| will out of desperation but definitely will bounce ASAP). The
| unsaid thing about doing heavy CSS work is that it doubles as
| a QA job from all the testing required.
|
| And again, I'm someone that's good at it. You can't pay me
| enough to do it, not if I have choices.
| ChrisRR wrote:
| If you think CSS is tedious, then you've never dealt with
| medical device regulations. cross browser testing will seem
| like an absolute breeze. If a UK employer were paying PS90k
| for CSS, absolutely everybody and their dog would be
| applying for a job that pays double a typical dev salary.
|
| I think we've already experienced the race to the bottom
| and come out the other side, with $24 being fairly average
| for the world and the US being on the high side. This all
| happened years bacj when companies started outsourcing
| development and IT to India at rock bottom prices, but then
| received a lot of low-quality work (you get what you pay
| for). I believe India has a much different approach to
| software quality than many other countries.
|
| It's taken many companies years to realise that mistake,
| but I wouldn't call $24 a race to the bottom for skilled
| labour as that will land you comfortably above average
| income in the UK
| runawaybottle wrote:
| Should we go lower than 24 dollars? Sincere question.
|
| If not, never ever show bitterness for your fellowship
| that brought honor to the profession, wherever they are.
|
| I hope never to see developers disrespected that way,
| anywhere in the world.
| lucozade wrote:
| I think the important bit of info is that they work for a
| bank, not that they write CSS.
|
| If I look at the equivalent compensation for people who work
| for me, the vast majority of developers in the UK and US earn
| > $100k. Like for like the US employees earn more but that's
| almost wholly swallowed up in other costs (basically
| healthcare and our US healthcare plan isn't particularly
| bad).
|
| And the FAANGs and hedge funds, in my experience, have a
| reasonably similar dynamic.
|
| The simple fact is that we generally don't hire for PL
| knowledge except in very specific circumstances (KDB for
| example). If all we wanted was a coder, there are much more
| cost effective options than hiring someone, regardless of
| location.
| [deleted]
| christophilus wrote:
| That is going to happen. Big corporations are finally waking
| up to 1st class remote work, and that's the gateway to lower
| US wages. I say this as a remote worker, and a huge fan of
| remote work. But I do think the high US salaries are going to
| mean revert a bit.
| nanna wrote:
| Sounds to me like tech workers in the US should join a
| union, and quick!
| indigochill wrote:
| Now, admittedly I'm a skeptic of unions by default (in my
| view they're mostly just another layer of
| bureaucracy/waste), but isn't unionization of tech
| workers in the US the quickest way to make themselves
| even less desirable?
|
| Why hire a US union member when you can hire an Eastern
| European who both works for peanuts and doesn't have
| union hang-ups? (Admittedly outsourcing has its own
| problems, especially when there are language/cultural
| barriers)
| wirespot wrote:
| EU has very strong employee rights, so that will come to
| the same point as a union in the US. The lower pay is an
| advantage but the time zone difference of 8-12 hours can
| be a disadvantage. There are no language barriers in IT
| between the US and Europe, by the time they graduate
| college the average European has gone through more than a
| decade of English courses. Cultural differences are
| minor, management style is very similar (in the East) and
| so is the communication culture.
|
| So yes, lots of American companies already outsource to
| East Europe. There are lots of "Silicon Valley"s across
| EE thriving on Western outsourcing from companies who
| aren't quite desperate or cheap enough to go to India.
| cosmodisk wrote:
| There are some phenomenal outsourced shops in EE. Those
| that do pay 2-4 higher the going rate in the country.
| These aren't wordpress sweatshops. These are usually
| small teams and people work on interesting,specialised
| projects. Management style is usually very pragmatic ( a
| means a and let's cut the crap) .But the best part about
| these is that people do get exposed to things,build
| experience and eventually start on their own. 10-15 years
| ago there was hardly any product driven company in my
| country.Now the ones most worth working for do have
| successful software product that are sold in western
| markets.
| speedgoose wrote:
| The US salaries in IT are huge, but you need to take into
| account that they have to pay a lot to have a quality of life
| comparable to what a minimum wage worker is getting in west
| Europe.
|
| If you have a few kids, I would bet you are not that bad in
| UK with one fewer digit.
| amINeolib wrote:
| In the United States, you can spend 6k on health insurance
| and 12k out of pocket for unlimited family health care.
|
| So as long as a US job pays 18k more, it's pretty similar.
|
| People talk about vacation, but my job pays so much I'll
| take months off between contracts. (Engineering)
|
| Also it's hard to compare lifestyles in the US vs Europe.
| Homes in the US are gigantic, often newish, and have Air
| Conditioning. Cars in the United States are more feature
| rich and have higher safety standards (when I was an airbag
| engineer in 2015)
| speedgoose wrote:
| I'm sure in terms of money, working in the US as an IT
| person is a good deal.
|
| But you have to think not only about you but also the
| others. I don't know whether you have children or
| grandchildren , but if you do I'm sure knowing that they
| will never have a bad situation is pretty nice. You can't
| expect all your children and grandchildren to have a well
| paid job and you can't finance all of them forever.
| AdrianB1 wrote:
| Workforce mobility means people can always move for a
| system that makes more sense for them. If grandpa was a
| good IT engineer and made some nice money in US, but the
| grandchild is the village idiot then moving to Germany or
| France is a solution. Germany has an open door policy to
| foreigners (there are millions of Turkish descendants of
| "guest workers" invited after WW2 for reconstruction),
| East Europeans and now "refugees" from all over Middle
| East and Africa. No idea how immigration works in France,
| but there are huge Magrebian communities and lots of
| other foreigners as well, so I think it is doable.
| speedgoose wrote:
| Well if your child can't make it in USA, s*he will not
| make it in Europe either. You can't just land in France
| and become a citizen without a job.
|
| But do you want your child to immigrate because you live
| in a country of selfish people? I'm sure you would find
| the situation difficult.
|
| By the way, the communities you are mentioning in France
| are French since a few generations and not foreigners.
| AdrianB1 wrote:
| One can live in Western Europe on welfare. Most of my
| colleagues in France are not born in France, they are
| foreigners. The trend is growing in Germany too, in our
| department there is no German in Germany but people from
| Brazil, India or Eastern Europe.
| pantaloony wrote:
| > In the United States, you can spend 6k on health
| insurance and 12k out of pocket for unlimited family
| health care.
|
| Where? How? I... this total is about what I'm seeing for
| shit-tier covers-nothing insurance. Like, there are plans
| out there that are HCA non-conforming and not _that_ far
| under $18k /year just for the premiums. Who do I talk to
| to get total max healthcare spending of $18,000 without
| an employer-provided plan, in the US? Who's offering
| $12,000 annual max-out-of-pocket family plans for $500/m?
| kube-system wrote:
| Just ran some rates in my area for an EPO with reasonable
| copays and zero co-insurance:
|
| $3,600/yr individual, $0 deductible, 8k OOPL
|
| $9,600/yr self + spouse + kid, $0 deductible, 16K OOPL
|
| $12,000/yr self + spouse + 2 kids, $0 deductible, 16K
| OOPL
|
| Although I don't really think it makes sense to compare
| costs based on OOPLs. For most people, the deductibles,
| coinsurance, and copays are much more relevant to actual
| costs.
| rusticpenn wrote:
| Yes, This is the main difference. In Germany the education
| is free and medical insurance not something to worry about
| ( I have no idea about what deductables, deletables etc
| mean). This is where the difference lies.
| wirespot wrote:
| As simple rule of thumb an employer in the EU has to pay
| roughly double the net salary amount, so on top of the
| salary pocketed by the employee yet another similar
| amount goes to taxes. The education/insurance aren't
| "free", they're just managed better and give more direct
| benefits to the taxpayer.
| rusticpenn wrote:
| It depends. When I was a student, I did not have to spend
| a penny on medical biils, my wife got paid by the
| government for some courses (+ cost of rent etc) that
| would have costed us around 20K EUR at that time. Now
| that we are earning enough, I have no problem in paying
| back, so that others who need it will be also be able to
| achieve their dreams.
| sushshshsh wrote:
| Deductable is a scary word but a simple concept, it
| represents the amount of money you must pay before your
| insurance begins to pay bills for you :)
| rusticpenn wrote:
| That is scary. When my child had to stay in the hospital
| for a month, the main costs for me were the parking
| tickets.
| ChrisRR wrote:
| I know the difference to the cost of living in the US in
| silicon valley, of course not everyone lives in areas like
| that.
|
| But I'm talking from the employer side, not the employee
| and why they would employ US devs who cost twice as much
| swebs wrote:
| The employer pays roughly the same amount. It's just that
| the employee sees much less in Europe due to all the
| taxes.
| mroset wrote:
| For context: I'm an American who's currently working as a
| software engineer in France (for a French company).
|
| I agree that engineering salaries are much higher in the US
| than in Europe and other non-US countries, however it's worth
| considering that there are additional expenses to hiring in
| other countries. My french salary is ~30-40% lower than I was
| making in the US. However, my cost to my employer is nearly
| as high. Employer taxes are much higher, my company is
| required to reimburse my transit and all-but-obligated to
| cover lunch as well. Certainly, many US software companies do
| some/all of that, but not all.
|
| And beyond those pure costs, there are more liabilities to
| the employer. For instance, if they want to fire me, they're
| legally on the hook for four months of severance. And, I get
| ~7 weeks of combined vacation time and "comp time" (based on
| the fact that I work more than 35 hours a week). In the US, I
| got 2-3 weeks.
|
| I don't have exact numbers, and I don't disagree that there
| are potentially savings to be had, but I don't think it's
| nearly as clear cut that you could get anything close to
| twice as many developers.
| benhurmarcel wrote:
| Here is an official simulator for France: https://mon-
| entreprise.fr/simulateurs/salaire-brut-net
|
| It's not 100% accurate (the exact amounts depend on many
| variables) but gives a good idea. For example, a cost to
| the employer of USD 100k (87460EUR/year) gives a before-
| taxes salary of USD 70.5k, and a salary after all taxes of
| USD 47k.
| [deleted]
| dahfizz wrote:
| > before-taxes salary of USD 70.5k, and a salary after
| all taxes of USD 47k.
|
| What!? That's over 30% of your income gone, and for a
| relatively average income. That's not even counting VAT
| and other taxes.... No wonder there's so much "free"
| stuff in Europe.
| pantaloony wrote:
| Notably, I doubt you could get family healthcare coverage
| in the US that reduced your financial risk as much as
| France's does for under $25,000/yr. Even at that rate I
| bet your exposure's still worse.
| dahfizz wrote:
| > I doubt you could get family healthcare coverage in the
| US that reduced your financial risk as much as France's
| does for under $25,000/yr.
|
| I'm not so sure. It looks like the average liability for
| a family (12 monthly premiums plus deductable) comes in
| at just under $23k[1]. That's the max the average family
| would pay. Obviously for just a single person total
| liability is a lot lower.
|
| So for a person like me who makes good money being an
| engineer, I am still better off in America where I can
| make a lot of money but also pay a little more in COL /
| healthcare stuff.
|
| [1]
| https://www.ehealthinsurance.com/resources/individual-
| and-fa...
| pantaloony wrote:
| Wow, that's... much cheaper than I've seen. In my non-
| coastal middling-wealth state, you're looking at $1500/m
| for an HSA family plan that still leaves you with tens of
| thousands in risk per year, and reducing that risk gets
| expensive fast (often it's even worse, and you end up
| _guaranteed_ to pay more per year than you _might_ pay if
| something goes wrong under one of the cheaper plans)
| balfirevic wrote:
| For fun, here are the figures for Croatia (yearly take-
| home salary and total cost for employer, all in USD for
| easier comparison):
|
| Average salary (take-home): $11874
|
| Average salary (total cost for employer): $19875
|
| Median salary (take-home): $10225
|
| Median salary (total cost for employer): $16526
|
| Starting junior dev salary (take-home): $14800
|
| Starting junior dev salary (total cost for employer):
| $25800
|
| Senior dev salary (they can go higher, but that's
| relatively rare for local employers) (take-home): $27700
|
| Senior dev salary (total cost for employer): $52000
|
| VAT is 25%. Safety net is a joke. Health care is
| universal, but not that good. Education is mediocre at
| best.
| benhurmarcel wrote:
| EUR61k before taxes isn't really a relatively average
| income in France. A junior engineer (with a Masters)
| starts around EUR35k ($40k) before-taxes. Country-wide
| median salary is EUR28k ($32k). But across all those
| salaries it doesn't change the fact that around 45~55% of
| the employer's cost isn't going to the employee.
|
| And yes, taxes and cotisations are very high. On the
| other hand they cover most higher costs and risks in life
| (education, health, basic retirement...).
| dahfizz wrote:
| Isn't $70.5k USD around EUR61k EUR?
| benhurmarcel wrote:
| You're right, I mixed up. I edit it.
|
| Still, EUR61k isn't an average salary. An engineer
| reaches that after about 10-15 years (from personal
| experience and some statistics I have access to). It's
| double the national median.
| dahfizz wrote:
| Wow, that's just crazy to me. It makes sense with the
| much stronger safety net, it's just a shock.
|
| How does rent and food costs compare to America, do you
| know?
| benhurmarcel wrote:
| Even with the stronger safety net, it doesn't make up for
| the difference compared to the US for well-paid employees
| (such as engineers, or tech in general). US employees are
| much more well-off, there's no denying that. US levels
| for engineers compare more to Swiss level of living.
|
| However the safety net is much more beneficial for less-
| paid people, at a relatively low cost for them.
|
| I only visited the US so others might be able to provide
| a more detailed comparison. It seems to me that rent is
| generally significantly higher in US cities (might be
| different in lower CoL areas), and groceries and other
| smaller budgets were slightly higher in France
| (restaurants, tech purchases, cars...).
| codpiece wrote:
| I have worked in the US and Europe, and may give a direct
| comparison.
|
| US healthcare and education consume a vast portion of
| your pay. We paid cash for our daughter's college
| (biomedical engineering) at a total of over $300K. That
| buys her freedom of choice when it comes time to take a
| job, get an advanced degree, etc. Her colleagues will
| have more than $500K USD debt hanging over their heads
| when you factor interest payments.
|
| The company pays for a portion of health insurance, but
| much of the cost is picked up by the employee, either
| though co-payments or deductibles.
|
| We live modestly, drive low-end cars and don't dine out
| often. We see our European friends taking great vacations
| and their children bounce in and out of college programs.
| We see free healthcare, mountain cottages, and other
| perks unavailable to us.
| cosmodisk wrote:
| Without going into numbers all I can say about US vs
| Europe: for people with low income,Europe is much much
| better. For middle class, it boils down to some difficult
| choices( kids, education, leisure) and is probably equal.
| While upper middle class or highly paid professionals
| have it better in the US.
| LandR wrote:
| I'm in Scotland, my salary is about PS45-PS48k. I take
| home about PS31k.
|
| The median salary here is about PS21k nationwide.
|
| I bought my home for PS170k, now worth about PS230k. it's
| a decent sized apartment in a nice area in the city where
| I work. For an indication of size, my living room is
| about 23ft by 28ft, 2 bedrooms, 2 bathrooms.
|
| Some photos to show what I got for my money:
|
| https://imgur.com/gallery/6oNLRtl
|
| My outgoings each month average out to around PS1200k.
| Mortgage is under PS450 a month.
|
| Healthcare is all free, university is free, prescriptions
| are free.
| balfirevic wrote:
| Did you have a large down payment? That looks like a
| small monthly cost for such mortgage. Or maybe the
| interest on such loan in Scotland is very small.
| LandR wrote:
| My down payment was PS70k, interest rate is 2.14%
|
| When I renew at end of year it shoul be around 1.1%
| balfirevic wrote:
| Well damn, I don't think there is anything below 3.00%
| (3.50% more common) where I live.
|
| That's nominal - 3.5% - 4.0% is the effective interest
| rate. I don't know much about mortgages, so not sure if
| I'm missing something. Congrats on your place - it looks
| great!
| Tade0 wrote:
| _Sometimes I wonder why companies even pay developers so much
| in the US._
|
| It boils down to real estate prices combined with some
| companies really really really wanting those people to be on
| site.
|
| I had my highest rate ever during a brief, beautiful moment
| in Switzerland where a studio apartment costs ~$2000 per
| month.
|
| I choose to think that this rate is how much our work is
| actually worth - otherwise those companies couldn't afford
| having people on site.
| AdrianB1 wrote:
| This is a catch 22, high wages make the rent increase
| (demand and offer) and high rents demand high salaries,
| it's a spiral going to a bubble.
| Tade0 wrote:
| Indeed, but eventually a ceiling is reached over which it
| would be impossible to make a profit having on-site
| employees.
|
| I don't envy the locals though. I spent 2,5 months in
| Zurich, during which I saved so much that in pre-corona
| times it would be enough for the minimal allowed down
| payment for an apartment.
|
| The Swiss don't have a Switzerland of Switzerland where
| they could pull off the same trick.
| rrrrrrrrrrrryan wrote:
| Housing supply is the variable that can act as a release
| valve. If cities don't want to expand vertically, that's
| fine, but they'll inevitably end up in a Bay Area type
| rent spiral.
|
| I think the real issue is that homeowners vote so much
| more frequently than renters (who would love to have more
| housing and lower rents), even though they're technically
| outnumbered.
| wruza wrote:
| I think (hope, really) that gp is just one heavy "/s". The
| knowledge presented in the article is so basic that it is
| hard to believe that a person who does html for two years and
| six figures doesn't know these. As for the article, I fail to
| see any reason for it to exist beyond cheap media presence.
| Or maybe I should start a blog, because I'm not even halfway
| too.
| porker wrote:
| I've done CSS since 1999, none of this was new to me, and I've
| never earned 6 figures for doing HTML and CSS. I moved my
| career away from HTML/CSS in order to earn more.
| davidmurdoch wrote:
| Same here (but started in 2000), except I didn't know about
| the ch unit. OP likely has some great soft skills and
| negotiation prowess.
| towb wrote:
| I think we picked up a lot more of the basics back in the
| days because doing CSS was much less forgiving than it is
| now. And the whole struggle with pixel perfect between
| browsers just forced you to spend hours on these tiny things.
| rimliu wrote:
| I was also waaay more limited. All those clever hacks to
| get equal height columns, "sliding doors", workarounds for
| IE5/6/7...
| towb wrote:
| Yep, for sure! It was a fun ride but I'm happy it's over,
| though I don't enjoy CSS the same these days. Could be
| age and all that, who knows.
| miiiiiike wrote:
| I've never been happy with a front-end dev that I've paid six-
| figures to.
|
| I once paid a senior front-end engineer far too much to do a
| fairly involved layout. Three months, an uncountable number of
| bugs, and one unusable tangle of Sass later I pulled the plug
| and swore off ever hiring a "CSS Person" again.
|
| I took the Linus+Git approach and said "I'm not writing another
| line of Python until I understand CSS." After a few weeks of
| study (I read CSS: The Definitive Guide cover-to-cover) I was
| able to implement the layout in, and I'm not exaggerating, two
| hours. No bugs, responsive, cross browser support, etc. Flat
| out done.
|
| I went back to the dev and asked why they tried to implement it
| with over a thousand lines of Sass using Flexbox over a few
| lines with CSS Grid.
|
| It went like this:
|
| Me: "Hey, why did you choose Flexbox over CSS Grid for feature
| XYZ?"
|
| Senior Front-End Dev (SFED): "I used a grid. Bootstrap's grid."
|
| Me: "No, _CSS Grid_ "
|
| SFED: "Like the 'display: grid' thing? I don't know how that
| works."
|
| I've never met a CSS Person who has read a book on CSS. Or one
| that can do the arithmetic on a simple flex-grow/flex-
| shrink/flex-basis combo.. Even with a cheat sheet.
|
| I'm a back-end dev, I used to think that CSS was "garbage".
| After learning the ins and outs I think it's a pretty
| remarkable set of technologies. A true discipline. But, it's
| hard to find someone who really understands it because it sits
| at a weird level in the tech stack. Most developers feel it's
| beneath them or that they "have the gist of it" and most CSS
| specialists don't have a firm grip on it or keep up with
| browser developments.
|
| If you're going to work with, hire, or exist as a "CSS Person"
| within 6-feet of me I'm going to require you to read "CSS: The
| Definitive Guide" before I give your laptop charger back to
| you.
|
| This article is good, but it's barely the bare minimum that you
| need to know about not knowing CSS.
|
| Six-figures for a "CSS Person" who's read CSS:TDG is completely
| worth it.
|
| CSS and Sass are both worth mastering.
|
| For CSS read: "CSS: The Definitive Guide"
| (https://www.amazon.com/CSS-Definitive-Guide-Visual-
| Presentat...)
|
| For Sass read: "Pragmatic Guide to Sass 3"
| (https://www.amazon.com/Pragmatic-Guide-Sass-Modern-
| Style/dp/...)
| PetahNZ wrote:
| But when was this? CSS grid has only really been viable for a
| few years in terms of significant browser support.
| miiiiiike wrote:
| Last year. Around November and 91% unprefixed usage
| (https://caniuse.com/#search=display%3Agrid)
| bigmanwalter wrote:
| CSS Grid has only been widely supported for a couple
| years now. Not so hard to believe a frontend dev was
| still using bootstrap grid.
| epicureanideal wrote:
| I agree. It's fairly common for experienced front end
| devs who have been bitten by browser incompatibilities in
| the past to wait several years to adopt the latest CSS
| techniques. The "old techniques" often work very well.
|
| Most likely if you had asked me "why flexbox and not CSS
| grid" I would have said "because flexbox is able to
| perfectly well support this use case, and I'd rather not
| introduce a dependency on a less well supported CSS
| feature unless I need to".
|
| I personally tend to prefer using the oldest (within
| reason) CSS feature that lets me accomplish a task. Or
| I'll pick the one that best conceptually maps to the task
| I'm trying to accomplish, if there's a significant
| difference.
| tr1coder wrote:
| The inexcusable fact here is that he said that he didn't
| know how it works. A font-end developer not knowing grid
| is not worth 6 figures.
| epicureanideal wrote:
| I disagree, as both an engineer and a manager.
|
| CSS grid is only recently becoming a reasonable tool to
| use in practice. I don't think any of the top 1% of front
| end engineers I know would be able to use CSS grid
| without looking at the documentation.
|
| Based on experience, the kind of person who would be able
| to use it from memory either 1) is very skilled AND had a
| reason to use it recently, or 2) someone of medium skill
| who just recently read the spec but in almost all other
| ways is less skilled than the people I mentioned in the
| first paragraph.
| ibdf wrote:
| Too bad you had a bad experience with your dev, but
| seriously, you just picked up css, people have been
| fighting it for years because of browser support. There's
| a reason why there are css reset stylesheets, and
| frameworks out there. If you are using it in one project
| great, but when you do it for living you will ended up
| building your own framework if you are not already using
| one. SASS also saves you so much time in development.
| epicureanideal wrote:
| Yes, one of the issues with people who've recently
| learned the 2020 version of JS/CSS/frameworkX is that
| they assume what they've learned is the correct way to do
| things according to "the best, latest standard". It's a
| variation of Dunning-Kruger almost.
|
| As you said, experienced engineers have been dealing with
| CSS browser support issues for years, so as a habit try
| to avoid using the latest shiny new features.
|
| Also, experienced engineers do refresh their knowledge
| from time to time, but you might have caught them between
| refreshes. Remember that these engineers are also working
| 40-60 hours per week producing work output in addition to
| periodically refreshing their skillset. And depending on
| the environment they've worked in previously they may not
| have had the ability to use the latest features of
| whatever technology. Maybe they were working on a legacy
| app that didn't support ES6, for example. That would be
| less common now in the days of Babel, but there was a
| time a few years ago when it would have been reasonable
| for a working JS engineer not to be familiar with every
| detail of ES6, as an example.
| LocalPCGuy wrote:
| Front end development is a craft, just like other crafts.
| People need to treat it seriously if they expect to be taken
| seriously and be paid accordingly. (BTW, if you still haven't
| met a FE dev who's ever read a book on CSS, you have now. I
| own quite a few AND have read them.)
|
| I also think a lot of the value from a front end developer
| comes from their ability to merge the technical requirements
| with a designer's vision, and produce a product that is at
| the same time usable, accessible and (bare minimum) meets the
| technical requirements.
|
| Not going to touch the CSS Grid except for two quick
| comments:
|
| - they absolutely should have been keeping up with CSS Grid,
| where it was at, and when it was usable and when it isn't
|
| - it is still an open question, because although the overall
| numbers should 90+% available in browsers, you have to check
| your own stats. For example, the stuff I work on is often
| used in Enterprise environments, so IE11 is a requirement
| (yes, we know our numbers, it is, it could literally cost us
| 6 figure sales if we don't have support for it). We are using
| CSS Grid, but we have to be very careful what we use it for
| and to test those uses in IE to make sure the old Grid spec
| in IE supports the things we do it with. Otherwise it's back
| to Flex or other layout techniques. It's not a silver bullet,
| but I also recognize that is becoming a more unique example
| these days.
|
| Those are the kinds of things a good FE dev should know
| though, IMO, and be able to articulate.
|
| Plus, FE devs also need to know HTML and semantics,
| accessibility, and of course, Javascript. When you can put
| that all together along with the skills earlier re: usability
| and accessibility, then you can justify the higher salary
| brackets.
| commandlinefan wrote:
| > I've never met a CSS Person who has read a book on CSS
|
| I'm not a CSS person, but I've read three (including CSSTDG)
| and I still can't do anything useful with CSS.
| miiiiiike wrote:
| Ha!
| bobmaxup wrote:
| I too have worked with many front-end developers that were
| book and spec averse who preferred to gather lore from
| various gurus in three paragraph blurbs.
| [deleted]
| egfx wrote:
| You seem to be trivializing css as something static you just
| have to deal with. This maybe true for 99% of websites but
| css has had more innovation in the last few years than
| anything else. And much of it hasn't reached textbooks. For
| example css3 functions and now being able to mix these new
| techniques in undiscovered ways. CSS requires a very nimble
| and creative mindset. That maybe why backend devs usually are
| very dismissive of it. By the way I became a frontend
| developer after I spent many years as a backend dev. My
| background is in Php and Perl.
| IggleSniggle wrote:
| Have you _looked_ at Definitive CSS? It 's up to date and a
| massive 1000 page tomb of encyclopedic knowledge and
| guidance. Anyone who digests that entire thing is not being
| dismissive of CSS.
|
| Digesting that is taking CSS more seriously than most
| people take learning new programming languages...which is
| appropriate! Because with CSS, you not only need to learn
| the language, you are effectively learning something like a
| language and a framework at the same time. Lots of folks
| learn the language minimally, piecemeal, on an "as needed
| basis," and end up wasting a lot of time because they
| aren't aware of the larger features and how they can be fit
| together.
|
| Most folks do the equivalent of learning about goto
| statements, variable declarations, and arithmetic
| operators, and figuring you have everything you need to do
| good programming work.
|
| Technically, you do have everything you need. And with a
| decade of work under your belt using those things, you can
| build some amazing and good robust systems. It's also easy
| to build total junk that nobody can understand but you.
| Perl, of course, is also infamous for having this quality.
| egfx wrote:
| > Technically, you do have everything you need. And with
| a decade of work under your belt using those things, you
| can build some amazing and good robust systems. It's also
| easy to build total junk that nobody can understand but
| you.
|
| This is what's beautiful about the frontend. It's "magic"
| and underneath in code speak it may be ugly but the work
| speaks for itself. Arguably that is only if you own it
| and maintain it.
|
| > Lots of folks learn the language minimally, piecemeal,
| on an "as needed basis," and end up wasting a lot of time
| because they aren't aware of the larger features and how
| they can be fit together.
|
| The way I see it, learning about all the ingredients in a
| recipe will not teach you how to cook. In css techniques
| are unearthed by a small handful of css artisans and it's
| not about learning css itself in 99% of the cases. It's
| about digging and finding the best ideas on GitHub, stack
| and codepen. And hacker news.
| IggleSniggle wrote:
| Or, you know, using a well vetted, well organized
| resource that has already done all the digging and
| collating of techniques and organized into a well
| structured Definitive Guide.
| megous wrote:
| > Have you looked at Definitive CSS? It's up to date ...
|
| Not really, it doesn't talk about custom properties,
| inline svg, how to style them, etc. All very useful these
| days, if you want to allow color theming for your web app
| and not use hacks like custom fonts for icons...
|
| And custom properties are around since 2014 at the very
| least.
| dahfizz wrote:
| I think this is a culture problem in fornt end dev in
| general. Front end devs learn frameworks, not technologies.
| It's very much focused on getting started as quick as
| possible instead of taking the time to read and understand
| the tech they are working with. Even though, as your story
| shows, you can get things done quicker when you know what's
| going on.
| nefitty wrote:
| This might be one of the most helpful book recommendations
| I've ever read.
| miiiiiike wrote:
| Thanks. If you'd like some more book and video suggestions
| I sent this to a friend back when she was looking to get
| into front-end development a few months ago:
|
| Here are some book and video links (with Amazon affiliate
| tags snuck in). I've read all of these books cover-to-cover
| save for the RxJS one. They approach front-end as a set of
| technologies that should be understood and mastered rather
| than the "CsS hAckS to GET YoU pAiD!" style of most web
| tutorials.
|
| Not sure where to point you with React but if you decide to
| use Angular or Vue I have some suggestions.
|
| CSS/Sass:
|
| "CSS: The Definitive Guide": https://www.amazon.com/CSS-
| Definitive-Guide-Visual-Presentat...
|
| "Pragmatic Guide to Sass 3: Tame the Modern Style Sheet":
| https://www.amazon.com/Pragmatic-Guide-Sass-Modern-
| Style/dp/...
|
| This Sass book has the best structure of any introductory
| tech book I've ever read.
|
| "TypeScript":
|
| Mastering TypeScript 3: https://www.amazon.com/Mastering-
| TypeScript-enterprise-ready...
|
| "Programming TypeScript":
| https://www.amazon.com/Programming-TypeScript-Making-
| JavaScr...
|
| RxJS: Reactive programming the most significant development
| in UI technology in 20 years. Once you get the hang of it
| managing asynchronous events (user generated, network
| generated, time based, etc) become a breeze.
|
| "Build Reactive Websites with RxJS: Master Observables and
| Wrangle Events": https://www.amazon.com/Build-Reactive-
| Websites-RxJS-Observab...
|
| RxMarbles - Interactive RxJS visulizations:
| https://rxmarbles.com/
|
| Angular:
|
| "Angular Development with TypeScript":
| https://www.amazon.com/Angular-Development-Typescript-
| Yakov-...
|
| "Architecting Angular Applications with Redux, RxJS, and
| NgRx: Learn to build Redux style high-performing
| applications with Angular 6":
| https://www.amazon.com/Architecting-Angular-Applications-
| Red...
|
| Videos:
|
| I watched most of the Layout Land videos when I was getting
| a grip on the state of CSS. Jen Simmons is a developer
| advocate at Mozilla and has the best overviews I've seen.
|
| Basics of CSS Grid: The Big Picture:
| https://www.youtube.com/watch?v=FEnRpy9Xfes
|
| Using Flexbox + CSS Grid Together: Easy Gallery Layout:
| https://www.youtube.com/watch?v=dQHtT47eH0M
| divan wrote:
| - One of the biggest traps for smart engineers is optimizing a
| thing that shouldn't exist.
|
| (c) Elon Musk, speaking about CSS (maybe)
| amanzi wrote:
| This is great! I've been hacking away at CSS for years and
| learned heaps from this. Also, reminded me to look up the
| differences between `rem` and `em`, which I've been meaning to do
| for ages!
|
| https://j.eremy.net/confused-about-rem-and-em/
| techbubble wrote:
| This was a great article and I learned a few new tricks.
|
| I learned CSS over the years by gradually solving problems I
| encountered building apps. Compare this to people learning CSS
| now as evidenced by the #100DaysOfCode tag on Twitter. The
| learning technique is comprised primarily of using gradient-
| heavy, absolutely positioned HTML elements to create a photo-
| realistic, 3D rendering of objects.
|
| The results are pretty amazing, but I have my doubts about
| whether these skills are easily translatable for building an
| interactive, responsive UI. Some examples:
|
| https://twitter.com/bauervadim/status/1282264611912327169
|
| https://twitter.com/mercyoncode/status/1282449080132804609
|
| https://twitter.com/ellie_html/status/1276177277315932161
|
| https://twitter.com/thecoffeejesus/status/128204582508278169...
|
| https://twitter.com/alyd789/status/1271200537988431873
| umaar wrote:
| I learnt CSS in a similar way. I'd take Photoshop designs and
| try to recreate them in vanilla HTML + CSS:
|
| https://jsfiddle.net/umaar/YNA5V/
|
| https://jsfiddle.net/umaar/fu4TT/
|
| I'd even make 3d graphics of things like the HTML5 logo:
| https://i.imgur.com/kuEYpSV.png
|
| I posted this all to a community called "Forrst" (think of it
| like twitter, but curated for developers and designers).
|
| I spent time giving feedback on other peoples work, I tried to
| ask insightful questions
| https://twitter.com/umaar/status/823915022917271552 to have an
| open discussion, I spent hours replying to comments every few
| days.
|
| Then one day, Forrst got acquired by Zurb
| https://zurb.com/blog/zurb-acquires-forrst and later on it got
| shut down, and with that, I lost access to huge amounts of my
| work which I hadn't stored anywhere else (some stuff has been
| archived online, but not everything).
|
| When it comes to web development tips, I now self-host on my
| own website and it's a really good feeling knowing that it'll
| be preserved: https://umaar.com/dev-tips/
| techbubble wrote:
| I like what you have done with the site -- very simple and
| easy to check out the tips. I subscribed.
| umaar wrote:
| Hey thanks for that appreciate it. Yes not spending time on
| fancy things/random enhancements let's me actually focus on
| creating new content.
| dwd wrote:
| Some pseudo elements, a gradient and some transforms and you
| can do some really cool stuff. Highly recommend learning how to
| use these effectively:
|
| https://developer.mozilla.org/en-US/docs/Web/CSS/background-...
|
| https://developer.mozilla.org/en-US/docs/Web/CSS/transform-o...
| peruvian wrote:
| A lot of people make games or fun projects for #100DaysOfCode
| when their job might be updating a CRUD MVC app using Y
| framework. I think as long as it puts them in the "coding"
| mindset it's worthwhile.
| techbubble wrote:
| I agree with that 100% -- if it isn't fun, it's work. And if
| you build enough knowledge about how CSS works in general,
| when it comes to implementing specific layout or responsive
| design techniques you have a good understanding of the basics
| to build upon.
| cosmodisk wrote:
| I looked at the one with glass and lemon and I want to cry.
| It's just crazy how much some people push things. I wonder how
| long it took though..
| continuational wrote:
| > Using pixels (px) is tempting because they're simple to
| understand: declare font-size: 24px and the text will be 24px.
| But that won't provide a great user experience, particularly for
| users who resize content at the browser level or zoom into
| content.
|
| Pixels (px) in CSS are relative as well, and scale with zoom.
| What is the benefit of em/rem?
| wackget wrote:
| Yeah I came here to ask this. Using relative units for layout
| seems like a terrible idea. If you want to make your text a
| little bigger, your entire layout changes too. That's fine if
| it's something like text padding or paragraph margins, but
| stuff like border width, or dimensions of boxes? That seems
| weird.
|
| Browsers have been able to zoom pixel widths for years.
| rimliu wrote:
| "Relative" and "Absolute" have their own definitions and by
| that definition "px" is indeed an absolute unit.
| matsemann wrote:
| Not anymore, as most px units now is based on a reference px,
| a size determined based on screen density and viewing
| distance. That's why something rendered at 600px on an iphone
| takes almost all the width, even though the screen has more
| than double that in pixels. And when zooming, the reference
| px is zoomed. So the old reason for not using px and instead
| use rem doesn't apply.
|
| https://developer.mozilla.org/en-US/docs/Glossary/CSS_pixel
| chmod775 wrote:
| >What is the benefit of em/rem?
|
| They (em*) scale with the element's font size, and if you set
| an elements font-size itself in em, that will be relative to
| the parent element's font size.
|
| For example: body { font-size: 18px }
| .something { border: 0.1em solid black; } .something >
| .inner { font-size: 1.5em }
|
| If you change the font-size on body, everything on that page
| will re-scale seamlessly. This is most useful for things like
| buttons/icons that are supposed to flow properly with text. So
| now even if you use them once in big text, and once in a small
| footnote, they'll still fit perfectly within the line.
|
| The biggest limitation to this approach is that you can easily
| end up with computed values that are weird fractions of pixels,
| so you have to be a bit smart and pick an easily divisible
| number for your base font-size if you're aiming for something
| pixel-perfect.
| onion2k wrote:
| The challenge with em units is that if you modify a parent
| element's size it changes the children as well. In your
| example, if you put 'font-size: 2.0em' on the .something
| class then the .inner would end up changing to 3.0em. That's
| rarely what you actually want to happen (especially in a web
| app). If you just want to control the overall font scaling of
| everything on the page using rem is preferable, because then
| they'd ignore the parent and scale based on the root element
| size.
| bbx wrote:
| The key is to use rem for font-size and em or unitless for
| all other properties: padding, border-width, margin, line-
| height. That way the size of the element is independent of
| the context.
| continuational wrote:
| Ok, I can kinda see the value of that - e.g. if you put a
| "tag button" inside some text, it will have the right size in
| relation to that text.
| Izkata wrote:
| There's no date on the article, and this was the entry that
| made me wonder if it's 5+ years old, back when text zoom was
| more prevalent. When full zoom became the default, em/rem
| became less necessary, and at least to me appear to be falling
| out of favor as extra unnecessary complexity.
|
| (Quick edit: Mentioned but not really given much focus is that
| em/rem can be used on, say, image width and margin, as well -
| making it adjustable in a text-zoom world. That's mainly what I
| have in mind here.)
|
| (Even aside from affecting non-text, in the newly popular
| component-oriented design, you typically don't want relative
| font sizing to leak between components.)
| jb3689 wrote:
| CSS is such a weird abstraction. Who thinks in blocks and inline
| blocks? Who thinks in paddings and margins? Floats, etc? I know
| these are more flexible, but I've always found grid-based
| frameworks to be far more intuitive
| Sharlin wrote:
| CSS is a very reasonable abstraction for the job it was
| originally designed for: layouting of mostly textual documents.
| As such it borrows its concepts from the desktop publishing
| world. Margin and padding make absolute sense when you think in
| terms of headings and paragraphs. Float is an established term
| for having text flow by an image or other rectangular
| insertion. And so on. You have to remember the context in which
| CSS was first conceived. The Web looked quite different then.
| runarberg wrote:
| CSS has very much caught up for layouting and styling web
| applications. If you don't believe me, take a look at CSS
| grids.
| Sharlin wrote:
| Yes, I know. But the OP was talking about the classic
| stuff.
| IggleSniggle wrote:
| Dear lord it's 2020 CSS has its own grid system, it's CSS Grid,
| and it's both easier to understand and more flexible than
| adopting the old frameworks. It also has variables, pseudo-
| selectors (which, like with html elements, you can invent new
| ones to suit your purposes), and more.
| benrbray wrote:
| Is creating your own pseudo-selectors really possible? I like
| to think I'm pretty up to date on modern CSS but I've never
| heard of this.
| runarberg wrote:
| I might be wrong but I think GP is talking about shadow
| parts[1] my-element::part(custom-
| selector) { /* ... */ }
|
| 1: https://developer.mozilla.org/en-US/docs/Web/CSS/::part
| [deleted]
| IggleSniggle wrote:
| Well, I wouldn't recommend it, but certainly you can
| programmatically apply a pseudo-element or pseudo-class and
| programmatically define behavior around those things.
| tenuousemphasis wrote:
| You can construct a grid based system based on a block system,
| but wouldn't the reverse be much more difficult?
| robertoandred wrote:
| An off-the-shelf grid system is too inflexible, and you spend
| more time customizing it or fighting it to get the result you
| need than you would have just building what you need.
| z3t4 wrote:
| Specificity and cascade.
| geewee wrote:
| This is actually really nice. I've worked with CSS for a long
| while with the "Stackoverflow it until it works" philosophy, so
| some of these things (e.g. margin collapses) I had no idea about.
| Phillips126 wrote:
| Good stuff here, I certainly learned a few new tricks.
|
| I've been doing web development since around 2005 and to me, CSS
| and HTML has become far easier to use (although that could also
| be from experience). I took a web development course in college
| and found it interesting, later joining a small marketing company
| as an intern. My internship was unique, the company would travel
| to local businesses and sell them on advertising. They'd record a
| small ~2 minute commercial showcasing their business and then I'd
| build an application that compiled all of this data into a "local
| tourism" application. The real kicker - we didn't host the
| content, we burned it onto CDs and distributed the discs (think
| AOL). The company didn't profit well, but it was small and able
| to survive on what income it did make. I'm actually surprised to
| see it still around today - however, it seems they've moved on to
| actual hosted web development and graphic design work now. During
| this time we mostly used a combination of Tables and Photoshop
| "slices" to do layout (yuck!).
|
| Today I use CSS/HTML/JavaScript daily building internal
| applications (and a few external). There is certainly more things
| to worry about such as building applications that are responsive
| now that mobile devices are so prevalent, however my arsenal has
| improved dramatically over the years with the addition of Flex
| and Grid (and many others). I actually enjoy the challenge of
| creating something beautiful and functional.
| daiyanze wrote:
| Hi, all! I'm author on pitayan.com. It's about front end
| development.
|
| Link: https://pitayan.com
| gorgoiler wrote:
| It feels like HTML and CSS could be useful for print layout, but
| I've rarely seen a high quality PDF renderer.
|
| I know Atom's markdown preview uses headless chrome under the
| hood. These are hugely heavyweight tools but the output is very
| high quality.
|
| Are there any other recommended tools for going an HTML route,
| for typesetting? I'd much rather design pages that way than use
| InDesign, PDF scripting, or TeX.
| mkayokay wrote:
| I have been using Python with Jinja2 templates and
| Weasyprint[1] for PDF creation for a side project of mine. The
| libary does have its css limitations but the PDFs it produces
| look good enough for me.
|
| [1] https://weasyprint.org/
| elondaits wrote:
| Yes, I was going to recommend WeasyPrint as well.
| vraylle wrote:
| We use WKHTMLTOPDF (https://wkhtmltopdf.org/). In our case it's
| in the Rotativa package (.NET MVC). There are a few caveats; it
| uses an older headless WebKit engine that doesn't support
| everything. We use the QT Web Browser (http://www.qtweb.net) to
| test/debug when needed. We do design pages to be specific
| "paper" sizes and lean on SVG a lot for anything fancy. We have
| some JS that breaks long tables into multiple tables, etc. But
| the resulting output looks flawless.
| werdnapk wrote:
| I use wkhtmltopdf without much issue. Sure, it has some
| limitations and is built around an older html rendering engine,
| but it works well for a free tool.
|
| I use it mainly via the wicked_pdf ruby gem and I'm sure there
| are wrappers available for other languages too.
| PetahNZ wrote:
| Although not exactly what you want, my day job is basically
| implementing systems that take SVG's produced in design tools,
| pipe them through to a customer UI for designing print books,
| posters etc, then renders high res images server side with
| Chrome headless and finally sending them off to the printer.
| SVG does a great job, but still requires a lot of coding for
| laying out the text, line breaks, pages, etc.
| blauditore wrote:
| > but I've rarely seen a high quality PDF renderer
|
| What exactly do you mean by this? That HTML-to-PDF converters
| mess up the layout, or similar?
|
| You might be aware of this, but it's still worth pointing out
| that you can specify a different stylesheet for the print
| version of an HTML page than the default one. I've used this in
| the past for websites where the customer wanted to use a
| product description page directly for generating PDFs, without
| having to do the work twice. We also used some Java-based HTML-
| to-PDF renderer, which was not perfect but had full support of
| CSS 2.1 and some support of CSS 3 (and this was several years
| ago). I think the library was Flying Saucer (based on itext).
| erichurkman wrote:
| A true CSS+HTML-powered print renderer is PrinceXML.
| https://www.princexml.com/samples/
|
| Having used it for over a decade, it's a wonderful tool.
| Someone1234 wrote:
| That product's license tiers are a complete non-starter,
| unprofessional, and they "call for pricing" on the only
| potentially usable license (but don't provide a copy of the
| CSO License for review before calling).
|
| > A Prince Server License can be installed on a single server
| to produce PDF documents for company-internal use, or
| documents that are made available to everyone free of charge.
|
| They never define what "company-internal use" means, even in
| the actual terms[0]. This was clearly written by a non-
| lawyer, and any company worth its salt wouldn't touch this
| (the "FAQ" isn't a legally binding document, and even that is
| incredibly vague/unhelpful).
|
| > You many not use Prince to generate documents that are part
| of a Commerial Service, for example invoices and monthly
| statements.
|
| So "company-internal use" doesn't include
| order/remittance/invoice/receipt to your company's
| suppliers/vendors? That's just bizarre, the whole licensing
| is. The "Service License" feels like a Honey Trap.
|
| [0] https://www.princexml.com/license/
| leephillips wrote:
| Modern CSS technologies such as grid are convenient for laying
| out webpages. But there can be no "high quality PDF renderer"
| from HTML/CSS. The result will always look as crude as a web
| page. In order to produce a high quality document, you need a
| sophisticated line breaking algorithm such as that deployed by
| TeX or some other software.
| acqq wrote:
| Apart from the course promoted (which sounds really good!), does
| anybody know a really good book that already presents this kind
| of material about CSS use in a similar "logical" way and is not
| being written the style "margin defines the margin" (how
| insightful)?
|
| I'm also searching for the material that is specifically oriented
| on:
|
| - depending on the features existing in all browsers since the
| last 3-4 years, also mentioning how to make the features "usable"
| with the older vendor prefixes, but not depending on the
| JavaScript "fixes" for older browsers, and then showing the
| examples with minimal number of lines.
|
| - demonstrating all the functionality that can be achieved with
| CSS only, no JavaScript
|
| - addressing the real-life problems encountered during the design
| of the modern looking pages, and the goal to use all the power of
| the commonly available CSS features.
| maweki wrote:
| I think a better understanding between inline and block is, that
| inline-elements do not generate a block. The idea of a block
| breaks down for inline elements, especially when they go over
| multiple lines. It's not just a horizontal expansion.
|
| So understand what creating a block means. Inline-elements don't.
| swyx wrote:
| how does this help explain inline-block? your explanation must
| accommodate the holes.
| aflag wrote:
| In his explanation inline-blocks do generate a block. It's
| just a block that doesn't fill the entire horizontal space,
| but expands with the inner element.
| c-smile wrote:
| There are couple of things that author still don't get.
|
| display:inline means that element does not establish a box. Such
| element is rather a collection of individual content boxes (e.g.
| glyphs). These boxes can be placed on different lines (text
| wrapping) and so on. As no element box as no margins and paddings
| applied to such elements.
|
| img element (and input and other replaced(^) elements for that
| matter) is not a display:inline but rather display:inline-block.
| Even you will define them as display:inline they will be treated
| as display:inline-block and so e.g. margins will apply to them.
|
| (^) representation of replaced elements
| (img,input,textarea,iframe,etc.) is outside the scope of CSS -
| they are always treated as solid boxes.
| paozac wrote:
| Useful article. Getting started with CSS must be harder these
| days than it was 15-20 years ago. Not only for mobile-
| friendliness, but also because of the coexistence of
| flexbox/grid/traditional layouts. I'm wondering if the standard
| will ever been simplified, instead of being added more and more
| features.
| dwd wrote:
| https://xkcd.com/927/
|
| Backwards compatibility support will always require adding on
| new ways to do things and not removing stuff.
|
| I personally find flexboxes frustrating at times and tend to
| limit my usage to non-grid spacing (footer columns, horizontal
| menus) and responsive vertical alignment.
|
| CSS grids are pretty cool, and maybe if you were just starting
| out it would be easier to pick up fresh than having to unlearn
| floating divs.
|
| Funny thing is that if you go back 25 years (pre-table layout
| era), everything was not only mobile compatible but your target
| viewport was 800x600 which I find the painful part of mobile
| compatibility these days - it's that ugly zone in-between a
| nice mobile/cell phone layout and having the whole desktop to
| work with.
| perardi wrote:
| "Getting started with CSS must be harder these days than it was
| 15-20 years ago."
|
| Not like I'm teaching anyone these days, but I'm not sure about
| that. Yes, there's just more now. Grid and flexbox and
| transforms and on and on.
|
| But if you were totally starting from scratch, certain stuff is
| just way easier now, or at least, not a pile of hacks upon
| hacks. Basic beginner stuff that comes to mind...
|
| * How can I center something vertically and horizontally
| without having to explicitly know the size of the container and
| object to be centered?
|
| * What is all this float stuff, how do I just make a grid of
| icons?
|
| * Wait, borders fundamentally change the size of my div? What?
|
| * I have to do what now to have a drop shadow?
|
| * How do I keep my branding colors consistent without having to
| make really sure I plug in the right hex values in every little
| color declaration?
| the_other wrote:
| The whole float-based layout thing was a hack. Floats make
| perfect sense if you only ever use them as floats: box-outs
| to run text around.
|
| The fact you could use them to build all sorts of
| header/column/footer layouts was both very helpful and
| entirely confusing.
|
| It became the default way to use CSS, for good reason. Yet, I
| always felt it was a shame it wasn't often described as the
| hack it was.
| k3liutZu wrote:
| I started around 2006 and there are definitively more standards
| -- as in more ways to achieve the same thing. And yes, you have
| mobile -- though we did fluid and "responsive" layouts back
| then as well.
|
| One thing that is better is the browsers adherence to
| standards. I spent my first years learning all IE6 rendering
| bugs and how to overcome them.
| _the_inflator wrote:
| CSS and HTML are constantly evolving, and so its demands.
| However for me CSS is way more straight-forward than in the
| 90th and 00th.
|
| The standards addressed a lot of the pains and struggles we had
| with floats/clearfix etc. This was challenging but nothing im
| comparison to supporting IE 6-9, FF, Safari, Opra etc. at the
| time. Also hacking in JavaScript added to the complexity.
|
| Nowadays I can do with 10 lines of grid and flex what great CSS
| frameworks like Bootstrap abstracted away behind 1000th of
| lines of code.
|
| Also testing is way easier, since browser vendors follow
| standards and there is chromium everywhere.
|
| Earlier we did a lot of div soup, I remember fondly CSS zen
| garden as well as OneDiv.
|
| Awesome times to be a web dev, you work on products (PWAs!) not
| on browser hacks.
|
| My 2 cents.
| techbubble wrote:
| "div soup" - I like that.
|
| The present-day CSS frameworks use "class soup."
|
| For example, tailwind (which I like): <button
| class="bg-teal-500 hover:bg-teal-600 focus:outline-none
| focus:shadow-outline">
| runarberg wrote:
| This sort of class soup brakes the principal of DRY. Much
| better to use CSS to style. button {
| --background: teal; --focus-ring: 2px
| 2px 5px skyblue, -2px -2px 5px skyblue;
| background: var(--background); box-shadow: none;
| } button:hover { --background:
| wheat; } button:focus-visible,
| button:focus:not(:focus-visible) { outline: none;
| } button:focus-visible { box-shadow:
| var(--focus-ring); }
|
| Now you will never forget to add that `hover:bg-teal-600`
| class to your buttons.
| epicureanideal wrote:
| I avoid Tailwind-style CSS frameworks. I prefer SCSS and,
| if needed, mixins. Meaningful class names are much better,
| IMO.
| rimliu wrote:
| Btw, there is an effort to have modern-day CSS zen garden:
| https://stylestage.dev
| rimliu wrote:
| CSS is way easier now when it was 15-20 years ago (source: 24
| years with frontend, 22 professionaly). Alas, that's probably
| one of the reasons why people do not spend any effort learning
| it. I'd argue that 15 years ago was the golden age for CSS
| innovation and web standards in general. Technologies are much
| more powerfull now, but the attitude of those using them could
| use some improvement.
| madeofpalk wrote:
| 15-20 years ago it was exceptionally more complicated to have
| rounded corners on things.
|
| The complexity has just shifted. While previously you could
| easily start using floats, you might run into issues down the
| road with them, or with browser compatibility
|
| Now, you might struggle a bit more trying to understand Gris
| syntax and how to use it, but once you do you're probably set.
| onion2k wrote:
| Just use flexbox (and grid if you need to control both
| dimensions at once). You can ignore all of the old ways of
| doing layout. Flexbox is supported back to IE11.
| Someone1234 wrote:
| > Flexbox is supported back to IE11.
|
| Nope.
|
| An incompatible and broken version of Flexbox is supported in
| IE11. Therefore, layouts look completely different (and
| broken) when rendered in it.
|
| Only people who recommend Flexbox in IE11 haven't tried using
| it in IE11. I might via a library that did the heavy lifting
| for me, but there's just too many bugs to recommend anyone
| write Flexbox and expect it to just work -- it won't/doesn't.
|
| PS - I'd link all the IE11 Flexbox bugs but Microsoft took
| them offline with Microsoft Connect's retirement.
| onion2k wrote:
| I write a fairly substantiate app (60,000 DOM elements...)
| that uses flexbox and SVG for all the rendering and it's
| fine in IE11. The layout problems are more often SVG
| related. That said, if you don't need to support IE11 it's
| much easier not to.
| the_other wrote:
| Did you use AutoPrefixer/PostCSS?
| tzs wrote:
| As an occasional CSS user, I second that. Every time I have
| had to use CSS for anything more complicated than diddling
| item appearance has led to a lot of time on Stack Overflow
| trying to find answers to questions like "why did my height
| change work on this element but not that element?" or "how
| can I center this text vertically in this space?".
|
| I don't use CSS frequently enough to not forget these things
| by the next time I need it.
|
| I'll still probably forget parts of Flexbox between the times
| I need to use CSS, but it will be things like forgetting like
| what spacing modes are available, which is easy to quickly
| look up.
|
| Flexbox is now my turtle [1]. Well flexbox and grid.
|
| [1] https://en.wikipedia.org/wiki/Turtles_all_the_way_down
| thrownaway954 wrote:
| here is the greatest thing i learned about css just last week:
|
| .container { display: flex; align-items: flex-start; }
|
| OMG!!! where have you been my whole life you little flex darling
| :)
|
| you have no idea how much trouble and pain it is to align
| elements that are table cells.
|
| https://css-tricks.com/almanac/properties/a/align-items/
| yakshaving_jgt wrote:
| Cached URL since the server is apparently over capacity:
| https://webcache.googleusercontent.com/search?q=cache:jcSTVF...
| rapnie wrote:
| Now on http://archive.is/AiECQ
| peter_retief wrote:
| Thanks, clearly many people want to have a look.
| christiansakai wrote:
| Very nice. I know most of these but then occasionally forget,
| this website is a good reminder.
| seanalltogether wrote:
| I wish the author had gone a bit further into em vs rem. I'm
| reading other articles on the topic but they're simply technical
| explanations and I'm still not clear on what features of the page
| are best designed using em or rem.
| pabue wrote:
| Generally you want to use rem for setting the font-size of the
| elements and to controll overall spacing.
|
| em is often used for the padding of elements. For example
| buttons that exist in different sizes.
| agloeregrets wrote:
| From an overall perspective,
|
| em: unit based on the font size of the element it is querying.
|
| rem: unit based on the font size of the body element.
|
| rem is helpful if you want to make an entire page scale
| uniformly if you change the base font size (imagine
| accessibility settings) while keeping the same proportions with
| padding to font size.
|
| em is great for things like buttons where you may want to make
| one class for `button.cool-button{ padding: 1em; font-size:
| 14px; &.xl{ font-size: 20px; }}` and then you can change the
| font size by setting the `.xl` Class on that button and the
| padding will go from 14px to 20px. One button, shared
| proportions.
| chrismorgan wrote:
| Correction: rem is relative to the font size of the _root_
| element, which in HTML is <html>, not <body>.
| chrismorgan wrote:
| Just to mess with your mind: in media queries and in the root
| element's font-size declaration, em and rem mean the same
| thing, being the browser's default font size, which is 16px in
| most browsers by default, but customisable in some browsers and
| different by default in some environments (e.g. I seem to
| recall Kindle using 19px). I call this unit the "browser em",
| or _bem_. No one else really talks about it. One thing I
| _haven't_ investigated and probably should: does this unit
| depend on the _language_ the document is specified in? (Because
| you can define different default fonts and sizes for different
| languages in at least Firefox.)
| LocalPCGuy wrote:
| I would guess it does matter about the language, but likely
| because as the language changes the font itself may actually
| change. And different fonts would have different relative
| font sizes. But like you, I haven't investigated it enough to
| make a definitive statement about it.
| christophilus wrote:
| Margin collapse was new to me, and I've been doing this web thing
| a very long time. Over all, that's a great article. Nice and
| readable, too.
| k__ wrote:
| It always helped me to do an absolute basic concepts course on a
| new technology I learn.
|
| Like, sure I can play around in Photoshop or Eclipse or CSS or
| JavaScript and find most things.
|
| But a good 101 course is worth so much saved time.
|
| Most of the stuff in that article was mentioned in a CSS box
| model course I did 10 years ago.
|
| People were always baffled how I learned all this. Well, I read
| the docs!
|
| They always assume every one learned like them, by trying stuff
| out all of the time, until they got something working. Then they
| iterate from project to project, until they sorted out the bad
| ideas and kept the good ones. With that approach, learning CSS
| would probably have taken me 10 times as long.
|
| Sure this doesn't teach you everything or makes you a pro in a
| week, but I always have the feeling people just cobble around for
| too long and should instead take at least a few days for a more
| structured learning approach.
|
| What I didn't learn about CSS in a basic course and what cost me
| multiple weeks to fix, was `pointer-events: none`. Keep this in
| mind when your clicks stop working after you pulled some new CSS
| ;)
| nharmonia wrote:
| I have tried both approaches a fair amount, and realized that
| every time I try the cobbler approach I end up getting blocked
| on some major thing and thus having to rewrite everything
| because of some basic things that could have been avoided.
|
| I feel like it's getting both better and worse now with docs
| getting better in general(no of times I end up on stackoverflow
| has gone down significantly), however a lot of times I end up
| on medium posts with a list of steps and absolutely zero reason
| why. Whenever I try cobbling from those articles, I end up very
| frustrated
| theelous3 wrote:
| Cobbler here, currently cobbling a frontend (am a backend dev
| by trade).
|
| The issue for me is the format these courses and resources
| take. CSS is the most jam packed with non-intuitive technology
| I've met. How many dozens of pages or segments of video would I
| have to go through in a course to learn what the author in OP
| summarised in two or three sentences? Any time I've considered
| the structured approach for something like CSS, the material
| drones on and on with technically correct explanations and
| example code, but somehow against the odds, almost nothing of
| substance.
|
| Worse yet are the top google result reference resources. Look
| no further than the top result for "css grid" if you're in the
| mood to claw your brain from its stem, and flush it down the
| toilet.
|
| Link: https://css-tricks.com/snippets/css/complete-guide-grid/
|
| Behold, 8 zillion words and symbols across 7 trillion seemingly
| randomly organised boxes full of both all of the information,
| and simultaneously none of the information, about css grids.
|
| Which brings me to where I am now, cobbling. It's more
| effective for me to cobble, than to spend an entire day
| figuring out css grids "the right way". If the going gets tough
| I'll just use some grid tool, or look up some sandbox examples,
| and be on my way.
|
| If there was more material like the OP, and someone organised
| it well, well, I'd actually get around to learning it rather
| than cobbling. It's the best bit of writing I've ever seen on
| CSS. This is shocking. Not that there is anything wrong with
| the writing, but it's very, very simple. What on earth have all
| of the other CSS wizards with basic writing skills been doing?
| Confusing the issue, that's what.
|
| Which leads me to a sort of meta frustration with learning CSS.
| I know it's not hard, I know that if someone just wrote about
| it even half decently it would take only a moment to digest
| each concept, but watching learner-disconnected authors create
| resources I can tell have lost sight of what it's like to
| learn, turns me off.
| soperj wrote:
| > Behold, 8 zillion words and symbols across 7 trillion
| seemingly randomly organised boxes full of both all of the
| information, and simultaneously none of the information,
| about css grids.
|
| It's interesting, because that's my go to resource for CSS
| Grid. I find it super handy when I forget something.
| Although, I'm not learning grid, I'm using it.
| wrycoder wrote:
| Reference books aren't the same as textbooks.
|
| And, typically, there are several levels of textbook. e.g.
| high school, then freshman physics, undergrad
| electrodynamics, then Jackson, then specialist references.
|
| My point is you go over the subject completely several
| times, at increasing levels of sophistication.
| chrismorgan wrote:
| > _Although, I 'm not learning grid, I'm using it._
|
| _Precisely._ What CSS-Tricks calls a guide is actually
| almost entirely a reference. It makes a tolerable reference
| if you already know what you're looking for. It's a poor
| reference if you don't know what you're looking for because
| it's insufficiently structured and takes waaaaay too much
| scrolling to explore. (It used to be more manageable--it
| used to _be_ more a guide. It has been allowed to grow far
| beyond a healthy point.) And it's _atrocious_ as a guide.
| k__ wrote:
| Yes, web technology is overloaded, because of the history,
| backwards compatible stuff etc. pp.
| cosmodisk wrote:
| Couldn't agree more. I had less issues learning multiple
| programming languages,some challenging concepts around them
| and yet when it comes to CSS, most resources aren't very
| useful. You do something and it doesn't work. You check
| documentation and it show exactly the same thing that does
| work. 5 hours later it turns out it was some overriding
| property+ browser incompatibility+ weird undocumented
| exception. Very few books do deliver on their promise either.
| I don't know,maybe it's just me but the whole ecosystem is a
| bit weird.
| hutzlibu wrote:
| " but the whole ecosystem is a bit weird."
|
| It absolutely is.
|
| The web was meant for static documents and some link magic.
|
| Now allmost every complex programm can run in the browser
| with web technologies. And in the time between you had lots
| of powerful organisations with their own agenda, as well as
| millions of single developers with a agenda and a loud
| voice. How could a sane, clear spec be made, under these
| circumstances?
|
| Besides, it would be very hard, to make a clean spec that
| satisfies the needs of the whole population. So by now I
| say, all in all, it works pretty good.
| runarberg wrote:
| Your evaluation is problematic.
|
| I am a front-end dev by trade and I could really easily say
| similar things about the tech stack you work with daily.
|
| If you want a good reference and a learning guide start with
| this: https://developer.mozilla.org/en-US/docs/Web/CSS it is
| what us professional use.
|
| For us professionals that use CSS in our jobs, that have put
| the same amount of hours into front end technology as you
| have done for back-end, CSS is a perfectly cromulent
| technology. It is easy to work with, it is intuitive, it is
| easy to find a good reference (go to MDN not random blog
| posts from people that are admittedly not masters of the
| craft).
|
| If I try to cobble together a back-end I expect to be
| frustrated with it, I expect not to be able to do everything,
| I expect I'd need to find poor example and try to hammer them
| in to fit my needs, I don't expect to be able to understand
| all the example snippets. Why are you on your high horse
| judging my tech stack this way?
|
| If you need a good well crafted front-end for your project,
| you should hire a professional front-end developer. Or find a
| friend who is one that is willing to it in their spare time.
| Or spend a few thousand hours learning and mastering the
| craft. Alternatively you can cobble together a good-enough
| front-end that works, just don't complain about how hard it
| is because "technology hard wheee wheee". Us professionals
| use it every day and are fine with it.
| theelous3 wrote:
| "here I am, at the end of the maze, telling people at the
| beginning how straight forward it is" is basically all I'm
| getting here - and you call my eval problematic.
|
| Multiple accounts of people not in your position telling
| you a problem exists. Ok, great, you worked through it.
| Doesn't mean it's as good as it should be.
| runarberg wrote:
| Well you come across as an outsider telling us that the
| tools that we use--and do a fine job with--are no good,
| and that our literature sucks.
|
| I am here to argue that this sort of attitude is
| problematic. If you browse through this thread you will
| find no shortage of comments describing how absolutely
| basic this article is (and a little void of insight, and
| a little out dated), and that there are people in the
| industry getting six figures while not knowing this
| stuff. Frankly it is a little insulting. And I think the
| attitude that you presented above is part of the problem.
| There definitely exists a lack of respect for the craft
| of front-end development within our industry. This sort
| of attitude is not helping.
| mslm wrote:
| I had the same perspective on these frontend technologies as
| a backend/ops guy, and it all finally clicked when it came to
| me that I just couldn't find a justification for why CSS was
| the way it was.
|
| This was solved trivially by just reading the history of CSS.
| It was shocking to finally have made clear all of the quirks
| and weird aspects of CSS that always made it difficult for me
| to connect the dots and feel myself lost in a messy tangled
| up language.
|
| By far the best source I went through was found here:
| https://news.ycombinator.com/item?id=22215931 - it's a long
| read, but extremely enlightening!
|
| https://www.w3.org/Style/CSS20/history.html was also useful.
| _jal wrote:
| This is a great comment. I expect it only applies to some
| folks depending on how they learn, but it resonates a lot
| with me.
|
| I find it very difficult to learn the whats and hows of a
| new thing without the whys. I tend to construct mental
| frameworks of things, revising the inaccurate bits as I go,
| until theory starts meeting practice. (I always did poorly
| with math "teachers" whose method was, "doesn't matter,
| just do it." But it did take a while to realize that they
| were failing, not me.)
|
| So when I encounter complicated, new things with a history,
| I usually try to start with at least a bit of the history.
| vivekseth wrote:
| 100% agree. I found this to be a good guide:
| https://developer.mozilla.org/en-US/docs/Web/CSS
|
| After spending a few hours reading up on topics I thought would
| be relevant, I find that I am significantly more productive
| with CSS. Instead of trying to find answers on google, I find
| that I'm better equipped to build things and diagnose issues on
| my own.
| kccqzy wrote:
| I totally agree. A good _book_ that introduces CSS in a
| methodical perspective is a must. I personally cut my teeth on
| CSS with the book _Web Design in a Nutshell_ , a 2006 book. I
| remember having written CSS in a haphazard try-and-see fashion
| before that, which utterly confused me, and then reading an
| actual book made everything clear. This is an investment worth
| making. Many years later I'm still almost always "the guy" on
| my team to go to when there's a weird CSS issue.
| commandlinefan wrote:
| > A good _book_
|
| One under-appreciated value that actual books have over
| online documentation is that you know immediately what order
| you're supposed to read them in.
| wilsmex wrote:
| I built my first site in the 90's too (before CSS)! I've been
| in higher education lately, but have a YouTube channel with
| mostly CSS related content (both beginner & advanced). Check
| that out if you're interested in some great starter learning
| content for CSS and you prefer video format:
| https://www.youtube.com/followandrew
| im3w1l wrote:
| I'm kinda curious how the long term viability of these
| strategies look. Intuitively I think that reading the docs will
| become less and less viable as there are more and more
| available technologies and they become more and more featured.
| But I'm not fully convinced. Maybe it can keep working by only
| teaching the most important subset.
| theelous3 wrote:
| Learning by course is generally good (rust book!), but
| "overlearning" certainly exists in all technologies. I've
| been hanging out in freenode's ##learnpython for years
| helping noobs, and I can't count how many times I've met the
| scenario of a new programmer working their way methodically
| and studiously through a 2k page book, stuck on page 1643,
| because they haven't actually grasped concepts from page 20.
| They'll be all kinds of worried about how to correctly use
| slots and metaclasses, when they can't write even basic
| functions.
|
| CSS suffers massively from this info overload.
|
| What I tell every new programmer who will listen, is that
| they should first grasp the absolute basic building blocks,
| and then learn to read the docs. That's really all you need.
| Unless the particular language or technology their are using
| sucks, you can essentially compose anything from the basics.
| Once you've done that, the sortcuts and sugar you learn
| naturally actually make sense, rather than appear before you
| as spooky magic boxes and incantations.
|
| _My_ ideal CSS course would just be the absolute basics of
| syntax and concepts, a primer on understanding and
| incorporating information from the docs, and then an index of
| well organised resources, such as the OP 's.
|
| This way, it's impossible to overload, and I'm left in a
| state where I can expand at my own personal rate. Anything
| that tries to set the pace _for_ you is going to be
| suboptimal for 99% of readers.
|
| Furthermore, anything that flows easily and without extremely
| explicit DO NOT PASS GO UNTIL YOU ARE EXCELLENT AT THE LAST
| CHAPTER, will lead to overload. You can't overload if you
| don't provide the information one can overload with. Simply
| ending your course after the basics and docs, absolutely
| guarantees against this problem. "Leave the learner in a
| known good state", would be my rule of thumb.
| jrumbut wrote:
| Once I got the basic concepts of CSS I came to realize that of
| the trio of HTML, CSS, and JS (and SVG for that matter), CSS is
| the one you really miss when you have to make something using
| another system.
|
| The amount of suffering I've endured in Latex, PDF, different
| native layout systems, or even React Native's slightly
| restricted version of CSS that would have been resolved by a
| stylesheet is immense.
| thiht wrote:
| I completely relate. Other things I learnt "formally":
|
| - regexps (this is a big one, being able to write a complex
| regexp without thinking about it is amazing)
|
| - Git
|
| - basic JS when it was mainly used to add snow on your page
|
| Taking the time to properly learn things is extremely valuable.
| nwallin wrote:
| > I always have the feeling people just cobble around for too
| long and should instead take at least a few days for a more
| structured learning approach.
|
| There are two kinds of documentation: there's a list of all the
| individual things you can do, and there's a "The fundamental
| abstraction is _this_ ". The second is rare, and rarely done
| correctly, and _much_ more important.
|
| A lot of people assume that X is like Y, but with Z, and they
| know Y, so they just need to learn about Z. A lot of time that
| isn't true, the fundamentals are different. The natural way do
| perform W in Y might be profoundly wrong in X. Examples:
|
| * git is like subversion, but distributed.
|
| * C++ is like C, but with classes.
|
| * C++ is like Java, but you have to remember to delete stuff.
|
| I love git. I love C++. I think these things are the bee's
| knees. They're so simple and elegant. But I totally understand
| how people think they're arcane eldritch horrors when you're
| holding the sword by the pointy end.
| commandlinefan wrote:
| > there's a "The fundamental abstraction is this"
|
| In most cases, I'd settle for "what problem this is trying to
| solve" (although this is obvious for CSS, it isn't nearly as
| obvious for things like React and Vue).
| jyriand wrote:
| It's amazing how software engineers can get things done without
| actually knowing the tools they are using. CSS is one of these
| tools that i never bothered to learn properly but instead hack it
| until it works as expected.
| cookiengineer wrote:
| Meanwhile, this is, oh so damn outdated. (I'm not kidding)
|
| Most people don't know that the flow model totally changed
| meanwhile, and something like "display: inline-block" actually
| means "display: inline flow-root", everything that came after
| flexbox kind of had an influence to the meanwhile borderline
| insane display model as a result.
|
| Everything related to inset, margin and padding has gotten an
| overhaul that is ready for ltr and rtl content where they switch
| x/y flow based on "direction: ltr (or) rtl" whereas e.g. "margin-
| inline" and "margin-block" are the newer properties for the
| updated margin.
|
| A lot of stuff has changed for the better, too.
|
| CSS transforms are now specified in a cleaner way, with a
| predictable way to render them (e.g. translate rotate will not be
| different than rotate translate). So all CSS transforms have
| gotten their own properties like "rotate: 90deg" or "scale:
| 1.23".
|
| I learned a lot when I read through the actual CSS
| specifications, because I am implementing my own parser (for my
| Browser [1] project).
|
| Also, did you know that @media, @supports and @viewport queries
| can be nested in any order? The media queries 4 [2] spec is kind
| of insane from an implementor's view.
|
| [1] https://github.com/cookiengineer/stealth and
| https://github.com/cookiengineer/stealth/blob/X0/FEATURES.md
|
| [2] https://www.w3.org/TR/mediaqueries-4/
| andrewmcwatters wrote:
| I'm a layout implementor for Planimeter's Grid Engine.
| Implementing a naive subset of the algorithm for calculating
| the box sizes in the visual formatting model and calculating
| layout for normal flow, relative positioning, and absolute
| positioning is far easier to implement than flexbox.[1] There's
| nothing insane about this. And you'll learn even more when
| trying to draw to the screen.
|
| Normal flow also doesn't require multiple passes, whereas
| flexbox does.[2] Even Yoga doesn't implement a conforming
| model.[3] I'd even speculate that flexbox performs slower than
| the standard visual formatting model just because of the
| differences in the algorithm.
|
| Transform order absolutely matters. Any attempts to coerce
| order into a standardized sequence means developers have to
| account for this information.[4]
|
| [1]: https://github.com/Planimeter/grid-
| sdk/blob/master/engine/cl... [2]: https://www.w3.org/TR/css-
| flexbox-1/#resolve-flexible-length... [3]:
| https://github.com/facebook/yoga/blob/master/yoga/Yoga.cpp#L...
| [4]: https://docs.microsoft.com/en-
| us/dotnet/framework/winforms/a...
| irrational wrote:
| What are your thoughts on CSS Grid? Does it require multiple
| passes?
| andrewmcwatters wrote:
| I have not made any website or UI designs which require it,
| so I'm not experienced enough with it to say. As a result,
| I also have not made attempts to implement it.
|
| c-smile is a well known implementor in the space, and his
| comments are valuable as well.
| c-smile wrote:
| If the question is about layout computation then CSS Grid
| layout (and ideally <table> layout) is a typical LP task
| [1].
|
| And there are known way of solving these things, e.g.
| simplex methods or Cassowary constraint solver (CCS)[2]
| will work.
|
| In fact flexbox layout is a particular case of LP task and
| also can be solved by CCS efficiently.
|
| [1] https://en.wikipedia.org/wiki/Linear_programming [2]
| https://en.wikipedia.org/wiki/Cassowary_(software)
| cookiengineer wrote:
| > Implementing a naive subset of the algorithm
|
| ... and suddenly, a wild "overflow" and "text-overflow"
| appeared.
|
| > Transform order absolutely matters. Any attempts to coerce
| order into a standardized sequence means developers have to
| account for this information.
|
| What I meant is that the CSS specification for the new CSS
| transforms Level 2 has a fixed transformation matrix and
| order in which the properties are applied - whereas legacy
| "transform: rotate() scale() translate() ..." did not do
| this, and therefore was overly complicated.
|
| In the new specification the transform order does not matter,
| because the order in which "translate: ...", "rotate: ...",
| "scale: ..." and "offset: ..." are applied is specified and
| cannot be changed. See [1]
|
| PS: I'm talking about CSS transforms level 2, not level 1. I
| assume you are talking about level 1. "translate: 13% 37%" is
| a property whereas "transform: translate(13%, 37%)" was the
| legacy method.
|
| Personally, I prefer CSS transforms level 2, because they are
| implementable in an easy manner. Having to write a complex
| compositor isn't an easy task, especially on mobile.
|
| [1] https://drafts.csswg.org/css-transforms-2/#ctm
| andrewmcwatters wrote:
| Overflow is easy enough to deal with, text-overflow
| requires more work because it actually requires you have a
| model that matches the W3C specification understanding of
| generating boxes, instead of matching elements 1:1 which is
| what most naive implementations do. The same can be said
| about the white-space property.
|
| Both are easy to implement; in one version, you parse then
| push the exact order of the parsed statements to matrix
| transformations. In level 2, you coerce them into the
| standardized order.
|
| That being said, if you wanted to do anything based off of
| developer-specified transforms, you _have_ to use level 1
| 's style of applying the transformations. I would expect
| that GSAP and other such libraries rely on this behavior.
| Anyone familiar with shader-based transform code will be
| thinking in this manner anyway.
|
| I'm not sure why anyone would want to use the level 2
| manner of specifying transforms if you know what you're
| doing, because presumably, you immediately lose the ability
| to push additional transforms to the transform stack.
| andi999 wrote:
| Anybody knows a good book on CSS for ppl with a solid programming
| background? Every couple of years I try something and fail.
| Somehow the tutorial rave about the cascading on and on, and when
| it comes how to strategically design a good SAP working on
| different devices the stuff gets mute quickly.
| noir_lord wrote:
| Not a book but https://developer.mozilla.org/en-US/docs/Web/CSS
| is my go-to for all things CSS, I love mdn it's a fabulous
| resource.
|
| Also zeal (dash on Mac which is paid or you can build zeal
| yourself like I did) has docsets for CSS which are good.
| dwd wrote:
| https://caniuse.com/ is also invaluable to check whether the
| cool CSS feature is actually supported. it's very much
| today's quirksmode.com.
|
| Once upon a time I would have recommended Eric Meyer's CSS
| Definitive Guide without hesitation (I think I still have my
| 1st Edition copy) and it looks like he's re-released with
| updates for flexboxes and grids.
| lrmunoz wrote:
| Best resource I've found to learn the foundation of HTML/CSS is
| Shay Howe's guides [1]. I think it doesn't cover Flexbox and
| more advanced layouts, but it's totally worth a read. I still
| go back to it as reference from time to time.
|
| [1] https://learn.shayhowe.com/
| nanna wrote:
| Can't recommend Andy Bell and Heydon Pickering's Everyday
| Layout enough. It's a wonderful resource for learning (and re-
| learning) contemporary best practice CSS.
|
| https://every-layout.dev/
| httpsterio wrote:
| I have every book written by Heydon and am currently doing
| Andy's 11ty course. They're both stellar teachers and some of
| the most knowledgeable programmers when it comes to HTML and
| CSS. Every Layout is amazing. Strong recommend.
| bbx wrote:
| I've written a small CSS ebook if that interests you. [1] It
| teaches you how to build a webpage from scratch.
|
| I'm currently writing my second one, which will be more
| theoretical and cover things like this blog post actually. I'd
| be interested to know what kind of problems you're facing in
| CSS, so feel free to drop me an email.
|
| [1] https://jgthms.com/css-in-44-minutes-ebook/
| jventura wrote:
| I'm curious about your book, as it seems small enough for the
| kind of things I write as well [1]. Can I ask if it earns you
| enough for anything?
|
| Sorry for coming out of nowhere, but I have lots of small
| tutorials I could use (I teach in a local college) which I
| could make small ebooks out of them.. Looking for some side
| money..
|
| [1] https://github.com/joaoventura/full-speed-python
| bbx wrote:
| I've been earning a bit on a regular basis since I
| published it 1 year and a half ago. Not enough for
| replacing a salary, but enough as side pocket money. I'm
| lucky to have a decent following, so I didn't have to
| market it a lot. I'm currently writing a second one which
| is longer and more advanced, so hopefully it will earn me a
| bit more.
| jventura wrote:
| Thanks for the reply! Do you have any practical tips you
| may want to share? Maybe how did you grow your audience,
| how you wrote your book (technologies, etc.)?
| bbx wrote:
| Well I grew my audience on Twitter by building open
| source projects. [1] I didn't really plan or aim for
| anything. It mostly happened.
|
| As for technologies, I just wrote the book in markdown
| using Sublime Text. Then I used a markdown-to-pdf library
| from GitHub to generate my ebook, and voila. Nothing
| fancy really.
|
| [1]: https://twitter.com/jgthms
| superasn wrote:
| This is content marketing done right. I really don't mind that
| this article is there to promote the book when it actually offers
| some value to the reader (I actually learned a new thing, nth-
| child and nth-of-type)
| jraph wrote:
| An element that has: display: inline-block
|
| is inline outside, block inside.
|
| That is, the element is inline for the containing block, but its
| children feel like they are in a block.
|
| An inline-block element can be vertically aligned with respect to
| the baseline: it acts a bit like a character in a paragraph.
| That's why you can vertically center things using vertical-
| align:center on an inline-block element.
|
| At least, this is my intuition of inline-block, this comment is
| far from being normative.
| runarberg wrote:
| To be even more pedantic: It is inline outside and _flow-root_
| inside. From MDN:
|
| > The element generates a block element box that establishes a
| new block formatting context, defining where the formatting
| root lies.
|
| https://developer.mozilla.org/en-US/docs/Web/CSS/display-ins...
| jraph wrote:
| Ah but then it does not work as a mnemonic anymore!
|
| I'm kidding. Thanks, TIL I learned that with now have
| display-inside and display-outside (and flow[-root]). This
| makes perfect sense. Finally, even, I'd say. Having a
| property that defines both the behaviors of an element
| outside and inside without being able to define these
| behaviors separately was both strange and limiting. I'm happy
| I even used the terms that have been chosen to speak about
| these notions in CSS by chance.
|
| How do you track all these useful additions to CSS
| conveniently though? I can't rely on random comments on HN to
| learn about them by chance (no offense intended to your
| valuable comment btw, being random is perfectly fine). I also
| can't possibly systematically learn about each and every
| addition neither. Are there resources addressing this?
| runarberg wrote:
| I recommend taking the State of CSS[1] survey, it is a nice
| way of keeping up with the latest features. Other then that
| I use PostCSS with the postcss-preset-env[2] plugin. There
| you can enable various future features of the language and
| have it compile down to a more supported version. If your
| _really_ want to dive into the future of CSS you can read
| the issue board for the CSSWG[3] (beware, it can suck hours
| out of your days). Smashing Magazine[4] and A List Apart[5]
| also sometimes have articles about a new(ish) or upcoming
| features.
|
| But the CSS community could _really_ benefit from the spec
| maintainers having more active bloggers among them (e.g.
| like Rachel Andrew[6]) and provide a regular update of the
| language like 2ality does for JavaScript[7].
|
| 1: https://stateofcss.com/
|
| 2: https://preset-env.cssdb.org/
|
| 3: https://github.com/w3c/csswg-drafts
|
| 4: https://www.smashingmagazine.com/
|
| 5: https://alistapart.com/
|
| 6: https://rachelandrew.co.uk/
|
| 7: https://2ality.com/2019/12/ecmascript-2020.html
___________________________________________________________________
(page generated 2020-07-17 23:00 UTC)