Decorating html with javascript to avoid divitis?

[Nik Coughlin]

Wondering about people's opinion on this. For some complex layouts, to
achive certain graphical effects, it is *necessary* to wrap semantic markup
within quite a few container elements. Specifically I mean layouts where an
element or group of elements are enclosed within a box that has rounded
corners and/or a drop shadow and still remains flexible in nature, that is,
able to respond to changes in viewport and text size without breaking.

I have in the past submitted pages for critique that are entirely semantic
in nature aside from some rather heavy wrapping of some elements inside divs
to achieve affects otherwise not achievable due to the current limitations
of browsers, mostly non-support for CSS3 multiple backgrounds.

The way I see it, CSS actually serves two purposes. One is specifying the
way the page is laid out, ie two column, three column, whatever, information
boxes floated left or right within some other content, lists of links with
display inline or float to make horizontal navigation etc etc. The second
is in specifying how the content actually looks. So a) positioning of
elements (singly or in groups) and b) "skinning" and styling of elements
(colors, fonts, borders, margin, padding etc. etc. etc.).

So:

1. HTML - content marked up semantically
2. Layout CSS - how the content appears on the page and where
3. Skin/Appearance CSS - how the content looks
4. Javascript - Adds behaviour, should never take the place of #1. Or 2 or
3? That is my question I guess.

Now, adding HTML to enable #2 (layout) is still within the bounds of
semantic markup, if you enclose some of your content within a div (or
whatever) in order to display that content in a specific column for example,
you are implying that the enclosed content is all related in some way or
another.

However, I've in the past been heavily criticised for adding HTML markup
(lots of wrapper divs usually) solely in order to enable #3, CSS that
controls the appearance or skin applied to a set of content.

Is this such a bad thing? If it is so terrible to pollute the HTML with all
of these wrappers, then what about serving a page that consists solely of 1#
from the list above, semantic html, along with #2 from the list above, CSS
used solely for positioning (still semantic as I mentioned above, implying
relationships between elements), and a limited amount of #3, just CSS that
is is possible with current browser support without adding any unsemantic
wrapper elements to the page (ie just colors, simple backgrounds, borders
etc), and then finally using Javascript to modify the DOM adding wrappers
where necessary to apply the final CSS allowing the page to become
graphically rich.

Without Javascript and with thoughtful application of colours etc. etc. the
user gets a usable page but not necessarily graphically rich. With
Javascript they get the graphically rich version via extra wrappers being
added to the DOM.

So what's worse, only serving rich, modern graphical layouts to JS enabled
browsers, or "polluting" your markup with large amounts of wrappers that
serve only to enable appearance?

 

[dorayme]

Wondering about people's opinion on this.

Not sure if I count, but here is something from me anyway...

For some complex layouts, to
achive certain graphical effects, it is *necessary* to wrap semantic markup
within quite a few container elements.
....

The way I see it, CSS actually serves two purposes.

Perhaps. But normally one does think it serves just one purpose, namely:
to style the information. The information is some constant thing that
can be presented in many ways, some genuinely as good as other ways,
some not but they will do the practical job

One is specifying the
way the page is laid out, ie two column, three column, whatever, information
boxes floated left or right within some other content, lists of links with
display inline or float to make horizontal navigation etc etc. The second
is in specifying how the content actually looks. So a) positioning of
elements (singly or in groups) and b) "skinning" and styling of elements
(colors, fonts, borders, margin, padding etc. etc. etc.).

I don't think, when it boils down, you have a clear distinction here.

So:

So perhaps a need here to be cautious of drawing consequences.

1. HTML - content marked up semantically
2. Layout CSS - how the content appears on the page and where
3. Skin/Appearance CSS - how the content looks
4. Javascript - Adds behaviour, should never take the place of #1. Or 2 or
3? That is my question I guess.

Now, adding HTML to enable #2 (layout) is still within the bounds of
semantic markup, if you enclose some of your content within a div (or
whatever) in order to display that content in a specific column for example,
you are implying that the enclosed content is all related in some way or
another.

I think you are right in that there is no getting away from there having
to be some core presentational aspects to semantics. To take a model for
a sec, it matters which order the words go to a sentence's meaning. That
does not mean there are not alternative meaningful sentences that will
do as good a job to convey the information. What is usually advised in
good writing is to choose the simplest way that conveys the ideas.

And so too, the real idea of the advice to mark up semantically, in my
opinion, is to urge the simplest mark up that is consistent with
conveying the information.

What I suspect folk are objecting to when there is an over elaborate
htmling is that the author really is doing everything he can not to
*just* convey the information, but to present it fancy. The competent
author (like yourself) is massaging like crazy and then the css is added
and hey presto, he gets the look he wants. But he has not written up
semantically in the sense that was meant because a lot of the html is
redundant, unnecessary for the conveying of the meaning.

However, I've in the past been heavily criticised for adding HTML markup
(lots of wrapper divs usually) solely in order to enable #3, CSS that
controls the appearance or skin applied to a set of content.

Is this such a bad thing?

Ah... now this is a different matter, how bad it is! If you care about
looks, and you are not to be criticized for this, and if indeed there is
no route to elegance without 'less than simple' mark up plus clever css,
then who can say? You will just get opinions and no real arguments.

But there is a point here that people may miss: because of the
limitations due to browser differences and implementations, the bar is
actually quite high for producing elegant results, both in the html, the
css and the final product. In the end, each person must simply try their
best. To succumb too early to pressure to grow divs for non-semantic
purposes is bad, to be content with uninspiring looks is bad. You just
do your very best to avoid either.

 

[Travis Newbury]

4. Javascript - Adds behaviour, should never take the place of #1. Or 2 or

Never say never. A better comment would probably be, "USUALLY"
JavaScript should never take the place of...."

The second you use the term NEVER, you do your customer a
disservices.

 

[Nik Coughlin]

Never say never. A better comment would probably be, "USUALLY"
JavaScript should never take the place of...."

The second you use the term NEVER, you do your customer a
disservices.

I am going to respond to the other responses tomorrow, but I think I have
time for this now. While I totally agree with the statement "by saying
never you do your customer a disservice", I can't see any reason why you
would ever have content that is *only* accessibly by JavaScript -- there
really is NEVER content that *requires* JavaScript and cannot be served any
other way. You are doing your client's users a disservice by assuming the
opposite. Enhance with JS by all means but don't exclude. Even things that
are time sensitive re. a round trip to the server can be provided without
it. Or have I missed your point? It's the end of the day and I'm very,
very burnt out after 14+ hours of slog

 

[Chaddy2222]

Wondering about people's opinion on this. For some complex layouts, to
achive certain graphical effects, it is *necessary* to wrap semantic
markup within quite a few container elements. Specifically I mean layouts
where an element or group of elements are enclosed within a box that has
rounded corners and/or a drop shadow and still remains flexible in nature,
that is, able to respond to changes in viewport and text size without
breaking.

I have in the past submitted pages for critique that are entirely semantic
in nature aside from some rather heavy wrapping of some elements inside
divs to achieve affects otherwise not achievable due to the current
limitations of browsers, mostly non-support for CSS3 multiple backgrounds.

The way I see it, CSS actually serves two purposes. One is specifying the
way the page is laid out, ie two column, three column, whatever,
information boxes floated left or right within some other content, lists
of links with display inline or float to make horizontal navigation etc
etc. The second is in specifying how the content actually looks. So a)
positioning of elements (singly or in groups) and b) "skinning" and
styling of elements (colors, fonts, borders, margin, padding etc. etc.
etc.).

So:

1. HTML - content marked up semantically
2. Layout CSS - how the content appears on the page and where
3. Skin/Appearance CSS - how the content looks
4. Javascript - Adds behaviour, should never take the place of #1. Or 2
or 3? That is my question I guess.

Now, adding HTML to enable #2 (layout) is still within the bounds of
semantic markup, if you enclose some of your content within a div (or
whatever) in order to display that content in a specific column for
example, you are implying that the enclosed content is all related in some
way or another.

However, I've in the past been heavily criticised for adding HTML markup
(lots of wrapper divs usually) solely in order to enable #3, CSS that
controls the appearance or skin applied to a set of content.

Is this such a bad thing? If it is so terrible to pollute the HTML with
all of these wrappers, then what about serving a page that consists solely
of 1# from the list above, semantic html, along with #2 from the list
above, CSS used solely for positioning (still semantic as I mentioned
above, implying relationships between elements), and a limited amount of
#3, just CSS that is is possible with current browser support without
adding any unsemantic wrapper elements to the page (ie just colors, simple
backgrounds, borders etc), and then finally using Javascript to modify the
DOM adding wrappers where necessary to apply the final CSS allowing the
page to become graphically rich.

Without Javascript and with thoughtful application of colours etc. etc.
the user gets a usable page but not necessarily graphically rich. With
Javascript they get the graphically rich version via extra wrappers being
added to the DOM.

So what's worse, only serving rich, modern graphical layouts to JS enabled
browsers, or "polluting" your markup with large amounts of wrappers that
serve only to enable appearance?

Well I think the JS idea is a good one. It's a nice way of adding extra
visual design to a page.
However it is also good as you can place that JS in an external file just
like the CSS. It (useing Javascript ) to style parts of the page is also a
good modern way of adding functionality provideing that it is not the only
way of getting that same content, in other words add the JS as a feature but
keep the page as accessible as possible without it.
Oh and as for screen readers, they would ignore the extra code although it
might slow down processing.
So you would need to test the pages (obviously).

 

[Travis Newbury]

I am going to respond to the other responses tomorrow, but I think I have
time for this now. While I totally agree with the statement "by saying
never you do your customer a disservice", I can't see any reason why you
would ever have content that is *only* accessibly by JavaScript -- there
really is NEVER content that *requires* JavaScript and cannot be served any
other way.

There is the answer. While I agree there is never any content that
can't be served without javascript, sometimes it just makes sense to
do it that way, your client's may even prefer it that way. Would
google maps be better if served without javascript?

You are doing your client's users a disservice by assuming the
opposite.

How am I doing a disservice by leaving an option open? I am not
saying you HAVE to do it that way, just don't rule it (anything) out
prematurely.

Or have I missed your point?

no, I don't think so. You are just looking at it from a different
direction.

 

[cwdjrxyz]

I am going to respond to the other responses tomorrow, but I think I have
time for this now. While I totally agree with the statement "by saying
never you do your customer a disservice", I can't see any reason why you
would ever have content that is *only* accessibly by JavaScript -- there
really is NEVER content that *requires* JavaScript and cannot be served any
other way. You are doing your client's users a disservice by assuming the
opposite. Enhance with JS by all means but don't exclude. Even things that
are time sensitive re. a round trip to the server can be provided without
it. Or have I missed your point? It's the end of the day and I'm very,
very burnt out after 14+ hours of slog

In many cases server side script such as php can do what many do with
JS, but the client side browser does not see any of the server side
script - just the html produced by it. This has many advantage, the 2
most important ones being 1. the client can not turn the server side
script off. 2. Various browser responses for JS(fortunately not now as
important as in the browser war era), do not matter. I find myself
using more and more php and less and less JS. Of course you can use
many more languages on the server if you are allowed to do so. Even C+
+ may be used if you like to program in that language. Also various
extensions to php, such as the now common gd one, can do things with
graphics such as filled or unfilled arcs, and many other figures that
sometimes are quite useful

 

[Nik Coughlin]

There is the answer. While I agree there is never any content that
can't be served without javascript, sometimes it just makes sense to
do it that way, your client's may even prefer it that way. Would
google maps be better if served without javascript?

You're right of course, but I'm not saying you should just use one or the
other. Google Maps can still be used without JavaScript, it's just a bit
slower and the interface is dumbed down a lot. It's better with JavaScript,
but they've still made sure that you can use it without.

How am I doing a disservice by leaving an option open? I am not
saying you HAVE to do it that way, just don't rule it (anything) out
prematurely.

Sure, never say never. I guess a better way to phrase it would be, in the
vast majority of instances there is no need to serve content solely via
JavaScript. I can't think of any exceptions to that off the top of my head
but that doesn't mean that there aren't any. OK.

 

[Nik Coughlin]

Not sure if I count, but here is something from me anyway...

Oh, you count. Most definitely. Usually something wise to say, sometimes
something entertaining, often both.

Perhaps. But normally one does think it serves just one purpose, namely:
to style the information. The information is some constant thing that
can be presented in many ways, some genuinely as good as other ways,
some not but they will do the practical job

I don't think, when it boils down, you have a clear distinction here.

Oh, I do! At least, it's clear to me. Haha.

I think you are right in that there is no getting away from there having
to be some core presentational aspects to semantics. To take a model for
a sec, it matters which order the words go to a sentence's meaning. That
does not mean there are not alternative meaningful sentences that will
do as good a job to convey the information. What is usually advised in
good writing is to choose the simplest way that conveys the ideas.

Yes. A laudable goal and one I strive for -- not always successfully, but
so long as one tries (and tries again), right?

And so too, the real idea of the advice to mark up semantically, in my
opinion, is to urge the simplest mark up that is consistent with
conveying the information.

What I suspect folk are objecting to when there is an over elaborate
htmling is that the author really is doing everything he can not to
*just* convey the information, but to present it fancy. The competent
author (like yourself) is massaging like crazy and then the css is added
and hey presto, he gets the look he wants. But he has not written up
semantically in the sense that was meant because a lot of the html is
redundant, unnecessary for the conveying of the meaning.


Ah... now this is a different matter, how bad it is! If you care about
looks, and you are not to be criticized for this, and if indeed there is
no route to elegance without 'less than simple' mark up plus clever css,
then who can say? You will just get opinions and no real arguments.

Well that's OK. Either opinions or arguments are still useful.

But there is a point here that people may miss: because of the
limitations due to browser differences and implementations, the bar is
actually quite high for producing elegant results, both in the html, the
css and the final product. In the end, each person must simply try their
best. To succumb too early to pressure to grow divs for non-semantic
purposes is bad, to be content with uninspiring looks is bad. You just
do your very best to avoid either.

I don't know that there was much point in my replying to this. Seems my only
contribution in response was "Yes, I agree. Yes"

 

[dorayme]

Oh, you count. Most definitely. Usually something wise to say, sometimes
something entertaining, often both.

Oh, I do! At least, it's clear to me. Haha.

Your first category very much involves how things "actually look" but
you are attributing this description only to the second category. So
there is an unclarity to begin with.

 

[Nik Coughlin]

Rounded corners are something everyone wants and one of the bits of CSS
3 most people are already doing or will be soon, so then you won't need
all the extra elements.

Yep. But even so having rounded corners in CSS3 is I think less useful than
having the ability to have multiple backgrounds. I used rounded corners as
an example but what I really meant is any graphic that can be sliced into 9
logical units (top left, top, top right, left, center, right, bottom left,
bottom, bottom right) to decorate a rectangular block -- rounded corners
being the most common but by no means the only application of this.

Although rounded corners in CSS is a good idea, for lots of things I
think it's better to keep CSS simple.

If a problem can easily be solved with an extra div let it be solved
that way rather than putting a new obscure property into CSS 3. It's
fundamentally a more powerful way of doing things.

Yes. The problem arises with the current browser support is that each of
the 9 logical units that make up a "skin" require their own div, suddenly
you have a lot of them.

You can see what I mean here:

http://nrkn.com/skinning/

There is a lot of additional markup for all of the techniques aside from
CSS3 multiple backgrounds, and that has its own issues even aside from the
lack of browser support.

Actually I might post that url to the newsgroups for comment, would be
interested in seeing what people think.

The order in which the elements appear in the source document greatly
influences the layout options anyway, so the idea that presentation and
content are entirely separated is already a fantasy.

And if they were, life would become more complicated . Basically you'd
have to write two documents: the "semantic" one and another one that
remapped every element into its position in an alternative "layout
tree".

I suppose you could do it a bit like z-index: for most purposes things
are more or less stacked in the order they appear in the document tree,
but you can move them around a bit with z-index. You could set "y-index"
on an element which meant it started a "y context". Descendents from
later in the document could be transplanted into different positions in
their y context by setting y-index on them. The document would be laid
out in y order rather than in tree order.

That way you could do things like putting the second div above the first
one if you really wanted to, but if you couldn't be bothered, you'd just
get the document tree laid out as normal.

Yes. One thing that annoys me is that floating right mucks up your source
order. Oh, I understand why it's like that, but for practical purposes it's
a pain.

I think you're absolutely right, and I have seen people use JavaScript
for #2 as well, for just this kind of thing: where you need lots of
little fussy elements to get rounded corners and other CSS 3 effects
that aren't in CSS 2.1 yet.

Adding them all over the place to the markup creates the usual practical
maintenance problems of pasting boilerplate everywhere.

The purist philosophical argument for #2 is flawed IMO, but this
practical one is quite convincing.

The other thing you can consider here is pre-processing the HTML to put
the extra stuff in. Solves the practical problem but not the purist one
(and screen-readers that theoretically did things even vaguely properly,
of whose existence no evidence has been presented, would read out all
the extra cruft).

I do this anyway, so yeah. You have to in order to do skinning as discussed
above.

Yeah this is how people let themselves off the hook. You can sometimes
put the wrappers in with :after/:before.

Sure, but not supported in IE<8 (how many times do I find myself saying
that, sigh)

I think the appropriate question is just whether you could have done it
with fewer wrappers.

The answer is, generally not. Oh there's that nasty hackery when you look
at every child element and think, how could I subvert this to take the place
of one of the wrapper elements, but I really dislike that. If you want to
change the children suddenly you have to rework everything, and it's simply
not practical for generated content.

I think both solutions are OK in principle. Which means choose the one
that best fits what you're trying to do: if it's easier and simpler to
use JS to add the boilerplate then use it, but if it's only a couple of
wrappers per page, just use the markup.

If the HTML is so polluted it's a problem for browsers like lynx or
other HTML-processing tools, that could provide a swing towards using JS.

Well usually the wrappers are just a bunch of divs, I've never seen lynx and
friends choke on extra divs.

Search the archives for "brave layout": there was a discussion there on
whether pure HTML that then got schmutzed up by lots of JS was
considered OK or not.

I couldn't find anything with Google Groups search unfortunately.

 

[dorayme]

#1. HTML - content marked up semantically
#2. Layout CSS - how the content appears on the page and where
#3. Skin/Appearance CSS - how the content looks
#4. Javascript - Adds behaviour, should never take the place of #1. Or 2 or
#3? That is my question I guess.

Now, adding HTML to enable #2 (layout) is still within the bounds of
semantic markup, if you enclose some of your content within a div (or
whatever) in order to display that content in a specific column for example,
you are implying that the enclosed content is all related in some way or
another.

Just a little more on the nature or importance of the distinction
between #2 and #3? (Your last response to my questioning of it was that
it was clear to you and "ha ha").

What quite is involved in #2? Where stuff is on the page is obviously
part of how the page looks. And it is not a simple part like the colour
of an element's background. It can have a very dynamic aspect as when
text or a float is allowed to wrap according to user settings like
browser width, font-size. The aesthetics involved in #2 are of a deeper
kind to the ones that are involved in #3. Many of us rate it as more
fundamental, not so superficial. We care that information is presented
well and logically, and don't so much care if the box has rounded
corners or not. I would not be surprised if a lot of people felt this
way given the difficulty of negotiating so many websites.

It might seem tempting to think of #2 as more allied to meaning, your
point about grouping like with like in a column is a push in that
direction. But having material in a column on the left (the navigation,
for example) is no more semantic than having it on the right, or across
the top. There is nothing semantic in itself about the positioning on
the page. The semantics comes from the use of appropriate elements in
the HTML.

If you are wanting to say that nevertheless, where things go, is an aid
to the user understanding, this too can equally be said of many things
that fall under #3 if the author chooses wisely. This last condition is
significant. If all he does with #3 is mere pretty pretty, good luck to
him or he is not concerned with meaning anyway? If he does with #3 stuff
that helps draw attention to things to help understanding and
navigation, then here we have that deeper functional aesthetics
intruding into things that we might have supposed only applied to #2 (or
indeed #1).

These are the sorts of things I meant earlier when I was questioning the
distinction. The lines between hard content and presentation are really
not clear cut (as Ben C appreciates). But we can discern the rough form
of what presentation is hardcore (and entwined with meaning) that it is
not at all a matter of aesthetics. You simply cannot have a sentence or
a paragraph with the words all over the show. They have to be in a
certain order and together and that is that. Here presentational 'How
things look' are glued onto meaning.

The idea of CSS, as I see it, is to give the author a means to vary the
presentation without losing the meaning. The author can use this power
to help the meaning get into the head of the user more easily or he can
use it to do quite entirely different things over and above this.

The truth is that many websites have no more content than can be fitted
into the already atrophied brain of an ant. The author is off doing his
thing for looks for their own sake. Or to press buttons, to attract
attention, to make money, to get hits or whatever have you. I am not
saying it is a worthless activity. It is not a worthless thing to make
an abstract painting. But it needs to be distinguished from all
pretensions about meaningful content.

 

[Nik Coughlin]

Just a little more on the nature or importance of the distinction
between #2 and #3? (Your last response to my questioning of it was that
it was clear to you and "ha ha").

Yes, I wasn't trying to denigrate your response I just wasn't sure how to
explain it. There is a division between these two in my mind but of course
now that I try to explain it it is suddenly not so clear. Maybe one of the
reasons I see it as being two seperate things is that in the past I have
worked on white label projects (both desktop and web) where the application
or web interface had to work the same way and be consistant but also needed
to be branded differently for different clients, ie different colours,
fonts, logos etc. in the interface. Thus I have done a lot of work with
skinning technologies and I often see the layout of a web page or form in an
application (form having quite a different meaning in a desktop app than on
the web) as a plain black and white "where things are" visual that is then
going to have the appropriate colours and graphics painted over it

I think that sort of explains where I am coming from. It is my own personal
bias of experience.

What quite is involved in #2? Where stuff is on the page is obviously
part of how the page looks. And it is not a simple part like the colour
of an element's background. It can have a very dynamic aspect as when
text or a float is allowed to wrap according to user settings like
browser width, font-size. The aesthetics involved in #2 are of a deeper
kind to the ones that are involved in #3. Many of us rate it as more
fundamental, not so superficial. We care that information is presented
well and logically, and don't so much care if the box has rounded
corners or not. I would not be surprised if a lot of people felt this
way given the difficulty of negotiating so many websites.

It might seem tempting to think of #2 as more allied to meaning, your
point about grouping like with like in a column is a push in that
direction. But having material in a column on the left (the navigation,
for example) is no more semantic than having it on the right, or across
the top. There is nothing semantic in itself about the positioning on
the page. The semantics comes from the use of appropriate elements in
the HTML.

That's true, but there is also a certain way that people scan information,
in western culture we read top to bottom, left to right etc. You've
probably seen those heat map type graphics that show what parts of a page
people look at first/the most, that kind of thing. That guides decisions on
where to place content based on its importance and relevance too

If you are wanting to say that nevertheless, where things go, is an aid
to the user understanding, this too can equally be said of many things
that fall under #3 if the author chooses wisely. This last condition is
significant. If all he does with #3 is mere pretty pretty, good luck to
him or he is not concerned with meaning anyway? If he does with #3 stuff
that helps draw attention to things to help understanding and
navigation, then here we have that deeper functional aesthetics
intruding into things that we might have supposed only applied to #2 (or
indeed #1).

Ah see I think this is the purpose of pretty pretty, a) to aid user
understanding but also b) I attended a course on interface design where the
person giving the talk told us about a study that he was involved in, where
they had users rate the ease of use of an ATM interface. There were several
variants of the interface, but in all of them the various elements were
positioned in exactly the same place. The users that were given the
"pretty" version of the interface scored it more highly on "easy to use"
than the group given the plain interface. It's probably almost entirely a
psychological effect rather than a real one, and the study didn't provide
any metrics on whether or not the users *actually* navigated the system any
more effectively, it was just a *perceived* benefit.

These are the sorts of things I meant earlier when I was questioning the
distinction. The lines between hard content and presentation are really
not clear cut (as Ben C appreciates). But we can discern the rough form
of what presentation is hardcore (and entwined with meaning) that it is
not at all a matter of aesthetics. You simply cannot have a sentence or
a paragraph with the words all over the show. They have to be in a
certain order and together and that is that. Here presentational 'How
things look' are glued onto meaning.

No, the idea of arranging the words in a sentence in a very non-optimal form
for understanding because the words look more balanced in terms of length
for example in that order is plain silly, though maybe not so bad if you are
some avant garde poet

The idea of CSS, as I see it, is to give the author a means to vary the
presentation without losing the meaning. The author can use this power
to help the meaning get into the head of the user more easily or he can
use it to do quite entirely different things over and above this.

The truth is that many websites have no more content than can be fitted
into the already atrophied brain of an ant. The author is off doing his
thing for looks for their own sake. Or to press buttons, to attract
attention, to make money, to get hits or whatever have you. I am not
saying it is a worthless activity. It is not a worthless thing to make
an abstract painting. But it needs to be distinguished from all
pretensions about meaningful content.

I still think over and above everything else content is king, the most
important thing of all, but I also think there is huge value in aesthetics
too. So, I guess I totally agree with you in that sense.

Hey, thanks a lot for your time, sharing your experience and knowledge and
the thought you put into this. I really appreciate it.

 

[dorayme]

...There is a division between these two in my mind but of course
now that I try to explain it it is suddenly not so clear. Maybe one of the
reasons I see it as being two seperate things is that in the past I have
worked on white label projects (both desktop and web) where the application
or web interface had to work the same way and be consistant but also needed
to be branded differently for different clients, ie different colours,
fonts, logos etc. in the interface. Thus I have done a lot of work with
skinning technologies and I often see the layout of a web page or form in an
application (form having quite a different meaning in a desktop app than on
the web) as a plain black and white "where things are" visual that is then
going to have the appropriate colours and graphics painted over it

I think that sort of explains where I am coming from. It is my own personal
bias of experience.

Fair enough. I understand this... I was just trying to get away from all
our biases...

That's true, but there is also a certain way that people scan information,
in western culture we read top to bottom, left to right etc. You've
probably seen those heat map type graphics that show what parts of a page
people look at first/the most, that kind of thing. That guides decisions on
where to place content based on its importance and relevance too

That the whole business of how to communicate is heavily entwined with
presentational things best handled with CSS and even js is not in doubt
in my mind. A tone of voice of a kindergarten teacher can actually make
the difference between a small kid understanding something and not so
understanding it. There is nothing superficial (mere 'pretty pretty')
about presentation and art in the service of communication.

I would not describe many of the things that are to do with making a
body of information useful to people by means of colour, and placement,
choice of text and sizes in these terms. In a way, I use "pretty,
pretty" as a term for superficial looks that does none of these things.
I am also mindful that there can be deeper purely aesthetic
considerations for their own sake.

For my part, some colour schemes are pleasing to me on a website because
they *don't* distract from the information that I seek. I know, that
sounds a bit of a negative quality. But think about it, I bet we both
might agree that it would be good if more authors were conscious of it.

Ah see I think this is the purpose of pretty pretty, a) to aid user
understanding but also b) I attended a course on interface design where the
person giving the talk told us about a study that he was involved in, where
they had users rate the ease of use of an ATM interface. There were several
variants of the interface, but in all of them the various elements were
positioned in exactly the same place. The users that were given the
"pretty" version of the interface scored it more highly on "easy to use"
than the group given the plain interface. It's probably almost entirely a
psychological effect rather than a real one, and the study didn't provide
any metrics on whether or not the users *actually* navigated the system any
more effectively, it was just a *perceived* benefit.

Very hard to comment on this without seeing the actual experiment. It
all depends on what is meant by "plain". And the factors you mention are
worth being on guard about.
....

I still think over and above everything else content is king, the most
important thing of all, but I also think there is huge value in aesthetics
too. So, I guess I totally agree with you in that sense.

Something to watch out for in all of this stuff is that there may well
be genuinely serious and worthwhile websites with nothing particularly
to offer in terms of content. For these, content is not king because
there is none. Or, as some might have it, the medium is the message in a
particularly pure form.

I would not want to rule out that a website's *point* might be largely
its style, its aesthetic statement, its sheer pointless eventfulness! No
one who has not been around street theatre, art exhibitions, and
generally taking an interest in all forms of human lunacy will
understand this in the least. But never mind! <g>

 

[Andy Dingley]

For some complex layouts, to
achive certain graphical effects, it is *necessary* to wrap semantic markup
within quite a few container elements.

[Using client-side JS to generate extra markup to support CSS]

Are you thinking of A List Apart's "zebra tables" example?

I don't do this. I recognise the need for it, and it's an interesting
technique. I do make the extra markup and "CSS hooks", but I do it
through server-side code. That's mostly because I don't write HTML, I
hand-code server-side code to make HTML. For me, it's as easy to do it
on the server as anywhere.

I avoid client-side JS, not through fear of non-JS clients, but
through a desire for simplicity. These days I have a lot of bandwidth
but limited time to debug the code. I'd much rather work on something
that shipped a big, simple page than a small, complicated page
generation program. Time-to-working is better the first way.

If I wrote more static HTML, I'd be considering this.

As I write more AJAX-related code (I'm mainly doing intranet webapps,
not intaweb pages) then I might swith to doing this anyway,

However, I've in the past been heavily criticised for adding HTML markup
(lots of wrapper divs usually) solely in order to enable #3, CSS that
controls the appearance or skin applied to a set of content.

That's because the critics don't grok CSS beyond the level of, "All
<tables> are bad, every single time".

If you haven't already (anyone!) read Hakon Lie's PhD thesis on CSS
design. Look at what was leftout, and hoow CSS _requires_ some level
of pre-processing to its input HTML document to put hooks in place.
This was a deliberate trade-off, as a way to avoide the need for CSS
to end up as complicated as DSSSL.

 

[Travis Newbury]

It's [google maps] better with JavaScript,
but they've still made sure that you can use it without.

I personally find it completely unusable without Javascript. But
that's just me, and I need the bonus chocolate

 

[Andy Dingley]

I can't see any reason why you
would ever have content that is *only* accessibly by JavaScript -- there
really is NEVER content that *requires* JavaScript and cannot be served any
other way.

Using AJAX to serve 20MB navigation trees into complex forms. This is
only servable if you interactively serve slices of it, rather than the
whole thing. Although you don't need AJAX to serve slices, the round-
tripping needed to both select a new slice, and to leave the data
entry form in the same state, done _without_ AJAX (i.e. a submission
of the complete page and form by HTTP) is cruelly slow, both for user
interaction and for total server load.

You are doing your client's users a disservice by assuming the opposite.

My clients want an intranet app. It's still "HTML" (and that's where
this is posted, not even c.i.W.a.h) and there is no reason at all to
exclude JavaScript for this user population. Although I might go so
far as to say "Always include a non-JS fallback, no matter how
glacial" for internet pages, that's unnecessary for intranets with
guaranteed JS. Thus for a developer to assume that this _always_
applies is inappropriate.