csswg-drafts

ht-from-js, auto)` (CSS Variables (called CSS Custom Property[2]) with a fallback to `auto` when the variable is not defined) and later in JS I calculated the real width and height (using `getComputedStyle` or `getBoundingClientRect`) and just set `--width-from-js` and `--height-from-js` as inline style on the element. I also added event handler for the event that could change the size of this element (like browser window resize) and rerun this code to set updated CSS Property valaues. This way the changes required in JS were minimal, most of the things was in CSS. As a plus when one day browser would support animation to `auto` I would only have to delete the JS code. I need to write about this technique on this 3-pages stackoverflow question one day ;) Interesting observation was that when there was an animation in progress and the code for calculating the width of the element had run (because I resized the browser window) then the animation would just stop. I wouldn't mind if this was also the behavior if browsers would someday support animation of `width/height: auto` natively. [0]https://github.com/w3c/csswg-drafts/issues/626 [1]https://stackoverflow.com/questions/3508605/how-can-i-transi... [2]https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_c...

I preferred the brackets since it's explicit and some of the best wording is odd to me, but I think after considering my own `let rec` idea I prefer the optional `@nest` syntax because the only odd case which is relevant - and often enough that succinct but obvious syntax is warranted - is the child->parent->* case. That's the only time I'd want a heads up while visibly parsing css.

8 years[3]. It's barely been touched or worked on. It's a huge scary dangerous feature, that Apple has pushed, only recently. But you're right: I don't think Apple created it. I'm not sure where the suggestion came from; a Google editor wrote it initially but that doesn't mean it was their idea. I think it's misrepresentative to state this as a clear & surefire win. To keep score over a matter of months for a standard which is risky, in draft, and has been outstanding for 8 years seems like a high definition of petty scorekeeping. Trying to portray this like a real win is for-sure too-soon & risking bullshit. We don't even know that delivering it is going to actually be ok: it's still at risk, we might find it is as dangerous as Chrome said, csswg might remove it from the draft. [1] https://github.com/w3c/csswg-drafts/pull/4733 [2] https://groups.google.com/u/0/a/chromium.org/g/blink-dev/c/h... [3] https://github.com/w3c/csswg-drafts/commit/248f22c92839a6504...

ars aren’t required. So you’re trading one broken thing for another only-slightly-less-broken thing. In order to be properly useful in the presence of things like full-width elements with background colours or images or whatever, it needs to be able to be paired with env(safe-area-inset-*) (though hopefully with logical unit names) so that in the absence of a scrollbar you can opt into drawing in the space reserved for it.

rty link following is its primary use.)

er actually desirable. My observation is that places that use it are almost universally frustrating in some way. Browsers’ implementations are definitely getting better, so that the viewport units problem is almost all that’s left for this example, though accidentally swiping/scrolling past more than one slide is still a problem.