[Insert Clickbait Headline About Progressive Enhancement Here]

Published

06 December 2016

Reading Time

24 minutes

Tagged

progressive enhancement web design javascript

Reactions

Comments
152 Webmentions

Crossposted

Medium

Paying for Hosting

Late last week, Josh Korr, a project manager at Viget, posted at length about what he sees as a fundamental flaw with the argument for progressive enhancement. In reading the post, it became clear to me that Josh really doesn’t have a good grasp on progressive enhancement or the reasons its proponents think it’s a good philosophy to follow. Despite claiming to be “an expert at spotting fuzzy rhetoric and teasing out what’s really being said”, Josh makes a lot of false assumptions and inferences. My response would not have fit in a comment, so here it is…

Before I dive in, it’s worth noting that Josh admits that he is not a developer. As such, he can’t really speak to the bits where the rubber really meets the road with respect to progressive enhancement. Instead, he focuses on the argument for it, which he sees as a purely moral one… and a flimsily moral one at that.

I’m also unsure as to how Josh would characterize me. I don’t think I fit his mold of PE “hard-liners”, but since I’ve written two books and countless articles on the subject and he quotes me in the piece, I’ll go out on a limb and say he probably thinks I am.

Ok, enough with the preliminaries, let’s jump over to his piece…

Right out of the gate, Josh demonstrates a fundamental misread of progressive enhancement. If I had to guess, it probably stems from his source material, but he sees progressive enhancement as a moral argument:

It’s a moral imperative that everything on the web should be available to everyone everywhere all the time. Failing to achieve — or at least strive for — that goal is inhumane.

Now he’s quick to admit that no one has ever explicitly said this, but this is his takeaway from the articles and posts he’s read. It’s a pretty harsh, black & white, you’re either with us or against us sort of statement that has so many people picking sides and lobbing rocks and other heavy objects at anyone who disagrees with them. And everyone he quotes in the piece as examples of why he thinks this is progressive enhancement’s central conceit is much more of an “it depends” sort of person.

To clarify, progressive enhancement is neither moral or amoral. It’s a philosophy that recognizes the nature of the Web as a medium and asks us to think about how to build products that are robust and capable of reaching as many potential customers as possible. It isn’t concerned with any particular technology, it simply asks that we look at each tool we use with a critical eye and consider both its benefits and drawbacks. And it’s certainly not anti-JavaScript.

I could go on, but let’s circle back to Josh’s piece. Off the bat he makes some pretty bold claims about what he intends to prove in this piece:

Progressive enhancement is a philosophical, moral argument disguised as a practical approach to web development.
This makes it impossible to engage with at a practical level.
When exposed to scrutiny, that moral argument falls apart.
Therefore, if PEers can’t find a different argument, it’s ok for everyone else to get on with their lives.

For the record, I plan to address his arguments quite practically. As I mentioned, progressive enhancement is not solely founded on morality, though that can certainly be viewed as a facet. The reality is that progressive enhancement is quite pragmatic, addressing the Web as it exists not as we might hope that it exists or how we experience it.

Over the course of a few sections—which I wish I could link to directly, but alas, the headings don’t have unique ids—he examines a handful of quotes and attempts to tease out their hidden meaning by following the LSAT’s Logic Reasoning framework. We’ll start with the first one.

Working without JavaScript

Statement
“When we write JavaScript, it’s critical that we recognize that we can’t be guaranteed it will run.” — Aaron Gustafson
“If you make your core tasks dependent on JavaScript, some of your potential users will inevitably be left out in the cold.” — Jeremy Keith
Unstated assumptions:
Because there is some chance JavaScript won’t run, we must always account for that chance.
Core tasks can always be achieved without JavaScript.
It is always bad to ignore some potential users for any reason.

His first attempt at teasing out the meaning of these statements comes close, but ignores some critical word choices. First off, neither Jeremy nor I speak in absolutes. As I mentioned before, we (and the other folks he quotes) all believe that the right technical choices for a project depend on specifically on the purpose and goals of that specific project. In other words it depends. We intentionally avoid absolutist words like “always” (which, incidentally, Josh has no problem throwing around, on his own or on our behalf).

For the development of most websites, the benefits of following a progressive enhancement philosophy far outweigh the cost of doing so. I’m hoping Josh will take a few minutes to read my post on the true cost of progressive enhancement in relation to actual client projects. As a project manager, I hope he’d find it enlightening and useful.

It’s also worth noting that he’s not considering the reason we make statements like this: Many sites rely 100% on JavaScript without needing to. The reasons why sites (like news sites, for instance) are built to be completely reliant on a fragile technology is somewhat irrelevant. But what isn’t irrelevant is that it happens. Often. That’s why I said “it’s critical that we recognize that we can’t be guaranteed it will run” (emphasis mine). A lack of acknowledgement of JavaScript’s fragility is one of the main problems I see with web development today. I suspect Jeremy and everyone else quoted in the post feels exactly the same. To be successful in a medium, you need to understand the medium. And the (sad, troubling, interesting) reality of the Web is that we don’t control a whole lot. We certainly control a whole lot less than we often believe we do.

As I mentioned, I disagree with his characterization of the argument for progressive enhancement being a moral one. Morality can certainly be one argument for progressive enhancement, and as a proponent of egalitarianism I certainly see that. But it’s not the only one. If you’re in business, there are a few really good business-y reasons to embrace progressive enhancement:

Legal: Progressive enhancement and accessibility are very closely tied. Whether brought by legitimate groups or opportunists, lawsuits over the accessibility of your web presence can happen; following progressive enhancement may help you avoid them.
Development Costs: As I mentioned earlier, progressive enhancement is a more cost-effective approach, especially for long-lived projects. Here’s that link again: The True Cost of Progressive Enhancement.
Reach: The more means by which you enable users to access your products, information, etc., the more opportunities you create to earn their business. Consider that no one thought folks would buy big-ticket items on mobile just a few short years ago. Boy, were they wrong. Folks buy cars, planes, and more from their tablets and smartphones on the regular these days.
Reliability: When your site is down, not only do you lose potential customers, you run the risk of losing existing ones too. There have been numerous incidents where big sites got hosed due to JavaScript dependencies and they didn’t have a fallback. Progressive enhancement ensures users can always do what they came to your site to do, even if it’s not the ideal experience.

Hmm, no moral arguments for progressive enhancement there… but let’s continue.

Some experience vs. no experience

Statement
“[With a PE approach,] Older browsers get a clunky experience with full page refreshes, but that’s still much, much better than giving them nothing at all.” — Jeremy Keith
“If for some reason JavaScript breaks, the site should still work and look good. If the CSS doesn’t load correctly, the HTML content should still be there with meaningful hyperlinks.” — Nick Pettit
Unstated assumptions:
A clunky experience is always better than no experience.
HTML content — i.e. text, images, unstyled forms — is the most important part of most websites.

You may be surprised to hear that I have no issue with Josh’s distillation here. Clunky is a bit of a loaded word, but I agree that an experience is better than no experience, especially for critical tasks like checking your bank account, registering to vote, making a purchase from an online shop. In my book, I talk a little bit about a strange thing we experienced when A List Apart stopped delivering CSS to Netscape Navigator 4 way back in 2001:

We assume that those who choose to keep using 4.0 browsers have reasons for doing so; we also assume that most of those folks don’t really care about “design issues.” They just want information, and with this approach they can still get the information they seek. In fact, since we began hiding the design from non–compliant browsers in February 2001, ALA’s Netscape 4 readership has increased, from about 6% to about 11%.

Folks come to our web offerings for a reason. Sometimes its to gather information, sometimes it’s to be entertained, sometimes it’s to make a purchase. It’s in our best interest to remove every potential obstacle that can preclude them from doing that. That’s good customer service.

Project priorities

Statement
“Question any approach to the web where fancy features for a few are prioritized & basic access is something you’ll ‘get to’ eventually.” — Tim Kadlec
Unstated assumptions:
Everything beyond HTML content is superfluous fanciness.
It’s morally problematic if some users cannot access features built with JavaScript.

Not to put words in Tim’s mouth (like Josh is here), but what Tim’s quote is discussing is hype-driven (as opposed to user-centered) design. We (as developers) often prioritize our own convenience/excitement/interest over our users’ actual needs. It doesn’t happen all the time (note I said often), but it happens frequently enough to require us to call it out now and again (as Tim did here).

As for the “unstated assumptions”, I know for a fact that Tim would never call “everything beyond HTML” superfluous. What he is saying is that we should question—as in weigh the pros and cons—of each and every design pattern and development practice we consider. It’s important to do this because there are always tradeoffs. Some considerations that should be on your list include:

Download speed;
Time to interactivity;
Interaction performance;
Perceived performance;
Input methods;
User experience;
Screen size & orientation;
Visual hierarchy;
Aesthetic design;
Contrast;
Readability;
Text equivalents of rich interfaces for visually impaired users and headless UIs;
Fallbacks; and
Copywriting.

This list is by no means exhaustive nor is it in any particular order; it’s what came immediately to mind for me. Some interfaces may have fewer or more considerations as each is different. And some of these considerations might be in opposition to others depending on the interface. It’s critical that we consider the implications of our design decisions by weighing them against one another before we make any sort of decision about how to progress. Otherwise we open ourselves up to potential problems and the cost of changing things goes up the further into a project we are:

The cost of changing your mind goes up the further into any project you are. Just ask any contractor you hire to work on your house.

As a project manager, I’m sure Josh understands this reality.

As to the “morally problematic” bit, I’ll refer back to my earlier discussion of business considerations. Sure, morality can certainly be part of it, but I’d argue that it’s unwise to make assumptions about your users regardless. It’s easy to fall into the trap of thinking that all of or users are like us (or like the personas we come up with). My employer, Microsoft, makes a great case for why we should avoid doing this in their Inclusive Design materials:

When we design only for others like us, we exclude everyone who is not like us.

If you’re in business, it doesn’t pay to exclude potential customers (or alienate current ones).

Erecting unnecessary barriers

Statement
“Everyone deserves access to the sum of all human knowledge.” — Nick Pettit
“[The web is] built with a set of principles that — much like the principles underlying the internet itself — are founded on ideas of universality and accessibility. ‘Universal access’ is a pretty good rallying cry for the web.” — Jeremy Keith
“The minute we start giving the middle finger to these other platforms, devices and browsers is the minute where the concept of The Web starts to erode. Because now it’s not about universal access to information, knowledge and interactivity. It’s about catering to the best of breed and leaving everyone else in the cold.” — Brad Frost
Unstated assumptions:
What’s on the web comprises the sum of human knowledge.
Progressive enhancement is fundamentally about universal access to this sum of human knowledge.
It is always immoral if something on the web isn’t available to everyone.

I don’t think anyone quoted here would argue that the Web (taken in its entirety) is “the sum of all human knowledge”—Nick, I imagine, was using that phrase somewhat hyperbolically. But there is a lot of information on the Web folks should have access too, whether from a business standpoint or a legal one. What Nick, Jeremy, and Brad are really highlighting here is that we often make somewhat arbitrary design & development decisions that can block access to useful or necessary information and interactions.

In my talk Designing with Empathy (slides), I discussed “mystery meat” navigation. I can’t imagine any designer sets out to make their site difficult to navigate, but we are influenced by what we see (and are inspired by) on the web. Some folks took inspiration from web-based art projects like this Toyota microsite:

On Toyota’s Mind is a classic example of mystery meat navigation. It’s a Flash site and you can navigate when you happen to mouse over "hotspots" in the design. I’m pointing to one with a big red arrow here.

Though probably not directly influenced by On Toyota’s Mind, Yeshiva of Flatbush was certainly influenced by the concept of “experiential” (which is a polite way of saying “mystery meat”) navigation.

Yeshiva of Flatbush uses giant circles for their navigation. Intuitive, right?

That’s a design/UX example, but development is no different. How many Single Page Apps have you see out there that really didn’t need to be built that way? Dozens? We often put the cart before the horse and decide to build a site using a particular stack or framework without even considering the type of content we’re dealing with or whether that decision is in the best interest of the project or its end users. That goes directly back to Tim’s earlier point.

Progressive enhancement recognizes that experience is a continuum and we all have different needs when accessing the Web. Some are permanent: Low vision or blindness. Some are temporary: Imprecise mousing due to injury. Others are purely situational: Glare when your users are outside on a mobile device or have turned their screen brightness down to conserve battery. When we make our design and development decisions in the service of the project and the users who will access it, everyone wins.

Real answers to real questions

In the next section, Josh tries to say we only discuss progressive enhancement as a moral imperative. Clearly I don’t (and would go further to say no one else who was quoted does either). He argues that ours is “a philosophical argument, not a practical approach to web development”. I call bullshit. As I’ve just discussed in the previous sections, progressive enhancement is a practical, fiscally-responsible, developmentally robust philosophical approach to building for the Web.

But let’s look at some of the questions he says we don’t answer:

“Wait, how often do people turn off JavaScript?”

Folks turning off JavaScript isn’t really the issue. It used to be, but that was years ago. I discussed the misconception that this is still a concern a few weeks ago. The real issue is whether or not JavaScript is available. Obviously your project may vary, but the UK government pegged their non-JavaScript usage at 1.1%. The more interesting bit, however, was that only 0.2% of their users fell into the “Javascript off or no JavaScript support” camp. 0.9% of their users should have gotten the JavaScript-based enhancement on offer, but didn’t. The potential reasons are myriad. JavaScript is great, but you can’t assume it’ll be available.

“I’m not trying to be mean, but I don’t think people in Sudan are going to buy my product.”

This isn’t really a question, but it is the kinda thing I hear every now and then. An even more aggressive and ill-informed version I got was “I sell TVs; blind people don’t watch TV”. As a practical person, I’m willing to admit that your organization probably knows its market pretty well. If your products aren’t available in certain regions, it’s probably not worth your while to cater to folks in that region. But here’s some additional food for thought:

When you remove barriers to access for one group, you create opportunities for others. A perfect example of this is the curb cut. Curb cuts were originally created to facilitate folks in wheelchairs getting across the road. In creating curb cuts, we’ve also enabled kids to ride bicycles more safely on the sidewalk, delivery personnel to more easily move large numbers of boxes from their trucks into buildings, and parents to more easily cross streets with a stroller. Small considerations for one group pay dividends to more. What rational business doesn’t want to enable more folks to become customers?
Geography isn’t everything. I’m not as familiar with specific design considerations for Sudanese users, but since about 97% of Sudanese people are Muslim, let’s tuck into that. Ignoring translations and right-to-left text, let’s just focus on cultural sensitivity. For instance, a photo of a muscular, shirtless guy is relatively acceptable in much of the West, but would be incredibly offensive to a traditional Muslim population. Now your target audience may not be 100% Muslim (nor may your content lend itself to scantily-clad men), but if you are creating sites for mass consumption, knowing this might help you art direct the project better and build something that doesn’t offend potential customers.

Reach is incredibly important for companies and is something the Web enables quite easily. To squander that—whether intentionally or not—would be a shame.

Failures of understanding

Josh spends the next section discussing what he views as failures of the argument for progressive enhancement. He’s of course, still debating it as a purely moral argument, which I think I’ve disproven at this point, but let’s take a look at what he has to say…

The first “fail” he casts on progressive enhancement proponents is that we “are wrong about what’s actually on the Web.” Josh offers three primary offerings on the Web:

Business and personal software, both of which have exploded in use now that software has eaten the world and is accessed primarily via the web
Copyrighted news and entertainment content (text, photos, music, video, video games)
Advertising and marketing content

This is the fundamental issue with seeing the Web only through the lens of your own experience. Of course he would list software as the number one thing on the Web—I’m sure he uses Basecamp, Harvest, GitHub, Slack, TeamWork, Google Docs, Office 365, or any of a host of business-related Software as a Service offerings every day. As a beneficiary of fast network speeds, I’m not at all surprised that entertainment is his number two: Netflix, Hulu, HBO Go/Now… It’s great to be financially-stable and live in the West. And as someone who works at a web agency, of course advertising would be his number three. A lot of the work Viget, and most other agencies for that matter, does is marketing-related; nothing wrong with that. But the Web is so much more than this. Here’s just a fraction of the stuff he’s overlooked:

eCommerce,
Social media,
Banks,
Governments,
Non-profits,
Small businesses,
Educational institutions,
Research institutions,
Religious groups,
Community organizations, and
Forums.

It’s hard to find figures on anything but porn—which incidentally accounts for somewhere between 4% and 35% of the Web, depending on who you ask—but I have to imagine that these categories he’s overlooked probably account for the vast majority of “pages” on the Web even if they don’t account for the majority of traffic on it. Of course, as of 2014, the majority of traffic on the Web was bots, so…

The second “fail” he identifies is that our “concepts of universal access and moral imperatives… make no sense” in light of “fail” number one. He goes on to provide a list of things he seems to think we want even though advocating for progressive enhancement (and even universal access) doesn’t mean advocating for any of these things:

All software and copyrighted news/entertainment content accessed via the web should be free. and Netflix, Spotify, HBO Now, etc. should allow anyone to download original music and video files because some people don’t have JavaScript. I’ve never heard anyone say that… ever. Advocating a smart development philosophy doesn’t make you anti-copyright or against making money.
Any content that can’t be accessed via old browsers/devices shouldn’t be on the web in the first place. No one made that judgement. We just think it behooves you to increase the potential reach of your products and to have a workable fallback in case the ideal access scenario isn’t available. You know, smart business decisions.
Everything on the web should have built-in translations into every language. This would be an absurd idea given that the number of languages in use on this planet top 6,500. Even if you consider that 2,000 of those have less than 1,000 speakers it’s still absurd. I don’t know anyone who would advocate for translation to every language.¹
Honda needs to consider a universal audience for its marketing websites even though (a) its offline advertising is not universal, and (b) only certain people can access or afford the cars being advertised. To you his first point, Honda does actually offline advertising in multiple languages. They even issue press releases mentioning it: “The newspaper and radio advertisements will appear in Spanish or English to match the primary language of each targeted media outlet.” As for his second argument… making assumptions about target audience and who can or cannot afford your product seems pretty friggin’ elitist; it’s also incredibly subjective. For instance, we did a project for a major investment firm where we needed to support Blackberry 4 & 5 even though there were many more popular smartphones on the market. The reason? They had several high-dollar investors who loved their older phones. You can’t make assumptions.
All of the above should also be applied to offline software, books, magazines, newspapers, TV shows, CDs, movies, advertising, etc. Oh, I see, he’s being intentionally ridiculous.

I’m gonna skip the third fail since it presumes morality is the only argument progressive enhancement has and then chastises the progressive enhancement community for not spending time fighting for equitable Internet access and net neutrality and against things like censorship (which, of course, many of us actually do).

In his closing section, Josh talks about progressive enhancement moderates and he quotes Matt Griffin on A List Apart:

One thing that needs to be considered when we’re experimenting … is who the audience is for that thing. Will everyone be able to use it? Not if it’s, say, a tool confined to a corporate intranet. Do we then need to worry about sub-3G network users? No, probably not. What about if we’re building on the open web but we’re building a product that is expressly for transferring or manipulating HD video files? Do we need to worry about slow networks then? … Context, as usual, is everything.

In other words, it depends, which is what we’ve all been saying all along.

I’ll leave you with these facts:

Progressive enhancement has many benefits, not the least of which are resilience and reach.
You don’t have to like or even use progressive enhancement, but that doesn’t detract from its usefulness.
If you ascribe to progressive enhancement, you may have a project (or several) that aren’t really good candidates for it (e.g., online photo editing software).
JavaScript is a crucial part of the progressive enhancement toolbox.
JavaScript availability is never guaranteed, so it’s important to consider offering fallbacks for critical tasks.
Progressive enhancement is neither moral nor amoral, it’s just a smart way to build for the Web.

Is progressive enhancement necessary to use on every project?

No.

Would users benefit from progressive enhancement if it was followed on more sites than it is now?

Heck yeah.

Is progressive enhancement right for your project?

It depends.

My sincere thanks to Sara Soueidan, Baldur Bjarnasun, Jason Garber, and Tim Kadlec for taking the time give me feedback on this piece.

Of course, last I checked, over 55% of the Web was in English and just shy of 12% of the world speaks English, so… ↩

Comments

Sadly, I have not had the time to build a JavaScript-less implementation of the Disqus API yet, so you can’t comment. It’s a bummer. I really wanted to hear your thoughts.

If you use Twitter or Google+, your webmentions of this post’s URL will show up on this page still.

Webmentions

Kevin Marks
you could link to his subheadings with fragmentions ,and progressively enhance the links with a plugin
06 December 2016 | Permalink
Stephanie
the funny thing is that title is very click bait-ish.
06 December 2016 | Permalink
Aaron Gustafson
It was the one bit of snark I allowed myself.
06 December 2016 | Permalink
Stephen Hay
So, so good, Aaron. Thanks for writing it.
07 December 2016 | Permalink
Aaron Gustafson
I think important bits like that get overlooked because everyone seems to want to pick a side. We can (& should) work together.
07 December 2016 | Permalink
Stephen Hay
I have trouble understanding how people tend to see it as a threat to their favourite toys.
07 December 2016 | Permalink
Chris Poteet
Wonderful reply. Ironic that he set out to use “logic” and failed by his own standards. Nice job.
07 December 2016 | Permalink
Eric Bailey
Loved your rebuttal. Have you posted it to Sidebar? Original article got a lot traction when posted there.
07 December 2016 | Permalink
Aaron Gustafson
Thanks!
07 December 2016 | Permalink

Links

[Insert Clickbait Headline About Progressive Enhancement Here] aaron-gustafson.com/notebook/inser… +@AaronGustafson // Very gracious (undeservedly so)
Jeremy McDuffie on 06 December 2016
Great takedown of the Progressive Enhancement blog post I shared yesterday twitter.com/aarongustafson…
Nina on 06 December 2016
My coworker @AaronGustafson says pretty much all that needs to be said about progressive enhancement: aaron-gustafson.com/notebook/inser…
Rachel🦄Nabors on 06 December 2016
Excellent post from @AaronGustafson on Progressive Enhancement aaron-gustafson.com/notebook/inser…
Stephanie on 06 December 2016
“[Insert Clickbait Headline About Progressive Enhancement Here]” – bit.ly/2h3cJ2U @AaronGustafson
Jason D. Moss on 06 December 2016
Great piece by @AaronGustafson. If you still aren’t sure what #ProgressiveEnhancement is all about, read this.aaron-gustafson.com/notebook/inser…
Fredrik Frodlund on 06 December 2016
Thoughtful and well-written response by @AaronGustafson to that PE post the other day, as per his usual. aaron-gustafson.com/notebook/inser…
Tim Kadlec on 06 December 2016
Great response from @AaronGustafson to an earlier, and fairly flawed post on progressive enhancement. aaron-gustafson.com/notebook/inser…
Steve Fisher on 06 December 2016
A progressively enhanced rebuttal by @AaronGustafson aaron-gustafson.com/notebook/inser…
Snook on 06 December 2016
Great article by @AaronGustafson on progressive enhancement. Definitely worth a read. aaron-gustafson.com/notebook/inser…
Matt Halliday on 07 December 2016
While I rage about deliberately inflammatory posts, clever folk like @AaronGustafson write eloquent counterposts that do a far better job
twitter.com/aarongustafson…
Rich Archer on 07 December 2016
A must read article by @AaronGustafson aaron-gustafson.com/notebook/inser…
Ahmad Shadeed on 07 December 2016
Thanks @AaronGustafson for that, esp for pointing out that PE is not anti-JS, but pro-reach.aaron-gustafson.com/notebook/inser…
Tom Tinkerson on 07 December 2016
’Progressive enhancement is neither moral nor amoral, it’s just a smart way to build for the Web‘ – @AaronGustafson aaron-gustafson.com/notebook/inser…
Hidde on 07 December 2016
You should read this if you still had issues understanding what “Progressive Enhancement” is and why it’s so important! <3 @AaronGustafson
twitter.com/AaronGustafson…
Marco Hengstenberg on 07 December 2016
Also read @AaronGustafson’s piece. Nice to read a balanced reply, although I generally agree with @joshkorr. aaron-gustafson.com/notebook/inser…
Darin Dimitroff on 07 December 2016
“Is progressive enhancement right for your project? It depends.”@AaronGustafson nicely (re)explains what PE is.buff.ly/2gPHOZQ
Hubert🐸SABLONNIÈRE on 07 December 2016
This @AaronGustafson response to the Viget article on PE is 🔥 aaron-gustafson.com/notebook/inser…
Heydon on 07 December 2016
Great response by @AaronGustafson to Josh Korr’s article. Including “[PE] recognizes that experience is a continuum” aaron-gustafson.com/notebook/inser…
David Moulton on 07 December 2016
Brilliant article on Progressive Enhancement by @AaronGustafson aaron-gustafson.com/notebook/inser…
Adam Silver on 07 December 2016
Very good article by @AaronGustafson about why progressive enhancement is, in general, a pretty good idea aaron-gustafson.com/notebook/inser…
Ólafur Sverrir on 07 December 2016
This post by @aarongustafson on Progressive Enhancement is far more articulate and less ranty than mine. aaron-gustafson.com/notebook/inser…
Charlie Don't Surf on 07 December 2016
Reading this @AaronGustafson post makes me pine for the days when blogs ruled the web and discourse > 140 chars aaron-gustafson.com/notebook/inser…
Carl Camera on 07 December 2016
[Insert Clickbait Headline About Progressive Enhancement Here]aaron-gustafson.com/notebook/inser…@AaronGustafson has much more patience than I do.
Jason Grigsby, ☁4 on 07 December 2016
Absolutely brilliant piece from @AaronGustafson. Thank you for writing it. #progressiveenhancement
twitter.com/AaronGustafson…
Aki Karkkainen on 07 December 2016
👏 @AaronGustafson dissects a Vidget article in this elaborate post on progressive enhancement. A joy to read: aaron-gustafson.com/notebook/inser… #PE
Matthias Ott on 07 December 2016
Beatifully written rebuttal of the latest anti-progressive enhancement logical fallacies by @AaronGustafson: aaron-gustafson.com/notebook/inser… 👏
Gabriel Luethje on 07 December 2016
Pondering if @AaronGustafson’s aaron-gustafson.com/notebook/inser… OR @sonniesedge’s sonniesedge.co.uk/blog/progressi… is a better riposte to that shit PE article
Mark Skinner on 07 December 2016
Thankful people like @AaronGustafson take the time to practically articulate the benefits of progressive enhancement aaron-gustafson.com/notebook/inser…
Brad Frost on 07 December 2016
Well said about Progressive Enhancement by @AaronGustafson aaron-gustafson.com/notebook/inser…
Jonas Päckos on 08 December 2016
Screeching to an end in 2016, take a break & read an essay by @AaronGustafson. Inclusive design is practical & just. aaron-gustafson.com/notebook/inser…
Scott Gruber on 08 December 2016
One day I’d love that people like @AaronGustafson no longer have to spend time setting the record straight abt progressive enhancement.
twitter.com/AaronGustafson…
Tom Janssens on 08 December 2016
Another good response to that (purposefully inflammatory) article about progressive enhancement: ow.ly/EvzX306VXOX via @AaronGustafson
Max Antonucci on 08 December 2016
[Insert Clickbait Headline About Progressive Enhancement Here] buff.ly/2g9OnCz by @AaronGustafson #progressiveenhancement #webdesign
UXLx: UX Lisbon on 08 December 2016
@AaronGustafson drops the mic on the benefits of #ProgressiveEnhancements. #MicDrop #webdev aaron-gustafson.com/notebook/inser…
heyoka on 08 December 2016
@AaronGustafson: “PE is pragmatic, addressing the Web as it exists not as we might hope that it exists”…and more bit.ly/2h7Tisz
Knowbility on 08 December 2016
Excellent and really long read on progressive enhancement by @AaronGustafson. aaron-gustafson.com/notebook/inser…#webdev
stefan judis on 08 December 2016
on 09 December 2016
on 09 December 2016
on 09 December 2016
on 09 December 2016
Quoc Huy Tran on 10 December 2016
Inspirational Website of the Week: 10×16
A beautiful color theme combined with super-smooth movements make 10×16 our pick this week.
Get inspired
This content is sponsored via Syndicate Ads
See GraphicStock’s New Holiday Photo Collection
GraphicStock is giving you 7 days of free access to 350,000 fully-licensed images, including their new holiday photo collection.
Get started
JavaScript30
A fantastic 30-day challenge that will make you master Vanilla JavaScript. By Wes Bos. Check out the GitHub repo, too.
Check it out
Siema
Siema is a lightweight carousel plugin with no dependencies and no styling. Built by Paweł Grzybek
Check it out
IO – A space to publish freely
IO is a lightweight and powerful writing tool where you can publish your thoughts anonymously, under a pseudonym, or as yourself. Made by Bold.
Check it out
Dumb Password Rules
A shameful collection of not-so-intelligent password rules encountered on the Web. By Nicholas Duffy.
Check it out
Gitscout
Gitscout is a beautiful GitHub Issues experience for macOS.
Check it out
Progressive Web AMPs
Paul Bakaus shows the power of combining the ideas of Accelerated Mobile Pages with Progressive Web Apps.
Read it
[Insert Clickbait Headline About Progressive Enhancement Here]
Aaron Gustafson responds to Josh Korr’s article on Vidget and explains what progressive enhancement really is.
Read it
Server Side React
Remy Sharp decided to give React a go and used it for server side rendering. Read about his insights.
Read it
Four Experiments in Handwriting with a Neural Network
Fantastic interactive visualizations for understanding how machine learning works at the example of handwriting experiments.
Read it
React-instantsearch
React-instantsearch is a set of widgets and connectors to add instant-search experiences in your React application, using Algolia search engine.
Check it out
Get the Balance Right: Responsive Display Text
Richard Rutter shows how to handle responsive display text properly with the right balance.
Read it
Inspirational UI Elements vol. 2 (PSD)
A beautiful set of UI elements in PSD format.
Get it
Free Font: Ossem
A beautiful free typeface with various styles designed by Kiril Semkov.
Get it
Imzy
A new kind of community that aims to embrace diversity and simplicity.
Check it out
Mobirise Icons
A free, open source set of 124 elegant, pixel-perfect icons from Mobirise Builder.
Get it
Git Notify
Get daily code diffs from public GitHub repos. Made by Sai Ram Kunala.
Check it out
CSS Shorthand Syntax Considered an Anti-Pattern
Learn why the use of shorthand syntax in CSS can beautiful problematic. By Harry Roberts.
Read it
Saving the internet 2000 terabytes a day: fixing Font Awesome’s fonts
An interesting article on optimizing the Web’s most famous icon font.
Read it
The State of Babel
A very interesting article on the current state of Babel, the powerful JavaScript tooling suite. By Henry Zhu.
Read it
The major advancements in Deep Learning in 2016
A great summary of this year’s research progress in Deep Learning.
Read it
From Our Blog
Interactive Musical Instruments
Experimental ideas for playful musical interactions powered by MIDI.js and the Web Audio API. Play instruments or make sounds by interacting with content.
Check it out
From Our Blog
Geeky Christmas Vector Set + Patterns
A free hand-drawn vector set plus two bonus patterns with a geeky Christmas related theme. Includes vector files and ready-to-use, optimized PNGs.
Get it
Collective #271 was written by Pedro Botelho and published on Codrops.
Source: tympanus
admin on 10 December 2016
Go to Source
Inspirational Website of the Week: 10×16
A beautiful color theme combined with super-smooth movements make 10×16 our pick this week.
Get inspired
This content is sponsored via Syndicate Ads
See GraphicStock’s New Holiday Photo Collection
GraphicStock is giving you 7 days of free access to 350,000 fully-licensed images, including their new holiday photo collection.
Get started
JavaScript30
A fantastic 30-day challenge that will make you master Vanilla JavaScript. By Wes Bos. Check out the GitHub repo, too.
Check it out
Siema
Siema is a lightweight carousel plugin with no dependencies and no styling. Built by Paweł Grzybek
Check it out
IO – A space to publish freely
IO is a lightweight and powerful writing tool where you can publish your thoughts anonymously, under a pseudonym, or as yourself. Made by Bold.
Check it out
Dumb Password Rules
A shameful collection of not-so-intelligent password rules encountered on the Web. By Nicholas Duffy.
Check it out
Gitscout
Gitscout is a beautiful GitHub Issues experience for macOS.
Check it out
Progressive Web AMPs
Paul Bakaus shows the power of combining the ideas of Accelerated Mobile Pages with Progressive Web Apps.
Read it
[Insert Clickbait Headline About Progressive Enhancement Here]
Aaron Gustafson responds to Josh Korr’s article on Vidget and explains what progressive enhancement really is.
Read it
Server Side React
Remy Sharp decided to give React a go and used it for server side rendering. Read about his insights.
Read it
Four Experiments in Handwriting with a Neural Network
Fantastic interactive visualizations for understanding how machine learning works at the example of handwriting experiments.
Read it
React-instantsearch
React-instantsearch is a set of widgets and connectors to add instant-search experiences in your React application, using Algolia search engine.
Check it out
Get the Balance Right: Responsive Display Text
Richard Rutter shows how to handle responsive display text properly with the right balance.
Read it
Inspirational UI Elements vol. 2 (PSD)
A beautiful set of UI elements in PSD format.
Get it
Free Font: Ossem
A beautiful free typeface with various styles designed by Kiril Semkov.
Get it
Imzy
A new kind of community that aims to embrace diversity and simplicity.
Check it out
Mobirise Icons
A free, open source set of 124 elegant, pixel-perfect icons from Mobirise Builder.
Get it
Git Notify
Get daily code diffs from public GitHub repos. Made by Sai Ram Kunala.
Check it out
CSS Shorthand Syntax Considered an Anti-Pattern
Learn why the use of shorthand syntax in CSS can beautiful problematic. By Harry Roberts.
Read it
Saving the internet 2000 terabytes a day: fixing Font Awesome’s fonts
An interesting article on optimizing the Web’s most famous icon font.
Read it
The State of Babel
A very interesting article on the current state of Babel, the powerful JavaScript tooling suite. By Henry Zhu.
Read it
The major advancements in Deep Learning in 2016
A great summary of this year’s research progress in Deep Learning.
Read it
From Our Blog
Interactive Musical Instruments
Experimental ideas for playful musical interactions powered by MIDI.js and the Web Audio API. Play instruments or make sounds by interacting with content.
Check it out
From Our Blog
Geeky Christmas Vector Set + Patterns
A free hand-drawn vector set plus two bonus patterns with a geeky Christmas related theme. Includes vector files and ready-to-use, optimized PNGs.
Get it
Collective #271 was written by Pedro Botelho and published on Codrops.
Go to Source
Share this:
Like this:
Like Loading…
```
<h3><em>Related</em></h3>
```
info@danielemilana.it on 10 December 2016
Go to Source
Inspirational Website of the Week: 10×16
A beautiful color theme combined with super-smooth movements make 10×16 our pick this week.
Get inspired
This content is sponsored via Syndicate Ads
See GraphicStock’s New Holiday Photo Collection
GraphicStock is giving you 7 days of free access to 350,000 fully-licensed images, including their new holiday photo collection.
Get started
JavaScript30
A fantastic 30-day challenge that will make you master Vanilla JavaScript. By Wes Bos. Check out the GitHub repo, too.
Check it out
Siema
Siema is a lightweight carousel plugin with no dependencies and no styling. Built by Paweł Grzybek
Check it out
IO – A space to publish freely
IO is a lightweight and powerful writing tool where you can publish your thoughts anonymously, under a pseudonym, or as yourself. Made by Bold.
Check it out
Dumb Password Rules
A shameful collection of not-so-intelligent password rules encountered on the Web. By Nicholas Duffy.
Check it out
Gitscout
Gitscout is a beautiful GitHub Issues experience for macOS.
Check it out
Progressive Web AMPs
Paul Bakaus shows the power of combining the ideas of Accelerated Mobile Pages with Progressive Web Apps.
Read it
[Insert Clickbait Headline About Progressive Enhancement Here]
Aaron Gustafson responds to Josh Korr’s article on Vidget and explains what progressive enhancement really is.
Read it
Server Side React
Remy Sharp decided to give React a go and used it for server side rendering. Read about his insights.
Read it
Four Experiments in Handwriting with a Neural Network
Fantastic interactive visualizations for understanding how machine learning works at the example of handwriting experiments.
Read it
React-instantsearch
React-instantsearch is a set of widgets and connectors to add instant-search experiences in your React application, using Algolia search engine.
Check it out
Get the Balance Right: Responsive Display Text
Richard Rutter shows how to handle responsive display text properly with the right balance.
Read it
Inspirational UI Elements vol. 2 (PSD)
A beautiful set of UI elements in PSD format.
Get it
Free Font: Ossem
A beautiful free typeface with various styles designed by Kiril Semkov.
Get it
Imzy
A new kind of community that aims to embrace diversity and simplicity.
Check it out
Mobirise Icons
A free, open source set of 124 elegant, pixel-perfect icons from Mobirise Builder.
Get it
Git Notify
Get daily code diffs from public GitHub repos. Made by Sai Ram Kunala.
Check it out
CSS Shorthand Syntax Considered an Anti-Pattern
Learn why the use of shorthand syntax in CSS can beautiful problematic. By Harry Roberts.
Read it
Saving the internet 2000 terabytes a day: fixing Font Awesome’s fonts
An interesting article on optimizing the Web’s most famous icon font.
Read it
The State of Babel
A very interesting article on the current state of Babel, the powerful JavaScript tooling suite. By Henry Zhu.
Read it
The major advancements in Deep Learning in 2016
A great summary of this year’s research progress in Deep Learning.
Read it
From Our Blog
Interactive Musical Instruments
Experimental ideas for playful musical interactions powered by MIDI.js and the Web Audio API. Play instruments or make sounds by interacting with content.
Check it out
From Our Blog
Geeky Christmas Vector Set + Patterns
A free hand-drawn vector set plus two bonus patterns with a geeky Christmas related theme. Includes vector files and ready-to-use, optimized PNGs.
Get it
Collective #271 was written by Pedro Botelho and published on Codrops.
Go to Source
Share this:
Like this:
Like Loading…
```
<h3><em>Related</em></h3>
```
info@danielemilana.it on 10 December 2016
on 10 December 2016
on 10 December 2016
on 11 December 2016
This Web Design News Courtesy Of: http://feedproxy.google.com/~r/tympanus/~3/unfoUg3YjG0/
Re-posting this post that I am posting for you.EnjoyWeb Design
Inspirational Website of the Week: 10×16
A beautiful color theme combined with super-smooth movements make 10×16 our pick this week.
Get inspired
This content is sponsored via Syndicate Ads
See GraphicStock’s New Holiday Photo Collection
GraphicStock is giving you 7 days of free access to 350,000 fully-licensed images, including their new holiday photo collection.
Get started
JavaScript30
A fantastic 30-day challenge that will make you master Vanilla JavaScript. By Wes Bos. Check out the GitHub repo, too.
Check it out
Siema
Siema is a lightweight carousel plugin with no dependencies and no styling. Built by Paweł Grzybek
Check it out
IO – A space to publish freely
IO is a lightweight and powerful writing tool where you can publish your thoughts anonymously, under a pseudonym, or as yourself. Made by Bold.
Check it out
Dumb Password Rules
A shameful collection of not-so-intelligent password rules encountered on the Web. By Nicholas Duffy.
Check it out
Gitscout
Gitscout is a beautiful GitHub Issues experience for macOS.
Check it out
Progressive Web AMPs
Paul Bakaus shows the power of combining the ideas of Accelerated Mobile Pages with Progressive Web Apps.
Read it
[Insert Clickbait Headline About Progressive Enhancement Here]
Aaron Gustafson responds to Josh Korr’s article on Vidget and explains what progressive enhancement really is.
Read it
Server Side React
Remy Sharp decided to give React a go and used it for server side rendering. Read about his insights.
Read it
Four Experiments in Handwriting with a Neural Network
Fantastic interactive visualizations for understanding how machine learning works at the example of handwriting experiments.
Read it
React-instantsearch
React-instantsearch is a set of widgets and connectors to add instant-search experiences in your React application, using Algolia search engine.
Check it out
Get the Balance Right: Responsive Display Text
Richard Rutter shows how to handle responsive display text properly with the right balance.
Read it
Inspirational UI Elements vol. 2 (PSD)
A beautiful set of UI elements in PSD format.
Get it
Free Font: Ossem
A beautiful free typeface with various styles designed by Kiril Semkov.
Get it
Imzy
A new kind of community that aims to embrace diversity and simplicity.
Check it out
Mobirise Icons
A free, open source set of 124 elegant, pixel-perfect icons from Mobirise Builder.
Get it
Git Notify
Get daily code diffs from public GitHub repos. Made by Sai Ram Kunala.
Check it out
CSS Shorthand Syntax Considered an Anti-Pattern
Learn why the use of shorthand syntax in CSS can beautiful problematic. By Harry Roberts.
Read it
Saving the internet 2000 terabytes a day: fixing Font Awesome’s fonts
An interesting article on optimizing the Web’s most famous icon font.
Read it
The State of Babel
A very interesting article on the current state of Babel, the powerful JavaScript tooling suite. By Henry Zhu.
Read it
The major advancements in Deep Learning in 2016
A great summary of this year’s research progress in Deep Learning.
Read it
From Our Blog
Interactive Musical Instruments
Experimental ideas for playful musical interactions powered by MIDI.js and the Web Audio API. Play instruments or make sounds by interacting with content.
Check it out
From Our Blog
Geeky Christmas Vector Set + Patterns
A free hand-drawn vector set plus two bonus patterns with a geeky Christmas related theme. Includes vector files and ready-to-use, optimized PNGs.
Get it
Collective #271 was written by Pedro Botelho and published on Codrops.
on 11 December 2016
“We often put the cart before the horse…” —@AaronGustafson aaron-gustafson.com/notebook/inser…
Gunnar Bittersmann on 12 December 2016
“…sections—which I wish I could link to directly, but alas, the headings don’t have unique IDs” —@AaronGustafson 👏 aaron-gustafson.com/notebook/inser…
Gunnar Bittersmann on 12 December 2016
Another discussion of progressive enhancement – aaron-gustafson.com/notebook/inser… via @AaronGustafson #mobile #webdevelopment
PINT, Inc on 12 December 2016
Really interesting read, by @AaronGustafson on progressive enhancement & JavaScript: aaron-gustafson.com/notebook/inser…, via @Mendy_1, @reybango
Social Geek on 13 December 2016
Really interesting read, by @AaronGustafson on progressive enhancement & JavaScript: aaron-gustafson.com/notebook/inser…, via @Mendy_1, @reybango
StartUp Beat on 13 December 2016
Really interesting read, by @AaronGustafson on progressive enhancement & JavaScript: aaron-gustafson.com/notebook/inser…, via @Mendy_1, @reybango
Android Latino on 13 December 2016
Really interesting read, by @AaronGustafson on progressive enhancement & JavaScript: aaron-gustafson.com/notebook/inser…, via @Mendy_1, @reybango
The Sociable on 13 December 2016
Really interesting read, by @AaronGustafson on progressive enhancement & JavaScript: aaron-gustafson.com/notebook/inser…, via @Mendy_1, @reybango
PublicizePR on 13 December 2016
Really interesting read, by @AaronGustafson on progressive enhancement & JavaScript: aaron-gustafson.com/notebook/inser…, via @Mendy_1, @reybango
Conrad Egusa on 13 December 2016
on 21 December 2016
on 21 December 2016
on 21 December 2016
on 21 December 2016
on 21 December 2016
on 23 December 2016
on 26 December 2016
on 29 December 2016
on 29 December 2016
@AaronGustafson on wider perspectives of #ProgressiveEnhancement. Design for web users, not some browsers - aaron-gustafson.com/notebook/inser…
SteveALee on 04 January 2017
on 06 January 2017
on 13 January 2017
on 16 January 2017
on 14 February 2017
on 14 February 2017
on 14 February 2017
on 15 February 2017
I’ve been thinking a lot about speech for the last few years. In fact, it’s been a major focus in several of my talks of late, including my well-received Smashing Conference talk “Designing the Conversation 1.” As such, I’ve been keenly interested in the development of the Web Speech API 2.
If you’re unfamiliar, this API gives you (the developer) the ability to voice-enable your website in two directions: listening to your users via the SpeechRecognition interface 3 and talking back to them via the SpeechSynthesis interface 4. All of this is done via a JavaScript API, making it easy to test for support. This testability makes it an excellent candidate for progressive enhancement, but more on that in a moment.
A lot of my interest stems from my own personal desire to experiment with new ways of interacting with the web. I’m also a big fan of podcasts and love listening to great content while I’m driving and in other situations where my eyes are required elsewhere or are simply too tired to read. The Web Speech API opens up a whole range of opportunities to create incredibly useful and natural user interactions by being able to listen for and respond with natural language:
– Hey Instapaper, start reading from my queue!
– Sure thing, Aaron…
The possibilities created by this relatively simple API set are truly staggering. There are applications in accessibility, Internet of Things, automotive, government, the list goes on and on. Taking it a step further, imagine combining this tech with real-time translation APIs (which also recently began to appear). All of a sudden, we can open up the web to millions of people who struggle with literacy or find themselves in need of services in a country where they don’t read or speak the language. This. Changes. Everything.
But back to the Web Speech API. As I said, I’d been keeping tabs on the specification for a while, checked out several of the demos and such, but hadn’t made the time to play yet. Then Dave Rupert finally spurred me to action with a single tweet:
5<p>Within an hour or so, I’d gotten a basic implementation together for my blog 6 that would enable users to listen to a blog post 7 rather than read it. A few hours later, I had added more features, but it wasn’t all wine and roses, and I ended up having to back some functionality out of the widget to improve its stability. But I’m getting ahead of myself.</p>
I’ve decided to hit the pause button for a few days to write up what I’ve learned and what I still don’t fully understand in the hope that we can begin to hash out some best practices for using this awesome feature. Maybe we can even come up with some ways to improve it.
Hello, World Link
So far, my explorations into the Web Speech API have been wholly in the realm of speech synthesis. Getting to “Hello world” is relatively straightforward and merely involves creating a new SpeechSynthesisUtterance (which is what you want to say) and then passing that to the speechSynthesis object’s speak() method:
```
var to_speak = new SpeechSynthesisUtterance('Hello world!');
window.speechSynthesis.speak(to_speak);
```
Not all browsers support this API, although most modern ones do 8. That being said, to avoid throwing errors, we should wrap the whole thing in a simple conditional that tests for the feature’s existence before using it:
```
if ( 'speechSynthesis' in window ) {
  var to_speak = new SpeechSynthesisUtterance('Hello world!');
      window.speechSynthesis.speak(to_speak);
}
```
See the Pen Experimenting with `speechSynthesis`, example 1 35 12 9 by Aaron Gustafson (@aarongustafson 36 33 13 10) on CodePen 37 34 14 11.
Once you’ve got a basic example working, there’s quite a bit of tuning you can do. For instance, you can tweak the reading speed by adjusting the SpeechSynthesisUtterance object’s rate property. It accepts values from 0.1 to 10. I find 1.4 to be a pretty comfortable speed; anything over 3 just sounds like noise to me.
See the Pen Experimenting with `speechSynthesis`, example 1 35 12 9 by Aaron Gustafson (@aarongustafson 36 33 13 10) on CodePen 37 34 14 11.
You can also tune things such as the pitch 15, the volume 16 of the voice, even the language being spoken 17 and the voice itself 18. I’m a big fan of defaults in most things, so I’ll let you explore those options on your own time. For the purpose of my experiment, I opted to change the default rate to 1.4, and that was about it.
A Basic Implementation: Play And Pause Link
When I began working with this code on my own website, I was keen to provide four controls for my readers:
- play
- pause
- increase reading speed
- decrease reading speed
The first two were relatively easy. The latter two caused problems, which I’ll discuss shortly.
To kick things off, I parroted the code Dave had tweeted:
```
var to_speak = new SpeechSynthesisUtterance(
  document.querySelector('main').textContent
);
window.speechSynthesis.speak(to_speak);
```
This code grabs the text content (textContent) of the main element and converts it into a SpeechSynthesisUtterance. It then triggers the synthesizer to speak that content. Simple enough.
Of course, I didn’t want the content to begin reading immediately, so I set about building a user interface to control it. I did so in JavaScript, within the feature-detection conditional, rather than in HTML, because I did not want the interface to appear if the feature was not available (or if JavaScript failed for some reason). That would be frustrating for users.
I created the buttons and assigned some event handlers to wire up the functionality. My first pass looked something like this:
```
var $buttons = document.createElement('p'),
    $button = document.createElement('button'),
    $play = $button.cloneNode(),
    $pause = $button.cloneNode(),
    paused = false,
    to_speak;
if ( 'speechSynthesis' in window ) {
  // content to speak
  to_speak = new SpeechSynthesisUtterance(
    document.querySelector('main').textContent
  );
  // set the rate a little faster than 1x
  to_speak.rate = 1.4;
  // event handlers
  to_speak.onpause = function(){
    paused = true;
  };
  // button events
  function play() {
    if ( paused ) {
      paused = false;
      window.speechSynthesis.resume();
    } else {
      window.speechSynthesis.speak( to_speak );
    }
  }
  function pause() {
    window.speechSynthesis.pause();
  }
  // play button
  $play.innerText = 'Play';
  $play.addEventListener( 'click', play, false );
  $buttons.appendChild( $play );
  // pause button
  $pause.innerText = 'Pause';
  $pause.addEventListener( 'click', pause, false );
  $buttons.appendChild( $pause );
} else {
  // sad panda
  $buttons.innerText = 'Unfortunately your browser doesn’t support this feature.';
}
document.body.appendChild( $buttons );
```
This code creates a play button and a pause button and appends them to the document. It also assigns the corresponding event handlers. As you’d expect, the play button calls speechSynthesis.speak(), as we saw earlier, but because pause is also in play, I set it up to either speak the selected text or resume speaking — using speechSynthesis.resume() — if the speech is paused. The pause button controls that by triggering speechSynthesis.pause(). I tracked the state of the speech engine using the boolean variable paused. You can kick the tires of this code over on CodePen 19.
I want to (ahem) pause for a moment to tuck into the speak() command, because it’s easy to misunderstand. At first blush, you might think it causes the supplied SpeechSynthesisUtterance to be read aloud from the beginning, which is why I’d want to resume() after pausing. That is true, but it’s only part of it. The speech synthesis interface actually maintains a queue for content to be spoken. Calling speak() pushes a new SpeechSynthesisUtterance to that queue and causes the synthesizer to start speaking that content if it’s not already speaking. If it’s in the process of reading something already, the new content takes its spot at the back of the queue and patiently waits its turn. If you want to see this in action, check out my fork of the reading speed demo 20.
If you want to clear the queue entirely at any time, you can call speechSynthesis.cancel(). When testing speech synthesis with long-form content, having this at the ready in the browser’s console is handy.
Taking It Further: Adjusting Reading Speed Link
As I mentioned, I also wanted to give users control over the reading speed used by the speech synthesizer. We can tune this using the rate property on a SpeechSynthesisUtterance object. That’s fantastic, but you can’t (currently, at least) adjust the rate of a SpeechSynthesisUtterance once the synthesizer starts playing it — not even while it’s paused. I don’t know enough about the inner workings of speech synthesizers to know whether this is simply an oversight in the interface or a hard limitation of the synthesizers themselves, but it did force me to find a creative way around this limitation.
I experimented with a bunch of different approaches to this and eventually settled on one that works reasonably well, despite the fact that it feels like overkill. But I’m getting ahead of myself again.
Every SpeechSynthesisUtterance object offers a handful of events you can plug in to do various things. As you’d expect, onpause21 fires when the speech is paused, onend22 fires when the synthesizer has finished reading it, etc. The SpeechSynthesisEvent23 object passed to each of these includes information about what’s going on with the synthesizer, such as the position of the virtual cursor (charIndex24), the length of time after the current SpeechSynthesisUtterance started being read (elapsedTime25), and a reference to the SpeechSynthesisUtterance itself (utterance26).
Originally, my plan to allow for real-time reading-speed adjustment was to capture the virtual cursor position via a pause event so that I could stop and start a new recording at the new speed. When the user adjusted the reading speed, I would pause the synthesizer, grab the charIndex, backtrack in the text to the previous space, slice from there to the end of the string to collect the remainder of what should be read, clear the queue, and start the synthesizer again with the remainder of the content. That would have worked, and it should have been reliable, but Chrome kept giving me a charIndex of 0, and in Edge it was always undefined. Firefox tracked charIndex perfectly. I’ve filed a bug for Chromium 27 and one for Edge 28, too.
Thankfully, another event, onboundary29, fires whenever a word or sentence boundary is reached. It’s a little noisier, programmatically speaking, than onpause because the event fires so often, but it reliably tracked the position of the virtual cursor in every browser that supports speech synthesis, which is what I needed.
Here’s the tracking code:
```
var progress_index = 0;
to_speak.onboundary = function( e ) {
  if ( e.name == 'word' ) {
    progress_index = e.charIndex;
  }
};
```
Once I was set up to track the cursor, I added a numeric input to the UI to allow users to change the speed:
```
var $speed = document.createElement('p'),
    $speed_label = document.createElement('label'),
    $speed_value = document.createElement('input');
// label the field
$speed_label.innerText = 'Speed';
$speed_label.htmlFor = 'speed_value';
$speed.appendChild( $speed_label );
// insert the form control
$speed_value.type = 'number';
$speed_value.id = 'speed_value';
$speed_value.min = '0.1';
$speed_value.max = '10';
$speed_value.step = '0.1';
$speed_value.value = Math.round( to_speak.rate * 10 ) / 10;
$speed.appendChild( $speed_value );
document.body.appendChild($speed);
```
Then, I added an event listener to track when it changes and to update the speech synthesizer:
```
function adjustSpeed() {
  // cancel the original utterance
  window.speechSynthesis.cancel();
  // find the previous space
  var previous_space = to_speak.text.lastIndexOf( ' ', progress_index );
  // get the remains of the original string
  to_speak.text = to_speak.text.slice( previous_space );
  // math to 1 decimal place
  speed = Math.round( $speed_value.value * 10 ) / 10;
  // adjust the rate
  if ( speed > 10 ) {
    speed = 10;
  } else if ( speed < 0.1 ) {
    speed = 0.1;
  }
  to_speak.rate = speed;
  // return to speaking
  window.speechSynthesis.speak( to_speak );
}
$speed_value.addEventListener( 'change', adjustSpeed, false );
```
This works reasonably well, but ultimately I decided that I was not a huge fan of the experience, nor was I convinced it was really necessary, so this functionality remains commented out in my website’s source code 30. You can make up your mind after seeing it in action over on CodePen 31.
Taking It Further: Tweaking What’s Read Link
At the top of every blog post, just after the title, I include quite a bit of meta data about the post, including things like the publication date, tags for the post, comment and webmention counts, and so on. I wanted to selectively control which content from that collection is read because only some of it is really relevant in that context. To keep the configuration out of the JavaScript and in the declarative markup where it belongs, I opted to have the JavaScript look for a specific class name, “dont-read”, and exclude those elements from the content that would be read. To make it work, however, I needed revisit how I was collecting the content to be read in the first place.
You may recall that I’m using the textContent property to extract the content:
```
var to_speak = new SpeechSynthesisUtterance(
  document.querySelector('main').textContent
);
```
That’s all well and good when you want to grab everything, but if you want to be more selective, you’re better off moving the content into memory so that you can manipulate it without causing repaints and such.
```
var $content = document.querySelector('main').cloneNode(true);
```
With a clone of main in memory, I can begin the process of winnowing it down to only the stuff I want:
```
var to_speak = new SpeechSynthesisUtterance()
    $content = document.querySelector('main').cloneNode(true),
    $skip = $content.querySelectorAll('.dont-read');
// don’t read
Array.prototype.forEach.call( $skip, function( $el ){
  $el.innerHTML = '';
});
to_speak.text = $content.textContent;
```
Here, I’ve separated the creation of the SpeechSynthesisUtterance to make the code a little clearer. Then, I’ve cloned the main element ($content) and built a nodeList of elements that I want to be ignored ($skip). I’ve then looped over the nodeList — borrowing Array’s handy forEach method — and set the contents of each to an empty string, effectively removing them from the content. At the end, I’ve set the text property to the cloned main element’s textContent. Because all of this is done to the cloned main, the page remains unaffected.
Done and done.
Taking It Further: Synthetic Pacing Tweaks Link
Sadly, the value of a SpeechSynthesisUtterance can only be text. If you pipe in HTML, it will read the tag names and slashes. That’s why most of the demos use an input to collect what you want read or rely on textContent to extract text from the page. The reason this saddens me is that it means you lose complete control over the pacing of the content.
But not all is lost. Speech synthesizers are pretty awesome at recognizing the effect that punctuation should have on intonation and pacing. To go back to the first example I shared, consider the difference when you drop a comma between “hello” and “world”:
```
if ( 'speechSynthesis' in window ) {
  var to_speak = new SpeechSynthesisUtterance('Hello, world!');
  window.speechSynthesis.speak(to_speak);
} 
```
See the Pen Experimenting with `speechSynthesis`, example 2 32 by Aaron Gustafson (@aarongustafson 36 33 13 10) on CodePen 37 34 14 11.
Here’s the original again, just so you can compare:
See the Pen Experimenting with `speechSynthesis`, example 1 35 12 9 by Aaron Gustafson (@aarongustafson 36 33 13 10) on CodePen 37 34 14 11.
With this in mind, I decided to tweak the pacing of the spoken prose by artificially inserting commas into the specific elements that follow the pattern I just showed for hiding content:
```
var $pause_before = $content.querySelectorAll(
  'h2, h3, h4, h5, h6, p, li, dt, blockquote, pre, figure, footer'
);
// synthetic pauses
Array.prototype.forEach.call( $pause_before, function( $el ){
  $el.innerHTML = ' , ' + $el.innerHTML;
});
```
While I was doing this, I also noticed some issues with certain elements running into the content around them. Most notably, this was happening with pre elements. To mitigate that, I used the same approach to swap carriage returns, line breaks and such for spaces:
```
var $space = $content.querySelectorAll('pre');
// spacing out content
Array.prototype.forEach.call( $space, function( $el ){
  $el.innerHTML = ' ' + $el.innerHTML.replace(/[rnt]/g, ' ') + ' ';
});
```
With those tweaks in place, I’ve been incredibly happy with the listening experience. If you’d like to see all of this code in context, head over to my GitHub repository 38. The code you use to drop the UI into the page will likely need to be different from what I did, but the rest of the code should be plug-and-play.
Is speechSynthesis Ready For Production? Link
As it stands right now, the Web Speech API has not become a standard and isn’t even on a standards track 39. It’s an experimental API and some of the details of the specification remain in flux. For instance, the elapsedTime property of a SpeechSynthesisEvent originally tracked milliseconds and then switched to seconds. If you were doing math that relied on that number to do something else in the interface, you might get widely different experiences in Chrome (which still uses milliseconds) and Edge (which uses seconds).
If I was granted one wish for this specification—apart from standardization—it would be for real-time speed, pitch and volume adjustment. I can understand the need to restart things to get the text read in another voice, but the others feel like they should be manipulable in real time. But again, I don’t know anything about the inner workings of speech synthesizers, so that might not be technically possible.
In terms of actual browser implementations, basic speech synthesis like I’ve covered here is pretty solid in browsers that support the API 40. As I mentioned, Chrome and Edge currently fail to accurately report the virtual cursor position when speech synthesis is paused, but I don’t think that’s a deal-breaker. What is problematic is how unstable things get when you start to combine features such as real-time reading-speed adjustments, pausing and such. Often, the synthesizer just stops working and refuses to start up again. If you’d like to see that happen, take a look at a demo I set up 41. Chances are that this issue would go away if the API allowed for real-time manipulation of properties such as rate because you wouldn’t have to cancel() and restart the synthesizer with each adjustment.
Long story short, if you’re looking at this as a progressive enhancement for a content-heavy website and only want the most basic features, you should be good to go. If you want to get fancy, you might be disappointed or have to come up with more clever coding acrobatics than I’ve mustered.
Want To Learn More? Link
As with most things on the web, I learned a ton by viewing other people’s source, demos and such — and the documentation, naturally. Here are some of my favorites (some of which I linked to in context):
(rb, yk, il, al)
↑ Back to top
Tweet it Share on Facebook
Source link
on 09 March 2017
Ponieważ moja biblioteka przydatnych linków stopniowo się powiększa, pomyślałem że jest to dobry moment i miejsce, aby je zebrać razem.
JavaScript
W3Schools Online Web Tutorials ES6 for Everyone — The best way to learn modern ES6 JavaScript NodeSchool ES2015 Crash Course Eloquent JavaScript getify/You-Dont-Know-JS · GitHub Best resources to learn JavaScript – Stack Overflow Unheap – A tidy repository of jQuery Plugins Javascript [Illustrator Praxis] skrypty do Adobe Illustrator Douglas Crockford: The JavaScript Programming Language – YouTube Douglas Crockford: An Inconvenient API – The Theory of the DOM – YouTube Douglas Crockford: Advanced JavaScript – YouTube Train with Programming Challenges/Kata | Codewars Video Courses on JavaScript and Front-End Web Development Learning Functional Programming with JavaScript // slidr.io The Little JavaScripter Douglas Crockford’s Javascript Coderbyte How to Learn JavaScript Properly | JavaScript is Sexy The 50 Best Websites to Learn JavaScript CodeCombat – Learn how to code by playing a game Learning JavaScript Design Patterns Object-Oriented JavaScript Programming Course | Udacity JavaScript Design Patterns | Udacity So You Want to be a Functional Programmer (Part 1) – Medium Named function expressions demystified Function Declarations vs. Function Expressions – JavaScript, JavaScript…Understand JavaScript Callback Functions and Use Them | JavaScript is Sexy Learn ECMAScript6 by doing it JSbooks – free javascript books Kurs JavaScript Loading JSON-formatted data with Ajax and xhr.responseType=’json’ · Mathias Bynens JavaScript + jQuery Design Pattern Framework – dofactory.com The Best of JavaScript and the web platorm Up and Running with ESLint — the Pluggable JavaScript Linter JavaScript Garden Learning JavaScript Design Patterns | Degreed JavaScript Best Practices: Tips & Tricks to Level Up Your Code | Codementor JavaScript books by Dr. Axel Rauschmayer Best Web Development & Programming Blogs in 2017 | Codementor Functional Programming – Mostly Adequate Guide The Two Pillars of JavaScript – JavaScript Scene – Medium A Gentle Introduction to Functional JavaScript: Part 1 Read JavaScript Allongé (ES5) | Leanpub Pure JavaScript on Vimeo Read JavaScript Allongé, the "Six" Edition | Leanpub JSONPlaceholder – Fake online REST API for developers Ajax Requests – You Don’t Need jQuery! – Free yourself from the chains of jQuery by embracing and understanding the modern Web API and discovering various directed libraries to help you fill in the gaps.Andrew Van Slaars stoeffel/awesome-fp-js: A curated list of awesome functional programming stuff in js Synchroniczna asynchroniczność – webroad.pl Understanding Asynchronous JavaScript Callbacks Through Household Chores The Evolution of Asynchronous JavaScript | RisingStack Understanding Asynchronous JavaScript – YouTube JavaScript Goes Asynchronous (and It’s Awesome)No promises: asynchronous JavaScript with only generators KIRUPA | become a better web developer Basic AJAX Request: XMLHttpRequest XMLHttpRequest object usage Browser APIs and Protocols: XMLHttpRequest – High Performance Browser Networking (O’Reilly)Making HTTP Requests in JavaScript | kirupa.com
React
How-to setup Webpack on an ES6 React Application with SASS? – Jonathan Petitcolas Learn React.JS in 8 Minutes – Learning New Stuff – Medium Building Your First React.js App – Learning New Stuff – Medium SurviveJS React SurviveJS Webpack ReactJS Program egghead.io – Learn professional JavaScript tools with Tutorial Videos & Training @eggheadio Thinkster Building Your Second React.js App – Learning New Stuff – Medium Getting Started with Redux – Course by @dan_abramov @eggheadio Be an expert in ReactJS by watching these 5 videos.
HTML i CSS
Semantyczny blog w HTML5 [IT] Ciekawe artykuły z branży – Porady i tutoriale WWW – forumweb.pl BEM I (finally) understand BEM – krótki przykład na żywo | Pasja Online BEM & Atomic Design: A CSS Architecture Worth Loving | Lullabot Organize your CSS (BEM way) | ZaraffaSoft Better CSS: Putting it together with Atomic, ITCSS & BEM » SilverStripe Structuring Sass: Saying Goodbye to Atomic Design Ambiguity Understanding Flexbox: Everything you need to know Almost complete guide to flexbox (without flexbox) | Kenan Yusuf A Complete Guide to Flexbox | CSS-Tricks Flexbox Sheet Learning from Lego: A Step Forward in Modular Web Design · An A List Apart Article Sass Reference Sass Guidelines — Polish translation How Sass 3.3 Will Solve Your RWD Problems Bulma: a modern CSS framework based on Flexbox Utility OpenType † Simple, CSS utility classes for advanced typographic features.Profound Grid | A grid system for fixed and fluid layouts Getting started · Bootstrap Components · Bootstrap CSS-Tricks CSS Animation 101 CSS Reference – A free visual guide to the most popular CSS properties.[Insert Clickbait Headline About Progressive Enhancement Here], From the Notebook of Aaron Gustafson Screenfly / Test Your Website at Different Screen Resolutions HTML 5 Cheat Sheet – Including Free PDF Download Learn HTML5 and CSS3 for Free 4.7 Embedded content — HTML5 HTML5 Doctor, helping you implement HTML5 today Web API Interfaces | MDN The 100% correct way to do CSS breakpoints
Różne
RegExr: Learn, Build, & Test RegEx Emmet Expand Abbreviation for SublimeText3 Rog.ie Archives | Sublime Text Tips Sublime Text 3 (OSX) Cheat Sheet by martinprins – Cheatography.com: Cheat Sheets For Every Occasion Sublime Text Power User Plunker Design + Code — FREEBIE.SUPPLY scraps/bootstrap-full-class-list.txt at master · BillyWM/scraps · GitHub Codrops | Useful resources and inspiration for creative minds An introduction to functional programming Learning How to Learn: The Most Important Developer Skill gulp/getting-started.md at master · gulpjs/gulp Blog – CodeUnion.io Blog o zwinnym zarządzaniu produktami|ProductVisin W3cubDocs API Documentation – W3cubDocs Git – Book
```
				<a href="http://blog.grzegorzlaszczyk.pl/chodzimy-po-drzewie/">
					← Chodzimy po drzewie
				</a>
```
- Daj się poznać 2017 (7)
on 20 March 2017