Re: [css3-lists] Published as WD!

On Thu, May 26, 2011 at 11:26 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
> On May 26, 2011, at 5:52 PM, Tab Atkins Jr. wrote:
>> We need 'outside', as it plays better with mixed-direction content.
>> Fantasai says that 'hanging' is useful.  A 'hanging' marker, for
>> example, pays attention to 'text-align'.  (So does 'inside', but
>> 'hanging' doesn't mess with the alignment of the content.)
>
> Sounds like examples in the spec to show those differences and value of each would be valuable. I'm not sure that what I am imagining in my mind's eye is correct. D

I agree.  I need to put in a good example there.  Aharon has some
reasonable graphics that I'll either appropriate or use as
inspiration.

>>> • There is a note next to the description of 'outside' that says the Marker section has more to say about it. But that section doesn't seem to say anything specific about outside vs. hanging. Maybe that note could be worded less vaguely, or maybe it applies to 'hanging' also.
>>
>> It's mainly just the dir of the ::marker box.
>
> Section 6 isn't about the dir of the marker box. And as near as I can tell, it is as much about hanging as about outside. Am I wrong? It is "additional implications for the marker, described in the Marker section" that I think is vague.

Hmm.  The text about the direction of the ::marker is *supposed* to be
there in Section 6.  I don't know if I just *intended* to write it and
didn't get around to it, or what.

I'll fix that.


>>> • If you are going to say that the marker is absolutely positioned, then you should say that the containing block for it is NOT established by the nearest positioned ancestor. As I understand it, the containing block is the list item's parent for 'outside' (which seems weird, as I would have expected it to be the list item itself), and for 'hanging' is the first descendant with text or significant white space. Am I reading that right?
>>
>> Actually, that's not necessary.  The containing block is only used for
>> evaluating non-'auto' values for t/r/b/l.  As far as default markers
>> are concerned, though, all that matters is their 'auto' position.
>>
>> I would actually rather *not* muck with the containing blocks, just to
>> avoid surprises.
>
> OK, so it sounds like they have absolute positioning, but trbl are all at 'auto', and you are redefining what 'auto' means in this context. Right?

Yes.


>>> • Back to absolute positioning: Is 'the marker's "end" edge is placed against the "start" edge of the list item's parent' equivalent to 'right:100%' in LTR text? If I have '::marker { right:10px; }' or '::marker { right:auto; }' or '::marker { left:10px; }' would any of that change, and how? And assuming '::marker { top:auto; bottom:auto; }', does anything change if I set top or bottom to something else?
>>
>> If you treat the parent as the containing block for the ::marker, yes,
>> that is equivalent to 'right:100%'
>>
>> The positioning rules given there specify the "static position" of the
>> marker, which is the position that it assumes when t/r/b/l are 'auto'.
>> If you set t/r/b/l to a non-'auto' value, you'll switch over to the
>> normal positioning rules for that axis, which is based on offsets from
>> the containing block.
>
> I got it now. I think that could be worded better in the spec. Mentioning the "auto" values would be more clear than mentioning "static" position, which I see now that you do. "Static" means "non-positioned", but you say it iS positioned. The important thing about the static position is that it affects what the "auto" values mean, and I think it would be clearer if you just came out and said that as long as trbl properties have "auto" values, then it is positioned thusly. It doesn't feel like it can ever really have anything I'd call a static position if it is always positioned.

I initially talked about the "auto position", but was told to change
it to "static position", as that's the term used in 2.1 to mean "where
abspos elements go if you don't give them an explicit position".


> Hmm. If it is always positioned, what happens if I declare ::marker { position: static; }? Does it become 'list-style-position:inside'? If nothing changes, because it is always positioned, then you should probably say so in the spec. For added clarity, if nothing else.

Yes, it essentially becomes 'inside', as that's the element-tree
position of the ::marker.  The actual value of list-style-position
doesn't change, of course.


>> Hmm.  I may need to make it clearer, but that's the intention already.
>> Using an inline marker just (1) suppresses the display of the
>> element, and (2) makes the default contents of ::marker be the textual
>> contents of the element.  The ::marker then has completely control
>> over the styling, because its contents are freshly generated and
>> separate from the display:marker element.
>
> I still think that is kinda weird to do it that way. You use normal selectors to select the marker you want as a candidate, in order to give it a very special 'display' value; but if that value is successful in advancing the candidate then all other properties (other than 'display') set on the element are ignored. As is the 'display' value, actually, since that is whatever ::marker says it is (initial value 'inline-block').

The confusion here is that you're not actually using the
display:marker element.  You're using/styling the ::marker pseudo,
which happens to have the same textual contents as the inline marker.


> And you still can't add parentheses or arrow glyphs or bullets or anything to it.

True, but the intention of display:marker is that you want exactly
what you put in, you just want to be able to style it like a 'hanging'
or 'outside' marker.  (An ordinary inline element is almost treated
the same as an 'inside' marker - the only difference is whether it's
before or after ::before.)


> I would rather see it pulled in via the 'content' property instead of pushed via 'display'. No candidates, just whatever single descendant of the list item that the 'content' value pulls in via a selector. Having a mechanism to do that (grab content from a descendant to use in a pseudo element's content) might even be useful for other things too. The fallback for other 'candidates' would be better too, as they could have whatever 'display' value is desired.

Okay, slight rethink.  The entire purpose of display:marker, as I said
above, is to take an inline element and give it the same positioning
behavior as a real marker.  In all other respects, there's no
difference between using ::marker and using a real element.

What if, then, we just address the positioning issue directly?  Define
the value "position:marker", which is identical to 'absolute', but
sets the static position to the position that the nearest list-item
ancestor would put its marker?  That way there's no confusion about
which should be styled - you just position an element and style it as
you wish.

This also means that any structure in the inline marker (like a <b>,
for example) is preserved, where it's stripped in the current model
(since I only copy over the textual contents).

~TJ

Received on Friday, 27 May 2011 23:37:35 UTC