RE: XPath as CSS-selectors?

David Woolley wrote:

> The reality of the world is that the people who make the decisions
> about paying people wages also make decisions about how the web
> site will look.

That's true. It's also true that most web-duh-signers in the world
don't know the difference between:

  <font size="4"><b>Heading</b></font>

and

  <h1>Heading</h1>

so the mix between the two, is catastrophical.

> They don't understand the philosophy behind the web; they just
> know how they want their page to appear (visually) and behave.

The problem is that web developers aren't competent enough to
say that what they want, won't actually behave the way they want
when done this or that way. They should e.g. explain that (i)frames
won't behave right in browsers that don't support them, and more
important; search engines most probably won't index their web
pages right.

Not being properly indexed by search engines means loss of page
impressions, which in other hand means loss of customers, which
then again means loss of money. If you can speak directly to the
money nerve of these decision makers, they will listen.

All bad HTML (and combined technologies) will most probably lead
to a loss of customers and money, while good HTML will not. Other
techniques that can loose you customers:

  1. The use of the abovementioned <font><b> as headings. These
     "headings" will not be indexed by search engines as headings,
     because they are not.

  2. The use of frames. This will lead to search engines not
     indexing your site the right way. Commonly you'll see that
     the <title> tag on sub pages of a framed site is empty, or
     set to "New Document 1". This is because the wrong title
     isn't discovered because it never reaches the title field
     of the browser. 

  3. Ignoring blind users. Blind users are also customers. When
     making a menu out of nothing but JavaScript, forgetting
     alternative texts on images, using tags for what they aren't
     meant for (e.g. <table> for design and not table data), blind
     users won't be able to use the site.

  4. Blind users will also have huge problems with (i)frames.

  5. Not paying attention to color blindness. If customers can't
     read the red text on the green background of your web page,
     (s)he can't buy any of your neat products either.

  6. Using images instead of text. To a small extent, this is
     acceptable, but only for short or unimportant messages.
     (Bitmap) images can't be resized, and if you forget the
     alternative text as well, they will be almost useless to
     any other user than those who sit on the same type of
     PC as the designer.

  7. Using pt, px, etc., as font units. This makes the font
     unscalable in Internet Explorer, which may lead to unreadable
     fonts in resolutions the designer haven't thought about.
     If e.g. a user sits on a 1600 x 1200 monitor with his text
     size adjusted to "Larger", the text won't be any larger if
     the font size is set with px.

  8. Embedding too much, or all, information into objects like
     Flash and Java. This might look cool, but the information
     is unavailable for blind users, users without support for
     such objects due to security settings in their company,
     and yet againg; search engines.

This were just some points from the top of my head. I'm sure there
are many more. If web designers could tell about these points to
the decision makers, they would pay attention to them, especially
if they can be convinced that they'll lose money wihtout doing so.

> They are at the top of the chain of command, so the developer
> who knows what's best for them manipulates the available tools
> to work the way requested, *without* expressing opinions back up
> the chain of command.

This might be true in some cases, but more commonly I think the
web designers don't have a clue about how things really should be
done.

> Some may realise that particular ways of doing things are travesties
> of the web or have huge performance costs, but, if they can achieve
> the objective at all, they are expected to do so by whatever hacks
> they can.

Yes they will, because they either don't have the courage to tell
their boss/customer that "this and that" isn't a good idea, or
because they just don't know that it is a bad idea themselves.

Also; would you tell your carpenter that he should build your house
out of whipped cream, because it looks great and has a nice "feeling"
to it? If you did, would you not pay attention to what he had to say
about your suggestion? If he said "I don't think that's a good idea",
would you start arguing and asking why not? If he told you 10 extremely
good reasons for why you shouldn't, would you still not listen?

Why is it that people listen to carpenters and not to good web
developers?

> Others may not really understand the implications, because training
> them to understand costs money, and their cut and paste HTML coding
> does the job the managers want.

It does the work for a period of time. The code is most likely not
forward compatible. It's most likely not compatible at all, other than
with Internet Explorer. They would therefore have to redesign and
rewrite the whole shebang every now and then, because they don't know
how to make it right and forward compatible.

> If the performance is then bad, the tools get blamed, not the lack
> of training or the one way communication.

True.

> If the tools get blamed, people move suppliers until they find tools
> that tolerate bad coding better.

This is the main problem. "Tools that tolerate bad coding better". The
fact that such programs exist, and that it's almost a contest in the
business to accept as much crap as possible, is sceary. "In our tool,
you can write any bogus crap you want, and it will display perfectly
in the browser 95% of the market use!".

> Generally selection pressures are against people who really understand
> things, and certainly against those who don't believe the customer is
> always right.

Yup.

> Although the ideal might be for the software developers and the
> page specifiers to negotiate their requirements, the reality is that
> the chain of command makes the software developers slaves of the
> page specifiers.

Sad, but true. Hopefully this will change in time. I'm not holding my
breath, though.

-- 
Asbjørn Ulsberg           -=|=-          X-No-Archive: No
"He's a loathsome offensive brute, yet I can't look away"

Received on Monday, 23 June 2003 06:32:03 UTC