W3C home > Mailing lists > Public > www-style@w3.org > November 1997

Re: Header, Footer, and Sidebars

From: Liam Quinn <liam@htmlhelp.com>
Date: Thu, 27 Nov 1997 00:33:30 -0500
Message-Id: <3.0.5.32.19971127003330.009608a0@undergrad.math.uwaterloo.ca>
To: "'W3C Style List'" <www-style@w3.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 11:04 PM 26/11/97 -0500, David Norris wrote:
>    For future reference, I am well aware that HTML is not a presentation
>language.  Unless I missed something big, CSS is a presentation language. 
 I
>am very aware that HTML is designed to abstract data from presentation.  
I
>have been preaching this for over a year to would-be web authors.  It 
would
>be impossible for most or all authors in this list to ignorantly destroy 
a
>page, enough said.  Visual authoring tools are deficient and will always 
be
>such.  Visual tools narrow the author's perception when dealing with an
>abstract idea.

But the abstract idea you're talking about is HTML's structural markup.  I 
was claiming that visual authoring tools could be useful for the non-
abstract, visually-oriented task of producing a style sheet for screen or 
print media.  Visual creation of such style sheets is a natural idea, 
unlike visual HTML authoring.

>Visual tools popularly led to <em> meaning italic and <strong> meaning 
bold,
>rather than the intended meanings.

No, visual tools led to <i> meaning emphasis and <b> meaning strong 
emphasis.  I agree that visual authoring tools have had a negative impact 
on HTML, but I don't think this will necessarily be true with style sheets 
since non-aural style sheets are inherently visual.  There is no meaning 
behind font-style: italic, just a simple presentational suggestion.

Visual tools still aren't suitable for someone who doesn't understand that 
what you see isn't what others get on the Web.  CSS Positioning can be 
especially problematic for authors who don't understand this.

>Frames were a decent
>interim solution.

I disagree, but that's just my opinion.  There have been so many "interim 
solutions" that were never necessary (FONT, CENTER) and have only served 
to impede progress and deter accessibility of the Web.  If frames were a 
decent interim solution, would Alta Vista show 60159 documents containing 
the text "If you are seeing this message, you are using a frame challenged 
browser."?

>We are emerging from the dark ages and need to fix the
>errors of the past.

And we need to make sure we don't create more errors.

>2.  In my thinking.  A CSS property that creates a sidebar, head, or foot
>piece of text, exactly like a frame, would be better than simply telling 
it
>to position this block over there.

I don't understand.  You still need a way of specifying where the block 
should be positioned and what size it should be.  That's basically all 
that there is to using CSS Positioning for frames.

>A simple, frame-like property with a height,
>width, and alignment would be ideal.  Yes, this may be accomplished with
>absolute positioning, but, it may be better implemented with a property 
of
>its own.

If I'm understanding you, all that you want is a shorthand for the left, 
top, width, and height properties.  This might not be a bad idea, but I 
think as an author it's simpler and more intuitive to specify these 
properties separately.  Mixing width/height into left/top would seem to 
give a more confusing style rule than the separate rules.  Separate 
shorthands for width/height and left/top might be useful though.

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBNH0GKfP8EtNrypTwEQJdhwCg6j3xW28xdntUBXo5A/llXa6XcLgAoO8A
KXk1gM7NC1qQ3amw1mmvTHLG
=vMKu
-----END PGP SIGNATURE-----

--
Liam Quinn
Web Design Group            Enhanced Designs, Web Site Development
http://www.htmlhelp.com/    http://enhanced-designs.com/
Received on Thursday, 27 November 1997 00:32:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:53:53 GMT