[HN Gopher] Conditional CSS
___________________________________________________________________
Conditional CSS
Author : mooreds
Score : 59 points
Date : 2023-01-16 18:20 UTC (4 hours ago)
(HTM) web link (ishadeed.com)
(TXT) w3m dump (ishadeed.com)
| danielvaughn wrote:
| I've been writing CSS for well over a decade, and as much as I
| love it, there's one thing I've always been irked about. The
| language lacks an explicit if/else syntax because the authors
| felt that the presentation layer shouldn't be responsible for
| "behavior", which is how they think of logic. So what's funny
| here is that this article perfectly illustrates why the lack of
| an else/if is just pure silliness. There's "behavior" embedded
| everywhere in CSS, it's just all so implicit that it almost goes
| unnoticed.
| sebazzz wrote:
| CSS is reaching the point for me that it is becoming too
| complex. I'm perfectly fine with complex backends though - CSS
| though, there are now so many options and so many ways to do
| things. It must probably be me though.
| suprjami wrote:
| It isn't just you.
|
| I work on systems software - kernel, daemons, networking,
| debuggers, machine language disassembly - so I'm used to
| looking at things which other people say are "hard".
|
| Nothing frustrates me more than writing a Stylus rule or
| figuring out how to place an element on my Jekyll theme.
| Every time I do this, my appreciation for modern well-made
| websites doubles.
|
| CSS is so opaque and impossible, I wouldn't be a web
| developer for any money.
| marcosdumay wrote:
| It may be time for CSS to consolidate, factor some
| functionality, and deprecate some old stuff...
|
| But I can't point any functionality that could go through
| that. Ok, there are a few functionalities that are not
| independent, but they are still better designed than any
| alternative I can think.
|
| I'm staying with the opinion that a universal formatting
| language is inherently complex. And CSS is quite well fit to
| function.
| madeofpalk wrote:
| What's an example of something you could do with an if/else,
| that's not possible today? I think this article demonstrates
| why an if-statement is not needed when you can declare rules of
| how styles are applied.
| danielvaughn wrote:
| It's not about functionality, it's about being explicit and
| clear. Had the authors decided to include an if/else
| construct, it would have meant that none of those other
| concepts were even necessary. You could have bundled all of
| them together under one syntax. Much cleaner and easier to
| understand.
| psygn89 wrote:
| I think part of the problem was that selectors that looked
| inwards or outwards from an element was deemed too
| expensive to parse. It only looked at the current element
| or following adjacent ones (with + or ~). Now that it's
| deemed doable without noticeably hurting performance,
| :has/:not(:has()) basically comes around and allows you the
| inward/outward selector lookups, e.g.
| (`.container:has(input:checked) { border: 1px solid green
| }` ).
|
| That said, I do agree it would've been nice if they had the
| foresight to use `:has(:checked)` (or some kind of :if()
| syntax), but it's all hindsight 20/20 and it was the wild
| west on the web back when a lot of these features were
| spec'd/implemented. Kinda wish there was a new css version
| every 10 years or so to fix the inconsistencies (which you
| would have to opt into).
| madeofpalk wrote:
| What's an example that's not explicit or clear enough?
|
| I think `p:empty { }` is a perfectly clear syntax. As the
| article says it's already a conditional statement - just
| imagine an invisible `if` in front of every selector or
| media query.
|
| CSS is not a procedural language, so I think that if
| statements could be less clear about how rules are applied.
| glasss wrote:
| I think you and the blog post make sense. If you present people
| with a outside-in view of building a website, I wager they
| would agree that form and presentation layers have a huge
| impact of behavior, expected or implicit.
|
| With the inside-out view of HTML then CSS, it feels like that
| same stance gets muddied because of the technical aspects of
| the languages and their original intents.
| gnull wrote:
| The current syntax also makes it hard to characterize the class
| of predicates that can be expressed with CSS. Kind of hurts my
| sense of perfectionism, but I guess it wasn't their goal.
|
| I assume CSS was made very restrictive on purpose so that it
| can be applied to the page elements and analyzed very
| efficiently.
| nine_k wrote:
| So useful; thanks to the author.
|
| But a number of things are still Chrome-only, and even with that,
| only available in the latest version. Will have to wait before I
| can apply them.
| grose wrote:
| Great article. I am super excited for :has, I think it will open
| up a lot of doors to truly declaritive UI with vanilla CSS and
| HTML.
|
| One more handy feature is data attributes. You can use them to
| introduce some state to your UI.
|
| Here's a quick and dirty example of a menu for an RPG game.
| <ul id="menu" data-can=""> <li id="menu-
| attack"><button>attack</button></li> <li id="menu-
| magic"><button>magic</button></li> <li id="menu-
| run"><button>run</button></li> </ul>
|
| We can use data attribute selectors to hide menu buttons that the
| player can't use. #menu:not([data-can~=attack])
| #menu-attack, #menu:not([data-can~=magic]) #menu-magic,
| #menu:not([data-can~=run]) #menu-run { display: none;
| }
|
| Then all we need to update the menu UI is this single line of JS.
| document.getElementById("menu").dataset.can =
| getPossibleActions().join(" ");
|
| You can see a rough example here:
| https://github.com/kawaiisolutions/tactics. It's very nice for
| prototyping.
| wildrhythms wrote:
| Yes, I use data attributes all over! It lets me keep certain
| data and certain states in the DOM, and I can actually use
| querySelector to... you know, do a query based on data
| attribute values. I've met many devs who didn't know that CSS
| queries can actually string match within the values of
| attributes! (i.e. [attribute~="value"] and the other
| variations)
|
| https://css-tricks.com/almanac/selectors/a/attribute/
| throwaway744678 wrote:
| This article has interesting points; I learned a few CSS
| features. Yet the premise seem rather bland: of course CSS is
| "conditional"! No need for fancy media queries and whatnot, a
| basic selector is already a "condition". Styling different
| elements in different ways is the whole point of CSS.
| karaterobot wrote:
| At first I assumed this was a blast from the past article about
| having to feed special styles to older versions of IE using
| syntax that was invalid in other versions. Like using `_` or `*`
| characters in properties. I had to look up all those old tricks I
| used to know by heart, from the bad old days.
| swyx wrote:
| could you use the :checked or :has selector for opening up mobile
| menus? i currently use JS for that and feel a bit guilty about
| it, yet i dont really know how to do it in pure CSS and hide the
| checkbox somehow
| cookie_monsta wrote:
| You just hide the checkbox the way you normally would with CSS.
| Search for CSS Hamburger Menu - there are plenty of examples
| online. There's some other trick in there using target. It's
| been a while since I did it but once you get your head around
| it it's pretty simple.
| zachrip wrote:
| Be careful in this space, keep accessibility in mind when doing
| things like this. JS is meant for interactivity, don't feel
| guilty for using it for the right job.
| chatmasta wrote:
| Yes, this is what I do, with :checked and <details> and some
| sibling selector trickery instead of :has (basically, the
| checkbox is the last element, and <details> is an accessible
| browser-native way to toggle visibility without javascript).
|
| I was able to make some complex hover menus and sidebar toggles
| work like this entirely without JavaScript. It's also
| accessible, _to the user._ The downside is that for the
| developer, the resulting code is not easy to read nor maintain.
|
| I would link to it but it's in a private repository atm. One
| day I'll open source this behavior as its own package... one
| day...
| Lisa_Novak wrote:
| [dead]
___________________________________________________________________
(page generated 2023-01-16 23:00 UTC)