Re: [css3-lists] Published as WD!

On May 27, 2011, at 4:36 PM, Tab Atkins Jr. wrote:

>>>> • 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".

I thought "static position" was where they would be if they were 'position:static', i.e. somewhere else in this case.

>>> 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.

It is not so much that I am confused, as it is that it is not as straightforward as it could be. This can make it harder in general for authors to easily grasp how it works. I understand that you are using 'display:marker' to be something like 'display:none' when the candidate is chosen to push its text into the marker. That seems much more convoluted than just using the 'content' property as you do in all other markers.

>> 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. 

That just seems unnecessarily limiting. I understand that the text must be in the document but you want to style it like a full-fledged marker. But why not give it the same power with regard to adding a colon or parentheses, or an arrow glyph pointing into it, or any other number of things that the content property allows on the others. 

What is the computed value of 'content' when using 'display:marker'? is it an empty string (or 'normal', or whatever the initial value for content is), or is it the text of the 'display:marker' element? And if I change to '::marker { content:"foo"; } is that text get replaced by "foo", or does "foo" win out?

It is a level of indirection that causes confusion and is harder to learn than if you just used the 'content' property to pull in the content. The other forms of marker all use 'content' as a centrally important aspect of how they work, and it makes they powerful and easy to understand, so why not use 'content' for pulling in document content for markers too? Is there any reason to NOT have the full power of combining the document content with other glyphs and text?

> 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.

That may be a little better. You still have a bit of a fallback problem though, as it prevents the author from choosing position values for the candidates that were not advanced into actual markers. But a '::marker' rule can still be written to, can't it? So you still have two rules; one for setting 'position:marker' and one for styling the '::marker' separately. f they have competing styles, which one wins?

With my version's concept, you could write something like this:

li::marker { content: "→ " first-scoped("b") ":"; font-weight: normal; }
li b { color: red; }
li::marker i { color: green; font-weight: bold; }

and this markup:

<li><b>102.51.31<i>b</i></b> In accordance with section <b>103</b>, bla bla</li>
<li><b>102.51.31<i>c</i></b> yada yada</li>

And end up with something like this:

→ 102.51.31b: In accordance with section 103, bla bla
→ 102.51.31c: yada yada

...in which only the ::marker rule styles the marker text and the only thing red is "103", because the first B of line is no longer part of the LI content.

Since the B element would still exist inside the marker, it would still receive the general styling of bold, unless overridden as in the example. But it wouldn't be in the primary box of the LI any more, and wouldn't get LI B styles. 

I think this is unambiguous and much easier to understand, and more in line with your other ::marker concepts. Even 'position:marker' is not as clear and simple. (I'm not tied to the name, "first-scoped()", "scoped-descendant()", "select-within()", or whatever.)

> 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).

I didn't realize until this e-mail that you were only taking the text before, and not the whole element (or at least its contents including children). I definitely think that text-alone is not enough.