As a result of travel arrangements, I wasn’t able to catch Eric Meyer’s opening keynote on the first morning of @media 2006 as I’d hoped. A podcast of the keynote is now available, so I took the opportunity to catch up on what I’d missed. You should too.
Eric’s presentation looks back over the last 10 years of the evolution of CSS – which is far more interesting than it may initially sound, I promise. I guess the recurring theme is that of community involvement and shared knowledge. The history of CSS and modern web development is peppered with instances of individuals making discoveries, having innovative ideas and engineering clever work-arounds to found problems and implementing and sharing that knowledge for the benefit of the industry as a whole.
I guess the classic example of this is the story behind the invention of the Box Model Hack. Jeffrey Zeldman had problems with a particular bug, the end result of which was that it wasn’t really possible to use CSS for layout and have it work right in the major browsers. He expressed this to Tantek Çelik, who as far as I’m aware hadn’t come across the particular problem himself, but was able to devise a work-around – the Box Model Hack. The simple act of highlighting the problem brought it to the attention of someone who knew how to solve it, and the end result was that pure CSS layout became a reality for designers and developers everywhere.
This is a repeatable pattern. Look at the progress we’ve been able to make as a community by discussing problems like typography, complex layouts, PNG transparency and even (warning: self promotion) Flash.
So, my question is this. What are the biggest unsolved problems facing web design in 2006? What causes you the most pain or restricts your creative freedom in your daily work? Flag the issues, because we need to talk about them. You never know who might be listening. Let’s talk about them now, and see if we can get a few more problems crossed off that list.
Comments
Designers handing you designs littered with rounded corners, when you’d really rather not have to add shed loads of spans to make it look exactly like they want it.
My biggest problem is forms. To be more specific, the styling of forms. It’s pretty much impossible to get anything other than very basic styling that looks the same cross browser. Styling the legend element reliably is a case in point, and don’t get me started on dropdown combos and radio buttons.
I guess another thing is vertical alignment that is currently only possible crossbrowser with a few divs and only under certain circumstances.
Yep, forms were my first thought too. Whether to style them in the first place, and if styling, how to make them consistent across browsers.
I’d go with forms. In fact, a recent ALA article on prettier forms falls apart pretty quickly when dealing with long form labels and doesn’t address error message placement. http://alistapart.com/d/prettyaccessibleforms/example_3/
When it comes to form design, I always feel like I have to use way too many elements to pull off something decent.
Styling Form Controls
http://www.456bereastreet.com/archive/200409/styling_form_controls/
Styling Even More Form Controls
http://www.456bereastreet.com/archive/200410/styling_even_more_form_controls/
Don’t get me wrong: I think using tables for layout is the spawn of the Dark One, but it’s still FAR easier to make relatively fluid layouts with tables than with CSS. Maybe the “display: table-cell” rules will help with this, but it’s not supported in IE.
Joe Schmoe web designers aren’t going to use CSS for layout until it’s close to being as easy as tables.
What mike nicholaides said about not being able to have one div “know” the dimensions of another div. Also, decent typography (without the ingenious but rather Heath Robinson SIFR) or kludgey image replacement. All of this will be solved when everything renders xhtml 2 and css 3 fully. But that’s a while away yet.
And, of course, accessible Ajax.
Accessibly DOM manipulation (alerting screen readers when something on the page has changed).
Maintainable CSS: ways of working with CSS that make it easy to maintain and easy for a team to collaborate on.
Layout, layout, layout. The temptation to “just use a table” is still there no matter how many CSS layouts I do… It’s just not as easy as it should be.
For me, like Bruce, it has to be fonts.
It’s got to be forms. Cross browser form display is a shocker … www.wufoo.com launched today and it looks promising as far as improving accessibility and appearance goes, but still, as a designer, there’s got to be an easier way. The fact that someone has a business plan to make $$’s by providing nice looking forms suggests that this is an area with improvement required.
The slow implementation of CSS3 and the fact that CSS3 isn’t finished yet.
Internet Explorer.
Why is it when a question about CSS is posted somewhere, you always get a few people saying “tables are better for layout because [insert common un-informed reason here]”? Seriously, you use tables for desgin because you’re lazy and uninterested. This is a serious problem for:
a) the future of your career,
b) the future of your clients, and even worse
c) the future of the web.
If you’re still using tables for web-design, then you shouldn’t be doing web-design. I’m not of the camp that screams standards whenever tables are mentioned, but I read the specs and use a technology for what it has been designed. Makes sense – you wouldn’t use a window to leave your house when there’s a door available, so why use tables when there’s CSS available? The truth is, CSS works. I’ve been a web developer/designer for 8 years, and I’ve not used a single table for design for the past 4. There have been a few problems with certain designs, but we simply tweaked them. You can’t expect to exactly recreate a print design on the web, anyway. ;-)
Phil Sherry: Round corners are easy to implement – just fix one axis. All your problems go away then. ;-)
Simon Willison: Ditto for maintainable CSS. Constants would be very useful.
Why is it when a question about CSS is posted somewhere, you always get a few people saying “tables are better for layout because [insert common un-informed reason here]�
I don’t know about better, but if you’re at least using CSS enough to get rid of the spacer gifs, they certainly tend to be easier. Especially if you want equal-height columns or vertical alignment.
It’s something that should be fixed.
What about display:inline-block?
I think it would often solve many things, such as laying out a bunch of elements inline with set widths. This time it’s gecko (firefox) letting us down.
And also multiple background-images (CSS3). Who has had to do this to get multiple backgrounds?
div div div Content /div /div /div
refactored: “I read the specs and use a technology for what it has been designed.”
So you mean you don’t use floats for anything but wrapping text around images and callouts? No CSS hacks either?
I’d like more than five fonts. A way to put any font on the server, and select it via CSS.
Like CSS, Tables behave equally inconsistently across browsers. Tables aren’t easier in that respect. Sometimes I’m forced to use tables for layout, and I find it next to impossible to get the thing to behave in IE6. IE6 just doesn’t respect my width and heights. Instead, it ignores them completely, given certain circumstances. FFX, Opera and Safari do a better job.
However, for something like vertical centering (that is, equal top- and bottom-space), I find that a single table with a single cell is the utmost robust and reliable way, across all browsers.
I’d prefer it if margin-top:auto;margin-bottom:auto; would take care of that. It makes a world of sense.
Consistent margin-collapse implementation across browsers, AND FFX’s dreaded margin-overflow issue, where a begin- or end-margin may stick out the top or bottom of a containing block.
I’d like IE6 to stop applying unchangeable styles to its buttons.
I’d like other form fields fully styleable as well. Same goes for scrollbars.
@MH: “So you mean you don’t use floats for anything but wrapping text around images and callouts? ”
I’ve heard it said a few times recently that floats were only made for this purpose and should not be used for laying out pages in columns etc. Is there a document that specifies this?
I’m pretty sure it’s in Eric Meyer’s O’Reilly CSS book (the “salmon” one). Also, check the CSS 1.0 spec—it talks about text wrapping around elements but nothing of multiple columns.
I’ve never seen floats for layouts explicitly forbidden, but it’s pretty obvious that those above were the use cases in mind, and it’s hardly straightforward to use it for layout.
What would be really great would be the ability to define an object’s position in relation to another object that isn’t necessarily a parent or close sibling—i.e.,
#comments {align-top:#post}
where the structure of the document would otherwise make it very difficult.
Hey Drew. Good topic, but shouldn’t this read “biggest unsolved problems of Web development” or maybe “biggest unsolved technical problems of Web design?”
My biggest “unsolved” problem with Web design at the moment is the focus on technology and technique as opposed to solving problems with design and a focus on fundamentals, content, usability, etc.
But if we’re going for technology stuff I’ll go with typography. I think what’s been done with siFR and the like is awesome, but it’s not ideal by a long shot. Maybe form styling second.
Hey Keith. I specifically went with “Web design” as so often it’s design that drives the need for better technical solutions. Or to put it the other way, the technology constrains the design. Without the requirement for well designed, attractive sites that communicate well, there are very few technical problems.
... I still owe you a beer.
@MH: The CSS1 floats spec http://www.w3.org/TR/REC-CSS1#floating-elements merely talks of floating elements (and a div full of navigation etc is still an element). It also says “This property is most often used with inline images, but also applies to text elements.” but that isn’t normative, even if it were true of most pages when the spec was written.
It seems to me more likely that those who wrote the spec were engineers who didn’t really think deeply about what is required of a well-designed web site (analogous to the html spec, with its plethora of elements for computer geeks – kbd, var, samp etc – but no ability to properly markup poetry, for example).
I agree that the spec as is lacks the ability to lay out a page (although display:table-cell would help if it were supported by IE, and even that is flawed imo).
For me there are three things:
1. Browsers. You still need to take account of, test in and fix problems in the way code is interpreted in browsers. It was interesting to hear Eric’s speech as it seems much better than it was back in the day.
2. AJAX / DOM and accessibility
3. Designers wanting to maintain absolute control over the design. The user has input and they should accept and encourage this.
1. Fonts – Ability to put any font on a page, from the server. sIFR is great, but a pain in the arse to configure. Hopefully sIFR 3 fixes that.
2. Forms – I hate forms.
So, here’s the thing. We’ve all been working with, through and around this stuff for years now. The fact that we have something called “the box model hack” as a staple of our craft is, to me, still somewhat disturbing.
Sure, browsers all support/implement css, js, etc to vary degrees of compliance. Sure, there are quirks in the specifications. Sure, early on, plenty of work was short sighted and inadequate merely a year later. But, I ask you, does that mean we should perpetuate the madness by designing with workarounds as the solution.
sIFR, I believe, is a good step forward. It does not relay on a hack, hole or quirk in the browser. It simply leverages what is there, fails gracefully if something is not available and is an example of a technology solution used in place of realistic font deployment.
The difference is that when the standards change, get fixed or whatever, sIFR can be modified as a separate entity, outside of the HTML it sits on top of. If browsers fix the box model problem, but introduce another in its place, or compound it in some way, it will be a painful revisitation to all the “clever” CSS built on top of it. I’d much rather just upgrade sIFR, or any software, than go back over scads of templates.
Consider the referrer module in Apache. The misspelled it (or chose to spell it differently) way back when as “referer” and now, for legacy reasons can never change it without impacting bajillions of lines of code all over the place. So, should we argue that the box model needs to stay broken such taht our layouts will stay working into the future?
——-
As for fixing things, I’d arrgue for:
1) a single RSS/ATOM/whatever feed standard
2) careful separation of the “new controller” in MVC, namely the “AJAX” layer
3) real support for XML in the browser
4) any support for xpath in the browser
5) IE finally getting GZIP in place so we don’t have to obfuscate everything, and just send a gzipped file
Along the typography lines, I would like to see a broader range of web users with cleartype turned on. This is more of a microsoft (windows) problem however.
More standardizations, so that webpages can interact with each other easier (microformats).
Hello,
Can you tell me if this is correct…
Omaha Nebraska’s Number One Web Designer or should the brackets include the whole thing?
I tend not to worry about the nuts and bolts of design technologies (i.e., forms, typogoraphy…) as the colllaborative nature of this industry has proven highly efficient in tackling new obstacles. What troubles me is how Designers and Developers will be perceived by other, more traditional, business professionals.
It seems to me that the Design community is perpetually having to validate its own existence to other industries, although they are obviously dependent on us. Web standards are definitely a huge leap forward, but how the Design community addresses the need for industry standardization is always on my radar.
We can fly to the moon, travel faster than sound yet can’t make CSS layouts easy to use and hack free :|
I agree with #9 – Accessibly DOM manipulation .. Though working with Screen readers a lot for my job, I notice that screen readers are not ideal tools to browse with, an ideal situation would be a screen reader browser one that supported the standards, mmm anyone know someone at Mozilla or up for writing one perhaps that would be the ideal then Jaws (or Supernova etc) could use that as program to browse the web.
The other problem I have is overuse of Divs (hence my homepage).
The uglyness of forms in not-safari browsers
For me, it is the same interpretations by Firefox and IE,
for my website they see in another way put pictures in levels of height.
I would love to be able to ditch CSS classes and use the much more sophisticated selectors offered by CSS 2.1—it’s really frustrating making a pure HTML document that can be nicely styled for compliant browsers but still require extra classes for IE.
In particular, global support in all browsers for attribute selectors would be fantastic…
This would also make styling forms a little less painful and I agree with much of the above on forms—highly depressing trying to get complicated forms looking the way you want.
well there are many other problems also which arises when you do web designing.At our place most of this work is handled by proffesional not easy for us to handle..
http://allinthehead.com/retro/295/the-biggest-unsolved-problems-of-web-design
13. Juicd10 – The slow implementation of CSS3 and the fact that CSS3 isn’t finished yet.
I think we need 1 more open source browser project. One that ignores security and every thing else and just focuses on how to implement CSS3 and when they get stuff to work, all the other browsers that people actually use can freely re-use the code to implement the css features in their browsers.
Wouldn’t you love to have a few hours just styling up a page with every CSS 3 feature there is. So what if nobody in their right mind would ever actually use the browser (thats no what it’s for anyway). I just want to taste the future.
19. Willem – I’d like more than five fonts. A way to put any font on the server, and select it via CSS.
Don’t we all. But in case we can’t get that I was thinking we could beg a few font design companies to release about 10 really useful fonts to the public and allow them to be ‘embedded’ in the browser. That way we never have to worry about the user not having the font on their system, it’ll be _in_the_browsers! I’m sure we’ve all seen lots of flash using fonts that we don’t have installed.
As for centering I really think there’s potential in using position:absolute and equal top/bottom values for vert alignment and equal left/right for horiz alignment. I also think that position:absolute with top:0 and bottom:0 inside of a div whose height is determined by it’s content could possibly be a solution for equal height columns but it doesnt work right in IE.
“I’d like other form fields fully styleable as well. Same goes for scrollbars.”
Don’t say that out loud in any #css irc channels!
I started writing down some ideas of exactly how much stylability I’d like scrollbars and form elements to have. Eventually I came to the conclusion that every part of every element should be the styleable equivalent of a DIV. Think about it. Imagine how flexible that would be. At the very least you could increase the width of scrollbars on textareas for poor sighted people who have a hard time clicking on things. And with enough background images you can make a scrollbar that perfectly matches your sites style while continuing to be OBVIOUSLY a scrollbar.
#scrollbar-horizontal
#scrollbar-vertical
#track
#drag-handle
#north
#north .arrow
#south
#south .arrow
#east
#east .arrow
#west
#west .arrow
sure some javascript guru can code up a styeable scrollbar system out of some divs, but it’s not as good as having native to the browsers stylable scrollbars.
21. MH – What would be really great would be the ability to define an object’s position in relation to another object that isn’t necessarily a parent or close sibling.
That would be awesome and very useful. I prefer this tho:
#comments {position:absolute; relative-to:dom(#container .content); bottom:0; }
—————————
CSS needs to borrow many more concepts from DTP.
We should be able to absolutely position an image within a body of text and have that text properly flow around the image DTP-style.
When are we going to be able to just convert fancy heading text to .svg paths and use those as background images instead of flash header replacement?
But how are we going to convince the browser devs to make any of these dreams come true?
I don’t know but I do know that in the forseeable future the most money to be made will be on the web. Think about it. Your average joe computer owner spends the vast majority of his/her time in the web browser. They get access to more data/applications than they ever would have if it were up to them to buy software and figure out how to install and use it. The fact that web tech sort of limits us to just a few ways of interacting with a site makes using a web site easier than many desktop apps by default. And any additional functionality mimicing desktop software is so difficult to create that only the best and most useful desktop concepts get ported to the web.
I could go on and on but I know I’m wasting my breath.
Designers wanting to maintain absolute control over the design. The user has input and they should accept and encourage this.
Whether to style them in the first place, and if styling, how to make them consistent across browsers.
More standardizations, so that webpages can interact with each other easier (microformats).
Keep up the good work
It has to be fonts(Ability in putting font on a page) and layout.
Fonts are important – Ability to put any font on a page, from the server. sIFR is great, but a pain in the arse to configure.
Nice article