<snip>HTML was always intended to render semantic information</snip>
I know it was always intended.
I'm just wondering, where does that stand now we have XML? Hasn't HTML
become a formatting language, in an evolutionary kind of way?  If you want a
semantic markup language for your information, don't we now have the option
of producing a really powerful customised one for our specific subset of
data?

<snip>Why waste our time trying to get one page that renders the same in all
browsers</snip>
I totally agree.  I hate NS4, particularly the size of FORMS.  I'm canning
support for it next year.

Alistair

-----Original Message-----
From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 20, 2001 1:57 PM
To: [EMAIL PROTECTED]
Subject: Re: [OT] Design Rant


Alistair Hopkins wrote:

> -1
>
> Unless someone can explain WHY tables are a bad way to lay out HTML.
'They
> weren't intended for it' isn't really good enough!  If they provide a
richer
> functionality without nasty side effects why not?  How are they so bad for
> text browsers?  Now, the argument behind FORMATTING using css is rock
solid,
> but I always thought that HTML was about LAYOUT and CSS was about
> FORMATTING.  Looking at w3c, they go on about 'adding style': I always
read
> that as 'formatting'. In my work, I'm clear:


Here are some really *practical* reasons why tables suck for layout
purposes,
beyond "div" is supposed to represent logical divisions:

* Their use means that you are trying to support outdated browsers, and they
   _all_ represent tables differently.

* Using broken browsers like Netscape 4.x (creature features are great, but
   the rendering code sucks), tables slow down the rendering to a crawl.  It
   is not uncommon for a 8k page to take over 30 seconds to render on that
   browser.

* Due to inconsistent layout engines (in some browsers, whitespace makes a
   *huge* difference), you have to have several proprietary attributes.

* People try to be too tricky with them, and it backfires in page download
   size explosions, and the content does not render the same.

* You can never be as espressive with table rendering as you can with CSS
   styling in your layout.

The argument regarding HTML representing FORMAT is false.  HTML was always
intended to render semantic information.  That is the reason for <h1>, <p>,
<strong>, etc.  The bold, italic, and teletype tags (<b>, <i>, <tt>) were
all hacks.

Are there some implicit styles for the elements?  Yes.  In the CSS2
documentation,
they have an appendix that shows the _default_ style for every
tag--including
the display properties.

Also, there are things that CSS can let you do that HTML won't, or that you
would need to write 100 lines of javascript code to accomplish (like
watermarking--
an image on the background of the page).  The power of HTML+CSS is
incredibly
powerful.

CSS was designed to be a declarative description language, so that when the
interpreter encountered a tag of a particular class and/or id, it knew how
to render it.  With the default CSS styles defined by the W3C, your page
will
be rendered more consistently.



> XML [data] -xsl-> HTML [data+layout] -css-> Screen
[data+layout+formatting]
>
> To change the layout, I change the xsl.  I design the xsl so that
> site-global layout is managed from a single point.  If I want HTML without
> any HTML markup for non-browser-usage, I use - well, XML!  If I want
'HTML'
> to print nicely, I use FO and FOP.


I am all for XSL--but the XSL layer is best used for transforming a simple
page into vastly different presentations.  For example, I have set up a
system with Cocoon so that the web site can be re-themed on the fly.  This
is to show off what our pre-packaged web themes look like, without giving
work away.

Each conceptual design is so vastly different, it would never be possible to
correctly express in CSS.  This is where XSL comes in.



> Pragmatism over purism, I say.


The pragmatism is this:  We all only have so much time to devote to
developing
the site and the projects.  Why waste our time trying to get one page that
renders the same in all browsers when you are working around four year old
BUGS, that have been fixed in later releases.  Four years is enough time for
people to buy new computers, much less upgrade their browsers.

Who wants to develop three renditions of the EXACT SAME page?  There is
little
feeling of payoff for it.  I mean, unless you want to _pay_ me to do it ;)


--

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


---------------------------------------------------------------------
In case of troubles, e-mail:     [EMAIL PROTECTED]
To unsubscribe, e-mail:          [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
In case of troubles, e-mail:     [EMAIL PROTECTED]
To unsubscribe, e-mail:          [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to