Re: [css3-lists] Published as WD!

On Thu, May 26, 2011 at 10:45 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
> Overall, I like where it's going. I've started giving it a more thorough read, and here are my thoughts so far on the new bits:

Thanks for the review, Brad!


> On May 24, 2011, at 1:47 PM, Tab Atkins Jr. wrote:
>> 1. Split the 'outside' value for list-style-position into two values,
>> 'outside' and 'hanging', reflecting the two classes of outside
>> positioning that browsers actually do (Webkit and IE's behavior is
>> close to the new 'outside', while Firefox and Opera are close to the
>> new 'hanging').  'hanging' attaches the marker to the outside of the
>> text, while 'outside' attaches it to the box, and makes it draw some
>> things (like 'direction') from the parent element.
>
> • Is there any author benefit to this difference? If not, we should just pick one and let the inconsistent UAs converge on one behavior, and call it 'outside'. So far, the differences seem rather esoteric to me.

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


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


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

> • That section (6.0) seems to be mostly about giving examples to illustrate that all CSS properties, including width, text-align, padding, etc. apply to the ::marker. But the examples are not styled as examples (with the beige box, etc.). It seems like they should be. Also the sentence "Just like other generated content, markers generate a box when they're created, which has margins, border, padding, and everything else a box normally has" seems more conversational than precise. I would change it to, "Just like other generated content, markers generate a box when they're created, which can be styled with the full range of properties and values." Or something like that. If there are some properties that don't apply to ::marker, then they need to be called out, somewhere.

Sounds like a reasonable edit.  All properties apply to ::marker -
it's basically equivalent to ::before.


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


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

~TJ

Received on Friday, 27 May 2011 00:52:53 UTC