[HN Gopher] You want enabling CSS selectors, not disabling ones
       ___________________________________________________________________
        
       You want enabling CSS selectors, not disabling ones
        
       Author : AryanBeezadhur
       Score  : 68 points
       Date   : 2021-08-31 21:21 UTC (1 hours ago)
        
 (HTM) web link (css-tricks.com)
 (TXT) w3m dump (css-tricks.com)
        
       | politician wrote:
       | Is there a language that compiles to CSS but excludes the decades
       | of cruft that have accumulated in CSS? Something that just
       | exposes a few key primitives and jettison's the rest even if that
       | means it doesn't handle some extreme edge cases?
        
       | jontro wrote:
       | I don't see why 0 should be treated as special value. Initial
       | should be used if meant to "disable" it.
       | 
       | What if you want margin: 5px as the general rule and margin: 10px
       | on the last element. Is 10px a disabling selector?
        
         | cerved wrote:
         | I believe that's exactly the point. You don't set all to 5px
         | and then override using a special rule that says 0px for the
         | last. You exclude the last element from the 5px rule.
         | 
         | There might be other rules, browser, user that should not over
         | the 5px rule
        
           | TimTheTinker wrote:
           | I disagree. If a 5px margin is the general rule, then I would
           | argue it's cleaner to apply it generally, and then apply the
           | 10px margin exceptions in separate rules.
           | 
           | - When special cases are added or removed, the general rule
           | won't have to be adjusted, just code that handles the special
           | cases.
           | 
           | - On the other hand, a single general rule that specifically
           | avoids application to multiple exceptional cases will be
           | pretty long and have multiple :not()s, thus reducing
           | readability and maintainability.
           | 
           | Why burden the general rule with knowledge of its exceptions?
           | To me, doing so is a (small) violation of the principle of
           | separation of concerns.
        
         | [deleted]
        
       | oleganza wrote:
       | This reminds of an idea in math that proofs by construction are
       | better than proofs by contradiction. Or making artificial
       | grammars (e.g. PLs) with recursive descent parsers instead of
       | context-sensitive grammars with Turing-complete parsers.
       | 
       | If you can build something step-by-step with a clear hierarchy
       | and easy to trace causes and effects, the result seems to be more
       | convincing/reliable than a process involving a bunch of logical
       | roundabouts. Of course, if that's at all possible for a problem
       | at hand.
        
       | poniko wrote:
       | yes but no .. seems like a weird rule that makes it harder to
       | understand and read. A flow of default, exception, exception is
       | easier to follow. And What if you have odd even, every third etc
       | etc ..
        
       | matthoiland wrote:
       | Interesting way to think - we use additive color (RGB) on web so
       | why not additive styling?
       | 
       | But in practice while creating interfaces, we're making broad
       | brush strokes, then accommodating exceptions, like :last-child.
       | 
       | Also curious about how browsers prioritize the render stages -
       | does every style get applied sequentially (hence cascading), or
       | do pseudo selectors get applied later during the paint?
        
         | andrewmcwatters wrote:
         | Style calculations are typically done before rendering.
        
       | dvaun wrote:
       | I found the linked article "Axiomatic CSS and Lobotomized Owls"
       | to be a decent read. I'm surprised that it hasn't been highly
       | upvoted in the past despite having many submissions to HN.
       | 
       | Article: https://alistapart.com/article/axiomatic-css-and-
       | lobotomized...
       | 
       | Prev. submissions:
       | https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
        
       | bob229 wrote:
       | Stating the obvious much
        
       | kebman wrote:
       | I had a sore throat, so I made an "In A World" reading of this
       | web page.
        
       | math-dev wrote:
       | I wrote (what I hope) is a great read to CSS selectors, check it
       | out if you are keen for a nice intro to this important topic:
       | 
       | https://ashok-khanna.medium.com/rounded-tables-an-elusive-dr...
        
       | paraph1n wrote:
       | > I think gap is where this is all headed in the long term.
       | 
       | gap? Is this new? I've been waiting for years for CSS to finally
       | support something like that. Always thought it was weird that I
       | had to mess with margins (and last-child hacks) to get a proper
       | gap between items in a container.
        
         | btown wrote:
         | Yep!
         | 
         | https://developer.mozilla.org/en-US/docs/Web/CSS/gap
         | 
         | https://caniuse.com/?search=gap
        
         | seumars wrote:
         | It's part of CSS grid so in a way it's new, but CSS grid well
         | supported nowadays.
        
           | petepete wrote:
           | It's been made more general than just grid (it used to be
           | called grid-gap) and works with flexbox too. I don't know if
           | Safari supports it in flexbox yet and it's a pain to detect
           | with @supports because Safari _does_ support gap but in a
           | different context, but it works fine in Chrome and Firefox.
           | 
           | Edit: just checked, Safari 14.1 added support for using gap
           | with Flexbox.
        
           | [deleted]
        
       ___________________________________________________________________
       (page generated 2021-08-31 23:00 UTC)