xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henning von Bargen <H.vonBar...@triestram-partner.de>
Subject AW: [OT] Design Rant
Date Fri, 21 Dec 2001 09:57:59 GMT
> -----Urspr√ľngliche Nachricht-----
> Von:	Robert Koberg [SMTP:rob@koberg.com]
> Gesendet am:	Donnerstag, 20. Dezember 2001 17:52
> An:	general@xml.apache.org
> Betreff:	Re: [OT] Design Rant
> 
> How do you handle text resizing by the user when using DIVs with two or
more
> columns? Don't they overlap when they get larger or do you use fixed font
> sizes and don't let the user resize text?  For example try to build the
> proposed layout with DIVs and then change the browsers view-text setting
to
> a larger size. Does the nav now overlap the content?
> 
> How do you handle more than a three column layout?
> 
> These are 'real world' concerns.
> 
> DIVs are not the best solution to the widest appeal.  The problems you
site
> about tables affect a very small minority of web users.

A HTML page should simply be coded in a linear fashion
(I read that somewhere in an article about designing web pages for impaired
readers),
so that it is usable with screen readers.
As a rule of thumb, it should be more or less possible to read the html code
like a book if you think all the html tags stripped off.
Tables should be used for tabular data only inside the content
and (as a practical exception) can be used inside toolbars at the top and
bottom
which aren't part of the content.
BTW, the text resizing problem you mentioned above is exactly the same with
fixed-size tables.
All that pixel-measuring-stuff should be left to the browsers.

> 
> 
> ----- Original Message -----
> From: "Berin Loritsch" <bloritsch@apache.org>
> To: <general@xml.apache.org>
> Sent: Thursday, December 20, 2001 5:57 AM
> 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:     webmaster@xml.apache.org
> > To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
> > For additional commands, e-mail: general-help@xml.apache.org
> 
> 
> ---------------------------------------------------------------------
> In case of troubles, e-mail:     webmaster@xml.apache.org
> To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org

---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org


Mime
View raw message