gist.github.com

2023_css_pain_points_freeform.txt

9/20/2023Updated 3/23/2026

Excerpt

| |100vh on mobile| |--|--| | |Accessibility: ads extra data aria labels for video description so it's possible to add alternative text not only below the video| | |Animate from display none to block and backwards| | |Animation rendering is slow for more involved animations| | |Animations| | |Animations| | |Architecture and maintenance ❤️| | |Been mainly using Tailwind CSS lately, which removes many of the pain points mentioned above. One pain point with that is to get other developers use it consistently and not come up with workarounds when something can be easily done with Tailwind alone. And maybe the issue of using only specific values from the config for spacing, font sizes etc. and not a ton of custom values, but that also requires a good design system and collaboration with designers.| | |Better table and selectbox native elements| | |CSS| | |CSS animations at SVG elements| | |CSS and web-components. Global styling should be accessible inside web-components| | |CSS has a confusing and all over the place api| | |CSS variable auto completion across modules/components/app| | |Can't have full-width <details> elements without messing up the marker position| | |Canvas for 2D games could be easier.| | |Centering a div| | |Clip-path styling such as shadow, border, Also class naming| | |Code Reuse / Composability ("calling" library "functions" (mixins?))| | |Common resources for learning CSS practices fixate on simple pages (e.g. landing pages, basic forms) and never get into complex pages as one might find in a CMS or content-heavy, interaction-heavy site.| | |Complexity — CSS is getting to big, too fast. What ever happened to the Extensible Web Manifesto?!| | |Container queries solves a lot, but as someone who works with CMS content, being able to adapt to content more easily is high up on the list of wants.| | |Contrast colors| | |Customising| | |Debugging tools| | |Default form/browser elements are ugly so the clients want to build their own all the time. I wish we could use the default ones more often, proper accessibility is complicated enough without us developers overwriting defaults.| | |Differences in Email Browser and still very low posibilites, very archaic part of this industry| | |Dire need of masonry layout, which is still not supported in every browser.| | |Drag and Drop styling of dragged object and drop zones| | |E-mails! Horrible!| | |Email client compatibility| | |Font loading| | |Font vertical centering by Cap height| | |Form Elements Styling, but using tailwindcss is easy| | |General re-usability of css which has caused all these libs and frameworks| | |I always use the same features of grid, and even if I have been using it for long time I still struggle with complex grid configurations.| | |I think is necessary increment the tables functionality| | |Image Scaling| | |Inconsistent historical naming conventions of properties/rules| | |Inline (style attribute) pseudo classes| | |Is a pain in the a#?... trying to build a responsive web page, and start to manage all the size posible instead of using variable like sm for mobile or md for tablets. It would be great if we have native media querys like boostrap| | |Isonla| | |Issues with -webkit-mask-image when used with transforms| | |It is difficult to compose components that use different css modules files. It is not possible to specify how you'd like nested styles to cascade for nested components.| | |It would be great if there was better support overall for complex native inputs that could be styled in detail.| | |It's a pain that creating a variable requires 2 characters '--' and when referring to it requires 6 'var(--' . It would be a lot simpler if creating and referring to a variable, could be done with just 1 character, for instance a dollar sign '$' .| | |It's very verbose and complicated| | |Javascript devs| | |Lack Doc. Lack of description of the layout rendering, not the individual properties.| | |Lack of advanced typography as in LaTeX| | |Lack of good tolling for CSS, compared to compile time checks as for typescript| | |Managing css files, and file organization is the biggest pain point for me.| | |Mobile Safari, No Infinite Scroll Snap| | |Native elements styling missing documentation| | |Parent styling. Adding styling to a parent based on hover on childeren.| | |Print Styling with paged media & generated content (page number in TOC)| | |Printing PDFs with Puppeteer| | |Professionally - Why do I have to ::ng-deep to be able to deal with an element I am pulling onto a page?| | |RTL styling when properties don’t have logical variants|

Source URL

https://gist.github.com/foolip/6e28f5465c971b2ebe017099bf131616

Related Pain Points

Email CSS compatibility remains archaic and extremely limited

7

Email client CSS support is antiquated with very few styling possibilities available. This creates a major disconnect from modern web CSS and requires developers to use outdated techniques.

compatibilityCSSEmail

Performance issues from DOM complexity and animations

6

Electron apps experience performance degradation from excessive DOM elements or animations. Overuse of animations increases CPU usage and makes apps feel sluggish, requiring developers to carefully optimize rendering strategies.

performanceElectronDOM

CSS file organization and management is poorly structured

6

Managing CSS files and file organization is cited as the biggest pain point for developers. Stylesheets often become giant, unmaintainable piles of spaghetti code without proper architectural patterns.

architectureCSS

Form element styling requires custom overrides, breaking accessibility

6

Default browser form elements are limited and aesthetically poor, forcing developers to build custom versions. This introduces accessibility complexity that is already difficult to manage without developers further overwriting defaults.

dxCSSHTML Forms

Overlooked accessibility requirements excluding disabled users

6

Developers fail to implement accessibility features like screen readers, voice commands, and high-contrast text, excluding people with disabilities from using the app. This is not just a nice-to-have but a critical requirement for inclusive design.

compatibilityFlutter

Debugging configuration and CSS specificity issues

5

Debugging Tailwind configuration issues is less intuitive than debugging CSS itself. Developers must examine parent element styles, specificity conflicts, and conditional classes to understand unexpected style overrides, making troubleshooting complex and time-consuming.

dxTailwind CSS

Grid layout complexity and configuration is difficult to master

5

Even after extensive use, developers struggle with complex grid configurations. Grid is powerful but unintuitive, requiring significant learning and trial-and-error to use effectively.

dxCSSCSS Grid

CSS lacks runtime error checking and compile-time validation

5

CSS lacks tooling comparable to TypeScript for catching errors at compile-time. There is no good static analysis, making typos and invalid properties undetectable until runtime.

testingCSSTypeScript

CSS styling of web components is isolated and not accessible globally

5

Global styles cannot be easily applied inside web components due to shadow DOM encapsulation, creating friction when trying to apply consistent design systems.

compatibilityCSSWeb Components

Custom CSS implementation in Tailwind projects negates framework benefits

5

Complex projects require custom CSS alongside Tailwind utilities and @apply overrides, creating a hybrid CSS architecture. This defeats the purpose of using Tailwind and introduces maintenance complexity from multiple paradigms coexisting.

architectureTailwind CSSCSS

Inconsistent and confusing CSS API design

4

CSS has a confusing, scattered API with inconsistent naming conventions across properties and rules, making it difficult to remember and predict behavior.

dxCSS

100vh on mobile behaves unexpectedly due to mobile browser UI

4

The 100vh unit does not account for mobile browser chrome (address bar, nav bars), causing layout overflow and poor mobile UX.

compatibilityCSS

Vendor-specific prefixes and browser inconsistencies

4

Developers must write browser-specific prefixes and hacks to handle inconsistent CSS rendering behavior across different browsers, particularly for advanced features.

compatibilityCSS

Speed of CSS language evolution outpaces developer adoption

3

CSS is evolving rapidly with new features introduced constantly, making it difficult for developers to keep up with learning curve and adoption timelines.

ecosystemCSS

CSS variable auto-completion across modules is missing

3

IDE tooling does not provide auto-completion for CSS variables across different modules, components, and applications, making variable discovery and reference difficult.

dxCSSCSS Custom Properties

Hard-to-remember CSS syntax

2

CSS has many features with complex or counter-intuitive syntax that developers struggle to remember, increasing cognitive load and requiring frequent reference checks.

dxCSS