[Standards-JIG] Re: XHTML further simplification

Byron Ellacott bje at apnic.net
Thu Sep 23 23:27:38 UTC 2004


Peter Saint-Andre wrote:
> In article <4152654A.90906 at apnic.net>, Byron Ellacott <bje at apnic.net> 
> wrote:
>>Either way, it's not a bug in Gecko that is causing the apparently 
>>incorrect rendering.  It's a faulty assumption about how lists are 
>>rendered that's causing unexpected but correct results.  See my other 
>>post. :)
> Rendering by browsers aside (I tested with Firefox, Safari, and IE), the 
> question remains: do we or do we not include <div/> in our recommended 
> profile? It seems that some browsers incorrectly render the examples I 
> marked up (I've been somewhat depending on browsers to correctly render 
> the XHTML+CSS1 examples in the JEP), but that should not affect what we 
> recommend.

Do you or do you not consider it important for XHTML-IM messages to 
include the ability to mark up a section, or block, as it were, of a 
message as having a particular style, whether that style is 
"padding-left: 5%" or "color: blue; font-style: italic" ?

If the answer to that is "yes," you will find it easier overall to allow 
nested blocks, since that will avoid problems trying to apply a 
particular style to a number of elements and discovering that they don't 
always work out exactly how you'd expected.

If the answer is "no," you can get rid of the <div/> element because you 
don't need to divide your messages up into discreet blocks.

(You may also consider asking yourself if an XHTML-IM needs lists, too, 
since lists are the only element in the XHTML-IM recommended set that 
have default properties for {margin,padding}-left, but I apologise in 
advance for any cans of worms I may have just opened.)

The problem can be worked around by having a stylesheet applied to 
XHTML-IM messages which includes:

     li, ol {
         margin-left: 40px;
         padding-left: 0;
         -moz-padding-start: 0;
     }

For a full explanation of why this works, read on below my signature. 
If you don't care about the internals of the various browsers, don't 
bother. :)

-- 
bje

The Gecko rendering is making the assumption that the content of an 
<ol/> element doesn't include the numbering.  "padding-left" is applied 
to the content as seen by Gecko, so when you use "padding-left" on a 
number of elements to line them up, the part of the list that lines up 
is the list entries proper, not their numbering.

In CSS2.1, this /is/ the correct behaviour, since the <li> content is 
the principal box, and the marker box is optional.  Positional styling 
is applied to the principal box, with marker boxes being placed relative 
to that box.  See http://www.w3.org/TR/CSS21/generate.html#q10.

Opera is doing the exact same thing; the padding in the second example 
is being applied to the <li/> contents, not the marker box.  However, in 
the case of Opera, an <ol/> element is styled with a default of 
"margin-left: 40px."  If you explicitly set "margin-left: 0" for all 
ordered lists, you will get both <div/> and non-<div/> sections looking 
the same - the same way the non-<div/> section renders in Gecko.

Konqueror's default style sheet, however, includes "padding-left: 40px" 
for <ol/> and <li/>.  I asked a co-worker to load up my test page in 
Safari, and it appears WebKit does the same thing, so I surmise that 
this isn't changed between the two.

Note that this is all about CSS2.1.  Opera, WebKit, KHTML and Gecko are 
all CSS2.1 renderers.  IE is somewhat in between.  The text of the CSS1 
spec is a little vague about this, but expected behaviour is for a CSS1 
renderer to behave in the same way as a CSS2.1 renderer in this case, 
which is what IE does.



More information about the Standards mailing list