Re: Selectors, vendor prefixes (again...) and IE9

On May 14, 2010, at 3:38 PM, David Hyatt wrote:

> On May 14, 2010, at 3:06 PM, Daniel Glazman wrote:
> 
>> Le 14/05/10 20:30, David Hyatt a écrit :
>> 
>>> The WebKit implementation has been around forever. I am not sure exactly when I implemented it, but at the time I don't recall ::selection being labeled as "at risk", and I went to a CR spec for details on how to implement it.   CR means you can drop the vendor prefixes as far as I'm concerned.
>>> 
>>> In terms of timing it's a lot like text-shadow.  We implemented it in WebKit a long long time ago back when it was in a CR/PR spec and not labeled as being at risk.
>>> 
>>> To retroactively accuse us of being sloppy with vendor prefixes because years later the WG decided they didn't like it is unfair.
>>> 
>>> Know your history,
>> 
>> Being the original author and editor of that spec, I know it pretty
>> well, thanks. As I said previously, we have a hole in our process.
>> ::selection was dropped after a first CR. So if we want to reach future
>> interoperability on a feature that was dropped, the only real solution
>> is to go back to vendor prefixes or suffer painful comments à la "we
>> have users already relying on this".
> 
> The problem is once something is shipped with no vendor prefix, the genie is out of the bottle.  We can't then ship a new version that breaks a feature that people may have come to rely upon.  It's also not realistic to expect to wait until PR to drop the vendor prefixes.  It's also not realistic to expect the vendor to put the prefix back onto the property after shipping a version with no prefix.

I think this is a very good point, in principal. Once a feature is in CR, it no longer requires a prefix. Once that ships, the genie can't be stuffed back in the bottle. My view is that it CAN, however, be treated otherwise the same as if it were prefixed, if the CR goes back to draft. Which is to say, that it may change significantly (noting that the WG tends to maintain existing interoperable behavior).

That said, I don't think the Web would break much if ::selection went away or changed completely in a way incompatible with existing ::selection implementations.


> It's important that if ::selection is specified, that it doesn't try to dictate a model that is incompatible with the UA's selection model.  The UA needs to have the flexibility to interpret the specified properties in a way that is compatible with its model.

It already is incompatible with Webkit on iPhones. Or vice versa. On iPhones and iPads, the selection area is a translucent shape in front of the page, with what appears to be an ink effect (looks like "multiply" or "darken" in Photoshop parlance, but I'm not sure; it doesn't lighten black text, but it does darken red text). That shape can select across multiple inline elements, but becomes a single rectangle when selecting across more than one block display or table-* display box. There do not appear to be any new per-element boxes inserted around the text and above the background.

> As some have noted, WebKit has a very very different style of selection than other browsers (a model primarily motivated by the desire to match the way selection works elsewhere on OS X).  It applies to more than just text, involves gap filling in margins, etc.,

Yeah, I hate that. When that first appeared, it was a major WTF. I don't notice any other OS X app with selection behavior anywhere close to that, which may be because regular apps are built with so many boxes within boxes within boxes (most without margins), that it is an undetectable behavior.

> and does do color manipulation to ensure that the selection colors match when you both wash over animage or paint behind text.