Re: list-style-position

On Fri, 12 Sep 2003, staffan.mahlen@comhem.se wrote:
>
> Ah, but why is the marker not seen as a box in its own right rather
> than a previously defined one?

Simplicity and code re-use. Although in this case, it may be required
anyway (as mentioned in my last mail, e.g.).


> To my mind the marker does have special requirements that make none of
> the other boxes fit perfectly.

So it seems.


> Why was the CSS2 display value 'marker' discarded?

Because it is redundant in the new model (regardless of what the type of
the box is, 'display' doesn't apply to '::marker' boxes).


>> The overflow comment stands on its own -- the 'overflow' property does
>> not apply, and the overflow on a marker box is always visible.
>
> This could perhaps be one example of why the marker should be a new type
> of box.

Why? It just doesn't apply. No need to define a new type of box.


> > > Would having a restriction on when the value 'outside' is actually
> > > applicable help with reducing and/or help debugging the troublesome
> > > conflicts?
> >
> > Which troublesome conflicts? I think the current spec is pretty
> > well-defined for those cases, isn't it?
>
> I was probably confusing the implementations of the rec with the text
> of the rec here.

It's only a draft, there shouldn't be any implementations. :-)


> I was referring to the float issues as well as the "hidden markers"
> issues that occur in UAs. The idea being that avoiding as many as
> possible of the cases where markers "dissappear"  would be helpful to
> the user.

I don't think there are any such cases in the usual practice, since the
marker boxes are horizontally aligned according to the line box of their
element, not the element in which they are vertically aligned, and their
parent's children will most likely have margins or padding that moves the
children's markers. So they won't overlap.


> But wouldn't the current way the marker is positioned mean that the
> marker always gets in conflict with the float since it is normally
> occupying the same space [...] ?

This is why the draft says that authors must ensure their floats have
margins. Defining it according to the content area or padding doesn't
solve this problem, it only makes it worse.


> but by making the marker occur outside the border-edge at least the
> floats nested into the principal box dissappears as an issue (or rather
> are displayed between the line and the marker, which seems more
> correct)?

Floats inside the principal box aren't an issue anyway.

Floats outside the box are less of an issue if you use the line box start
(at least the bullets will be near the text rather than on the other side
of the float).


> This would also stop markers from overwriting borders of the
> principal box without requiring explicit margin.

In practice this is a non-problem.


> It may also be more clear that line-affecting properties do not have any
> effect on the marker positioning (i believe there are issues in current
> implementations with at least text-align and text-indent).

A note will probably be added to draw attention to the fact that the line
box size and position is unaffected by 'text-align' and 'text-indent'.

Cheers,
-- 
Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 12 September 2003 04:53:03 UTC