Re: Interoperability vs file: URLs
On Thu, Dec 4, 2014 at 7:50 AM, Sam Ruby wrote: > On 12/02/2014 02:22 AM, Jonas Sicking wrote: >> To be clear, I'm proposing to remove any and all normative definition >> of file:// handling from the spec. Because I don't think there is >> interoperability, nor do I think that it's particularly high priority >> to archive it. > > > A bug has been file on your behalf: > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=27518 > > In response, I suggest that your proposal is a bit too extreme, and I > suggest dialing it back a bit. That sounds ok to me. / Jonas
Re: [Pointer Lock] Comments
Thank you for the detailed comments, I will incorporate and reply back.
On Tue, Dec 2, 2014 at 6:43 PM, timeless wrote:
> 1. w3c is en-us
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#abstract
>
> modelling -> modeling
>
> 2. Xlib
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#h3_why-bundle-all-functionality-hiding-cursor-providing-mouse-deltas-instead-of-using-css-to-hide-the-cursor-always-providing-delta-values-and-offering-an-api-to-restrict-the-cursor-movement-to-a-portion-of-the-web-page
>
> > Direct APIs do not exist on all platforms (Win, Mac, Linux) to bound the
> cursor to a specific rectangle, and prototypes have not yet been developed
> to demonstrate building that behavior by e.g. invisible windows with xlib
> or manual cursor movement on Mac.
>
> "Xlib - Wikipedia, the free encyclopedia" --
> http://en.wikipedia.org/wiki/Xlib
>
> Also note that "Mac" is not a proper term, it could be "Mac OS (X)",
> "Macintosh ..." or "macs".
>
> 3. Mouse capture
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#introduction
>
> > Pointer Lock is related to Mouse Capture [MDN-SETCAPTURE].
>
> should https://www.w3.org/Bugs/Public/show_bug.cgi?id=14600 be noted?
>
> MS should probably be referenced:
> http://msdn.microsoft.com/en-us/library/ie/ms536742%28v=vs.85%29.aspx
> since it's their fault...
>
> 4. a11y/i18n
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#dfn-engagement-gesture
>
> > An event generated by the user agent as a result of user interaction
> intended to interact with the page. e.g. click, but not mousemove.
> > Engagement gestures are any events included in the definition of being
> allowed to show a popup with the addition of keypress and keyup.
>
> "shift", or "control+shift" and similar things are often used to trigger
> an assistive technology, or an IME / language switch.
>
>
> https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/access_stickykeys_settings.mspx?mfr=true
>
> > turn StickyKeys on or off by by pressing the SHIFT key five times
>
>
> http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/langbar_keystroke_shortcuts.mspx?mfr=true
>
> > Switch between languages or keyboard layouts CTRL+SHIFT or left ALT+SHIFT
>
> http://support.microsoft.com/kb/97738
>
> > When you press the APOSTROPHE (') key, QUOTATION MARK (") key, ACCENT
> GRAVE (`) key, TILDE (~) key, ACCENT CIRCUMFLEX key, or CARET (^) key,
> nothing appears on the screen until you press the a second key. If you
> press one of the letters designated as eligible to receive an accent mark,
> the accented version of the letter appears. If you press an ineligible key,
> two separate characters appear. In other words, the US-International
> keyboard layout dynamic-link library (DLL) automatically accents letters
> that customarily receive an accent but does not automatically accent
> letters that do not customarily receive an accent.
>
> While it's nice to allow for "keys" to trigger a lock, "keys" that may
> eventually be handled by something outside the UA should probably not be
> eligible for this.
>
> 5. must
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#pointerlockchange-and-pointerlockerror-events
>
> > Two events are used to communicate pointer lock state change or an error
> in changing state. They are named pointerlockchange and pointerlockerror.
> If pointer lock is entered or exited for any reason a pointerlockchange
> event must be sent.
>
> If I press ctrl-w/cmd-w (close window/tab), is the UA required to send
> these events?
>
> If an iframe has pointerlock, and its parent removes the iframe from the
> dom, is the UA required to send these events?
> If an iframe has pointerlock, and its parent changes the iframe's document
> url to another page, is the UA required to send these events?
>
>
> 6. and
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#widl-Element-requestPointerLock-void
>
> > (for example: mousemove, mousedown, mouseup, click, wheel)
> > (for example: mouseover, mouseout, drag, drop).
>
> Please use "and" -- you do elsewhere:
>
> > clientX, clientY, screenX, and screenY
>
> 7. movement/focus
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#widl-Element-requestPointerLock-void
>
> > Movement and button presses of the mouse must not cause the window to
> lose focus.
>
> Suppose I'm using Windows w/ a standard 104 key keyboard:
> http://en.wikipedia.org/wiki/Computer_keyboard#mediaviewer/File:Qwerty.svg
>
> If I press a system key (the Windows key), or a system key equivalent
> stroke (ctrl+esc), I expect the application to lose focus.
>
> http://developer.android.com/design/media/whats_new_nav_bar.png
>
> If I press the home key on an Android device, I expect the window to lose
> focus.
>
> If a user is on a system where there is no hardware home button, but there
> is
RE: CfC: Move URL spec to 2014 Process (and publish)
Microsoft supports the proposal. cheers -Original Message- From: cha...@yandex-team.ru [mailto:cha...@yandex-team.ru] Sent: Tuesday, December 2, 2014 4:45 PM To: Webapps WG Subject: Re: CfC: Move URL spec to 2014 Process (and publish) 03.12.2014, 02:41, "cha...@yandex-team.ru" : > Hello all, > > this is a call for consensus on the proposal > > Webapps will publish future drafts of the URL specification under the > 2014 Process Document http://www.w3.org/2014/Process-20140801/ > > Silence will be taken as assent but positive response to this email is > preferred, and will be accepted before midnight Hawaii time on Wednesday > December 10. Yandex supports the proposal. cheers -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru - - - Find more at http://yandex.com
[Bug 16070] uses MessageEvent but doesn't define or reference external definition
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16070 Arthur Barstow changed: What|Removed |Added Status|NEW |RESOLVED CC||art.bars...@gmail.com Resolution|--- |FIXED --- Comment #1 from Arthur Barstow --- This was fixed a while ago (including the December 2012 Candidate Recommenation). -- You are receiving this mail because: You are on the CC list for the bug.
Re: Interoperability vs file: URLs
On 12/02/2014 02:22 AM, Jonas Sicking wrote: On Mon, Dec 1, 2014 at 7:58 PM, Sam Ruby wrote: On 12/01/2014 10:22 PM, Jonas Sicking wrote: On Mon, Dec 1, 2014 at 7:11 PM, Domenic Denicola wrote: What we really need to do is get some popular library or website to take a dependency on mobile Chrome or mobile Safari's file URL parsing. *Then* we'd get interoperability, and quite quickly I'd imagine. To my knowledge, all browsers explicitly block websites from having any interactions with file:// URLs. I.e. they don't allow loading an from file:// or even link to a file:// HTML page using . Even though both those are generally allowed cross origin. So it's very difficult for webpages to depend on the behavior of file:// parsing, even if they were to intentionally try. Relevant related reading, look at the description that the current URL Living Standard provides for the origin for file: URLs: https://url.spec.whatwg.org/#origin I tend to agree with Jonas. Ideally the spec would match existing browser behavior. When that's not possible, getting agreements from browser vendors on the direction would suffice. When neither exist, a more accurate description (such as the one cited above in the Origin part of the URL Standard) is appropriate. To be clear, I'm proposing to remove any and all normative definition of file:// handling from the spec. Because I don't think there is interoperability, nor do I think that it's particularly high priority to archive it. A bug has been file on your behalf: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27518 In response, I suggest that your proposal is a bit too extreme, and I suggest dialing it back a bit. / Jonas - Sam Ruby
Re: [url] Feedback from TPAC
On 11/25/2014 03:52 PM, David Walp wrote: Apologies for being a late comer to the discussion, but here is some feedback in our implementation. We're looking forward to engaging on these interactions more proactively in the future. On Wednesday, October 29, 2014 6:55 PM, Sam Ruby wrote: Now to get to what I personally am most interested in: identifying changes to the expected test results, and therefore to the URL specification -- independent of the approach that specification takes to describing parsing. To kick off the discussion, here are three examples: 1) http://intertwingly.net/projects/pegurl/urltest-results/7357a04b5b A number of browsers, namely Internet Explorer, Opera(Presto), and Safari seem to be of the opinion that exposing passwords is a bad idea. I suggest that this is a defensible position, and that the specification should either standardize on this approach or at a minimum permit this. Yes, we, Microsoft, are of the opinion that exposing passwords is a bad idea. Based on received feedback, customers agree and I suspect our customers are not unique on this opinion. I've filed a bug on your behalf: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27516 There already is a discussion as a result. I encourage you to register with bugzilla and add yourself to the cc-list for this bug. 2) http://intertwingly.net/projects/pegurl/urltest-results/4b60e32190 This is not a valid URL syntax, nor does any browser vendor implement it. I think it is fairly safe to say that given this state that there isn't a wide corpus of existing web content that depends on it. I'd suggest that the specification be modified to adopt the behavior that Chrome, Internet Explorer, and Opera(Presto) implement. Agreed. Standardizing something not used that is not in anyone's interest. What you have posted on Github: https://github.com/rubys/url/tree/peg.js/reference-implementation#readme ".. I found I had a hard time determining what should be the parsing output for a number of cases." rings true here. There is no advantage to adding complexity when it is not required. I've filed a bug on your behalf: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27517 Hopefully you find the following work-in-progress easier to follow: https://specs.webplatform.org/url/webspecs/develop/ If not, please let me know how it could be improved. 3) http://intertwingly.net/projects/pegurl/urltest-results/61a4a14209 This is an example of a problem that Anne is currently wrestling with. Note in particular the result produced by Chrome, which identifies the host as a IPV4 address and canonicalizes it. This is the type of interop issue we think should be a focus of the URL specification and the W3C efforts. This is the subject of an existing bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26431 The webspecs link above contains a concrete proposal for resolving this. Finally we are focused at identifying and fixing real-world interop bugs that we see in live sites in support our goal of "The web should just work...". (http://blogs.msdn.com/b/ie/archive/2014/05/27/launching-status-modern-ie-amp-internet-explorer-platform-priorities.aspx). For example, I think you had at one time listed an IE issue in the discussion section of the URL spec - http://intertwingly.net/projects/pegurl/url.html#discuss. This bug was related to a missing "/" at the front of URLs under certain conditions. Since this issue has been removed from the discussion section, I am hoping you have seen that we have fixed the issue. We are actively pursuing and fixing similar interop bugs. We want the URL spec to be source of interop behavior and believe that our goal is in line with your direction. To the best of my knowledge, the fix has not been released, but a workaround has been published. See: https://connect.microsoft.com/IE/feedbackdetail/view/1002846/pathname-incorrect-for-out-of-document-elements Cheers, _dave_ - Sam Ruby
