It made me learn about http://caniuse.com/#feat=input-pattern ; thanks for that!
Same. Didn't even knew that exists. Awesome.
Same here and it seems fucking amazing. I'm beginning to wonder how many more html-things like this I don't know about?
You might not need JavaScript
111–120 of 254 posts
Re: You might not need JavaScript
#112Earlier quoted context omitted.
> Safari is the new IE6, stop supporting it and let it die. 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...
He is parroting a year old clickbait headline ( https://nolanlawson.com/2015/06/30/safari-is-the-new-ie/ ) where the main gripes were that - 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 would rather refer to this https://news.ycombinator.com/item?id=12051267
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
Re: You might not need JavaScript
#113But I need my site to work in IE9 too.
Re: You might not need JavaScript
#114You might not, but you probably do. 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.
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.
Re: You might not need JavaScript
#115It's funny that all the examples previews use CodePen and,
>Codepen requires JavaScript to render the code and preview areas in this view.
Re: You might not need JavaScript
#116Does anyone else feel that a site called "You Might Not Need Javascript", probably shouldn't use Javascript?
This website does not need JavaScript. It's progressively enhanced with it.
Re: You might not need JavaScript
#117The 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!
Re: You might not need JavaScript
#118I'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…
> 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.
In the meantime, this works and gets around a bug in FF: http://stackoverflow.com/a/20189012
> 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.
Re: You might not need JavaScript
#119The site makes no claims as such, but it undermines its own credibility if it uses .js files. Surely they could have figured a way to do without them.
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.
Re: You might not need JavaScript
#120It'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 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.
I think you've hit the nail on the head here.