Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

State of CSS

web.dev

Post reply on HN
Print view View original

161–170 of 234 posts

Re: State of CSS

#161

Post by clairity »

easrng wrote: post #157
clairity wrote: post #69

Earlier quoted context omitted.

i believe the problem with form elements like checkboxes is that they are 'replaced elements', which the browser defers to the underlying operating system, and that's why it requires a "hack" like accent-color rather than direct styling. this is also why you can't use ::before and ::after on form elements (to do things like add a 'required' indicator using css only).

IIRC they used to, but not anymore. They're implemented with a special Shadow DOM that's not accessible by the page but you can style some elements if the browser exposes them as psuedoelements.

are OG form elements actually reimplemented in shadow DOM, like they're doing with open UI (https://open-ui.org/) custom elements?

i've seen safari and chrome (but not firefox) expose some form input components as shadow DOM (e.g., slots), but wasn't sure if it was actually reimplemented.

Re: State of CSS

#162

Post by soperj »

azemetre wrote: post #156
dmitriid wrote: post #146

Earlier quoted context omitted.

When it comes to CSS Safari is rarely behind, and often ahead. When it comes to Chrome-only non-standards Safari is right where it needs to be: not implementing this bullshit.

Thank you for calling this out. I feel like there is a psyops campaign paid for by Google denouncing any organization/tech that doesn't blindly follow their non-standard standards.

I don't even use chrome, nor do I develop against it.

Re: State of CSS

#163

Post by hot_gril »

dmitriid wrote: post #146
soperj wrote: post #143

Earlier quoted context omitted.

It's so annoying to me that there's one browser that's holding everyone back. They also make it so that no one can use anything but their browser engine on mobile phones so they're harder to ignore.

When it comes to CSS Safari is rarely behind, and often ahead. When it comes to Chrome-only non-standards Safari is right where it needs to be: not implementing this bullshit.

I mostly agree, but mobile Safari seems intentionally behind on PWAs, and I do blame Apple's obvious conflict of interest with the App Store. Biggest thing is lack of support for notifications, though supposedly that's finally changing after years: https://www.searchenginejournal.com/web-push-coming-to-ios/4...

Re: State of CSS

#164

Post by hot_gril »

reaperducer wrote: post #49
toastercat wrote: post #2

Great overview. I'm always excited by newer features to CSS that make older JS-only methods obsolete. I've also grown CSS-tooling fatigued after using SASS and PostCSS plugins for years. I've recently gone back to only using vanilla CSS on personal projects and while there are niceties I do miss (nesting) it's refreshing not having to deal with config files or waiting for stuff to compile.

I'm always excited by newer features to CSS that make older JS-only methods obsolete. I wonder if it's just about how some people's brains are wired. I grok CSS. I won't claim to know everything about it, but I'd say I'm 90% proficient and prefer it to JavaScript. But I think this is because JavaScript somehow never fully made sense to me. I can read it and figure out what it's doing, but it was never intuitive to me…

I don't understand either one. I use React (while technically pure JS, I assume this isn't what you mean) and calculate most of the sizes manually, just passing width and height as props into my elements. People tell me that's dumb, but it's always worked, and I don't have to keep up with this topic of CSS that doesn't really interest me. I've tried the "correct" flexbox way too, and it wasn't easier.

One particular thing about CSS... seems to never behave in any kind of auto-sizing container the same way a regular div would; it seems to need pixel dimensions to work as expected in all scenarios, especially when things are resizing dynamically. Idk how other people deal with that. That alone was my motivation for trying things my own way.

I did something similar developing an app long ago for the iPhone 4. Calculated all my dimensions in C macros cause AutoLayout made no sense. Tons of apps using AutoLayout broke anyway when the new screen sizes came out, but my app was fine. "Math is math."

Re: State of CSS

#165

Post by dheera »

LukeLambert wrote: post #97
dheera wrote: post #76

Yet 15 years later, I still can't specify a width and aspect ratio for an div without some unintuitive nested div hell.

div { width: 640px; aspect-ratio: 16 / 9; }

> But with Chrome and Firefox supporting it behind an experimental flag

So basically not supported, and you have to go back to div hell.

There should be some future.js file that you can import to make all this stuff just work in older browsers.

Re: State of CSS

#166

Post by [deleted] »

lbotos wrote: post #3

Does anyone else feel like CSS has jumped the shark a bit? https://web.dev/state-of-css-2022/#accent-color Sure it's a "nice to have" but it bloats the spec? Look at the current actual implementation: https://web.dev/accent-color/#guaranteeing-contrast chrome and firefox already tint differently... How is this better than a good ol CSS variable and leaving it up to the designer to manage? Sure http://dowebsitesneedto…

[deleted]

Re: State of CSS

#167

Post by hot_gril »

jjcm wrote: post #78

Interesting to see a lot of negative responses here. I'm quite excited for a large amount of these items. @container queries are going to help a ton in making components more reusable - components that react to their own size rather than the browser size have been needed for a long time, and currently the only way to really do it is with the javascript observer api, which comes with huge performance tradeoffs. Color-…

Well the amount of lag my max-spec 2019 MBP incurred loading that webpage didn't bode well.

Re: State of CSS

#168

Post by cageface »

purplerabbit wrote: post #130
toastercat wrote: post #2

Great overview. I'm always excited by newer features to CSS that make older JS-only methods obsolete. I've also grown CSS-tooling fatigued after using SASS and PostCSS plugins for years. I've recently gone back to only using vanilla CSS on personal projects and while there are niceties I do miss (nesting) it's refreshing not having to deal with config files or waiting for stuff to compile.

Serious question: how do you refactor code when using nesting? In my experience it makes styles impossible to audit.

Also not a fan of nesting. It makes it way to easy to create unmaintainable CSS spaghetti.

Re: State of CSS

#169

Post by alpaca128 »

reaperducer wrote: post #49
toastercat wrote: post #2

Great overview. I'm always excited by newer features to CSS that make older JS-only methods obsolete. I've also grown CSS-tooling fatigued after using SASS and PostCSS plugins for years. I've recently gone back to only using vanilla CSS on personal projects and while there are niceties I do miss (nesting) it's refreshing not having to deal with config files or waiting for stuff to compile.

I'm always excited by newer features to CSS that make older JS-only methods obsolete. I wonder if it's just about how some people's brains are wired. I grok CSS. I won't claim to know everything about it, but I'd say I'm 90% proficient and prefer it to JavaScript. But I think this is because JavaScript somehow never fully made sense to me. I can read it and figure out what it's doing, but it was never intuitive to me…

Meanwhile for me CSS is like the MS Word memes. Things that worked just break one day, certain options make other seemingly compatible options do nothing, and some settings just don't do what you'd guess from their name.

Almost everything can be made to look correctly but somehow the right solution is the last one I'd ever think of.

Re: State of CSS

#170

Post by asiachick »

nicoburns wrote: post #133
asiachick wrote: post #120

Earlier quoted context omitted.

IIRC the way someone reimplemented flexbox was to take the layout tests and iterate until their implementation passed. https://yogalayout.com/

Yes, but the fact that someone had to do this makes it clear that the spec isn't complete. A complete spec would state the algorithm unambiguously. You might still need to fix bugs based on tests, but you shouldn't need to be working about behaviour because it's unspecified.

Not my experience at all. It doesn't matter how well written a spec is. No tests = no conformance. End of story. Most people can't hold an entire spec in their head or think through all the ramifications of the edge cases. Even the spec writers. I work on several specs. I work with people who work on specs. They're all mortal. No test = divergence. Always and without fail.
Post reply on HN