Re: [whatwg] [selectors4] drag-and-drop pseudo-classes
On Aug 14, 2012 10:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Aug 14, 2012 at 12:13 PM, Ryosuke Niwa rn...@webkit.org wrote: Yeah, and that's not compatible with how drag and drop are implemented on the Web. I know. You'll notice that I didn't suggest we somehow change to that. ^_^ However, other languages might want this kind of model, Other languages?
Re: [whatwg] [selectors4] drag-and-drop pseudo-classes
On Wed, Aug 15, 2012 at 9:12 AM, Henri Sivonen hsivo...@iki.fi wrote: On Aug 14, 2012 10:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Aug 14, 2012 at 12:13 PM, Ryosuke Niwa rn...@webkit.org wrote: Yeah, and that's not compatible with how drag and drop are implemented on the Web. I know. You'll notice that I didn't suggest we somehow change to that. ^_^ However, other languages might want this kind of model, Other languages? Anything else that might use CSS that isn't HTML on the web. ~TJ
[whatwg] [selectors4] drag-and-drop pseudo-classes
The CSSWG discussed drag-and-drop pseudo-classes today. The current proposal is to have three pseudo-classes: * One for the element representing the drop target that would receive the item if it were dropped. * One for all elements representing possible drop targets that could receive the item. * One for all elements representing drop targets that do not accept this type of item. We'd like comments on a) whether this is a correct and useful set of pseudo-elements b) what these pseudo-elements should be called, that would best (most clearly and succinctly) represent their functionality to authors using them Name sets being considered: Set A Set B Set CSet D :active-drop:drop:current-drop:active-drop :drop :can-drop:valid-drop :valid-drop :no-drop:no-drop :invalid-drop:invalid-drop Thanks~ ~fantasai
Re: [whatwg] [selectors4] drag-and-drop pseudo-classes
On Mon, Aug 13, 2012 at 9:19 PM, fantasai fantasai.li...@inkedblade.netwrote: The CSSWG discussed drag-and-drop pseudo-classes today. The current proposal is to have three pseudo-classes: * One for the element representing the drop target that would receive the item if it were dropped. * One for all elements representing possible drop targets that could receive the item. How do we find these elements? On one hand, if we're only supporting dropzone attribute, then adding new pseudo element seems unnecessary. On the other hand, I can't think of ways to detect whether an element could return false or prevents the default action on dragover/dragenter events without firing those events. - Ryosuke
Re: [whatwg] [selectors4] drag-and-drop pseudo-classes
On Mon, Aug 13, 2012 at 11:55 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Aug 13, 2012 at 9:19 PM, fantasai fantasai.li...@inkedblade.netwrote: The CSSWG discussed drag-and-drop pseudo-classes today. The current proposal is to have three pseudo-classes: * One for the element representing the drop target that would receive the item if it were dropped. * One for all elements representing possible drop targets that could receive the item. How do we find these elements? On one hand, if we're only supporting dropzone attribute, then adding new pseudo element seems unnecessary. On the other hand, I can't think of ways to detect whether an element could return false or prevents the default action on dragover/dragenter events without firing those events. Just using [dropzone], yes. We're not adding a pseudo-element, we're adding pseudo-classes. I'm not sure how we can possibly do these without pseudo-classes. Can you outline what you think it would be? We have to (a) only trigger these pseudo-classes while a drag is happening, and (b) trigger the valid/invalid distinction based on what type was declared in JS or assumed by OS-level data for the dragged thing. As well, the pseudo that matches the drop target that will be used if you dropped right now might not be expressible in pure CSS even given the above. It's probably equivalent to when you :hover it, but there are applications that basically have this functionality that work differently - for example, I think that the built-in Windows solitaire game highlight the closest drop target to the current mouse pointer, even if you're nowhere near the actual drop zone. ~TJ
Re: [whatwg] [selectors4] drag-and-drop pseudo-classes
On Tue, Aug 14, 2012 at 3:03 AM, Sebastian Zartner sebastianzart...@gmail.com wrote: * One for all elements representing possible drop targets that could receive the item. * One for all elements representing drop targets that do not accept this type of item. This sounds like these two pseudo-classes would do exactly the opposite. So why not use :not() for this case? Nope, the distinction is similar to :valid/:invalid - usually, most elements will match neither, because they're not drop targets at all, so they can't be a valid drop target *or* an invalid one. ~TJ
Re: [whatwg] [selectors4] drag-and-drop pseudo-classes
On 08/13/2012 11:55 PM, Ryosuke Niwa wrote: On Mon, Aug 13, 2012 at 9:19 PM, fantasai fantasai.li...@inkedblade.net mailto:fantasai.li...@inkedblade.net wrote: The CSSWG discussed drag-and-drop pseudo-classes today. The current proposal is to have three pseudo-classes: * One for the element representing the drop target that would receive the item if it were dropped. * One for all elements representing possible drop targets that could receive the item. How do we find these elements? On one hand, if we're only supporting dropzone attribute, then adding new pseudo element seems unnecessary. On the other hand, I can't think of ways to detect whether an element could return false or prevents the default action on dragover/dragenter events without firing those events. I don't know. I'm just going on what was asked for in the following thread. :) http://lists.w3.org/Archives/Public/www-style/2011Sep/0402.html The spec prose so far is this: http://dev.w3.org/csswg/selectors4/#drag-pseudos The definition is pretty generic; I'm happy to add details on how exactly it should work with HTML, if someone can provide them. ~fantasai
Re: [whatwg] [selectors4] drag-and-drop pseudo-classes
On 08/14/2012 03:03 AM, Sebastian Zartner wrote: * One for all elements representing possible drop targets that could receive the item. * One for all elements representing drop targets that do not accept this type of item. This sounds like these two pseudo-classes would do exactly the opposite. So why not use :not() for this case? That question was asked and answered here: http://lists.w3.org/Archives/Public/www-style/2011Sep/0417.html Apparently an invalid dropzone is one that accepts drops, but not of this type, so it's not exactly the same as :not(:valid-drop). I'm unsure if it's necessary to add at this point, but can add it and mark at-risk for the time being. ~fantasai
Re: [whatwg] [selectors4] drag-and-drop pseudo-classes
On Tue, Aug 14, 2012 at 11:04 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Mon, Aug 13, 2012 at 11:55 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Aug 13, 2012 at 9:19 PM, fantasai fantasai.li...@inkedblade.net wrote: The CSSWG discussed drag-and-drop pseudo-classes today. The current proposal is to have three pseudo-classes: * One for the element representing the drop target that would receive the item if it were dropped. * One for all elements representing possible drop targets that could receive the item. How do we find these elements? On one hand, if we're only supporting dropzone attribute, then adding new pseudo element seems unnecessary. On the other hand, I can't think of ways to detect whether an element could return false or prevents the default action on dragover/dragenter events without firing those events. Just using [dropzone], yes. We're not adding a pseudo-element, we're adding pseudo-classes. I'm not sure how we can possibly do these without pseudo-classes. Can you outline what you think it would be? I'm asking how we're supposed to implement this pseudo-classes given that the only way to know whether an element can receive the item is by firing dragenter and/or dragover events. e.g. http://dev.w3.org/csswg/selectors4/#drag-pseudos says The :valid-drop-target pseudo-class represents an element that is a possible drop target for an item that is currently being dragged in a drag-and-drop interface. How are we going to figure out whether a given element is a possible drop target for an item, when the element can dynamically decide whether to accept the item or not in dragenter/dragover events? As well, the pseudo that matches the drop target that will be used if you dropped right now might not be expressible in pure CSS even given the above. It's probably equivalent to when you :hover it, but there are applications that basically have this functionality that work differently - for example, I think that the built-in Windows solitaire game highlight the closest drop target to the current mouse pointer, even if you're nowhere near the actual drop zone. Yeah, and that's not compatible with how drag and drop are implemented on the Web. - Ryosuke
Re: [whatwg] [selectors4] drag-and-drop pseudo-classes
On Tue, Aug 14, 2012 at 12:13 PM, Ryosuke Niwa rn...@webkit.org wrote: I'm asking how we're supposed to implement this pseudo-classes given that the only way to know whether an element can receive the item is by firing dragenter and/or dragover events. e.g. No, we can know it declaratively via the dropzone attribute. That's what these will key off of in HTML. In @dropzone, you can declare the types of data that it will accept, and you know the type of the data as soon as the drag starts, so you have all the info you need. We obviously can't address dropzones that are only detectable during the dragover event. That's fine - they just won't respond to these pseudo-classes. Consider it an inducement to use the new, better model that @dropzone allows. As well, the pseudo that matches the drop target that will be used if you dropped right now might not be expressible in pure CSS even given the above. It's probably equivalent to when you :hover it, but there are applications that basically have this functionality that work differently - for example, I think that the built-in Windows solitaire game highlight the closest drop target to the current mouse pointer, even if you're nowhere near the actual drop zone. Yeah, and that's not compatible with how drag and drop are implemented on the Web. I know. You'll notice that I didn't suggest we somehow change to that. ^_^ However, other languages might want this kind of model, and we could in the future add a switch to allow this kind of behavior in HTML. My point is just that, even if you solve the other problems, you still might not be able to implement that pseudoclass in existing CSS. ~TJ
Re: [whatwg] [selectors4] drag-and-drop pseudo-classes
On Tue, Aug 14, 2012 at 12:53 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Tue, Aug 14, 2012 at 12:13 PM, Ryosuke Niwa rn...@webkit.org wrote: I'm asking how we're supposed to implement this pseudo-classes given that the only way to know whether an element can receive the item is by firing dragenter and/or dragover events. e.g. No, we can know it declaratively via the dropzone attribute. That's what these will key off of in HTML. In @dropzone, you can declare the types of data that it will accept, and you know the type of the data as soon as the drag starts, so you have all the info you need. Okay, thanks for the clarification. We obviously can't address dropzones that are only detectable during the dragover event. That's fine - they just won't respond to these pseudo-classes. Consider it an inducement to use the new, better model that @dropzone allows. I'm not sure if I'm a big fun of that idea given that I haven't seen people using dropzone attribute in wild. Have other browser vendors even implemented it yet? (We haven't prefixed it in WebKit) All in all, I feel like it's premature to build more features on top of it. - Ryosuke
