Re: WebIDL Plans
On 4/12/15 2:44 AM, Anne van Kesteren wrote: On Fri, Apr 10, 2015 at 2:53 PM, Yves Lafon yla...@w3.org wrote: We are planning to move WebIDL forward to REC, here is the plan to achieve that: Who is we? Apparently this wasn't even discussed with the editors. I consider Yves' posting [1] as a followup to a related started at the end of last year [2]. Naturally, feedback on [1] is welcome from all (Boris, Cameron, Everyone). -Thanks, ArtB [1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0078.html [2] https://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0515.html
Re: Mozilla and the Shadow DOM
On Wed, Apr 8, 2015 at 9:56 AM, Hayato Ito hay...@chromium.org wrote: At the same time, however, I still have a concern, Do developers really need such a fine-grained control? Is it too early optimization, isn't? There has been pretty clear feedback from e.g. Ember that not exposing the primitives but rather a package of primitives is what stopped them from adopting the technology. And this is a recurring theme whenever we package various features together. It's why https://extensiblewebmanifesto.org/ was written up. And although that has been cited as support for Web Components, it seems quite clear in hindsight that the initial Web Components proposal did not go far enough. For example, in the past, event.path() filtered out a node if it's in an (open) shadow tree, however, I changed it because developers gave us the feedback that they want to see a node even if it's in a shadow tree. Right, which is why I think we should not have event retargeting by default. It makes sense for closed and future isolated trees, but not for open. Also making event.path and event.target use a different model is reminiscent of the originalTarget hack from XBL. -- https://annevankesteren.nl/
Re: [clipops][editing] document.execCommand('copy', false, 'some data') ?
On Sat, Apr 11, 2015 at 8:16 PM, Aryeh Gregor a...@aryeh.name wrote:
element.onclick = function(){
document.execCommand('copy', false, 'foo');
}
Is this really copying?
As in an operation that places some data on the system clipboard, yes ;)
but I see your point of view.
I think a new function for set clipboard
contents to specified value would make more sense than overloading
execCommand(copy) to mean something more than the standard
text-editor meaning of copy. Besides, execCommand() is awful and we
should prefer other APIs when possible.
So.. are you suggesting something like
window.Clipboard.setData('text/plain', 'foo') ?
-Hallvord
Re: [clipops][editing] document.execCommand('copy', false, 'some data') ?
On Mon, Apr 13, 2015 at 3:18 PM, Hallvord Reiar Michaelsen Steen
hst...@mozilla.com wrote:
So.. are you suggesting something like
window.Clipboard.setData('text/plain', 'foo') ?
Maybe. I don't know what a good name would be.
Re: PSA: publishing new WD of Gamepad on April 14
On Thu, Apr 9, 2015 at 5:15 PM, Ashley Gullen ash...@scirra.com wrote: Why doesn't the Gamepad API fire events for button pushes or axis movements? For example when pressing a mouse button or moving the mouse the browser fires mousedown and mousemove. The Gamepad API however requires you to passively poll the state regularly (probably in rAF) and look for changes yourself. Why does it not fire events like gamepadbuttondown or gamepadaxischange? This would have a few advantages: Hi Ashley, We've talked about this at length, and Firefox even includes a prototype implementation of button and axismove events (about:config, search for dom.gamepad.non_standard_events.enabled), but I just don't have the time to spec them out usefully right now and I'd like to finish up spec'ing the already-interoperably-implemented set of stuff that's in the spec right now. Once we get that out the door we can work on useful additions like events. There's a wiki page[2] that already has a list of such useful additions. -Ted 2. https://www.w3.org/wiki/Webapps/GamepadFeatures
