Die 7 1/2 Todsünden des Barrierefreien Webs

68
Die 7½ Todsünden Barrierefreien Webdesigns Eric Eggert A-Tag ’08

description

 

Transcript of Die 7 1/2 Todsünden des Barrierefreien Webs

Page 1: Die 7 1/2 Todsünden des Barrierefreien Webs

Die 7! Todsünden Barrierefreien Webdesigns

Eric EggertA-Tag ’08

Page 2: Die 7 1/2 Todsünden des Barrierefreien Webs

Eric Eggert

Page 3: Die 7 1/2 Todsünden des Barrierefreien Webs

!

Page 4: Die 7 1/2 Todsünden des Barrierefreien Webs

Eric EggertFreier WebdesignerMitglied der Webkrauts, der HTML5-WG und der BAD-TF des W3COrganisator des WebMontags und des A-Tags ’08Webdesign seit 2001

*

*Und ich mag große Schrift!

Page 5: Die 7 1/2 Todsünden des Barrierefreien Webs

Eric EggertFreier WebdesignerMitglied der Webkrauts, der HTML5-WG und der BAD-TF des W3COrganisator des WebMontags und des A-Tags ’08Webdesign seit 2001

HyperText Markup Language

*

*Und ich mag große Schrift!

Page 6: Die 7 1/2 Todsünden des Barrierefreien Webs

Eric EggertFreier WebdesignerMitglied der Webkrauts, der HTML5-WG und der BAD-TF des W3COrganisator des WebMontags und des A-Tags ’08Webdesign seit 2001

Arbeitsgruppe

*

*Und ich mag große Schrift!

Page 7: Die 7 1/2 Todsünden des Barrierefreien Webs

Eric EggertFreier WebdesignerMitglied der Webkrauts, der HTML5-WG und der BAD-TF des W3COrganisator des WebMontags und des A-Tags ’08Webdesign seit 2001

Before and After Demo Task Force

*

*Und ich mag große Schrift!

Page 8: Die 7 1/2 Todsünden des Barrierefreien Webs

Eric EggertFreier WebdesignerMitglied der Webkrauts, der HTML5-WG und der BAD-TF des W3COrganisator des WebMontags und des A-Tags ’08Webdesign seit 2001

World Wide Web Consortium

*

*Und ich mag große Schrift!

Page 9: Die 7 1/2 Todsünden des Barrierefreien Webs

Eric EggertFreier WebdesignerMitglied der Webkrauts, der HTML5-WG und der BAD-TF des W3COrganisator des WebMontags und des A-Tags ’08Webdesign seit 2001

*

*Und ich mag große Schrift!

Page 10: Die 7 1/2 Todsünden des Barrierefreien Webs

7 TodsündenCatholic Church Hardcore Edition

Page 11: Die 7 1/2 Todsünden des Barrierefreien Webs

Was ist eine Todsünde?

Page 12: Die 7 1/2 Todsünden des Barrierefreien Webs
Page 13: Die 7 1/2 Todsünden des Barrierefreien Webs

1.Schwerwiegende Materie

zum Gegenstand

Page 14: Die 7 1/2 Todsünden des Barrierefreien Webs

Volles Bewusstsein

2.

Page 15: Die 7 1/2 Todsünden des Barrierefreien Webs

Aus freiem Willen heraus

3.

Page 16: Die 7 1/2 Todsünden des Barrierefreien Webs

Was ist eine Todsünde?

Page 17: Die 7 1/2 Todsünden des Barrierefreien Webs

7! Todsünden des Barrierefreien Webdesigns

W3C Hardcore Edition

Page 18: Die 7 1/2 Todsünden des Barrierefreien Webs

7! Todsünden des Barrierefreien Webdesigns

W3C Hardcore EditionFirst Working Draft

Page 19: Die 7 1/2 Todsünden des Barrierefreien Webs

1. Todsünde

Page 20: Die 7 1/2 Todsünden des Barrierefreien Webs

SuperbiaHochmut

Page 21: Die 7 1/2 Todsünden des Barrierefreien Webs

SuperbiaHochmut

Page 22: Die 7 1/2 Todsünden des Barrierefreien Webs

SuperbiaHochmut

Page 23: Die 7 1/2 Todsünden des Barrierefreien Webs

SuperbiaHochmut

Page 24: Die 7 1/2 Todsünden des Barrierefreien Webs

SuperbiaHochmut

Page 25: Die 7 1/2 Todsünden des Barrierefreien Webs
Page 26: Die 7 1/2 Todsünden des Barrierefreien Webs

„Wir bekommen die Webseite auch irgendwie barrierefrei hin!“

(Machen wir halt ’ne Text-Version dazu!)

Page 27: Die 7 1/2 Todsünden des Barrierefreien Webs

„Wir können das schon selbst mit dem CMS!“

Page 28: Die 7 1/2 Todsünden des Barrierefreien Webs

2. Todsünde

Page 29: Die 7 1/2 Todsünden des Barrierefreien Webs

AvaritiaGeiz

Page 30: Die 7 1/2 Todsünden des Barrierefreien Webs

„Dem Sohn des Freundes meines Nachbarn sein Onkel macht aber

’ne ganz billige Homepage!“

Page 31: Die 7 1/2 Todsünden des Barrierefreien Webs

„Dem Sohn des Freundes meines Nachbarn sein Onkel macht aber

’ne ganz billige Homepage!“

Page 32: Die 7 1/2 Todsünden des Barrierefreien Webs

„Müssen wir wirklich AA erfüllen oder reicht da nicht Level A?“

Page 33: Die 7 1/2 Todsünden des Barrierefreien Webs

„Alte Inhalte müssen aber nicht Barrierefrei sein, oder?“

Page 34: Die 7 1/2 Todsünden des Barrierefreien Webs

„Wie kann ich mich davor drücken?“

(Okay, das hat noch niemand gefragt… aber schon gedacht.)

Page 35: Die 7 1/2 Todsünden des Barrierefreien Webs

3. Todsünde

Page 36: Die 7 1/2 Todsünden des Barrierefreien Webs

InvidiaNeid

Page 37: Die 7 1/2 Todsünden des Barrierefreien Webs

„Die anderen haben doch aber viel mehr Ressourcen als wir!“

Page 38: Die 7 1/2 Todsünden des Barrierefreien Webs

„Andere Webseiten müssen doch auch nicht barrierefrei sein!“

Page 39: Die 7 1/2 Todsünden des Barrierefreien Webs

4. Todsünde

Page 40: Die 7 1/2 Todsünden des Barrierefreien Webs

IraZorn

Page 41: Die 7 1/2 Todsünden des Barrierefreien Webs

„Es ist doch gar nicht möglich Seiten barrierefrei zu machen!“

Page 42: Die 7 1/2 Todsünden des Barrierefreien Webs

„Deine Seite ist aber auch nicht valide!“

Page 43: Die 7 1/2 Todsünden des Barrierefreien Webs

„Deine Seite ist aber auch nicht barrierefrei!“

Page 44: Die 7 1/2 Todsünden des Barrierefreien Webs

„Deine Seite ist aber auch nicht hübsch!“

Page 45: Die 7 1/2 Todsünden des Barrierefreien Webs

5. Todsünde

Page 46: Die 7 1/2 Todsünden des Barrierefreien Webs

AcediaFaulheit, Feigheit, Ignoranz

Page 47: Die 7 1/2 Todsünden des Barrierefreien Webs

„Der Nutzer muss schon dafür sorgen, dass er auf die Webseite

zugreifen kann!“

Page 48: Die 7 1/2 Todsünden des Barrierefreien Webs

„Ich bin aber viel schneller fertig, wenn ich das mit einer

Tabelle mache!“

Page 49: Die 7 1/2 Todsünden des Barrierefreien Webs
Page 50: Die 7 1/2 Todsünden des Barrierefreien Webs
Page 51: Die 7 1/2 Todsünden des Barrierefreien Webs
Page 52: Die 7 1/2 Todsünden des Barrierefreien Webs
Page 53: Die 7 1/2 Todsünden des Barrierefreien Webs

Activate your free membership today | Log-in

The Web Renaissance is here

NEWS PODCASTS SHOWCASES RESOURCES TRAINING CONFERENCE JOBS PLANET PATTERNS CONTRIBUTE NEWSSearch

JOBS @ AJAXIAN

Find a Job, Post a job.

TOPICS

.NET (66)

Accessibility (49)

Adobe (79)

Advertising (3)

Ajax (364)

Ajaxian.com

Announcements (6)

Android (2)

Announcements (87)

Apple (2)

Aptana (26)

Articles (206)

Atlas (6)

Book Reviews (19)

Books (30)

Browsers (164)

Builds (4)

Business (16)

Calendar (12)

Canvas (72)

Chat (22)

Chrome (3)

Cloud (3)

ColdFusion (10)

Comet (53)

Component (111)

Conferences (27)

CSS (129)

Database (10)

Debugging (23)

Design (17)

Dojo (205)

DWR (17)

Editorial (272)

Email (5)

Examples (155)

Ext (69)

Firefox (83)

Flash (75)

Framework (59)

Fun (68)

Games (59)

Gears (65)

Google (142)

GWT (75)

HTML (53)

IE (120)

Interview (28)

iPhone (53)

Java (143)

JavaScript (1058)

jMaki (7)

jQuery (117)

JSON (46)

Library (482)

LiveEdit (5)

LiveSearch (17)

Mac (1)

Mapping (39)

Microformat (3)

Microsoft (37)

Mobile (50)

MooTools (38)

Mozilla (4)

Office (9)

Offline (29)

OpenAjax (6)

OpenWebPodcast (4)

Opera (17)

Performance (100)

Perl (8)

PHP (83)

Plugins (7)

Podcasts (37)

Portal (13)

Pragmatic Ajax (2)

Presentation (60)

Programming (134)

Prototype (211)

Python (11)

Qooxdoo (2)

Rails (38)

Recording (8)

Remoting (19)

RichTextWidget (19)

Roundup (13)

Ruby (63)

Safari (45)

Screencast (36)

Scriptaculous (37)

Security (77)

Server (13)

Showcase (656)

Social Networks (15)

Sound (8)

Standards (48)

Storage (3)

Survey (12)

SVG (19)

Testing (45)

The Ajax Experience (72)

TIBCO (24)

Tip (74)

Toolkit (168)

Tutorial (20)

UI (111)

Unobtrusive JS (21)

Usability (77)

Utility (160)

W3C (8)

Web20 (24)

Widgets (10)

Workshop (7)

XmlHttpRequest (41)

Yahoo! (118)

ARCHIVE

November 2008 (60)

October 2008 (104)

September 2008 (107)

August 2008 (97)

July 2008 (100)

June 2008 (103)

May 2008 (93)

April 2008 (110)

March 2008 (108)

February 2008 (113)

January 2008 (110)

December 2007 (92)

November 2007 (106)

October 2007 (123)

September 2007 (99)

August 2007 (109)

July 2007 (89)

June 2007 (86)

May 2007 (89)

April 2007 (87)

March 2007 (106)

February 2007 (87)

January 2007 (105)

December 2006 (92)

November 2006 (120)

October 2006 (120)

September 2006 (92)

August 2006 (106)

July 2006 (100)

June 2006 (83)

May 2006 (99)

April 2006 (78)

March 2006 (111)

February 2006 (117)

January 2006 (118)

December 2005 (106)

November 2005 (111)

October 2005 (67)

September 2005 (87)

August 2005 (85)

July 2005 (51)

June 2005 (70)

May 2005 (63)

April 2005 (11)

March 2005 (23)

0 (1)

TechTarget Events, the most targeted events for today's top enterprise ITpros. View full schedule of upcoming topics and dates!

Powered by WordPress.

Entries feed. Valid XHTML and CSS.

All rights reserved, Copyright 2008. About Us. Privacy Policy

57 Comments »

I have yet to see a layout in IE6+, FF2+ that required tables….

.

Does someone actually have an example of one that is easier to create and

read with tables?

Comment by TNO — November 12, 2008

I dont use tables but there have been many times I keep thinking why on earth

I chose to do something with CSS in the end. Especially true when something

looks ok in firefox and when i preview in IE the div’s won’t fit and fall under.

Comment by kyriakos — November 12, 2008

I *really* don’t understand the evangelists.

Fact:

* Not all of us are CSS gurus

* Not all of us know all the CSS hackery by heart, nor want to

* The boss wants you ‘to get the shit done’

* Some weird CSS hackery (like, for instance, a mulit-column auto-scaling

layout with background images) take *AGES* to build and thén tweak

I am proud to say that i *dare* use tables for layout every now and then. CSS

is the preferred way, but if i run into nasty stuff that makes CSS in multiple

browsers a pain (floating footers anyone????) i switch to tables.

Then a question to all the stubborn evangelists that spend hours and hours

fiddling to fix some weird css bug:

*HOW* on earth are you going to explain to your boss why a fairly simple

feature cost you 12 hours instead of 2?

Comment by SchizoDuckie — November 12, 2008

in my opinion complex forms are almost always a challange when you try to

make them without table layout. i’ve searched a lot for good looking css-only

forms, but was not satisfied with the solutions i found:

e.g.: i did not find any css-form that can vertical-align labels and form-fields

and keep the possibility to have long labels with line-breaks. almost all css-only

forms i’ve seen for example bottom-align labels and fields, which looks really

ugly — imo.

css-form design is always very time-consuming and error-prone.

but that’s for me the only case, where i still like to use tables for layouting

every now and than.

Comment by aurora — November 12, 2008

Did anybody notice that giveupandusetables.com has 1 td inside 1 tr inside 1

table. I mean I understand they are trying to promote tables but was it

necessary to add 3 extra tags. Not exactly somebody I would want to listen to.

Of course that’s probably part of the joke.

Comment by JonBad — November 12, 2008

@Shizoducky: and that is why we have CSS frameworks. If you don’t grok CSS

and you don’t want to understand it, use something that works that other

people built, maintain and test for you. It is a no brainer. When my boss asks

me to repair the sprinkler system because experts cost money I say no. If you

don’t want to work on CSS, don’t.

Comment by Chris Heilmann — November 12, 2008

Who cares, If you want to use tables, do it. If you don’t than don’t? Does it

matter? NO as they both will render out the same if you use both techniques

good..

Comment by V1 — November 12, 2008

Schizo: You don’t have to be a “CSS Guru”, but “the boss wants you ‘to get shit

done’” is no excuse to not continue to improve your skills. OK, let’s say you’ve

got to do a layout that you know doesn’t require tables, but that you don’t

currently have the skill to do without it. Well, you’re never going to learn until

you sit down and make yourself learn, just like you sat down and made

yourself learn tables. So, fine, use the tables if your boss is so inflexible that he

doesn’t care one whit for whether his employees spend extra time learning to

get better at their jobs.

But it’s pretty important that you take the time, at some point, to learn how to

do your job better. If you’re a web professional (and I presume you are, if

you’re commenting here), improving your skillset is an ongoing, constant

process. Our industry moves too fast to take a lackadaisical approach to

keeping up to date. Techniques that were unknown two years ago are

commonplace today and will be bad practices two years from now. A career in

this field is something that must be nurtured, and that means aggressively

continuing to stay on top of your abilities.

Plus, and this is important, you have a duty as a professional to provide an

accessible website, and tables hinder accessibility. This isn’t just a matter of

karma, this should be considered a business requirement. Target.com lost a

huge lawsuit over having an inaccessible lawsuit. If you’re getting paid to make

a website, you really are obliged to ensure that you’re not exposing your

employers or clients to legal risk.

For myself, tables aren’t a matter of philosophy or dogma, they’re simply

inconvenient. Once you start nesting them, once you have to make changes to

a layout, once you want to start reusing HTML in different places, tables start to

slow development time down. There’s real, tangible benefits to semantic, CSS

based layouts that far outweigh the very short term gains tables give you.

Refusing to get better at your job isn’t something to take a stubborn pride in.

It’s career suicide.

Comment by skippyK — November 12, 2008

@skippyK and Chris Heilman

I’m mostly a backend / web GUI developer. I know the ins and outs of CSS,

can use a reset style, floats, understand absolute vs relative positioning and all

that. i *know* CSS, but I *choose* to not ‘improve’ (if you can call learning all

the different hacks by heart) my CSS skill level to cope with the crappy

browsers.

I fully agree with this nice quote from giveupandusetables.com:

We want to make it work with CSS. But sometimes it’s just not worth the effort.

The hacks and conditional comments ruin our clean markup. And we spend

hours trying to make a simple layout work.

The reason why i agree with this has nothing todo with me doing my job better

(understand that I will use nice semantic html 99% of the time), nor my boss

not allowing me to evolve myself, It’s a personal choice. CSS, as it is now with

all it’s crappy hacks *SUCKS* if you just want to output and style your html

and make it work.

I cannot wait until CSS3 is adopted by all major browsers and we can just

forget about the headache-causing hackjobs.

Comment by SchizoDuckie — November 12, 2008

@SchizoDuckie - Nobody really likes the hackery, but table based layouts are

not the way to go - forget the layout and how it renders, it’s the semantic

meaning of the markup and how this is read and understood (or not) by

assistive technologies and search engines.

You’ll be pleased to know that IE8 joins the other browsers and supports CSS

tables which are going to solve a lot of the hackery so there is a light at the

end of the tunnel…

Comment by danh2000 — November 12, 2008

Schizo:

CSS is hacky, I agree. I’d say for any reasonably complex page, it’s 95%

legitimate code, 5% hacks. That sucks, yes, but in all honesty, it’s about the

same ratio as nearly any other programming language (except Python which is

96%/4% (j/k)). But let’s be honest here, isn’t using tables for anything other

than presenting tabular data also a hack? Spacer gifs are hacks, invisible tables

are hacks, so ditching CSS on the basis of “too many hacks” when the

alternative is also a hack isn’t a very strong argument.

And to be honest, there’s only three hacks you really need to know for nearly

all css: “zoom: 1;”, “*propertyname” and “_propertyname”. The rest you can

accomplish through legitimate CSS and some vendor-specific CSS.

Comment by skippyK — November 12, 2008

Please understand that i never *totally* ditch css. Even if i use a table for

some layout 100% of the rest of the layout is styled with css to keep the

semantics as clean as possible. I’m just beyond the “when all you have is a

hammer, everything looks like a nail” point.

Comment by SchizoDuckie — November 12, 2008

I can’t believe anyone still argues about this - if you still use tables for layout

you’re not very good with CSS or design or both.

Lets argue about something much less solvable: what’s the semantics of

having using a top level heading tag for your main content? Seems

wrong to me ;-)

Comment by edeverett — November 12, 2008

“We want to make it work with CSS. But sometimes it’s just not worth the

effort.”

That is complete and utter nonsense. It’s always worth the effort, if only for

accessibility and seo reasons. Beyond that, it is good to keep in mind that most

browsers today follow the standards ánd webdesign is something completely

different to print design. You have to let go, a tiny bit. Loosen up. Not

everything will be exact to the pixel in every browser, but if your design is

flexible and good enough, it won’t matter.

A conditional stylesheet for IE, that’s one thing. But CSS hacks? That’s bad

practice (if you’re not working on a site that needs to run on ie5.5) and

completely unnecessary.

Now JavaScript, that’s a whole ‘nother ballpark.

Comment by DiSiLLUSiON — November 12, 2008

I would find their argument a lot more compelling if they hadn’t also given up

and used flash for the in-page countdown timer, rather than a javascript

solution.

Comment by henrah — November 12, 2008

Not to mention there are a number of CSS guru’s on the interwebs, floating

around forums just waiting for an opportunity to increase their e-penor by

solving your CSS problem

Comment by TNO — November 12, 2008

tables are for slobs.

Comment by RobRobRob — November 12, 2008

I think part of the reason some people get a hard on for tables is that it masks

their flawed logic in some cases. You want a fluid 2 column layout, but you

define everything in pixels instead of a percentage/em, and you also want it all

on the screen at the same time regardless of the size of the end user’s browser

size… And then you piss yourself when it wraps to the next line and blame

Microsoft, God and the Republican party for your broken design. Then you run

off and do it in tables and say: “Look, its moar better than stupic CSS”. When

all that really happened is that the table ignored some of the crap you gave it

and followed its own logic.

Comment by TNO — November 12, 2008

As for floats……

floats kill kittens

Comment by TNO — November 12, 2008

The very fact that people argue about it shows that CSS has not completely

gotten rid of the need for tables.

.

The very fact that people are fighting over how to fix CSS so they can make it

easier for people to implement the designs in there head tells you why people

use tables.

.

I prefer CSS. But when the CSS gets so complicated that I don’t see a way to

go forward, I use tables.

.

I expect that in five years, CSS will have the bits and pieces to accommodate

how I want to do things, and I won’t have to use tables any more.

.

The problem is we’re moving from a more natural system of layout to a less

natural one.

.

Yes, I used to work for a magazine, back in the time when the layout people

were still pulling columns off the Linotype and cutting them with xacto knives

and pasting them on the boards.

.

It’s silly to tell people to back away from a system that makes physical sense

to one that is more abstract. It will work for some people but not for everyone.

.

Give me a CSS table that maps to the design in my head and I’ll use it 100% of

the time. Promise.

.

You no-table people. You sound like the people telling me why Esperanto is

better than English.

Comment by Nosredna — November 12, 2008

Personally, I keep a foot in both camps (though I do favor tables). There are

times when tables just work and then there are other times that DIVs and

floats are required. To completely reject one method or the other is foolish

given the current state of browser HTML standards support.

Comment by RSarvas — November 12, 2008

Tables for layout and excessive floats are like the Kentucky Windages of the

web. You basically say “forget what I just told you to do, just do what I mean.”

.

This isn’t just about initial design and “getting shit done”, it’s also maintenance.

After you make your 4-5 deep nested tables to get your so called grid just right,

how long is it going to take you or anyone else to go back behind you to

update something or fix something? What if you need to change your site

layout across an entire domain?

.

“The very fact that people argue about it shows that CSS has not

completely gotten rid of the need for tables.”

.

I’ll partially agree with you there, but the way I would word it is:

“The very fact that people argue about it shows that CSS has not gotten rid of

the DESIRE for tables”.

.

I think the majority of us can agree on both sides of the fence that CSS is not

intuitive and is not necessarily moving in a direction to make things easier (Like

the CSS3 ASCII layout in the other thread in this page IMO). But currently the

standardized options are to use clunky, butt ugly, hard to maintain tables which

are an intuitive common denominator for new comers, OR a not quite there,

hard to understand abstract layout language that is progressively trying to

encompass more than just “styling” (CSS).

.

Douglas Crockford brought up at one time how broken CSS is and how we need

a replacement for it and I have to agree with him. But until we get that

intuitive styling language, CSS is still the better choice regardless of the slightly

steeper learning curve.

.

Of course you could use a CSS framework. Too bad we don’t see more of those

advertised on ajaxian.

Comment by TNO — November 12, 2008

TNO,

.

I mostly agree with you. I don’t nest tables (except for putting something that

SHOULD be a table inside a scaffolding table).

.

You can certainly make an unmaintainable mess with tables. But that’s just an

argument not to make a mess. You can make perhaps even a bigger mess in

CSS.

.

Frameworks are great. I’ve used them. But they often don’t cover (well) all my

cases.

.

I look forward to CSS getting more concrete and usable. Until then, I’m going

to avoid zealotry and embrace pragmatism and do the best job with what is

available.

.

Newcomers are going to screw up whatever they use. I think we can agree on

that. Anyone who’s had to maintain old stuff will use whatever tools he has in

more reasonable ways.

Comment by Nosredna — November 12, 2008

I think the excuses “oh it’s not semantic” and “oh it’s not accessible” are

bandied about way too easily, without thinking it through. I seriously doubt that

it’s not possible to combine table-based layout with screen reader accessibility.

Also, “it’s not semantic” is a meaningless argument, because tons of nested divs

aren’t semantic either, even if you give them sensible class names.

Comment by Joeri — November 12, 2008

We’re in a transitional period where CSS can’t do everything we need/want it to

do, either because of technical limitations, lack of knowledgable developers, or

both.

-

Therefore, it seems to me foolish to not have a transitional mindset as well.

-

Start from the premise that you’re going to do it with CSS, because that’s

where we all pretty much agree we need/want to go. But, if and when you get

to the point where it’s not happening, either because the technologies doesn’t

seem to be up to it, or *you* don’t seem to be up to it, drop back to tables as

necessary.

-

At the end of the day, most of us have a ton of work to get done. The better

developers among us demand the time to do it right, and are more times than

not granted it. Still, there comes a point where you simply can’t spend any

more time on something and you have to use the fallback position. Your client

doesn’t want to hear “but gee, we’re not applying the correct semantic meaning

to the content on the page” or “CSS is the future and we have to be onboard

with it fully RIGHT NOW!”. They just want the project done.

-

So, START with CSS, use CSS whenever possible, but don’t be so anal about it

that you’ll never touch a table under any circumstances. And conversely, don’t

just punt CSS because you don’t understand it or because it might be more

effort. CSS is the right answer… until it’s not! :)

-

Speaking for myself, I’ve done some rather complex work with CSS with

success. I’ve also ran into some issues at times that I couldn’t find a solution to

after a day or so of research and so I went with some tables instead. I’m not

about to flog myself over it, and the project stakeholders believe I made the

right decision too.

-

Zealots on either side of an argument are usually not worth listening to. Have

you ever watched that show Wife Swap? Ever notice how they always find the

two most polar opposite families, both with extreme views? You sit there the

whole time saying “neither of these bozos are right!”, and at the same time

“both of these bozos are right!”. Seems to me the same can be said for the

CSS vs. tables debate, at least during this period of transition.

Comment by fzammetti — November 12, 2008

To paraphrase John Resig on the design of js libraries, we start off by avoiding

browser sniffing, we try and use feature testing and best practices, but in the

end we come right back to browser sniffing because the technology isn’t quite

where we need it.

.

When you’re dealing with very large sites with picky design-savvy clients, CSS

evangelism gets counter-productive: doing things like client-editable multi-line

top navs with vertically centered text with CSS isn’t exactly cleaner than just

plopping in a small table. And don’t even get me started on complex multi-

lingual forms :)

Comment by LeoHorie — November 12, 2008

There’s a heck of a lot of browser sniffing in jQuery. I keep wondering if that’s

because the alternative would be too big or too slow. It’s hard to believe that

it’s not feasible. Seems more like a trade-off for performance than a matter of

something that can’t be done.

.

Over the long run, browsers will be closer to standards (I hope) and there will

be less sniffing in the libraries.

Comment by Nosredna — November 12, 2008

people switched to css FROM table with reasons. It was hard to create some

layout with tables. it’s hard to maintain too because that image is nested in

table>tr>td>table>tr>td>table>tr>td>table>tr>td….and you need to specify

colspan and rowspan if you want the top and bottom of this image align with

the top of that and the bottom of another. if you add another row, oops, you

need change the numbers, manually.

for people who aren’t really into web design but need to get the webpage up,

there is nothing wrong with using this. but if anyone thinks this should be the

direction all web designers should rethink and readopt, you can’t be serious.

Comment by coolnalu — November 12, 2008

>> There’s a heck of a lot of browser sniffing in jQuery. I keep wondering if

that’s because the alternative would be too big or too slow.

.

In the talk John gave about library design, he said that a lot of that is because

of specific quirks in how browsers draw things. It seems there are things you

can’t reliably get programatically from javascript (John can probably list these

issues better than I can).

.

As far as performance vs feasibility goes, I think they are very similar: in js you

want things running as fast as possible, and that can’t be accomplished nearly

as effectively without sniffing. In CSS, sometimes you want things to have

certain elasticity properties without a ton of code and a ton of effort, and

sometimes tables are simply more efficient at accomplishing that.

Comment by LeoHorie — November 12, 2008

Help me remove the tables here:

http://www.thechangecreation.com/accomplices/

This should be a list of accomplices. However, if a li was taller than the next,

the row after would display only one li.

If you know how to fix this via css without specifying the height let me know.

I’ve run out of ideas and used a table instead. :(

Comment by troynt — November 12, 2008

@troynt,

.

You’re my new hero. Ballsy to put yourself out like that. Wouldn’t it be cool if

there were a place we could post our tables and ask for help to get to a pure

css layout? There are already places we can post code and have people help

simplify and optimize it.

Comment by Nosredna — November 12, 2008

As someone who is required to make email newsletters, I could not always use

a tableless design. It’s almost impossible to get images to wrap properly in all

(still used) versions of Outlook. I still use a mix where applicable.

Comment by azmoviez — November 12, 2008

@troynt: easiest page in the book:

1) Each block is a block element (li or div or whatever) and has float: left or

float: right; and a specified width.

2) All blocks are wrapped in a container element (div) with a specified width.

3) Each first, alternating float has clear: both; (each second doesn’t).

Done.

That’s why people advocating tables sound so crazy to most webdesigners:

Creating most layouts in div’s is easy, fast and clean if the design is good &

flexible enough. Hacks are almost never needed (and haven’t been for some

time now), and all you need are a few div’s and p’s and such. Most layouts can

be built with only a few simple elements (don’t forget you can style the html

and body elements as well). And all that in a fraction of the time it costs to

build a table-based layout.

Because frankly, if typing table, thead, tbody, tr and td everytime you need a

simple block is faster then simply creating only one element and positioning it,

then you’re doing something very, very wrong indeed.

Comment by DiSiLLUSiON — November 12, 2008

@DiSiLLUSiON,

.

The problem is mapping. From brains to CSS. Better tools is the only solution I

see.

Comment by Nosredna — November 12, 2008

I can see where you’re coming from; to be a webdesigner you need to think

both intuitively / creatively — creating the design, and structured / logically —

creating the html/css (both simply put — though not exactly correct).

.

There’s no way around it, for now, though better tools would help.

.

But that still doesn’t justify the use of tables, except in those cases where the

defense is not that it’s better or faster, but that “when I slice it up in photoshop

it creates them”. But then again, “webdesigners” who can’t create html/css only

design visually; they might be wonderful artists but I wouldn’t classify them as

webdesigners.

.

However, do we really want to have that freedom? I’d think not; websites are

about supplying/recieving information in an interactive way. The more creative

it gets, the less usable it gets. There are infinitely more creative & original

designs out there that are a complete and utter mess if you take usability and

readability into account, compared to creative & original designs that are

actually good, informative and a joy to use.

Comment by DiSiLLUSiON — November 12, 2008

(I forgot:)

A document is a document is a document.

.

What I mean is this: Websites can be classified in a few categories: Document,

Application and Game/Promotional. The category dictates the kind of stuff you

need. CSS is limited in some ways, yes. But then again, for the stuff CSS

doesn’t have, there are usable alternatives; for applications there are things like

XUL and Javascript layout managers, for game/promotional there are

technologies like Flash & Silverlight and for Websites HTML & CSS is enough.

.

The only downsides of using CSS as it is now (how I see it):

.

1) In CSS it’s a hassle to center something vertically. But beyond a very, very

few cases (an actual online business-card-like landing page or a portfolio with

images of the same size) you would never want to! Websites are interactive

documents (in the largest possible way), not business cards.

.

2) In CSS it’s a hassle to have UI-like flexible layouts. But beyond online

applications (where it is actually preferred), you would never want to (and for

applications there are formats like XUL). Why not? Because scrolling is as

natural as turning a page. You wouldn’t want a book that’s printed on one huge

paper with a transparent rectangle on top that you’d have to move by hand to

read it.

.

3) In CSS/HTML/Javascript it’s a hassle to animate something. Up to a point, it

can improve usability. Fortunately, there are Javascript libraries for that and

SVG/Canvas for the other stuff. Beyond that, Flash is the way to go. You can

forget accessibility, you can forget good search indexing but it might just be the

thing to promote the client’s new product/service/whatever.

.

CSS isn’t perfect, but it’s a long cry away from deficient.

Comment by DiSiLLUSiON — November 12, 2008

Look, we can argue all day/week/month/year/century/etc. long. There will be

those that advocate tables and those that advocate CSS.

The only issue I have with the giveup site is that they don’t even know enough

good html to not use the deprecated font tag… I mean dang man!

Comment by HendryB — November 12, 2008

The reality is that we’re just not there yet with CSS. We’re close.

.

Want to see gratuitous? Go to Google Finance and use Web Developer Toolbar’s

Outline->Outline Tables->Table Cells to show all the crazy ways Google is using

tables for page layout.

.

iGoogle? Yep. For real table things, but also for layout, like that new sidebar to

the left.

.

Twitter? Yep. For rough layout.

.

Google News? Yep. For layout.

.

Amazon? Lots of tables for layout.

.

Sure, you can say all these pros are lazy are dumb if you want, or we can try

to improve the situation as we all learn to use CSS better. It’s going to be

gradual.

Comment by Nosredna — November 12, 2008

CSS really isn’t that hard to learn. And once you do learn it - I believe it

becomes much easier to maintain and alter large sites and apps than with a

nested table layout.

Comment by WillPeavy — November 12, 2008

One more thing I wrote a while back about tables that I think ties nicely with

this discussion: using tables for non-tabular data.

Comment by LeoHorie — November 12, 2008

@DiSiLLUSiON: Not so fast on that solution.

“if a li was taller than the next, the row after would display only one li.”

So your solution would require one to specify a height. I could use javascript to

vjustify the elements, however I want it to work without javascript as well.

Comment by Tr0y — November 12, 2008

@DiSiLLUSiON: wait, maybe your suggesting something that looks like…

Which looks a lot like…

That solution is no better than a table.

It should be a list

foo

bar

foo2

etc.

Comment by Tr0y — November 12, 2008

grr.. ate my markup.

Which looks like a table.

Should be a list

If the LIs heights are not consistent this will break, you can fix this with

javascript, but I want it to work without javascript as well.

Comment by Tr0y — November 12, 2008

@troynt You should us a list then apply a style of inline-block to each li. Nice

looking site though.

Comment by edeverett — November 13, 2008

@troynt Here’s the two minute version of that layout.

http://edeverett.co.uk/experiments/noTables.html. Ok, so there’s a small hack

for IE, but that’s a small price to pay for the benefits of not using tables for

layout (for me the benefits are most in having more maintainble flexible HTML).

Comment by edeverett — November 13, 2008

instead of using li use a span with inline block and it will work back to IE6

without a hack

Comment by TNO — November 13, 2008

@TNO - you can’t be having troynt’s H3s inside a span, but yes that would be

simpler for my example.

Comment by edeverett — November 13, 2008

If you’re referring to block elements not being allowed within inline elements,

its trivial to replace it using first-line:

li:first-line{

font-weight:bold;

color:blue;

line-height:2em;

text-decoration:underline;

}

Comment by TNO — November 13, 2008

use Flex. It looks the same in every browser, provides as complicated a layout

as you want, and gives you selectable text! What more could you ask for?

Comment by endOfLine — November 14, 2008

@endOfLine:

Something that doesn’t cost a bajillion dollars to develop for,

doesn’t require a leaky abstraction in the page,

is easy to index by a search engine,

can be quickly updated without firing up an IDE,

Is standardized and future compatible

Is readable

Is open source

Comment by TNO — November 14, 2008

Oh yes, and something that isn’t controlled by a single vendor and doesn’t

require a download for the user.

Comment by TNO — November 14, 2008

Thanks for this one! :-D

Comment by PeterMichaux — November 15, 2008

Fine post, ajaxian, but I think you just started another flame war.

Comment by luke01 — November 15, 2008

DiSiLLUSiON has summed it up nicely, why TABLES simply cannot die yet. Any

alternative mentioned (XUL, Flash, whatnot) may be better option than a non-

working CSS, but it is much worse option than having a working TABLES.

The thing is - when I begin to implement a design that smells with complexity,

I never know in advance whether I will hit the CSS problems DiSiLLUSiON has

mentioned - the requirements simply change too fast - and the world is just too

interesting place to spend all time with needless refactoring. Therefore I play it

safe and use tables from the get go, which I’m very proficient at both from

HTML as well as DOM side.

(Someone here said that “floats kill kittens”, so let me just add that TD

rowspan kills puppies - both are things to avoid.)

Attempting to produce a clean work with messy and broken tools (current web

starndards and their implementation by browsers) is simply foolish.

Once I can use CSS for everything where I use TABLE, but WITHOUT fugly

hacks like conditinal CSS includes and deep nesting, I will be all CSS. Until

then, I use both, as I’m not their bitch to exploit, they are mine:)

Comment by ypctx — November 16, 2008

@TheWorld

I can do mostly any layout my heart desires without having to resort to tables,

but there is one place I get stuck still - forms…

Does anyone here have a beautiful recipe for how to create CRUD forms using

CSS and getting the alignment right…?

I have tried a couple of times but I always end up with tables…

Comment by ThomasHansen — November 17, 2008

@ThomasHansen, I have examples of a few tableless forms here. I don’t know

if I’d go so far as to call them beautiful, but they work in modern browsers and

offer decent layout options.

Comment by garann — November 17, 2008

When building enterprise level sites, the amount of markup in a page matters.

The extra amount of code in a complex table-based layout may seem trivial,

but multiply it by a million hits a month and it does have impact.

An example I recently ran into -> loading paginated comments via ajax with a

CakePHP MVC backend. The view (HTML template) for each comment was built

using tables. The site could easily produce 300-500 comments per page. Mix

ajax loads with PHP application of a chunky DOM structure and we were getting

long wait times before a given page of comments would appear.

Solution: reduce HTML per comment via the use of few block-level tags styled

via CSS. Problem solved.

I’m NOT saying tables don’t have their place, but I would argue that when we

do need to use them its typically because we have to support old browsers that

don’t handle CSS well. In other words, its crappy old browsers that will

someday die that put us in the corner - not CSS.

Comment by miscon2 — November 18, 2008

Wednesday, November 12th, 2008

CSS and Tables; The warcontinues

Category: CSS , Fun

Time for a bit of fun. The eternal battle of tables vs. CSS layouts continues. We

geeks have had classics such as vi vs. emacs, and Star Wars vs. Star Trek.

First up we have giveupandusetables.com:

And then we have shouldiusetablesforlayout.com:

You have to take a look at the source for that one :)

PLAIN TEXT

Who will win? Maybe both, with display: table in the future.

HTML:

1.

2. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"

3. "http://www.w3.org/TR/html4/strict.dtd">

4. <html>

5. <head>

6. <meta http-equiv="Content-Type" content="text/html; charset=utf-8"

7. <title>Should I use tables for layout?</title>

8. <style type="text/css">

9. html,body{

10. background:#999;color:#ccc;

11. }

12. h1{

13. font-family:"Georgia",Helvetica,Arial,Sans-Serif;

14. font-size:10em;

15. padding:.1em 0;

16. text-align:center;

17. color:#333;

18. margin:.5em auto;

19. }

20. </style>

21. </head>

22. <body>

23. <h1>No.</h1>

24. <!-- Honestly, no. -->

25.

26. <!--

27. <table border="0" width="100%">

28. <tr>

29. <td align="center">No.</td>

30. </tr>

31.

32. -->

33. <!-- Fact: Chuck Norris hates layout tables! -->

34. </body>

35. </html>

36.

Leave a comment

You must be logged in to post a comment.

Posted by Dion Almaer at 12:01 am 4.5 rating from 17 votes

Comments feed TrackBack URI

ACTIVITY STREAM

Keep up to date on Ajax content via

Twitter or FriendFeed

Lively no more

Rewriting Twitter for web best

practices

Brendan Eich interviewed for CNET’s

CIO Sessions

A Security Model for Ubiquity

mozilla mission financials - 2007 and

beyond

iPhone sex: Google application

baffled by British accents (AFP) by AFP:

Yahoo! Tech

Why is the web the default

development platform?

Mac OS X accessibility: A success

story

SPONSORS

SearchSOA.com: expert advice,

technical tips and informative tutorials

and free research library.

Membership is free. Join today.

ABOUT THE AJAX EXPERIENCE

The Ajax Experience -

Over 500 web developers

and designers attended

TAE in 2007 - 98% said

they'd recommend it to a

friend.

Stay informed about 2008 here.

Learn More

AUDIBLE AJAX

Episode 25

In Episode 25, we

chat about IE 8,

standards, Acid3,

server side

JavaScript, and

more.

Podcast RSS

more podcasts

GET E-MAIL UPDATES

Receive e-mails on the topics that

interest you most. You'll get the latest

news, technical resources,

announcements and more. Select your

topics and submit your e-mail below.

Browser Plug-ins

Client-side Frameworks

Interaction Design/

Graphic Design/User Experience

JavaScript

Programming Techniques

Security

Server-side Frameworks

Get e-mail updates!

Not a member? We'll activate your

FREE membership with your

subscription.

AJAXIAN JOBS

More Jobs | Post a Job

PHP Engineer (part-time, 20-30 hrs/wk)San Francisco, CA (Bay Area,

telecommunte)

Front-end Java DeveloperChicago, IL (Minneapolis, Detroit)

MC+A

Web Client DeveloperLanham, MD

Vocus Inc (NASDAQ: VOCS)

Principal AJAX/Javascript SWELexington, MA

CTO/technical co-founderNew York, NY

Stealth Social Start-up

Powered by JobThread

CONTACT US

Who are the ajaxians? Find out.

Please contact us at

[email protected]. We would love

to hear about any news that we could

put up here.

We have individual blogs too:

Dion Almaer (Twitter, FriendFeed)

Ben Galbraith

Rey Bango

Michael Mahemoff

Chris Cornutt

Rob Sanheim

Dietrich Kappe

Chris Heilmann

FEEDS

Enter your Email

Subscribe me!

Powered by FeedBlitz

ADS BY GOOGLE

Intelligent CSS Editor

CSS & XML Editing Tool. Fully Functional

30 Day Trial

www.Altova.com/CSSEditor

Free Web 2.0 Templates

All Templates Are Free, Tableless, W3C-

Compliant & Licenced Under CCA.

www.TemplateWorld.com

CAD Plant Design

Bentley AutoPLANT. Perfect for factory

planning and design. Try!

www.Bentley.com/AutoPLANT

WHY NOT EXT?

Understand the drawbacks of Javascript

in seconds with example.

ZKoss.org

Free Web Templates

Build Your Website In Minutes! Download

Tons of Free Web Templates

www.FreeTemplatesOnline.c

om

Your E-mail Address

Page 54: Die 7 1/2 Todsünden des Barrierefreien Webs

6. Todsünde

Page 55: Die 7 1/2 Todsünden des Barrierefreien Webs

GulaVöllerei, Maßlosigkeit, Selbstsucht

Page 56: Die 7 1/2 Todsünden des Barrierefreien Webs
Page 57: Die 7 1/2 Todsünden des Barrierefreien Webs
Page 58: Die 7 1/2 Todsünden des Barrierefreien Webs
Page 59: Die 7 1/2 Todsünden des Barrierefreien Webs

7. Todsünde

Page 60: Die 7 1/2 Todsünden des Barrierefreien Webs

LuxuriaWollust

Page 61: Die 7 1/2 Todsünden des Barrierefreien Webs
Page 62: Die 7 1/2 Todsünden des Barrierefreien Webs
Page 63: Die 7 1/2 Todsünden des Barrierefreien Webs

7!. Todsünde

Page 64: Die 7 1/2 Todsünden des Barrierefreien Webs

Nonsensia

Page 65: Die 7 1/2 Todsünden des Barrierefreien Webs

”However fucked up and crazy something is, someone,

somewhere in a standards body is writing a parser,

schema or proposal for it.“— The Morris Law of Standards, Tim Morris

Page 66: Die 7 1/2 Todsünden des Barrierefreien Webs

”Egal wie beschissen und verrückt etwas ist, irgendwer, irgendwo in

einer Standards-Institution schreibt einen Parser, ein Schema

oder einen Vorschlag dafür.“— The Morris Law of Standards, Tim Morris

Page 67: Die 7 1/2 Todsünden des Barrierefreien Webs
Page 68: Die 7 1/2 Todsünden des Barrierefreien Webs

Vielen Dank!http://yatil.de

http://slideshare.net/yatil/