3 ms·
I completely agree, but the question remains what experience do we provide when JavaScript is not available? (Progressive enhancement isn't just for "people who
by deadA1ias 10y ago
I completely agree, but the question remains what experience do we provide when JavaScript is not available? (Progressive enhancement isn't just for "people who turn off JavaScript", it's an defensive approach to providing inclusive, universal solutions on the web. Something I feel is lacking in the modern, front-end developer's worldview.)
- Periodic 10y agoYou're back to the case of having one static page and then having your javascript enhance things as you go. You'll be stuck replacing elements with your JS. I still think it's a great way to think about how we render on things like mobile. Ever get those slow-loading pages where the elements jump all over the place? Or half-way through reading an article the pop-up add finally renders? We need to build those into the baseline. Fortunately, we can reliably depend on javascript now. What we cannot rely on is internet/processing speed. I've always found progressive enhancement to work best as an additive process. You want to define the functionality of your page and then add enhancements and verify that the base functionality still holds. If you start from the most complex behavior it is a lot harder to reason about how removing functionality might hurt the page.
- Touche 10y agoHow would you do a progress bar without JavaScript? Well, you wouldn't. So custom elements don't affect progressive enhancement as far as I can see. They enhance the DOM when JavaScript is available and when its not they are essential a div.
- dsego 10y agoWhy isn't there a skinnable native progress-bar widget?
- apconan 10y agolol it's 2016, we ignore people who have javascript turned off