At the start of the article they do state that you might need javascript. The point was to show off things you can do without javascript, not say that you never need it.
Of course it doesn't undermine it's own credibility. If you turn off JS you'll see that the site still works. It's progressively enhanced using JS to give you examples of what is shown here.
It's sad that this site uses SCSS for displaying the rules, I'm using it in production and fully understand it, but it's needlessly abstracting the rules for the sake of a few extra words in each declaration.
That aside, these are some pretty cool examples. Are there ways of doing this with CSS which doesn't screw with my browser back button?
I absolutely agree! While we can discuss about why SCSS is better, it is more like comparing Volvo with Mercedes. In the end, CSS is the standard, not SCSS. And CSS is evolving and getting better and better.
There's a "view compiled" button that turns up if you hover the SCSS in codepen. I got through half the doc before discovering it though. I was very surprised to see the ampersand, since I was pretty sure CSS didn't have anything like that.
I half agree with you, but one of the real benefits that SASS gives you here is making dependencies more obvious. A named variable like `$slider-height` is much clearer than a random number like `50px`. Yeah, you could put a comment next to every constant in the CSS, but I don't think that's clearer than the SASS alternative.
SCSS variables also make things FAR more maintainable. To change a color, you shouldn't have to change every single line where that color is used.
You update the value where your color variable is defined, and then each style declaration that uses the color variable receives the new value automatically.
Wow even the Android browser implements it. IE and Safari are lagging again...
I was surprised to see some Linux-style color picker pop up. It looks a lot like the one GIMP uses. Wonder if Firefox implemented that or they depend on something that does, and in the latter case, what's that dependency?
The you don't need jQuery website had a concrete use case - you need not include an entire library into your website for some simple tasks which makes your website faster.
Though, this site is cool in showing the power of CSS, I am not sure if there is any specific advantage of using CSS over JS to design tabs, sliders, etc. Just use the best tool for the job!
There's definitely some merit to not requiring users to download and run arbitrary and untrusted Turing-complete code. Whether abusing a stylesheet language to achieve that is worth said merit is certainly debatable, but I for one applaud the effort.
Safari is the new IE6, stop supporting it and let it die. It will not get any better anyway. If most of your users are on iOS, then make an app for them, it's what Apple also want you to do...
I switched from Chrome to Safari 5 months ago. The memory usage in Safari is far more superior than Chrome / Firefox on OS X. Also the CPU usage is relatively low, which means more time on battery for me.
I still use Chrome for development, though.
Safari, is not as bad as IE6 was and anyway no professional front-end developer would make a website that is not working properly on iOS Safari, so it's kinda obvious it will stay supported for a long, long time.
So I would consider what the OP is doing with the CSS, something that might also work on Safari, but with some polyfills.
Oh please. Safari 10 (both desktop & iOS versions) is the only browser with 100% ES6 compatibility. All browsers have some issues (e.g. Chrome still does not support 'sticky' position, Safari hasn't implemented Service Workers, etc), that's part of the multi-vendor / open-standard game.
Safari does have longer release cycle than e.g. Chrome, because Apple provides very uniform / polished support for wide range of devices (Macs, iOS devices, including very old ones such as iPhone 4S).
Chrome/Google has terrible/no support of many browser layout & interaction features, such as CSS Regions & scroll snap points.
Also, Safari is just a much better browser than Chrome. We need to make sure people stop using Chrome and move to the default browser in their environment - Safari & Edge.
If you support the default browser, then you're going to be fine.
I'm not the only one who think Safari is a joke compared to the competition. While IE6 was much much worse than what Safari is today, I feel like history is repeating itself again. And ES6 support is irrelevant when the main goal is to make sure websites renders and behave correctly, which is more painful for Safari than the other browsers.
Websites and browsing it self look and feel smoother in Safari compared to Google Chrome. Font rendering in Safari feel like font rendering in the rest of macOS. Not always but sometimes the same website has proper fonts in Safari but looks awkward in Chrome for some reason, I dunno why. Safari has proper GUI (especially settings) that feels at home in macOS instead of some weird web-based settings. Safari uses so much less power for the same usage compared to Chrome.
It's just my anecdotal view, but I believe that Chrome might be better for developers, but websites are made for the users, not the developers, and Safari is far superior on that front.
"Safari is the new IE6, stop supporting it and let it die."
I can only assume you never went through the pain that IE6 delivered... It has been some years now but I still get nightmares about it. It literally made me question at one time if I didn't made the wrong choice to focus on web development.
Apple may be dragging its feet when adapting new api stuff, but the situation is by no means comparable as what the situation was with IE6. Not by a million miles.
IE6 wasn't so bad. It could do everything in 2001 that practically every site needs today, and pretty intuitively if you didn't also support other browsers. But dealing with emerging "standards compliant" browser bugs alongside "the de facto standard" IE6 bugs in the same code, and eschewing table layout before CSS was up to the task, that was a nightmare.
A few days ago a saw a talk about CSS animations with RxJS [0] and the gist about CSS only stuff was something like: "Yes, you can do much with CSS only, but it gets ugly fast."
Often you're better of to do a mix of both, because some things that are very complicated in CSS are two-liners in JavaScript.
Note the absurd metric (lines and spaces) to justify how the blown-up version is considered to be smaller. Also note that the article consequently talks about "Node code" even though they are talking about client-side JavaScript.
From the article:
#gulp {
color : #0000ff;
padding : 10px;
}
This CSS takes up 4 lines, and at least 13 spaces. [...]
document.getElementById(‘gulp’).style.color=‘#00f’;
document.getElementById(‘gulp’).style.padding=‘10px’;
This Node code takes up only 2 lines and there are 0 spaces.
Essentially, we are saving lines, spaces, and files (delete
your .css documents!).
There is some useful stuff to learn from here, undeniably, but many of these are a bit useless when you compare them with what you would actually typically need on a real site. Yes, the "image slider" is vaguely functional, but really most of the time you will want a lot more control than just the CSS animations allow; similarly, yes, the form validation is a starting point, but normally you would want to customise the error messages and generally fiddle around with it a lot more; I'm not really sure the modal is fit for purpose beyond the most basic use case... etc.
It's fun to see what you can partially achieve without JavaScript, but there is no shame in using JavaScript sensibly to enhance the usefulness of a web site.
What bothers me is that I saw many of these things implemented in CSS only in ~2004. Of course, it required much more code then, including shims for IE 6 and careful slicing of GIFs, but things like tabs, accordion or lightbox were being implemented. Makes me wonder where the last decade went. At least there was a good reason to avoid JS back then: it was slow and often looked worse than CSS hacks.
Do any of the examples use Javascript? Or are you saying the site shouldn't use JS for syntax highlighting or whatever, even though that's not the sort of thing it claims JS isn't needed for?
It depends what you mean by "support". There are two things a JavaScript syntax highlighter is doing:
1. Classify each token (whether this is building up an AST or doing something more fuzzy/clever is immaterial for this discussion);
2. Construct a DOM tree (HTML) that is styled (CSS).
Step 1 does not have to happen client-side at all. Step 2 doesn't require JavaScript at all.
I was reading it with javascript disabled and very confused - are there only code snippets and no visualization of the examples? After reading your comment, I went back and enabled javascript and now can see the examples.
Also, some of them have major accessibility and usability issues.
The image slider for example can't be paused. There's the CSS property "animation-play-state" which could have been used to do this, but that literally freezes the animation, whereas you typically don't care about the animation but don't want the slider to move on to the next image (i.e. finish the transition, then pause).
And of course depending on which browsers you're targetting, many of these are horrendously broken for most of your users.
Yeah, the slider could have an overlay label that toggles a checkbox, where the slider animated is depending upon a checked property, but then the issue is which image is active... that would get fairly complicated with css only.
I'm cautious about using CSS to do things that feel like actual behaviours.
For example, the modal that appears when you click on the button actually doesn't do things on "clicking" but focusing. This means if you tab over the button it'll load the modal, then tabbing away means the modal is gone. I can't tab into the content in the modal at all. How does that work with accessibility?
Though I generally dislike the idea of saying content isn't there by making it present in the document but invisible.
Edit - Some of the default behaviours are also a bit pants. In chrome, the form validation on a pattern starts working after I hit submit, then angrily shakes at me for every keypress until it's valid. Then, it ignores invalid input as I type more! Please never use this for phone numbers or credit card numbers. Stop requiring an exact format when what people type varies, and stop telling me I'm putting in something wrong when you ask for a phone number and I give you something that'll connect to me if you type into a phone.
Maxlength is not a validation it's just ignores any more letters you type. Quietly ignoring your users input is probably not what you want.
The "Would you prefer a banana or a cherry?" just shouts "Please match the requested format" if I type "a cherry". I know chrome has nothing else to go on other than "the regex wasn't matched" but it's a bad end user experience.
The tabs example is something I need to tab onto then use left and right, I assume because it's a radio box underneath, not a series of links. Are tabs really radio buttons?
The same for the accordion. Which I've found if I add any tabbable content inside them then I'm focused on a hidden item. Great. Tab onto "tab 1", hit tab, focus has disappeared and I'm now potentially going to click on random items I can't see. This is because although you want to pretend the content isn't there just because it's not visible, it's still there! It's in your document.
Sure, you might not need javascript. But maybe you should still use it.
> The "Would you prefer a banana or a cherry?" just shouts "Please match the requested format" if I type "a cherry". I know chrome has nothing else to go on other than "the regex wasn't matched" but it's a bad end user experience.
Localized custom validation messages for the provided pattern should be added as part of HTML spec. Someone should follow up on that, because it'll probably be too much of a waste of time for me.
<input type="text" id="username" required placeholder="Enter Name"
oninvalid="this.setCustomValidity('Enter User Name Here')"
oninput="setCustomValidity('')" />
where setCustomValidity could provide any text, even localized text from some other source like a DB, potentially, since it's JS. Requires a modern browser, though.
> Sure, you might not need javascript. But maybe you should still use it.
Someone should put together a site that, given a set of browser restrictions the user provides, gives examples of each of these to show the most accessible and standards-compliant version of the code to use, minimizing external libraries required, with and without localization, because not everyone has the resources to provide localized content, unless localization could be provided by a built-in library in the browser or OS, which would be another great project.
Yes, there are sites that provide a matrix of supported browsers, but I don't think that would be as simple to use; developers like copy-and-paste examples, for better or worse, e.g. StackOverflow.
> Someone should put together a site that, given a set of browser restrictions the user provides, gives examples of each of these to show the most accessible and standards-compliant version of the code to use, minimizing external libraries required, with and without localization, because not everyone has the resources to provide localized content, unless localization could be provided by a built-in library in the browser or OS, which would be another great project.
This is something I'd like to see, because apart from a few things I know to look for (tabbing, for example), I don't know how well various devices and settings do with different content. Consistent approaches also help people working on things like screenreaders.
Best of luck making this work across browsers. And even more luck to anybody who uses this, and then has to come back 6 months later to change something.
The validation examples and input types are a case in point. Even on browsers where they work, the alerts can't be styled and the behaviors can't be controlled.
> the alerts can't be styled and the behaviors can't be controlled
It's not clear to me whether that's a problem. Isn't consistent UI a good thing? Isn't it faster to fill the forms correctly if alerts always appear in the same way?
I've actually spent many hours trying to make them work. You should at least invest a little research time before making proclamations about how you imagine they work.
I now see that we're not really talking about alerts in the 'alert()' sense, but rather about the popups - which are not native widgets (which are better off non-modifiable, in my opinion).
My bad.
Do you know of any good reading material concerning these form validation popups?
From reading on MDN [0], they seem to be browser specific - like the Chrome connection tab [1] - but somewhat customisable via JS.
Not really. The errors on Firefox at least, just say "Please match the requested format", which doesn't tell the user where they went wrong for potentially complex requirements.
When submitting a form with an incorrect pattern in Firefox, the validation behavior highlights the relevant textbox in red for a second, and removes its contents. This default behavior gives a very poor user experience.
And if we spent half the time we collectively spend making JavaScript validation programs on making the Firefox validation behaviour better, it'd not be this way.
Perfect enough? Hardly. Errors aren't shown until you submit, giving you no opportunity to fix the mistake while you are there. It also only shows one error at a time. So if you have multiple errors, you fix one, everything is fine, and you don't see an error until you submit again.
> You should do the rest on the backend anyway
Well yes, you should validate on the backend, but you shouldn't wait to only validate on the backend.
This works well enough for getting things done quickly, but it's hardly a good UX, and a far cry from "perfect enough," whatever that means.
Yeah, from the responses, I'm definitely seeing a gulf between "people who've read some random stuff on HN about web design" and "people who actually do web design".
I think a more important point is that you should design your website to still be functional even if Javascript is disabled.
Why? Because some users, such as those who use Tor, may have legitimate reasons to disable Javascript execution while browsing. Another reason is that Javascript-generated content can screw up your website's SEO when crawlers visit your site.
Using Javascript for your form validation is okay if your form will still work with Javascript disabled. Yes, the user will lose some functionality of not seeing pretty validations, but it's okay if they can still use your site. [1]
Where JS becomes a problem is when it's used in ways where disabling it completely breaks the page... Single page web apps: I'm looking at you.
-----
[1] One way to improve the experience of form input validations for Tor users could be to have both a JS runtime validation and server side validation of your form inputs, and then put the validation messages that both would generate in the same place so that they stay in sync.
I'd argue that single-page apps are a completely new emerging paradigm- the "web-page-as-application" rather than "web-page-as-interface-to-application" (or "webpage-as-hypertext-document", before that.) This isn't to say the previous two paradigms are bad, just that they're solving different problems. In light of that, here are a few responses to your points:
> Where JS becomes a problem is when it's used in ways where disabling it completely breaks the page... Single page web apps: I'm looking at you.
Here's my point: if you disable Javascript and navigate to a URL where a single-page app is hosted, the page isn't broken, your execution environment is. If I make a React app, then ipso facto I'm making an explicit choice to exclude folks that don't want to enable Javascript.
HOWEVER
> I think a more important point is that you should design your website to still be functional even if Javascript is disabled.
There's absolutely room on the Web for all three models: document, interface, and application. And despite my disagreement with this point when it comes to client-side applications, I definitely agree when it comes to Web documents and Web interfaces to server-side applications. (Rails muddied the water something fierce on that last one, which has been the source of uncountable headaches for me.)
I agree with what you're saying, but many, and I mean many, single page web applications get used for things that are essentially Web documents.
If you're building a game or something interactive, I get it. But many SPA's are used to give database-backed forms a pretty skin. It's the overuse of Javascript in this way, and the lack of graceful degradation for forms like this when Javascript is disabled, that I think is beginning to create concern.
you should design your website to still be functional even if Javascript is disabled
True, but irrelevant to the issue of "can you do X on the client side without Javascript?". I can imagine a Javascript form validator that somehow makes the form unusable with Javascript turned off, but I've sure never seen one.
And server-side validation is website 101 stuff that you should always be doing regardless of the front-end technology, not a counter to the many good uses of front-end validation.
I agree. Though sadly keeping your JS validation messages in sync with the ones your server produces can still be a surprisingly high amount of work and headache. Many people can think of the time it takes to build functionality like this as gold plating.
Or you can just respond with a "Bad Input" static HTML page.
Your Back End should be validating the Front End. As it is possible for people to make their own HTTP Post messages to your Back End. This is actually fairly trivial to do if you can use wireshark+curl/hippie/wget.
If you learn JavaScript, you would be learning an imperative language that shares many features with other languages, and you would be, as a resource, more flexible than if you just use CSS for everything.
It's powerful, flexible, supports classical and functional paradigms and can handle input validation and transformation better than most languages with less code.
It's the only reasonable cross platform client/server language which is well supported.
I can say this for (nearly) any dynamic language like python or ruby. Your second statement is plain wrong however. Take clojure for example which compiles to java bytecode and javascript (cljs) seamlessly. You seem to be a victim of the Blub paradox.
So let's show off what you can do without JavaScript...but also include SCSS as a dependency when the opening paragraph complains about a JavaScript dependency? Madness...but I digress.
Some of these are cool examples. Others, like the modal, won't scale very well because now you can trigger modals by tabbing (breaks keyboard navigation) or most of the form examples as you'll likely hit many endpoints that require JSON (which yeah I know "you're making a web app why can't your endpoints accept a form?" but as we all know it's never that simple and you might want to provide different behaviors for, say, showing a progress bar or disabling certain features during the submissions or a THOUSAND other things).
I get axing dependencies. I really do. I wrote msngr.js entirely in ECMAScript 5 using zero dependencies so I'd have the most flexibility possible. But at the same time overcomplicating your code to the point where it's breaking standard practices or making it un-maintainable simply to axe a dependency is the wrong way to go.
But by all means keep making cool stuff that shows off how versatile CSS is! Just don't expect to use all the CSS tricks you learn in a production environment.
Of course they're different but the article mentions JavaScript as a dependency. SCSS would also be a dependency it just comes into the stack at a different place but it's there nonetheless.
I never did conflate them. I've worked in this industry for 12 years now. I really don't get the disconnect here. I called it a dependency because it is and everyone is trying to tell me it's a different type of dependency. Well no shit but that was never my point to begin with.
The dependency thing was a minor quip at the start, it was never the point...the other 70% of the text was the point and unrelated to my dependency comment. I don't see anyone trying to say that, these comments seem as if my quip was the entire point of my post.
Talk about a tangent over a tiny, unremarkable comment that was meant to be light hearted.
SCSS is not a dependency for the user, this gets rid of the requirement of having JS and having it enabled and any page that works without JS is a better page than one that requires it.
You could go the other way just as easily, and eliminate the css requirement. Doesn't mean it's the best way to do a given thing.
Also, the examples don't support a lot of use cases... the accordian and tab examples, while interesting will submit goofy information if they're containing multi-part forms.
The image changer will break other bits of navigation, or similar changers by abusing the target. Similarly, the lightbox example doesn't have a slideshow support, and even if so, would probably be as/more complex than just using JS.
Also, how many of these examples work in IE11? This browser will be around a while for public facing sites, and has some really broken implementations of newer css features like calc (which doesn't work in several scenarios).
Amen. If you are really good at CSS, you might play to that strength. Or, you might play to different strengths. There's probably more than one way to do it in many cases that doesn't hurt the project.
I agree, but I think you're putting the emphasis in the wrong place. A SCSS dependency isn't that bad because the client will never see it.
What is bad is code that's hard to maintain. When I did a stint of front end development recently, I went in with the mindset that "JavaScript is evil for the user and therefore should not be used when avoidable". I discovered after a while that although you can replace JavaScript with CSS sometimes, the resulting code is often much more difficult to understand and modify than the original JavaScript would have been. It's no longer in my interest to avoid JavaScript at all costs, as was the case before.
You touch on this with your "overcomplicating" sentence, but I feel like it didn't get the spotlight it deserved in your comment!
Javascript is not evil, evil is when it's used unnecessarily, and when your page displaying 4-5 pages of text starts out 2mb without images and becomes 15mb as I scroll to bottom because you're pinging various third parties for analytics and whatnot, and when I can't view you pages where the essence is a couple paragraphs of text but you wanted to render it via Javascript and I have it blocked and you not whitelisted, and when I hesitate to use my schools web services for important things that may affect my academic career but god knows what's gonna break when on that halfe-arsed website, and especially when you mess with my history (my pet peeve).
These "you"s are rhetorical BTW, I'm not addressing kqr directly.
We-e-ell, it's not a good language. But it's what we have.
I agree, though, that it can be used well and does have a place in writing good web pages and sites, but that when it is used to create horrible 'web apps' it is being used for evil.
The first two were actually making a good point. This website (yours, presumably) is just jumping on the bandwagon and sticking an affiliate link in it. I'm not against affiliate links, but this site lacks substance.
The second one is the only one that puts any effort into actual legibility. There's a nice comfortable amount of space between the lines! The text doesn't render right at the edge of the page! There are MARGINS and WHITESPACE.
If you just take your browser's defaults for all the typographical stuff like that, everything looks like trash.
Honestly, I can't stand websites that decide to waste 70% of screen estate. I can see the first site almost without scrolling. It is 2 to 3 pages on the other iterations.
The only things I may agree with is https and zipping.
"Fits on all your shitty screens" Does mean that it FITS ON ALL YOUR SHITTY SCREENS. Mine is a 1920x1080 (which is the minimal nowadays) and the 2nd and third iterations DO NOT FIT IT.
That thing around the web page, it is called a fucking window. It resizes. I'll do that if I want your fucking column-format.
I remember one of my dev friends showed me this when jQuery was taking off. The site has changed over the years because back in the day when I first saw it, he was railing against using too much javascript - specifically jQuery.
None of these requires SCSS at all. You may verify by grabbing the SCSS they provide in the codepen and pasting it into http://www.sassmeister.com/
Most examples are equally compact in plain old CSS. In fact, many of them are just plain CSS displayed in a window labeled "SCSS".
The places using SCSS seem like they're simply being more sane in allowing a user to change numbers trivially. Instead of saying "just change all the 400px throughout to 500px", one can change the `$slide-width` definition in one place (usually at the top).
There's also the style preference of nesting to group. But neither of those make it a strict dependency.
---------
EDIT: I'm not saying that I disagree with your assertion that CSS is a bad place to layer logic from a maintainability standpoint; I'm more pointing out that blaming it on SCSS makes no sense in this context.
> I'm not saying that I disagree with your assertion that CSS is a bad place to layer logic from a maintainability standpoint; I'm more pointing out that blaming it on SCSS makes no sense in this context
I don't see where I blamed anything on SCSS just found it amusing the page purports to axe dependencies (JavaScript) but uses SCSS. The rest of my post is far more on topic and interesting. Everyone is focusing on my SCSS poke though, heh.
I certainly agree that the rest of the post makes sense and is more on topic! It's why I felt the need to add the statement at the end of my own stating that I agree with it, immediately after I posted it ;)
Re: requirement - there I was referring to your opening:
> So let's show off what you can do without JavaScript...but also include SCSS as a dependency when the opening paragraph complains about a JavaScript dependency? Madness...
And explaining that although they used SCSS, it certainly isn't a requirement, nor even much simpler than the plain CSS.
I'd guess that most of the responses probably focussed on it because leading statements are often read louder than what follows them. They set the mood/tone in a way.
The problem with using CSS for animations is that if the UX designers make a minor change to the spec, you might be forced to rip out the whole thing and redo it in JavaScript.
253 comments
[ 3.1 ms ] story [ 271 ms ] threadSurely they could have figured a way to do without them.
I expect my back button to open the previous page, not to move an image slider.
That aside, these are some pretty cool examples. Are there ways of doing this with CSS which doesn't screw with my browser back button?
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_v...
You update the value where your color variable is defined, and then each style declaration that uses the color variable receives the new value automatically.
I was surprised to see some Linux-style color picker pop up. It looks a lot like the one GIMP uses. Wonder if Firefox implemented that or they depend on something that does, and in the latter case, what's that dependency?
Though, this site is cool in showing the power of CSS, I am not sure if there is any specific advantage of using CSS over JS to design tabs, sliders, etc. Just use the best tool for the job!
Avoiding Javascript is an advantage if you want your website to be accessible to Tor users.
If your website only handles basic things like form inputs and it breaks when Javascript is disabled, then you have not made it accessible.
I still use Chrome for development, though.
Safari, is not as bad as IE6 was and anyway no professional front-end developer would make a website that is not working properly on iOS Safari, so it's kinda obvious it will stay supported for a long, long time.
So I would consider what the OP is doing with the CSS, something that might also work on Safari, but with some polyfills.
http://kangax.github.io/compat-table/es6/
Chrome/Google has terrible/no support of many browser layout & interaction features, such as CSS Regions & scroll snap points.
Also, Safari is just a much better browser than Chrome. We need to make sure people stop using Chrome and move to the default browser in their environment - Safari & Edge.
If you support the default browser, then you're going to be fine.
Hi, I'm Linux.
( By the way lynx is perfect to pierce through a lot of paywalls. )
The alternatives are Opera and Firefox. Everything else is like coding while wearing mittens.
It gets tedious switching the default browser setting over so I tend to just use Chrome for everything.
Not sure what old wives tales you have heard, but actually Safari was the first browser to 100% support ES6.
And compared to Chrome, it uses 1/3 less battery...
- Apple didn't attend EdgeConf 2015
- https://webkit.org/blog/ was not updated often enough
- Safari 9 had a seriously buggy IndexedDB (fixed in Safari 10)
I'm not the only one who think Safari is a joke compared to the competition. While IE6 was much much worse than what Safari is today, I feel like history is repeating itself again. And ES6 support is irrelevant when the main goal is to make sure websites renders and behave correctly, which is more painful for Safari than the other browsers.
I still have flexbox issues on Safari https://bugs.webkit.org/show_bug.cgi?id=136041
How does that opinion survive reality, e.g. Safari being the first browser to reach 100% ES6 compliance?
>I still have flexbox issues on Safari https://bugs.webkit.org/show_bug.cgi?id=136041*
So? All browsers still have Flexbox issues. Here are Chrome's:
https://bugs.chromium.org/p/chromium/issues/list?can=2&q=com...
Notably Fetch API and WebRTC for my use-cases.
Hopefully they'll figure it out eventually!
It's just my anecdotal view, but I believe that Chrome might be better for developers, but websites are made for the users, not the developers, and Safari is far superior on that front.
I can only assume you never went through the pain that IE6 delivered... It has been some years now but I still get nightmares about it. It literally made me question at one time if I didn't made the wrong choice to focus on web development.
Apple may be dragging its feet when adapting new api stuff, but the situation is by no means comparable as what the situation was with IE6. Not by a million miles.
FTFY :)
Often you're better of to do a mix of both, because some things that are very complicated in CSS are two-liners in JavaScript.
[0] https://www.youtube.com/watch?v=lTCukb6Zn3g
And vice-versa, in modern browsers! Best to have both in your toolbox, definitely.
Note the absurd metric (lines and spaces) to justify how the blown-up version is considered to be smaller. Also note that the article consequently talks about "Node code" even though they are talking about client-side JavaScript.
From the article:
Also, she called CSS "California Style Sheets" and called JS DOM manipulation "Node code".
Also, the header was obviously done in MS Paint.
Also, it's Jenn Schiffer.
It's fun to see what you can partially achieve without JavaScript, but there is no shame in using JavaScript sensibly to enhance the usefulness of a web site.
I don't see any features of this site which should require javascript, so they should probably "practise what they preach".
1. Classify each token (whether this is building up an AST or doing something more fuzzy/clever is immaterial for this discussion); 2. Construct a DOM tree (HTML) that is styled (CSS).
Step 1 does not have to happen client-side at all. Step 2 doesn't require JavaScript at all.
What's the lazy reason for not rendering that before serving the html page.
The image slider for example can't be paused. There's the CSS property "animation-play-state" which could have been used to do this, but that literally freezes the animation, whereas you typically don't care about the animation but don't want the slider to move on to the next image (i.e. finish the transition, then pause).
And of course depending on which browsers you're targetting, many of these are horrendously broken for most of your users.
Why do people try so hard not to use tools that make their life easier?
You might not need a car - you can walk. But it makes life easier and it just works!
Assuming you're more proficient in JS than CSS ;) With CSS3 I find some animation is easier w/ transitions and keyframes than JS.
For example, the modal that appears when you click on the button actually doesn't do things on "clicking" but focusing. This means if you tab over the button it'll load the modal, then tabbing away means the modal is gone. I can't tab into the content in the modal at all. How does that work with accessibility?
Though I generally dislike the idea of saying content isn't there by making it present in the document but invisible.
Edit - Some of the default behaviours are also a bit pants. In chrome, the form validation on a pattern starts working after I hit submit, then angrily shakes at me for every keypress until it's valid. Then, it ignores invalid input as I type more! Please never use this for phone numbers or credit card numbers. Stop requiring an exact format when what people type varies, and stop telling me I'm putting in something wrong when you ask for a phone number and I give you something that'll connect to me if you type into a phone.
Maxlength is not a validation it's just ignores any more letters you type. Quietly ignoring your users input is probably not what you want.
The "Would you prefer a banana or a cherry?" just shouts "Please match the requested format" if I type "a cherry". I know chrome has nothing else to go on other than "the regex wasn't matched" but it's a bad end user experience.
The tabs example is something I need to tab onto then use left and right, I assume because it's a radio box underneath, not a series of links. Are tabs really radio buttons?
The same for the accordion. Which I've found if I add any tabbable content inside them then I'm focused on a hidden item. Great. Tab onto "tab 1", hit tab, focus has disappeared and I'm now potentially going to click on random items I can't see. This is because although you want to pretend the content isn't there just because it's not visible, it's still there! It's in your document.
Sure, you might not need javascript. But maybe you should still use it.
Localized custom validation messages for the provided pattern should be added as part of HTML spec. Someone should follow up on that, because it'll probably be too much of a waste of time for me.
In the meantime, this works and gets around a bug in FF: http://stackoverflow.com/a/20189012
where setCustomValidity could provide any text, even localized text from some other source like a DB, potentially, since it's JS. Requires a modern browser, though.> Sure, you might not need javascript. But maybe you should still use it.
Yes, but if you are writing for a general audience, make sure it's accessible: http://webaim.org/techniques/javascript/
Someone should put together a site that, given a set of browser restrictions the user provides, gives examples of each of these to show the most accessible and standards-compliant version of the code to use, minimizing external libraries required, with and without localization, because not everyone has the resources to provide localized content, unless localization could be provided by a built-in library in the browser or OS, which would be another great project.
Yes, there are sites that provide a matrix of supported browsers, but I don't think that would be as simple to use; developers like copy-and-paste examples, for better or worse, e.g. StackOverflow.
That sounds like a reasonable addition. Perhaps a series of validators and messages?
> Yes, but if you are writing for a general audience, make sure it's accessible: http://webaim.org/techniques/javascript/
Very true. Thanks for the link.
> Someone should put together a site that, given a set of browser restrictions the user provides, gives examples of each of these to show the most accessible and standards-compliant version of the code to use, minimizing external libraries required, with and without localization, because not everyone has the resources to provide localized content, unless localization could be provided by a built-in library in the browser or OS, which would be another great project.
This is something I'd like to see, because apart from a few things I know to look for (tabbing, for example), I don't know how well various devices and settings do with different content. Consistent approaches also help people working on things like screenreaders.
Doesn't mean you should bruteforce everything with just one tech. CSS is hard to maintain.
- The modal dialog example
- Color picker
- Form validation
[0] http://gs.statcounter.com/#mobile+tablet-browser-ww-monthly-...
The validation examples and input types are a case in point. Even on browsers where they work, the alerts can't be styled and the behaviors can't be controlled.
It's not clear to me whether that's a problem. Isn't consistent UI a good thing? Isn't it faster to fill the forms correctly if alerts always appear in the same way?
My bad.
Do you know of any good reading material concerning these form validation popups?
From reading on MDN [0], they seem to be browser specific - like the Chrome connection tab [1] - but somewhat customisable via JS.
[0]: https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Form...
[1]: https://blog.digicert.com/understanding-the-google-chrome-co...
You should do the rest on the backend anyway.
Is it from the browser? Can someone explain?
Who goes first? Not me!
> You should do the rest on the backend anyway
Well yes, you should validate on the backend, but you shouldn't wait to only validate on the backend.
This works well enough for getting things done quickly, but it's hardly a good UX, and a far cry from "perfect enough," whatever that means.
Why? Because some users, such as those who use Tor, may have legitimate reasons to disable Javascript execution while browsing. Another reason is that Javascript-generated content can screw up your website's SEO when crawlers visit your site.
Using Javascript for your form validation is okay if your form will still work with Javascript disabled. Yes, the user will lose some functionality of not seeing pretty validations, but it's okay if they can still use your site. [1]
Where JS becomes a problem is when it's used in ways where disabling it completely breaks the page... Single page web apps: I'm looking at you.
-----
[1] One way to improve the experience of form input validations for Tor users could be to have both a JS runtime validation and server side validation of your form inputs, and then put the validation messages that both would generate in the same place so that they stay in sync.
> Where JS becomes a problem is when it's used in ways where disabling it completely breaks the page... Single page web apps: I'm looking at you.
Here's my point: if you disable Javascript and navigate to a URL where a single-page app is hosted, the page isn't broken, your execution environment is. If I make a React app, then ipso facto I'm making an explicit choice to exclude folks that don't want to enable Javascript.
HOWEVER
> I think a more important point is that you should design your website to still be functional even if Javascript is disabled.
There's absolutely room on the Web for all three models: document, interface, and application. And despite my disagreement with this point when it comes to client-side applications, I definitely agree when it comes to Web documents and Web interfaces to server-side applications. (Rails muddied the water something fierce on that last one, which has been the source of uncountable headaches for me.)
If you're building a game or something interactive, I get it. But many SPA's are used to give database-backed forms a pretty skin. It's the overuse of Javascript in this way, and the lack of graceful degradation for forms like this when Javascript is disabled, that I think is beginning to create concern.
True, but irrelevant to the issue of "can you do X on the client side without Javascript?". I can imagine a Javascript form validator that somehow makes the form unusable with Javascript turned off, but I've sure never seen one.
And server-side validation is website 101 stuff that you should always be doing regardless of the front-end technology, not a counter to the many good uses of front-end validation.
Your Back End should be validating the Front End. As it is possible for people to make their own HTTP Post messages to your Back End. This is actually fairly trivial to do if you can use wireshark+curl/hippie/wget.
I've never heard somebody say that. Can you elaborate?
It's the only reasonable cross platform client/server language which is well supported.
Some of these are cool examples. Others, like the modal, won't scale very well because now you can trigger modals by tabbing (breaks keyboard navigation) or most of the form examples as you'll likely hit many endpoints that require JSON (which yeah I know "you're making a web app why can't your endpoints accept a form?" but as we all know it's never that simple and you might want to provide different behaviors for, say, showing a progress bar or disabling certain features during the submissions or a THOUSAND other things).
I get axing dependencies. I really do. I wrote msngr.js entirely in ECMAScript 5 using zero dependencies so I'd have the most flexibility possible. But at the same time overcomplicating your code to the point where it's breaking standard practices or making it un-maintainable simply to axe a dependency is the wrong way to go.
But by all means keep making cool stuff that shows off how versatile CSS is! Just don't expect to use all the CSS tricks you learn in a production environment.
Regardless my other points still stand.
My point was hijacked and contorted here.
Talk about a tangent over a tiny, unremarkable comment that was meant to be light hearted.
Also, the examples don't support a lot of use cases... the accordian and tab examples, while interesting will submit goofy information if they're containing multi-part forms.
The image changer will break other bits of navigation, or similar changers by abusing the target. Similarly, the lightbox example doesn't have a slideshow support, and even if so, would probably be as/more complex than just using JS.
Also, how many of these examples work in IE11? This browser will be around a while for public facing sites, and has some really broken implementations of newer css features like calc (which doesn't work in several scenarios).
What is bad is code that's hard to maintain. When I did a stint of front end development recently, I went in with the mindset that "JavaScript is evil for the user and therefore should not be used when avoidable". I discovered after a while that although you can replace JavaScript with CSS sometimes, the resulting code is often much more difficult to understand and modify than the original JavaScript would have been. It's no longer in my interest to avoid JavaScript at all costs, as was the case before.
You touch on this with your "overcomplicating" sentence, but I feel like it didn't get the spotlight it deserved in your comment!
These "you"s are rhetorical BTW, I'm not addressing kqr directly.
We-e-ell, it's not a good language. But it's what we have.
I agree, though, that it can be used well and does have a place in writing good web pages and sites, but that when it is used to create horrible 'web apps' it is being used for evil.
If you just take your browser's defaults for all the typographical stuff like that, everything looks like trash.
The only things I may agree with is https and zipping.
"Fits on all your shitty screens" Does mean that it FITS ON ALL YOUR SHITTY SCREENS. Mine is a 1920x1080 (which is the minimal nowadays) and the 2nd and third iterations DO NOT FIT IT.
That thing around the web page, it is called a fucking window. It resizes. I'll do that if I want your fucking column-format.
14 style rulesets.
Most examples are equally compact in plain old CSS. In fact, many of them are just plain CSS displayed in a window labeled "SCSS".
The places using SCSS seem like they're simply being more sane in allowing a user to change numbers trivially. Instead of saying "just change all the 400px throughout to 500px", one can change the `$slide-width` definition in one place (usually at the top).
There's also the style preference of nesting to group. But neither of those make it a strict dependency.
---------
EDIT: I'm not saying that I disagree with your assertion that CSS is a bad place to layer logic from a maintainability standpoint; I'm more pointing out that blaming it on SCSS makes no sense in this context.
I don't see where I blamed anything on SCSS just found it amusing the page purports to axe dependencies (JavaScript) but uses SCSS. The rest of my post is far more on topic and interesting. Everyone is focusing on my SCSS poke though, heh.
Re: requirement - there I was referring to your opening:
> So let's show off what you can do without JavaScript...but also include SCSS as a dependency when the opening paragraph complains about a JavaScript dependency? Madness...
And explaining that although they used SCSS, it certainly isn't a requirement, nor even much simpler than the plain CSS.
I'd guess that most of the responses probably focussed on it because leading statements are often read louder than what follows them. They set the mood/tone in a way.