Christie Mason wrote:
> [...] Plus I've seen a lot more sites break that are dependant on CSS
> for positioning when new browser versions are released. How do you
> justify going back to a client to redesign a site that is breaking
> because it used CSS targeted for X versions of browser when a new
> browser version is released?
I've seen those sites too, and I've been involved in some. It's what's
known as "fragile constructions", which rely on what browsers do more
than on what they're supposed to do. That's a trap that it is easy to
fall into, and one that it sometimes is hard to avoid.
I don't know of any browser-version that has forced me to redesign a
site, although IE7 did need a few additional CSS fixes on a number of
sites when it arrived. Took a while to get that bugger somewhat in line
across the board, but it had little to no impact on what was served to
the other browsers. After all: IE7 was "dead on arrival" - stable, and
we had nearly a year to prepare for it.
Ideally, a design should be so well thought-out that one only has to
remove fixes for old, obsolete, browser-versions when these fixes are no
longer needed. For most sites that should never be necessary, as such
fixes should never backfire and end up messing things up in new
browser-versions.
I guess getting the targeting/fixes for old browsers right and safe
enough to be able to forget about them, is one of the hardest parts for
many designers.
That many also include "fixes" for new browser-versions, doesn't make
fragile designs more "future proof".
Advice: don't add "fixes" for new browsers.
Another cause for problems seems to be "overstyling", as
properties/values that don't seem to do any harm are left in the
stylesheets - often after a round of "trial and error" styling.
New browser-versions may start reacting on these "superfluous" styles,
and unless one knows exactly what will happen when they do the outcome
may not be good.
Advice: know what those styles are there for, or delete them.
------
The "trick" - if we can call it that, is to design for progress - close
to standards - and let the browsers catch up with us - instead of us
playing catch-up with the browsers. This is a mental model more than a
method or template, as it means one only targets old/dead browsers for
debugging, while checking standard compliance and logic in new, live,
versions and hold back on the "latest and greatest" until they're
somewhat stable. One can not trust any browser to get it right, until
they all support the same standard-parts and react the same way when
served the same code.
New browser-versions tend to inch slowly closer and closer to the same
standards, which, ideally, should mean they all end up doing more or
less what we expect them to do. Browser developers seem to finally have
figured out that it is money in standards and standardized development,
and as a result of improved cooperation even the standards are starting
to make sense. Would be nice if web designers/developers figured that
out too, so the process could be sped up a bit.
------
Arguing back and forth about "CSS based" vs. "table based" is futile, as
each designer/developer/front-end coder can make the most out of what
he/she knows best. Those layout-tables are pretty much "frozen in time"
by now though, while CSS still has potentials to become a useful
layout-tool. A few more rounds between standards- and
browser-developers, and CSS may satisfy most web designers' needs and
wishes.
I still think it's fun to include layout-tables when someone explicitly
asks for it, but I do find those layout-tables a bit limiting for all
but the simplest designs. I don't like limitations so I nearly always
find an excuse - or a whole bunch of excuses - to break out of those
tables. CSS provides more fun without them :-)
regards
Georg
--
http://www.gunlaug.no
______________________________________________________________________
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
