CSS being made to do yet another thing web browsers have no reason to provide:

https://codepen.io/NochEinKamel/...

CSS is awesome

When will it replace JavaScript?

And what is this thing you're referring to that browsers have no reason to provide? All I see there is styling.

@nitnip CSS for loop I guess?
Nvm it's a scss feature so the post doesn't make sense

@nitnip @devRancid why is a web browser forced to provide an algorithm for calculating the visible part of circularly layered 3D shapes? Why does a web browser have a 3D renderer at all? The most complicated layering a standard-compliant browser should be required to do is expliclty specified or trivially inferred draw order between fully rendered shapes.

CSS isn't a tool that is improved by new features. It's a standard, and every additional feature puts maintenance burden on browser devs and makes the creation of independent browsers ever more impossible.

There's no fancy 3D algorithm or circle logic

css provides simple things like z-index and transform. up to you what you do with it

Even with 2 regular overlapping elements the second one gets drawn above the first one

@devRancid Are you using Safari? Some people using Safari reported that it isn't working for them. The page contains a full circle of cards mutually overlapping each other in a way that is impossible to express with z-index

@lorentz So you have a bone to pick with "transform-style: preserve-3d". There are zero 3d shapes rendered there. This is just creative positioning. You could have found plenty of other examples on codepen. Sorry this just read like a thinly veiled "why is CSS so hard?" rant.

@nitnip Perspective isn't the hard part in 3D with flat surfaces, that's just a matrix transform. I'm not actually against 3D transform. This property is disproportionately harder to implement than 3D transform. In the MDN page you can see a much better example of this that is even harder to handle in an implementation with an arbitrary intersection line:

https://developer.mozilla.org/en-US...

I think the browser market is basically Google.

This is the case because a new competitor would have to implement a prohibitive number of features that could totally be the application's burden such as this one

It is a problem because Google unilaterally decides whether a standard such as JPEG XL should exist.

This was the motivation for the rant.

The @for loop is SCSS not css.
#clickBait much?

@C0D4 I'm talking about `transform-style: preserve-3d`, but if you're gonna comment on a thread without reading it you could at least assume that either OP isn't an idiot or somebody already told them.

Think I used the preserve-3d attr maybe once or twice since it was included in CSS and that was for a hobby project with an isometric grid.

The other use case for fancy-schmancy CSS 3d-manipulations would be creative & animated landing pages where HTML Canvas or WebGL would be overkill or no-go for SEO.

Curious what's your take on CSS functions like attr() & calc()?

Broken in mobile safari ^^

I agree. Browsers do too much shit they shouldn’t do and not enough shit they should do.

@Lensflare It also breaks in a really strange way in Safari, like it doesn't reject the order or settle on an approximately correct Z-index, boxes that can't be reasoned into a simple rendering order just get discarded.

@lorentz when you overscroll to the bottom, the missing parts appear

CSS gets the most useless shit. But a parent selector, which would actually be useful... Nope.

@Oktokolo at this point, CSS is an all-purpose mess of ancient legacy stuff, slapped on modern additions, semi-implemented standards, mixed with vendor specific stuff, and it has an identity crisis and doesn’t actually know what it is.

Is it a styling language? A layout language? A programming language? It’s all of it. Kind of.

@Lensflare CSS has nothing that would make it look like intending to be a programming language. And at this point, it would be still hard to beat Postcript - which has user-defined functions but isn't a programming language either...

Also, doing style and layout in a single language makes perfect sense. Both are device specific. So if layout would have to be done by HTML only, it would need to copy the conditions - and you would end up having two different syntaxes and places for very similar things.

But i wished they would focus more on polishing the base of the language like more flexible selectors, the layout aspect (align on other elements, maybe defining invisible guides to align elements on) and less on ultra-specific graphics bling.

And yes: Float has to die in favor of more generic and flexible positioning and element-flow options.

Fucking CSS has @for now???

Edit: ah, it's just codepin being a cunt. It knows it's SCSS (has drop-down menu to show compiled css/ uncompiled SCSS) but the tab still shows as "CSS"

@Oktokolo about styling and layout in a single language:

I agree. It makes sense if the language is designed for it or is suited to implement DSLs.
CSS however is supposed to be a single purpose language, specifically focusing on style. And it’s very good in it. But it’s also a Frankenstein's monster with other things which don’t go well with its actual purpose of defining cascading styles. That’s my critique.

@Lensflare Sure, it is a chimera. But (as an example) moving the menu around and hiding it behind a hamburger icon on small viewports has to be described somewhere somehow. It certainly doesn't belong in the backend. And doing it in JavaScript is a bit unwieldy too. You certainly don't want yet another dynamic language - so augmenting HTML is probably not a good choice either. Having CSS being capable to do that stuff makes a lot of sense.

Maybe it's time for the maintainers of CSS to finally accept that it isn't just a styling language. Maybe HTML can then actually be purely about semantics. And maybe we could finally get alignment based on guides and edges of other elements that aren't neccessarily in the same semantic container.

@Oktokolo you just summarized my whole problem with the current state of web development. It involves using tools that are not well suited for the current kind of apps that we want. And to make it more convenient, those tools are being bent and abused beyond their limits.

The only way to really solve the problem is to invent something new, but we all know that it wont happen any time soon, for obvious reasons.

Just because there are no alternatives, doesn’t mean that we should just accept the current state as the best thing ever and refuse to look for innovation.

@Lensflare Nah, CSS would be a pretty fitting place for a full layouting tool set. Layouting is pretty declarative in nature and often depends on other content that isn't semantically related.

CSS is declarative and has a pretty versatile selectors already. They just need to stop half-assing the layouting part. Define layout as part of styling and add the missing features.

And no one actually wants to decide which aspect of a thing is strictly just styling or strictly just layouting anyways. The two meet in a very fuzzy area in the middle. Having a single language do both is the least confusing and most flexible way to do it.

Spread the meme: CSS is a layouting language!

@Oktokolo Can we start calling it CLaSS for Cascading Layouting and Style Sheets?

I actually think the worst vice of CSS is specificity, with only one bit of manual override. If you don't have the resources to build good tools for defining hierarchy manually, exposing the priority as a floating point number kinda works. That's what I'm doing with Orchid, initially. The shitty heuristic on its own just causes pain.

@lorentz Nah, styling and layouting are fuzzy terms anyways. Just define styling to include positioning and flow behavior and CSS keeps being a good name.

While specificity is sortof an issue - i always end up with at least one ultra-generic selector that looks like .disabled.disabled.disabled.disabled - it is a pretty minor one. Streight up not being abe to reference elements containing something is way worse.