W3C home > Mailing lists > Public > www-style@w3.org > June 2011

Re: [css3-lists] Published as WD!

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 06 Jun 2011 12:03:13 +0900
Message-ID: <4DEC4371.2000206@inkedblade.net>
To: www-style@w3.org
On 05/30/2011 12:55 PM, Tab Atkins Jr. wrote:
> Sorry, whatever your mail program is doing to indent quotes is
> *completely* lost when converted to plain text.  I'll fix what I can.
>
> On Sat, May 28, 2011 at 7:56 AM, Brad Kemper<brad.kemper@gmail.com>  wrote:
>> On May 27, 2011, at 4:36 PM, Tab Atkins Jr. wrote:
>>> 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.
>
> I expect that that's the intended meaning of the term, yes.  Like I
> said, I was told to use that term; before this, I used the term "auto
> position".
>
> Fantasai, I think you were the one that asked me to change it.  Is it
> still the best term to use?

The "static position" is indeed where an element would be if it were
'position static'. The definition is used to calculate the used value
of 'auto' for the offset properties. CSS2.1 does not distinguish between
these two concepts because the point of its discussion on this topic is
to set the one to the other.

I don't know if it's the best term to use: depends how you use it.

> But here, with a positioning scheme, we can jettison the whole concept
> of "candidates".  It's just positioning.  If you position multiple
> things in the same place, well, it's your fault for doing so, and
> they'll overlap.
>
> This would just be a positioning scheme for elements, completely
> disconnected from the normal list marker.  It would typically be
> paired with "list-style-type: none;" to suppress the display of the
> ::marker.  If you don't suppress the ::marker, it'll show up and be
> positioned there as well, following normal overlap rules for abspos
> elements.
>
> This way, there's no confusion.  You have markers, and you have normal
> elements.  You can just make the normal elements piggyback on the
> marker positioning scheme if you want.

This makes sense to me. That it forces authors to style the marker-positioned
element and not ::marker is a feature, not a bug: it ensures that if the
marker-positioning doesn't take effect, you still get the correct-est styling
possible.

Tab, my only concern here is making this equivalent to abspos.
I think you should create a new positioning scheme that's similar to
abspos in how it takes the marker out-of-flow, but define the static
position / auto position / whatever to place the marker in the correct
marker place, and define the offsets to offset it from that position.
I think that'd be more reasonable than having "top: 0" float the marker
to the top of the initial containing block or something similarly silly.

Alternatively, define the offsets to work outward (rather than inward)
from the list-item box: "left: 1em" puts the left edge of the marker at
1em from the right side of the box, "right: 1em" puts the right edge of
the marker at 1em from the left side of the box... this sounds a little
crazy in plaintext, but I think if you draw out examples, it'll make
sense. ^_^

(You deal with overconstraints as usual by forcing margins to auto.)

~fantasai
Received on Monday, 6 June 2011 05:08:58 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:41 GMT