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

On May 15, 2010, at 12:24 PM, Brad Kemper wrote:

>> 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.

So my view on ::selection is that is is rather quaint to imagine that the visual representation of selection is something that can be adequately described via color and background-color alone. I believe Mac has been using color overlays with ink effects since the days of Quickdraw and OS 6. It is especially something distinctively different when you get to iPhone, iPads, etc. Would they be considered non-complient if ::selection was in a REC? I hope not, because I happen to think the iPad selection overlay is a better way to indicate selection, even if it was on a desktop, and I would rather be choosing the color of THAT, with its built in ink effect, or maybe even choosing the ink effect (lighten, darken, multiply, screen, etc.). 

And it does seem rather absurd to be creating hundreds or thousands of pseudo-elements if someone does a "select all" on a desktop computer, as Hyatt pointed out. There is only ever one selection at a time anyway, usually.

My view on prefixes in general is that CR is not PR, but a prefixed entity loses its prefix even though we all know further changes might be required. I think once an "official" implementation (non-beta, non-developer release) has shipped, then we cannot require the prefix to be put back on, but we can say that it is still changeable. In other words, it goes back to having the status of a prefixed property, even though the prefix is not there anymore.

Received on Monday, 17 May 2010 16:36:39 UTC