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

Re: Header, Footer, and Sidebars

From: David Norris <kg9ae@geocities.com>
Date: Thu, 27 Nov 1997 16:01:23 -0500
To: "'W3C Style List'" <www-style@w3.org>, "Liam Quinn" <liam@htmlhelp.com>
Message-ID: <01bcfb77$9ea31860$3c009696@kg9ae.dyn.ml.org>
Shorthand is a good explanation.  A shorthand method for CSS to replace
frames.  I am not sure how to best implement the short hand, though.  There
might be a useful shorthand method for some authors.  As for me, I will use
any reliable method available.  I would say that many authors don't
understand CSS or positioning.  Many authors, I have met, don't understand
and aren't willing to learn until they are forced to learn.  They say that
their method works and they don't care if some people can't see the document
properly.  They are willing to accept that 25% or more of the viewers are
ignoring them.  This is their problem, but, I say the language could help
them a little with regard to positioning.  So far, CSS is very easy for
anyone to implement.  Positioning is slightly more complicated than the rest
of CSS.  Then again, maybe we should just ignore the stubborn authors.

I gave frames a little too much credit.  It was an interim solution,
definitely not too decent.  Anyway, I would agree that interim solutions are
crippling to progress.  People tend to slow development when there is a
method in place, even if it is a bad one.

Better visual tools are definitely needed.  Many visual tools, right now,
deal with HTML structure directly.  They afford no abstraction of the
structure.  I am appalled by the lack of thought going into the HTML tools.
Most Windows HTML tools have a BOLD button that inserts <STRONG>, an ITALIC
button that inserts <EM>, an INDENT Button that inserts <BLOCKQUOTE>, etc.
(I did not mention the <i> and <b>, I don't even talk about those.)  This
masks reality for an author that has not studied HTML.  Only now are
developers starting to add decent CSS support to their HTML tools.  They
still treat HTML incorrectly, even though CSS is supported.  I think we need
a new way to design a document.  HTML doesn't work well with old methods of
editing.  I just can't imagine what we need to fully overcome this problem.

,David Norris
World Wide Web - http://www.geocities.com/CapeCanaveral/Lab/1652/
My Home's Web - http://kg9ae.dyn.ml.org/
ICQ Universal Internet Number - 412039
E-Mail - kg9ae@geocities.com
-----Original Message-----
From: Liam Quinn <liam@htmlhelp.com>
To: 'W3C Style List' <www-style@w3.org>
Date: Thursday, November 27, 1997 12:32 AM
Subject: Re: Header, Footer, and Sidebars


>-----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 16:01:43 GMT

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