Browser Detection is Bad
▻https://css-tricks.com/browser-detection-is-bad
“The whole reason that web standards exist is so that we don’t have to write specific code for specific environments. We should write code that adheres to established standards and software in charge of displaying our code should display it as the standards dictate.”
5 Reasons Why Browser Sniffing Stinks
▻https://www.sitepoint.com/why-browser-sniffing-stinks
“Browser sniffing is the act of detecting the web browser a visitor is using in order to serve version-specific pages, scripts, images, or other content. The technique was popular around 10 years ago because Microsoft and Netscape introduced their own technologies and web standards were in their infancy. In those dark days, it was fairly common to write two or more client-side scripts to implement identical functionality in different browsers.”
Resilient Web Design
►https://resilientwebdesign.com
temps de lecture - 1 heure
The World Wide Web has been around for long enough now that we can begin to evaluate the twists and turns of its evolution. I wrote this book to highlight some of the approaches to web design that have proven to be resilient. I didn’t do this purely out of historical interest (although I am fascinated by the already rich history of our young industry). In learning from the past, I believe we can better prepare for the future.
You won’t find any code in here to help you build better websites. But you will find ideas and approaches. Ideas are more resilient than code. I’ve tried to combine the most resilient ideas from the history of web design into an approach for building the websites of the future.
Citations
Java is to JavaScript as ham is to hamster.
C’est marrant. Mais il y a des informations sérieuses aussi.
2.0
The rise of JavaScript was boosted in 2005 with the publication of an article entitled Ajax: A New Approach to Web Applications by Jesse James Garrett. The article put a name to a technique that was gaining popularity. Using a specific subset of JavaScript, it was possible for a web browser to send and receive data from a web server without refreshing the whole page. The result was a smoother user experience.
The term Ajax was coined at the same time that another neologism was in the ascendent. Tim O’Reilly used the phrase Web 2.0 to describe a new wave of web products and services. Unlike Ajax, it was difficult to pin down a definition of Web 2.0. For business people, it meant new business models. For graphic designers, it meant rounded corners and gradients. For developers, it meant JavaScript and Ajax.
... puis ...
Stuart Langridge put together a list of all the potential points of failure under the title Everyone has JavaScript, right?
...
This doesn’t mean that web designers shouldn’t use JavaScript. But it does mean that web designers shouldn’t rely on JavaScript when a simpler solution exists.
...A platform provides a controlled runtime environment for software. As long as the user has that runtime environment, you can be confident that they will get exactly what you’ve designed. If you build an iOS app and someone has an iOS device, you know that they will get 100% of your software. But if you build an iOS app and someone has an Android device, they will get 0% of your software. You can’t install an iOS app on an Android device. It’s all or nothing.
The web isn’t as binary as that. If you build something using web technologies, and someone visits with a web browser, you can’t be sure how many of the web technologies will be supported. It probably won’t be 100%. But it’s also unlikely to be 0%. Some people will visit with iOS devices. Others will visit with Android devices. Some people will get 80% or 90% of what you’ve designed. Others will get just 20%, 30%, or 50%. The web isn’t a platform. It’s a continuum.
To paraphrase Karl Marx, progressive enhancement allows designers to ask from each browser according to its ability, and to deliver to each device according to its needs.
►http://dowebsitesneedtolookexactlythesameineverybrowser.com
Feature detection, cutting the mustard, whatever you want to call it, is a fairly straightforward technique. Let’s say you want to traverse the DOM using querySelector and attach events to some nodes in the document using addEventListener. Your mustard‐cutting logic might look something like this:
if (document.querySelector && window.addEventListener) {
// Enhance!
}
There are two points to note here:
This is feature detection, not browser detection. Instead of asking “which browser are you?” and trying to infer feature support from the answer, it is safer to simply ask “do you support this feature?”
There is no else statement.
As Brad Frost puts it:
“There is a difference between support and optimization.”
Support every browser ...but optimise for none.
“Always design a thing by considering it in its next larger context”
...
Here’s a three‐step approach I take to web design:
– Identify core functionality.
– Make that functionality available using the simplest possible technology.
– Enhance!
Building resilient websites is challenging. It takes time to apply functionality and features in a considered layered way. The payoff is a website that can better react to unexpected circumstances—unusual browsers, flaky network connections, outdated devices. Nonetheless, for many web designers, the cost in time seems to be too high.
Behaviour change is hard. Even if you are convinced of the benefits of a resilient approach to web design, you may find yourself struggling to convince your colleagues, your boss, or your clients. It was ever thus. Take comfort from the history of web standards and responsive design. Those approaches were eventually adopted by people who were initially resistant.
Demonstrating the benefits of progressive enhancement can be tricky. Because the payoff happens in unexpected circumstances, the layered approach is hard to sell. Most people will never even know whether or not a site has been built in a resilient way. It’s a hidden mark of quality that will go unnoticed by people with modern browsers on new devices with fast network connections.
For that same reason, you can start to implement this layered approach without having to convince your colleagues, your boss, or your clients. If they don’t care, then they also won’t notice. As Grace Hopper also said, “it’s easier to ask forgiveness than it is to get permission.”
Realising that it was impossible to be future‐proof, we instead resolved to be future-friendly:
Acknowledge and embrace unpredictability.
Think and behave in a future-friendly way.
Help others do the same.
That first step is the most important: acknowledging and embracing unpredictability. That is the driving force behind resilient web design. The best way to be future-friendly is to be backwards‐compatible.
The future, like the web, is unknown.
The future, like the web, will be written by you.
Alerte Web libre: Inside Google’s plan to make the whole web as fast as AMP - The Verge
►https://www.theverge.com/2018/3/8/17095078/google-amp-accelerated-mobile-page-announcement-standard-web-packaging-url
In a blog post today, Google is announcing that it’s formally embarking on a project to convince the group in charge of web standards to adopt technology inspired by its Accelerated Mobile Pages (AMP) framework. In theory, it would mean that virtually any webpage could gain the same benefits as AMP: near-instantaneous loading, distribution on multiple platforms, and (critically) more prominent placement on Google properties.
This sounds impenetrably dense and boring, but please don’t click away yet! This is important, a little tricky to understand, and critical to how the web and Google interact in the future. In many ways, Google’s success or failure in this endeavor will play a major role in shaping how the web works on your phone.
If you’re unfamiliar, AMP is Google’s attempt to make webpages as fast and portable as other “instant articles” (like what you might read on Facebook or Apple News). The idea is that when you click a link on those other platforms, you don’t have to wait for the article to load because it’s already preloaded in an app. AMP’s goal is to bring the same performance to the web itself.
“Google walked right into the center of a thicket”
By creating AMP, Google blithely walked right into the center of a thicket comprised of developers concerned about the future of the web. Publishers are worried about ceding too much control of their distribution to gigantic tech companies, and all of the above are worried that Google is not so much a steward of the web but rather its nefarious puppet master.
All that angst has metastasized in the past few months, with a widely circulated open letter to Google asking it to fix AMP, more Medium blog posts than can be read in a week, Twitter screeds, and arguments in the comments of AMP’s own GitHub code repository. And that’s only the stuff coming from web developers. (I keep a folder of bookmarks I call “AMPhole” to try to keep up, and that hole gets deeper nearly every day.)
The whole situation is slightly frustrating to David Besbris, VP of search engineering at Google. Earlier this week, I went to Mountain View to talk with Besbris and Malte Ubl, engineering lead for AMP. “This is honestly a fairly altruistic project from our perspective,” says Besbris.
”It wasn’t like we invented AMP because we wanted to control everything, like people assume,” he says. Instead, he argues, go back and look at how dire the state of the mobile web was a few years ago, before AMP’s inception. It sucked — in fact, Nilay Patel published a story on this very website titled “The mobile web sucks” in 2015. He was right. Apple and Facebook dealt with that problem by creating proprietary formats and then convinced publishers to distribute their news in those formats on their platforms. As Nilay wrote:
Taken together, Apple News and Facebook Instant Articles are the saddest refutation of the open web revolution possible: they are incompatible proprietary publishing systems entirely under the control of huge corporations, neither of which particularly understands publishing or media.
Google’s AMP is a gilded cage – Terence Eden’s Blog
▻https://shkspr.mobi/blog/2016/11/removing-your-site-from-amp
Retour d’expérience d’un bloggeur qui a activé AMP, puis a décidé le désactiver au bout d’un moment, et qui se trouva fort dépourvu : toutes ses pages en 404.
AMP, tu y adhères, tu n’en sors plus.
Le gars ne semble connaître ni les RewriteRules ni PHP...
Sur le même sujet :
Switching to Google AMP and back
Today I’m switching back from AMP to regular HTML. One reason is that I found that Disqus didn’t always reliably resizes, but there’s a few others.
I’ve always been pretty big on web standards, and AMP is basically a deviation from that. I really didn’t enjoy changing my <img> to <amp-img> tags. The weird boilerplate and new dependency on javascript didn’t help either. I believe my blog should be useful and useable in in places where Javascript is not enabled, and after removing AMP, this is true once more.
I believe that web standards will always win, so bending to the will of Google Engineers that make the web less open for something that is likely a fad didn’t seem right to me.
Another issue is that google effectively takes over your traffic, and replaces your url with their own. This means that if people want to share a link to your site, they’ll link to google, not you.
I still like the idea of AMP, and I would be happy to restrict myself to a stricter subset of HTML and CSS for better performance and to be allowed to be preloaded in google search results on mobile, but I refuse to tie myself to a superset.
The real question I would have though, is why didn’t they just use Atom or RSS for this?
►https://d3js.org
D3.js is a JavaScript library for manipulating documents based on data. D3 helps you bring data to life using HTML, SVG, and CSS. D3’s emphasis on web standards gives you the full capabilities of modern browsers without tying yourself to a proprietary framework, combining powerful visualization components and a data-driven approach to DOM manipulation.
Web-First Data Citations
▻https://research.science.ai/article/web-first-data-citations
We identify a set of properties desirable in a concrete implementation of data citations, considering the full publishing pipeline as well as the needs of landing pages for datasets. Building on top of these properties, we describe the specific implementation approach that we take, built completely on top of Web standards. Web technology is found once again to be awesome and more versatile than people expect.
(Une pré-version publiée ailleurs, c’est là la version finale/officielle.)
MicrosoftDX/grunt-webstandards · GitHub
▻https://github.com/MicrosoftDX/grunt-webstandards
"grunt-webstandards is a #Grunt plugin that improves your site with modern web standards. It checks if your website is using correct CSS prefixes, using up to date JavaScript libraries, using responsive web design, if you’re defining platform icons, … Tags: Grunt #Gulp qualité #clevermarks #VorlonJS
The App-ocalypse: Can Web standards make mobile apps obsolete? | Ars Technica
▻http://arstechnica.com/information-technology/2015/12/the-app-ocalypse-can-web-standards-make-mobile-apps-obsolete/?comments=1&post=30354823
this article assumes that Firefox OS development for smartphones has ceased. It has not, in fact it’s soon going to #support more phones than it ever did before (Sony, Fairphone, Nexus and all CyanogenMod-supported devices) and with a far easier inst… Tags: #FirefoxOS #matériel support #installation #clevermarks
BBC betrays the public, demands DRM for HTML5 - Boing Boing
▻http://boingboing.net/2013/02/16/bbc-betrays-the-public-demand.html
You may have heard that a group of batshit insane entertainment shills have asked the W3C (the standards body responsible for Web standards) to put “DRM” — magic beans anti-copying stuff — into HTML5. Shamefully, the BBC — a publicly funded organisation, chartered to act in the public interest — is one of the forces pushing for adding stuff to HTML that will make your browser hide things from you, disobey you, and say “I can’t let you do that, Dave.” Naturally, also requires a ban on free/open source software, because if your browser is open, you could just disable the “I can’t let you do that, Dave,” program.
▻http://blogs.computerworlduk.com/open-enterprise/2013/02/bbc-attacks-the-open-web-gnulinux-in-danger/index.htm
C’est pas tout à fait ça. Le problème est un peu plus compliqué.
voir aussi ►http://seenthis.net/messages/114021
Sexy // Web Typography for the Lonely
►http://webtypographyforthelonely.com
Web Typography for the Lonely aims to excite designers about the possibilities of cutting-edge web standards and javascript through beautiful and inspiring typographic explorations.
Même eux // IE6 Countdown
►http://ie6countdown.com
10 years ago a
#browser was born.
Its name was Internet #Explorer 6. Now that we’re in 2011, in an era of modern web standards, it’s time to say goodbye.
This website is dedicated to watching Internet Explorer 6 usage drop to less than 1% worldwide, so more websites can choose to drop support for Internet Explorer 6, saving hours of work for web developers.
Mozilla Labs » #Chromeless #Browser 0.1
►http://mozillalabs.com/chromeless/?p=26
Pour construire une appli à base de html/js/css :
Chromeless is an experimental toolkit to make it possible to prototype browser applications using HTML, JavaScript and related Web standards.