Re: XMLHttpRequest: uppercasing method names
On 2014-08-12 17:23, Boris Zbarsky wrote: On 8/12/14, 9:26 AM, Anne van Kesteren wrote: I somewhat prefer always uppercasing, but that would require changes to XMLHttpRequest. Gecko used to have the always uppercasing behavior for XHR and people complained about it until we aligned with the current spec. I don't think we particularly want to change behavior on developers again. -Boris +1. Please keep inconsistency with the base spec (HTTP) at a minimum. Best regards, Julian
[Bug 26673] Append topDoc to exitDocs?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26673 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Anne ann...@annevk.nl --- Fixed the first paragraph. No idea how to fix the second, but that's a separate bug :-) https://github.com/whatwg/fullscreen/commit/43d2f74803e6e915d2c056d1a5960591a71a0360 -- You are receiving this mail because: You are on the CC list for the bug.
Re: User Intentions Explainer (was: List of Intentions)
Pretty good docs, Ben. I have comments mostly about Issue 2 (http://w3c.github.io/editing-explainer/#h_issue_2). As long as actions are well documented, browsers can provide defaults that will fit 90% of the *good quality* content creation requirements out there. Additionally just selection is not enough to make content editable, so contenteditable=“minimal” would have no sense for the eyes of those not participating in this group. IMHO, the following are the “minimal” features that it should provide: - Selection: UI (e.g. caret), creation (e.g. mouse) and modifications (e.g. arrows) - Focus (probably part of Selection, but it’s so hard to make it right that I’m listing it here to not stay forgotten) - Input Text (typing) - Insert New Line - Delete / Backspace - Clipboard / DnD - Undo / Redo All the above should be paired with the proper Intention events so preventDefault and customizations can happen. Once we agree on what contenteditable=“minimal” should do, the next step would be writing specs for each of the above points, in very deep details, including all possible patterns and cases (hopefully unit tests). This is to help browsers’ adoption, easier implementation and guaranteeing a common behavior everywhere, which would require less customizations to happen. The goal here is fixing editing, not disabling it altogether. Otherwise Issue 5 (http://w3c.github.io/editing-explainer/#h_issue_5) makes total sense and editing will, by default, stay broken. -- Frederico Knabben CKEditor Project Lead and CKSource Owner -- CKSource - http://cksource.com -- Follow us on: Twitter (http://twitter.com/ckeditor) | Facebook (http://www.facebook.com/ckeditor) | Google+ (https://plus.google.com/107736718646302128806) | LinkedIn (http://www.linkedin.com/company/cksource) On Friday, 5 September 2014 at 23:04, Ben Peters wrote: There is now an Editing Explainer [1] and a User Intentions Explainer [2], which should help scope the problems and help us drive forward on both areas. I haven’t done much to fine tune them yet, but please let me know if you have feedback on this split from the initial Commands Explainer document. Thanks! [1] http://w3c.github.io/editing-explainer/ [2] http://w3c.github.io/editing-explainer/commands-explainer.html On Mon, Aug 11, 2014 at 5:23 PM, Ben Peters ben.pet...@microsoft.com (mailto:ben.pet...@microsoft.com) wrote: I agree with this. We should have a single 'shape' for these events and shared terminology. I think trying to solve all of the problems in one complete spec would be too complex, but if we use an Intentions Explainer to divide the problem into manageable pieces, we can continue on our trajectory of creating these events for Selection, Clipboard, Drag and Drop, Input (aka Editing), and perhaps other user interactions. Are there objections to this approach? If not, I will begin to adapt the Commands Explainer into a more generic Intentions Explainer.
Re: User Intentions Explainer (was: List of Intentions)
On Mon, Sep 8, 2014 at 6:05 PM, Frederico Knabben f.knab...@cksource.com wrote: snip IMHO, the following are the minimal features that it should provide: - Selection: UI (e.g. caret), creation (e.g. mouse) and modifications (e.g. arrows) - Focus (probably part of Selection, but it's so hard to make it right that I'm listing it here to not stay forgotten) - Input Text (typing) - Insert New Line - Delete / Backspace If we include deletion/backspace and input text, that will then also mean merging of paragraphs (and other nodes) when the caret is at the beginning of a second paragraph and the backspace key is being hit? Last I checked that was broken for example in Safari/Chrome (converting the HTML inside the two merged paragraphs from span style= into a mix of font-tags and other outdated things). To me it's fine if inputting text/backspace is being included, as long as browser makers believe they will have the time and resources to fix the actual text editing part. That to me seems to be the most broken thing about the whole thing currently. If they on the other hand say they have no time for any of this (as not having fixed bugs in this area for some years might indicate) I would be OK with them leaving the input/deletion/undo history part out. -- Johannes Wilm Fidus Writer http://www.fiduswriter.org
Re: Proposal for a Permissions API
On 2014/09/04 13:33, Marcos Caceres wrote: ... A developer can then have a Let's get started! screen, where they explain why they need each feature before they request it. ... Absolutely. I the above, a dev could still ask for each API as needed. Like: Ok, let's get your camera working. We need you to grant us access to it. Get user media Great! will you want to geotag your videos? If so, confirm the prompt. You can always turn this off in the app later. geolocation (or a checkbox-like option in their app - this can be enabled during recording even!) fullscreen is just a button in the UI: works just like it does today. None of the above e require all permissions to be asked at once. There is a great article that discusses this approach: http://techcrunch.com/2014/04/04/the-right-way-to-ask-users-for-ios-permissions/ I strongly support this approach. I want to know what functionality an app is going to provide me in return for each of the permissions I grant. I want to be able to selectively use those features whose required permissions I am willing to give to the app's developer. The Android up-front all-or-nothing approach is a disaster that results in it being much too easy to give unintended permissions and much too easy for apps to sneakily ask permissions for things they should not be doing. Let's not repeat it on the Web platform. What about the fingerprinting that a permissions API would enable? Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
