by ctvo on 7/5/16, 1:04 PM
I've worked with people who did things like this. It's not fun for anyone else on the team to try and figure out why you're using specific pseudo selectors on tags in a child inside a sibling in some label to make an accordion that would take 3 lines in Javascript.
by achairapart on 7/5/16, 9:51 AM
Most of these are just clever CSS hacks. There is a website collecting these kind of experiments since the early '00:
http://www.cssplay.co.uk/There was a time when separation of concerns and the "Rule of Least Power"[0] where the foundation principles of web development.
Today you have preprocessors, postprocessors, transpilers, content and style in JavaScript, behavior in CSS. Very powerful tools that can easily lead to unnecessary complexity.
On the other hand, somehow W3C failed to turn these principles into a truly interoperable and semantic web.
Ah! Also, nobody cares about unobtrusive JavaScript anymore.
[0]: https://www.w3.org/2001/tag/doc/leastPower.html
by danielnixon on 7/5/16, 9:48 AM
Numerous accessibility issues here. Many of these examples can't be operated by a keyboard, for example. "CSS only" is not a virtue if it comes at the cost (as it always does) of needlessly excluding people from the web.
by mcv on 7/5/16, 9:25 AM
I prefer using CSS for my styling and javascript for my functionality, as God intended. These examples could be educational for getting a bit more out of your CSS while keeping only the pure functionality in javascript. Too much styling-related stuff seems to be sneaking into code these days. I like my concerns separated.
by code_research on 7/5/16, 11:43 AM
I am missing one important argument in this discussion:
CSS only design is an important piece of a future web with reduced security and privacy threads.
The (interesting) model of allowing remote code execution per default was a beautiful, but naive vision. We have to make big advances in technology, politics and society to make this model work in a way that does not make internet users victims by default. We are not there yet. Reality is: the crooks destroyed that vision and are advantaged by the current situation, while all internet users are being trapped in their first moment of browser usage without their consent or knowledge.
For many use cases, (e.g. government websites, banking, anything where you type in your name) css-only design should become a requirement by law to protect the user until we figured out how to write secure software that respects user privacy and how to form governments that will respect their citizens (possibly will take longer). Until then browser vendors should implement more and better possibilities for CSS that help to avoid JavaScript whenever possible.
I very much like JS animations and stuff happening in the browser window, also there are some edge cases where JS brings some important advancements to a UI, but we have to face that privacy and security are much more important issues than having a nice UI and we have to change the current situation, as we, as programmers, are responsible for it.
The "remote-execution-by-default" experiment has failed, we need to change that, and CSS is a great way to go on with a web that might be less problematic for everyone, but still offers very nice usage experiences.
by adamjc on 7/5/16, 8:37 AM
The problem with relying on anchors means it stays in the browser history, so if you press 'back', you get the modal dialog again!
I don't think this is very useful, but it is a fun exercise in CSS.
by nnq on 7/5/16, 1:21 PM
May the gods have mercy on the soul of who'll maintain code using these... "techniques".
(I know because back in the days I've written things like this myself :) ..probably the curses whispered by those who've had to endure their progenitors are finally getting at me)
by zaidf on 7/5/16, 9:01 AM
History is going to look back at CSS in disbelief when it calculates the amount of engineering time was spent trying to position elements correctly.
This isn't hating on CSS as much as how broken layout creation is with no end in sight--but plenty of hacks.
by zuxfer on 7/5/16, 12:38 PM
And here I am, trying for past 10 years to centre align a div, both horizontally and vertically.
by jordanwallwork on 7/5/16, 8:28 AM
The problem with using css this way is that it's not as obvious what's supposed to happen as it is when using js. I'd love for there to be some explanation within the examples of _why_ they work - I've just been reading the first modal example but I can't really understand it
by awjr on 7/5/16, 8:47 AM
Although I think this is an interesting exercise, I need these behaviours to work the same across all browsers. This gets even more complicated within JavaScript apps where the state of the components is something I need to have fine grained control over.
Really cool and good to see what how powerful CSS3 is, but not sure how useful it is, particularly when I need this behaviour working on older mobile browsers.
by drinchev on 7/5/16, 9:01 AM
I'm still a huge fan of "If you can do something with CSS, avoid JS", but these days, working with React, everything is JS.
Although IMHO it makes logical sense to put the logic for the modal windows in the JS, not the CSS. And definitely easier for maintaining it.
by kyriakos on 7/5/16, 9:32 AM
Using checkboxes and radio buttons for keeping state is hacky to say the least. At the end of the day you can do the same with a few lines of easier to understand javascript.
by progval on 7/5/16, 9:00 AM
Ironically, all of these links point to jsfiddle/codepen, which require Javascript to see the demo.
by mxuribe on 7/5/16, 12:27 PM
Traditionally, I remember the rule that presentation should be managed by css, while behavior should be managed by javascript. But does the fact that some things can be reasonably done either way change - for example - a site's or app's maintainability? How about it performance? Is a CSS implementation rendered faster than javascript? I struggle with this at times, especially in some cases where - admittedly older - frameworks allowed for some overlap. Ah, well, much like lots of the web, i'll just work to get stuff done.
by the_mitsuhiko on 7/5/16, 8:46 AM
Whenever someone makes a menu with CSS instead of javascript i go crazy as a user. The lack of delay is such a frustration.
by acbabis on 7/5/16, 4:59 PM
The biggest problem with these hacks isn't a preference for CSS over JS (which IMO is fine in moderation); it's the fact that they aren't keyboard or screenreader accessible. A person using a screenreader can't even navigate to the accordion (
http://jsfiddle.net/yn4ls/), and if they could, it would tell them it's a form element.
by everydaypanos on 7/5/16, 9:00 AM
Still not good enough. For example the popover/tooltip that pops up on hover is fixed right below the target. If for example the viewport/window is smaller than the available space it will "bleed" out of view. You still need javascript to place it properly, and javascript that manipulates :after and :before pseudo elements is not straightforward.. Just saying :)
by nachtigall on 7/5/16, 8:39 AM
Would be nice if this would list the minium browser versions required for each example.
by jliptzin on 7/5/16, 9:51 AM
Just because you can, doesn't mean you should.
by dotdi on 7/5/16, 9:45 AM
Look ma! I replaced a few lines of JS with a crap-ton of CSS.
by ivanhoe on 7/5/16, 12:49 PM
IMHO this is a big step back, what do you really gain by sacrificing semantics just to avoid a little js code? CSS was supposed to help us separate content and presentation, and adding a bunch of unneeded tags just to make these hacks work is the very opposite of that.
by Fletch137 on 7/5/16, 9:42 AM
A fun exercise - while you might not _need_ JS, it's still the best option in a lot of cases.
I'd never even consider using most of these techniques in production - while they're interesting and showcase what CSS can do, they're practically unmaintainable.
by MrPatan on 7/5/16, 1:32 PM
The accordion example cheats a bit. The height of the items is fixed to 300px.
I don't know if it'd be possible with flexbox nowadays.
The usual max-height trick is not ideal, as the animation then doesn't have the right duration.
by IanCal on 7/5/16, 8:37 AM
So in the first modal example, the document contains both dialog windows at the same time.
Is that really what you want? Does that properly describe the content of your document?
by BinaryIdiot on 7/5/16, 2:53 PM
These are cool "CSS tricks" but I would seriously never allow someone to use these in a production web application.
- It's not an accessible solution in most cases (no keyboard navigation)
- The CSS classes are very and overly complex to the point where it's not intuitive at all what they're doing (honestly the code being intuitive is more important to me than any minor performance benefits that may be seen here)
by brador on 7/5/16, 9:00 AM
Not everyone is using the latest CSS standard browsers. Keep it simple for production code. It's easier to work with, support, and maintain.
by wnevets on 7/5/16, 2:47 PM
Is it wrong of me to not like using the css content property? I feel like actual content shouldn't be in css.
by vzip on 7/5/16, 2:12 PM
I've seen people create some beautiful things in pure CSS but often the code looks like a horrendous hack.
by supernintendo on 7/6/16, 12:27 AM
There are almost 300 comments here and no one has pointed out the obvious: these can be used within email templates where JavaScript is unavailable. For that reason alone, I think this is pretty cool.
But sure. Always use the right tool for the job, as they say, and for application logic that tool is not CSS.
by vladootz on 7/5/16, 9:55 AM
Even if you can do a lot of stuff in css, sometimes you shouldn't do them. Razvan Caliman from Adobe has some good points on this topic:
https://youtu.be/WupAsZGHDcYby amelius on 7/5/16, 9:11 AM
> Css is more powerful today and you can do a lot of thing dont need js
Yes, but the problem is that adding or changing functionality implemented in CSS can easily lead you into a brick wall.
At that point you will either have to rethink your approach completely, or move back to JS.
by imafish on 7/5/16, 12:11 PM
In my opinion, using Cascading
StyleSheets for this stuff is just broken. Animations are not
styles. Behavior is not a
style.
Readability and usability of animations could be improved by adding animation tags to the HTML Canvas (like WPF Storyboards: http://www.codeproject.com/Articles/364529/Animation-using-S...).
The view behavior-part could be done like WPF triggers. In fact let's just get rid of HTML/CSS and implement WPF for the browser.
by vkjv on 7/5/16, 1:21 PM
The accordion example isn't really what I think of as an accordion because it doesn't auto-close other elements.
For that behavior, you can make some minor tweaks swapping out the checkbox elements for radio buttons.
by majewsky on 7/5/16, 2:25 PM
I would like a superset of HTML that wraps these hacks up into nice controls, then compiles everything down to plain HTML + CSS.
by curiousgal on 7/5/16, 9:02 AM
I've always been told that the best way to learn something is to delve into it. Tried so with CSS but it was such a hassle that I gave up. Now, years later, all those past frustrations of my younger self remain to the point it's like a bête noire of mine. Seeing all this coolness makes me feel kinda bad for missing out. /rant
by erlehmann_ on 7/5/16, 10:33 AM
If I do not need JS, why do at least the first four demos do not work without it? I stopped trying the linked demos after that.
by lucaspiller on 7/5/16, 11:31 AM
Is it possible to display a "There are no records" message if a container is empty (i.e. tbody) using CSS only?
by drydenwilliams on 7/5/16, 2:32 PM
It's a really nice solution for experiments but I've found it quite difficult to get people to adopt this CSS approach in some companies (regardless of any cross browser implications).
Everyone needs to be on the same page and of course be up to date with CSS3 animations, which can be over looked.
by josephjrobison on 7/5/16, 4:13 PM
by 20years on 7/5/16, 5:27 PM
While I don't think I would use a lot of this in production for the maintainability alone, it does showcase what you can do with CSS. I see a lot of convoluted Javascript being used on things that can easily and more cleanly be accomplished with a little CSS.
by anacleto on 7/5/16, 7:29 PM
by wehadfun on 7/5/16, 4:16 PM
I''m glad that the general consent here seems to be doing this in CSS is not a great idea. I feel the same way about XAML where programmers try to do things in XML instead of C#
by d33 on 7/5/16, 8:50 AM
by nzjrs on 7/5/16, 11:56 AM
Related, does anyone else have a preferred pure css treeview?
by iLoch on 7/5/16, 9:10 AM
I think it would actually be wise to stick to JS style rendering (as is the case with React) as we're only going to see more and more styling being delegated to scripts with the rise of wasm. Only a matter of time before CSS will only really be useful for completely static websites IMO.
Edit: Downvoting me because you disagree isn't really in the spirit of HN.
Please provide a counter argument if you disagree, I'd be interested to hear it.
by reitoei on 7/5/16, 2:57 PM
ITT: people taking this way too seriously
by lasfter on 7/5/16, 10:26 AM
It is pretty easy to cheat at the rocketship game by dragging your mouse to avoid enemies.
by boubiyeah on 7/5/16, 2:00 PM
Please don't. CSS is unmaintenable. JS can be made very maintainable; end of story.
by hartator on 7/5/16, 6:01 PM
I think that's great, but everything is based on hacks using checkboxes.
by lsh on 7/5/16, 10:25 PM
hm. ironically (?) none of the linked examples work without javascript.
by ClassyJacket on 7/5/16, 12:56 PM
Is that title supposed to be in English?