Re: [css3-lists] position:marker and compatibility with existing 'outside' implementations/content

Ugh, sorry for letting this email sit in draft form for so long.  I
was dealing with other specs.

On Fri, Aug 17, 2012 at 8:52 AM, Øyvind Stenhaug <oyvinds@opera.com> wrote:
> Since I heard feedback on marker positioning was requested, I wrote down
> some comments. I really only looked at the positioning of 'outside' markers
> with respect to what can already be specified with CSS 2.1 syntax.
>
> It's possible I have misunderstood some parts of the spec, e.g. with regards
> to the placeholder thing. If my assumptions are wrong, I think the text
> needs to be clarified.
>
> In general, the model seems quite simple, which is often a good thing.
> However, in some cases it seems all major implementations would need to
> change, which makes me wonder if there would be compat issues.

*Every* implementation is unique in how it handles outside marker
positioning once you go past the most trivial markup.  At best, I
could just specify one impl's behavior exactly, so that everyone else
had to change.  What I've done instead is specify something that's
*very close* to modern IE's behavior, because it was by far the
sanest.  IE should only have to make trivial changes which only matter
in edge cases.  Other browsers will have to change in minor or major
ways.

In particular, I identified two major models of how to handle outside
markers, split roughly 50/50 between browsers.  The one that WebKit
and FF use is the crazier one, while Opera and IE use the saner one.

However, the vast majority of lists just fall into the "trivial
markup" bucket, and are rendered the same in every browser.  I haven't
changed this.

> 1) Unless the rumored part about placeholders in css3-positioning (an inline
> text search turned up nothing) is something quite different than what
> happens with regular absolute positioning, the spec doesn't consider that an
> 'outside' list marker may cause an empty, non-zero-height linebox to be
> created (or at least cause the auto height of an empty list-item to become
> non-zero). For instance, all browsers I tried (Chrome/Firefox/IE9/Opera)
> show two list markers and green background here:
>
> <!doctype html>
> <style> li { background: green; }</style>
> <ol>
> <li></li>
> <li></li>
> </ol>

I need to revise this, as it looks like we're not using the
"placeholder" concept (instead just having each layout mode define how
it places abspos children).

> 2) Similarly, a big 'outside' list-style-image marker can affect the height
> of an existing linebox. E.g. add list-style-image: url(/* URL to a
> 100px*100px image*/) to the above case (and optionally some text in the LIs)
> - no browser allows the images to overlap.

This is good to know.  I'll edit this in.

> 3) Given the above, it seems basing the block axis position on the 'inside'
> position (= immediately before the list-item's '::before') will cause empty
> lines to appear more often than they do in Firefox/Opera. Though maybe this
> was intentional, since "spec is similar to what IE does, because that was
> sanest" as the IRC log for 2012-08-15 states.

Yes, you will get more empty line boxes.  It's what IE does. ^_^

> 4) However, even so, the vertical alignment will be off if, for instance,
> the list-item's contents start with a block that has vertical padding and/or
> borders. Not even IE uses the hypothetical 'inside' position in this case.

Testcase?

> 5) No special attention is given to floats. For instance, here the marker
> will overlap the float (and will be a long distance away from the text that
> starts the line):
>
> <!doctype html>
> <style>
>    div {
>       float: left;
>       width: 100px;
>       height: 100px;
>       background: gray;
>       margin-right: 40px;
>    }
> </style>
> <div></div>
> <ul><li>list-item</li></ul>
>
> That doesn't happen in Firefox or Gecko, though it does in IE9 and Opera
> with Presto>=2.9 or thereabouts. Since changing, we've seen some issues
> popping up in the wild about this (e.g. on Wikipedia).

Correct, no special attention is given to floats.

~TJ

Received on Wednesday, 26 September 2012 17:46:33 UTC