W3C home > Mailing lists > Public > www-style@w3.org > August 2013

Re: [selectors4][naming] Naming the drag-and-drop pseudo-classes

From: Brice PARENT <briceparent@free.fr>
Date: Mon, 19 Aug 2013 16:30:55 +0200
Message-ID: <52122C1F.8050307@free.fr>
To: www-style@w3.org
Le 19/08/2013 15:10, Simon Pieters a écrit :
> FWIW, I think the other naming pattern is equally extensible in practice.
>
> For instance, let's say we wanted to introduce a new selector for
> "nearby drop target" (nevermind whether that's useful, just something
> I made up):
>
> :nearby-drop
> vs
> :drop(nearby)
>
> No problem with either of them, AFAICT.
>
> I don't have an opinion about which naming is better, but I think the
> extensibility argument for (3) isn't really a valid argument. 
I think :drop() is safer as we are sure that whatever the extensions
will be in the future, there can't be any naming collisions with any
other extisting (or custom) pseudo-classes, as we are just filtering the
drop targets instead of creating new pseudo-classes. In the spec, it
would allow the functionnality to be described somewhere else than in
the pseudo-classes (i'm not saying it should, just that it could), so
extensions to the drag-and-drop would make a new version of the
pseudo-classes section.
And as for the versions which have "drop-" as a prefix, it would make it
easy to use with an IDE's autocompletion.

As english isn't my mother language, an example would be easier for me
to explain why this is easier to use and extend :
:drop(current valid required not-empty) allows us to style elements that :
→ are drop targets
→ have something dragged upon them right now
→ are valid drop targets for the dragged element
→ are required (there need to be something droped here)
→ already have something that has been droped in
A use case for this is for example the choosing of a delivery mode in a
drag-and-drop cart cell, in which there has to be a delivery mode, but
there can't be more than one (so, a drag-and-drop equivalent to some
input type="radio").
We would have :
:drop(current valid required empty){/* style for : Cool, we needed a
delivery mode */}
:drop(current valid required not-empty){/* style for : There can't be
more than 1 delivery mode */}
which is way easier to read/write than
:drop-current:drop-valid:drop-required:drop-empty{/* style for : Cool,
we needed a delivery mode */}
:drop-current:drop-valid:drop-required:drop-not-empty{/* style for :
There can't be more than 1 delivery mode */}

For now, we could just say we have [current | not-current] and [valid |
not-valid] as values allowed in the pseudo-class' selector, and allowing
to create [required | not-required], [empty | not-empty] and any other
extensions in future versions.

Brice PARENT
Received on Monday, 19 August 2013 14:31:25 UTC

This archive was generated by hypermail 2.3.1 : Monday, 19 August 2013 14:31:26 UTC