Re: [css3-lists] Published as WD!

On Jun 9, 2011, at 12:12 PM, Tab Atkins Jr. wrote:

> On Mon, Jun 6, 2011 at 8:58 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> That is also ensured if the 'content' property pulls in the marker content instead of having it pushed in via the 'position' property, because then only the ::marker rule will style it if it is a marker; nothing else will. So for if the marker rule doesn't take effect on a particular element, it can still be styled in the traditional way with styling that would be most appropriate. In fact, if fallback is your concern (or even accidentally selecting too many elements to be the marker), then having 'content' pull in the content of the marker is even better, because it allows you to have your choice of any position value you want when the ::marker rule doesn't take effect.
>> 
>> Consider the following, in which I want to control 'position' in the marker and in the fallback:
>> 
>> ul { margin-left:0; }
>> li { margin-left: 8em; position:relative; list-style-type:none; }
>> li b:first-of-type { position:absolute; left: -8em; width:8em;  color:red; }
>> li b:first-of-type i { position: absolute; left:100%; }
>> 
>> li::marker { content: descendant-select-first("b") ": " ; position: relative;  width:5em; color:green; }
>> li::marker i { position: absolute; left:100%; }
>> 
>> <ul>
>>        <li><b>1002.1984<i>.36</i></b> Thusly, heretofore, in recompense, bla bla bla...
>> 
>> The above markup would let me have the bold item in (about?) the same place as it would be as with ::marker, for fallback in earlier UAs. It also lets me have all the italic elements align with each other, while the text to the left of them can wrap if necessary (assume wrapping at the decimal).
>> 
>> If ::marker content property works, then all the marker text is green; otherwise it is red.
> 
> I definitely don't think it's okay to have the element-tree be
> rearranged by properties.  That's a big layering violation.

Well, I'd hate to be thrown in layering prison by the layering police. Maybe they can just write me a layering ticket, and we can still have the benefits of doing it that way?  \:¬]

Or think of it as generated content that just happens to exactly match the structure and content of an existing element while also hiding or removing that element. If there is already some sort of marker box there generating content like bullets or numbers (or no content in that box, in the case of 'list-style-type:none; list-style-image:none;'), then I don't see a problem with having it pull the content into that existing box from an element within the list item. It would be extremely lightweight and simple compared to what regions does.

>> I don't think that sort of thing is possible using 'position:marker', without more extensive workarounds.
> 
> Correct.  However, using 'position:marker' on arbitrary elements is
> only useful for when you have an inline marker that you *really* want
> to position as if it were an 'outside' marker.  Until you can depend
> on this being supported, you can just live with your inline markers
> looking like an 'inside' marker; that is, just do this:
> 
> li {
>  list-style: none;
> }
> li > .marker {
>  position: marker;
>  display: inline;
>  /* more styling here */
> }
> 
> This would produce something that looks like an 'inside' marker on
> legacy browsers, but will give you a proper 'outside' marker on
> supporting ones.  This seems like an acceptable level of fallback.

Fallback wasn't the only thing my example illustrated. There is also the ability to still use whatever position you want for the marker box (author's choice of static or positioned)(if I understand you correctly, '::marker {position:static}' would essentially make it 'list-style-position:inside'),  and the ability to combine document content with other 'content:'. There is also the avoiding of confusion of what rules can style the marker if it is 'position:marker'. For instance, I'm still unclear on what happens here, in your model:

li > .marker {
 position: marker;
 color: red;
}
li::marker { color:green; }

In the first rule, is the 'position' adhered to, but the color ignored? That can be confusing. Or is the color read from both rules and then determined based on specificity and order? That can make it harder if you want styles to change when the element is successfully moved into the marker position (author has to add ' !important' to the declaration or try to increase selector specificity using longer chains of selectors). I'm not sure which it is, because I think you may have changed your model along the way  wrt this detail.

I'd rather see marker content always being handled by the 'content' property consistently, than to see 'position' (or 'display') overloaded and limiting how it can be used inside a marker area. I could probably live with 'position:marker', but it doesn't strike me as the best solution, or the most easy to casually understand, or the most versatile.

Received on Saturday, 11 June 2011 22:27:37 UTC