Re: A Call for ::nth-everything

> On 11/1/11 1:24 PM, Charles Pritchard wrote:
>> They're going to be more performant than cluttering the DOM with span
>> nodes.
>
> Chances are no.  They won't.  Browsers have lots of optimizations for 
> elements already, and more importantly the ways in which elements can 
> change styles is much more limited than the nth-* setup.  This makes 
> dynamic changes to the DOM _much_ easier to handle when nth-* stuff is 
> not involved.

Yes, existing optimizations make existing practices easier.

Worst case -- and I'm sure you'll correct me if I'm wrong -- the browser 
can just create <span> elements inside the shadow dom and use all of the 
existing optimizations. This still saves authors from having those DOM 
elements cluttering the public DOM.

I'm not going to get stuck on this issue: I've gone ahead using Canvas 
with ARIA and DOM selections. I'd like to have standard alternatives in 
the future. I've had to use split(' ').join('</span><span>') in prior 
projects. It felt wrong, deep in my programming soul.

>> nth-letter is specified in the same manner as ecmascript substr.
>
> That's a completely bogus definition once you're out of the BMP.
>
> Can we please stop defining these some-western-language-only kind of 
> things?
>
These are based on byte ranges, not on western-language. I understand 
UTF8 as well as the ambigious nature of the word "word" and "letter" 
when applying them universally. There are agglutinative languages where 
a single word may comprise an entire sentence. There are scripts where 
"letter" is not so easily defined.

I'm very happy to explore those issues, and I'm sure authors using those 
languages and scripts are aware of the issues from the moment they start 
programming with ECMAScript and styling with CSS.

We can't "stop" definining these from a western-language bias. "en" is 
the standard fallback in most specs; 7-bit ascii, roman script, in a 
1-byte is the most compatible way of working with content. That's just 
historical cruft.

If you'd prefer express things in UTF-8, that's fine: WebIDL uses 
DOMString. I get that. UTF8 has excellent support nowadays.

An author working with a script where nth-letter is not 
functional/relevant is simply not going to use that selector. CSS can be 
used with media queries. Authors can restrict their use of nth-letter to 
target languages. And users can simply disable stylesheets.


-Charles

Received on Tuesday, 1 November 2011 22:29:27 UTC