9 ms·
Things CSS could still use heading into 2023
- SigmundA 4y agoFull print/paged media support so Prince XML is no longer needed.
- mintaka5 4y ago[flagged]
- tannhaeuser 4y agoThe 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.
- christophilus 4y agoTaking 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.
- Joeri 4y agoI 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.
- pjmlp 4y agoDream 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.
- samwillis 4y agoThat'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)
- SirHound 4y agoWASM comes with no standard library which is bad enough for replacing JS but a killer for CSS.
- sergiomattei 4y agoIt’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.
- beardyw 4y agoFix styling on input range. Please.
- geewee 4y agoI'd settle for being able to style native selects properly
- 11235813213455 4y ago<option> allowing html so?
- geewee 4y agoI'm not exactly sure what you mean?
- kyriakos 4y ago<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.
- recrof 4y agodropdown menus are not stylable, that's the main problem.
- CM30 4y agoStill 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.
- rhn_mk1 4y agoAs an individual wanting stylistic consistency, I'd like for websites to leave my locally selected style the hell alone.
- eternityforest 4y agoI still really want native squircle borders.
- samwillis 4y agoThis 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.
- wbobeirne 4y agoClip-path gives you all the flexibility you could want, although not as convenient.
- webstrand 4y ago`clip-path: path(...)` not having relative units makes it basically useless for non-fixed size elements. And embedding an SVG into your html with a `<clipPath>` declaration is fragile and hackish.
- Waterluvian 4y agoI thought it was all about the round rect! https://www.folklore.org/StoryView.py?story=Round_Rects_Are_Everywhere.txt https://www.folklore.org/StoryView.py?story=Round_Rects_Are_...
- chrismorgan 4y agoRounded 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-designing-squircles-instead-rounded-rectangles/ https://99percentinvisible.org/article/circling-square-desig... shows the difference nicely if you (or any other reader) are unfamiliar with it.
- CM30 4y agoThere 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.
- perardi 4y agoSort of related… So, you’d like to animate the display property: https://css-tricks.com/so-youd-like-to-animate-the-display-property/ https://css-tricks.com/so-youd-like-to-animate-the-display-p...
- chearon 4y agoThe 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.
- kyleyeats 4y agoLove 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.
- Waterluvian 4y agoI 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?
- azangru 4y agoOf course. scrollbar-gutter: stable.
- Waterluvian 4y agoWell there’s my unexpected Christmas gift for the year. Thanks!
- dceddia 4y agoCool! 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
- azangru 4y agoIt's in the standard, so it'll come.
- azangru 4y agoDear Santa, 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.
- deleted 4y ago[deleted]
- chrismorgan 4y ago> 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.
- blowski 4y agoAssuming browser developers are not insane or incompetent psychopaths, why do you think they’ve done it this way?
- alberth 4y agocalc(100vw - (100vw - 100%)) Does above not work? https://stackoverflow.com/questions/33606565/is-it-possible-to-calculate-the-viewport-width-vw-without-scrollbar https://stackoverflow.com/questions/33606565/is-it-possible-...
- unvs 4y agoI 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.
- Someone1234 4y ago> 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?
- chrismorgan 4y ago> 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).
- asddubs 4y agoposition:device-fixed;! https://www.quirksmode.org/blog/archives/2010/12/the_fifth_posit.html 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.
- aliqot 4y agoI just want a responsive textarea instead of counting columns.
- andrei_says_ 4y agoMax-width: 100%; ought to work on text areas.
- di4na 4y agoOh 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.
- c-smile 4y agoJust in case Sciter supports mixins out of the box. @mixin button-alike { border:1px solid; border-radius; background:gold; } and its usage a.button { @button-alike; // mixin application point color:blue; } Parametric mixins are also supported: @mixin button-alike(back) { border:1px solid; border-radius; background:back; } and a.button { @button-alike(gold); // mixin application point with parameter color:blue; }
- deleted 4y ago[deleted]
- holoduke 4y agoI 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.
- plusminusplus 4y agoNesting (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
- willio58 4y agoFlowable regions would be amazing. Text placement edge cases would be mostly solved by this
- prox 4y agoIt’s kind of amazing that we are going into 2023 and this isn’t a thing yet. We need it yesterday!
- janitor61 4y agofont-size: [fit-width|fit-height|fit-container]; would be nice
- baggy_trough 4y agoSo many hacky font size adjustments over the years to keep some text from wrapping...
- agolio 4y ago> Ya know how a <textarea> is resizeable by default? Ah, yes, I knew that. (mind silently blown)
- c-smile 4y agoresizable <textarea> is generally quite a limited thing. It would be significantly more useful if we would have universal <frameset>: <frameset cols="200px,*> <select type="list">...</select> <textarea>...</textarea> </frameset> so to have split views. 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.
- danShumway 4y ago> 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 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.
- irrational 4y agoI want all of the good features of jquery baked into native css/JavaScript.
- namuol 4y agoAt 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.
- di4na 4y agoThis. 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...
- pbowyer 4y agoI can't wait for browsers to support https://developer.mozilla.org/en-US/docs/Web/CSS/margin-trim 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?
- dangoor 4y agoAm I the only person seeing JSON when I follow this link?
- throwaway743 4y agoText wrapping for SVG text without having to use foreignObject
- psygn89 4y agoI 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).