Splitting the CSS into two distinct pieces (or better: files, but I realize that's a limitation of jsfiddle) would go a very long way to making this technique maintainable. Having documentation that then shows the required HTML structure and the necessary classes to add would help immensely.
Essentially, build it like a UI library that just happens to be written in CSS.
Right now, it's just a demo of a technique that's not built in a reusable way, and you need to be pretty decent with CSS in order to understand and use it (since you pretty much have to re-implement it every time you want to use it). To be fair, the HN submission and site don't make any claims it's anything but this.
Try this in Chrome: https://jsfiddle.net/timdavila/f5rcarmn/
"Yeah, yeah, but your scientists were so preoccupied with whether or not they could that they didn't stop to think if they should."
With a sane limit to number of characters on each line as well.
JS:
var panels = [...document.querySelectorAll(".accordion li")];
panels.forEach(x => x.addEventListener('click', e =>
panels.forEach(y => y.setAttribute('class',
y == e.target && !y.classList.contains('open') ? 'open' : ''))
));All an accordion does is add an event listener that removes a class from all elements and adds it back to one of them. Then there's a 1 line transition for that class in css.
Yeah, it's incredibly crude but it is 3 lines and it took approximately 60 seconds.
But that's changing once web animations (https://w3c.github.io/web-animations/) hits mainstream anyway - both CSS & JS get access to the same engine.
If you only write it once and put it somewhere, among other advantages, you can document it easily.
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.
I do. I also care about graceful degradation. There are certain times (e.g. Web Apps like Gmail) where graceful degradation is almost impossible and unobtrusive JavaScript would be silly but those are the exception. Most sites on the web are just content and there's no reason to have excessive JavaScript or any reason why the page can't be perfectly functional without it.
People that disable javascript represent a tiny percentage of the population. No one is going to make engineering decisions based on that tiny percentage, anymore than people still target IE6.
I'm not sure that the semantic web would succeed even if it were a new idea today. HTML5 was popular because it gave web developers tons of shiny toys and got them excited to use it. XHTML was conceptually beautiful but it hardly enabled any user-visible improvements over HTML4, so only the philosophically-minded web developers gave a fuck.
.accordion .content {
padding:0 10px;
overflow:hidden;
border:1px solid #fff;
-webkit-transition: all .5s ease-out;
-moz-transition: all .5s ease-out;
}
Now it's totally OK to break all that with AJAX and "text-as-apps"... I much prefer the days of the old web.
http://caniuse.com/#search=css%20transition
This is just a webdev with old habits that isn't staying current.
No rules = Anarchy.
All of these are fairly simple show and hide interactions that are easier to use, build and maintain when done with javascript, with all the content shown if JS is turned off, not fully loaded or broken.
Of course for accordion in particular it would be better if the pure HTML solution of using <details> and <summary> elements was supported in all browsers. They're already in Chrome and Safari and will come out from behind a flag in the next Firefox version. A polyfill for IE etc. can bridge the gap.
I'm not saying your wrong, or that you are arguing against non-js browsers, just a funny twist.
Blind users can't opt to see.
To play devil's advocate, though... is an accordion or a carousel "functionality" any more than, say, a drop-down or a multi-line input box is? I mean, the games examples are pretty wacky (in a cool but "thank God I don't have to debug these" way), but things like tabs and tree views are so ubiquitous that a case could be made for having standard HTML input tags for them.
Well, that's my opinion at least.
and for the accordion at least, the case was made and approved. check out <details> and <summary>
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.
You can still make the apps you're talking about with html+css and enforce js=off in your user browsers, but there is a reason no one wants to do that these days.
And unless I'm not mistaken, there have been plenty of exploitable bugs in the core rendering engines that involve only html/css, so your utopian world STILL depends on a secure sandbox.
I'm going to heavily disagree with you. There were plenty of sites that were successful without using heavy JS. Most webapps I see can run easily without JS, they just choose not to. Yes, there are exceptions, but they are exceptions.
"The core features people want" aren't JS-pop-ups, and slow browsers. They want sites that work quickly, are easy to understand, and work on mobile just as well as on a desktop. I would argue that JS makes all of those aspects worse.
The reason is, that JS is enabled by default, nothing else.
If users had the possibility to actively decide before any remote code will execute on their computer, how many would like to enable it?
We are just one default checkbox setting away from what you call "utopia" here - a word that should be used for much bigger things.
Of utopic naivity in deed is the expectation that such powerful features will not be misused - delivering browsers with code execution enabled by default will be looked at as one of the most funny things of the first internet in a few decades.
Web application development paradigms that enforce JavaScript usage as an absolute necessity are examples of "naive utopian deadends". It is totally anti-avantgarde and anti-progressive, we should not waste so many young talents on that.
It might be convenient and powerful - but secure? With our current huge (in code and complexity) browsers? With the series of bugs in font rendering, image libraries etc?
[ed: autocorrect. Apologies for seemingly calling algolia "third-rate" for a while there!]
"same origin" is about the source of that code, only of minor relevance here as long as no working signed code distribution mechanism and infrastructure exists - why not, btw, after all these years?
For communications and general information transmission we do not need remote code execution.
Yes, browsers try to do that in a "safe way" - the "sandboxing" approach has been exercised for many years now, mostly without success. Maybe Qubes OS can be a successful approach to this problem, but we still have too many non-technical problems to solve, as reality shows, so enough time to do more research. Until then: css only should be the default.
CSS gives us a very good way to stop going on with that inacceptable defaults while we fix the first version of the internet.
Even with the same-origin policy, the default behaviour of a web browser is to execute code it downloads from a remote site (i.e., remote to your computer); as it turns out, this is an utter disaster for security and privacy, turning what is a relatively securable platform (HTML+CSS) into a nightmare.
It is not, today, possible to be secure and private while allowing JavaScript. That's a problem.
I don't think this is very useful, but it is a fun exercise in CSS.
(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)
This isn't hating on CSS as much as how broken layout creation is with no end in sight--but plenty of hacks.
Instead of getting reusable gui components we get indechiperable css hacks that were built for creating art installations on the web rather than getting any actual work done.
Still neat though.
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.
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.
You like sluggishness?
Whenever I see a menu with CSS, I'm delighted: it means I needn't enable JavaScript (which opens up my computer to infection) just in order to read a list of links.
[1] http://uxmovement.com/navigation/why-hover-menus-do-users-mo...
There is no need to throw some crazy JavaScript stuff at a problem that does not even exist.
Seems like lots of web developers have forgotten to keep it simple.
the other stuff ranges from clever tricks, like the label/checkbox modal, to stuff which would be a nightmare to maintain on a complex page
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.
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.
Is that really what you want? Does that properly describe the content of your document?
- 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)
But sure. Always use the right tool for the job, as they say, and for application logic that tool is not CSS.
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.
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.
For that behavior, you can make some minor tweaks swapping out the checkbox elements for radio buttons.
.container:empty:before {
content: 'There are no Messages'
}Also, keyboard support would be great. And if it wouldn't overflow offscreen.
Oh wait, no such thing.
(Note that these are basic issues, not arcane requests for 9-bit EBCDIC compatibility - but nooooo: let the users suffer, because we want to use this extra-cool trick)
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.
1. Cut all the power (grid connections A, B and C, disable generators) - nobody says no if you ask nicely and have a big gun 2. Watch the special teams struggle helplessly to hack into offline systems 3.PROFIT!!!
Your assumption (that the network somehow runs on unicorn farts and that the need for boots-on-the-ground protection is obsolete) is fatally flawed. There's no way to outcloud everything, no matter how vigorously you try to handwave away the physical layer. Someone needs to keep the juice flowing, which also needs physical protection.