B1 中級 3943 タグ追加 保存
>> NICHOLAS ZAKAS: Okay, excellent. So I did used to work at Yahoo!. I'm now a consultant,
which is why I wear these jackets, because it makes you look more professional when you
go in and talk with people. I want to apologize upfront: I lost my voice a couple of days
ago and it's just starting to come back, so this talk may actually sound a lot like a
conversation with an iPhone user which just kind of drops out randomly.
What else do I do? I write a bunch of books. I wrote this one, High Performance JavaScript,
this one, which just came out last month -- and we have three to give away at the end of the
night, so stay tuned for that -- and another one that will be coming out later this year.
And yes, that's a lot of books, but the NFL season is over and I have nothing else to
do on Sundays. The jokes don't get any better, so you might as well laugh at these.
And on Twitter, I am @slicknet.
>> NICHOLAS ZAKAS: Thank you.
Before I get started with progressive enhancement, I want to talk a little bit about the history
of web development, where we came from leading to where we are today. In the beginning there
was Mosaic. How many people have used Mosaic? Wow, that's a lot of people. Way more than
I expected. That's great. So Mosaic was the first web browser, created at the University
of Illinois where they have this great plaque that says 'Web Browser'. It's great. This
is like the only plaque that just has a regular noun at the top; I don't think that there's
any that's like 'Telephone' or 'Television', but for a web browser we have it.
This is what Mosaic looked like. Yeah, very pretty. This is what the web looked like at
the beginning. Everything was a gray background, black text, blue links, and if you were lucky,
a few images thrown in for good measure. Then came Netscape. Pretty much the same. We still
had these gray pages with black text and blue links. Netscape 2 -- same thing. The big change
there is we got the cool logo in the corner, which actually began the animated gif throbber
thing that browsers do all the time now, so thank you Netscape.
Then Netscape 3. This is where things started to get interesting, because you start to see
the beginning of page layout, right? How do you think that was laid out? Tables. Damn
straight. We had different size fonts, but the really interesting thing about Netscape
3 is that you could add color to your page. All of a sudden, the web went from being a
gray background on every single page to where you were now able to choose a different background,
which could be a color, a background image. You could change the text color as well. It
was very exciting. So you started to see these appear everywhere, these little buttons: 'Best
viewed in Netscape'. That's because that was the only browser that supported color, and
that gave us awesome web pages like this. 'Best viewed in Netscape', right there it
says it. Although I would argue there's no best way to view this.
Then came Internet Explorer. This is IE 2. Anybody ever use IE 2? Yeah? Wow, a bunch
of people too. Very much like Mosaic and Netscape 2 until we got to IE 3, which had color. You
know what quickly followed after that? It was these buttons showing up everywhere: 'Best
viewed in Internet Explorer'. Okay. So now developers started to say we have two browsers
that have similar capabilities -- well, I'm going to make my page so that it's best viewed
in both, and that awesome page that we saw earlier is also best viewed in Internet Explorer.
That little button is actually an animated gif that rotates between Netscape and IE.
Yeah, it's just a screenshot so you don't get to really see the awesome of it.
This was very frustrating to Tim Berners-Lee, because this was not what the internet was
supposed to be about. The whole idea was you write a document anywhere and then you can
access it from anywhere, and yet all of a sudden we had all of these little buttons
popping up saying best viewed with this browser, best viewed with that browser. It ended up
being a pain.
And so we entered the graceful degradation phase of web development. Graceful degradation
comes from physical products, because physical products, if something goes wrong, they can
hurt you. If your toaster just stopped working, it shouldn't explode in your face. In these
physical products, we build them with an anticipation of what could possibly fail, and then providing
some sort of logical fallback for that. For example, in real life, if you were to fear
that zombies would attack, you would come up with a logical fallback plan. I took this
photo in Hawaii, actually, which is not a huge bed of zombie activity.
Thank you for laughing. Seriously, if you look at any zombie movies, they don't take
place in Hawaii. But the fact of the matter is you have to be prepared just in case, so
this bunker is property of Bri if zombies attack.
There's a really good article written by Peter Paul Koch -- you may have heard of, founder
of QuirksMode -- down on Digital Web Magazine. This is all about graceful degradation. It's
ten years old now, but it's kind of nice to go back and read through. He talks about the
decisions that he went through with deciding whether he should support Netscape or not.
It's really great to go back and read these old articles to see just how far we've come
in web development.
is a good example of graceful degradation. It's your planning for something specifically
not working and then giving a fallback. This is graceful degradation. It would not be cool
to just show a blank page, but if you tell people that you're showing them a blank page
because their browser can't do something, that's okay. That's graceful degradation.
And of course, we're all very familiar with this now thanks to Apple. Graceful degradation.
Your browser doesn't support Flash? I'm just going to tell you it doesn't support Flash
and it sucks to be you right now. Graceful degradation.
Not surprisingly, people didn't love that, so the next way was progressive enhancement.
Another good article. This is written by Aaron Gustafson on A List Apart about progressive
enhancement and the difference between this and graceful degradation. The basic difference
is you're going from the other way; instead of saying I'm going to build the uber-experience
and then when things break I'm going to give you little crappy pieces of experience, it
says I'm going to build up from basic core experience and add on top of that.
If you go to my blog, which I encourage you to do, it will not look like this. This is
what it looks like when I have all the style sheets removed. It might not look pretty,
but you can actually still read the content, and that's the only reason why you'd go to
my blog is to read the content; there's nothing else there to do. So you start with that and
then layer on the CSS on top of that. Whether or not you like my green color scheme, it
just adds a little bit of styling to it.
The article had a really great diagram, which I've stolen and pasted right here for you,
of a Peanut M&M. If you want to build a Peanut M&M, you don't start with the candy shell,
right? Right? Okay. You start with the peanut, and then you cover it with chocolate, and
then you cover that with the candy shell. This is analogous to how you build your website.
You start with the core -- it's either content or some core experience -- and then you layer
on the presentation, the styling, the CSS, on top of that, and then you add the scripting
on top of that.
In real life an example is an escalator. Comedian Mitch Hedberg said "an escalator can never
break; it can only become stairs." This is really cool if you stop and think about it.
Somebody said I need to get up to that second floor. Well, you could take the stairs. Yeah,
but that's too slow. Well, what are you going to do? I know, we could come up with something
new? No, I have a better idea: let's make the stairs move! Really cool. Started with
something that already existed, and already worked, and just enhanced it by adding electricity.
So you'd never see 'escalator temporarily out of service', just 'escalator temporarily
stairs'. All right, five people laughing, we're getting there, we're getting there.
Also in real life, electric toothbrush. If you don't have batteries in there, it's a
toothbrush. You put batteries in and it's an electric toothbrush. Progressive enhancement.
No need to applaud for any of these, by the way.
So what does a stack look like? You start with your content, you layer presentation
on top of that, and you layer behavior on top of that. What I'm noticing that's very
interesting about this presentation, because it's the first time I've given it on this
computer, is all my animations are going automatically, which does wonders for your timing. It's great.
I hope I don't have any timing based jokes; that's going to be horrible.
These all map to the technologies that we know and love of HTML, CSS, and JavaScript.
The old Yahoo! graded browser support was based on this idea of progressive enhancement.
For A-grade browsers, you give all the layers, everything that your site is capable of doing.
For C-grade, you just strip off those top two layers and just keep it with HTML. That's
what I like to call Progressive Enhancement 1.0; that was really designed for the era
when we were dealing with two browsers, IE and Netscape.
Of course, today we have a lot more. This is just a small subset. Because of that, now
we're having some problems that we never really dealt with before. Development takes too long.
I'm always amazed at just how long it takes to do simple things these days. If you ask
your managers, I'm sure that they're pretty shocked too. 'Oh, it's just a button, what
the hell? What's taking so long?'
There's a lot of bugs. How many people spend most of their day fighting bugs? Yeah? A lot
of people. I know I do. This picture creep out anybody else? I'm just curious. Yeah?
Okay. It's just me. I mean I picked the picture, but it just really creeps me out.
And our pages are slow. Everybody's talking about performance. I even wrote a book about
it. There's a conference about it. Everybody's concerned about performance, and yet we have
all these fast computers and fast internet connections, and we're still complaining that
things are slow. That all leads to a horrible user experience. Nothing for Dr. Horrible?
So why is this happening?
No, okay, you're going to laugh at this? This is what you're going to laugh at? Really?
So this is a cop out excuse. It's not Internet Explorer's fault, it's actually our fault.
We got confused. The reason why we got confused is because we're dealing with a new technology;
this happens whenever new technologies come out: we try to figure out what the hell that
thing is. So we looked at a web page and we said what is that like? What is it that we
know it's like that we're already familiar with? We said well, web sites look a lot like
print. We have the print New York Times here on the left, and we have the online New York
Times on the right, and to the layman they look very similar: you have a banner up at
the top, you have columns of content and pictures mixed in. Very similar. Okay, so a web page
must be like a printed page, right? That makes sense.
[Audience member makes inaudible comment]
>> NICHOLAS ZAKAS: Hey, we're getting there, hold on. So we went through... Oh, this is
one of those things where it works way better with a delay of the animations. Imagine that
the circle isn't there yet, and I'll tell you when it is. You guys remember on the SATs
-- I may be dating myself here -- how many people remember on the SATs the analogies?
Yeah? Yeah. I hear that they're not actually on there anymore because they suck. We basically
went through and tried to figure out what this relationship was and ended up saying
that a web browser is kind of like a book. A web page is to the printed page as the web
browser is to a book. Okay, so every printed book is exactly the same, right? It doesn't
matter how many of them that you see, they're pretty much the same. I have three of my books
right here. You won't be able to tell one from the other. Okay, then that must mean
that we need to have identical experiences across websites too, right?
Really, nothing for the chubby guys with the browsers on their bellies? Nothing? You guys
are all filled up on pizza, right?
So people get angry if you try to tell them that things can look different in different
browsers, they get really, really angry. They say: don't you care about quality? It's a
quality job to make it look exactly the same across all browsers. Aren't you professional?
Because professionals make sure that things look the same across all browsers. Don't you
care about consistency? I mean, that's what our company is all about, is consistency,
and we have to have a consistent experience across all browsers. Then somebody comes in
and starts saying something like that; I don't even know what that means.
But all of that is bullshit, absolute bullshit. It's stuff that people told themselves because
they were confused about what they were doing. We started out with this analogy, and that
was just wrong. The reason why it's wrong is because of the way that media works. You
start out with some content -- that's your song, your video, some text -- and then you
have some consumption device, something that allows you to consume that content and enjoy
it. That's ultimately what leads to happy users. For most of civilization, we've had
the written word, and that means for most of civilization our content was actually the
same as our consumption device. It's the same thing. For most of time that's how we thought
about it. That's why conquering armies would come into towns and burn books, because once
the books are gone, the content was also gone.
But we're in a different era now. We have content, which is a web page, that lives completely
separate from a consumption device. In fact, we have a bunch of different consumption devices
because there are a bunch of different browsers. So all of a sudden the content and the device
that you use to consume that content are separate, they're decoupled. It's very, very different
from the written word.
The problem for us is that we started the analogy in the wrong spot. We started with
a web pages is like what, and we went to a web page is like a printed page, and that
was just wrong. What we should have done was try to define this relationship: a web browser
is to a web page. If you go through these and you say a web browser is to a web page
as...? What actually makes the most sense is a television is to a television show.
Let's stop and look at that for a minute. I said we have content and then a bunch of
different consumption devices. If you look at TV, you have your content...
Thank you. And you have a bunch of different consumption devices. So it looks very similar.
If you think about it, the old browsers are like black and white TV; they're kind of slow,
require a lot of energy, graphics are kind of crappy. We even saw at the beginning that
the older browsers actually were pretty much black and white. Newer browsers are like HDTVs;
very shiny, lots of new features, really nice graphics, everything's very pretty.
And TV already solved this exact problem. Nobody kept saying oh, you know what, we have
people on black and white TVs that aren't going to be able to enjoy that, so you know,
maybe we should just give everybody that same experience. That would have been insane. Why
are you doing that? Why did we even bother coming out with color TVs if you're just going
to be feeding me a black and white signal? That doesn't make any sense. And yet with
web development, we've been doing that. We've been going for the lowest common denominator
just to make sure it works the same across all browsers. It doesn't make any sense.
What came first, the color TV, or the color TV signal? It's chicken and egg, but you're
not going to have one without the other. Then when HDTV came out, all of a sudden we had
these signals that degrade really nicely. You have the HD signal on the HDTV, standard
def on standard TV, and yet there's still black and white TVs out there that can consume
that signal and display something logical.
Do web sites need to look the same in every browser? No. If you're not sure, you can go
to dowebsitesneedtolookexactlythesameineverybrowser.com. That's an actual site. This is a screenshot
of that actual site.
>> AUDIENCE MEMBER: Does it look the same in every browser?
>> NICHOLAS ZAKAS: It does not look the same in every browser. Your site should look different
in different browsers. Think about HDTV. When I went out and bought my thousand dollar HDTV
-- which is awesome, by the way: 42 inches, LED -- if I had plugged that in and I got
the exact same experience as my old CRT, I would have been really pissed. Why did I bother
spending all this money? Give your users an incentive to upgrade. This is exactly what
we've been complaining about with browser users forever -- they don't upgrade. Well,
why would they upgrade if things always look the same? They wouldn't. It's a lot of trouble.
So if this was Progressive Enhancement 1.0, Progressive Enhancement 2.0 looks a little
bit different. It starts with HTML as the base, you add a little bit of CSS and some
JavaScript, but now the CSS and the JavaScript are siblings because you can have HTML with
just JavaScript and no CSS. You can also have HTML with CSS and no JavaScript. When you
think about things this way, you're able to start adding on additional layers in both
stacks. This goes on forever, it goes on to infinity. You can just keep adding more and
more features on top.
For Chrome you can serve everything that you have, and you can start peeling things off
for other browsers. Firefox may be a little less, IE9 may be a little less, go to IE6
and then still for Netscape 4 you can go all the way down to your HTML. It gives you a
lot more options in what to serve. New browsers have a lot of capabilities just built in that
are very easy to use; this is just a very small list. What we're really aiming for is
to give the best possible experience given the device capabilities. That's what you should
be shooting for -- not the same experience for everybody, the best possible experience
for everybody.
This is one of my favorite charts. It plays really well with management, in case you ever
want to have this conversation with them. So you have a cross at the bottom, the amount
of effort increasing to the right, and the amount of value increasing to the top. We
spend a lot of our time in these two blue areas, where there's low effort, low value
activities. Okay, yeah, I'll go in and make something red, or make something blue, and
it's very quick and easy. It provides a little bit of value. Then there are ones in the upper
right here -- it's going to take a lot of effort but it's really, really important,
it's going to provide a lot of value to us.
Then we have this area over here, the red area, which is a ton of effort, very little
value. This is where things live like rounded corners without CSS. Cross frame communication
in IE6. That's where all of those live, right there, as opposed to the green square, which
is very little effort and high value, which is what newer browsers give you. There are
all these new JavaScript APIs that make it very, very simple to do things that you used
to need hundreds of lines of code to accomplish before. So you can spend a lot more time in
that green area if management lets you.
I want to share a little story with you. This is from a couple of years ago now. What I
did was I went through on a project I was on and looked at the browser market share
at the time. We had IE6 with 11 percent, and IE7 with 8 percent. This is a couple of years
ago; it's lower now. Others at 81 percent. So there's basically 19 percent for these
old browsers that we all kind of complain about. Then I went and looked to see how much
development time we were spending on those browsers, and it turned out we were spending
40 percent of our time on IE6 and IE7, mostly with bug fixes and trying to figure out workarounds;
how are we going to get this to work in IE6 and IE7? 40 percent of our time spent on 19
percent of the audience. That's not a pretty picture, especially when that 19 percent of
the audience isn't growing, it's shrinking. That doesn't make sense.
What's great is when you show pie charts like this, it makes inane things seem to make more
sense. You show this to management, it makes sense. I show you this one, it makes sense.
Okay, take a minute, read. Okay. All right? Okay.
So here's my proposal to you. Let's do all these rounded corners, drop shadows, and gradients
only with CSS. No more images for this. I get really annoyed when I think that there
are people sitting with a really suped up Mac and Adobe Photoshop creating pixel perfect
little rounded corners and gradients. We have human beings creating gradients and cutting
them up and slicing them up and then putting them up on some CDN, and then engineers coming
in and taking them and measuring them and figuring out where they are and putting them
into CSS. What a colossal waste of time. We're in 2012, people! We don't need to manually
create gradients anymore. We almost have cars that can drive themselves, and we still have
people creating gradients by hand, it's insane.
And let's do our advanced scripting and behavior only with native APIs when they're available.
You want to do cross iframe communication? Let's just do it in browsers that support
that by default. In the other ones we can scale that out. Spend more time in the awesome
area of that chart. Because basically, trying to make old browsers do things they were never
meant to do is the reason that we're having so many problems now. It's the reason why
development takes too long. If I could have cut out that 40 percent development time,
we would have got a lot more stuff done faster. You'll have fewer bugs, and you'll have faster
Now older browsers usually need a lot more code to do the exact same thing as newer browsers.
This is another example. This was an element from a page I was working on that had the
trifecta: rounded corners, drop shadows, gradients. This was all using images, all sliced up like
we all hate to do. That was about 1.4kb. Redone to use CSS instead, it's about a third of
the code to accomplish the exact same thing. A third of the code. That's pretty cool, especially
when you consider this was just one small part of the page. You start to apply it to
the rest of the page, those bytes really start to add up. Less code will always be faster,
and that means that you're actually giving older browsers a better experience when you
serve them less code because they can't handle as much. It's generally just slower, so you
give them less code, it goes faster, it's a better experience.
Won't people notice? People ask me this all the time: if I do that, won't people notice?
So tell me, what did you see? A baby. Yeah, yell it out, come on. Crying baby. What else?
[Audience member makes inaudible comment]
>> NICHOLAS ZAKAS: What? Somebody holding the baby.
>> AUDIENCE MEMBER: Blonde baby.
>> NICHOLAS ZAKAS: Blonde baby.
>> NICHOLAS ZAKAS: Good, zipper.
>> AUDIENCE MEMBER: No rounded corners.
>> NICHOLAS ZAKAS: What was that?
>> AUDIENCE MEMBER: No rounded corners.
>> NICHOLAS ZAKAS: No rounded corners. Excellent. Even on the baby's head? Anything else you
noticed? All right, well let's take another look. So we have a crying baby, blonde -- good
call -- someone holding it. There's a little zipper there, it looks like, yeah. Where are
your rounded corners? Where are they? Yeah. So does anything jump out at you now that
you're seeing this again? Are you noticing more? Yeah? Well that's great, because this
isn't what I showed you before. This is what I showed you. Oh, there's a little shadow
there, yeah, and there's a little gradient in the background, a little rounded corners
around the edge. But except for one guy -- thanks for ruining this, by the way -- nobody noticed
the other things that were going on in the page. Why?
You're looking at the baby, you're looking at the content. That's what you cared about:
the baby. What's wrong with that baby, why is it crying? How are we going to make it
stop? It's making me very uncomfortable, I feel like I have to go and call my kids now
and make sure that they're okay. There are all these thoughts that are going through
your mind. You're not really paying all that much attention to the stuff that's around
the edges.
Keep in mind, too, that your users only use one browser. We use multiple browsers. We
frantically go back and forth between Firefox and IE and Chrome and Safari and Opera, trying
to make sure that everything works, but that's us. Normal users don't do that. Believe it
or not, most normal users don't even know that they're using a web browser per se, and
if they do know, they might not know that there's an option, that there's another one.
They just know that they click on something and they go to the internet.
I want to introduce you to a normal user. This is my mom, for reals. My mom uses one
browser, and that browser is Firefox. She gets to Firefox by clicking on the Internet
Explorer icon that I put on her desktop...
[laughter and applause]
>> NICHOLAS ZAKAS: So why did this happen? Because my mom was using Internet Explorer,
I wanted to change her to Firefox, so I removed the Internet Explorer icon from the desktop
and I put the Firefox icon there, and I said mom, come here. From now on, you click on
that icon to go to the internet. And she said no, I click on Internet Explorer to go on
the internet, and I said no, no, no mom, you used to click on Internet Explorer to go to
the internet -- now you click on Firefox to go to the internet. She said no, I don't.
Not wanting to let that conversation go on forever, I decided that the path of least
resistance would be to set up the Internet Explorer icon to point to Firefox.
You can laugh -- Lord knows I do -- but this is the experience for a lot of internet users.
Internet users are not tech savvy, they don't understand, which means that they're also
not going to notice that there are other browsers, or go back and forth between them. They're
going to have one experience; it's going to be the experience of the browser that came
with their computer. Always keep that in mind. Or the one that their son went and set up
on their computer when they weren't paying attention.
So you're not alone if you want to try this and you're looking for examples to show. They're
all over the place. Google actually does a fantastic job at progressive enhancement.
Whenever new browser features come out, I swear like that day Gmail is taking advantage
of it. When drag and drop from the desktop first came out, it was first in Firefox, when
that version of Firefox came out, Gmail was already enabled with the ability to drag files
from your desktop and attach them to emails. For everybody you would get this screen up
at the top, and then for the browsers that supported it, which are a lot more now than
I could fit over there, you would also get this if you dragged your file over. This is
progressive enhancement. You can still attach a file by clicking 'attach a file' there if
you don't have drag and drop, but they just added this on top for the browsers that support
Also, Gmail for the iPad. The same elements, just rearranged a little bit to give a better
experience on a tablet device.
We have Twitter. So this is a Twitter login page. They still, to this day, even in IE9,
do not have rounded corners. But in every other browser they do. Just a very small progressive
enhancement. Would the IE users notice? Probably not, unless they're putting together a presentation.
Then they notice.
Go to Facebook in IE6 and you get a nice little notice that tells you you can't use chat on
Facebook in IE6, because they decided that it was too much work to continue to support
IE6 when they could spend more time on newer features for the more capable browsers. This
is a great idea. Why try to make chat work in IE6 when you could be doing so many more
cool things for all the rest of your users? Chat really is a progressive enhancement.
You can go in, you can still see your timeline, you can still do whatever, you just can't
chat. That's an added bonus you get only when you're using a newer browser, and that's okay.
When Yahoo! came out with the tablet home page -- I was still here at that time -- we
spent a lot of time thinking about what happens if that tablet home page shows up on a desktop
browser. We made sure that it kind of looks the same, but there are a few little different
things based on capabilities at the time. Firefox didn't have the same fonts because
at the time it didn't have the same web font capabilities, so we just left those off. And
we were using CSS animations and transitions in order to create a little carousel at the
top, and since Firefox at the time wasn't supporting that, we just left that off. More
or less it's the same thing, and it still works. That's what you want to go for. Whenever
a user comes to the page, they get whatever is the main point of the page. In this case
it's the content. If it's an email program, it's to be able to read their email. You don't
want to leave them hanging.
To wrap up, whenever you're talking about websites and compatibility across browsers,
think of this analogy: a web browser is to a web page as a television is to a television
show. This was Progressive Enhancement 1.0. With 2.0 we have a lot more layers for both
JavaScript and CSS that you can play with and mix and match. This analogy works really
well for everybody. I've had this conversation with engineers, with designers, product management,
marketing, pretty much everybody. Drawing upon the analogy of black and white TVs, CRT
TVs, HDTVs, this is something that makes sense to people because it's something that we've
already experienced and lived through. Any time you tell somebody that you want to give
them a black and white signal through an HDTV, they're instantly going to understand what
you're talking about.
To close, don't be horrible, do be awesome. And that is it.
>> ALLEN RABINOVICH: If there are any questions for Nicholas, can you guys actually come up
to the front and we'll have the microphone right here?
>> NICHOLAS ZAKAS: Looks very strange from this point of view. I just wanted to throw
that out there.
>> AUDIENCE MEMBER: One thing I've noticed is that a lot of times we're developing stuff
that isn't really based on the notion of a document, but we're developing stuff that's
really based more on the notion that it's an application and it's JavaScript driven.
There's the assumption that JavaScript's there. I mean, when you gave the example of the Facebook
page with chat, you said well chat's just progressive enhancement. Unfortunately it
seems like a lot of the stuff we work on is all about the chat, and I was just wondering
if you could comment on that.
>> NICHOLAS ZAKAS: Yeah, that's actually a very good point. There is an analogy to web
application. Yeah, for web sites, content is key. For web applications, there's usually
one or two core features that are your value proposition. They are the thing that you are
good at, and that's why people use your product. If you're eBay, that's bidding on stuff and
seeing stuff and posting stuff. If it's Facebook, it's mostly about status updates, photos,
etcetera. If you look at Gmail, Yahoo! Mail, it's to go and read your email and send your
email. All of these things are possible without JavaScript completely.
The assumption that JavaScript is going to be there, I know a lot of people love to make
that, but there's actually a large amount of the internet population that for one reason
or another can't run JavaScript. In fact, when I was here at Yahoo! I did some research
and found that there was about 3 percent of our US users that didn't have JavaScript running.
For what reason we don't know, but they just didn't. 3 percent doesn't seem like it's that
big of a deal, except when you consider that the amount of traffic that Yahoo! gets is
hundreds of millions, so 3 percent actually ends up being several million people that
if something is completely reliant on JavaScript, they just can't use.
Of course, it's completely up to you to say hey, you know, for those people we're just
going to say sorry and we're going to go the graceful degradation route, and we're going
to say in order to use this you need to have a browser that supports JavaScript. That's
not the way I like to build things. It's not the way that I have built things. I've built
web applications as well as content sites, and I always start out with the plain old
form submission way of doing things and then add JavaScript on top. Does it take a little
more time? Yeah, it does. But the great thing is that if your JavaScript happens to break
for some reason, people can still use the site.
This was another thing that I found from time to time, is that there is a fairly consistent
failure rate of CDNs delivering content out. For some percentage of time -- and it varies
depending on the CDN, and actually web servers this happens to for some reason -- for some
reason your JavaScript just doesn't get there for some percentage of users, and we don't
know why. It gets lost in the ether somewhere. For those people, they actually can use JavaScript,
but for some reason your JavaScript isn't getting there, or it's getting there mangled
or garbled or broken or something. Then they're kind of stuck. I can tell you that I've actually
seen happy tweets from people that said oh, for some reason this site wouldn't load the
JavaScript, but I could still use it anyways, and they were very, very excited about it.
All that being said, JavaScript-only applications are not my favorite. I think doing that, you
tend to paint yourselves into a very dangerous corner where you're always going to be stuck,
where any little JavaScript error means that the user interface breaks, and that makes
me very uncomfortable. It does take a little bit of extra time, but I think that the payoff
is well worth it. By the way, I'm not even talking about canvas based games that are
only JavaScript -- I have no answer for that. I hope that answered your question. And if
not, email me.
>> AUDIENCE MEMBER: I was just wondering about Initializr, and HTML Boilerplate, if you're
familiar with those, and recommend those? Do you see any drawbacks to using them?
>> NICHOLAS ZAKAS: What was the first one?
>> AUDIENCE MEMBER: Initializr. It's just an open source project. People basically put
a bunch of the browser hacks or stuff to make it degrade well and stuff like that.
>> NICHOLAS ZAKAS: I'm not familiar with Initializr. HTML 5 Boilerplate I am.
>> AUDIENCE MEMBER: Yeah, it's the same.
>> NICHOLAS ZAKAS: Except it's not Modernizr.
>> AUDIENCE MEMBER: Yeah, Initializr is Modernizr, HTML 5 Boilerplate and a couple of like...
>> NICHOLAS ZAKAS: Ah, excellent, okay. That makes sense. Those are all great tools to
help get you up and running. I think it is super awesome to start out with something
that we know actually works well and build on top of that rather than recreating from
scratch every time. Yeah, go ahead.
>> AUDIENCE MEMBER: In what stage do you think progressive enhancement is in? Is it just
beginning? And is there any framework you suggest fits in that category, and are you
going to do something to push this movement?
>> NICHOLAS ZAKAS: I should say, the first part of the question was how far along is
progressive enhancement?
>> AUDIENCE MEMBER: Yeah, 2.0.
>> NICHOLAS ZAKAS: Oh, 2.0. That's just a term I made up, that's not a real thing. But
progressive enhancement is getting a lot of attention lately. Aaron Gustafson, who wrote
that article that I showed you earlier, actually just wrote a really good book on progressive
enhancement as well. If you've heard about things like mobile firsts, responsive design,
all of these have aspects of progressive enhancement in them. They're all about giving the best
experience to the user based on the capabilities of the device. There was kind of a curve of
progressive enhancement that's starting to ramp up now, especially as people are trying
to tackle these problems of, you know, the desktop and the tablet and the mobile, and
how do you get things that work across all of those, or do you? So there's a lot of that.
In terms of frameworks, YUI is a really great framework.
You're welcome. I say that not joking at all, actually. I was a fan of YUI before I started
working at Yahoo!. I've been a fan ever since. Part of that is because YUI does embrace progressive
enhancement -- you can have stuff in your page and then annotate it a certain way and
get YUI widgets popping up and bringing things to life. I think they have really great infrastructure
for that. jQuery UI also does a really nice job with progressive enhancement. Both do
a really nice job with progressive enhancement in terms of accessibility as well, so you're
not just throwing a tab list on a page, but you're making sure that it's actually accessible
for everybody.
>> AUDIENCE MEMBER: Hi Nicholas. Basically my question would be similar to the second
person, which is how does the polyfill fit in to your progressive enhancement? There
are two kinds of polyfill: one is like Modernizr, to make the old browser act like a modern
browser. The other one is conditional loader. Does that mean that if you use those polyfills,
you automatically embrace the progressive enhancement?
>> NICHOLAS ZAKAS: Polyfills are an interesting thing. I'm not a huge fan, but given that
they're out there, I usually say that it's better to use somebody else's polyfill than
to try to stop and make your own because that takes way too much time. But the polyfills,
I think, generally, you have to be careful of. Sometimes they're adding capabilities
that the browser was never actually meant to have. Every cross iframe thing for IE6
is a horrific hack, because that's the only way you can get it to work.
I personally prefer to use things that are facades, instead. This is approach that libraries
like YUI and jQuery take, which is basically that they try to give the capabilities that
are available natively but with a different wrapper, so that you're not trying to access
the native API. I think that's better for a couple of reasons, but the most important
reason is that native APIs are usually buggy in strange ways, so if you add a polyfill
into the mix then you have a buggy, native API in one browser, a buggy, native API in
another browser, and then a polyfill that's trying to copy one or the other and probably
isn't aware of all the bugs, so then you have three sets of bugs you need to deal with.
As opposed to creating a wrapper around it that is able to say, okay, I know that there's
a quirk here and I know that there's a quirk there, and just try to smooth those over for
>> AUDIENCE MEMBER: So that means it's better to use a conditional loader, right? Conditional,
based on the browser capabilities.
>> NICHOLAS ZAKAS: Yeah, conditional loaders are actually really cool. You asked it in
the context of polyfills. Sometimes conditional loaders are basically if this isn't implemented
natively then I'm going to load this thing in and polyfill it, which is okay. But I still
prefer the if I'm going to give a facade and then if the thing isn't there natively then
I'll sort of implement something underneath that isn't exactly a polyfill for it, but
we'll accomplish the same thing.
>> AUDIENCE MEMBER: All right, thanks.
>> NICHOLAS ZAKAS: Sure. Last question.
>> AUDIENCE MEMBER: For your mom, when you made Internet Explorer...
>> NICHOLAS ZAKAS: Wait, you're talking about my mom?
>> AUDIENCE MEMBER: It's a question...
>> NICHOLAS ZAKAS: I don't know if that's cool.
>> AUDIENCE MEMBER: When you made Internet Explorer logo point to Firefox, why didn't
you point to Chrome?
>> NICHOLAS ZAKAS: Why didn't it point to Chrome? Good question. Actually when I did
that, Chrome didn't exist. Ha! Got you. Serves you right for talking about my mom.
Okay, if nobody has any other questions, thanks. You can feel free to contact me if you think
of things afterwards, and stick around for Doug and books.


Nicholas Zakas: Progressive Enhancement 2.0

3943 タグ追加 保存
Ian Jyun Li 2015 年 2 月 9 日 に公開
  1. 1. クリック一つで単語を検索


  2. 2. リピート機能


  3. 3. ショートカット


  4. 4. 字幕の表示/非表示


  5. 5. 動画をブログ等でシェア


  6. 6. 全画面再生


  1. クイズ付き動画


  1. クリックしてメモを表示

  1. UrbanDictionary 俚語字典整合查詢。一般字典查詢不到你滿意的解譯,不妨使用「俚語字典」,或許會讓你有滿意的答案喔