[whatwg] FW: VIDEO and pitchAdjustment
From: Domenic Denicola From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Robert O'Callahan According to the spec it should work, but it's very low priority for us and implementing it would be very inefficient as Yay295 describes. So I don't think it's going to happen in Firefox in the forseeable future. I was looking in to this yesterday and it seems like the spec places absolute no limits on playbackRate. Am I right? This seems a bit bad. If nobody is supporting negative nor has any plans to, we should at least consider throwing for negative. I guess we can leave the upper limit unspecified, unless implementations all happen to agree on one. Support is certainly poor; Internet Explorer/Trident and Edge both support negative playback rates on desktop (I haven’t tested mobile) but do so by simply showing the key frames as they are reached in reverse, in my testing. Firefox, Chrome and Safari on desktop and mobile don’t support negative values at all AFAICT. I have notes here suggesting that mobile platforms don’t even support positive rates other that 1. -- James Ross ja...@james-ross.co.uk
[whatwg] FW: DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
Date: Thu, 9 Jul 2015 14:42:07 +0200
From: phil...@opera.com
I think this looks like a very promising approach. Would there be any
way to feature detect support for EventListenerOptions as the third
argument? It seems like a problem that addEventListener(type,
callback, { mayCancel: false }) would be treated as
addEventListener(type, callback, true) in existing browsers.
http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#extensions-to-the-event-interface
and
http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#examples
example 2 are intended to cover this.
--
James Ross ja...@james-ross.co.uk
Re: [whatwg] Hide placeholder on input controls on focus
From: k...@iqmultimedia.com.au To: resca...@emsai.net; derer...@gmx.ch Date: Thu, 21 Mar 2013 01:18:26 + CC: whatwg@lists.whatwg.org Subject: Re: [whatwg] Hide placeholder on input controls on focus I'm skeptical that this is genuinely a significant issue with users, chiefly because I've never really seen any page authors feel the need to implement anything like this, and because as stated earlier Safari, Firefox and Chrome all use non-hiding placeholders in various places in their browser chrome without any sort of special treatment on focus. Surprisingly, the only example I could find of a developer doing something both on focus *and* once the user starts typing is Opera in its address bar and search field, which behaves as you describe; the placeholder text goes lighter on focus. Nevertheless, the _only_ browser I can find which actively removes its placeholder text on focus is IE 8 (in its search field). I can't believe that there needs to be a different implementation for fields in the browser's own chrome as for in-page form fields. Just as an added data-point (that I only noticed today) - Windows 7's placeholder implementation in the Start menu and Explorer's search box: - The text is displayed in grey *and* italic *and* with a space at the start. - Focusing the input box with tab/Control-E or autofocus when opening the Start menu does *not* hide the placeholder. - Typing hides the placeholder and clearing to empty re-shows it. - Control-A or clicking in the textbox hides the placeholder. This to me seems like a very interesting compromise between the two observed behaviours in browsers - autofocus does not prevent the user seeing the placeholder but any attempt to interact with it (by typing, mouse clicking or control-a) removes it. I would be interested in why this behaviour was not adopted in IE10's input[placeholder] implementation. -- James Ross sil...@warwickcompsoc.co.uk
Re: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use
Date: Wed, 20 Mar 2013 22:46:15 -0400 From: bzbar...@mit.edu To: wha...@whatwg.org Subject: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use 1) Gecko shows exactly the string we put on the wire in document.referrer (punycode and all). document.URL and document.location.href show the non-ASCII chars in some cases. 2) WebKit (or at least Chrome) seems to return punycode for all three of these. 3) Opera seems to return non-ASCII chars for all three of these, at least in some cases. IE 10 shows the non-ASCII chars in all three in the cases I've tried just now. -- James Ross sil...@warwickcompsoc.co.uk
Re: [whatwg] Hide placeholder on input controls on focus
Date: Mon, 18 Mar 2013 10:31:56 +0100 From: derer...@gmx.ch To: whatwg@lists.whatwg.org Subject: [whatwg] Hide placeholder on input controls on focus A short browser comparison shows: - Firefox and Chrome hide the placeholder when the user starts typing - Opera and Safari hide it when the field gets focus IE 10 hides it when the field gets focus. -- James Ross sil...@warwickcompsoc.co.uk
Re: [whatwg] Priority between a download and content-disposition
From: lcam...@coredump.cx Date: Mon, 18 Mar 2013 10:00:40 -0700 To: gl...@zewt.org CC: wha...@whatwg.org; derhoe...@gmx.net; jo...@sicking.cc Subject: Re: [whatwg] Priority between a download and content-disposition Downloads are associated with the site the link is on, not the domain the resource is served from. If users click a download link and the file comes from s3.amazonaws.com, they didn't come from Amazon; they came from your page. I don't believe that's the case in most browser UIs. Correct; IE 10 and Firefox 19 both specifically say file filename from host of file and make no mention of the page/URL containing the link. Chrome 25 doesn't show the host at all in the primary UI but the Downloads window includes the full URL of the file, and nothing about the page containing the link. -- James Ross sil...@warwickcompsoc.co.uk
Re: [whatwg] Background audio channels
Date: Fri, 15 Mar 2013 10:57:44 -0700 From: wjohns...@mozilla.com To: public-h...@w3.org; wha...@whatwg.org Subject: [whatwg] Background audio channels Note: This is all based rather loosely on the AudioChannels implementation written for B2G recently [1]. It includes a few other use-cases on its wiki page, along with definitions of additional channels to accomadate them. I've been trying to simplify it down to handle the most common use cases. Finding the correct terminology here is difficult though. For instance, it seems likely that games will see the background channel and think its an appropriate place to play game background music, the exact type of audio you'd like to have paused when you leave the game. Ideas for better ways to describe it are welcome. [1] https://wiki.mozilla.org/WebAPI/AudioChannels For comparison, Windows 8 defines msAudioCategory (http://msdn.microsoft.com/en-us/library/windows/apps/hh767375) with similar channels to the B2G list, but also a separate msAudioDeviceType (http://msdn.microsoft.com/en-us/library/windows/apps/hh767376) which specifies which device to output to (console - not sure what this means, multimedia, communications). -- James Ross sil...@warwickcompsoc.co.uk
Re: [whatwg] URL: query string
(Browser support is all over the map. For mailto:test?test; Firefox gives neither pathname/search, Opera/Safari give pathname/search, Chrome only gives pathname, which is test?test. No access to Internet Explorer unfortunately.) FWIW, according to http://dump.testsuite.org/url/inspect.html, IE10 gives pathname/search as test/?test in both IE10 and IE9 modes. -- James Ross sil...@warwickcompsoc.co.uk
Re: [whatwg] URL: query string
On Wed, Nov 21, 2012 at 9:07 PM, James Ross sil...@warwickcompsoc.co.uk wrote: FWIW, according to http://dump.testsuite.org/url/inspect.html, IE10 gives pathname/search as test/?test in both IE10 and IE9 modes. Sweet, is that true for test:test?test, about:blank?test, and data:test?test too? In any case it sounds like this change should be made. Alas not quite; for test:test?test and data:test?test it works, but for about:blank?test it gives pathname=blank?test and search=. The behaviour change appears to be specific to the about: scheme (it happens no matter what I put after). It also doesn't split out the hash, if there is one, when the scheme is about:. -- James Ross sil...@warwickcompsoc.co.uk
Re: [whatwg] Should scrollbars move focus?
From: o...@chromium.org Date: Thu, 1 Nov 2012 10:45:07 -0700 I didn't test nested scrollbars in Windows. I believe Elliott may have. I did test them on Mac and Ubuntu. Clicking on nested scrollbars doesn't move focus even if the scrollable element is focusable. On Ubuntu, clicking on scrollbars doesn't even change window focus if the scrollbar is in a different window. On Windows (tested on 7 using the Resource Monitor and Command Prompt properties windows), interacting with scrollbars will focus the window, but not the scrollable item itself (i.e. preserving the focus within the window). However, Internet Explorer (9, on Windows 7), will move the focus to the scrollable element (for all types in Robert's test page). James
