- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Sun, 29 May 2011 20:55:13 -0700
- To: Brad Kemper <brad.kemper@gmail.com>
- Cc: www-style list <www-style@w3.org>
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? >> 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. You shouldn't have multiple candidates - that text was just there to specify what happens when you *do* accidentally specify more than one. 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. > 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? 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. > 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 actually starts to sound more like a Region thing, where you're reflowing an element into another place. That should be doable, but it's also more complex than you strictly need here. I'll go ahead and just spec position:marker for now. ~TJ
Received on Monday, 30 May 2011 03:56:01 UTC