Select Page

Category: progressive enhancement

Using <details> for Menus and Dialogs is an Interesting Idea

One of the most empowering things you can learn as a new front-end developer who is starting to learn JavaScript is to change classes. If you can change classes, you can use your CSS skills to control a lot on a page. Toggle a class to one thing, style it this way, toggle to another class (or remove it) and style it another way. But there is an HTML element that also does toggles! ! For example, it’s definitely the quickest way to build an accordion UI. Extending that toggle-based thinking, what is a user menu if not for...

Read More

How @supports Works

CSS has a neat feature that allows us to test if the browser supports a particular property or property:value combination before applying a block of styles — like how a @media query matches when, say, the width of the browser window is narrower than some specified size and then the CSS within it takes effect. In the same spirit, the CSS inside this feature will take effect when the property:value pair being tested is supported in the current browser. That feature is called @supports and it looks like this: @supports (display: grid) { .main { display: grid; } } Why? Well, that’s a bit tricky. Personally, I find don’t need it all that regularly. CSS has natural fallback mechanisms such that if the browser doesn’t understand a property:value combination, then it will ignore it and use something declared before it if there is anything, thanks to the cascade. Sometimes that can be used to deal with fallbacks and the end result is a bit less verbose. I’m certainly not a it’s-gotta-be-the-same-in-every-browser kinda guy, but I’m also not a write-elaborate-fallbacks-to-get-close kinda guy either. I generally prefer a situation where a natural failure of a property:value doesn’t do anything drastic to destroy functionality. That said, @supports certainly has use cases! And as I found out while putting this post together, plenty of people use it for plenty of interesting situations. A...

Read More

Nobody is quite wrong.

There are two opposing views on using non-polyfillable new web features that I find are both equally common in our industry: Websites don’t need to look the same in every browser. The concept of progressive enhancement helps with that. There are tools, even native language features, that help with this. If browser support isn’t where I want it to be, it’s just exotic eye candy for demos and not to be used. I’m not sure I’d say either one of these is more or less correct than the other. I also imagine it doesn’t come as much of surprise that I support the thinking behind #1. It’s perfectly possible to design and implement things that behave differently in different browsers and conditions. That’s essentially what responsive design is, and that’s pretty much the entire internet now. The backbone of progressive enhancement is starting with a working foundation that works everywhere and layering design and functionality on top of that, when possible. There are even native language features to support the idea. @supports rules allow us to write CSS that can do something if a feature is supported and do something else if it isn’t. This is the entire use case for Modernizr and it has 22,804 stars. I don’t want to argue against progressive enhancement. Remember, I just said I support that thinking. But I do have some empathy...

Read More

New mobile Chrome feature would disable scripts on slow connections

This is a possible upcoming feature for mobile Chrome: If a Data Saver user is on a 2G-speed or slower network according to the NetInfo API, Chrome disables scripts and sends an intervention header on every resource request. Users are shown a UI at the bottom of the screen indicating the page has been modified to save data. Users can enable scripts on the page by tapping “Show original” in the UI. And the people shout: progressive enhancement! Jeremy Keith: An excellent idea for people in low-bandwidth situations: automatically disable JavaScript. As long as the site is built with progressive enhancement, there’s no problem (and if not, the user is presented with the choice to enable scripts). Power to the people! This reminds me of the importance of a very useful building strategy called “Progressive Enhancement” 👀 🙌🏻 https://t.co/H4KHu9AzZC — Sara Soueidan (@SaraSoueidan) August 27, 2018 Did you bet on JavaScript or are you gambling with JavaScript?https://t.co/uYULr5F9oj — Zach Leatherman (@zachleat) August 27, 2018 George Burduli reports: This is huge news for developing countries where mobile data packets may cost a lot and are not be affordable to all. Enabling NoScript by default will make sure that users don’t burn through their data without knowledge. The feature will probably be available in the Chrome 69, which will also come with the new Material Design refresh. The post New mobile...

Read More
www.000webhost.com