Heydon Pickering - Getting nowhere with CSS best practices

Fronteers 2014 | Amsterdam, October 9, 2014

Broadly speaking, common CSS best practices cover readability, efficiency and modularity. Adopting them purports to make long-running projects more manageable. But do any of them really help, and how many of them actually improve the product that falls into people's hands? Is it possible that CSS best practice can perpetuate or even beget bad design practice?


(jake) Give a big Fronteers welcome-- it's Heydon Pickering.

[APPLAUSE] It's Steve.

Hi, everyone.

I appreciate that you're probably quite hungover, especially those of you who went to the jam session last night.

I didn't go.

I got an early night.

So I'm prepared for this.

All right.

I have to walk slowly back over here, again.

So I appreciate that CSS's best practices are a highly contentious and deeply serious subject.

So I'm going to try and keep things light.

So I'm going to throw in some little tidbits about religion, politics, and death.

So, you're welcome.

So what is best practice? Before we get into CSS best practice, what is best practice, per se? I don't know.

I have no idea.

People sort of say it a lot around the office and at conferences and things.

It comes up a lot.

I didn't know what it is.

I don't know where to start.

I feel like a bit of a charlatan, really, talking about it.

But when I don't understand things, I like to try and break them down into their constituent parts, semantically, in this case.

You've got best on the left.

That's a superlative.

There's not much you can say about best except that it's the best.

Simply the best.

Better than all the rest, as Tina Turner famously said.

She put it better than me.

But I'm just paraphrasing.

Practice is a very vague lexeme, which doesn't really mean anything except to take an idea and make it manifest.

So it's just doing stuff.

So it's just doing stuff in the best possible way.

That's pretty vague, I'd say.

That's pretty vague.

And what I'd like to do, then, is I try to make a few paradigmatic substitutions.

So if we replace each of these words with synonyms, we get stuff like this-- ultimate procedure, unbeatable action, and exceptional method.

It sounds either like marketing copy.

That's dramatic irony, by the way, because I'm going to be talking about marketing and stuff throughout the talk.

Or, alternatively, like the rhetoric you'd expect in the indoctrination manual of a new age cult.

That's also dramatic irony.

Because it's so vague and doesn't mean anything, it's really easy to troll people using the expression best practice.

I can be typing away on my computer over here, doing some coding, thinking everything's good.

And then a colleague will, of course, come over and look over my shoulder and say, that's not best practice.

And then just walk off.

And then I'll shout after him and say, hey man, you can't just come and say that's not best practice.

How is it not best practice? Of course, he doesn't know why it's not best practice.

Nobody knows what best practice is.

So he'll say, oh, you don't even know that that's not best practice.


So then later on, he'll be at his desk and he'll be typing away.

And I'll be furious because he's made me feel stupid and small because he's been attacking my code.

So I'll go over to him and I'll say the same thing.

And I'll say, that's not best practice.

And it just goes on and on, ad infinitum.

And that's what we call web development.

Or, in the broadest sense, just the digital economy.

There is a darker side to best practice, though, and that is because it's a very positive term and yet it's a very vague term.

It's like concepts like freedom and democracy and things like that.

And it's so easy to use.

It's like a mantra and convince ourselves that we're doing good and we're actually making quality when actually we're just going through the motions.

We're just conforming to certain ideals, which perhaps don't help users.

And that's the subject of the talk.

A lot of the best practices that I'm going to be talking about are much beloved of developers.

They're good for arguments and they're good for blog posts.

Managers like them because it keep things accountable.

And to some extent, clients as well, are served by best practices.

Now I appreciate that that is a crude representation of a client.

In fact, I've only ever actually worked for a very few clients who've been Halloween pumpkins who take intravenous drugs and are interested in haberdashery, probably as many as I can count on one hand.

But this is a kind of client who-- well, we know the kind of client.

So, users, though, where do they come into the picture? When we say best practices to ourselves or we're doing best practice, are we really actually improving the quality of the product for the people we are doing that service for? So here are the main areas of CSS best practice.

There's readability.

So, how easy it is to read the CSS code.

There's efficiency.

How quickly it computes.

And there's maintainability.

How much we can dick about with it without breaking it, essentially.

And so I'm going to address each of these in turn.

So here's readability.

So the best practice, the important question we have to ask about best practice in terms of readability is, which is best.

Is this best, or is this best? Is this best, or is this best? I'm sort of channeling my inner optometrist there.

Have you ever been to the optometrist where they just do the thing with the glass? In DevTools, that's where I spend 95% of my time adjusting, inspecting, and generally taking account of my CSS.

It reformats it all for me, anyway.

It does the syntax highlighting.

You can see it's actually-- I substituted the black keyword with a hexadecimal thing there.

And it tells me which line of the CSS I should be looking at.

So I think it's fair to say that the readability of it doesn't make that much difference to me, at least.

And I don't think it makes much difference to anyone else.

But still, the question remains-- because it's an important question, we like to have these arguments-- which is best.

Is it this type of inconsequential, noncritical, white space? Because CSS isn't affected by white space.

It computes the same way regardless of the type of white space we put in there.

Or is it this type of inconsequential, insignificant, nothingness white space? So let's put things into perspective.

When I'm on my deathbed-- this is going to get a bit macabre, but it's a bit early for that, I appreciate the-- when I'm on my deathbed, I want to look back at my life and think about the meager things that I've done-- and they aren't meager-- but the little things I've done to try and help people or make things for people that they might enjoy or they might guide them towards some information which might edify them or something like that.

I don't think I'm going to be laying on my deathbed thinking I was right to fight for tabs all of that time.

It's always tabs, never spaces.

It is tabs.

You have to be a complete maniac to use spaces.

But that's not the point.

It's not important.

So this is the important bit.

The important bit is I've worked on projects where that will break a build.

Travis will shout down my neck and say, screw you, you can't have this because there's a task here which says, if you have this bit of trailing white space on the end of a line, usually JavaScript, but you can set it up for CSS as well.

It will say, you are no good.

You are a worthless developer.

You have to redo this.

Whereas, if I was to make that ineffectual construction, a completely inaccessible approximation of a button using a div, that's fine with that.

That's no problem.

You can get away with that.

So I think that's a bit weird.

And in fact, it's a bit mad.

And you may have noticed, I'm wearing a t-shirt here, which has a picture of a child smoking a cigarette.

And above it, it says shocking finale.

And underneath, visual touch.

That makes less sense than my t-shirt.

Here's some more things that could break your build-- using things like a CSS linter because you're trying to maintain best practices and you put some automation in place to do that.

Using ID selectors.


Concatenating classes.


No, never do that.


Using a unit on a zero value.

Oh, no.

Using the important thing.

Qualifying headings.

You basically don't use descendant selectors.

Don't do that.

Get behind me, Satan.

But one thing that I won't get a complaint about as part of the build process is this-- using the most excremental possible font and just outright insulting the user.

All the test will pass doing that.

And I'm not saying that it's easy or even possible to have that as part of the build process.

But I think that we have an obsession with process and best practice which doesn't account for things which actually matter and actually have an impact.

And so is this really best, is this the best we can do for the user? So the secondary of readability is semantics.

Talking about semantics at this time in the morning.


So, Chris Coyier did a really excellent post a long time ago called "What Makes for a Semantic Class Name?" And at the beginning of his post, he has qualified that bad semantics is when you use classes to define the appearance of things, and good semantics is when you semantic HTML.

Now, the article there won't provide much interoperable information to save people who use assistive technologies or whatever.

But by the simple expedient that an H1 is there, that is infinitely better markup.

So, that's sorted.

That's been covered.

And yet, 109 comments.

I mean, he gets a lot of comments anyway.

But there's 109 comments on his article.

And most of them are arguing the toss over what makes a semantic class name.

Now that's an important concern to developers, perhaps.

But you know, how far does it go? But what really astounded me was this one comment.

Now I have no idea whether this person is taking the piss or whether they're trolling, I suppose.

I never considered where the class left or right was semantic or not.

But I suppose it is not.

I feel like my world is falling down around me.

Which feels, it seems hyperbolic to me.

To me, it feels kind of hyperbolic.

And I had this weird revelry about what might have happened to him that would cause him all of that pain.

So let's say he was having a peer program or peer designing type thing where they're trying to establish how they were going to use naming conventions within the project.

And he's arguing for this.

He's saying, well, I want left on the left and right on the right.

Is that left? Yeah.

Left on the left.

Right on the right.

I mean, that's bulletproof.

You cannot, you cannot do better than that because that is left is left, right is right.

So, yeah.

And then, of course, his colleague will say, well, let's talk about break points.

What? So, you know, that's the sort of thing that you might expect.

So what we tell ourselves is that we should name things for the type of content they are.

That's the way we should use classes.

But the thing is that main and sidebar-- I mean, even sidebar could argue it's not right because it implies that it's to the side-- don't provide any information to any users.

This is all in code, which the average user doesn't look at.

HTML is the interface.

And this is the most important lesson I've learned since I've started to work in the field of accessibility.

You have to think of HTML as the interface and CSS is just the branding.

CSS is just what the interface looks like.

You don't interact with CSS anymore than you have sex with someone by looking at them, which would be weird and creepy, anyway.

So here's another example using navigation.

So what should we call our navigation block is the question.

Should it be nav, or is it more semantically correct if within an application to call it a menu.

Or if not a menu, perhaps we should call it main-nav if it is the main nav.

So maybe we should start to connect the dots.

But should we use one hyphen or should we use two hyphens to connect those two concepts together? And it's all a bit of a moot point because the only things that you really have to put in the markup are the correct elements.

And in the case of nav, or it's better supported using the ARIA role of role equals navigation, you are actually providing information.

And you're providing navigational cues for people using assistive technologies.

So if you're using NVDA or JAWS, you'll be able to pull up a dialogue which will list all of the landmarks, which would include your navigation landmark, which can then be navigated straight to.

So that actually has an impact on some people.

Real people, not developers.

And the thing is, it's not just the case of you need to put that stuff there.

And then you also need to think about the way you're going to style it.

You might as well tie the two things together because that's robust.

That's getting close to actually being a genuine best practice if you're using the kind of selectors which are conducive of the correct markup.

So you can just style the element nav or you could style with the attribute selected, role equals navigation.

So the really important thing to remember there is that if you have used a role of navigation in your style sheet but you haven't actually put that attribute in the markup, it won't look like what it is, what it actually is interoperably, what it is to everyone, so you know to be able to fix it.

So that seems like a fail-safe, a natural way to do things in a better way.

So let's talk about states.

Why not? A state is something that augments and overrides all other styles.

For example, an accordion section may be in a collapsed or expanded state.

Fairly straightforward.

This is from the book or perhaps the online documentation for SMACSS, which is the CSS framework.

And it suggests that you might want to do something like a tab, which would define a generic tab.

And is tab active to define the tab which is the one in the foreground, which corresponds to the open pane.

That makes sense.

It's good to use conventions because, then, it's easier to maintain.

The problem is that that doesn't actually, again, provide any information other than visual information.

So classes only define the appearance of the state.

To an assistive technology user, they would have no idea that they were actually even interacting with something which is supposed to approximate a tab interface.

So the only unequivocal way to define stars, the only really genuinely semantic way to define the selectors for a tab interface is to use the roles and properties, which should always be there if you're doing it properly.

Now that those technologies are there, it's like using the right HTML.

Use the right extension semantics.

So role equals tab because you need a role of tab on a tab so that that semantic is provided so that it can be heard as well as seen.

Role equals tab-- and you can concatenate attribute selectors like you can with classes.

ARIA-selected-- that's the state.

So that would correspond to that foreground tab.

This, you don't need to use any other selectors.

That's done.

We're done with that now.

So we don't have to argue about it anymore.

And this is the payoff, I suppose, is that when someone using AT is actually interacting with it, they will actually get this read to them, "active tab, two of three, CSS."

They get context.

They get the actual semantic of the thing that's being focused.

And then they get the label, of course.

The label is the accessibility term for text, basically.

Then, any reason you'd want to use class is, is if you wanted to have different tabbed interface styles all on the same page.

Now that's just a UX nightmare.

I don't know why anyone would want to do that.

So I suppose what I'm saying is that the idea of object orientating everything only goes so far, when it actually means fragmenting things arbitrarily and unnecessarily.

W3C actually has its own sort of best practice rules.

They call them authoring practices.

And one of them is tied to the CSS display property to the WAI-ARIA hidden state.

So what they're saying is the actual state should be tied to the appearance of that state because there will be some user agents which only deal in the state itself.

They won't implicitly regard something which is, say, display, none as display hidden.

So that's robust.

That to me is an actual best practice.

So there it is.

This is a complete list of states as defined in the ARIA spec.

There is nothing there.

There's nothing you can make in one of your applications which will not be in some way analogous to one of these.

So there's no point arguing about what names you should use via classes, because you might as well use these.

And talking of semantics, it's just as simple as putting the boxes on either side.

But, ha, what about types of buttons? As someone did say to me not so long ago, this is all very well and good, but I need more verbosity if I'm designing my interface.

I've got loads of buttons in my interface.

My first reaction was, if you've got 20 different buttons that was in your interface, I don't want to use it.

It sounds like a nightmare.

That was the sort of thing I'd want to pull my hair out with.

But let's just say that that was true.

How do you define the difference between things in terms of their ontology rather than just the state that they're in? And the answer is text.

You just use text.

You put text in.

Just text.

Put text in there.

So if it's a Save button, you have to text save.

Or if it's an Edit button, the text edit, and so on and so forth.

And text is supported since IE1.

So it's well-supported and it's highly accessible.

You have to put text in there anyway for accessibility reasons, otherwise it won't be compliant.

So you might as well just lead with text.

I keep saying text.

I've got a bit of an obsession.

Let's talk about efficiency now.

This will be fun.

I get a lot of jip from people telling me that when I use attributes and selectors and things like that, it's very nonperforming and I'm being a bastard to everyone because I am making slow CSS.

I've read a lot of studies about this, and I haven't seen any evidence that that is the case.

So let's compare two selectors here.

Now notoriously, the class selector compiles the style, I suppose, faster than an attribute selector.

Let's say that this is true.

Let's say that at this point in the race, that Greyhound is a nose ahead.

And it will be a nose.

It won't be much difference between the two.

The only way that you can even see a difference between this performance of actual selected types is if you create a DOM completely and utterly filled with garbage.

And that's your problem.

You don't want to do that.

And then you won't have the problem with the selectors.

But something really interesting happens after this point in the race.

Something perhaps unexpected and a little bit weird.

And it's subtle, it's subtle.

But something interesting happens at this point.

At this point, the class is ahead, but the attribute selector is behind.

But at this point, what happens is that you start loading massive resources like JPEGs and unsubsetted web fonts and all the sort of things that you can actually see your page be affected by.

So you'd see your JPEG actually loading down the screen, or you'd see all of that white, you know, the flash of non-text content or whatever it's called.

So that's the sort of thing which will actually affect it.

I spoke to a representative from Topcoat, which is a framework a little bit like Bootstrap, not so long ago.

And I suggested to him that perhaps this example, which is used in CSS code, should be changed because making a button like that is making a button which doesn't work because it's a link, it provides the wrong semantics.

Because in assistive technologies, it will be read as a link.

So people pressing it will think they'll go somewhere rather than it do something.

That's the difference between links and buttons.

But also, it doesn't have an href.

And links which don't have hrefs aren't focusable.

So a keyboard user can't use that.

They were very good.

They were very accommodating.

And so I do appreciate that.

And they've changed those examples to actual buttons now.

But what I found interesting was the reason that they haven't done that already was that they were razor focused on performance.

And it seems to me like a question of priorities here.

And that their priorities were a little wrong, really.

It's sort of like saying, I've manufactured you a car.

It's a fast car.

It's a brilliant car.

You touch it or it insomuch as runs over a snail, it would explode.

It'll just blow up.

You'll die, everyone's dead.

But the seat warmers are really rather nice.

So the one time-- that actually makes me feel sick looking at that-- the one time that performance will become a problem with CSS is when you're animating everything.

If you're doing lots and lots of concurrent animations, things will slow down.

The thing is, I never see that happen in talks like this one, except ones which are about performance, where you're deliberately trying to make things as slow as possible to make a point about how you would then inspect it and try and fix it.

Or, it will be based on the diktat of, well, him-- Mr.


Do you remember when we had to fight clients off and tell them not to do that.

Now, it's OK to do it because of CSS3.

It's exciting, right.

The user, of course, never wants any of that.

But it's a bit worse than that.

As the Zeldman points out himself, some types of animations-- not all animations, I mean, a little bit of animation is really nice, right.

And it can sort of helps tell the story and guide you along.

But a lot of animation, the kind that would actually bring on a performance problem, well, it can make people physically sick.

So imagine you've built something using best practices all the way home.

So all these are really high performance animations.

They're hardware accelerated and all of that stuff.

And yet, it's so bad that someone's actually throwing up.

That's some pretty bad design work, right.

And I spoke to my friend Dennis about this.

And he astonished me.

This is a genuine anecdote.

He maintains it's true, that his co-worker told the designer that she experienced vertigo whilst using a parallax animation effect.

And they said, no you don't.

And that, it's almost depressive, really, isn't it.

I mean, that picture I had at the beginning of the talk with big brother, and there's a reason for that, is this sort of we're all right, you're going to accept what we've made for you.

You're just going to accept it.

It's best practice.

And then best practice starts to sound like political rhetoric, then, doesn't it.

And it's this sort of waiver, saying-- I try to imagine it, like the conversation being had in the fancy design agency-- and then saying, right, I think the product is done.

We're ready to ship.

It's looking good.

Come on guys, we're going to be rich.

We're going to be rich.

And then we can go down to the bar.

Sorry, what? Oh, that.

Yeah, no that's vomit.

That's vomit.

Head to toe, I'm covered in sick there.


No, no, not my vomit.

Someone else's vomit.

Best to ignore that.

Best to ignore that.

It's a great product.

We use BEM in this one, actually.

Yeah, it made it much more modular.

Yeah, so shall we? Yeah, let's go down.

Let's go to the pub.

So, the last one I want to talk about is maintainability, which is probably the most contentious area.

I think it's our biggest obsession because things get complex really quick, right.

And as professional front-end developers, we are charged with managing to take care of that complexity, to accommodate that complexity.

So pre-processes with variables and object-oriented CSS, because it's about the dry principle and reusing components and things like that.

BEM, which is a mad version of OOCSS and all of this the in-house within your team ways of managing this stuff and the rules and guidelines that you give yourselves.

That's the complexity we're looking at.

A traditional webpage just looks like florid prose, which just goes title, text, title, text text text, like that.

That's more what we're looking at.

But what is it made of? Where does the complexity come from? We know that users don't like complexity.

There's books written about it.

Don't make me think it's all about just making stuff as simple as possible because people want to achieve tasks and go somewhere else.

So where does it all come from? This is the funder obligatory widget.

This whole website was funded by someone who, because they've had a stake in it and because it wouldn't exist without their funding, they have demanded that a large part of the website will be dedicated to their product, which is completely irrelevant to the content of the website.

These are the social media bits.

People know how to share things, anyway.

But they're there, anyway, just to speed up the page-- sorry, slow down the page by about 800%.

Carousel-- demonstrably, completely inaccessible.

And the client, whether they demand it or not, will not get any return on investment on that because no one ever clicks on any of the slides apart from the first one.

And it moves around and makes people physically sick, presumably, as well.

This is Ken's thing.

Everyone has a Ken.

There's always a Ken.

Maybe it's a Ken, maybe it's a Steve.

Or it's someone like that.

And he's got a bad personality.

And what he does is he hijacks meetings.

And he starts saying, oh, we need to get this thing in here.

It's like his brainchild.

No one wants to argue with him.

Everyone is tired and bored.

They're fed up with his project already.

So he just gets his way.

I have no fucking idea what that thing is.

But it's something that Ken has decided will be there.

I've worked on projects where this happens, by the way.

This is an advert for a news site feature.

So there will be a part of the site which they put somewhere else which isn't on the homepage.

But they have so little faith in the people who are using the website that they've decided that they have to actually make a small version of it and put it on the front page, as well, because they didn't think they can use the navigation to get to it.

This is the feedback widget.

At this stage, it's looking pretty bad.

They're thinking, maybe this website is not going to pull together too well.

So they're going to placate the user by saying, we realize this is rubbish.

Here's a feedback widget which allows you to write comments towards us about improving the website, which we'll never read.

So that's just third party adverts.

So we're just asset-stripping now.

We know it's going to fail.

So we're just going to try and get a little bit of return on our investment there.

Now as front-end developers-- oh, sorry, that's the editorial, that's the content-- then we need to make sure that we've used all of our best practices regarding modularity, some sort of methodology to make sure that all of this stuff can be moved around.

Not that it needs to be moved around.

It's just because the client or someone else in the organization is like a psychopath supermarket magnate type person who just-- you know, when you go into supermarkets and they always change the aisles for no reason.

And it's no good to the user.

They like to know where things are and for them to stay where they are, but still.

And then, we've got our engineering badge because all of that stuff that's been put together as bad as it is, as front-end developers, we've done a really good job of making sure that that has happened.

Now, have we really done a good job or have we just facilitated an abomination? Difficult question.

This is the Sky Sports website.

I'm white and I'm British.

I can't stand football, so it's easy for me to criticize this website.

But it was used as an example by someone to say that, well, you wouldn't be able to maintain a website of this complexity without using some sort of object-orientated methodology or what have you, which is a fair point.

I hate this website.

And I told them I'd rather that the website didn't exist at all.

But that's just my opinion.

You can tell it's my opinion because it's coming out of my mouth.

But it wouldn't be fair for me to just say, I don't like this, it's rubbish.

So I'm going to compare it to something which does not use a methodology like that.

And that is the book "1984" by the author George Orwell.

This book does not use any kind of a methodology for modularity or anything like that.

It just starts from the beginning and goes to the end.

In terms of content, it's very good.

This is perhaps one of the most seminal works of fiction in the last 100 years.

Whereas, the Sky Sports website-- well, the content is, well, you've got 1-0.

You've got 2-1.

Occasionally, you get a 3-5.

Not very often, but you do get them.

You do get them sometimes.

I don't have anything against anyone who likes football.

If you like football, you like football.

But I think, when it came down to it, if you really had to choose, this is probably of more value, I suppose.

But you can move stuff around on the Sky Sports website.

And you can rearrange all the content.

It's configurable.

This is not configurable.

From beginning to end, all of the pages run onto each other.

So George Orwell is not able to respond and react to the demands of his publisher.

He's not able to be micromanaged because of the format of his book.

What if the marketing department decided that the word on page 323 of Winston, which is the name of the main character, was-- that had some good feedback.

We decided that users like that.

It's not on the first page.

So we'd actually have to take the page out and move it to the front of the book.

But that wouldn't stop there, would it, because it just goes on and on and on.

So they decide that, well, that was good.

But there's another page that we quite like which has the word telescreen, sort of techie.

People like tech.

Let's take that out and put that on the front of the book as well.

And on it goes.

This is garbage.

So we used to call ourselves web designers, didn't we.

Do you remember when we used to call ourselves web designers? And then we became front-end developers.

And I think the term front-end developer is a bit of a weird term.

It's like saying I'm an upstairs fireman.

But the important difference is that I suppose we gave up being called web designers because we were afraid that the term designer meant making things pretty, or at least that's an element of it.

And so we've adopted a term which sounds a lot more technical and professional because we want to prove to people that we can actually do things as well as just make things look a certain way.

But we've given up something quite important in that process, I think.

We've given up what design really means.

And the difference between being a front-end developer and being a designer is this.

A front-end developer asks, how should I do this.

You are told in a ticket, or by a client directly, or by your manager, or by a colleague, that you have to do something.

Can you do it? And you have to prove that you can because it's a matter of professional pride to be able to demonstrate that you can do something.

And so you do it.

Or you find a way.

A designer asks, should I do this.

So before they even get into how they can do it, they ask, should I really actually be going down this road.

Is it right? Let me give you one last example using the Sky Sports website.

There is 424 links on the Sky Sports website's homepage.

That is too many links to get through.

If you're using a keyboard, it would take you seven or eight years to get from the top of that page to the bottom of the link just using the Tab key.

The Tab key would burst into flames.

Not one of those links has an outline for focus.

They've removed that on all of the links.

All 424 links are not focusable by keyboard.

So that's gone because no one said, should I do this.

Someone said, we want to get rid of that because it's ugly.

And no one said, should I get rid of that.

There was no design of it.

But they haven't stopped there.

Most of the links have had this removed as well.

So the only way to differentiate between link and normal text is now by color.

And a lot of people who have problems with color blindness will not be able to differentiate between a dark blue and a black.

So that makes it yet more difficult for another group of people.

No one said, should we do this.

But it didn't stop there.

A lot of the links on that page actually have the actual color removed, as well.

So it just looks like text.

The only way to actually know whether something is a link is to hover your mouse over it and see if you get a hand.

Now, there are two members of my family-- one deceased and one who is still around-- who have Parkinson's.

And there is no way that they're going to go into the Sky Sports website and do that for 20 minutes, trying to click on things, let alone do it just to find out if anything is clickable at all.

So with all of this stuff that we've now attached to CSS, all of these things that we've now decided are important parts of the process in making good CSS, if the people that made the Sky Sports website had done literally nothing and hadn't provided any CSS at all-- because the user agent styles for browsers will provide an outline-- it would be a better interface in a very, very important way.

And that, I think, is slightly worrying.

So who does actually do the should I do this stuff, and who does the ensures that we make these websites usable and workable? What we do is we pay expensive accessibility consultants long after the project is finished to come in and press our Tab keys for us.

And it's not that difficult, is it, to just press the Tab key and look around and go, oh shit, I can't see any visual feedback.

So we need to change that.

We need to sort that out.

And I think that's weird that we have all of that process and all of that stuff we call best practice.

We use that superlative and nobody is actually doing that quite yet.

And I think it's time that we all took a lot more time to actually think in terms of a design and not someone who makes things pretty, but someone who actually worries about what should and shouldn't be done, what's actually going to work for people, for the users.

Because although we have designers in our organizations, often, they're the people who are sitting in a corner making dribble shots.

And whilst the work that they do can be valuable, they are still not working in the same medium.

Making something accessible is still part of design.

And that's all I have to say for today.

Thank you.

[APPLAUSE] Come and join me in my lounge, which chair would you like? I'll have this one.

Yeah, yeah.

So you're not having to walk as far.

Thanks, Jake.

That's OK.

You're sitting comfortable? Yeah.

I think these jeans are a bit tight.

So when you were saying before, we are all going to die.

I think that's [INAUDIBLE].

Yeah, yeah, yeah.

We definitely are, right.

Is that? I don't know when.

I just know its an inevitability.

I saw "Final Destination" with a friend.

And when we left the cinema, they said, I don't know how I'd cope with that.

I couldn't live knowing I was going to die.

I had to sit them down and go, I have some really bad news for you.

So I think on the web, in terms of designs, like gradients were really, really popular.

And we were all doing them with images and stuff.

Don't worry, that's just the next talker .

Your work over there is done.

They can burn that now.

Yes, we had gradients.

We were doing them with images.

And then we actually got support in CSS to do these things.

And then now, designers are like no, we just want flat colors now.

Based on that, should we get native support for parallax scrolling, in the hope that it will go out of fashion really, really quickly.

That's good thinking.

That's good thinking.

So, we have native support for everything which is abominable, then, yeah.

I mean, basically, anything which is specified, which the W3C or is there any other standards organization tells you should do.

Designers and developers, they don't like being told what to, which is why we tend to make our own vocabularies, usually through classes and data attributes and things like that.

So yeah, anything which we don't want people to do, we should tell them that they should do it.




I think that's [INAUDIBLE].

So you mentioned like Ken's thing.

I've encountered this before, especially when I was working at the BBC.

How do we kill Ken? What culture change do we need to make happen to stop that? I suppose the way I was talking about it, I was talking about it a little bit bitterly.

But I mean, it's just the way these things are where you do have people like that.

But what I suppose bothers me is people's unwillingness to say no.

I mean, if one was a doctor, and the patient started telling the doctor, actually, I'd prefer you did my heart surgery this way.

I mean, doctors have a reputation for being arrogant, of course, because they will tell you, I'm a doctor, I know what I'm doing.

But I think we should be doing that a bit more, I think, in a kind way.

But we should be saying, I think this will actually be better for your audience if we do this.

I like that metaphor because you can end up having a patient sitting there with their stomach open and they're like, oh, so that's where you're leaving my lung.

Can I not drag and drop that and put it down here.

It's always drag and drop, isn't it.

We should standardize drag and drop a lot more.

That's true.

Well, I've had that with clients before where we've shown them designs and they've said, oh, this is really cool.

Can I take this side bar and drag it into the main bar.

And we're like, well, no you can't.

But why not? Because it would look terrible.

Like you've paid us thousands of thousands pounds to do this site.

No to do that, right.

So what has made, what has brought on clients to think that that's a good idea, and how can we stop that? I think a lot of it is to do with just people who have a little bit of an insecurity about their role within an organization.

And it's not that they have strong ideas about how something should be done, it's more that they feel that they should be involved.

They perhaps rather not be involved.

They'd rather let someone else get on with it.

But it's a case of, I feel like I should be doing something here.

I've had clients who have been coming back to me and back to me and saying, can we just tweak this and can we just tweak this and can we just tweak this.

And the best thing I could say to them, and the only way I could make them happy and less anxious about it was to just say, it's finished now.

And they're like, oh, brilliant, OK.

So none of that was really important to them.

It's just that they didn't want to let go of it, I guess.

So you're talking about outline effects and how we see so many sites just removing outlines blanketly across site.

Well, what do you think makes people do that? What brings that home? The thing is, I've done it.

And so I'm not pointing any fingers.

I remember when I started using jQuery UI and when you pulled up a dialogue, one of the buttons in the dialogue would be focused already.

And that's important for accessibility because then you're ready to dispel the dialogue.

And I looked at it and I saw this weird mark around it.

And I thought, that's a bug, isn't it.

That's a bug.

We must be able to hook into this and get rid of it.

And now a few years later on the same project, I'm doing an accessibility audit on it, and I've got myself to blame for a lot of terrible things which have been done to it.

Do you think we need some kind of way, then, to separately the idea of carrot focus from widget focus from element focus? Yeah.

Yeah, I think I think part of the problem is that dotted outline, which is sort of standard.

It's a compromise between that-- that's very well recognized as a focus thing.

So I think perhaps-- although I'm guessing a lot of keyboard users like to see that because then they know that's what it means.

But I've experimented a lot with different ways of showing focus for web elements.

So you change the background color, or you could have a thicker outline, or you could change a border, or use box shadow or something like that.

As long as it's really obvious and clear.

And in that case, using animation is a really interesting approach, as well, because you see something come into focus.



So I've worked in interfaces before, one that was kind of like a remote control.

And I made it have a tab index that made sense.

Usually, it's just based on element order.

But when you clicked or tapped those things, like select on the remote control, it would then get focused, which would give it a focus state.

But that doesn't work for the design, right, because it's tapped.

You just want it to click and be done.


That's like the ARIA spec has an ARIA-pressed state for buttons.

So that would be a button which is in a pressed state.

So it's like in an on state, I suppose.

So it corresponds to something which is going on elsewhere in the page.

And I think that's interesting because when I write active styles, I'll put them in a comma-separated list of selectors with the ARIA-press styles, with the ARIA attribute selectors so that i know that the momentary pressing in style, which would usually be a relative positioning with a change of box shadow or something so that it looks like it's being depressed, will be the same as it looking constantly depressed.

And so you could tie those things together and save yourself a bit of time and worry, I suppose.

So ARIA-pressed is for the intermediate state, or is that for the constant? No.

The Aria-pressed is for the constant state of it being on.

So if you have three buttons, they're different modes.

Oh, like radio buttons.


So they're like radio buttons.

It's kind of analogous to that.

Yeah, that's right.

So when it comes to assigning class names for just arbitrary design changes, I know I've seen that with some of your examples with buttons.

Sometimes, they'll be a button at the top of the page or somewhere else that wants a kind of special attention to it so it will be bigger.

Well, what do you do in that case because I don't know if there's a rule or something to kind of say, this is arbitrarily the [INAUDIBLE].


That's the thing.

I do think that ARIA extends the vocabulary of HTML are almost to the point where you can do a lot of design work in that robust form-follows-function way.

But there's always going to be that point where using classes, perhaps, to pick things out is interesting.

But there is contextual cues you can use as well.

So I'm working on something at the moment where I'm trying to make it a little bit more automatic.

So for the person who'll just be writing HTML but they're not really interested in learning a class vocabulary.

I would, for instance, if there was a button on its own, that I would make bigger.

So I'd use a pseudo-class of only of type.

That perhaps would be a button which is larger.

Whereas, if it was two buttons next to each other, only of type no longer applies, they'd be smaller.

So that might be another way of doing it.

But it's a little experimental, I suppose.

Is there a danger there if you're trying to make sure your class names, I guess, as generic as possible to avoid leaking in design into them? Is there a danger that they become almost meaningless, like you end up just using a lot of synonyms for button because you're running out of words.

I think it's ironic that you can have this long debate about what the most semantic, as in what the most sensibly written word or term is for a button, and ultimately, you can only possibly arrive at button.

And there's an element called button.

So you might as well use the element.

I often look at Flexbox or something that maybe went slightly wrong.

Well, its naming is based on the idea that it can be in any direction.

It's OK.

You can say that Flexbox went wrong.

That's cool with me.

Tab Atkins slept through my talk at CSS.

No, he was cool.

It was an interesting talk but-- so wrong in what way? Well, I mean, I know when I see there's a Flexbox and it's align something or justify something, I have to go back to the spec to work out which access that might be working on.

And this is another thing which I find extraordinary, it's adding complexity to try and make things more simple.

That I find weird.

And that applies to class semantics as well.

There's already a vocabulary there with a specification that you can go and address to find out what those things mean and how they should behave.

And that's all written by the W3C.

And then so then adding your own vocabulary to make things easier and more manageable seems like a weird thing to do because then you've just got two lexicons butting heads.

So yeah, I think systemically then you're bound to create something which is over complex.

And I think Flexbox is really powerful.

And I've used it in projects where it's been really, really handy.

But yeah, it takes a long time to learn it.

And I do like things being simple.

And I wonder whether someone who's quite a junior web developer would be able to get their head around it.

Well, thank you very much.


A big round of applause for Heydon Pickering.

Thanks, guys.

Thank you.

Thank you very much.

Thank you.

Post a comment