Things CSS could still use heading into 2023(chriscoyier.net)
chriscoyier.net
Things CSS could still use heading into 2023
https://chriscoyier.net/2022/12/21/things-css-could-still-use-heading-into-2023/
101 comments
> means overcoming infinite loops caused by edge cases
It doesn’t, really, if you instead just commit to reserving space for the scrollbars. And this indeed was how viewport units were initially specified a decade ago, and implemented in Firefox: write `html { overflow-y: scroll }` or similar, and vw is now actually what 100% of users want (seriously, there are exactly zero valid use cases for the current behaviour, it’s wrong every single time—just very occasionally useful despite its unknowable-in-pure-CSS rate of error). Unfortunately, no one else implemented it or was interested in doing so (even though this was the only hope of making viewport units correct for >99% of web pages—and remember this was before flex, too, so it was much more common to need correct viewport units) and they ended up ripping it out of the spec and Firefox a few years later.
And it looks like the only hope of ever getting sane viewport units is doing much the same once again, but more likely just with scrollbar-gutter this time. But having monitored relevant issues on the CSSWG bug tracker for years, I’m not holding my breath for any sort of fix. No, it’s pretty clear that no browser makers are much interested in fixing ancient design bugs in scroll bars that take space.
It doesn’t, really, if you instead just commit to reserving space for the scrollbars. And this indeed was how viewport units were initially specified a decade ago, and implemented in Firefox: write `html { overflow-y: scroll }` or similar, and vw is now actually what 100% of users want (seriously, there are exactly zero valid use cases for the current behaviour, it’s wrong every single time—just very occasionally useful despite its unknowable-in-pure-CSS rate of error). Unfortunately, no one else implemented it or was interested in doing so (even though this was the only hope of making viewport units correct for >99% of web pages—and remember this was before flex, too, so it was much more common to need correct viewport units) and they ended up ripping it out of the spec and Firefox a few years later.
And it looks like the only hope of ever getting sane viewport units is doing much the same once again, but more likely just with scrollbar-gutter this time. But having monitored relevant issues on the CSSWG bug tracker for years, I’m not holding my breath for any sort of fix. No, it’s pretty clear that no browser makers are much interested in fixing ancient design bugs in scroll bars that take space.
Assuming browser developers are not insane or incompetent psychopaths, why do you think they’ve done it this way?
> automatically subtract the scrollbar width
Santa: "That is simply impossible with the default scrollbar model".
You may have infinite loop in layout algorithm in cases when content is close to size of the viewport.
0) remove scrollbars
1) calculate VW;
2) do content layout;
3) if content exceeds viewport height, add v-scrollbar and goto 1 if it has not the scrollbar before;
4) if content does not exceed viewport height, remove v-scrollbar and goto 1 if it has it before;
The only option is to use scrollbars that do not take space: normally scrollbar appears as thin semitransparent bar on top of content. And on mouse hover the real scrollbar appears , but again on top of content.
Such scrollbars do not cause re-layout as you see and VW is a viewport width always.
That's why in Sciter(https://sciter.com) I've added
Santa: "That is simply impossible with the default scrollbar model".
You may have infinite loop in layout algorithm in cases when content is close to size of the viewport.
0) remove scrollbars
1) calculate VW;
2) do content layout;
3) if content exceeds viewport height, add v-scrollbar and goto 1 if it has not the scrollbar before;
4) if content does not exceed viewport height, remove v-scrollbar and goto 1 if it has it before;
The only option is to use scrollbars that do not take space: normally scrollbar appears as thin semitransparent bar on top of content. And on mouse hover the real scrollbar appears , but again on top of content.
Such scrollbars do not cause re-layout as you see and VW is a viewport width always.
That's why in Sciter(https://sciter.com) I've added
overflow:scroll-indicator;
Dear Santa,
Please consult the list of gifts you brought to us for Christmas before the last. You will find included in that list the scrollbar-gutter property. With scrollbar-gutter set to stable, you could safely skip steps 3 and 4 in your algorithm, thus avoiding the infinite loop. Would you please consider giving our wish a second thought?
Please consult the list of gifts you brought to us for Christmas before the last. You will find included in that list the scrollbar-gutter property. With scrollbar-gutter set to stable, you could safely skip steps 3 and 4 in your algorithm, thus avoiding the infinite loop. Would you please consider giving our wish a second thought?
Why do you need to waste screen space for the gutter?
Check your mobile devices that use such scroll indicators. We haven't heard any major complaints about them.
Check your mobile devices that use such scroll indicators. We haven't heard any major complaints about them.
Do the new large/small/dynamic viewport units satisfy that need? https://css-tricks.com/the-large-small-and-dynamic-viewports...
No, they address ui elements other than the scrollbars.
I don’t think that’s correct. I think VMIN solves the OP comment.
“Unit vmin refers to the smallest dimension of the viewport. Just like is the case with unit vw, unit vmin needs recalculation to subtract the scrollbar from the viewport width.
https://www.terluinwebdesign.nl/en/css/incoming-20-new-css-v...
“Unit vmin refers to the smallest dimension of the viewport. Just like is the case with unit vw, unit vmin needs recalculation to subtract the scrollbar from the viewport width.
https://www.terluinwebdesign.nl/en/css/incoming-20-new-css-v...
From the article on the new viewport units, from the web.dev site maintained by Google[0]:
"Caveats
There‘s a few caveats to know about Viewport Units:
- None of the viewport units take the size of scrollbars into account. On systems that have classic scrollbars enabled, an element sized to 100vw will therefore be a little bit too wide. This is as per specification."
Notice that although the example in the above paragraph uses the well-known vw unit, the text explicitly says "none of the viewport units".
[0] - https://web.dev/viewport-units/#caveats
"Caveats
There‘s a few caveats to know about Viewport Units:
- None of the viewport units take the size of scrollbars into account. On systems that have classic scrollbars enabled, an element sized to 100vw will therefore be a little bit too wide. This is as per specification."
Notice that although the example in the above paragraph uses the well-known vw unit, the text explicitly says "none of the viewport units".
[0] - https://web.dev/viewport-units/#caveats
scrollbar-gutter: stable
Seems like someone else in this thread might have solved this problem.
https://news.ycombinator.com/item?id=34116719
https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-g...
Seems like someone else in this thread might have solved this problem.
https://news.ycombinator.com/item?id=34116719
https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-g...
On the face of it, the only thing I'd worry about is if scrollbars appear/disappear, and if that would cause the elements using this new unit to get resized up/down.
Or to phase another way: If the scrollbar isn't currently rendered, is a hypothetical scrollbar still excluded or not? Since both ways you answer this question may make people unhappy.
Or to phase another way: If the scrollbar isn't currently rendered, is a hypothetical scrollbar still excluded or not? Since both ways you answer this question may make people unhappy.
The most common problem that I see is that people (almost always writing their CSS on a Mac, because Macs, by default, would hide the consequences of this) assign a width of 100vw to their header, footer, or main section, as a result of which, the moment that the page content's height exceeds the viewport height, the page will show not just a vertical scrollbar, but a horizontal scrollbar as well, because now 100vw is greater than 100% of body width.
The above is easily fixed; however, I have also seen designs like this one [0], where a team has painted itself into a corner by assigning max-width to the body element; yet also wanting to have hero elements inside of the body element that would break out of the confines of the body and span the whole width of the viewport. They tried to use 100vw for the hero, which resulted in the infamous horizontal scrollbar.
(I have since learnt — from Josh Comeau, I think — that their design problem could have been cleanly solved by designing the layout with CSS grid)
[0] - https://i.imgur.com/LNyJIAq.png
The above is easily fixed; however, I have also seen designs like this one [0], where a team has painted itself into a corner by assigning max-width to the body element; yet also wanting to have hero elements inside of the body element that would break out of the confines of the body and span the whole width of the viewport. They tried to use 100vw for the hero, which resulted in the infamous horizontal scrollbar.
(I have since learnt — from Josh Comeau, I think — that their design problem could have been cleanly solved by designing the layout with CSS grid)
[0] - https://i.imgur.com/LNyJIAq.png
[deleted]
calc(100vw - (100vw - 100%))
Does above not work?
https://stackoverflow.com/questions/33606565/is-it-possible-...
Does above not work?
https://stackoverflow.com/questions/33606565/is-it-possible-...
No:
(a) it only works on elements whose parents are the full viewport width, such as the body (simplifying the rules a little—there’s much finer nuance to the interpretation of percentages), and most of the places you might want viewport units aren’t suitable; and
(b) that’s literally just a longwinded way of writing “100%”, because mathematics.
(a) it only works on elements whose parents are the full viewport width, such as the body (simplifying the rules a little—there’s much finer nuance to the interpretation of percentages), and most of the places you might want viewport units aren’t suitable; and
(b) that’s literally just a longwinded way of writing “100%”, because mathematics.
As a comment on that answer points out,
100vw - (100vw - 100%) = 100vw - 100vw + 100% = 100%
100vw - (100vw - 100%) = 100vw - 100vw + 100% = 100%
There are definitely some good examples here. The fact that this:
> Animate to Auto
Still isn't possible with vanilla CSS in 2022 just boggles the mind, especially given jQuery managed to get it working decades earlier.
Similarly, why can't we have different visible and scroll/auto values for overflow? Like, this feels like the weirdest limitation to be stuck with decades later:
> The computed values of ‘overflow-x’ and ‘overflow-y’ are the same as their specified values, except that some combinations with ‘visible’ are not possible: if one is specified as ‘visible’ and the other is ‘scroll’ or ‘auto’, then ‘visible’ is set to ‘auto’. The computed value of ‘overflow’ is equal to the computed value of ‘overflow-x’ if ‘overflow-y’ is the same; otherwise it is the pair of computed values of ‘overflow-x’ and ‘overflow-y’.
Such utterly bizarre design choices that don't take designer/developer expectations into account at all.
> Animate to Auto
Still isn't possible with vanilla CSS in 2022 just boggles the mind, especially given jQuery managed to get it working decades earlier.
Similarly, why can't we have different visible and scroll/auto values for overflow? Like, this feels like the weirdest limitation to be stuck with decades later:
> The computed values of ‘overflow-x’ and ‘overflow-y’ are the same as their specified values, except that some combinations with ‘visible’ are not possible: if one is specified as ‘visible’ and the other is ‘scroll’ or ‘auto’, then ‘visible’ is set to ‘auto’. The computed value of ‘overflow’ is equal to the computed value of ‘overflow-x’ if ‘overflow-y’ is the same; otherwise it is the pair of computed values of ‘overflow-x’ and ‘overflow-y’.
Such utterly bizarre design choices that don't take designer/developer expectations into account at all.
Sort of related…
So, you’d like to animate the display property: https://css-tricks.com/so-youd-like-to-animate-the-display-p...
So, you’d like to animate the display property: https://css-tricks.com/so-youd-like-to-animate-the-display-p...
The browser doesn't know what the auto size is any more than you do until it performs a layout (reflow). Layouts are expensive and must be minimized. And what if content is changed in the middle of the transition? Should it recalculate the new auto size? Maybe we will get it some day, but there are good reasons to be cautious.
I'd go as far as saying layout properties like `height` and `font-size` shouldn't even be animated. If you pay attention to animations on macOS or iOS, the animations are performed on post-layout pixels: scaling and translating. That gets you very smooth FPS and isn't thrashing the CPU.
I'd go as far as saying layout properties like `height` and `font-size` shouldn't even be animated. If you pay attention to animations on macOS or iOS, the animations are performed on post-layout pixels: scaling and translating. That gets you very smooth FPS and isn't thrashing the CPU.
> Animate to Auto
Sciter supports animate to min/max-content. This
Sciter supports animate to min/max-content. This
div {
height:0;
overflow-y:hidden;
transition: height ease 300ms;
}
button:checked + div {
height:min-content;
}
<button|checkbox checked>Show/hide</button>
<div>
This is a summary
</div>
> And browsers are in principle capable of doing that too if they support animation in <summary>/<details>
Do any of them do this? On my iPad right now the MDN example (1) isn’t animating, and last time I checked Chrome didn’t either.
(1) https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de...
Do any of them do this? On my iPad right now the MDN example (1) isn’t animating, and last time I checked Chrome didn’t either.
(1) https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de...
Love this comment. In general I think developers shouldn't change the height of things, animation or no. If you're using vh then the page shouldn't have a scrollbar at all. You should only ever use it to fit your whole UI on one screen.
I actually can't imagine any other use for vh that isn't related to screenjacking (giving you a "full screen experience" mid-article) or scrolljacking (changing how the page scrolls). Parallax effects, maybe? I like the current limitations.
I actually can't imagine any other use for vh that isn't related to screenjacking (giving you a "full screen experience" mid-article) or scrolljacking (changing how the page scrolls). Parallax effects, maybe? I like the current limitations.
> I actually can't imagine any other use for vh that isn't related to screenjacking
Creating fixed panels on the left or right side of the viewport that are full height and sticky.
Creating fixed panels on the left or right side of the viewport that are full height and sticky.
But it's clearly the feature that people want and expect to be there. This is the most upvoted issue on CSS WG Github[0] and the StackOverflow question how to do it in CSS has 3 pages of answers (spoiler-alert: there is no nice way to do it only with CSS).
> The browser doesn't know what the auto size is any more than you do until it performs a layout (reflow). Layouts are expensive and must be minimized. And what if content is changed in the middle of the transition? Should it recalculate the new auto size? Maybe we will get it some day, but there are good reasons to be cautious.
Unfortunately these are good questions to answer and probably the reason browsers don't have it yet.
Last time I had to animate `width:auto` and `height:auto` I came up with quite a clever idea. I wrote `width: var(--width-from-js, auto)` and `height: var(--height-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...
> The browser doesn't know what the auto size is any more than you do until it performs a layout (reflow). Layouts are expensive and must be minimized. And what if content is changed in the middle of the transition? Should it recalculate the new auto size? Maybe we will get it some day, but there are good reasons to be cautious.
Unfortunately these are good questions to answer and probably the reason browsers don't have it yet.
Last time I had to animate `width:auto` and `height:auto` I came up with quite a clever idea. I wrote `width: var(--width-from-js, auto)` and `height: var(--height-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...
> Flowable Regions
Yes, yes, yes.
I actually didn't love Adobe's standard, and I thought some of the criticism of it was warranted. But the overall feature would be very nice to have. I'm just not sure exactly how it should be approached. ----
If I can be greedy, I know these aren't necessarily great features to add, but I would love:
- an (optionally) less performant text-justification algorithm: Justified text on the web is basically unusable today, I think because of performance concerns with reflowing containers. There are scenarios though where I would be very willing to pay a performance penalty to get nicely justified text, even if I had to like mark a container in CSS as unable to resize/reflow or something.
- CSS vertex shaders/custom filters: This is never going to happen as far as I can tell because of privacy concerns, and I have no idea how to get around those privacy concerns, and it's a feature I would almost certainly turn off in my own browser for most websites, but... I still want them.
----
Also I'm hoping that 2023 is potentially the year where I can start to feel safer about using container queries: https://caniuse.com/css-container-queries. I think once they hit mainline Firefox, Chrome/Safari/Firefox will be good enough support that I'll be comfortable including them at least in niche projects and just using progressive enhancement and a slightly uglier style as a fallback for other browsers.
Yes, yes, yes.
I actually didn't love Adobe's standard, and I thought some of the criticism of it was warranted. But the overall feature would be very nice to have. I'm just not sure exactly how it should be approached. ----
If I can be greedy, I know these aren't necessarily great features to add, but I would love:
- an (optionally) less performant text-justification algorithm: Justified text on the web is basically unusable today, I think because of performance concerns with reflowing containers. There are scenarios though where I would be very willing to pay a performance penalty to get nicely justified text, even if I had to like mark a container in CSS as unable to resize/reflow or something.
- CSS vertex shaders/custom filters: This is never going to happen as far as I can tell because of privacy concerns, and I have no idea how to get around those privacy concerns, and it's a feature I would almost certainly turn off in my own browser for most websites, but... I still want them.
----
Also I'm hoping that 2023 is potentially the year where I can start to feel safer about using container queries: https://caniuse.com/css-container-queries. I think once they hit mainline Firefox, Chrome/Safari/Firefox will be good enough support that I'll be comfortable including them at least in niche projects and just using progressive enhancement and a slightly uglier style as a fallback for other browsers.
The question is not what to add, but what to take away. But I guess this notion due to Antoine de Saint-Exupéry is lost on CSS heads which brings us into the territory of another quote attributed to Upton Sinclair: "it's difficult to get a man to understand something, when his salary depends upon his not understanding it."
By whom however I don't mean Chris Coyler even though his css-tricks.com when he was still running it certainly profited off CSS' let's say less-than-razor-sharp scope.
By whom however I don't mean Chris Coyler even though his css-tricks.com when he was still running it certainly profited off CSS' let's say less-than-razor-sharp scope.
Taking anything away breaks backwards compatibility, so that’s a problem. I agree, though, that this means we should be really hesitant to keep piling on features.
It’s different with CSS. It’s been so unreasonable and unergonomic for so many years, and for no reason whatsoever.
Today I’m using PostCSS to get over these problems, but I wish I didn’t have to.
Today I’m using PostCSS to get over these problems, but I wish I didn’t have to.
I feel like wasm is the way out of that. Keep the legacy standards but move them to an open source wasm implementation that’s shared by all the browsers. This way making a new browser could be done without dealing with the mass of legacy and we might see the chromium monoculture broken.
That's literally the opposite of what WASM is good for.
The browser platform is incredible because it doesn't break backward comparability, and has a very wide set of features to allow you to do 90% of what you want, but at an (occasional) cost of performance for the 1% of cases. WASM is there for that 1%.
Figma is a good example, JS+SVG+Canvas+DOM would be too slow for their use case so they built a WASM renderer. But that renderer is limited in functionality to exactly what they need, that is where they gain there performance improvement. Not by being able to magically solve problems the browser devs haven't been able to. It just a case of having a simpler renderer.
That's where WASM shines (for rendering), allowing you to simplify to gain speed improvements.
It's exactly the same with using JS+Canvas for performance critical drawing where the DOM is too slow. Use a simpler toolkit.
Running a whole browser in WASM will always be slower, and doing what you suggest would just result in a single implementation "monoculture" anyway.
(On the monoculture comment, there isn't one, Safari is massive because of Apples block of other engines on iOS. Loose that block then there may well be a monoculture)
The browser platform is incredible because it doesn't break backward comparability, and has a very wide set of features to allow you to do 90% of what you want, but at an (occasional) cost of performance for the 1% of cases. WASM is there for that 1%.
Figma is a good example, JS+SVG+Canvas+DOM would be too slow for their use case so they built a WASM renderer. But that renderer is limited in functionality to exactly what they need, that is where they gain there performance improvement. Not by being able to magically solve problems the browser devs haven't been able to. It just a case of having a simpler renderer.
That's where WASM shines (for rendering), allowing you to simplify to gain speed improvements.
It's exactly the same with using JS+Canvas for performance critical drawing where the DOM is too slow. Use a simpler toolkit.
Running a whole browser in WASM will always be slower, and doing what you suggest would just result in a single implementation "monoculture" anyway.
(On the monoculture comment, there isn't one, Safari is massive because of Apples block of other engines on iOS. Loose that block then there may well be a monoculture)
Dream on, WASM still hasn't a solid story for a GC after all these years, multi-threading isn't a given across all workloads, any new browser that doesn't run existing Web is worthless for the majority of consumers.
Everyone that helped Chrome and Electron apps to be widespread, don't have anyone but themselves to thank for.
Everyone that helped Chrome and Electron apps to be widespread, don't have anyone but themselves to thank for.
WASM comes with no standard library which is bad enough for replacing JS but a killer for CSS.
I'd settle for being able to style native selects properly
Still surprised (and disappointed) how limited the styling options for native form fields are in CSS. Select fields, checkboxes, radio buttons, sliders and calendar inputs should be just as easily stylable as plain old text boxes and buttons.
The fact they're not is probably hurting accessibility and usability a ton, since just about every individual and business wanting stylistic consistency is stuck reinventing the wheel with 'fake' versions or JavaScript.
The fact they're not is probably hurting accessibility and usability a ton, since just about every individual and business wanting stylistic consistency is stuck reinventing the wheel with 'fake' versions or JavaScript.
As an individual wanting stylistic consistency, I'd like for websites to leave my locally selected style the hell alone.
Since CSS has explicit support for your use case, then I assume you want CSS to add support for styling native widgets.
Or are you trying to keep the status quo, where people hack some shit out of divs that you can't change the appearance?
Or are you trying to keep the status quo, where people hack some shit out of divs that you can't change the appearance?
If it was up to me, I'd add the ability for the browser to ignore all styling of form elements which doesn't come from the native widgets.
You mean greasemonkey?
I believe firefox got this natively after greasemonkey died, but I never looked how to do it.
I believe firefox got this natively after greasemonkey died, but I never looked how to do it.
But alas, highly paid graphic designers that are hired by executives do not like your locally selected style and insist that it does not fit with their "corporate branding".
CSS Relativity?
Again, just in case...
In Sciter, all input elements are ordinary styleable primitive DOM elements. <select> is there too so you can style it in the way you want:
This for example is a table that behaves as a <select type="list"> with rows-options:
In Sciter, all input elements are ordinary styleable primitive DOM elements. <select> is there too so you can style it in the way you want:
select {...}
select > caption {...}
select > button {...}
select > popup {...}
select > popup > option {...}
This for example is a table that behaves as a <select type="list"> with rows-options:
<table>
<tbody style="behavior:select-list; overflow-y:auto;">
<tr role="option" value="A"><td><td></tr>
<tr role="option" value="B"><td><td></tr>
</tbody>
</table>I think https://open-ui.org/ is trying to make this happen for a lot of unstyleable native elements.
What's the issue with bog standard selects? Is it purely aesthetics, or are there accessibility problems?
Accessibility wise the default select/option is fine, because it does so little it is easy to reason about.
Calling the problem "aesthetics" though is too narrow. There are numerous things people would like to see in a native select:
- Optional search/filtering of options (without the need for an input field and JavaScript wiring).
- Being able to style.
- HTML in an option for example multi-line options.
Calling the problem "aesthetics" though is too narrow. There are numerous things people would like to see in a native select:
- Optional search/filtering of options (without the need for an input field and JavaScript wiring).
- Being able to style.
- HTML in an option for example multi-line options.
<option> allowing html so?
dropdown menus are not stylable, that's the main problem.
I'm not exactly sure what you mean?
<option> element doesn't allow styled HTML content as a dropdown option. This has led into hundreds of non native / js based Select Dropdown implementations to overcome this. Not a bad thing but at the same time native controls are always better and gurranteed to work everywhere especially on mobile.
I just want a reasonable way to show scroll bars without completely shifting the layout.
Is there a way to reserve the scroll bar space but only show it on auto?
Is there a way to reserve the scroll bar space but only show it on auto?
Of course. scrollbar-gutter: stable.
Cool! I was hoping it was one of those hidden gems that’s been there all along, but unfortunately doesn’t work in Safari.
https://caniuse.com/mdn-css_properties_scrollbar-gutter
https://caniuse.com/mdn-css_properties_scrollbar-gutter
It's in the standard, so it'll come.
Well there’s my unexpected Christmas gift for the year. Thanks!
position:device-fixed;!
https://www.quirksmode.org/blog/archives/2010/12/the_fifth_p...
Basically a version of position:fixed that doesn't get zoomed in on when zooming the rest of the page on mobile, so it's always actually visible. would be hugely useful for making bottom/top menus like apps have, without having to re-implement zooming in javascript.
https://www.quirksmode.org/blog/archives/2010/12/the_fifth_p...
Basically a version of position:fixed that doesn't get zoomed in on when zooming the rest of the page on mobile, so it's always actually visible. would be hugely useful for making bottom/top menus like apps have, without having to re-implement zooming in javascript.
Am I the only person seeing JSON when I follow this link?
https://archive.today/2GhX3 may work better.
Me too.
At this point I’m pretty sure we’ll have AGI and commercial fusion power before we get Mixins in CSS.
Edit: I’m very happy with the last decade of progress in CSS at the feature level, but at the language level I get the sense that there’s a fundamental disconnect with web developers.
Edit: I’m very happy with the last decade of progress in CSS at the feature level, but at the language level I get the sense that there’s a fundamental disconnect with web developers.
This. Tbf i think this is a generic problem in the frontend tooling side.
The build tools documentation and DX all seems built with the idea your html come from js or as static assets too. When in reality it is probably handled by a server side framework like Laravel, Django, Rails, Phoenix, etc
I stopped having hopes on mixins. Now i just try to make a product successful enough that i can fund someone or a team to work on the problem in a decade. It feels like the most probable solution.
And that is not a high probability of success...
The build tools documentation and DX all seems built with the idea your html come from js or as static assets too. When in reality it is probably handled by a server side framework like Laravel, Django, Rails, Phoenix, etc
I stopped having hopes on mixins. Now i just try to make a product successful enough that i can fund someone or a team to work on the problem in a decade. It feels like the most probable solution.
And that is not a high probability of success...
Oh thank you so much for putting the mixins in this.
It would be the most massive DX positive change to CSS. It had been on my want list for years.
But it seems all the momentum went into shadow DOM and we stopped talking about it.
"All" we need in theory is someone willing to take the mantle and shepherd it. There is previous work on it from the `@apply` experiment that could be leveraged. In theory it should not be too hard.
But noone has the time in the people that want it it seems.
It would be the most massive DX positive change to CSS. It had been on my want list for years.
But it seems all the momentum went into shadow DOM and we stopped talking about it.
"All" we need in theory is someone willing to take the mantle and shepherd it. There is previous work on it from the `@apply` experiment that could be leveraged. In theory it should not be too hard.
But noone has the time in the people that want it it seems.
Just in case Sciter supports mixins out of the box.
@mixin button-alike {
border:1px solid;
border-radius;
background:gold;
}
a.button {
@button-alike; // mixin application point
color:blue;
}
@mixin button-alike(back) {
border:1px solid;
border-radius;
background:back;
}
a.button {
@button-alike(gold); // mixin application point with parameter
color:blue;
}Lot of stuff support it, but this is not really the same DX as... Just supporting it in browsers. Especially for debugging
> Lot of stuff support it,
@mixins are built-in in Sciter and I don't know any other HTML/CSS UA that supports that.
@mixins are built-in in Sciter and I don't know any other HTML/CSS UA that supports that.
Tailwind has `@apply` from postcss
Sciter is an embeddable HTML/CSS engine (like a browser): https://sciter.com
And its CSS has @mixin built-in.
Right so a tool for something else. But great for them
> You can make anything resizeable so long as it’s not an inline element and it has overflow: hidden;.
Correction on the last part: so long as it’s not `overflow: visible`. Doesn’t need to be `overflow: hidden`, and indeed my experience is that you normally want `overflow: auto` on resizeable things.
Also “anything” is inaccurate: you mostly can’t use it with replaced elements like img/audio/video/iframe, though it varies by browser (e.g. my recollection is that resize works on iframe in Blink but not Gecko).
Correction on the last part: so long as it’s not `overflow: visible`. Doesn’t need to be `overflow: hidden`, and indeed my experience is that you normally want `overflow: auto` on resizeable things.
Also “anything” is inaccurate: you mostly can’t use it with replaced elements like img/audio/video/iframe, though it varies by browser (e.g. my recollection is that resize works on iframe in Blink but not Gecko).
I can't wait for browsers to support https://developer.mozilla.org/en-US/docs/Web/CSS/margin-trim. It's been 4 years since it was introduced into the spec and there's been little movement. Maybe 2023 will bring it to Chrome?
I wish CSS had a dynamic color property that will update the font color to white or black (or your choosing) depending on the background. For now I have to either calculate it with sass or js (when the users can change colors on the fly).
There's a spec proposal for precisely that. It's in Colour Level... 6, I believe? https://developer.mozilla.org/en-US/docs/Web/CSS/color_value...
Awesome! Thanks for letting me know.
Fix styling on input range. Please.
Nesting (like the `&` parent in Sass) is mentioned, for now there is a PostCSS plugin for it.
https://github.com/postcss/postcss-nested
https://github.com/postcss/postcss-nested
I still really want native squircle borders.
This so much! I'm surprised that Apple haven't implemented it in Safari so they can use them to match their style elsewhere.
I'm not sure what the spec should be though, maybe bezier curve corners. That would allow asymmetry with "setback" and "control-length" for each side of the corner.
I'm not sure what the spec should be though, maybe bezier curve corners. That would allow asymmetry with "setback" and "control-length" for each side of the corner.
I thought it was all about the round rect!
https://www.folklore.org/StoryView.py?story=Round_Rects_Are_...
https://www.folklore.org/StoryView.py?story=Round_Rects_Are_...
Rounded rectangles are easy to manufacture, but ugly due to their tangency. For best results, you want to smooth the curvature—whether in the form of squircles, or something a bit more locally-constrained. https://99percentinvisible.org/article/circling-square-desig... shows the difference nicely if you (or any other reader) are unfamiliar with it.
I would like to have sticky elements on non parents. Very handy when you want to replicate android tab and header collapse functionality. Currently only possible with scroll listeners who are too slow and always show slight hickups.
I just want either a zoom constant so we can know how much the browser is zoomed in or out, or a scaling type size unit that will take zoom into account. In the former case we could set font size as vw multiplied with the zoom factor.
> I just want either a zoom constant so we can know how much the browser is zoomed in or out
So that zooming in on websites has unexpected side effects like some elements ignoring the zoom and staying the same size?
When users zoom they want everything to maintain the same proportions but be larger on their display, but web developers in their infinite wisdom want to do clever stuff when a user zooms so that isn't their experience.
What is a non-abusive use case for this?
So that zooming in on websites has unexpected side effects like some elements ignoring the zoom and staying the same size?
When users zoom they want everything to maintain the same proportions but be larger on their display, but web developers in their infinite wisdom want to do clever stuff when a user zooms so that isn't their experience.
What is a non-abusive use case for this?
I want all of the good features of jquery baked into native css/JavaScript.
Full print/paged media support so Prince XML is no longer needed.
> Ya know how a <textarea> is resizeable by default?
Ah, yes, I knew that.
(mind silently blown)
Ah, yes, I knew that.
(mind silently blown)
resizable <textarea> is generally quite a limited thing.
It would be significantly more useful if we would have universal <frameset>:
Resizable textareas are quite trivial to implement with barebone JS but such split views require native support from browsers in order resizing to work effectively.
It would be significantly more useful if we would have universal <frameset>:
<frameset cols="200px,*>
<select type="list">...</select>
<textarea>...</textarea>
</frameset>
Resizable textareas are quite trivial to implement with barebone JS but such split views require native support from browsers in order resizing to work effectively.
Text wrapping for SVG text without having to use foreignObject
font-size: [fit-width|fit-height|fit-container]; would be nice
So many hacky font size adjustments over the years to keep some text from wrapping...
I just want a responsive textarea instead of counting columns.
Max-width: 100%; ought to work on text areas.
[deleted]
I would like to have CSS units of viewport size that automatically subtract the scrollbar width. A cross between 100% (which discounts scrollbars but is unaware of viewport) and 100vw (which is aware of the viewport but does not exclude scrollbars). I understand that such a unit of measurement means overcoming infinite loops caused by edge cases. This is where your elves come in.