Re: W3C Core Styles

Todd,
I'm referring to this in the composition nodule:

A, ABBR, ADDRESS, BDO, BLOCKQUOTE, BODY, BUTTON, CITE, CODE, DD, 
DEL, DFN, 
DIV, DL, DT, EM, FIELDSET, FORM, H1, H2, H3, H4, H5, H6, IFRAME, IMG,
INS, 
KBD, 
LABEL, LI, OBJECT, OL, P, Q, SAMP, SMALL, SPAN, STRONG, SUB, SUP, UL, 
VAR,  
APPLET, B, BIG, CENTER, DIR, FONT, HR, I, MENU, PRE, S, STRIKE, TT, 
U	{ 
	height: auto; 
	margin-top: 0; 
	margin-bottom: 0; 
	padding-top: 0; 
	padding-bottom: 0; 
	border-top: 0; 
	border-bottom: 0; 
	vertical-align: baseline; 
	} 

At first glance it seemed to me that the margin and padding properties
might be what's being interpreted wrongly, and I can't see why these
need to be declared on these elements at all in a basic core style
sheet. (I confess I was wrong to refer to them as positioning
properties--that's just intuitive.) I think it's fair to assume these
are browser default values.

However, I just commented out this section of the style sheet and it
didn't solve the problems in the Netscape rendering so it will take a
little more fiddling to figure out what's happening. I'll let you know
when I do.

Gayle Kidder

Todd Fahrner wrote:
> 
> Thus spake Gayle Kidder:
> 
> > Todd--
> > How about leaving out the troublesome positioning properties on block
> > elements that will inherit properly from the parent? I'm not sure what
> > the use is of including positioning on such elements as EM and STRONG
> > anyway, as leaving them to default positioning should render them
> > correctly.
> 
> I'm not sure what you're talking about here. Can you quote from the CSS in
> question?
> 
> I do not attempt to turn inline content elements like EM and STRONG into
> block display types, nor vice versa - no implementation supports this
> anyway. Neither do I use any of the CSS-P ("positioning") properties, with
> the lone exception of the "visibility" property on HR.
> 
> __________________
> Todd Fahrner
> mailto:fahrner@pobox.com

Received on Monday, 16 February 1998 10:27:35 UTC