Re: HTML Import for Web Designers
Hi, On 09.04.2015 10:46, Rahly wrote: I've tried searching for messages regarding duplicate custom elements, but I haven't found anything. Has this been addressed? Some reading material: https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0452.html https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0783.html Regards, Janusz Majnert Senior Software Engineer Samsung RD Institute Poland Samsung Electronics
Re: Are web components *seriously* not namespaced?
On Thu, Feb 5, 2015 at 4:12 PM, Kurt Cagle kurt.ca...@gmail.com wrote: Tab, I spend the vast majority of my time anymore in RDF-land, where namespaces actually make sense (I'm not going to argue on the XML use of namespaces - they are, agreed, ugly and complex). I know that when I've been at Balisage or any of the W3 confabs, the issue of namespaces ex-XML has been hotly debated, and many, many potential solutions proposed. Regardless, I do think that there is a very real need for namespaces in the general sense, if only as a way of being able to assert conceptual domain scope and to avoid collisions (div is the prototypical example here). Although they are ugly, they did do one thing correct, and that was to place the burden of namespace resolution and use on the final document creator. I think that namespace/prefix should be defined by the web page designer and not the component library designer. This allows end users of the component the ability to resolve the conflicts, instead of filing a bug report and a component designer has to fix all namespace resolutions. As a component designer, I'd like the ability to develop with a single panel instead of my-really-long-hopefully-not-conflicting-panel. I definitely prefer the prefix solution as it looks cleaner in the end product. document.registerElement should warn/error if the end product tag is already in use, that's for sure.
HTML Import for Web Designers
I've tried searching for messages regarding duplicate custom elements, but I haven't found anything. Has this been addressed? It seems that if a web designer wants to use multiple libraries that may register the same tag names, this would prevent the web designer from using said components until they rewrote the underlying component to rename it. It would be nice if the web designer could use components without fear of having to rewrite someone else's components. link rel=import href=toolset1/toolbar.html namespace=tool1 / link rel=import href=toolset2/toolbar.html namespace=tool2 / where if the component code calls var ele = document.registerElement(x-toolbar); it would instead create tool1-x-toolbar and tool2-x-toolbar respectively. If the designer wants to know what tag he actually received, ele.tagName ( should report the actual registered name ) Also any links in the component would get that namespace as well.
Re: PSA: publishing new WD of Gamepad on April 14
The polling model for axes has a significant advantage as I'll illustrate. Suppose you're steering a cursor of some kind in 2 dimensions. That cursor would also draw a trail/line whatever. Here's what happens if you apply this logic on events per axis: You get a staircase. Why? Because the X-axis event arrives, you move the cursor to the side, draw a line, then the Y-axis event arrives, you move the cursor up, you draw a line - a staircase. If you poll the position of all axes, this effect will not happen, you draw the correct diagonal line. In order to emulate the correct behavior with axis events, you'd have to capture all events, and keep the value of axes separately so you can draw to the appropriate position. But that can't work, because you don't have control over the polling behavior, that is, you don't know when all events are processed. This problem is broadly in the category of correlated event updates, and polling the status (of at least all axes) at a given time solves this nicely. So this functionality should not go away. In fact, it could be well argued that even if you do dispatch events (where they're primarily useful as in buttons), you should still be able to initiate the poll as for when all events are delivered (instead of having them delivered at an unopportune/uncontrolled time). The main drawback of not having events isn't that you'll have to keep the state separately. That's easy. The main problem is that because multiple events make up one final state, you can miss things, such as a button press. On Thu, Apr 9, 2015 at 11: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: - it would be consistent with the way all other input events are handled on the web platform - it is easier to program for. As it stands since there is nothing like a gamepadbuttondown event, so if you want one, you have to implement it yourself by polling the state, keeping the previous polled state, and comparing the differences looking for a previously up but currently down state and then run your handler. - browsers have a couple of important features that can only work in a user gesture, such as opening a popup window, copying to the clipboard, or - critically for games! - starting audio (or video) playback on mobile. Since the Gamepad API does not fire events, this does not integrate nicely with the existing user gesture model, and therefore currently no browser allows these features to be triggered by gamepad input. Considering the use case of a gamepad controlling a browser game on a tablet, it's pretty embarrassing that you can't play audio without resorting to some other kind of input, like regularly leaning forwards to touch the screen. This could involve significant changes to the spec, but I think it's necessary. It looks a bit like a first draft that never got reconsidered. Ashley Gullen Scirra.com On 9 April 2015 at 12:52, Arthur Barstow art.bars...@gmail.com wrote: Hi All, A new Working Draft publication of Gamepad is planned for April 14 using the following version as the basis: https://w3c.github.io/gamepad/publish/gamepad.html If anyone has any major concerns about this, please reply right away. A few notes about this spec: * This spec is now using Github https://github.com/w3c/gamepad and the ED is https://w3c.github.io/gamepad/gamepad.html. PRs are welcome and encouraged. * The permissions of the spec's now obsolete Hg repository will be set to read-only. * After Ted copies the open Bugzilla bugs to Github, the spec's Bugzilla component will be marked `Historical` and set to read-only. -Thanks, ArtB
Re: PSA: publishing new WD of Gamepad on April 14
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: - it would be consistent with the way all other input events are handled on the web platform - it is easier to program for. As it stands since there is nothing like a gamepadbuttondown event, so if you want one, you have to implement it yourself by polling the state, keeping the previous polled state, and comparing the differences looking for a previously up but currently down state and then run your handler. - browsers have a couple of important features that can only work in a user gesture, such as opening a popup window, copying to the clipboard, or - critically for games! - starting audio (or video) playback on mobile. Since the Gamepad API does not fire events, this does not integrate nicely with the existing user gesture model, and therefore currently no browser allows these features to be triggered by gamepad input. Considering the use case of a gamepad controlling a browser game on a tablet, it's pretty embarrassing that you can't play audio without resorting to some other kind of input, like regularly leaning forwards to touch the screen. This could involve significant changes to the spec, but I think it's necessary. It looks a bit like a first draft that never got reconsidered. Ashley Gullen Scirra.com On 9 April 2015 at 12:52, Arthur Barstow art.bars...@gmail.com wrote: Hi All, A new Working Draft publication of Gamepad is planned for April 14 using the following version as the basis: https://w3c.github.io/gamepad/publish/gamepad.html If anyone has any major concerns about this, please reply right away. A few notes about this spec: * This spec is now using Github https://github.com/w3c/gamepad and the ED is https://w3c.github.io/gamepad/gamepad.html. PRs are welcome and encouraged. * The permissions of the spec's now obsolete Hg repository will be set to read-only. * After Ted copies the open Bugzilla bugs to Github, the spec's Bugzilla component will be marked `Historical` and set to read-only. -Thanks, ArtB
PSA: publishing new WD of Gamepad on April 14
Hi All, A new Working Draft publication of Gamepad is planned for April 14 using the following version as the basis: https://w3c.github.io/gamepad/publish/gamepad.html If anyone has any major concerns about this, please reply right away. A few notes about this spec: * This spec is now using Github https://github.com/w3c/gamepad and the ED is https://w3c.github.io/gamepad/gamepad.html. PRs are welcome and encouraged. * The permissions of the spec's now obsolete Hg repository will be set to read-only. * After Ted copies the open Bugzilla bugs to Github, the spec's Bugzilla component will be marked `Historical` and set to read-only. -Thanks, ArtB
[gamepad] UA applied mapping cannot be escaped [Was: Re: PSA: publishing new WD of Gamepad on April 14]
On 4/9/15 8:28 AM, Florian Bösch wrote: If my reading is correct, there is no provision to escape a mapping that the UA would apply? I've observed in the past that the mappings can go quite awry. Would it be possible to offer a way toggle off mapping on a gamepad? Hi Florian - I was about to ask you to file issues for this and I see that you already beat me to it :-) (https://github.com/w3c/gamepad/issues/). -Thanks, Art
Re: Are web components *seriously* not namespaced?
On Thu, Apr 9, 2015 at 9:04 AM, Rahly hungry.ra...@gmail.com wrote: On Thu, Feb 5, 2015 at 4:12 PM, Kurt Cagle kurt.ca...@gmail.com wrote: Tab, I spend the vast majority of my time anymore in RDF-land, where namespaces actually make sense (I'm not going to argue on the XML use of namespaces - they are, agreed, ugly and complex). I know that when I've been at Balisage or any of the W3 confabs, the issue of namespaces ex-XML has been hotly debated, and many, many potential solutions proposed. Regardless, I do think that there is a very real need for namespaces in the general sense, if only as a way of being able to assert conceptual domain scope and to avoid collisions (div is the prototypical example here). Although they are ugly, they did do one thing correct, and that was to place the burden of namespace resolution and use on the final document creator. I think that namespace/prefix should be defined by the web page designer and not the component library designer. This allows end users of the component the ability to resolve the conflicts, instead of filing a bug report and a component designer has to fix all namespace resolutions. As a component designer, I'd like the ability to develop with a single panel instead of my-really-long-hopefully-not-conflicting-panel. This is a problem I would like solve as well. I definitely prefer the prefix solution as it looks cleaner in the end product. document.registerElement should warn/error if the end product tag is already in use, that's for sure. It already does: http://w3c.github.io/webcomponents/spec/custom/#dfn-definition-construction-algorithm :DG
