Re: [css3-lists] Published as WD!

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

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

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

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

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

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.

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.


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

Received on Friday, 27 May 2011 06:26:43 UTC