Re: [css3-lists] Published as WD!

Sorry for my late entry into this conversation!  Nice work on the Lists 
module, Tab.

The things that caught my attention on my initial complete read-throughs 
were already queried by Brad, as it happens:

On 28/05/2011 01:36, Tab Atkins Jr. wrote:
> On 27/05/2011 08:26, Brad Kemper wrote:
>> On May 26, 2011, at 5:52 PM, Tab Atkins Jr. wrote:
>>> On Thu, May 26, 2011 at 10:45 AM, Brad
>>> Kemper<brad.kemper@gmail.com>  wrote:

>>> All properties apply to ::marker - it's basically equivalent to
>>> ::before.

Really? What happens to the properties that ordinarily influence
position and flow, such as display, position, float, clear etc? Are they
merely ignored? Because it sounds like 'list-style-position' wants to
have complete control over positioning, and it's not possible eg to
float or abspos a marker.

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

I don't think I follow, but that's probably because I don't understand
why 'position' would be honoured at all; see above.

Also, from Section 6:

   # The value of ‘list-style-position’ on the marker's superior parent 
can vary the marker's directionality and the initial value of its 
‘position’ property.

Again, I don't understand the reference to the 'position' property (nor 
what is meant by "an element's initial value of its 'position' property").

(I won't comment on the "static position" discussion until I've 
understood this!)

>>>>> 3. The 'inline' value for 'list-style-type' was added,
>>>>> alongside the new (well, repurposed) 'marker' value for
>>>>> 'display'.  Using these in concert makes the first element
>>>>> with display:marker use its text contents as the marker
>>>>> value.  This is useful for documents where the list marker is
>>>>> a vital part of the content, and so must be included inline
>>>>> to ensure that it is displayed properly even when CSS is
>>>>> missing.
>>>>
>>>> I like the idea, but I think it is backwards. The way you have
>>>> it, the 'display' property has this one value that pushes the
>>>> content into a marker, but only under very limited
>>>> circumstances, and with a fallback that might not always be
>>>> appropriate. I think instead, the ::marker should pull the
>>>> content into its 'content' property (something like
>>>> 'content:select-first-within(.myMarkers)'), where it can be
>>>> combined with other images and text if desired, and where it
>>>> can have its own 'display' properties set to whatever (maybe to
>>>> 'table-cell' with some height and border and padding and
>>>> background, for example), and where there is not the idea of
>>>> candidates. Pulling it into ::marker would mean that it would
>>>> only be styled there and by inheritance, and not by anything
>>>> that selected it before it was pulled. Thus avoiding confusion
>>>> like this:
>>>>
>>>> li .myMarker { display: marker; color:red; } li::marker {
>>>> display: block; color:green; }
>>>>
>>>> I want ::marker to be what sets the properties, without having
>>>> to override the other selectors or use !important.
>>>
>>> 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').
>>
>> And you still can't add parentheses or arrow glyphs or bullets or
>> anything to it.
>>
>> 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).

I share Brad's concern that using display:marker to mean "display:none
and then magically copy the contents to a pseudo-element that then
displayed somewhere else" is unusual. (I'm not saying it's wrong or even
a bad idea (yet!); I'm just saying that it's a new model AFAIK.)

I think Brad's proposal to be able to pull content explicitly from the
document using 'content' seems more natural, and could have applications
in various places in CSS not just here. (We can do this for element
attribute content already.) However, it's also a new model and would
require a fair bit of thought. It is pretty similar to populating flows
(à la regions) as you suggest (and may therefore be more complex that we 
would like for the purposes of this module).

I also agree with your analysis that you're merely interested in moving
the would-be marker contents to a new, well-defined place in the layout.
So something like position:marker is worth considering. However, what
happens if you also specify
::marker { position: <something>; }
? See my question above.

The thing I'm concerned about with using position:marker is that until
now, 'position' hasn't been used to reshuffle contents. In CSS21, abspos
removes content from the normal flow, and relpos visually repositions
content but doesn't affect "layout". In CSS3 template positioning, the
mechanism is more akin to regions but specifically the "slots" are
defined in such a way that positioning something into them doesn't
require us to worry about rewrapping neighbouring content around the
something's new location. Under your proposal, however, you're taking
content inside of a list item and moving somewhere else, and in the case
of list-style-position:inside you're moving it elsewhere inside the same
block box and expecting neighbouring content to flow around it; that is,
you're reshuffling (a bit like using 'float').

I think we should think carefully about whether we want to extend
position in this way. Again, I'm not saying we don't; I'm just saying it
deserves some thought.

Another aspect about position:marker is that you're not so much setting
a position as setting a rôle. So I can't help but feel that this is a
bit of an abuse of the 'position' property, and that use of
display:marker might indeed be better. I would be happier with
display:marker if we could avoid getting into the "populating flows"
model by insisting that display:marker could only be used on the "first"
content of a list item, in some sense. That would seem to cover your use
cases without getting bogged down in moving content to somewhere else in
the flow.

Cheers,
Anton Prowse
prowse@moonhenge.net

Received on Sunday, 3 July 2011 09:41:20 UTC