[HN Gopher] Old dogs, new CSS tricks
___________________________________________________________________
Old dogs, new CSS tricks
Author : mxbck
Score : 158 points
Date : 2024-05-26 19:46 UTC (1 days ago)
(HTM) web link (mxb.dev)
(TXT) w3m dump (mxb.dev)
| nolongerthere wrote:
| This article is interesting but when we're talking about design
| elements I think it's always a good idea to include some actual
| demos or examples showing the final result and not just the
| "code". I might also not be the target audience but I still don't
| understand what container queries are or what old paradigm
| they're replacing. The author does a good job explaining the
| difference between border-radius and the old way of using
| photoshop, but fails to do that for the features that he's trying
| to promote.
| ervine wrote:
| Old paradigm (media queries): You make layout changes based on
| the width / height of the viewport (browser).
|
| New paradigm (container queries): You make layout changes based
| on the width / height of the containing element.
|
| This lets you layout a component so that it looks good in any
| sized container. Picture a component that might be in the main
| section or in the sidebar - you can now just style directly
| based on width of the container instead of having to know the
| total width of sidebar + main section and do the calculation
| using viewport width.
| kevindamm wrote:
| Agreed, but to add to this:
|
| media queries are still useful, and since a media query may
| hide/remove entire containers in the view then the remaining
| containers may have widths that are no longer a simple
| proportion of the viewport width (or other property being
| selected for).
|
| So container queries can also enhance styles with media
| queries, not just replace them.
| AltruisticGapHN wrote:
| CSS is becoming too complex. The syntax looks like it wants to be
| output by some compiler instead of being crafted by hand.
| Personally I also don't have any pleasure anymore writing CSS
| these days.
|
| Sass and BEM methodology works fantastically well. Naming things
| isn't that hard, but Tailwind/utility approach is also extremely
| useful.
|
| Those new features, besides container queries is just gibberish.
| Layer? WTF? The cascade is bad enough as it is, most devs can't
| even deal with the cascade it's why Tailwind become so popular.
| And we should dive even deeper into the cascade BS with layers
| and scoping and whatnpt? Again, this all looks like it was made
| to be output by some CSS compilers, not written by a developer.
| notRobot wrote:
| You don't have to use the new fancy features, you can keep
| doing things the old way.
| pipeline_peak wrote:
| I think he means other people will though.
| willio58 wrote:
| I'm unsure if you have specific feedback or just a general
| misunderstanding of the point of additions like layer to the
| spec.
|
| At the end of the day these are all more tools in our toolbelt.
| If you want you can keep writing CSS the same way you always
| have.
| paulryanrogers wrote:
| There is a concern that one can have too many tools to do the
| same -- or very similar -- things. This can reduce
| readability. Consider Perl's many ways approach to Python's
| (initial) goal of one way.
| orhmeh09 wrote:
| Every new release of Python 3.x further erodes this idea. I
| like using the new features because I find Python generally
| inexpressive and verbose, but I have a hard time explaining
| to nondevelopers who read the code about the assignment
| expression, keyword only arguments, structural pattern
| matching, typing improvements and deprecations and so on.
| culi wrote:
| > At the end of the day these are all more tools in our
| toolbelt. If you want you can keep writing CSS the same way
| you always have.
|
| I don't really stand by GP's comment but I also don't think
| their concern can be dismissed this easily. We generally
| write CSS as teams. You'll have to read as much CSS as you'll
| have to write. Ideally you actually read more than you write
| so you can reuse existing rules and follow established
| patterns
|
| Anyone writing CSS for a day-job, an OS project, or even just
| following a tutorial will have to _at least_ familiarize
| themselves with these concepts
| bryanrasmussen wrote:
| it's sort of weird, there have been multiple comments where
| people have responded as if they write CSS all by
| themselves and there are no colleagues to worry about, and
| that they also think this is an industry-wide standard!
|
| on edit: just to note I'm generally the old guy who is
| pushing for people to use 'new' stuff like clamp, min, and
| max functions and lab color profiles, to no effect.
| paulddraper wrote:
| Is your complaint about the features, or the syntax?
|
| I think the syntax is good (getting better with nested
| selectors)
| cthor wrote:
| Just because you don't understand it yet doesn't mean it isn't
| useful.
|
| An ideal version of CSS would remove the need for SASS, BEM,
| and any non-thematic framework. That we have to use those right
| now is a problem to be fixed.
| JimDabell wrote:
| I've got the exact opposite reaction to you: the improvements
| to CSS are making the CSS I write simpler.
| kerkeslager wrote:
| > Quick question: how many of these have you actively used in
| production?
|
| > Container Queries
|
| I haven't used this, but it looks super useful.
|
| > Style Queries
|
| Eh, I'm sure this is useful for situations that don't come up
| very often.
|
| > CSS Layers
|
| Ugh, I'm not going to use this overly-complex silliness, and I'm
| not looking forward to debugging this when other people use this.
|
| > Subgrid
|
| Again, overly complex. Grid could already do everything this can
| do, more simply.
|
| > Native Selector Nesting
|
| I'm already using this.
|
| > Anchor Positioning
|
| Eh, I already had solutions to this problem, but this seems like
| it probably communicates intent a bit better. I guess I'll pick
| that up.
|
| > :has, :is, :where
|
| :has is useful
|
| :is... okay, fine, syntactic sugar.
|
| :where I don't believe in hell. If I did, I'd be against it
| because burning someone for eternity is inhumane. But I might be
| willing to make an exception for people who write CSS that
| requires you to read the MDN article on Specificity to understand
| it.
|
| > Logical Properties
|
| Perhaps useful for situations that don't come up very often.
| Seems complex, but that might be because the thing it's
| representing is inherently complex.
|
| > Scroll-Linked Animations
|
| Okay, someone who isn't me will probably do really cool things
| with this.
|
| > View Transitions
|
| Another thing that seems complex, but possibly because the thing
| it's representing is inherently complex.
| bobthepanda wrote:
| i actually came up with a thing where subgrid would be useful,
| since subgrid lets you denote that a child wants to use the
| same grid as the parent.
|
| if you wanted to use grid template areas, and you had something
| that looked like <div id="my parent grid">
| <h1>Title</h1> <ul> <li />
| <li /> </ul> </div>
|
| There isn't a great way to make the <li> adhere to the grid
| template areas, because without subgrids only direct children
| (the ul) have coordinate attributes.
| noduerme wrote:
| I haven't needed to do CSS grids for awhile, but couldn't
| this have already been done with `display:contents` ?
| bobthepanda wrote:
| TIL about display:contents. I'll have to check it out but
| it sounds like it does: https://bengammon.co.uk/css-grid-
| and-display-contents/
|
| Subgrid lets you do it for anything more involved or deeper
| though.
| noduerme wrote:
| I think subgrid might give you a freer hand. Because if I
| remember correctly, the trouble with display:contents is
| that no other styles you put on that element will affect
| elements within it. This means shifting all styles down a
| node, which can be a real pain and have knock-on effects.
| yurishimo wrote:
| `display: contents` has a11y concerns in a lot of
| scenarios. The `ul` will be hidden from a screenreader and
| it will be read as `h1, li, li, li...` etc.
|
| It's a neat hack, but it's still a hack.
| richrichardsson wrote:
| After having seen a11y written about 100x times in Svelte
| warnings, it's finally dawned on me that it means
| accessibility, which is somewhat ironic that I had no
| idea what it meant all those times before.
| yurishimo wrote:
| Please don't take this the wrong way, but can I ask how
| you personally find answers to similar solutions when
| they come up in your work/personal life?
|
| The first thing I do when I see an acronym or word I
| don't understand is go to Google and type `what is a11y
| webdev` or whatever. I think you get the idea.
|
| This has been a part of my life for almost 2 decades now
| so I'm curious how others handle the situation! What made
| you wait so long to find the answer? Did you eventually
| search for it, or did you finally read some document that
| spelled it out explicitly?
|
| Again, genuinely curious! I assume many people operate
| like I do and there is a line between explaining too
| little and too much. Understanding how others approach
| these problems hopefully will help me improve my own
| communication in the long run.
| azangru wrote:
| > But I might be willing to make an exception for people who
| write CSS that requires you to read the MDN article on
| Specificity to understand it.
|
| May I ask you, are you a front-end developer?
| rafark wrote:
| > I can't use [feature X], I need to support [old browser].
|
| And that's not necessarily a bad thing.
|
| As I commented a few days ago, nowadays devs don't seem to care
| too much about backwards compatibility. I like to hold onto my
| devices longer than most people and it's a bit frustrating to see
| that most sites nowadays expect you to be in the latest and
| greatest. It didn't use to be like this.
| parhamn wrote:
| I'm a bit torn on this when it comes to browsers.
|
| We recently had a user email us that our app stopped working
| for them. After we dug into it it was because their Chromebook
| was last updated in 2021 and didn't have Object.hasOwn (which a
| third-party library uses) and it's not even included in most
| common polyfills either. We fixed it, because I hate these
| sorts of compatibility issues.
|
| Nevertheless, I left a bit concerned that they hadn't updated
| their Chrome in 3 years. Software decays much quicker than
| hardware in a real way, especially with the never ending list
| of security vulnerabilities found every year. Theres definitely
| a case to be made that forcing software upgrades is good for
| the end user too.
| nemomarx wrote:
| I think you can expect that for a Chromebook, but a different
| type of laptop might not support modern Chrome? I remember
| that Steam uses enough chromium nowadays that they had to
| drop support for Windows 7 early. Chrome doesn't have quite
| as long a support window for older OSes as the OSes do for
| security updates.
| Guidii wrote:
| Is that true? Windows 7 OS updates ended in 2020, while
| Chrome continued to update until M109 in 2023[1].
|
| [1] https://support.google.com/chrome/thread/185534985/suns
| ettin....
| jwells89 wrote:
| Yes, for browsers the window for what qualifies as being
| recent enough to be safe has shrunken dramatically. I'd be on
| edge about using a browser that hadn't been updated in even
| one year... if I had to use a 2+ years outdated browser, I'd
| have it locked down (NoScript installed, bells and whistles
| like webfonts disabled, etc) and be much more cautious than I
| am normally.
| chrismorgan wrote:
| Just a remark on that _specific_ case: Object.hasOwn landed
| in Chrome 93 in August 2021, and came last to Safari 15.4 in
| March 2022. My general advice is: _never_ depend1 on features
| less than two years old, _avoid_ depending on features less
| than three years old, and treat two-and-a-half-year-old
| Safari as a bigger deal than one-and-a-half-year-old any
| other browser, because of how Safari major versions are tied
| to major OS versions to at least _some_ extent2.
|
| --***--
|
| 1 When I say "depend" I mean "break if it's not present". A
| degraded but still functional experience is acceptable.
|
| 2 I don't use Apple stuff, so correct me if I'm wrong, but I
| _believe_ that this used to be the case for macOS but may be
| fixed since macOS 12 <https://en.wikipedia.org/wiki/Safari_(
| web_browser)#Version_c...>, and is still the case with iOS
| _et al._ I believe iOS /Safari 15 is still the current
| version on some actively supported devices.
| panzerboiler wrote:
| On my 2012 macbookpro I am forced to use chrome or orion
| since safari is stuck on 15.X. On my 2015 iMac I can still
| use the current version of safari, but probably not safari
| 18 when it will come out. So, for now, the cut-off is 10
| years. Pretty good I would say.
| yurishimo wrote:
| Yes, macOS makes it possible to install newer Safari
| versions on older versions of the OS. However, if you are
| the type that doesn't update your major OS version
| regularly, you probably don't check for random software
| updates anyway, because Apple still shows the Safari
| updates in the same place as general OS updates. From the
| settings app, it's the same little red update dot
| regardless of what the update actually is.
|
| I suspect that many people who use old Safari versions are
| either used to sites being broken, or they use Chrome and
| don't care. I wish we had more data to verify those
| assumptions.
| 6510 wrote:
| One cant update an iphone if there is insufficient free
| storage, they may have very limited storage and there is
| no good way to manually move photos and videos to windows
| over usb or from icloud. People then end up deleting
| media one by one by hand while taking new pictures and
| making new videos. It can take a very long time. Most
| pictures are/feel more valuable than the update.
| yurishimo wrote:
| Totally. The phone problem I think is unavoidable for a
| large enough organization. At a certain size of company,
| with enough users, you just have to accept that your tech
| stack will lag behind for a few years, OR, you're going
| to spend an extraordinary amount of dev time building
| backwards compatibility for less capable devices.
|
| I find it silly how some people tack on "just ship a
| fallback stylesheet" as a legitimate answer (not accusing
| you) because we all know that it's never that simple.
| 6510 wrote:
| I just don't use any of the new features until someone
| complaints about it. If support is there and it doesn't
| make it impossible to reason about ill adopt it and thank
| them. @container style(color: green) and
| style(background-color: transparent), not
| style(background-color: red),
| style(--themeBackground), style(--themeColor:
| blue) or style(--themeColor: purple), (max-width:
| 100vw) and style(max-width: 600px) { /*
| <stylesheet> */ }
|
| It is useful as a selector for people. Best not let that
| guy anywhere near my code.
| eviks wrote:
| > Software decays much quicker than hardware in a real way,
| especially with the never ending list of security
| vulnerabilities found every year.
|
| What's the connection to security vulns? How does that impact
| devs not using "a separate stylesheet to support everyone."
| or ignoring "progressive enhancement"?
|
| Or what's the vulnerability explanation of hasOwn?
|
| It seems it mostly decays quicker on some webby platforms
| that culturally don't care much about backwards compatibility
| nine_k wrote:
| Is there a Chrome LTS channel?
|
| Firefox has an LTS version which can be a baseline for
| features, but which receives security updates at the very
| least.
|
| I don't know about, say, Chrome 80 line that would receive
| security fixes but not new features. I also think that
| would be against Google's interests to have such an LTS
| line, it would decrease the moat between it an other
| browsers.
| eviks wrote:
| Why do you need Chrom LTS to use "a separate stylesheet
| to support everyone."?
| JimDabell wrote:
| Security vulnerabilities are found in browsers.
|
| Browsers are updated to fix the security vulnerabilities.
|
| People upgrade to the latest version to get the security
| fixes.
|
| If a person is using a browser that is years out of date,
| they are subject to a lot of security vulnerabilities in a
| piece of software that is constantly exposed to untrusted
| code.
|
| Using an old browser is unsafe. If you encounter people
| using old browsers, you should strongly encourage them to
| do whatever they can to update their browser _for their own
| good_. If they do this, a nice side-effect is that you
| don't have to support their older browser version.
| eviks wrote:
| Yours is s PSA for updating browsers, but this doesn't
| explain breaking backwards compatibility since newer
| browsers with security updates don't break older CSS
| features.
| JimDabell wrote:
| > Nevertheless, I left a bit concerned that they hadn't
| updated their Chrome in 3 years. Software decays much
| quicker than hardware in a real way, especially with the
| never ending list of security vulnerabilities found every
| year. Theres definitely a case to be made that forcing
| software upgrades is good for the end user too.
|
| It seems very easy to understand the logic here. What
| part don't you grasp? Don't support older versions =>
| this pressures them to upgrade => upgrading is good for
| their security.
| PinguTS wrote:
| Sometimes you can't even update. I have an iPad that is
| perfectly fine for browsing. We use it mainly for TV
| purposes. It doesn't get any updates anymore.
|
| Now, some streaming services do not work anymore, because the
| website doesn't work. Why? There is no real technical reason
| for this. For some streaming services I have a collection of
| the real streaming URL. That still works fine. The problem is
| not the streaming itself, it's the website to choose the
| right stream.
| wruza wrote:
| That is reasonable though if a missing feature is trivially
| obvious must-have. Browsers (and standards, and platforms) that
| are slow to add it must develop themselves better. It's nice to
| respect compat if a new way is a redesign based on feedback,
| e.g. you used poll/select and now it's epoll/kqueue/iocp with a
| fallback. But if it is a feature that was simply missing for
| years, e.g. UIKit adding random useful methods which existed
| since forever in Cocoa, no respect. Really, you don't want to
| support a platform that takes years to wake up. Let their users
| know that it's obsolete, they will update.
| the_other wrote:
| In my team, we write software for TVs and set-top boxes, as
| well as modern browsers. TVs don't get the ipdate support we're
| used to on desktop and mobile. The same codebase has to support
| Safari 6-era webkit as well as contemporary Blink. We still
| can't use some of the flex spec let alone the new hotness.
| onion2k wrote:
| _" I can't use [feature X], I need to support [old browser]."_
|
| Any time someone says this it's important to add a caveat of
| "and I want my site to look the same everywhere". Using
| @supports means you can feature detect what CSS the user's
| browser supports and enhance where possible. A user with an
| older browser might see a less pretty, simpler design with
| somewhat worse UX, but that's often ok if it's a tiny minority
| and you can give the users on new browsers a much better
| experience. The two versions might look a bit different _but
| that 's fine_.
| spartanatreyu wrote:
| > Quick question: how many of these have you actively used in
| production?
|
| > Container Queries
|
| They aren't useful yet because:
|
| 1. Using them requires a wrapper element which can dirty up the
| HTML
|
| 2. While we were waiting for container queries to arrive, we also
| got new rules that made fluid layouts easier to implement which
| handle a chunk of container queries use cases.
|
| Container queries will become more useful when elements can query
| their own size, rather than their size inside a designated
| parent.
|
| > Style Queries
|
| A solution in search of a problem. Current selectors are
| acceptable for most current use cases. May be useful for
| customizable widget/dashboard style layouts.
|
| > CSS Layers
|
| Nice, but they currently place too many demands on the developer
| to understand what layers currently exist. These will become more
| useful as browser dev tools make debugging them easier to reduce
| the burden on the developer to keep the layers in their mind
| while coding/debugging.
|
| > Subgrid
|
| Very useful when you need things aligned, especially in things
| like card layouts. The only thing holding this back is developers
| who are too reliant on 3rd party framework/libraries, e.g.
| bootstrap developers relying on grid column classes and tailwind
| developers building things with margin/padding everywhere. This
| will take time for developers to shift to, but those developer
| who limit themselves inside their own framework/library bubbles
| may never use them.
|
| > Native Selector Nesting
|
| Very nice quality-of-life improvement.
|
| > Anchor Positioning
|
| Only supported by one browser. I have no idea why this was even
| in the article to begin with. But it will completely remove the
| need for some JS placement/layout logic that keeps getting
| reimplemented all the time with pop-ups (pave the desire paths
| and all that). It also has the potential to make margin notes
| easier.
|
| > :has, :is, :where
|
| :has is super powerful as a parent selector
|
| :where is great for simplifying repetitive css
|
| > Logical Properties
|
| If you maintain the discipline required to use these aliases over
| {top/left/down/right}, or if you have a linter to remind you, all
| of a sudden you're now able to support RTL languages without
| needing to spend time and money to make a different site for
| them.
|
| > Scroll-Linked Animations > View Transitions
|
| Both will be abused by marketers and "designers" who don't
| understand accessibility, but both will also greatly simplify
| micro-interactions on proper websites that aren't trying to be a
| "marketing experience".
| o11c wrote:
| :has isn't available in Firefox ESR (115) yet. The next ESR
| (128) will trickle out between July and October.
|
| @property (not mentioned) is only in Firefox Nightly; hopefully
| it makes it for 128 ...
| npn wrote:
| This is a bad article.
|
| > And while support for Container Queries is green in all modern
| browsers, people still seem reluctant to go all-in, fearing they
| could break something as fundamental as site layout in older
| browsers.
|
| Don't you know there are still a fuck ton of people that are
| still using the old iOS versions with their old phones? I have
| plenty of them, and they are long term supporters that I just
| can't shut them off.
|
| There are new css features that are almost harmless and do not
| affect the usability, some css features on the other hand...
| baggy_trough wrote:
| If you want to use nesting, for example, you will have to give up
| Windows < 10 and iOS < 17.2. It's a big ask for some sites.
| eviks wrote:
| why wouldn't this work?
|
| > You'd need a separate stylesheet to support everyone.
| yurishimo wrote:
| In theory it can, but when you work with 20 other devs all
| working on the same codebase, tracking those changes can
| become burdensome.
|
| Are we going to add an entirely new testing suite and
| workflow tools to save 5 lines of legacy CSS in favor of the
| new version? Probably not in a lot of teams.
|
| You also need to write and maintain code to conditionally
| load that fallback stylesheet and hope your users aren't
| using some weird user agent hacks (looking at you instagram
| in-app browser).
|
| All of these problems can be solved, but obviously nobody
| wants to because the juice is not worth the squeeze. This is
| not our first rodeo. I'm gonna wait another 18-24 months and
| then start using most of the features released this year.
| It's fine.
| JimDabell wrote:
| You don't.
|
| Safari has supported CSS nesting since v16.5. The specification
| was updated to remove the earlier requirement to use & though,
| and support for _that_ was introduced in v17.2. As long as you
| include the &, you can support everything back to v16.5.
|
| Not sure what you are referring to regarding Windows < 10, but
| Windows 10 was released nine years ago. Only a tiny fraction of
| web developers need to support decade-old clients.
|
| If you do need to support browsers that don't understand CSS
| nesting, use PostCSS or Lightning CSS. They will transcode your
| nested CSS to older syntax browsers support. Then, when you
| drop support and remove those browsers from your browserslist,
| they will stop transcoding it and the CSS you deploy will get
| smaller. But you'll have been writing standard nested CSS all
| along.
| baggy_trough wrote:
| If you want to use the normal non-& syntax, then you will
| need to use Safari 17.2, yes.
|
| I am referring to the fact that there are no browsers with
| native CSS nesting that support Windows < 10.
| InMice wrote:
| Whats the eloquent javascript or think python equivalent for css?
| is it mdn docs or another? Does anyone know the best active,
| comprehensive online references?
|
| How else do you really keep up on all the crazy new stuff
| sphars wrote:
| It may be ran by Google, but https://web.dev/ is one good
| source for keeping up with new web technologies
| chrisweekly wrote:
| Great Q!
|
| Pretty much everyone in the field knows about MDN
| (https://developer.mozilla.org/en-US/ )
|
| and https://web.dev
|
| and https://caniuse.com
|
| but the Interop project is newer and maybe flying under the
| radar:
|
| https://webkit.org/blog/14955/the-web-just-gets-better-with-...
|
| Enjoy!
| emmanueloga_ wrote:
| The state of CSS surveys [1].
|
| --
|
| 1: https://stateofcss.com/en-US
| bruce511 wrote:
| >> But take container queries, for example. They were the number
| one feature requested by front-end devs for a looong time. So why
| don't we use them more, now that they're finally here?
|
| A number of things are in play here.
|
| 1) when people ask for something it's because they need it _now_.
| The client wants it to look like x. Providing it a year later
| doesn 't mean I'll retro-fit it, I'm working for another client
| now.
|
| 2) the new features on offer are (mostly) not low-hanging fruit.
| 20 years ago we were asking for the basics - not-table layout
| (flex, grid), variables (var --), conditionals (@media) and so
| on. The low hanging fruit stuff. Now "most people" aren't really
| asking for anything. (The sliver of a minority attending css
| conferences naturally are dreaming up new edge cases.)
|
| 3) most of the websites that exist (aka have been styled) are
| older than these features. Since redesigns are typically multiple
| years apart it takes years for them to filter in. As a proportion
| the number of sites built, or updated, in the last year is small.
| And the proportion of those _needing_ these features is smaller.
|
| 4) most sites are not styled from an empty notepad. Most use
| (reuse) a framework - either personal or public.
|
| CSS is starting to move from mid-stage to late-stage development.
| We're well passed the "terrible to work with" stage, well passed
| the "good enough" stage, and now into the "what can we dream up
| stage".
|
| That said I can see myself using some of these things - sub-grid
| and :has being the obvious ones for me.
| atoav wrote:
| Yeah, I still remember a site where I really would have needed
| the :has selector, but I have written a workaround in JS and
| now I would rather so the whole thing new than fix that tiny
| aspect.
|
| I will however definitely rely on the has: selector next time I
| encounter that situation (it had to do with markdown output
| putting img tags inside paragraphs, so I needed css that treats
| a paragraph that _has_ a img inside differently than other
| paragraphs).
| noduerme wrote:
| Does :has function as a parent selector? That's probably the
| only thing I ever really wanted from CSS and I assumed it
| would never happen because of the (back propagating)
| implications for the order the DOM is rendered in.
| atoav wrote:
| Yes, because that was truly a gap in waht could be
| selected.
|
| Here is a blog post outlining what can be done using :has
| https://webkit.org/blog/13096/css-has-pseudo-class/
| Cyberdog wrote:
| Very good take. CSS is at a point of complexity now where you
| can't really blame anyone for not knowing everything you can do
| with it or every new feature that's been adopted in the last
| couple years, especially for full-stackers like me. I know a
| lot, including more than enough to get my job done, and though
| I will still learn new things now and then (I didn't know
| container queries existed before this article and now that I do
| I may use them in the future), I'm not in a hurry to learn
| every new bleeding-edge feature which are probably just going
| to cause compatibility issues for some non-insignificant number
| of my clients' browsers (or my clients' clients' browsers)
| anyway.
|
| Also, as someone who started doing web dev professionally
| nearly 20 years ago where if it didn't work in IE 6 then you
| just couldn't use it at all, I just instinctually don't even
| bother with new (as in 3-4 years old) CSS or JS features most
| of the time. It's pretty deeply ingrained in me and I suspect
| many other devs who were around in that time. That said,
| 5-year-old CSS and JS specs at this point are pretty damn good
| and you can do a whole lot of cool stuff with them, so this is
| not nearly as painful now as it was back then.
|
| Good enough is good enough.
| patates wrote:
| > I just instinctually don't even bother with new (as in 3-4
| years old) CSS or JS features most of the time. It's pretty
| deeply ingrained in me and I suspect many other devs who were
| around in that time.
|
| I'm also a web dev with nearly 20 years and do exactly this
| as well. Old versions (or any version of) IE crushed our
| dreams too many times to feel comfortable delivering anything
| modern, let alone cutting edge.
| lobsterthief wrote:
| Same here (>20 years at this point)--I just know how to do
| nearly everything with existing CSS features, or else I'm
| already using a framework like MUI that eliminates a lot of
| the issues the new CSS features aim to solve. For example,
| the unique class names and low specificity offered by MUI
| negates the need for the new container functionality.
|
| I've definitely used :has() though to replace the need for
| certain CSS combinators--for example, being able to style a
| label that wraps a checkbox based on the checkbox being
| checked, rather than relying on the next-sibling combinator
| while placing the label after the checkbox input. That's
| pretty cool and solves some limitations that existed
| previously.
| Chris_Newton wrote:
| As a developer of a similar vintage, I can relate to this
| mindset, but I think we should be careful about it. We
| learned in an era when differences in browser behaviour
| were a big deal and new versions of browsers sometimes came
| along years apart. But those days are long gone -- even
| Safari now gets several updates each year -- and we should
| let the habits they created go with them.
|
| Should we be cautious about relying on non-standard
| features or trusting the perma-beta culture that Google
| never seems to have grown out of? Of course. But there have
| been many recent developments that are useful and already
| widely supported, and not using those when they provide a
| good solution to an immediate problem seems
| counterproductive.
| CM30 wrote:
| Yeah, I think the first factor is probably the biggest one
| here. Devs tend not to rebuild existing sites on a whim,
| especially not to integrate new technology for the hell of it.
|
| We'll almost certainly see more container queries used on new
| website/app development projects going forward, but any that
| started prior to their integration into most browsers are
| likely going to remain using the old design philosophy with
| media queries instead.
| skolind wrote:
| Great article! CSS doesn't get enough attention - not outside of
| Tailwind, which I don't think is the way to go, but that's
| another story.
|
| :has() and :is() are awesome.
|
| One issue I've had with any of the newer CSS features is that,
| most of the people I work with don't know what they do, because
| nobody use them. So, I have to explain myself in each pull
| request - but I guess that's ok, because then people learn.
| michaelnny wrote:
| Agreed, I still prefer to write my own CSS than using tools
| like Tailwind.
| swagasaurus-rex wrote:
| For specific components, I use explicit CSS, but for layout
| <divs> I use the tailwind shorthand (flex, flex-row, mb-7)
| and just add those to my CSS as I go so I don't need tailwind
| as a dependency. It's the best of both worlds.
| sir_pepe wrote:
| The real problem in my experience is that people who consider
| themselves to be "real" developers don't care about CSS. I do a
| ton of code reviews and consulting for companies of all sizes and
| their JavaScript and TypeScript is almost always at least in a
| borderline defensible state? But CSS is always one giant file
| that has been growing since 2002 and is treated as an append-only
| log of !important. Nobody even tries to fix their CSS because
| nobody can imagine the concept of "well written CSS". It's like
| JavaScript in the early 2000s, where the language has (in the
| minds of developers) to be worked around with stuff like
| tailwind.
| graftak wrote:
| Css scoping has been fixed for ages already by css modules,
| styled components, or/and (native) support for nested css
| declarations. If those all fail there's namespace conventions
| like BEM.
|
| If your css is a mess in 2024 (2016 really) it is all on the
| developer and not the language.
| _heimdall wrote:
| Fixing scoping in userland, like with styled components or
| BEM, is definitely doable but not really the same as having
| native support for scoped styles in CSS.
|
| There's nothing wrong with those solutions and I've used
| those and similar plenty, but they are fragile. Those are
| conventions that have to be maintained and stuck with, and
| often for scoped style solutions you're also left with a hard
| dependency on a build step (BEM is an exception there). That
| may not be a problem at all, if you're using react you almost
| certainly already have a build _and_ bundle step, but not
| every project is that way.
| gonzo41 wrote:
| You are not wrong. But my god, the tech debt in any slightly
| older web app's CSS is bonkers. Even with really well thought
| out templates you still end up with ~5000 line css files that
| have all sorts of state and magic in them. And like all tech
| debt, it's a triage.
|
| What I'd really like is more intellisense for css so I could
| take a css file and get sensible code complete and class
| suggestions for elements.
| agos wrote:
| you raise a very important point: the tooling around CSS is
| nothing like we have everywhere else. you can get class
| completion with Tailwind or CSS Modules (which I prefer), but
| even basic stuff like CSS Variables or SASS mixins are a
| black hole
| 6510 wrote:
| Often I only use CSS if I have no choice. I really do try to
| fix it but I still cant imagine "well written CSS". I look at
| the 2000 lines of necessities and know some of it isn't even
| used and other things could be simpler. The process consumes
| lots of time without much to show for it or worse.
| lenkite wrote:
| CSS needs a compiler with warnings, dead-code removal, type
| safety, modularization, standard structuring and "design
| patterns" - then software engineers will take it seriously.
| _heimdall wrote:
| We do have tools for that though, how would a build tool fit
| into a language specification? Aren't those different
| concerns?
| andrecarini wrote:
| > Anchor Positioning
|
| Are there selectors for this anchor relationship? e.g. style
| anchored element when anchor is on :hover
| holoduke wrote:
| If one wants to replicate exact similar behavior in a webapp
| conpared to a native app we need the scroll/view animation to be
| available in all browsers. Right now animation is only possible
| with js and results in jittery animations.
| paavohtl wrote:
| The answer in my team's case is browser support and especially
| Safari on iOS. Our UI is quite complex and demanding regarding
| functionality, visual presentation and accessibility and would
| benefit greatly from most of these features, especially subgrid
| and container queries (and anchor positioning, but that feature
| doesn't exist outside of the latest version of Chrome).
|
| Even though MDN lists most of these features as "baseline"
| supported, the reality is that a small but still meaningful share
| of our users are using old iOS devices - especially iPads - and
| they can't or won't update their operating system to update
| Safari. Our oldest supported browser is Safari 14 because of
| Flexbox gap support.
|
| None of the other platforms are a problem, as basically everyone
| else is using an automatically updating evergreen browser.
| Unai wrote:
| I've read a few articles like this in the last few days and I
| don't understand why everyone is ignoring the elephant in the
| room. It's 2024 and Safari is still not evergreen.
|
| When people say Safari is the new Internet Explorer, replies
| always mention how Safari just adopted such and such bleeding
| edge CSS feature (while ignoring much older features, though),
| but the truth is many Apple users won't see those features for
| years, until their devices break.
|
| Apple is stopping both users and developers from enjoying these
| very same new features they so happily announce. The web is
| stuck in time, waiting for enough people to update their
| devices. Just like in the age of Internet Explorer. At least
| back then people had the option of installing a different
| browser. So maybe Safari and the apple ecosystem is actually
| worse than IE and Windows used to be.
| BeFlatXIII wrote:
| > but the truth is many Apple users won't see those features
| for years, until their devices break
|
| Yet another case of iPads being held back by their software.
| IIRC, iPads have slower replacement cycles than either
| iPhones or Macs.
| Flimm wrote:
| For me personally, it's because I've been burned too many times
| by blog posts announcing that "feature X is here!", when in
| reality, it's only here in Chrome or behind a feature flag, or
| the exciting parts haven't been implemented yet. Even this blog
| post falls into the same trap. There isn't good cross-browser
| support for view transitions or anchor positioning, and yet
| they're listed as here now.
| leephillips wrote:
| It does not fall into the trap:
|
| "Granted some things are relatively new, and others might be
| sort of niche-y."
| bramus wrote:
| View transitions are the perfect candidate progressive
| enhancement. If the browser supports it, then the user will get
| the rich animations. If it doesn't, then they get what they
| currently have.
|
| And once other browsers starts supporting it, the experience
| will automatically work in those browsers too without you
| needing to touch a single line of code :)
| 6510 wrote:
| I dunno sir, do you just assume everyone knows what these list
| items are? I would link them to their appropriate mdn article. I
| think non of the readers know everything about all of the items.
|
| This should be one of those articles one can click around in for
| considerable time.
|
| Having to select and search made me wonder at what point in time
| we lost the ability to click on the bullet to select the list
| item text? Does anyone remember that feature?
| tbm57 wrote:
| don't call me a monkey for not using a tool that I don't need,
| thank you!
| PaulStatezny wrote:
| Some comments here are framing CSS as getting too complex. Some
| folks are recommending the utility-class approach (e.g.
| Tailwind).
|
| I don't want to argue for Tailwind, but as someone who's used it
| for ~4 years now, it strikes me that I've _forgotten_ what it 's
| like to have to think about sets of CSS rules and how they
| collide.
|
| Utility class systems completely remove the need to even consider
| conflicting rules.
|
| That doesn't mean CSS shouldn't continue to grow though, and I
| welcome these new features.
| marcinreal wrote:
| I simply need wide support. I made some websites for a client who
| receives many 1. older customers and 2. customers from all over
| the world. I was conscious of the possibility that these
| customers could have either ancient devices or some highly
| obscure foreign devices not reflected on caniuse.com.
|
| Now, if your domain ends in .dev you can just assume that your
| users are up-to-date techies, but otherwise I avoid anything
| newer than flexbox (which is just so useful).
| sebazzz wrote:
| CSS layers are completely unintuitive to work with. I really
| don't see the use case for them. I hoped to isolate Telerik
| styling with it but it only made it harder to override styling.
___________________________________________________________________
(page generated 2024-05-27 23:02 UTC)