You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs-dev@perl.apache.org by Thomas Klausner <do...@zsi.at> on 2002/01/04 22:42:24 UTC
table or not table
Hi!
As the implementation of a basic table around the left nav / content area is
rather trivial, I'd like to discuss the issue once more:
PROs of using table:
* The page renders as intended on non-CSS browser
CONs of using table:
* The page won't render before </table> is transmitted to the client
* Some browsers (lynx, browsers for disabled people) don't render tables
* the Web Content Accessibility Guidelines 1.0 disencourage the usage of
HTML for presentation.
(http://www.w3.org/TR/WCAG10/#gl-structure-presentation
Misusing markup for a presentation effect (e.g., using a table for layout or
a header to change the font size) makes it difficult for users with
specialized software to understand the organization of the page or to
navigate through it.
)
PROs of not using table:
* The page degrades properly on all browser (exept buggy ones)
* Less HTML overhead (although very minor in this case, but quite big when
compared to Stas' initial design)
CONs of not using tables:
* The page may look bad on browsers with no or buggy CSS support
So the main thing to decide is:
Do we want the page look exactly (or nearly) the same on all browsers
thereby using some (IMO) dirty HTML tricks, or do we want the page to be
clean and well degrading, but looking broken/strange on some (buggy) browsers.
I think you know my opinion (don't use the table) but if this is a little bit
too utopian for the mod_perl site, I won't object to using a table.
(Although I don't like giving in to "the mainstream" just because
"if everybody does it wrong, why should I care". If enough people do care
and communicate this issue, sooner or later web pages will be working for
everyone (no more "please enable JS/download flash/take this cookie"
bouncers anymore!!)
But I won't let my personal crusade get in the way of the mod_perl
community, so I don't insist on my ideas.
Maybe we should discuss this issue on the mod_perl mailing list?
--
D_OMM +----> http://domm.zsi.at <-----+
O_xyderkes | neu: Arbeitsplatz |
M_echanen | http://domm.zsi.at/d/d162.html |
M_asteuei +--------------------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: table or not table
Posted by la...@inet.uni2.dk.
Quoting Stas Bekman <st...@stason.org>:
> Thomas Klausner wrote:
>
> > Hi!
> >
> > As the implementation of a basic table around the left nav / content
> area is
> > rather trivial, I'd like to discuss the issue once more:
> >
> > PROs of using table:
> > * The page renders as intended on non-CSS browser
> >
> > CONs of using table:
> > * The page won't render before </table> is transmitted to the client
> > * Some browsers (lynx, browsers for disabled people) don't render
> tables
> > * the Web Content Accessibility Guidelines 1.0 disencourage the usage
> of
> > HTML for presentation.
> > (http://www.w3.org/TR/WCAG10/#gl-structure-presentation
> > Misusing markup for a presentation effect (e.g., using a table for
> layout or
> > a header to change the font size) makes it difficult for users with
> > specialized software to understand the organization of the page or to
> > navigate through it.
> > )
> >
> > PROs of not using table:
> > * The page degrades properly on all browser (exept buggy ones)
> > * Less HTML overhead (although very minor in this case, but quite big
> when
> > compared to Stas' initial design)
> >
> > CONs of not using tables:
> > * The page may look bad on browsers with no or buggy CSS support
>
>
> good summary!
+1
> > So the main thing to decide is:
> > Do we want the page look exactly (or nearly) the same on all browsers
> > thereby using some (IMO) dirty HTML tricks, or do we want the page to
> be
> > clean and well degrading, but looking broken/strange on some (buggy)
> browsers.
>
>
> I say clean and well degrading, but still usable in buggy browsers.
>
>
> > I think you know my opinion (don't use the table) but if this is a
> little bit
> > too utopian for the mod_perl site, I won't object to using a table.
> > (Although I don't like giving in to "the mainstream" just because
> > "if everybody does it wrong, why should I care". If enough people do
> care
> > and communicate this issue, sooner or later web pages will be working
> for
> > everyone (no more "please enable JS/download flash/take this cookie"
> > bouncers anymore!!)
>
>
> OK, why don't we try this approach. We keep it table-less to start with.
>
> If too many people complain we add tables?
in fact i agree with you all at one point or another (i fully apricate all
thomas points in why not to use tables and likewise bills to actually do use
them) and this approach stas is suggesting is probably the best.
i think we all agree that the actual meat/content is never going inside a large
table, right?
so we will not see a perfomance loose rendering wise if we stick (and only if
necesary of course) to tables for the widgets and possibly the menu.
./allan
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
RE: table or not table
Posted by "Jonathan M. Hollin" <ne...@digital-word.com>.
:: Please don't. We don't want to create unnecessary off-topic traffic
:: waves. Most people don't care about this kind of things and when the
:: load goes high they simply unsubscribe, which is bad.
::
:: So once we think we have what we want, we will post the
:: URL(s) to the
:: list and if anybody wants to comment on these, they will be
:: asked to do
:: it here.
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: table or not table
Posted by Stas Bekman <st...@stason.org>.
Thomas Klausner wrote:
> Hi!
>
> As the implementation of a basic table around the left nav / content area is
> rather trivial, I'd like to discuss the issue once more:
>
> PROs of using table:
> * The page renders as intended on non-CSS browser
>
> CONs of using table:
> * The page won't render before </table> is transmitted to the client
> * Some browsers (lynx, browsers for disabled people) don't render tables
> * the Web Content Accessibility Guidelines 1.0 disencourage the usage of
> HTML for presentation.
> (http://www.w3.org/TR/WCAG10/#gl-structure-presentation
> Misusing markup for a presentation effect (e.g., using a table for layout or
> a header to change the font size) makes it difficult for users with
> specialized software to understand the organization of the page or to
> navigate through it.
> )
>
> PROs of not using table:
> * The page degrades properly on all browser (exept buggy ones)
> * Less HTML overhead (although very minor in this case, but quite big when
> compared to Stas' initial design)
>
> CONs of not using tables:
> * The page may look bad on browsers with no or buggy CSS support
good summary!
> So the main thing to decide is:
> Do we want the page look exactly (or nearly) the same on all browsers
> thereby using some (IMO) dirty HTML tricks, or do we want the page to be
> clean and well degrading, but looking broken/strange on some (buggy) browsers.
I say clean and well degrading, but still usable in buggy browsers.
> I think you know my opinion (don't use the table) but if this is a little bit
> too utopian for the mod_perl site, I won't object to using a table.
> (Although I don't like giving in to "the mainstream" just because
> "if everybody does it wrong, why should I care". If enough people do care
> and communicate this issue, sooner or later web pages will be working for
> everyone (no more "please enable JS/download flash/take this cookie"
> bouncers anymore!!)
OK, why don't we try this approach. We keep it table-less to start with.
If too many people complain we add tables?
> But I won't let my personal crusade get in the way of the mod_perl
> community, so I don't insist on my ideas.
>
> Maybe we should discuss this issue on the mod_perl mailing list?
Please don't. We don't want to create unnecessary off-topic traffic
waves. Most people don't care about this kind of things and when the
load goes high they simply unsubscribe, which is bad.
So once we think we have what we want, we will post the URL(s) to the
list and if anybody wants to comment on these, they will be asked to do
it here.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: table or not table
Posted by Bill Moseley <mo...@hank.org>.
At 10:42 PM 01/04/02 +0100, Thomas Klausner wrote:
>As the implementation of a basic table around the left nav / content area is
>rather trivial, I'd like to discuss the issue once more:
>
>PROs of using table:
>* The page renders as intended on non-CSS browser
Important point, since, after all, you are spending so much time on getting
it to look right in the first place.
>CONs of using table:
>* The page won't render before </table> is transmitted to the client
GET http://domm.zsi.at/modperl-site-domm/style5/index.html | wc -c
5615
Ok, that's just an example page, but not a lot of content, even at 56K
modem speeds. Not to mention client caching will minimize that problem.
>* Some browsers (lynx, browsers for disabled people) don't render tables
lynx http://yahoo.com isn't that bad, really. I'm not sure what to expect
to see, considering I'm using a text-based browser to view a web page
that's probably designed as a graphic image originally.
lynx http://www.php.net/ isn't too bad either.
...
>So the main thing to decide is:
>Do we want the page look exactly (or nearly) the same on all browsers
>thereby using some (IMO) dirty HTML tricks, or do we want the page to be
>clean and well degrading, but looking broken/strange on some (buggy)
browsers.
I guess you would have to answer the question of "what is the purpose of
the mod_perl site?"
Is it an information delivery portal? Then a consistent "look" probably
isn't that important.
Or is it to promote mod_perl? Then the "look" is probably very important
-- businesses spend huge amounts of money just to develop their "brand".
Maybe "brand" or "image" is not that important with mod_perl, that is,
maybe some IT manager looking at web technology wouldn't care about how the
site looks, compared to someone trying to buy a book at Amazon.com when the
site doesn't render.
My guess is that it's most likely that people will view the site with
browsers instead of "specialized software" as that w3.org document
suggests. So, it seems to make sense to design for that. So that either
means using those dirty HTML tricks until better days arrive, or that the
site is either dynamically generated or URLs rewritten based on browsers.
My suggestion would be to design it as you feel comfortable with, look at
it with different browsers that you know are accessing perl.apache.org and
decide what's acceptable to you. Then ask on the mod_perl list if anyone
has rendering problems.
I realize this is the same kind of thinking that results in Americans
*still* not using the metric system! ;)
--
Bill Moseley
mailto:moseley@hank.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org