Re: [gamepad] preventing default/capturing controller
Adding a best approach to the spec is a good idea. Originally I thought that having a gamepadconnected callback (or some use of the Gamepad API) would be enough of an indicator to prevent the UA from manipulating the key presses / cursor movement. The main scenarios I'm struggling to see as a good fit for this: - The developer has a settings screen and would rather use the UA's manipulated keys within an event listener, rather than handle gamepad state in an animation frame. A separate API would probably be cleaner for developers to follow and presumably easier to implement in the UA side. - [Much more niche] There are native components around the edge of the UA which could be interacted with, Firefox on the Ouya is a great example. Should this be something which is catered for? Ideally the game would want to be in fullscreen mode and the user would have to leave fullscreen to interact with the native elements, this way the UA has a clear point to break out of the gamepad mode. I'll try and get hold of Scott Graham and see if he has any thoughts / comments.
[fyi] Early alpha announce: PubRules Checker NG
Editors - Robin created a new online pub rules checker that is now in alpha http://pubrules.jit.su/. If you have any comments about this service, please send them to spec-p...@w3.org http://lists.w3.org/Archives/Public/spec-prod/. Original Message Subject:Early alpha announce: PubRules Checker NG Resent-Date:Mon, 17 Mar 2014 16:38:20 + Resent-From:cha...@w3.org Date: Mon, 17 Mar 2014 17:38:08 +0100 From: ext Robin Berjon ro...@w3.org To: Chairs cha...@w3.org Dear chairs, I've just sent the message below to spec-prod[0] which introduces the next-generation pubrules checker that we've been working on. We invite you to bring this to the attention of your editors, and we'd be very interested in hearing feedback about it. Thanks! [0] http://lists.w3.org/Archives/Public/spec-prod/2014JanMar/0035.html === Hi, you are all, of course, familiar with your dear old best frenemy the Pubrules Checker. For a variety of reasons, the W3C team have decided to give it an overhaul in order to make it easier to maintain and to provide it with newer features over time. The new version is not yet production-ready, but it is starting to take shape and as such we would like to invite you to start using it. We would really like to make it as easy as possible for editors to get their documents published, and as such your feedback in the early stages of this new tool would be very useful. If you feel daring, you can even try to use it as your primary pubrules checker, just be sure to tell the webmaster that you used the new checker when requesting publication. You can find the new checker running here: http://pubrules.jit.su/ We naturally welcome not only feedback but also patches (well, pull requests) from the community. You can fork the code from here: https://github.com/w3c/specberus The same repository contains the issues, feel free to report any you find there (be they functional or UI): https://github.com/w3c/specberus/issues Please keep in mind that this is alpha software. Sometimes, it crashes. When that happens, the page won't disappear on you or show an error: you will just notice that the checking stops progressing (or doesn't even start). In such cases, please don't press the Run button twenty times in a row as that will just make things worse (if there are too many crashes in a short period of time, the service is just stopped until I manually restart it — obviously that won't be the case with the final deployment, this is just a temporary measure to avoid it spinning out of control while in development mode). Also note that the last checks (internal link integrity, HTML validation, CSS validation) can take more time than the other checks, especially on large documents. We plan to run this experiment for a month, starting now. Based on the number and severity of issues that surface we will formulate a timetable for the final transition from the current pubrules to the new one. We hope you enjoy the tool and tell us everything that's wrong with it! PS: For you ReSpec users out there, once this is deployed there will also be a way in ReSpec to run pubrules on your document directly, without having to generate and upload it. Stay tuned! -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [Editing] Splitting Selection API Into a Separate Specification
On Mon, Mar 17, 2014 at 1:59 PM, Robin Berjon ro...@w3.org wrote: My understanding from talking to various people is that at least part of the problem comes from the type of code that is currently deployed in the wild. An awful lot of it works around browser inconsistencies not through feature testing but through user agent switching. This means that when a given browser fixes a bug in order to become more in line with others (and presumably the spec), it actually breaks deployed code (some of which is deployed an awful lot). I don't think this is the primary issue. Most of the users of execCommand I've seen don't depend very much on specific behaviors, and only browser-switch on a few things, and this is a problem whenever browsers converge on common behavior. Generally browsers work around this by someone taking the hit and changing their behavior and dealing with a bit of interop fallout by evangelism, or in IE's case mode-switching. The major issue is that the feature is extremely complex, so it would require tons of resources invested by all the browsers to get interoperable, and this would introduce zillions of clear-cut bugs that would have to be fixed at the cost of even more resources. There just aren't enough consumers to be worth it. Sites that make non-trivial use of editing features mostly have given up and use JS libraries anyway. One suggestion has been to make at least the selection API interoperable, which seems achievable. So I'm very glad to see Ryosuke propose it here, I was about to suggest the same. Yes, this should mostly not be difficult, with a couple of exceptions (.modify and stringification come to mind). Another that I've been mulling over is to have something like contenteditable=minimal (bikeshed syntax at will). This would give you a caret with attendant keyboard motion and selection, but no ability to actually edit the content. Editing would happen by having a script listen to key events and act directly on the content itself. The hope is that not only is this a saner architecture for an editor, but it can also bypass most (possibly all, if the selection API is improved somewhat) browser bugs to do with editing. This would be possible using the beforeinput/input events that are already specced. Per spec, various standard actions like delete next character could be intercepted at a high level -- watch the beforeinput event, and if you see .command == delete cancel it and do your own thing. I don't think browsers actually implement the necessary bits for this, though. Also, it's not so hard to do this yourself with key handlers, although it might require a bit of work to get it to not be error-prone. On Mon, Mar 17, 2014 at 10:58 PM, Ryosuke Niwa rn...@apple.com wrote: I'm very pessimistic about the prospect of fixing execCommand. I think we have a much better chance of coming up with some lower-level API that JS libraries could use to build editors. Yes, especially the bits that are very hard to get right -- like wrap this list of consecutive nodes in tag X https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#wrapping-a-list-of-nodes and such. I've tried to spec some such algorithms separately in the spec (without speccing APIs for authors), but they're likely to still be buggy. Browsers mess this sort of basic operation up a lot, which is a good reason to expect authors won't get it right! We still should have execCommand specced well enough that a new browser could theoretically write a web-compatible implementation based only on the spec, but it's probably not worth the effort relative to other things. The biggest piece we're missing on the web platform today is mapping of key events to intended editing actions. e.g. how do you know that Shift+Enter should insert line break as opposed to start a new paragraph, or that Shift+Control+Left should extend selection to the beginning of the line. Relative to the difficulty of writing a full editing implementation, a JS editor implementation should be able to do this pretty easily, shouldn't it?
[Bug 25090] New: Use document's encoding for url query encoding in XHR open()
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25090 Bug ID: 25090 Summary: Use document's encoding for url query encoding in XHR open() Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: XHR Assignee: ann...@annevk.nl Reporter: sim...@opera.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org http://xhr.spec.whatwg.org/#sync-warning [[ Let parsedURL be the result of parsing url with base. ]] Given the resolution in https://www.w3.org/Bugs/Public/show_bug.cgi?id=23822 I guess we should change XHR. (WebKit/Blink already use the document's encoding for XHR.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25091] New: [imports]: Want to be used with data: URL scheme
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25091 Bug ID: 25091 Summary: [imports]: Want to be used with data: URL scheme Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: morr...@google.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 20683 Currently we cannot use (or aren't clear if we can use) data: URL. This is because the origin of data: URL isn't clearly defined. In Blink/WebKit, I believe it has its own origin. And AFAIK there is no way to do CORS request against data: URL. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25091] [imports]: Want to be used with data: URL scheme
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25091 Morrita Hajime morr...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Morrita Hajime morr...@google.com --- (In reply to Anne from comment #1) Yes there is. Per http://fetch.spec.whatwg.org/ a data URL will return a response that isn't tainted. It might take some time for everyone to get on board with this architecture but given service workers I think this is the way to go. Thanks for the feedback Anne! So based on the spec, it seems data:// URL should return the response. because it doesn't set response tainting mode and the basic fetch algorithm doesn't see CORS related flags for data: url. That means the imports spec doesn't have to take care of it. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [Editing] Splitting Selection API Into a Separate Specification
On Mon, Mar 17, 2014 at 4:59 AM, Robin Berjon ro...@w3.org wrote: On 15/03/2014 18:44 , Johannes Wilm wrote: yes btw -- where should one go to lobby in favor of the editing spec? I have been communicating with several other browser-based editor projects, and there seems to be a general interest of more communication with the browser creators and spec writers. Currently the situation is that it's so broken in all the browsers, that one needs to use a 100% javascript approach, painting the caret manually and creating a separate system for selections, to circumvent the main problems of contenteditable (for example: https://bugzilla.mozilla.org/show_bug.cgi?id=873883 ). Codemirror is a good example of that. My understanding from talking to various people is that at least part of the problem comes from the type of code that is currently deployed in the wild. An awful lot of it works around browser inconsistencies not through feature testing but through user agent switching. This means that when a given browser fixes a bug in order to become more in line with others (and presumably the spec), it actually breaks deployed code (some of which is deployed an awful lot). That is interesting. I had not heard that before, but it certainly makes sense in many cases. Some other issues, such as when joining two paragraphs by hitting backspace at the beginning of the second one leading to the two paragraphs not being merged the way one would assume by joining the contents of the two paragraphs, but instead by a number of font elements and similar being inserted, don't seem like they would be used by any current editor. It is my understanding that the reasoning behind this is just that A. there is no full and good spec on doing this, so B. everybody waits until there is one with fixing this. I've been talking with some editor developers and have heard some interesting ideas, notably from the Substance.io people. They are also some of those I have spoken to. We share a lot of the same problems as they have, but it is my understanding that they have not yet had to deal with noneditable islands or noneditable islands with editable lakes and similar items. The CKEditor on the other hand does have to deal with this, as do we. One suggestion has been to make at least the selection API interoperable, which seems achievable. So I'm very glad to see Ryosuke propose it here, I was about to suggest the same. Another that I've been mulling over is to have something like contenteditable=minimal (bikeshed syntax at will). This would give you a caret with attendant keyboard motion and selection, but no ability to actually edit the content. Editing would happen by having a script listen to key events and act directly on the content itself. The hope is that not only is this a saner architecture for an editor, but it can also bypass most (possibly all, if the selection API is improved somewhat) browser bugs to do with editing. This would certainly be an improvement. As it is now, we for example do not use contenteditable for anything else than the caret movement, so if that could be done right in all cases, that would mean a lot. Creating a javascript/contenteditable editor is not that hard, if one only has to deal with the various text formatting and adding functions. The problems starts if one has to get around bugs related to the cursor not moving correctly or not moving at all to certain places (for example between two inline non-editable objects in Firefox). Then one needs to create a fake-cursor, etc. which is a much bigger task and only has been achieved by a very few projects so far. I reckon a spec for that could be put together relatively easily. I'm still digging through Web editors' code to get a feel for how much it would actually help. If it would help, I could help organize a meeting with the various editor creators (Aloha, TinyMCE, CKEditor, Substance.io, Fidus writer, HalloJS, etc.) to discuss this. In my experience, these developers are very interested in getting in contact with the browser makers about this, and haven't always been successful in this. -- Robin Berjon - http://berjon.com/ - @robinberjon -- Johannes Wilm Fidus Writer http://www.fiduswriter.com
