Re: Making selectors first-class citizens
On Sat, Sep 14, 2013 at 4:26 AM, Brian Kardell bkard...@gmail.com wrote: I am not really sure why you feel this way - this piece of the draft is tremendously stable, and interoperable as anything else. The decision to make it matches was old and popular. It's not just random joe schmoe doing this, it's illustrated and recommended by respected sources... For example http://docs.webplatform.org/wiki/dom/methods/matchesSelector 1) I don't think that's a respected source just yet. 2) When I search for matchesSelector on Google I get https://developer.mozilla.org/en-US/docs/Web/API/Element.matches which reflects the state of things much better. Note that the name matchesSelector has been gone from the standard for a long time now. So.. Ok to keep prefix working in all browsers, but not just add it? For the most part, isn't that just like an alias? Depends on the implementation details of the prefixed version. FWIW, I'd expect Gecko to remove support for the prefixed version. Maybe after some period of emitting warnings. We've done that successfully for a whole bunch of things. -- http://annevankesteren.nl/
Re: Making selectors first-class citizens
On Sep 14, 2013 6:07 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sat, Sep 14, 2013 at 4:26 AM, Brian Kardell bkard...@gmail.com wrote: I am not really sure why you feel this way - this piece of the draft is tremendously stable, and interoperable as anything else. The decision to make it matches was old and popular. It's not just random joe schmoe doing this, it's illustrated and recommended by respected sources... For example http://docs.webplatform.org/wiki/dom/methods/matchesSelector 1) I don't think that's a respected source just yet. 2) When I search for matchesSelector on Google I get https://developer.mozilla.org/en-US/docs/Web/API/Element.matches which reflects the state of things much better. Note that the name matchesSelector has been gone from the standard for a long time now. So.. Ok to keep prefix working in all browsers, but not just add it? For the most part, isn't that just like an alias? Depends on the implementation details of the prefixed version. FWIW, I'd expect Gecko to remove support for the prefixed version. Maybe after some period of emitting warnings. We've done that successfully for a whole bunch of things. -- http://annevankesteren.nl/ I think there may be confusion because of where in the thread i responded - it was unclear who i was responding to (multi). I pointed to web platform link because it is an example of a respected source: a) showing how to write it for forward compat b) assuming that, based on old/popular decision it would be called matches. I didnt use the moz ref because i think it is misleading in that: a) unlike a *lot* of other moz refs, it doesn't show anything regarding using it with other prefixes/unprefixing b) the state of that doc now still wouldn't be what someone referenced in a project they wrote 6 months or a year ago. My entire point is that it seems, unfortunately, in this very specific case, kind of reasonable that: A) Element.prototype.matches() has to mean what .mozMatchedSelector() means today. It shouldn't be reconsidered, repurposed or worrisome. B) Enough stuff assumes Element.prototype.matchesSelector() to cause me worry that it will prevent unprefixing. C) We could bikeshed details all day long, but why not just add both where one is an alias for the other. Then, what Anne said about dropping prefix over time becomes less troubling as the number of people who did neither and don't rev becomes vanishingly small (still, if it is easy why drop at all). Very succinctly, i am suggesting: .matchesSector be unprefixed, .matches is an alias and docs just say see matchesSelector, its an alias. And no one breaks. And we avoid this in the future by following better practices.
Re: Making selectors first-class citizens
On Sat, Sep 14, 2013 at 1:48 PM, Brian Kardell bkard...@gmail.com wrote: Very succinctly, i am suggesting: .matchesSector be unprefixed, .matches is an alias and docs just say see matchesSelector, its an alias. And no one breaks. And we avoid this in the future by following better practices. We can decide doing that if it's actually a problem in practice. We will try to ship the plan of record first before committing to a less optimal solution. -- http://annevankesteren.nl/
Re: Why the clipboard API needs copy/paste event simulation as a permission option
We've discussed enabling click-to-copy in another thread ( http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0061.html and beyond) and have agreed that it is an acceptable risk. When I started the thread, I had also mentioned requesting site-wide user permissions as an option (e.g. like the Geolocation API) but, again, it was deemed irrelevant as allowing click-to-copy out-of-the-box is now considered an acceptable risk. Generally speaking, I think what you are proposing would be so fantastic for testing purposes but that it is generally overshooting a bit for normal users. Perhaps requesting side-wide permissions would be a sufficient compromise to getting that approved, though? I'm not positive. One thing that would be nicer about pursuing such a route in the HTML5 Clipboard API world vs. the security uproar that resulted when Flash 9 allowed unprompted clipboard injection is that this could legitimately be restricted to just the site domains, thus avoiding having annoying ads from another domain injecting into your clipboard. Thoughts from others? Sincerely, James Greene On Wed, Aug 7, 2013 at 12:34 PM, James Babcock jimrand...@gmail.com wrote: Currently, the clipboard API allows Javascript to read the clipboard in response to a paste event (in most UAs, that's when the user types Ctrl+V or picks Paste from the default context menu); and it lets JS write to the clipboard in response to a copy event (when the user types Ctrl+C or picks Copy from the default context menu). Generating these events with document.execCommand is disallowed for security reasons, because of concerns about clipboard stealing and clipboard poisoning: someone might write a script that watches the clipboard for things that look like passwords and steals them, or for things that look like shell commands and replaces them with something nasty. This is a legitimate concern, but there really needs to be a way to grant pages permission to access the clipboard. To see why this is important, observe: In Google Docs, if you pick Copy or Paste from its menu or a context menu, it prompts you to install a plugin. This is a particularly conspicuous example, but it's not the only one. Anything that wants to replace the default context menu is faced with a dilemma: most browsers' default context menu has cut/copy/paste options on it, but a replacement context menu can't. Another case where it's a problem is in browser-based ssh clients, where Ctrl+C is not available as a hotkey for copy, but copy/pasting is nevertheless very important (so important, in fact, that many terminals copy to the clipboard on text-select without any keystroke at all). This is a problem for one of my side-projects (a browser-based extended terminal), and a fairly serious one, so I'd like to see this resolved; I don't want to have to include a plugin and only support one browser. (For my particular application, I would strongly prefer that the access permission not be limited to responding to input events, because I'm working in a programming model where the client page is a stub that sends DOM events and receives DOM mutations, so the state necessary to fill the clipboard, and to determine which keystrokes correspond to copy/paste events, all lives on the server side. Limiting access to times when the tab is visible and the window is focused is fine, though.)
