[RT] Getting rid of the table-based layout

[Miles Elam]

Hi all!

Okay, I finally had enough free time to work on a CSS version of
http://xml.apache.org/forrest/

The mockup is at http://forrest.iguanacharlie.com/

Total size is 24,639 bytes
7,190 is the HTML
11,549 is the printer, project and group images
4,659 is the CSS
1,241 is the dependent CSS skinning images

If you gzip -9 index.html and default.css you get 2,148 bytes and 1,108
bytes respectively. Adjusted total size would be 16,046 bytes. I
started eyeing those logos too, but I am hesitant to mess with
organization logos quite so whimsically.

That's a lot of page views per block of bandwidth. And no more spacer GIFs!

-----------------------------

I tried to keep things clean on the filesystem:

index.html
default.css
images/
project-logo.gif
group-logo.gif
printer.gif
skins/
default/
...all of the dependent CSS images...

I also switched to using <link ... media="all"/> instead of the @import
hiding technique to keep things simpler in Netscape CSS hiding. It may
cause problems for users of IE4. If there are any problems, I (or
anyone else) can switch it back.

I have only checked it in Mozilla on RedHat 7.3, Mozilla/Phoenix on
Windows, IE 5.5 for Windows, Netscape 4.79 for Windows, Links on RedHat
7.3, and Lynx on RedHat 7.3. Those are the only browsers I have handy.
Could someone check them in other browsers especially Opera, Konqueror,
IE 5.x on Mac (which I wouldn't be surprised is kinda crufty due to font
size differences), Mozilla 1.x/Netscape 6/7 on Mac, and IE 6.x on Windows?

Note: If you use Mozilla or a derivative, you can preview what it would
look like in older browsers by selecting "View"->"Use Style"->"Basic
Page Style" from the menubar.

Dependent CSS images are all PNGs. All browsers that support element
background images also support PNGs with at least 1bit transparency levels.

One awkward issue for accessibility is that this code uses fixed size
areas so if you expand the text it gets cropped. Unfortunately, as
soon as you start using variable width areas you hit lots of browser
incompatibilities with CSS support. Today I am actually converting
our site back to tables to provide better accessibility!

Thanks. I had forgotten about that when I made the Cocoon homepage
mockup. Truth be told, I forgot about that when making my group's new
homepage too. I made special effort to use more flexible sizing this
time. With extensive use of "em"s, it should degrade gracefully when
font sizes are changed. The tab images and other assorted rounded edges
get a bit crufty as I didn't spend much time tweaking them. The real
solution for them requires CSS3 and scaling element background images.
For now, I think it should be fine for casual observers.

Tables may provide better accessibility only if the tables can
conceptually be serialized. As an exercise, try using it with Lynx.
It'll look pretty good to someone with good eyesight. Imagine you're
blind and must have the navbar read to you on each and every page you
browse until you hit the main content. As such, I moved the main nav
info to the bottom of the XHTML page after the main content.

As for browser incompatibilities, those exist when you use tables as
well. It's just been so long since those issues cropped up, people are
used to them (IE respecting table cell widths but not heights and
Netscape 4.x not listening to either, default cell padding and cell
spacing, default border widths, behavior of ignorable whitespace, etc.).

IE 5.x Mac had issues with element background images so I am especially
curious as to how this renders in it. (I don't own a Mac and
unfortunately can only check it when I'm at friends' homes.) If you see
some extra special cruftiness, please send me a screenshot (only try to
keep the image below 500kB). I tried to keep the CSS as conceptually
simple as possible following the guidelines of this page:
http://developer.apple.com/internet/css/ie5cssbugs.html

- Miles

P.S. I came across a page a couple of weeks ago that had a new and
updated table of CSS hiding tricks listed by technique on the y-axis and
browser on the x-axis. If anyone knows what I'm talking about, please
send me the URL as I neglected to bookmark it.

[Miles Elam]

Wups! Forgot the validation icons for XHTML 1.0 and CSS 2.

Add on another 664 bytes to the uncompressed total page size; That
makes it 25,303 bytes.

- Miles

[Steven Noels]

Post by Miles Elam
Hi all!
Okay, I finally had enough free time to work on a CSS version of
http://xml.apache.org/forrest/
The mockup is at http://forrest.iguanacharlie.com/

Awesome work. This should be translated in a skin.

All: please cross-check with your favorite browser/OS and tell Miles
what you think. If it degrades gracefully, we could consider this making
the default.

</Steven>

[Stefan Bodewig]

Post by Miles Elam
I finally had enough free time to work on a CSS version of
http://xml.apache.org/forrest/
The mockup is at http://forrest.iguanacharlie.com/

Mozilla 1.1 on Linux - both look good and render fine, the only
notable differences to my non-GUI-person eye:

Fonts are bigger in Miles' mockup and I don't get any "diamonds" in
front of the headings (About, Getting involved, ...) inside the
navigation bar. Not sure, whether this is intentional.

Miles' version looks a lot better in lynx, while one could argue about
links (which tries to put the navigation bar to the left in the
"original" table design).

Stefan

[David Crossley]

Post by Steven Noels

Post by Miles Elam
Hi all!
Okay, I finally had enough free time to work on a CSS version of
http://xml.apache.org/forrest/
The mockup is at http://forrest.iguanacharlie.com/

Awesome work. This should be translated in a skin.
All: please cross-check with your favorite browser/OS and tell Miles
what you think. If it degrades gracefully, we could consider this making
the default.

Here are shots of Mozilla and Netscape (4.79) on Linux.
http://cvs.apache.org/~crossley/look/

However, i think that the most important thing is not the "look",
but how the result performs against "Standards Compliance".
http://xml.apache.org/forrest/compliance.html

If they want to use an older browser, then they have to suffer
the poorer appearance.

--David

[Robert Koberg]

Hi - my two cents:

I like the iguancharlie layout. I think it degrades very nicely for Nav4.

You could put a hidden div at the top stating something like:
'the Forrest proj supports standards initiatives. The page layout was designed
in accordance with this. The browser you are using does not support CSS and
therefore you are seeing a degraded version, but all the relevant content is
available.'

nice job iguanacharlie!

The tableless layout is much easier to change into many different views. In
fact, I think the whole concept of how you use the word 'skins' leads to
confusion. You are saying the XSL is the skin when it is more like a skeleton or
actually a bag of bones. The CSS is the skin. XSL=structure, CSS=style. By going
tableless you get closer to the separation of concerns ideal where you can
change the entire layout just by dropping in a new CSS - no regeneration and
possibly solely in the hands of a designer (though I have yet to work with one
who can actually use the power of CSS).

best,
-Rob

-----Original Message-----
Sent: Wednesday, November 13, 2002 3:18 AM
Subject: Re: [RT] Getting rid of the table-based layout

Post by Steven Noels

Post by Miles Elam
Hi all!
Okay, I finally had enough free time to work on a CSS version of
http://xml.apache.org/forrest/
The mockup is at http://forrest.iguanacharlie.com/

Awesome work. This should be translated in a skin.
All: please cross-check with your favorite browser/OS and tell Miles
what you think. If it degrades gracefully, we could consider this making
the default.

Here are shots of Mozilla and Netscape (4.79) on Linux.
http://cvs.apache.org/~crossley/look/
However, i think that the most important thing is not the "look",
but how the result performs against "Standards Compliance".
http://xml.apache.org/forrest/compliance.html
If they want to use an older browser, then they have to suffer
the poorer appearance.
--David

[Nicola Ken Barozzi]

Post by Robert Koberg
I like the iguancharlie layout. I think it degrades very nicely for Nav4.
'the Forrest proj supports standards initiatives. The page layout was designed
in accordance with this. The browser you are using does not support CSS and
therefore you are seeing a degraded version, but all the relevant content is
available.'
nice job iguanacharlie!

+1

Post by Robert Koberg
The tableless layout is much easier to change into many different views. In
fact, I think the whole concept of how you use the word 'skins' leads to
confusion. You are saying the XSL is the skin when it is more like a skeleton or
actually a bag of bones. The CSS is the skin. XSL=structure, CSS=style. By going
tableless you get closer to the separation of concerns ideal where you can
change the entire layout just by dropping in a new CSS - no regeneration and
possibly solely in the hands of a designer (though I have yet to work with one
who can actually use the power of CSS).

Skin is just more than appearance, it's also about functionality.
Skins in programs expose buttons that actually do stuff or can hide them
for simplified stuff.

XSL gives you much more flexibility than CSS in this regard, and is the
only solution for some skinning needs.

Apart from the fact that server side XSL is still needed for a generic
cinversion system, I agree that we should in any way incourage and tout
the use of the forrest skin with custom CSS personalizations.

Maybe it's a terminology issue, right?

Now it's
XSL+CSS=skin
CSS= personalization

But you say:
CSS = skin
XSL = ?

Right?

[Robert Koberg]

-----Original Message-----
Sent: Wednesday, November 13, 2002 5:56 AM

Post by Robert Koberg
The tableless layout is much easier to change into many different views. In
fact, I think the whole concept of how you use the word 'skins' leads to
confusion. You are saying the XSL is the skin when it is more like

a skeleton or

Post by Robert Koberg
actually a bag of bones. The CSS is the skin. XSL=structure,

CSS=style. By going

Post by Robert Koberg
tableless you get closer to the separation of concerns ideal where you can
change the entire layout just by dropping in a new CSS - no regeneration and
possibly solely in the hands of a designer (though I have yet to

work with one

Post by Robert Koberg
who can actually use the power of CSS).

Skin is just more than appearance, it's also about functionality.
Skins in programs expose buttons that actually do stuff or can hide them
for simplified stuff.

This is not my experience with skins. A skin only changes how it looks - it does
nothing to the underlying functionality.

XSL gives you much more flexibility than CSS in this regard, and is the
only solution for some skinning needs.
Apart from the fact that server side XSL is still needed for a generic
cinversion system, I agree that we should in any way incourage and tout
the use of the forrest skin with custom CSS personalizations.
Maybe it's a terminology issue, right?
Now it's
XSL+CSS=skin
CSS= personalization
CSS = skin

XSL = bones (and tendons, ligaments or maybe the tendons and ligaments are
business logic :)

If you drop a new CSS over the same XSL output you change the skin. Where does
the XSL come in?

Right?

I guess it is a terminology issue, but I do believe skins have nothing to do
with functionality

best,
-Rob

[Nicola Ken Barozzi]

Post by Robert Koberg

-----Original Message-----
Sent: Wednesday, November 13, 2002 5:56 AM

Post by Robert Koberg
The tableless layout is much easier to change into many different views. In
fact, I think the whole concept of how you use the word 'skins' leads to
confusion. You are saying the XSL is the skin when it is more like

a skeleton or

Post by Robert Koberg
actually a bag of bones. The CSS is the skin. XSL=structure,

CSS=style. By going

Post by Robert Koberg
tableless you get closer to the separation of concerns ideal where you can
change the entire layout just by dropping in a new CSS - no regeneration and
possibly solely in the hands of a designer (though I have yet to

work with one

Post by Robert Koberg
who can actually use the power of CSS).

Skin is just more than appearance, it's also about functionality.
Skins in programs expose buttons that actually do stuff or can hide them
for simplified stuff.

This is not my experience with skins. A skin only changes how it looks - it does
nothing to the underlying functionality.

Look at the skins for Windows Media Player or AIM for example, they can
reduce the overall functionality.

For example also for Forrest, we have skins that put the author on to,
on the botton, add or not the email, or even change the email from
***@domain to nameATdomain for anti spamming.

But I concede that the general perception of skin is about giving
roughly the same stuff with a different appearance.

Although I fail to see how your CSS-only skin would make the pages
viewable on WAP, which I'm doing right now for some internal intranet pages.

Post by Robert Koberg

XSL gives you much more flexibility than CSS in this regard, and is the
only solution for some skinning needs.
Apart from the fact that server side XSL is still needed for a generic
cinversion system, I agree that we should in any way incourage and tout
the use of the forrest skin with custom CSS personalizations.
Maybe it's a terminology issue, right?
Now it's
XSL+CSS=skin
CSS= personalization
CSS = skin

XSL = bones (and tendons, ligaments or maybe the tendons and ligaments are
business logic :)
If you drop a new CSS over the same XSL output you change the skin. Where does
the XSL come in?

Right?

I guess it is a terminology issue, but I do believe skins have nothing to do
with functionality

Then we can say it's a terminology issue.

That said, I still need the possibility of specifying a set of XSLs that
work on the output; one set would be the forrest system with the
corresponding skins, one would be the ken-wap system, etc.

What name do you propose?

[Robert Koberg]

Howdy,

-----Original Message-----

Post by Robert Koberg

-----Original Message-----
Sent: Wednesday, November 13, 2002 5:56 AM

<snip/>

Post by Robert Koberg
This is not my experience with skins. A skin only changes how it

looks - it does

Post by Robert Koberg
nothing to the underlying functionality.

Look at the skins for Windows Media Player or AIM for example, they can
reduce the overall functionality.

They do that by exposing or hiding things, just like you can with CSS. They do
not change how it works.

For example also for Forrest, we have skins that put the author on to,
on the botton, add or not the email, or even change the email from

These, to me, are configuration attributes for a folder that can be overrriden
at the page level. Then based on the value the XSL decides what to do.

But I concede that the general perception of skin is about giving
roughly the same stuff with a different appearance.
Although I fail to see how your CSS-only skin would make the pages
viewable on WAP, which I'm doing right now for some internal intranet pages.

I only have slight experience with WAP. It seems to me that the skin for a WAP
device is built in - you only send structure. I also think it is talking apples
and oranges - for WAP you need a different set of bones. Just as you can't use
(I think?) a winamp skin with AIM, you can't use an HTML browser skin for WAP.
<snip/>

Then we can say it's a terminology issue.
That said, I still need the possibility of specifying a set of XSLs that
work on the output; one set would be the forrest system with the
corresponding skins, one would be the ken-wap system, etc.
What name do you propose?

?? bonesaw :) I guess I am just rambling so I will shut up now (don't all sigh
at once :)

-Rob

[Nicola Ken Barozzi]

Post by Robert Koberg
Howdy,

-----Original Message-----

Post by Robert Koberg

-----Original Message-----
Sent: Wednesday, November 13, 2002 5:56 AM

<snip/>

Post by Robert Koberg
This is not my experience with skins. A skin only changes how it

looks - it does

Post by Robert Koberg
nothing to the underlying functionality.

Look at the skins for Windows Media Player or AIM for example, they can
reduce the overall functionality.

They do that by exposing or hiding things, just like you can with CSS. They do
not change how it works.

Ok.

Post by Robert Koberg

For example also for Forrest, we have skins that put the author on to,
on the botton, add or not the email, or even change the email from

These, to me, are configuration attributes for a folder that can be overrriden
at the page level. Then based on the value the XSL decides what to do.

Ah, but you assume that they are all pre-decided. I want to be able to
change them if needed in an easy way.

Mind me, I do agree that CSS+attributes is the way we should encourage
our users to make skins, but I still want to have the XSL solution at hand.

Post by Robert Koberg

But I concede that the general perception of skin is about giving
roughly the same stuff with a different appearance.
Although I fail to see how your CSS-only skin would make the pages
viewable on WAP, which I'm doing right now for some internal intranet pages.

I only have slight experience with WAP. It seems to me that the skin for a WAP
device is built in - you only send structure. I also think it is talking apples
and oranges - for WAP you need a different set of bones. Just as you can't use
(I think?) a winamp skin with AIM, you can't use an HTML browser skin for WAP.

Yup. I tend to call the "presentation" bones and the skin all "skin",
and I agree we should instead go with a new terminology and encourage a
more "layered" use of the current "skins".

Post by Robert Koberg
<snip/>

Then we can say it's a terminology issue.
That said, I still need the possibility of specifying a set of XSLs that
work on the output; one set would be the forrest system with the
corresponding skins, one would be the ken-wap system, etc.
What name do you propose?

?? bonesaw :) I guess I am just rambling so I will shut up now (don't all sigh
at once :)

:-P

I think you are right, and probably skin is a bad name for that
bone+skin hybrid we have now, but we need a name for those bones...

[Jeff Turner]

Post by Miles Elam
Hi all!
Okay, I finally had enough free time to work on a CSS version of
http://xml.apache.org/forrest/
The mockup is at http://forrest.iguanacharlie.com/

Excellent :)

Post by Miles Elam
Total size is 24,639 bytes

54k

Under half the size :) :)

Post by Miles Elam
7,190 is the HTML

12,708

Post by Miles Elam
11,549 is the printer, project and group images
4,659 is the CSS

2,276

Post by Miles Elam
1,241 is the dependent CSS skinning images
If you gzip -9 index.html and default.css you get 2,148 bytes and 1,108
bytes respectively. Adjusted total size would be 16,046 bytes. I
started eyeing those logos too, but I am hesitant to mess with
organization logos quite so whimsically.
That's a lot of page views per block of bandwidth.
And no more spacer GIFs!

:)
...

Post by Miles Elam
Note: If you use Mozilla or a derivative, you can preview what it would
look like in older browsers by selecting "View"->"Use Style"->"Basic
Page Style" from the menubar.

Looks as good as any CSS site could.. certainly better in lynx.


Any volunteers to skinify this? Otherwise I'll have a go after some
other work..


--Jeff

Post by Miles Elam
- Miles

[Nicola Ken Barozzi]

Post by Jeff Turner

Post by Miles Elam
Hi all!
Okay, I finally had enough free time to work on a CSS version of
http://xml.apache.org/forrest/
The mockup is at http://forrest.iguanacharlie.com/

Excellent :)

Yes, my compliments :-)

It look worse in Netscape 4 though...

Post by Jeff Turner
Looks as good as any CSS site could.. certainly better in lynx.

Can someone please also check it in "links" with images turned on?

Better, why not put up screanshots of what it looks like in all
browsers, so we can all see it and vote knowing more of it?

Post by Jeff Turner
Any volunteers to skinify this? Otherwise I'll have a go after some
other work..

Not me ;-P but may I suggest one thing...

We have a PDF-printable link on every page, IMHO it would be cool if we
had a "legacy" link that showed the site with the current table based
skin, so that older browsers have a nice viewing experience too...

[Jeff Turner]

On Mon, Nov 11, 2002 at 09:00:53AM +0100, Nicola Ken Barozzi wrote:
....

Post by Nicola Ken Barozzi
We have a PDF-printable link on every page, IMHO it would be cool if we
had a "legacy" link that showed the site with the current table based
skin, so that older browsers have a nice viewing experience too...

..and an "XML" link, so that newer browsers can download just the page
XML and apply the stylesheet themselves.

Perhaps instead of a separate "printer friendly" link, we should have a
block of links under the tabs bar:

legacy | pdf | xml

With corresponding skinconf.xml flags to allow each of these to be
switched off.


--Jeff

[Nicola Ken Barozzi]

Post by Jeff Turner
....

Post by Nicola Ken Barozzi
We have a PDF-printable link on every page, IMHO it would be cool if we
had a "legacy" link that showed the site with the current table based
skin, so that older browsers have a nice viewing experience too...

..and an "XML" link, so that newer browsers can download just the page
XML and apply the stylesheet themselves.
Perhaps instead of a separate "printer friendly" link, we should have a
legacy | pdf | xml

YEAH!!!! +1000

Post by Jeff Turner
With corresponding skinconf.xml flags to allow each of these to be
switched off.

Yup, and possibly tell it to use a certain skin for that linked page :-)

[David Crossley]

Post by Jeff Turner
....

Post by Nicola Ken Barozzi
We have a PDF-printable link on every page, IMHO it would be cool if we
had a "legacy" link that showed the site with the current table based
skin, so that older browsers have a nice viewing experience too...

..and an "XML" link, so that newer browsers can download just the page
XML and apply the stylesheet themselves.

Why do we want to encourage this? I see XML/XSL as a
server-side thing only.

When you say "apply the stylesheet", i wonder "how" and
"to what".

How would a stylesheet be declared? As a hard-coded URL
pi in the XML instance? Cumbersome.

To what does their browser apply the XSL? The xdocs/faq.xml
for example, is raw content. As we know, it undergoes
various server-side transformations before the browser sees
the final product.

So why would we want to let a browser loose on raw XML?

--David

Post by Jeff Turner
Perhaps instead of a separate "printer friendly" link, we should have a
legacy | pdf | xml
With corresponding skinconf.xml flags to allow each of these to be
switched off.
--Jeff

[Jeff Turner]

Post by David Crossley

Post by Jeff Turner
....

Post by Nicola Ken Barozzi
We have a PDF-printable link on every page, IMHO it would be cool if we
had a "legacy" link that showed the site with the current table based
skin, so that older browsers have a nice viewing experience too...

..and an "XML" link, so that newer browsers can download just the page
XML and apply the stylesheet themselves.

Why do we want to encourage this?

If you "view source" on a CSS page like forrest.iguanacharlie.com, you'll see
there are lots of <div> and <span> tags whose sole purpose is to specify a CSS
type. If that's all they do, why not replace them with XML with an associated
stylesheet (CSS and/or XSLT) describing how to render the XML. I'm pretty sure
that IE 6 and Mozilla could handle an XML version of iguanacharlie today.

Probably no-one cares if Forrest sends <faq> instead of <div id="faq"> when
they render the same, but it can't hurt to send semantically rich stuff to
users who want it.

Post by David Crossley
I see XML/XSL as a server-side thing only.

XSLT stylesheets, yes..

Post by David Crossley
When you say "apply the stylesheet", i wonder "how" and
"to what".

<?xml-stylesheet href="site.css type="text/css"?>

To the output of site2xml.xsl, a theoretical equivalent of site2xhtml.xsl.

Post by David Crossley
To what does their browser apply the XSL? The xdocs/faq.xml
for example, is raw content. As we know, it undergoes
various server-side transformations before the browser sees
the final product.

It would be an interesting experiment to see if client-side XSLT could be made
to aggregate header, menu, tabs and content XML files. Perhaps lots of
document() functions. If the browser caches files, then it could speed things
up a bit, because header, tabs and menu are the same for all pages in the same
directory.

Post by David Crossley
So why would we want to let a browser loose on raw XML?

Fun, conceptual neatness and lack of better things to do.

--Jeff

Post by David Crossley
--David

[Nicola Ken Barozzi]

Post by Jeff Turner

Post by David Crossley
So why would we want to let a browser loose on raw XML?

Fun, conceptual neatness and lack of better things to do.

Actually, my view is that Cocoon essentially started as a hack to a
client problem. If all web browsers had xml+xsl+css, Cocoon wouldn't
probably have /started/.

Now, of course, Cocoon is much bigger and has become a webapp server,
even if some persist on ignorance in calling it an xml templating system.

The fact is that for a semantic web, all content should be saved and
served as conceptual xml. Thus the div tags are also "hacks".

And of course, bandwitdh need is greatly reduced, performance++, and
users can eventually apply their style or use the content as they wish:
the Web would be an information service system.

This is teh long term view, but the reality is that browsers are not all
there yet. If they ever will be totally.

So Cocoon should be used to deliver the right content to the right
client: xml+xsl+css to Mozilla and some IEs, html+css to others and do
the work for them for other clients like wap.

With conversions client side it's less bandwidth, less server load, more
clear data, easier searching, semantic web possibilities, faster browser
performance, etc.

The bottom line: nice idea, but yet impossible to realize on a single
web page style.

[Miles Elam]

Post by Jeff Turner
If you "view source" on a CSS page like forrest.iguanacharlie.com, you'll see
there are lots of <div> and <span> tags whose sole purpose is to specify a CSS
type. If that's all they do, why not replace them with XML with an associated
stylesheet (CSS and/or XSLT) describing how to render the XML. I'm pretty sure
that IE 6 and Mozilla could handle an XML version of iguanacharlie today.
Probably no-one cares if Forrest sends <faq> instead of <div id="faq"> when
they render the same, but it can't hurt to send semantically rich stuff to
users who want it.

I mostly agree. While their are some complex operations that cannot be
done client-side, having a rich semantic document sent instead of a
somewhat semantic layout-driven document makes sense to me. Adding the
processing instruction is a very simple stylesheet in the pipeline and
detection of XSLT-aware browsers isn't very hard as it's a very short list.

A warning about Mozilla's XSLT support though: it works fine for me
except for some reason the generated document ignores CSS background
colors for <body>. Really annoying when that's your only impediment to
sending XML to Mozilla. Everything else seems to work fine.

Post by Jeff Turner

Post by David Crossley
I see XML/XSL as a server-side thing only.

XSLT stylesheets, yes..

To me, it depends. XSLT has different roles. If what you are doing is
transforming from one utility schema to another utility schema (DB query
markup to DocBook for example), it has no other role than in server
side. If you have an XSLT file that transforms from DocBook to XHTML,
what is it but a layout stylesheet? It seems well suited to be sent to
the browser if it supports it.

Post by Jeff Turner

Post by David Crossley
When you say "apply the stylesheet", i wonder "how" and
"to what".

<?xml-stylesheet href="site.css type="text/css"?>
To the output of site2xml.xsl, a theoretical equivalent of site2xhtml.xsl.

This *can* work, but CSS styling is much less flexible than XSLT. As
long as everything is already in the correct structure, you don't need
to generate a dynamic ToC (for example), items that you want to
absolutely position on the page aren't constrained within another tag
and vice versa, etc. you can style XML just with CSS.

Post by Jeff Turner

Post by David Crossley
To what does their browser apply the XSL? The xdocs/faq.xml
for example, is raw content. As we know, it undergoes
various server-side transformations before the browser sees
the final product.

It would be an interesting experiment to see if client-side XSLT could be made
to aggregate header, menu, tabs and content XML files. Perhaps lots of
document() functions. If the browser caches files, then it could speed things
up a bit, because header, tabs and menu are the same for all pages in the same
directory.

Are you sure you aren't thinking of XInclude? It's possible that you
could use the document() selector with XSLT, but then you have
duplication of labor as you want to avoid that construct on server-side
where performance issues become more pronounced in volume. Two methods
== (at least) two stylesheets that must be kept in sync.

Post by Jeff Turner

Post by David Crossley
So why would we want to let a browser loose on raw XML?

Fun, conceptual neatness and lack of better things to do.

The more the client can do, the less the server has to do. For the same
reason that most clients can handle HTML so we don't need to pregenerate
an image of each page for them to layout things correctly, more of the
work that used to be concentrated on the server can be distributed out
to the clients. IE 6.x is a non-trivial number of browsers out there
and its share will only grow as it takes away from 5.x. Mozilla can
take up some of this load as well but unfortunately it's a much smaller
piece of the pie.

- Miles

[Miles Elam]

Someone had to rain on my parade. It might as well have been me.

http://forrest.iguanacharlie.com/ie5_mac.html

Standards compliant my ass! I'd love to know which standard...

- Miles

[Steven Noels]

Post by Miles Elam
Someone had to rain on my parade. It might as well have been me.
http://forrest.iguanacharlie.com/ie5_mac.html
Standards compliant my ass! I'd love to know which standard...

<quote> So I'm going to go into a dark corner and cry for a while. When
I'm done, I'm sure it will devolve into unintelligible ravings of a man
who feels betrayed. ...in a couple of days, I think I will have relaxed
enough to try to fix it (in the neutering sense).</quote>

We'll dust out that corner especially for you - don't give up! ;-)

</Steven>

[Miles Elam]

Post by Steven Noels
We'll dust out that corner especially for you - don't give up! ;-)

Oh I'm not giving up. I just need some time to cool off or else I might
"accidentally" put some JavaScript in it that detects IE5 Mac and
rewrites the main content div with "This browser has performed an
illegal request. Please upgrade your web client. Your credit card has
been processed successfully. You are now eligible to download the
newest update at http://www.mozilla.org/. The download will begin
automatically in five seconds."

And the fact that it would be done in 100% standards compliant DOM level
1 would "hypothetically" bring a smile to my face.

...or I could just count to ten, go to sleep, and let it lay for now.

Give up? Mac IE 5.x is my new arch-nemesis. Netscape 4 can breath a
sigh of relief for the time being. But I'm just going to let it lay for
now. Mark my words: Mac IE 5.x will be the client that screws up
everyone's designs in much the same role that NS4 has occupied for the
last few years.

- Miles

[Nicola Ken Barozzi]

Post by Steven Noels

Post by Miles Elam
Someone had to rain on my parade. It might as well have been me.
http://forrest.iguanacharlie.com/ie5_mac.html
Standards compliant my ass! I'd love to know which standard...

<quote> So I'm going to go into a dark corner and cry for a while. When
I'm done, I'm sure it will devolve into unintelligible ravings of a man
who feels betrayed. ...in a couple of days, I think I will have relaxed
enough to try to fix it (in the neutering sense).</quote>
We'll dust out that corner especially for you - don't give up! ;-)

Yup, and there's a toothbrush ready just for you, private Elam! ;-)

Keep it up, don't surrender!

[Robert Koberg]

Don't use em for sizes.

-Rob

-----Original Message-----
Sent: Thursday, November 14, 2002 1:11 AM
Subject: Re: [RT] Getting rid of the table-based layout
Someone had to rain on my parade. It might as well have been me.
http://forrest.iguanacharlie.com/ie5_mac.html
Standards compliant my ass! I'd love to know which standard...
- Miles

[Konstantin Piroumian]

Post by Nicola Ken Barozzi

Post by Jeff Turner

Post by Miles Elam
Hi all!
Okay, I finally had enough free time to work on a CSS version of
http://xml.apache.org/forrest/
The mockup is at http://forrest.iguanacharlie.com/

Excellent :)

Yes, my compliments :-)
It look worse in Netscape 4 though...

Looks quite good in IE 6sp1.
Though, there is a small gap in the search box (see the screenshot).

Post by Nicola Ken Barozzi

Post by Jeff Turner
Looks as good as any CSS site could.. certainly better in lynx.

Can someone please also check it in "links" with images turned on?
Better, why not put up screanshots of what it looks like in all
browsers, so we can all see it and vote knowing more of it?

Post by Jeff Turner
Any volunteers to skinify this? Otherwise I'll have a go after some
other work..

Not me ;-P but may I suggest one thing...
We have a PDF-printable link on every page, IMHO it would be cool if we
had a "legacy" link that showed the site with the current table based
skin, so that older browsers have a nice viewing experience too...

Is it really needed? Woudn't it be better to display the basic skinned
version?

Konstantin

Post by Nicola Ken Barozzi
--
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------

[Miles Elam]

Post by Nicola Ken Barozzi
Yes, my compliments :-)

Thanks!

Post by Nicola Ken Barozzi
It look worse in Netscape 4 though...

Ahem...In a manner of speaking, it's supposed to. Or rather, it's meant
to be accessible but not necessarily "pretty" in legacy browsers.

Post by Nicola Ken Barozzi
Can someone please also check it in "links" with images turned on?

How do you do this? I have links installed, but I always assumed that
it was a text-only browser.

Post by Nicola Ken Barozzi
Better, why not put up screanshots of what it looks like in all
browsers, so we can all see it and vote knowing more of it?

Great! This would help me find where certain CSS properties are
destructively interfering with layout on certain browsers.

Post by Nicola Ken Barozzi

Post by Jeff Turner
Any volunteers to skinify this? Otherwise I'll have a go after some
other work..

What's involved? I know XSLT so if I know the source schema/DTD, I
could give it a shot. But then again, the last time I said that, it
took me two weeks to get back to you. :-/

Post by Nicola Ken Barozzi
We have a PDF-printable link on every page, IMHO it would be cool if we
had a "legacy" link that showed the site with the current table based
skin, so that older browsers have a nice viewing experience too...

That should be easy. Add some text saying "Click here if you are using
Netscape 4, IE 4, etc." This takes them to a page with the following
links.

http://www.mozilla.org/
http://www.microsoft.com/ie/
http://www.netscape.com/download/
etc.

Kidding aside, with a limited amount of developer time, will you be
making the bug fixes and stylesheets changes when schemas change and
features are added? If older browsers can't get the content, I would be
the first to say that there needs to be more work done. As far as I'm
aware, the content is completely available to all browsers; They simply
don't get the pretty blues, and they get navigation on the bottom
instead of on the left. Qué malo suerte... Older computers can still
run the newest versions of Opera. Did Blizzard hold back release on
Warcraft III because it didn't run on Windows 95-era computers? Of
course the difference here is that we *are* making a version available.
It's just that while the gameplay is just as good, the graphics are
lower resolution.

It makes me think of a 70s vintage car owner complaining that leaded
gasoline isn't readily available anymore.

Post by Nicola Ken Barozzi
From personal experience I can say that stylesheets for XHTML+CSS is

much easier than for HTML+tables. Myself, I have no particular love for
the mental gymnastics necessary to keep the stylesheet well-formed while
filling in table cells. It's sad, but a big reason why I learned CSS
was so that the XSLT would be simpler and more efficient. Tables make
me sleepy.

Speaking of accessibility, I forgot to mention that I removed all
JavaScript from my mockup. It wasn't needed at all for the Google
search. And rather than rehash a discussion I'm sure took place long
before I got here, could someone send me a link as to why the breadcrumbs
were used instead of server-side inclusion? I'm not saying it was a
bad decision, I probably just don't know the history. It just worries
me that if someone doesn't have scripting enabled, they lose part of the
page navigation. That and document.write() sidesteps the DOM...

- Miles

P.S. I hope I haven't completely alienated everyone with my politics.

[Nicola Ken Barozzi]

Miles Elam wrote:

<snip/>

Post by Miles Elam
Speaking of accessibility, I forgot to mention that I removed all
JavaScript from my mockup. It wasn't needed at all for the Google
search. And rather than rehash a discussion I'm sure took place long
before I got here, could someone send me a link as to why the breadcrumbs
were used instead of server-side inclusion? I'm not saying it was a
bad decision, I probably just don't know the history. It just worries
me that if someone doesn't have scripting enabled, they lose part of the
page navigation. That and document.write() sidesteps the DOM...

There is no server-side solution just because nobody has done it, and
the javascript solution was just a quick copy-paste hack from another
page design.

In fact, we all would like to see a server-side solution, when someone
gets along to do it...

[Steven Noels]

Post by Miles Elam
P.S. I hope I haven't completely alienated everyone with my politics.

No worries - just go on with the show.

</Steven>

[Miles Elam]

Post by Stefan Bodewig
Mozilla 1.1 on Linux - both look good and render fine, the only
Fonts are bigger in Miles' mockup and I don't get any "diamonds" in
front of the headings (About, Getting involved, ...) inside the
navigation bar. Not sure, whether this is intentional.
Miles' version looks a lot better in lynx, while one could argue about
links (which tries to put the navigation bar to the left in the
"original" table design).

Yeah, I noticed when I was finishing up that the side by side had font size
differences. I figured it wasn't dire. If anyone wants it smaller, I
can do
so. It's only one or two CSS directives. ;-)

Diamonds? I don't recall any diamonds on the nav section headings. Are
you seeing them in Mozilla because I haven't on either Linux or Windows.
I mean if folks want diamonds there, it's not a big deal. I just never saw
them.

Links is also prone to link jumping: haphazard flow from one link to the
next. As a demonstration, go to http://slashdot.org/ in links and try
to login
for an extreme example. One minute you're in the nav, the next you are in
the news queue, the next you're back in the nav. The only thing that's easy
to get to is the search box.

Nowadays you can get a perfectly capable browser in an airport, a library,
and even a cell phone. I worked for a company that used Mozilla as a
rendering engine prior to serialization to a Palm device. Even Palm
devices are becoming CSS aware! XHTML+CSS would be more efficient
for these access points especially when some of them have per kilobyte and
per minute charges. The fact that links can render tables at all is
amazing,
but who can't get a graphical browser these days? The only people I can
think of who can't effectively use a graphical web browser are the visually
impaired -- and they aren't using links for text retrieval for the reasons
mentioned above.

If there is really going to be support for a text interface with all of
the bells
and whistles, why not just start hosting a gopher server?

- Miles

P.S. Once again, I apologize for my tone. I have no animosity for
anyone on
this list (quite the contrary!). All of the crappy pages out there that
remain
crappy only because of Netscape 4 compatibility or some other fringe
browser from years ago really get me down sometimes.

[Stefan Bodewig]

Post by Miles Elam
Diamonds? I don't recall any diamonds on the nav section headings.
Are you seeing them in Mozilla because I haven't on either Linux or
Windows.

Yes, with Mozilla 1.1. They are present for both Linux and MacOS X.

Post by Miles Elam
I mean if folks want diamonds there, it's not a big deal.

I don't really have an opinion here, just noticed the difference 8-)

Stefan

[Nicola Ken Barozzi]

[...]

Post by Miles Elam

Post by Stefan Bodewig
Miles' version looks a lot better in lynx, while one could argue about
links (which tries to put the navigation bar to the left in the
"original" table design).

[...]

Post by Miles Elam
Links is also prone to link jumping: haphazard flow from one link to the
next. As a demonstration, go to http://slashdot.org/ in links and try
to login
for an extreme example. One minute you're in the nav, the next you are in
the news queue, the next you're back in the nav. The only thing that's easy
to get to is the search box.
Nowadays you can get a perfectly capable browser in an airport, a library,
and even a cell phone. I worked for a company that used Mozilla as a
rendering engine prior to serialization to a Palm device. Even Palm
devices are becoming CSS aware! XHTML+CSS would be more efficient
for these access points especially when some of them have per kilobyte and
per minute charges. The fact that links can render tables at all is
amazing,
but who can't get a graphical browser these days? The only people I can
think of who can't effectively use a graphical web browser are the visually
impaired -- and they aren't using links for text retrieval for the reasons
mentioned above.
If there is really going to be support for a text interface with all of
the bells
and whistles, why not just start hosting a gopher server?

I don't care how well it looks, as long as unneded images are not shown
(spacer images and such), and that content important images are.

Post by Miles Elam
- Miles
P.S. Once again, I apologize for my tone. I have no animosity for
anyone on
this list (quite the contrary!). All of the crappy pages out there that
remain
crappy only because of Netscape 4 compatibility or some other fringe
browser from years ago really get me down sometimes.

[Nicola Ken Barozzi]

Sorry for the early mail sending, I just found out a Mozilla mail
"feature" I didn't know of ;-)

Post by Nicola Ken Barozzi
[...]

Post by Miles Elam

Post by Stefan Bodewig
Miles' version looks a lot better in lynx, while one could argue about
links (which tries to put the navigation bar to the left in the
"original" table design).

[...]

Post by Miles Elam
Links is also prone to link jumping: haphazard flow from one link to the
next. As a demonstration, go to http://slashdot.org/ in links and try
to login
for an extreme example. One minute you're in the nav, the next you are in
the news queue, the next you're back in the nav. The only thing that's easy
to get to is the search box.
Nowadays you can get a perfectly capable browser in an airport, a library,
and even a cell phone. I worked for a company that used Mozilla as a
rendering engine prior to serialization to a Palm device. Even Palm
devices are becoming CSS aware! XHTML+CSS would be more efficient
for these access points especially when some of them have per kilobyte and
per minute charges. The fact that links can render tables at all is
amazing,
but who can't get a graphical browser these days? The only people I can
think of who can't effectively use a graphical web browser are the visually
impaired -- and they aren't using links for text retrieval for the reasons
mentioned above.
If there is really going to be support for a text interface with all
of the bells
and whistles, why not just start hosting a gopher server?

I don't care how well it looks, as long as unneded images are not shown
(spacer images and such), and that content important images are.

Post by Miles Elam
- Miles
P.S. Once again, I apologize for my tone. I have no animosity for
anyone on
this list (quite the contrary!). All of the crappy pages out there
that remain
crappy only because of Netscape 4 compatibility or some other fringe
browser from years ago really get me down sometimes.

[Nicola Ken Barozzi]

[...]

Post by Miles Elam

Post by Stefan Bodewig
Miles' version looks a lot better in lynx, while one could argue about
links (which tries to put the navigation bar to the left in the
"original" table design).

[...]

Post by Miles Elam
Links is also prone to link jumping: haphazard flow from one link to the
next. As a demonstration, go to http://slashdot.org/ in links and try
to login
for an extreme example. One minute you're in the nav, the next you are in
the news queue, the next you're back in the nav. The only thing that's easy
to get to is the search box.

But some users use it, nevertheless.

Post by Miles Elam
Nowadays you can get a perfectly capable browser in an airport, a library,
and even a cell phone. I worked for a company that used Mozilla as a
rendering engine prior to serialization to a Palm device. Even Palm
devices are becoming CSS aware! XHTML+CSS would be more efficient
for these access points especially when some of them have per kilobyte and
per minute charges. The fact that links can render tables at all is
amazing,
but who can't get a graphical browser these days? The only people I can
think of who can't effectively use a graphical web browser are the visually
impaired -- and they aren't using links for text retrieval for the reasons
mentioned above.

It's not me you have to convince, it's an important user we have.
As I have already forwarded on this list, the Forrest skin will not be
used in Apache Commons till it doesn't look ok in "links".
Ok means without spacer images and such, and fully validating. No more,
no less.

Post by Miles Elam
If there is really going to be support for a text interface with all of
the bells
and whistles, why not just start hosting a gopher server?

No need to make it look that good on text browsers.

I don't care how well it looks there, as long as unneeded images are not
shown (spacer images and such), and that content important images are.

Text browsers are needed to be functional only -> let's make the skin
functional for them, no more, no less.

Post by Miles Elam
- Miles
P.S. Once again, I apologize for my tone. I have no animosity for
anyone on
this list (quite the contrary!). All of the crappy pages out there that
remain
crappy only because of Netscape 4 compatibility or some other fringe
browser from years ago really get me down sometimes.

[Jeff Turner]

On Mon, Nov 11, 2002 at 11:38:25AM +0100, Nicola Ken Barozzi wrote:
...

Post by Nicola Ken Barozzi

Post by Miles Elam
Nowadays you can get a perfectly capable browser in an airport, a library,
and even a cell phone. I worked for a company that used Mozilla as a
rendering engine prior to serialization to a Palm device. Even Palm
devices are becoming CSS aware! XHTML+CSS would be more efficient
for these access points especially when some of them have per kilobyte and
per minute charges. The fact that links can render tables at all is
amazing,
but who can't get a graphical browser these days? The only people I can
think of who can't effectively use a graphical web browser are the visually
impaired -- and they aren't using links for text retrieval for the reasons
mentioned above.

It's not me you have to convince, it's an important user we have.

No-one has to convince anyone :) Forrest provides the skins, users
decide. We can provide as many skins as we can maintain.

How about we have a docs/ directory in each skin, describing the skin's
characteristics, with screenshots on various browsers?


--Jeff

[Nicola Ken Barozzi]

Post by Jeff Turner
...

Post by Nicola Ken Barozzi

Post by Miles Elam
Nowadays you can get a perfectly capable browser in an airport, a library,
and even a cell phone. I worked for a company that used Mozilla as a
rendering engine prior to serialization to a Palm device. Even Palm
devices are becoming CSS aware! XHTML+CSS would be more efficient
for these access points especially when some of them have per kilobyte and
per minute charges. The fact that links can render tables at all is
amazing,
but who can't get a graphical browser these days? The only people I can
think of who can't effectively use a graphical web browser are the visually
impaired -- and they aren't using links for text retrieval for the reasons
mentioned above.

It's not me you have to convince, it's an important user we have.

No-one has to convince anyone :) Forrest provides the skins, users
decide. We can provide as many skins as we can maintain.

Exactly, I think we shouldn't maintain 2 visually identical skins.
And it's more about switching to current version, and for this the users
(us too as far as our site is concerned) must be convinced.

IMHO it's not too hard to convince users about a CSS design, as long as:

1) browsers don't crash
2) the content is decently visible on all browser
3) it plays nicely with text browsers (no hacks and only content-images)
4) standards compliant and validated

The proposed skin doesn't look far off, I'd be very happy to have a CSS
version of our skin.
And remember, to me "less bandwidth" is a magic word ;-)

Post by Jeff Turner
How about we have a docs/ directory in each skin, describing the skin's
characteristics, with screenshots on various browsers?

+1

[Steven Noels]

Post by Nicola Ken Barozzi
It's not me you have to convince, it's an important user we have.
As I have already forwarded on this list, the Forrest skin will not be
used in Apache Commons till it doesn't look ok in "links".
Ok means without spacer images and such, and fully validating. No more,
no less.

No user is more important than the others. Besides, we should optimize
in the direction of standards rather than try to support all user
agents. I also hope people will use Forrest not only because of its
skin(s), but because of the underlying ideas. If they want to create a
skin that is fully optimized for their preferred UA, we provide them
with the system to support that.

I believe we are all ready to adopt Miles' skin, but are only reluctant
to say so :-)

I've attached a links (0.96) and lynx (2.8.4) screenshot for those who
still need to be convinced.

If anyone can come up with a screenshot of Netscape 4 running on a Unix
platform, that would ease my mind.

</Steven>

[Nicola Ken Barozzi]

Post by Steven Noels

Post by Nicola Ken Barozzi
It's not me you have to convince, it's an important user we have.
As I have already forwarded on this list, the Forrest skin will not be
used in Apache Commons till it doesn't look ok in "links".
Ok means without spacer images and such, and fully validating. No
more, no less.

No user is more important than the others.

Which also means that every user is important.

Post by Steven Noels
Besides, we should optimize
in the direction of standards rather than try to support all user
agents. I also hope people will use Forrest not only because of its
skin(s), but because of the underlying ideas. If they want to create a
skin that is fully optimized for their preferred UA, we provide them
with the system to support that.

Not necessarily fully optimized (as I have already explained), simply
not bad looking with images turned on (again, it was the spacer gifs
basically).

Post by Steven Noels
I believe we are all ready to adopt Miles' skin, but are only reluctant
to say so :-)

I didn't hear anyone against it, which 99,9% of the time means :-)

Post by Steven Noels
I've attached a links (0.96) and lynx (2.8.4) screenshot for those who
still need to be convinced.

Good, exactly what I wanted to see.
Very nice, I like it :-)

NOTE: is it possible to have the links on the top of the page. But even
more important, is it desireable? Suggestions...

Post by Steven Noels
If anyone can come up with a screenshot of Netscape 4 running on a Unix
platform, that would ease my mind.

[Steven Noels]

Post by Nicola Ken Barozzi

Post by Steven Noels

Post by Nicola Ken Barozzi
It's not me you have to convince, it's an important user we have.
As I have already forwarded on this list, the Forrest skin will not
be used in Apache Commons till it doesn't look ok in "links".
Ok means without spacer images and such, and fully validating. No
more, no less.

No user is more important than the others.

Which also means that every user is important.

Finally somebody who understands my twisted logic :-)

Seriously: let's cater for the majority & educate the minority.

Post by Nicola Ken Barozzi

Post by Steven Noels
Besides, we should optimize in the direction of standards rather than
try to support all user agents. I also hope people will use Forrest
not only because of its skin(s), but because of the underlying ideas.
If they want to create a skin that is fully optimized for their
preferred UA, we provide them with the system to support that.

Not necessarily fully optimized (as I have already explained), simply
not bad looking with images turned on (again, it was the spacer gifs
basically).

Post by Steven Noels
I believe we are all ready to adopt Miles' skin, but are only
reluctant to say so :-)

I didn't hear anyone against it, which 99,9% of the time means :-)

Make that a :-D

</Steven>

[Miles Elam]

Post by Nicola Ken Barozzi
NOTE: is it possible to have the links on the top of the page. But
even more important, is it desireable? Suggestions...

I forgot where I read about putting navigation at the bottom of the
page. Basically it's a technique used to avoid giving users the same,
redundant information over and over again before they can get to the
main content.

However, the page is written in such a way that if anyone really wants
the navigation to come first, it can with no changes needed in the CSS.
Just move <div id="nav"/> anywhere you like as long as it remains an
immediate child of <body />.

- Miles

[Nicola Ken Barozzi]

Post by Miles Elam

Post by Nicola Ken Barozzi
NOTE: is it possible to have the links on the top of the page. But
even more important, is it desireable? Suggestions...

I forgot where I read about putting navigation at the bottom of the
page. Basically it's a technique used to avoid giving users the same,
redundant information over and over again before they can get to the
main content.

Ok, fine.

Post by Miles Elam
However, the page is written in such a way that if anyone really wants
the navigation to come first, it can with no changes needed in the CSS.
Just move <div id="nav"/> anywhere you like as long as it remains an
immediate child of <body />.

Cool, I reckoned. Anyway, I'm +1 to keep it as-is for now, let's see
what our users will have to say.

[Rodent of Unusual Size]

Post by Miles Elam
I forgot where I read about putting navigation at the bottom of the
page. Basically it's a technique used to avoid giving users the same,
redundant information over and over again before they can get to the
main content.

it's a fine line.. between keeping navigation accessible and keeping
content accessible. put the navigation at the bottom, and people
may hate having to scroll to get it. put it at the top, and people
may get annoyed that they always have to scroll past it.

my personal preference is to have it at the top, but consuming as little
real-estate -- at least vertically -- as possible. but that's just
me.

[Nick Chalko]

Post by Rodent of Unusual Size

Post by Miles Elam
I forgot where I read about putting navigation at the bottom of the
page. Basically it's a technique used to avoid giving users the same,
redundant information over and over again before they can get to the
main content.

it's a fine line.. between keeping navigation accessible and keeping
content accessible. put the navigation at the bottom, and people
may hate having to scroll to get it. put it at the top, and people
may get annoyed that they always have to scroll past it.
my personal preference is to have it at the top, but consuming as little
real-estate -- at least vertically -- as possible. but that's just
me.

At the top is good for the sighted, because afte the first time it is
easy to ignore.
For the blind it is much harded to get the reader to skip the navigation
part.
Also some people set there FONTS REALLY LARGE, and navigation chews up
all of the first screenfull.

I think the bottom is the best location for navigation on simplified
presentations..

[Robert Koberg]

Hi,

A common(?) thing to do is put a div with a link that is hidden by CSS

<div class="hideme">
<a href="#top_of_content_id">Skip Nav</a>
</div>

best,
-Rob

-----Original Message-----
Sent: Monday, November 11, 2002 3:59 PM
Subject: Re: [RT] Getting rid of the table-based layout

Post by Miles Elam
I forgot where I read about putting navigation at the bottom of the
page. Basically it's a technique used to avoid giving users the same,
redundant information over and over again before they can get to the
main content.

it's a fine line.. between keeping navigation accessible and keeping
content accessible. put the navigation at the bottom, and people
may hate having to scroll to get it. put it at the top, and people
may get annoyed that they always have to scroll past it.
my personal preference is to have it at the top, but consuming as little
real-estate -- at least vertically -- as possible. but that's just
me.

[Bruno Dumon]

Post by Steven Noels
I've attached a links (0.96) and lynx (2.8.4) screenshot for those who
still need to be convinced.

And here's one in konqueror. There's some distance between the tabs and
the navigation but otherwise it's ok. (note: if using crt screen or lcd
with other rgb ordening then mine, the fonts may look strange).

And while I was at it I also made some w3m screenshots (though I don't
use it usually)