- 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.
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.
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.
I don't think this is very useful, but it is a fun exercise in CSS.
It's just easier to do this with Javascipt without hacking the history.
(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?
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.
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.
Yup that all makes sense now then
How many sites using Meyer's reset didn't add focus styles to links? Even with the comment /* remember to define focus styles! */
It's not the fault of the original developer but it certainly helps to have more robust examples.
y.classList.toggle('open', y == e.target && !y.classList.contains('open'))
y == e.target ? y.classList.toggle('open') : y.classList.remove('open'))
y.classList[y == e.target ? 'toggle' : 'remove']('open')(when having lots of tabs open)
None of that changes that js adds incredible power to what webpages can do and there is zero chance of rolling back browser-delivered applications at this point.
I also don't understand why you think html+css doesn't have the same fundamental 'code execution' flaw - you're accepting unseen input from a remote source and feeding it into an execution engine which will have exploits - whether that's css or html or js or xml or *.
Back to your question though: yes, 98% of web users want remote code execution on because they want spotify, facebook, and youtube to work. They would be upset if they even had to manually go in and enable it. And I'm not even sure you could make a quality version of those sites without js.
If you use Wordpress, like millions of people do, you will have a fuck ton of JS plugins running, so I can see where this would be advantageous.
In a word: busywork.
- Page content doesn't need to be side-loaded in AJAX.
- Site layouts don't need to be set in JavaScript at page load. Animated menus don't need to be done in JavaScript and neither do pinned toolbars, doing so usually causes issues and stuttering when scrolling because you have a script running every pixel shift.
- Every link on the page doesn't need to be a JavaScript function, it makes bookmarking or opening in a new window difficult to impossible to what benefit?
- If you do want something to open in a new window, you also do not need JavaScript.
- User controls don't need to be JavaScript and when they are, they usually fail to work in mobile.
- Popover slideshow galleries don't need JavaScript to manage page reflow. Most shopping sites do this for their product images and it completely falls apart on Mobile when you pinch-zoom.
Far to often I find myself on pages that are unresponsive (not referring to Responsive Design) because they're so laden with JavaScript that everything comes to a screeching halt. Or worse still, some syntax error in one script brings the whole page down or one script reference doesn't load and the page is completely unusable.
>It is a common misconception that people with disabilities don't have or 'do' JavaScript, and thus, that it's acceptable to have inaccessible scripted interfaces, so long as it is accessible with JavaScript disabled. A 2012 survey by WebAIM of screen reader users found that 98.6% of respondents had JavaScript enabled.
Either way, I'm reticent to pull the WebKit prefixes from our mixins for now.
I wonder if my employers would be interested in releasing (& aggregating with other relatively large sites) our browser usage stats to create a categorised set of current 'real world' stats?
My impression is that Javascript has basically been the most successful sandbox ever deployed on a large scale. All vulnerabilities I've seen that escape the sandbox are due to things like Flash.
Does anybody know of any "JS-only" exploits that have happened?
This was used to win a contest: https://securityevaluators.com/knowledge/papers/engineeringh...
Then there's this: http://arstechnica.com/security/2015/08/dram-bitflipping-exp...
And this looks to execute some shellcode (but maybe it doesn't work): http://stackoverflow.com/questions/381171/help-me-understand...
Regardless, the bottom line is clear: if you value security and privacy, you disable JavaScript.
function eachItem(arrayLike, cb) {
return [].slice.call(arrayLike).forEach(cb);
}
Since that's more realistic, yes that would do nicely.
And no, I'm not making this up.
Good menus are complex. In desktop toolkits, there is a lot of logic to ensure they are accessible and don't behave in annoying ways. For example, a high quality menu will have a certain leeway to trigger into and out of submenus so that you don't accidentally drift into the incorrect submenu should you make an error of a couple of pixels while navigating them. They will have various delays and margins in place so that you are able to move your mouse in straight lines rather than make awkward 90 degree turns.
A good menu system will also be navigable with a keyboard-only and will have access keys to quickly jump to items within it.
Everybody who is reinventing the wheel because they see a menu as a mere "styled list of links that shows on hover" is missing out on the decades of learned UX that desktop systems have gone through. I sigh whenever I read, as I have many times in these comments, about making menus in CSS so that it's accessible to the 0.001% that doesn't use JS, while shutting off the much more real percentage of users that can't use a mouse (users that don't generally have a choice in the matter - unlike those turning JS off).
https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
1.1% of users don't see JavaScript enhancements. Most because it doesn't load, not because they've disabled it. Also, some people use browsers that don't support JavaScript, or their ISP filters JavaScript, or a whole bunch of other things.
I'm not endorsing making menus in CSS. I'm just saying that it isn't "accessibility vs. people who turn JS off".
As the link says: progressive enhancement is the solution to this.
Not quite: users want to achieve specific tasks as quickly and easily as possible. Certainly "work quickly" and "work on mobile" are two huge pillars of that for many (probably the majority of) tasks, but for many applications you have to make significant trade-offs in functionality under the constraints of a static site.
Anything built on the web is competing with something that already is or can be built natively. Native applications don't have to concern themselves with this sort of limitation on interactivity as a trade-off for latency, which is an advantage. On the other hand, the web has the (huge) advantages of open discoverability and no-install distribution. It makes sense for both platforms to be working to fill in their gaps while trying to minimize the trade-offs.
It's clear that slow startup due to big chunks of js (and media) on load has become a big problem, and people are working on that, perhaps without much to show for it yet, but it isn't obvious to me that ceding the territory of interactive applications back to native implementations would be the better way forward.
Of course, this is all in context of a typical webpage. There are exceptions to this.
Hi, that's me. The reason is, quite simply, because this is not a good user experience:
https://pbs.twimg.com/media/CmaP3JvUcAA8-5a.jpg:large
The open web is my platform of choice, and the technology is finally there. Progressive Web Apps[1] offer the features of native but are instantly-available, without downloading or installing. So yes, I very much want that as a developer.
I don't know of anyone, besides programmers, who doesn't like the current interactive-web-app web more than the decade-ago full-page-load web. They don't like ads and popups and things being slow either, but they love Gmail and AirBnB and Facebook and on and on. We should solve the problems without throwing away all the good stuff.
Two others completed the accordion in 3 lines task without jQuery.
I think if one of your main selling points is interactivity afforded by javascript, then it is unlikely to have much return on investment to accommodate users who don't want that. But for sure people should be thinking harder about what their selling points really are - the market for "it's better because of ajax!" is probably tapped out.
Also for what it's worth, I still use the Basic HTML view because I find it a better experience, so AJAX was definitely not the selling point for me. The 1GB thing was a huge factor though.
https://w3c.github.io/html/interactive-elements.html#the-men...
Have you seen XUL? Here's an example, from https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tu...
<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>
<window id="findfile-window"
title="Find Files"
orient="horizontal"
xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
<button id="find-button" label="Find"/>
<button id="cancel-button" label="Cancel"/>
</window>
(sul
(stylesheet "chrome://global/skin" "text/css")
(window "findfile-window" "Find Files"
(button "find-button" "Find")
(button "cancel-button" "Cancel")))
Now, imagine that JavaScript were Scheme or Lisp instead, so that your browser interaction code were also written in an s-expression language. And imagine that CSS were s-expression-based, so that you were using the same tools to manipulate the same data everywhere.
It makes me weep.
And I know the trends around jQuery, that was not the issue at all.
jQuery is JavaScript, so...
I've written a couple of small jQuery plugins and I don't claim I wrote this awesome Javascript code that does this cool thing. I say I made a jQuery plugin that does this cool thing.
And to repeat: Those that disable javascript have a choice in the matter. Accessibility isn't a matter of choice.
Those that disable JavaScript do have a choice in it, but those who don't have JavaScript because it has been disabled for them, or because they are using a device that doesn't support JavaScript, don't have a choice in the matter.
For example, the latter relies on more implicit information (the order of the arguments), which can be harder to keep in mind than the keywords use by the former, particularly as you add more than two attributes. I'd say this version actually reduces the cognitive load, but it doesn't save as many words:
(sul
(stylesheet :href "chrome://global/skin" :type "text/css")
(window :id "findfile-window" :title "Find Files"
(button :id "find-button" :label "Find")
(button :id "cancel-button" :label "Cancel")))Twice the disk space, who cares?
Twice the cognitive load, I guess I have a high tolerance.
Still don't see a compelling reason one is better than the other.
OK, fine. I'll concede devs want more interactiveness. I have yet to see evidence that users want more interactiveness. I think that points to the arrogance of devs "who totally know better than the user".
This had traditionally happened through POST/GET requests and having all the logic server-side. Yes it's possible to build interaction without Javascript, but it's not a great effect. Imagine if you had to wait for a page load every time you voted on a post on reddit.
Now extend that to modern webapps. Take Google's Voice Memos demo[1]. It loads instantly. It supports any device. You can even add it to your homescreen and you won't be able to tell it from a native app. Everything about it just works. Why would a user not want such an experience?
Javascript interaction is the natural evolution of the web. If it wasn't JS it would have been something else. This growth has been driven by users, devs, and browser vendors alike. There's nothing "arrogant" about it.
Ignoring the fact that it clearly wasn't intended to be taken literally, "in 3 lines of JS" when speaking in the context of a team effort on a web application can be understood as "adding 3 additional lines to the source code." Context.
There's no need to be nasty and argumentative for no reason.
To me it just feels like basic view is just v1.0 from 2004.
CSS has no console.log() for debugging, CSS often fails silently, and the demos in the link are more or less (albeit pretty neat) hacks, but don't use CSS features in the way the specifications intended.
It doesn't have a console.log, but it has `background: red`.
JS as a language and as such ( especially it's callback / event-driven nature ) makes it harder to debug.
- use simplified program model and enforce it, [2]
I know what you mean (I tried fighting the default Plone theme before the littering of various instances of !important got refactored out) - but it's also deeply ironic. It's Cascading Style Sheets - if you don't use the namespacing - you will have a bad day. Remember how bad javascript snippets based off of tweaked code that some old version of Dreaweaver had injected to a project some generations prior to the one you were working on was?
Just as people "programmed" javascript without learning the language, so people did with CSS. And not just "hammer it with !important until it stops resisting" either.
Simple example: today, if you want poor man's stand-alone component ; stick the html in a div (or other element) with a class of Mygreatcomponent, and style from there with direct parent/child-stuff. Sure, you need to do manual namespacing, but even if your project is huge, you can grep for class='whyisitallpinkComponent'.
This means you I'm able to retrofit old sites with new code with zero fear that the code I'm adding can affect anything else previously on the site :) It's also handy when building new stuff too.
e.g. you click a link in your email and it takes you to "www.foo.com/somethingWithParametersAndImportantStuff", foo.com detects you're on a phone and redirects you to their mobile homepage at "m.foo.com", blowing away your URL or even better not supporting your particular URL's page in the mobile site... where... your mobile browser could've just rendered the original site, albeit pinched.
It comes to mind because I'm currently dealing with this as an issue with UPS.com. We're halfway to 2017, people! How can we be having these problems.... :-)
Anyone know where I can find publication dates for individual comics? I don't see anything on the comic's page.
Flash never really was a problem for me; very very few used it for anything critical. It was mostly for entertainment and media that has no value for me. I lived just fine with no flash installed, and got performance & security benefits for simply not having it. Living with JS (and other obnoxious features) disabled, on the other hand, has gotten really fucking difficult now.
And frankly the "best viewed in whatever" websites weren't a problem either. On one hand it was mostly fanboyism. On the other, web designers using some niche feature that had no real impact on functionality or my ability to read & navigate the content. Again, I don't recall ever having to switch to another browser because of that. So it really was better for me back in the day.
Actually there was a period (end of the 90s, early 2000s) where flash was pervasively used to build entire sites. They were worse than single pages app of today. Completely broke browser history, urls etc... Those are similar complaints to today but now that APIs and workaround exit, it's mostly laziness that prevent people from properly building apps that avoid these pitfalls.
"And frankly the "best viewed in whatever" websites weren't a problem either".
There were days where not having a windows machine with IE installed meant not being able to bank online, access university course website etc... This is no longer an issue that I run into much in 2016.
"Living with JS (and other obnoxious features) disabled, on the other hand, has gotten really fucking difficult now."
That used to be the case too with Flash (and java to a smaller extent). Without flash many many sites were completely broken. This obviously got better with time to the point where it's hard to remember but it was pretty horrible to try to use the web without flash circa 2000-2006 or so.
I get that some want JS disabled but it's the only cross browser method of achieving certain interactive experiences on the web. It's not new technology and has been around since the earliest days of the web. The percentage of people with JS disabled is so low (less than 1% in sites on many sites I've dealt with) that it was very hard to justify the added effort to support both (in the case of the sites I worked on, they were large enough that the effort was made). As the web becomes used for more and more use cases, it's going to be hard to keep accommodating a very small minority of users. If JS wasn't there, something else would have to exist to do what it does.
That's a pretty low bar.
We have "best viewed in Chrome" today, which is no different.
A crappy, lazy developer won't care about state history. A good developer will. You can do things right if you want to. It's more work but not a huge amount more.
https://developer.mozilla.org/en-US/docs/Web/API/History_API...
Just as a pointer, using this "portmanteau as diss" discourse style is generally a bad idea if you want to be persuasive to people who aren't sure yet whether or not they agree with you, rather than just "preaching to the choir" who already share your views. The rest of your comment made some decent points, but name-calling like this just comes off as childish.
"We recommend Internet Explorer."
This comic was March 7, 2011.
http://www.explainxkcd.com/wiki/index.php/869:_Server_Attent...
http://forums.xkcd.com/viewtopic.php?f=7&t=69169&hilit=serve...
It's from some time around Mar 07, 2011.