W3C home > Mailing lists > Public > www-style@w3.org > December 1995

Re: comments on CSS1

From: David Seibert <seibert@hep.physics.mcgill.ca>
Date: Tue, 5 Dec 1995 16:07:41 -0500 (EST)
To: "Scott E. Preece" <preece@predator.urbana.mcd.mot.com>
Cc: HTML Style <www-style@w3.org>
Message-Id: <Pine.ULT.3.91.951205133355.24604B-100000@prism.physics.mcgill.ca>
On Tue, 5 Dec 1995, Scott E. Preece wrote:

> There are two possible conflicts:  something has requested a *lighter*
> frame than the author requested (or none) or something has requested a
> heavier frame than the author requested (or a frame when the author
> indicated none).  Moving towards the default or away from the default
> will favor the author or not, depending on the specific conflict, the
> default, and the author's specification.

Any modification of a frame from the default could be used to emphasize 
an element.  I assume that the author wants something different than the 
default, which in my experience is pretty boring to look at.  Actually, I 
would not refer to the "default", but rather to the "standard style" for 
the table in question, which might be from basic html style, the user's 
favorite style sheet, an imported style sheet, or just a style 
declaration given in the body of the document.  

How about the following rule for resolving framing conflicts in tables,  
assuming that the standard is declared before the table begins?
1) The UA should scan all elements of each row, and assign each element 
  of a given row the top and bottom frame widths that are most different 
  from the standard of all the frame declarations for the elements of 
  that row, so that all elements in any row have the same top and bottom 
  frame widths.
2) The UA should treat columns in the same manner as rows, but assign left 
  and right frame widths (instead of top and bottom).
3) If there are still framing conflicts (width, style, or color) between 
  adjacent elements of the table, the UA should examine framing 
  declarations for the adjacent elements, and again use the declaration 
  that makes the shared frame most different from the standard. 
The rules for determining "most different from standard" should be 
reasonably straightforward, and there shouldn't be too may cases where a 
shared frame is requested to be on both sides of standard, at least not 
by good authors.

One example of the use of these rules is a request for a change in frame 
properties around a specific <td> element for emphasis.  Following the 
rules above, the UA would change the frame width on the top and bottom of 
all entries in the same row, and on the sides of all entries in the same 
column, so that all elements line up properly.  It would then draw a 
special frame around the desired element if requested, while following 
the standard declaration for all other elements (except of course for 
elements with common edges), as illustrated below (for a simple increase 
in frame width).

11111111111111 1 1111111111111
22222222222222 2 2222222222222

33333333333333 3 3333333333333

44444444444444 4 4444444444444
55555555555555 5 5555555555555

This also emphasizes all other entries in the same row or column, but the 
reader's eye would naturally be drawn to the desired entry as the author 
intended, as shown below.  If the author want to emphasize the difference 
between 2 rows, he could make a table like this by specifying a different 
top and bottom frame in the <tr> element.





What do other people think of these rules?  They would add power to the 
table facility, and I can't think of any situations in which they would 
cause bad effects in the hands of a reasonably careful author.  There 
aren't many situations where an author would want an extra-thick frame 
around one element and an extra-thin frame around another in the same row 
or column.


Work: seibert@hep.physics.mcgill.ca         Home: 6420 36th Ave.
Physics Department, McGill University       Montreal, PQ, H1T 2Z5 
3600 Univ. St., Mtl., PQ, H3A 2T8, Canada   Canada
(514) 398-6496; FAX: (514) 398-3733         (514) 255-5965
Received on Tuesday, 5 December 1995 16:08:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:38 UTC