Re: A Call for ::nth-everything

> On 11/1/11 9:30 PM, Charles Pritchard wrote:
>>> Doing that from script is actually easier, because you don't have to,
>>> for every dynamic change to the DOM, check whether it happens to be in
>>> the region you're interested in. Especially if you, the author, happen
>>> to know that region is completely static. That's something the browser
>>> _never_ knows.
>>
>> I don't understand the demonstration you're describing.
>>
>> Is it using substr/slice and join of span and associating a class?
>
> I'm not sure I understand the question.
>
> My point is that if you as the page author know your effect is scoped 
> to a small part of the DOM, then even if your effect is expensive to 
> set up there changes to all other parts of the DOM incur no cost 
> whatsoever.
>
> But the browser has no way to know such things a priori.  The best it 
> can do is guess based on the structure of selectors and whatnot.  It's 
> not a particularly easy problem.  Furthermore, even if the browser 
> guesses right checking whether mutations happen to affect the content 
> that you may be styling can end up xpensive.

Sure, authors risk slowness when using CSS.

Most of the mistakes I've seen have been over-specifying selectors in 
their css file, leading to a very bloating CSS file (and some slightly 
more bloated rendering -- most of it gets optimized out).

>
>> The difficulty I'm having is in roles: I don't know when you're talking
>> about an author vs. an implementer when you say "Doing that from script
>> is actually easier".
>
> In some cases, it is possible for an author to implement an effect in 
> script and have it perform better than a similar effect implemented by 
> the UA.  This happens because of asymmetrical information: the author 
> has a lot more information about what sort of edge cases they do or do 
> not care about than the UA does.

Thanks for clarifying. I absolutely understand that position.

Authors can perform better than the UA with Canvas as well. These


>> I'm all for being pragmatic. I don't understand why you are labelling
>> this as something that would be "purposefully-broken".
>
> Because this involves strictly more performance hit, as far as I can 
> see, than things that UAs are _already_ leaving purposefully broken?
>
> Heck, even ::first-letter is broken in some UAs (e.g. Gecko) when some 
> dynamic changes are involved.

Oh, I need to catch up on that reading to see what areas were 
purposefully broken or unimplemented.

Would using content replacement techniques help with the situation? 
Something like this, to create an anonymous box:

::first-letter { display: none; } /* incomplete */
::first-letter:before { content "A"; }
<span>An example</span>

I'm not well versed in what has and hasn't been implemented in these 
parts of the spec. I'll follow-up on them so I can speak with some idea 
about the non-BMP issues.


>> CSS has an amazing replaced/generated content spec.
>
> The CSS 2.1 one, or the CSS3 one?  No one implements the latter, and 
> implementations of the former are somewhat buggy and inconsistent....

At this point, CSS is a lot like HTML -- a living standard.

Large swaths of the spec are not implemented, some concepts are widely 
implemented.
I suppose the spec is quite a bit more amazing than the reality of 
implementations.

Still, the implementations with the spec provide for some precedent I 
believe I can build on.


>> Wouldn't you agree that this is presentational markup:
>> <div><span>H</span><span>e</span><span>y</span></div>
>>
>> Whereas this is a bit easier on everyone:
>> <div>Hey</div>
>>
>> With the first, I can nth-child, with the second, I could nth-letter.
>
> Sure.  I appreciate the use cases here.  What I'm not certain of are 
> that the use cases are sufficiently prevalent to merit the complexity 
> this will introduce....  Maybe I'm overestimating the complexity, of 
> course.

The first example also comes up with <altGlyph> in SVG. SVG provides for 
transforms on it, I think.

I'm not experienced with the <altGlyph> element, but I think that's what 
happens, and if it is, it'd be nice move that shared issue into CSS and 
out of SVG and HTML.

I can't speak to complexity nor prevalence but it does seem to be a 
shared SVG-HTML readability issue.


-Charles

Received on Wednesday, 2 November 2011 04:02:04 UTC