Re: SEUL: Re: Web Site Prototype

[Ian Bicking <bickiia@earlham.edu>]

> >I think it also might rely too heavily on stylesheets.  It would be
> >nice if you could change the stylesheet and change the look for the
> >entire site, but I don't think that's even possible in a theoretical
> >way -- stylesheets can only change the look of individual elements,
> >not the structure of the elements.  Without changing the structure
> >of the elements you can't really change the look.  XSL/XSLT is one 
> >possible way to do this, but I've only heard bad things about that...
> >anyway, maybe Zope would also offer a way to abstract the look more
> >completely.

I'd like to reemphasize this.  Stylesheets aren't enough to change
the look for the site.  The abstraction they provide isn't terribly
useful, because a higher level of abstraction is necessary.  Most
concretely, you can't rearrange the elements of a table with
stylesheets (I don't even know if you can do it with XSL), and
that is necessary even for fairly simple changes in layout.

Well, that's not to say stylesheets aren't useful.  But a 
stylesheet as something seperate from the HTML representation of
the page doesn't provide a lot of power.

> >Also, the stylesheet means another file needs to be retrieved in
> >order to render the page.  Inline stylesheets (via <style></style>)
> >mean more maintenance, but are advantageous for rendering.  The
> >maintenance would be fixed if we were using something that
> >abstracted the look, since it could add the style in as well.
> >
> Actually, a stylesheet (i.e., a CSS file) is only retrieved once for an
> entire site, regardless of where it is referenced.  If you use inline
> stylesheets, then the browser has to load (and parse) the stylesheet with
> every page it loads.  (not to mention it is terrible maintenance-wise.)

I guess the overhead depends on how people use the site.  If they are
accessing individual pages sporatically, then the seperate file can
make a difference, since it stay in the cache.  The biggest problem
is that nothing at all renders until it is retrieved, instead of the
partial rendering that occurs when you have inlined images.

In my own surfing I find the latency and unreliability of HTTP
connections to be far worse than the actual size of the page.
Reducing the number of HTTP requests would, I think, make the
page load faster than having smaller individual files.  Either
way we're talking about a few K at most, not much compared to 
the size of pictures.

The maintenance shouldn't be a problem if we aren't writing straight
HTML.  If we do write straight HTML then we're dooming ourselves
to horrible maintence problems anyway.  If we aren't, then inlining
the stylesheet information is very easy.  It does make the source
a little more messy, though.


> >Stylesheet support is also really spotty.  My own experience
> >using stylesheets has hardly made me love them -- they can refine
> >the look quite nicely, and as long as it's a refinement it doesn't
> >matter if everyone doesn't get to see it.  But table widths and
> >the sort seem a bit extreme to put in the stylesheet, especially
> >because they relate to icons and other things used in the page,
> >which needn't otherwise be tied to the stylesheet.  I think at
> >this point -- and for the foreseeable future -- stylesheets should
> >not play an essential role in the page.
>
> Actually, the styles that I am using in the prototypes style sheet are
> supported by at least Netscape 4.05 and later, and Internet Explorer 4.0
> and later.  I've been very careful not to use any style element that is not
> supported by both browsers.

I think that version 4.05/4.0 are much to recent to consider them a
lowest denomonator for the basic rendering.  Versions 3 *do* support
all of the table stuff, as well as quite a bit of other functionality.
They *can* render decently, but that's not certain if you use 
stylesheets.  They do have some support of CSS, but certainly not
as complete as later versions.

Schools particularly will have a lot of old browsers, which are the
only appropriate thing for them to have on their old computers.  For
SEUL/edu at least this is an important consideration.

Usually it seems you can fit fixed-width images into proportional-
width tables decently, with a little compromise.


> That largely depends on how one lays out the menu--there are a number of
> ways to make a useless menu (i.e., by using frames with set heights.) and
> there are just as many ways to create a useful sidebar menu that is common
> to all pages.  I've noticed a lot of times, especially with many links, the
> bottom or top of a web document is not the best idea.

More important than the visual design is what you choose to put in
the menu.  

> >My last (hopefully constructive) criticism would be the use of
> >pixel-widths in tables as opposed to percentages.  It wastes a
> >lot of the screen space for people with higher resolutions,
> >and can make it harder to resize pages for doing multiple things
> >on the screen (when you have multiple not-overlapping windows).
> >I expect (hope) that people will be using the site like this,
> >especially if it has good HOWTOs on it.  (this is also part of
> >the issue with the menu as well.
> >I think you could just make the main table have a width of 100%, 
> >put a pixel width on the menu column, and let the rest expand as 
> >necessary.  With simple tables I haven't had much problems 
> >getting this to render properly.
> You have to be very careful how you set % widths--That's fine provided you
> don't have an image with a set pixel width as your "title".

You have to be careful, and the actual rendering isn't all it
could be, but I think it's *definately* worth it.  Having the
layout of the page not scale to the width of the browser just
isn't good design, IMHO.

> >Something that's just occured to me -- I'll be doing this in the
> >future as well -- is that titles/subtitles will render better
> >on Lynx if you place <center></center> around them instead of
> >using table-based or stylesheet-based centering (which Lynx will
> >ignore).  (Lynx is also a place where menus can be annoying)
> 
> Use of the center tag within a table, especially when one can utilize <th>,
> can get to be annoying--it adds more html code into the page that a browser
> has to render.

Tables have the potential to seriously slow down the browser's
rendering, but I don't imagine <center> would do this.  It is a
little extra code, but hopefully we can abstract that so that
original representation of the pages that we use (before any
processing) doesn't have to include it.

> The biggest problem is where do we want to stop?  Do we want to design a
> page that is just text--so that it will totally work with lynx? or do we
> want to help ease the task of maintaining the site?

I think it would be useful to have a straight text version of most
pages, for printing, slow computers/connections, and text browsers.
That's something that depends a lot on what we do in the way of
processing the pages, and doesn't really need to be done right
away.

But I don't think it should be a problem to maintain.  As long
as we have a decent preprocessing system -- something that is
*essential* for maintenance -- then the complexity of the HTML
doesn't have to relate to maintenance.

-- 
Ian Bicking         / 4869 N. Talman Ave. Apt. G, Chicago, IL 60625
bickiia@earlham.edu / http://www.cs.earlham.edu/~bickiia