You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Steven Noels <st...@outerthought.org> on 2002/10/28 21:28:28 UTC
Re: [RT] Getting rid of the table-based layout
Miles Elam wrote:
> But then again, this is all sophostry and rhetoric without something to
> look at or back it up with. So, getting to my point, I got bored today
> and made a mockup of http://xml.apache.org/cocoon/ in XHTML 1.0 Strict.
>
> http://cocoon.iguanacharlie.com/
>
> I hope this illustrates my point of view. Sure, it could use some
> tweaking (I just whipped it out), but it validates, looks pretty good
> for braille readers, looks pretty good for good browsers, and any
> browser should be able to get the content (including Mosaic holdouts who
> can't handle tables). Wasn't this the point of XHTML? Wasn't this the
> point of CSS?
Hm. Hmmmm. Why don't you give a shot at http://xml.apache.org/forrest/,
the slightly more complicated skin we will be using on Forrestized
Apache sites - such as xml.apache.org?
> I'm sorry if I'm starting another fight, but seeing non-standard pages
> on ASF sites has been paining me for some time. But rather than just
> complain, I'm trying an alternative and seeing how many people sigh.
> Given this, is it still worth avoiding CSS? (A hell of a lot easier to
> write XSLT for XHTML to be sure.)
>
> I was also going to convert the GIFs to PNGs, but I'm quite sure that
> would've had me lynched before long because they most certainly don't
> show up in old browsers. Now pardon me while I duck the incoming bullets.
Nice work, I must admit. Lean and mean code - but we should check on
older browsers - I'll be trying this with my rusty NS 4.07 on Linux.
We could use some helping hands over at Forrest to finish our skins.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
Re: [RT] Getting rid of the table-based layout
Posted by Miles Elam <mi...@geekspeak.org>.
Steven Noels wrote:
> Miles Elam wrote:
>
>> But then again, this is all sophostry and rhetoric without something
>> to look at or back it up with. So, getting to my point, I got bored
>> today and made a mockup of http://xml.apache.org/cocoon/ in XHTML 1.0
>> Strict.
>>
>> http://cocoon.iguanacharlie.com/
>>
>> I hope this illustrates my point of view. Sure, it could use some
>> tweaking (I just whipped it out), but it validates, looks pretty good
>> for braille readers, looks pretty good for good browsers, and any
>> browser should be able to get the content (including Mosaic holdouts
>> who can't handle tables). Wasn't this the point of XHTML? Wasn't
>> this the point of CSS?
>
>
> Hm. Hmmmm. Why don't you give a shot at
> http://xml.apache.org/forrest/, the slightly more complicated skin we
> will be using on Forrestized Apache sites - such as xml.apache.org?
How much margin do I have? Those tabs have rounded edges. Does the
page have to be pixel for pixel? Are squared edges okay as an
alternate? Can the tabs be made a uniform width?
Other than those questions, doesn't seem too tough. The rounded edges
mean that I have to use images of course. Nevermind. Not a big deal.
It's not like the page doesn't have logos et al.
I have a radio show to do tonight, but I'll try to get to it soon.
> Nice work, I must admit. Lean and mean code - but we should check on
> older browsers - I'll be trying this with my rusty NS 4.07 on Linux.
I would think that it would look more bland, but definitely readable in
NS 4.07. Since NS4 doesn't support the @import CSS directive, it
doesn't even know there's CSS basically. What you end up with is a page
with header tags and paragraphs (akin to 1995 pages) that look pretty
good in Lynx (and by association, readers for the visually-impaired).
But then again, that's the question I wanted to make: how much do
people really care about the aesthetics vs. just the content when using
two generation old browsers? Content is 100% available for all, layout
is minimal for old, and layout is like a magazine for new.
> We could use some helping hands over at Forrest to finish our skins.
I have to admit, I have my hands full with my radio show website for the
short term. I was scrapping all the cruft in exchange for a 100%
standards compliant and accessibility compliant website.
It's...um...taking a while as I un-learn all of my old HTML skills.
Then again, I procrastinate a lot. We'll see. I can't promise, but
working on Apache pages is definitely up there in my book of reasons to
procrastinate on my own site. ;-)
- Miles
Re: [RT] Getting rid of the table-based layout
Posted by David Crossley <cr...@indexgeo.com.au>.
Tony Collen wrote:
> Steven Noels wrote:
<snip/>
> > We could use some helping hands over at Forrest to finish our skins.
>
> Where do I sign up? :)
http://xml.apache.org/forrest/
and send subscribe email to:
forrest-dev-subscribe<at>xml.apache.org
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Getting rid of the table-based layout
Posted by Steven Noels <st...@outerthought.org>.
Miles Elam wrote:
> P.S. I hope I haven't completely alienated everyone with my politics.
No worries - just go on with the show.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
Re: [RT] Getting rid of the table-based layout
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 11 Nov 2002, Miles Elam <mi...@geekspeak.org> wrote:
> 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.
> 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
Re: [RT] Getting rid of the table-based layout
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sorry for the early mail sending, I just found out a Mozilla mail
"feature" I didn't know of ;-)
Nicola Ken Barozzi wrote:
>
> Miles Elam wrote:
>
>> Stefan Bodewig wrote:
>>
>
> [...]
>
>>> 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).
>>
>
> [...]
>
>> 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.
>
>> - 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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Getting rid of the table-based layout
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Miles Elam wrote:
> Stefan Bodewig wrote:
>
[...]
>> 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).
[...]
> 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.
> - 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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Getting rid of the table-based layout
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote:
> On Mon, Nov 11, 2002 at 11:38:25AM +0100, Nicola Ken Barozzi wrote:
> ...
>
>>>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 ;-)
> How about we have a docs/ directory in each skin, describing the skin's
> characteristics, with screenshots on various browsers?
+1
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Getting rid of the table-based layout
Posted by Jeff Turner <je...@apache.org>.
On Mon, Nov 11, 2002 at 11:38:25AM +0100, Nicola Ken Barozzi wrote:
...
> >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
Re: [RT] Getting rid of the table-based layout
Posted by Steven Noels <st...@outerthought.org>.
Nicola Ken Barozzi wrote:
>
> Steven Noels wrote:
>
>> Nicola Ken Barozzi wrote:
>>
>>> 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.
>> 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).
>
>> 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>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
Re: [RT] Getting rid of the table-based layout
Posted by Nick Chalko <ni...@chalko.com>.
Rodent of Unusual Size wrote:
>Nicola Ken Barozzi wrote:
>
>
>>>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..
RE: [RT] Getting rid of the table-based layout
Posted by Robert Koberg <ro...@koberg.com>.
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-----
> From: Rodent of Unusual Size [mailto:Ken.Coar@Golux.Com]
> Sent: Monday, November 11, 2002 3:59 PM
> To: forrest-dev@xml.apache.org
> Subject: Re: [RT] Getting rid of the table-based layout
>
>
> Nicola Ken Barozzi wrote:
> >
> > > 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.
>
Re: [RT] Getting rid of the table-based layout
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Nicola Ken Barozzi wrote:
>
> > 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.
Re: [RT] Getting rid of the table-based layout
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Miles Elam wrote:
> Nicola Ken Barozzi wrote:
>
>> 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.
> 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.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Getting rid of the table-based layout
Posted by Miles Elam <mi...@geekspeak.org>.
Nicola Ken Barozzi wrote:
> 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
Re: [RT] Getting rid of the table-based layout
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Steven Noels wrote:
> Nicola Ken Barozzi wrote:
>
>> 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.
> 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).
> 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 :-)
> 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...
> If anyone can come up with a screenshot of Netscape 4 running on a Unix
> platform, that would ease my mind.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Getting rid of the table-based layout
Posted by Bruno Dumon <br...@outerthought.org>.
On Mon, 2002-11-11 at 13:45, Steven Noels wrote:
> 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)
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org
Re: [RT] Getting rid of the table-based layout
Posted by Steven Noels <st...@outerthought.org>.
Nicola Ken Barozzi wrote:
> 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>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
Re: [RT] Getting rid of the table-based layout
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Miles Elam wrote:
> Stefan Bodewig wrote:
>
[...]
>> 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).
[...]
> 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.
> 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.
> 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.
> - 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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Getting rid of the table-based layout
Posted by Miles Elam <mi...@geekspeak.org>.
Stefan Bodewig wrote:
>
>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).
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.
Can someone do that breadcrumb trail server-side, pleeease? ( was
Re: [RT] Getting rid of the table-based layout)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Miles Elam wrote:
<snip/>
> 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...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Getting rid of the table-based layout
Posted by Miles Elam <mi...@geekspeak.org>.
From: "Nicola Ken Barozzi" <ni...@apache.org>
>
>Yes, my compliments :-)
Thanks!
>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.
>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.
>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.
>>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. :-/
>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.
>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.
Re: [RT] Getting rid of the table-based layout
Posted by Miles Elam <mi...@geekspeak.org>.
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
Re: [RT] Getting rid of the table-based layout
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote:
> On Mon, Nov 11, 2002 at 09:00:53AM +0100, Nicola Ken Barozzi wrote:
> ....
>
>>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
YEAH!!!! +1000
> 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 :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Getting rid of the table-based layout
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote:
> On Wed, Nov 13, 2002 at 10:38:56PM +1100, David Crossley wrote:
>
>>Jeff Turner wrote:
>>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.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: [RT] Getting rid of the table-based layout
Posted by Robert Koberg <ro...@koberg.com>.
Don't use em for sizes.
-Rob
> -----Original Message-----
> From: Miles Elam [mailto:miles@geekspeak.org]
> Sent: Thursday, November 14, 2002 1:11 AM
> To: forrest-dev@xml.apache.org
> 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
>
>
Re: [RT] Getting rid of the table-based layout
Posted by Miles Elam <mi...@geekspeak.org>.
Steven Noels wrote:
> 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
Re: [RT] Getting rid of the table-based layout
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Steven Noels wrote:
> Miles Elam wrote:
>
>> 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!
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Getting rid of the table-based layout
Posted by Steven Noels <st...@outerthought.org>.
Miles Elam wrote:
> 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>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
Re: [RT] Getting rid of the table-based layout
Posted by Miles Elam <mi...@geekspeak.org>.
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
Re: [RT] Getting rid of the table-based layout
Posted by Miles Elam <mi...@geekspeak.org>.
Jeff Turner wrote:
>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.
>>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.
>>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.
>>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.
>>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
Re: [RT] Getting rid of the table-based layout
Posted by Jeff Turner <je...@apache.org>.
On Wed, Nov 13, 2002 at 10:38:56PM +1100, David Crossley wrote:
> Jeff Turner wrote:
> > Nicola Ken Barozzi wrote:
> > ....
> > > 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.
> I see XML/XSL as a server-side thing only.
XSLT stylesheets, yes..
> 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.
> 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.
> So why would we want to let a browser loose on raw XML?
Fun, conceptual neatness and lack of better things to do.
--Jeff
> --David
Re: [RT] Getting rid of the table-based layout
Posted by David Crossley <cr...@indexgeo.com.au>.
Jeff Turner wrote:
> Nicola Ken Barozzi wrote:
> ....
> > 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
> 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
Re: [RT] Getting rid of the table-based layout
Posted by Jeff Turner <je...@apache.org>.
On Mon, Nov 11, 2002 at 09:00:53AM +0100, Nicola Ken Barozzi wrote:
....
> 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
Re: [RT] Getting rid of the table-based layout
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Nicola Ken Barozzi" <ni...@apache.org>
> Jeff Turner wrote:
> > On Sun, Nov 10, 2002 at 05:26:33PM -0800, Miles Elam wrote:
> >
> >>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).
>
> > 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?
>
> > 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
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
Re: [RT] Getting rid of the table-based layout
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote:
> On Sun, Nov 10, 2002 at 05:26:33PM -0800, Miles Elam wrote:
>
>>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 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?
> 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...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Getting rid of the table-based layout
Posted by Jeff Turner <je...@apache.org>.
On Sun, Nov 10, 2002 at 05:26:33PM -0800, Miles Elam wrote:
> 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 :)
Some comparisons with the current site:
> Total size is 24,639 bytes
54k
Under half the size :) :)
> 7,190 is the HTML
12,708
> 11,549 is the printer, project and group images
> 4,659 is the CSS
2,276
> 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!
:)
...
> 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
> - Miles
>
Re: [RT] Getting rid of the table-based layout
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Robert Koberg wrote:
> Howdy,
>
>
>>-----Original Message-----
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
>
>>Robert Koberg wrote:
>>
>>>>-----Original Message-----
>>>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>>>Sent: Wednesday, November 13, 2002 5:56 AM
>>>>Robert Koberg wrote:
>>>>
>>>
> <snip/>
>
>>>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.
>
> They do that by exposing or hiding things, just like you can with CSS. They do
> not change how it works.
Ok.
>>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
>>name@domain to nameATdomain for anti spamming.
>
> 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.
>>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".
> <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...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: [RT] Getting rid of the table-based layout
Posted by Robert Koberg <ro...@koberg.com>.
Howdy,
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Robert Koberg wrote:
> >>-----Original Message-----
> >>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> >>Sent: Wednesday, November 13, 2002 5:56 AM
> >>Robert Koberg wrote:
> >>
<snip/>
> > 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.
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
> name@domain to nameATdomain for anti spamming.
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
Re: [RT] Getting rid of the table-based layout
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Robert Koberg wrote:
>>-----Original Message-----
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>Sent: Wednesday, November 13, 2002 5:56 AM
>>Robert Koberg wrote:
>>
>>>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.
>
> 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
name@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.
>>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 = 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?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: [RT] Getting rid of the table-based layout
Posted by Robert Koberg <ro...@koberg.com>.
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Wednesday, November 13, 2002 5:56 AM
> Robert Koberg wrote:
> > 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.
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
>
> But you say:
> 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
Re: [RT] Getting rid of the table-based layout
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Robert Koberg wrote:
> 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!
+1
> 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?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: [RT] Getting rid of the table-based layout
Posted by Robert Koberg <ro...@koberg.com>.
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-----
> From: David Crossley [mailto:crossley@indexgeo.com.au]
> Sent: Wednesday, November 13, 2002 3:18 AM
> To: forrest-dev@xml.apache.org
> Subject: Re: [RT] Getting rid of the table-based layout
>
>
> Steven Noels wrote:
> > Miles Elam wrote:
> >
> > > 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
>
Re: [RT] Getting rid of the table-based layout
Posted by David Crossley <cr...@indexgeo.com.au>.
Steven Noels wrote:
> Miles Elam wrote:
>
> > 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
Re: [RT] Getting rid of the table-based layout
Posted by Stefan Bodewig <bo...@apache.org>.
Miles Elam wrote:
> 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
Re: [RT] Getting rid of the table-based layout
Posted by Steven Noels <st...@outerthought.org>.
Miles Elam wrote:
> 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>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
Re: [RT] Getting rid of the table-based layout
Posted by Miles Elam <mi...@geekspeak.org>.
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.
Stuart Roebuck wrote:
> 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.
Re: [RT] Getting rid of the table-based layout
Posted by Stuart Roebuck <st...@adolos.co.uk>.
On Monday, October 28, 2002, at 08:43 pm, Tony Collen wrote:
> Steven Noels wrote:
>
>> Miles Elam wrote:
>>
>>> But then again, this is all sophostry and rhetoric without something
>>> to look at or back it up with. So, getting to my point, I got bored
>>> today and made a mockup of http://xml.apache.org/cocoon/ in XHTML
>>> 1.0 Strict.
>>>
>>> http://cocoon.iguanacharlie.com/
>>>
>>> I hope this illustrates my point of view. Sure, it could use some
>>> tweaking (I just whipped it out), but it validates, looks pretty
>>> good for braille readers, looks pretty good for good browsers, and
>>> any browser should be able to get the content (including Mosaic
>>> holdouts who can't handle tables). Wasn't this the point of XHTML?
>>> Wasn't this the point of CSS?
>>
>
> For the most part, the page degrades gracefully on NS 4.7n on Win2k.
> There's a bit of cruft that has some of the navbar images in it, but
> that might be able to get hidden from browsers that don't do CSS.
> The nice part about using CSS is that the content can appear in any
> order in the source page, but appear in a different place thanks to
> CSS-P. That way, for browsers that don't support CSS (Old Netscape,
> Lynx), text-based navigation/copyright/etc can appear lower on the
> page, letting them get to the content faster. In fancier browsers,
> the navigational text can appear anywhere on the page.
>
>>
>> Nice work, I must admit. Lean and mean code - but we should check on
>> older browsers - I'll be trying this with my rusty NS 4.07 on Linux.
>
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!
Stuart.
Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck
(Adolos)
Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD
65AF
------------------------------------------------------------------------
-
Stuart Roebuck, BSc, MBA Tel.: 0131 228 4853 / Fax.: 0870 054
8322
Managing Director
ADOLOS
<http://www.adolos.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Getting rid of the table-based layout
Posted by Tony Collen <tc...@hist.umn.edu>.
Steven Noels wrote:
> Miles Elam wrote:
>
>> But then again, this is all sophostry and rhetoric without something
>> to look at or back it up with. So, getting to my point, I got bored
>> today and made a mockup of http://xml.apache.org/cocoon/ in XHTML 1.0
>> Strict.
>>
>> http://cocoon.iguanacharlie.com/
>>
>> I hope this illustrates my point of view. Sure, it could use some
>> tweaking (I just whipped it out), but it validates, looks pretty good
>> for braille readers, looks pretty good for good browsers, and any
>> browser should be able to get the content (including Mosaic holdouts
>> who can't handle tables). Wasn't this the point of XHTML? Wasn't
>> this the point of CSS?
>
For the most part, the page degrades gracefully on NS 4.7n on Win2k.
There's a bit of cruft that has some of the navbar images in it, but
that might be able to get hidden from browsers that don't do CSS.
The nice part about using CSS is that the content can appear in any
order in the source page, but appear in a different place thanks to
CSS-P. That way, for browsers that don't support CSS (Old Netscape,
Lynx), text-based navigation/copyright/etc can appear lower on the page,
letting them get to the content faster. In fancier browsers, the
navigational text can appear anywhere on the page.
>
> Nice work, I must admit. Lean and mean code - but we should check on
> older browsers - I'll be trying this with my rusty NS 4.07 on Linux.
What's even cooler is when your 100% CSS/XHTML page contains no images,
and there's only 2 requests per page - one for the page itself and one
for the linked stylesheet. Converting a page from table-based with
<font> tags to CSS will also reduce bandwidth usage.
I spent a weekend converting Microsoft's mane page (www.microsoft.com)
from table-based to CSS-based. The table-based page was over 30KB of
HTML. I think all of my CSS and XHTML didn't top much past 7KB.
>
> We could use some helping hands over at Forrest to finish our skins.
Where do I sign up? :)
Regards,
TC
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Getting rid of the table-based layout
Posted by Robert Koberg <ro...@koberg.com>.
Hi,
I just saw this link at webstandards.org:
http://www.meryl.net/css/
"All-CSS Site Repository
CSS boring? CSS too restrictive? No way. Look, here's a collection of nearly 800
table-free CSS designs, courtesy of Meryl who is thankfully mirroring the
original archive from webnouveau.net, which has gone sadly AWOL. Admire, view
source, learn "
I clicked around a few of the sites and was too impressed but I am sure there
are a few gems in there.
We also have an updated version of our CSS site up at:
http://livesb.livestoryboard.com - feel free to use the CSS techniques
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org