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
The :target pseudoclass is used, along with anchors. It means that it also pollutes the browser history, which is somewhat appropriate for modals, but probably not what you want.
Ah forget that, as usual it's immediately obvious after I post that I don't understand! Looks like I had a bit of a mental block and couldn't see the top buttons for some reason - I was looking at the close links.
Building web applications with screens that have complex workflows and state is a need that is largely ignored by browsers and web standards.
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.
All that does is display a window with two buttons. You can imagine how hideous it could get when it got more complex. Now, imagine this alternative (I'm assuming that id & title are mandatory arguments, and that orient is optional, default to horizontal):
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.
The former has 46 words/348 characters; the latter 20 words/176 characters. That's more than twice the tokens, twice the disk space, twice the cognitive load.
Frankly, it's silly to think that cognitive load is directly proportional to number of words/characters.
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:
And using style sheets that were initially for styling documents for animation/graphics, and using javascript which was created as a lightweight language for non-professionals to create reactive diff-based dom manipulations, and...
To be fair in some cases this can be a benefit. There have been occasions where I have wanted to link to content contained within a modal. You are right in that there are also occasions where this isn't desired.
You can always use transitions to add the same effect. I personally enjoy when things open quickly, some people almost fetishize transitions to an absurd level.
There's a lot more to this than just "a little delay" to avoid accidental triggers.
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).
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.
That article is very nice but you're not reading it correctly if your takeaway is that "1.1% of users would benefit more from a CSS menu than from a JS menu". GDS is the UK government - a large portion of that 1.1% is likely not loading the CSS either. Bots, crawlers, rss readers, etc. The 0.2% number is much closer to what you're looking for.
And to repeat: Those that disable javascript have a choice in the matter. Accessibility isn't a matter of choice.
I didn't take that from it. See "I'm not endorsing making menus in CSS." I'm endorsing progressive enhancement.
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.
Good points, but surely all that knowledge could be encoded once into some CSS attributes, rather then rewritten every time for every JavaScript framework on every site?
A "correct" fix would be to build stylable core UI elements from the chrome itself. Leave the accessibility to the browsers (and by extension their UI toolkit). For this, you need a standard `<menu>` element, which is in HTML5.1:
Could be. And polyfilled for the monstrosity that is IE. That's a huge pie in the sky - whereas with JS, that's something which has already been here for at least a decade.
> Whenever someone makes a menu with CSS instead of javascript i go crazy as a user. The lack of delay is such a frustration.
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.
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.
That is actually wrong. HTML + CSS3 + user interaction is turing complete. Yet, as Olia Lialina argues, quite a lot of software + user interaction can actually be turing complete: http://contemporary-home-computing.org/turing-complete-user/
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 :)
I write a lot of CSS and I would probably disagree.
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.
Yes, but with the browser debugger you can step through the JS code and visualize what it is doing. How can you visualize what is happening with CSS, short of debugging the internal browser code ?
Easier to find the bug harder to fix I think. The problem is CSS has a global scope - you change one thing and breaks the whole site's layout. With javascript usually code affects more specific areas of the site/web app.
the thing is that we don't always start working on sites from scratch. more often I have to clean up someone else's mess or my own that I made months or years ago. in that case I'd rather debug javascript than css.
Yeah, I think it's a lot easier to fix shitty JS than it is to fix shitty CSS. Every job I've had, I've fixed more than I build. If it's a 5 person startup, I'm iteratively fixing my own shit as the product pivots. If it's 30 people, I'm fixing code from that one idiot that interviewed well and turned out to be impressively terrible. If it's a 10,000 person company, I'm fixing shit from that entire division that wasn't properly managed.
On the contrary, I think it is a lot easier to fix shitty CSS than shitty JS, because CSS is not run, but specifies attributes. This makes analysis static for the most part; race conditions and similar bugs usually do not occur.
"The problem is CSS has a global scope".
CSS can be written in a way that it affects only specific parts of the site/app.
"you change one thing and breaks the whole site's layout".
There are use-cases when you want changes to reflect across the entire site and CSS can be easily used to achieve it. (Ex: changing color of buttons).
Javascript can also break the whole site's layout. It just depends on what code we write.
I experiment with scoped CSS - where styles and even responsive conditions are tied to a specific element on the page and not the page as a whole.
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.
> The problem is CSS has a global scope - you change one thing and breaks the whole site's layout.
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'.
CSS layout is actually pretty good these days, with flexbox anyway. It's hard to come up with a better layout system used anywhere near as much as CSS.
Agreed, however there are a ton of companies with extremely outdated os/browser policies, that refuse to update for whatever reason. Been a contract developer for ~10 years and even this year we were told to support IE 8 on a specific project because some fortune 50 company needs us to (Seriously). There were plenty of modern tools that helped reduce issues but there was still a bit of headache.
Nope. There's usually plenty of work to do; supporting IE4 (or FF 3, or whatever Webkit shipped on Android 1.6) just makes it longer and over the budget, while squeezing out other projects.
What do you mean? It's quite easy to position elements on the page however you please. It can get quite complicated if you wish to support multiple viewport sizes with dynamic resizing, but it can be done.
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
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.
It would actually be wise to arm special forces with laptops, as we're only going to see more and more operations depending on hacking into security systems and building automation systems with the rise of smart devices that have no business being on the web (aka IoT). Only a matter of time before guns will only really be useful in third world countries without electricity.
So, are you saying that a bunch of guys with wire cutters and guns would be unstoppable? Simple scenario:
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.
Not good at metaphorical sarcasm, eh? Special forces not using guns because they sometimes need hackers make as much sense as web developers not using CSS because they sometimes need Javascript-based layout.
I was responding to this: "Only a matter of time before guns will only really be useful in third world countries without electricity" (emphasis mine) - still convinced that "issue not relevant at my level of abstraction" is not the same as "nonexistent".
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.
> I prefer using CSS for my styling and javascript for my functionality
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.
They just display stuff, right? I'm fine with having those in pure CSS if it can be done in an understandable and maintainable way. But the decision to display a message in a modal popup when you click a button is functionality and should be javascript. The behaviour of the modal popup itself is fine as CSS.
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.
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.
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.
Was about to write the same. The three examples I clicked on - tabs, accordion, and menu - didn't work via keyboard.
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.
The accordion can work via keyboard with some styling changes, e.g. position or clip checkbox instead of display:none, add visual indication on :focus. I didn't check the others but their accessibility may be similarly correctible.
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.
True, yet when examples like these are added without basic keyboard accessibility in mind they can get added to projects in the same half finished state.
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.
It's funny to hear this argument. I constantly hear "well, we don't worry about non-js browsers, because they are such a small minority". Yet how many people are keyboard-only users?
I'm not saying your wrong, or that you are arguing against non-js browsers, just a funny twist.
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.
Still a suprising number of old safari builds out in the wild, from a very quick look at our GA. Largely elderly iphones I assume?
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?
Days of the old web where flash was pervasive and best viewed in [IE6|Netscape|Mosaic|...] pages were everywhere. Every generation of the web has had really crappy devs building bad experiences. The current generation is not making anything worse than it's predecessor.
My current-favorite problem with modern web development is mobile-specific redirection.
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.... :-)
I'm very curious about this: is there a hypothesis that non-mobile computers are going away in the business world and/or that "young people" will not be involved in that world? I don't know the stats - are tablets making big inroads in business computing?
I think that just means new computing devices have expanded the market, not replaced old devices. Some functionality that was once used exclusively on PCs (what else did you have?) may now be more commonly accessed via mobile devices. You didn't have a PC in your pocket when you needed to look up directions on a map..
If it comforts you, I used an upside-down SNES gamepad for a few years before ever touching a mouse. And today I use my mouse far more than any game controllers.
Humans have several millennia of evolution "touching things" for tactile feedback. Mice on the other hand are a relative (and quite useful) hack compared to that. It requires training and a different mental dimensional model to use. To a child growing up with modern touch screens, a screen without touch is the aberration and "broken". Mice may not disappear entirely, but certainly more and more screens in our lives will support touch interactions, even on desktops and "non-mobile computers", simply because it requires less training and feels more natural ("touch the button" versus "move the mouse to the button and click" may not seem that different after decades of mouse usage, but are very different experiences to an untrained person). There's a sense already today that kids growing up with tablets find mice strange and annoying ("Why can't I just touch that?"), and it's easy to wonder watching today's kids if mice will last for more than a footnote in history and in increasingly small niches that require "headshot precision" like games and maybe CAD.
The archive page -- http://xkcd.com/archive/ -- has each comic listed by title, with the publication date in the hover text. Server Attention Span was published 2011-3-7.
Well, "your browser is unsupported" is something I still live with. And on the other hand, if I don't have the setup the developer expects, things just quietly break with nothing to tell me what's up. How is that better?
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.
"Flash never really was a problem for me; very very few used it for anything critical."
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.
I have to maintain a web interface with framesets and it's much worse than the React stuff I build. Yes it's "one huge js-dependant page for everything", but it can keep track or where it is (and go back to it) using location.hash or path entirely (if the webserver agrees). So I can fix single page apps, I can't fix framesets.
From a user's perspective, what you [as a developer] can or cannot fix doesn't really matter. What's broken is what matters. I find that with the JS craze we've been living for a few years now, things break a lot in the same way they did back in the frameset days. Except that now it is worse in some ways; with framesets, I could link to a specific frame if I wanted. And I could navigate back and forth too, as long as I understood the mechanics behind it. Now with the JS crapps, it's no longer something I can work around as a user.
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.
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.
Every modern framework I'm aware of has either built-in or popular third-party routers that use HTML5's History API to make the back button and links work just like they'd work in a static HTML-only site.
I think we learned from X- headers and x- media types that vendor prefixes are a mistake: inevitably one must support vendor-prefixed keys forever. That's why that practice is no longer recommended: just use the right key, and specify it properly so others may support it as well.
The W3C's job is to standardize implementations. Most standards bodies do not invent on their own. In any case, a standards body will generate the fundamentals allowing the ability to piece together components to create what a developer wants. No standards body is able to come up with every desire of every developer.
That's not really a nitpick: in case of the Internet, it's the main modus operandi - with various warlords carving out a temporary fiefdom here and there (remember the Browser Wars, when IE had 90%? Brace yourselves, we're headed for a re-run with Chrome), but no actual rulers or enforcement.
> 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.
I often hear rationalizations about how x couldn't be built with graceful degradation in mind. There certainly are _some_ examples (games, for example). But GMail doesn't strike me as a particularly compelling example. GMail is also _just content_. The fancy ajax interactions, though nice, are hardly required for an email client.
This is a-historical by my memory - the entire reason Gmail became so successful was that its use of "fancy ajax interactions" made it shockingly nicer to use than any of its competitors at the time.
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.
AJAX isn't why Gmail became successful. What set Gmail apart from its competitors was the huge amount of initial storage you got (1 GB for free at a time when Hotmail offered less than 10 MB for free), a higher maximum attachment size (25 MB compared to the webmail standard 10 MB), Google search, and conversation view. All of which, by the way, worked with the AJAX-free basic HTML view.
I had forgotten how big a change conversation view was compared to other webmail.
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.
For me, the basic view has always felt neglected and kind of halfassed. The full experience has fully styled UI elements where as the basic view just defaults to the browser defaults. Outlook does this too.
To me it just feels like basic view is just v1.0 from 2004.
Well, I doubt either of us have statistics for what really drove its success (and if you do, I'll gladly cede the point), but anecdotally, I and a lot of my friends at the time switched to Gmail not because we needed more storage (I don't remember even thinking about that as a problem with Hotmail at all) but because the interface was way better. If anything, I think it had more to do with the "cool" factor of getting an invite and the cachet of Google at the time than with the storage. But I freely admit this just personal experience talking.
Just because something can be done a certain way doesn't mean it should be done a certain way. Minimizing javascript for the sake of minimizing it is silly.
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.
>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.
I'm not talking about minimizing for the sake of minimizing. I'm talking about not using JavaScript for the sake of JavaScript. Or better, not using JavaScript because you can't be bothered to understand what your problem is or how to avoid it.
- 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.
The semantic web failed in large part because browsers didn't implement XSL, and so the average web developer never learned about the idea of sending structured data to the client as XML and using XSLT to instruct browsers to render the data as XHTML. If these specs hadn't been released in the middle of Internet-Explorer-monopoly-induced-browser-stagnation then they wouldn't have been dismissed as failures by the time browser competition increased and standards started to be honored.
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.
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/WupAsZGHDcY
Have you seen the whole presentation or just the first minutes? In the beginning he is showing some edge cases of css only usage, but then he actually demos some really good examples. The slides are here:
There are HN guidelines, and there's also the English grammar with a plethora of tools to help those with a mother tongue different than English like myself. HN is not a chatroom - it's a news website.
You're complaining about casing and one missing apostrophe... if you cared this much, how come you didn't notice the title is missing two words to even make sense?
I am complaining about things that even idiots should know (and that better yet HN should detect and reject). English is not an easy language to master but doing proper casing and basic punctuation right should be no challenge.
You keep implying people are idiots for missing apostrophes and not casing how your lordship likes it, I'll keep flagging your posts. In the mean time, neither CSS nor JS are featured in the dictionary so why on earth do you think your initial post is appropriate?
I'm sure if you google enough you'll find a community that finds it acceptable as a whole to be rude to people who don't have proofreaders and a full publishing staff for their internet comments. Sure as hell hope HN isn't it.
Flag as much as you pervertedly enjoy it - I really don't care, and this here is not kindergarten! CSS and JS don't have to be in any dictionary as they are abbreviations! I'm not rude - you just fail to comprehend what I'm trying to say. If your issue is that you associate yourself with one of those, then I apologize, but I can't be rude as I don't expect idiots to hang in here as this is not Reddit.
My sentence is fine according to Grammarly, LanguageTool, and Word. So, can you be more specific, please? Anyway, I was talking about basic rules that even idiots should get right.
I normally wouldn't comment on this but since you've self-identified as being interested in correct grammar and punctuation, I will.
A hyphen isn't appropriate where you've used it. It should be an em dash. You can type an em dash with shift+option+hyphen on a Mac or by holding alt and typing 151 on Windows.
318 comments
[ 2.9 ms ] story [ 250 ms ] threadStill neat though.
Yup that all makes sense now then
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.
Have you seen XUL? Here's an example, from https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tu...
All that does is display a window with two buttons. You can imagine how hideous it could get when it got more complex. Now, imagine this alternative (I'm assuming that id & title are mandatory arguments, and that orient is optional, default to horizontal): Which would you rather write in?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.
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:
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.
Is that really what you want? Does that properly describe the content of your document?
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.
And no, I'm not making this up.
[1] http://uxmovement.com/navigation/why-hover-menus-do-users-mo...
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.
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.
https://w3c.github.io/html/interactive-elements.html#the-men...
http://terrillthompson.com/blog/474
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.
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.
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.
https://news.ycombinator.com/item?id=2300836
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
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.
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.
- use simplified program model and enforce it, [2]
[1] https://github.com/jamesshore/quixote
[2] https://github.com/unframework/airtight-css-lint
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.
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.
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 isn't hating on CSS as much as how broken layout creation is with no end in sight--but plenty of hacks.
In a word: busywork.
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.
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.
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.
and for the accordion at least, the case was made and approved. check out <details> and <summary>
Well, that's my opinion at least.
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.
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.
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.
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.
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
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?
Now it's totally OK to break all that with AJAX and "text-as-apps"... I much prefer the days of the old web.
That's a pretty low bar.
"We recommend Internet Explorer."
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.
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.
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.
We have "best viewed in Chrome" today, which is no different.
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.
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...
http://caniuse.com/#search=css%20transition
This is just a webdev with old habits that isn't staying current.
No rules = Anarchy.
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.
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.
To me it just feels like basic view is just v1.0 from 2004.
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.
>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.
http://webaim.org/techniques/javascript/
- 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.
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.
https://github.com/oslego/css-for-decoration
- "JS" or better yet "JavaScript", not "js", nor "Javascript";
- "don't", not "dont";
- use title case as per the guidelines.
I'm sure if you google enough you'll find a community that finds it acceptable as a whole to be rude to people who don't have proofreaders and a full publishing staff for their internet comments. Sure as hell hope HN isn't it.
Ah, like politeness?
I normally wouldn't comment on this but since you've self-identified as being interested in correct grammar and punctuation, I will.
A hyphen isn't appropriate where you've used it. It should be an em dash. You can type an em dash with shift+option+hyphen on a Mac or by holding alt and typing 151 on Windows.
http://logicmason.com/2013/the-difference-between-hyphens-en...
:D