You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Miles Elam <mi...@geekspeak.org> on 2002/11/11 02:26:33 UTC
Re: [RT] Getting rid of the table-based layout
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 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