Live data from Hacker News

State of CSS

web.dev

171–180 of 234 posts

Re: State of CSS

#171
post #82
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.

Yes you can https://css-tricks.com/almanac/properties/a/aspect-ratio/

Experimental on Safari, so it's unusable of you have a real world project.

Re: State of CSS

#172

Just fyi: This is from May (and was posted a number of times then) What might be more interesting if it's your area is the currently running State of CSS Survey https://stateofcss.com

I only knew 13 of 54 (24%) which is a huge surprise, I've been writing CSS for 26 years. I guess I have fallen further behind on modern CSS than I thought. Seems like there's some other cool stuff to learn!

Re: State of CSS

#173
I'm using functional css approach and I cannot be more happy than ever. I even use most of the new features without having to even use SCSS.

Re: State of CSS

#174
I'd love to see something like constraint layouts in pure CSS. It's an incredibly powerful tool when building user interfaces.

I was really excited to see GSS (http://gss.github.io), however at the time it was far too slow to be usable in real projects.

Re: State of CSS

#175

Earlier quoted context omitted.

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…

> Idk how other people deal with that.

CSS handles it just fine. That's how they deal with it.

Re: State of CSS

#176
post #162

Earlier quoted context omitted.

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.

Then presuming you use Firefox, the only viable non-Chromium alternative that’s mature enough to fit your implicit preference, you’re surely aware there are a wide variety of things not supported in that browser too. If you’re inclined to look for patterns, you’ll find that quite a lot of them overlap with Safari—either for the same privacy-respecting reasons, or the same standards process-respecting reasons, or the same second implementation in the standardization process reasons.

It’s good that both browsers are a hindrance to Google just shipping stuff and that stuff becoming a de facto web standard. It’s even good that they have different priorities because that gives them different perspectives from which to catch mistakes before they’re almost totally irreversible.

Re: State of CSS

#177
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.

I like how you need a mac to test safari and how the ios animated address bar destroys any easy layout for applications.

They literally added new viewport units specifically to address variably sized browser UI.

I do agree you shouldn’t need to buy Apple hardware or pay anyone else money to test in their web browser though.

Re: State of CSS

#178
post #155

Earlier quoted context omitted.

Reading between the lines, it seems like you're suggesting Safari is that browser holding everyone back. The Compatibility section in this article doesn't seem to support that.

Ahhh, that's the version number. I thought that's how % of the spec that they actually supported.

No post body was provided.

Re: State of CSS

#179

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.

This is absolutely true in my experiences. I don't think I've genuinely met one Chrome user who hasn't beamed at the prospect of using Safari, yet in light discussions they seem to promote Google products extensively.

Re: State of CSS

#180
post #157

Earlier quoted context omitted.

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.

Yep, there are settings to show them in the devtools for both Chrome and Firefox. You can't access them with JS though, you can only see them in the devtools.
Post reply on HN