Re: [whatwg] High-density canvases
For posterity, here were our objections to the original high-DPI canvas
spec:
- The API feels like a short-term hack to automagically do something
that the developer may or may not want done (e.g., if the game/app was
tuned for particular resolution, or for pixel-exact rendering) that we'll
be stuck with in the web platform long after its short-term usefulness has
expired
- It doesn't scale well to non-integer devicePixelRatios
- It is easy for developers to implement the above behaviour in JS if
desired
I think the new proposal addresses the first point, since it's opt-in. I
don't think the second point is a problem, since [get|put]ImageData() will
be back to manipulating exact backing store pixels, so no non-integer
resizing will be required. The third point becomes moot.
One question: now that some browsers are including browser zoom (page zoom)
in window.devicePixelRatio, will/should the new proposal automatically
cause a resize callback on page zoom, in order to preserve 1:1 device
pixels? (Note that I think this is a problem with current JS-based
implementations of canvas auto-scale as well, although perhaps there's a
DOM event for this that you can listen to; I might just be showing my
ignorance here.)
Stephen
On Mon, Sep 9, 2013 at 8:00 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 17 Jul 2013, Rik Cabanier wrote:
Ian wrote:
The density aspect of this might be pointless, given the failure of
getImageDataHD(); if we're dropping that one, I'll drop this one at
the same time.
Yes, please drop it since the HD methods are going away from the one
implementation.
On Tue, 9 Jul 2013, Stephen White wrote:
Conversely, if it helps to bring the spec closer to the implementations,
one thing we do not intend to implement in Chrome is the automatic
high-DPI canvas scaling (ie., auto-doubling of backing stores,
getImageDataHD(), putImageDataHD(), etc).
I believe Apple has also announced that they are dropping support for
this in Safari 7.
So my understanding is that the reason this feature failed is that there's
existing content that assumes a 1:1 ratio, and having an automatic
high-density mode was making some pages end up with canvases with four
canvas pixels per CSS pixel (linearly) -- two from the browser making a
native canvas, times two from the page scaling the canvas for high DPI
displays. This is a factor of sixteen over a 1:1 canvas, a factor of four
more than it should be for high DPI, and a big waste of resources.
As much as sites do this manually, though, it's a huge pain in the neck to
have to worry about pixel density when you're creating your canvas and
drawing on it, especially if you're not drawing sprites on it.
While we're talking about annoying things, there's also the annoyance that
canvases tend to not take zoom into account (either density-affecting zoom
like page zoom on desktop, or transparent zoom like pinch-zoom on mobile
for non-mobile-optimised sites, which the site isn't supposed to know
about): you have to remember to listen for onresize, and then manually
blow away your canvas and recreate it at the right density and then
squeeze it into place so that the coordinate space matches what your code
is expecting while the canvas is actually sized for the display.
There's also the issue of full-bleed canvases where every time the
container changes, you have to remember to re-update the canvas coordinate
space and repaint because otherwise your pretty page gets all warped.
It would be nice to fix these all at once, and I think we can, by
introducing a configuration option on getContext(), in the style of WebGL:
getContext('2d', { density: 'autosize' });
This would trigger the following behaviour: When the context is created,
and subsequently when the canvas changes size (e.g. due to being sized
with CSS relative units and the element they're relative to changing), or
when the display density changes size (e.g. due to page zoom), then:
- the width and height of the canvas bitmaps get updated to match the
new native size of the canvas, at native density.
- the coordinate space of the canvas (context.width/context.height)
gets updated to match the size of the canvas in CSS pixel units.
- a 'resize' event gets fired at the canvas.
We would dump the *HD versions of the methods, and make the regular ones
go back to returning the actual raw pixels, since that would now work fine
and still provide HD-quality content everywhere it's available.
What do people think?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] High-density canvases
On 9/10/13 2:55 PM, Dean Jackson wrote: Ouch. Who is doing this and why? Any browser in which zoom changes the size of a CSS pixel, and because that's the definition of devicePixelRatio? -Boris
Re: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use
On Tue, 10 Sep 2013, Ian Hickson wrote: In cases when the hostname is non-ASCII, the Referer header will have it encoded in punycode. Is that defined anywhere? http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 which defines it syntactically as a URI, which means that if you have an IRI you have to convert it to an IRI before putting it in there. That's normatively imported by the HTML spec's fetch algorithm, so it's the case per HTML too. Specifically, HTML just says to generate the Referer header's value as required by HTTP using a particular URL as the input. Incidentally, Anne, fetch.spec.whatwg.org seems to have omitted the dependency on HTTP so this is broken there, if I'm not mistaken. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] High-density canvases
On 11 Sep 2013, at 5:32 am, Ian Hickson i...@hixie.ch wrote: On Wed, 11 Sep 2013, Dean Jackson wrote: On 11 Sep 2013, at 12:14 am, Stephen White senorbla...@chromium.org wrote: now that some browsers are including browser zoom (page zoom) in window.devicePixelRatio Ouch. Who is doing this and why? Why ouch? Because we’ve always operated under the assumption that devicePixelRatio is the mapping from CSS px to device pixels at 1:1 scale/zoom, and that it is constant for a particular display. The only change content would see is if the window is dragged to/from a high resolution screen. There are other ways to query the page zoom. I fear this will break existing content. I don’t think we’d ever want to change the behaviour. Dean Actually what I really think we should do is also change the window.devicePixelRatio for pinch zoom. Combined with the suggestions for canvas, that would allow (as Rik pointed out on IRC) for high-quality canvas all the way zoomed in, and for cheap canvases when zoomed out.
Re: [whatwg] High-density canvases
On Wed, 11 Sep 2013, Dean Jackson wrote: On 11 Sep 2013, at 5:32 am, Ian Hickson i...@hixie.ch wrote: On Wed, 11 Sep 2013, Dean Jackson wrote: On 11 Sep 2013, at 12:14 am, Stephen White senorbla...@chromium.org wrote: now that some browsers are including browser zoom (page zoom) in window.devicePixelRatio Ouch. Who is doing this and why? Why ouch? Because we’ve always operated under the assumption that devicePixelRatio is the mapping from CSS px to device pixels at 1:1 scale/zoom, and that it is constant for a particular display. The only change content would see is if the window is dragged to/from a high resolution screen. There are other ways to query the page zoom. That seems broken... why would you want to hide the page zoom? I fear this will break existing content. I don’t think we’d ever want to change the behaviour. I guess we'll just have to treat devicePixelRatio as legacy and introduce a new value that's the real device:pixel ratio, then. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] High-density canvases
On 11 Sep 2013, at 6:13 am, Ian Hickson i...@hixie.ch wrote: On Wed, 11 Sep 2013, Dean Jackson wrote: On 11 Sep 2013, at 5:32 am, Ian Hickson i...@hixie.ch wrote: On Wed, 11 Sep 2013, Dean Jackson wrote: On 11 Sep 2013, at 12:14 am, Stephen White senorbla...@chromium.org wrote: now that some browsers are including browser zoom (page zoom) in window.devicePixelRatio Ouch. Who is doing this and why? Why ouch? Because we’ve always operated under the assumption that devicePixelRatio is the mapping from CSS px to device pixels at 1:1 scale/zoom, and that it is constant for a particular display. The only change content would see is if the window is dragged to/from a high resolution screen. There are other ways to query the page zoom. That seems broken... why would you want to hide the page zoom? We don’t want to hide page zoom. I think there are two separate things a developer might want: - the number of actual pixels that correspond to 1 CSS px without zoom - the page zoom If you merge the two, then an unsuspecting developer might think that the user has zoomed in by 2x on an iPhone, and decide to make things smaller. Yes, that’s not necessarily great content, but it makes some sense. For most page content you don’t really care about the device:pixel ratio - text looks fine! For images, you should use the mechanisms we’ve developed (srcset and image-set). Now, I completely agree that there are going to be cases where you might want the image selected for srcset and image-set to respond to zoom. After all, there is no point loading a huge image if it is going to be 1x1 cm^2. But I think that’s separate from changing devicePixelRatio. I fear this will break existing content. I don’t think we’d ever want to change the behaviour. I guess we'll just have to treat devicePixelRatio as legacy and introduce a new value that's the real device:pixel ratio, then. Indeed. I’m not opposed to exposing this. I am reluctant to change something that has behaved a particular way for a number of years. Meanwhile, back to canvas, why don’t we change canvas to be purely callback based, and pass in all the info a developer needs to decide what the best output should be? Put something like requestAnimationFrame into the canvas spec (although that is a bad name - it only sometimes is related to animation). That way you could even imagine a future where a single canvas could have multiple render targets (when printing you get an even higher resolution). Dean
Re: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use
On 9/10/13 3:54 PM, Ian Hickson wrote: These seem like the logical places for it to be set. Am I missing something? No, you're not. I was. Well, then they'll be broken, I guess. (They'll break safe, though.) Well, the outcome is user can't use site. (Which they care more about than whether the site is safe or not, too, though the safety bit is not relevant to the discussion per se.) It might be, depends on what the URL is. Basically, if we want interop on this stuff we need to define which things get punycoded where and which things are stored as ACE instead and whatnot. :( -Boris
Re: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use
On Fri, 12 Jul 2013, Boris Zbarsky wrote: On 7/12/13 2:15 PM, Ian Hickson wrote: The document's referrer is not really defined anywhere in a useful way that I can find. What's not useful about the way it's defined? It's set to a specific string. I couldn't find where it was normatively set to anything. It's normatively set in two places. For the about:blank Document, it's set (if necessary) here: # If the browsing context has a creator Document, then the browsing # context's Document's referrer must be set to the address of that creator # Document at the time of the browsing context's creation. -- http://whatwg.org/html#windows For regular Documents, it's set in the Creating a new Document object steps: # Set the document's referrer to the address of the resource from which # Request-URIs are obtained as determined when the fetch algorithm # obtained the resource, if that algorithm was used and determined such a # value; otherwise, set it to the empty string. -- http://whatwg.org/html#create-a-document-object These seem like the logical places for it to be set. Am I missing something? In cases when the hostname is non-ASCII, the Referer header will have it encoded in punycode. Is that defined anywhere? http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 which defines it syntactically as a URI, which means that if you have an IRI you have to convert it to an IRI before putting it in there. That's normatively imported by the HTML spec's fetch algorithm, so it's the case per HTML too. Specifically, HTML just says to generate the Referer header's value as required by HTTP using a particular URL as the input. That's correct per spec (assuming the punycoding is required anywhere). The latter two are set separately than document.referrer: http://whatwg.org/html/#set-the-document's-address The thing is, people are comparing origins from postMessage to origins from document.referrer. See https://bugzilla.mozilla.org/show_bug.cgi?id=852796#c6. Also see https://bugzilla.mozilla.org/show_bug.cgi?id=720331. Well, then they'll be broken, I guess. (They'll break safe, though.) Also, as a note, nothing above makes it particularly clear that the URL that was originally to be fetched is not already punycode... Ah, well. It might be, depends on what the URL is. If other browsers don't match this, file bugs on them. :-) shrug. It probably won't do much good, but: http://code.google.com/p/chromium/issues/detail?id=259920thanks=259920ts=1373653828 https://bugs.webkit.org/show_bug.cgi?id=118611 Thanks. On Fri, 12 Jul 2013, Adam Barth wrote: I don't think we're likely to change this behavior. We always use punycode for URLs except in the location bar. Why? On Fri, 12 Jul 2013, Boris Zbarsky wrote: On 7/12/13 2:40 PM, Adam Barth wrote: Why not change Firefox to use punycode in window.location? If nothing else because that seems user-hostile (both to web developers examining location values and users who are shown document.URL or location.href in web pages). Yeah... On Fri, 12 Jul 2013, Anne van Kesteren wrote: But then we shouldn't garble pathname either and we do because we have to. So I'm not sure that line of reasoning makes sense. I do think we should offer some kind of conversion utility between the two. It is unfortunate that resolving URLs does that, it's true. But just because we're constrained here, why should we mess up domains also? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] High-density canvases
On Tue, Sep 10, 2013 at 12:45 PM, Dean Jackson d...@apple.com wrote: On 11 Sep 2013, at 5:32 am, Ian Hickson i...@hixie.ch wrote: On Wed, 11 Sep 2013, Dean Jackson wrote: On 11 Sep 2013, at 12:14 am, Stephen White senorbla...@chromium.org wrote: now that some browsers are including browser zoom (page zoom) in window.devicePixelRatio Ouch. Who is doing this and why? Why ouch? Because we’ve always operated under the assumption that devicePixelRatio is the mapping from CSS px to device pixels at 1:1 scale/zoom, and that it is constant for a particular display. The only change content would see is if the window is dragged to/from a high resolution screen. There are other ways to query the page zoom. I fear this will break existing content. I don’t think we’d ever want to change the behaviour. There's a thread on www-style: http://lists.w3.org/Archives/Public/www-style/2012Nov/0144.html It's been in firefox for a while and blink is going to ship it soon: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/RyUSi3zdumQ Actually what I really think we should do is also change the window.devicePixelRatio for pinch zoom. Combined with the suggestions for canvas, that would allow (as Rik pointed out on IRC) for high-quality canvas all the way zoomed in, and for cheap canvases when zoomed out I believe pinch zoom should not change devicePixelRatio. It would be nice if there was a standard way to determine pinch zoom though and if the canvas could automatically resize.
Re: [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use
On Tue, 10 Sep 2013, Boris Zbarsky wrote: On 9/10/13 3:54 PM, Ian Hickson wrote: [some sites compare values that are always-punycoded domains with values that can be full Unicode for security checks] Well, then they'll be broken, I guess. (They'll break safe, though.) Well, the outcome is user can't use site. (Which they care more about than whether the site is safe or not, too, though the safety bit is not relevant to the discussion per se.) Do you have a concrete example I can look at here? I agree we should make this interoperable. It might be, depends on what the URL is. Basically, if we want interop on this stuff we need to define which things get punycoded where and which things are stored as ACE instead and whatnot. :( Agreed. I think we have (if it doesn't say to punycode, don't punycode; nothing ever unpunycodes). The current definitions might not be always what we want, but I think to the extent that they are not, we need to study concrete examples to see what we should do. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] High-density canvases
On Wed, 11 Sep 2013, Dean Jackson wrote: I think there are two separate things a developer might want: - the number of actual pixels that correspond to 1 CSS px without zoom - the page zoom Why? Exposing page zoom separately from device density seems like a fundamental abstraction failure. What's the difference between page zoom and native density? If you merge the two, then an unsuspecting developer might think that the user has zoomed in by 2x on an iPhone, and decide to make things smaller. That's precisely why we should never make page zoom detectable. The entire point of zooming is that the author should _not_ make things smaller. Zooming should make CSS pixels bigger. Authors should always treat CSS pixels as the core unit, so if something should be 10 CSS pixels wide, then that's what the author should do. If the user happens to have zoomed in so that those 10 pixels are 30cm across, then that's what the user wants -- why would the author be able to override that? Yes, that’s not necessarily great content, but it makes some sense. What sense does it make? For most page content you don’t really care about the device:pixel ratio - text looks fine! For images, you should use the mechanisms we’ve developed (srcset and image-set). Well the context here is canvas, right? Now, I completely agree that there are going to be cases where you might want the image selected for srcset and image-set to respond to zoom. Not edge cases, they're pretty core cases. srcset= should definitely be influenced by page zoom, there's no question there. Otherwise, users who zoom in will get low quality images, which defeats the whole point. After all, there is no point loading a huge image if it is going to be 1x1 cm^2. But I think that’s separate from changing devicePixelRatio. Why? I fear this will break existing content. I don’t think we’d ever want to change the behaviour. I guess we'll just have to treat devicePixelRatio as legacy and introduce a new value that's the real device:pixel ratio, then. Indeed. I’m not opposed to exposing this. I am reluctant to change something that has behaved a particular way for a number of years. Meanwhile, back to canvas, why don’t we change canvas to be purely callback based, and pass in all the info a developer needs to decide what the best output should be? Put something like requestAnimationFrame into the canvas spec (although that is a bad name - it only sometimes is related to animation). That way you could even imagine a future where a single canvas could have multiple render targets (when printing you get an even higher resolution). I'm not really understanding what you're proposing here. Can you elaborate? What's the problem this is trying to solve? How would this work in a multi-worker environment? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] High-density canvases
On 11 Sep 2013, at 12:14 am, Stephen White senorbla...@chromium.org wrote: now that some browsers are including browser zoom (page zoom) in window.devicePixelRatio Ouch. Who is doing this and why? Dean
Re: [whatwg] scrdoc and session history don't play along in the spec
On Fri, 12 Jul 2013, Jonas Sicking wrote: The algorithms in the spec are great when it comes to defining things with high level of exactness. However they only work well when the implementations of those algorithms actually look like the algorithms in the spec. When they don't, the implementor has to read in all relevant algorithms defined in the spec. Then map those algorithms into the semantics and behavior they actually result in for the feature that the implementor is working on implementing. Then map those semantics and behaviors into an implementation that fits with existing code. Yeah. This is further complicated by the way all the implementations are implemented in ways that differ from each other, so that there's no way to write a single description that would be easy to understand for all vendors. I do sometimes actually try to follow one or the other browser's implementation, if I understand it well enough and it's clear enough. Generally speaking, it would be easier if the spec defined the semantics and the behaviors instead. Thereby avoiding having to do the initial algorithms-behavior mapping. I agree. Unfortunately, it's really hard (for me) to describe behaviours like navigation in a declarative way while still covering all the edge cases. I'd be very happy to consider alternatives ways to describe the behaviours in the spec that are currently algorithmic in declarative ways, if anyone has any suggestions for how to do this. I do actually do it where possible. Another fix would of course be to rewrite implementations to match the algorithms and concepts in the spec more precisely. Though that's a very risky undertaking for something like navigation since the spec probably isn't getting all edge cases right. Yup. Additionally the spec doesn't deal with all the situations that at least Gecko has to deal with (desktop shortcuts being clicked. Bookmarklets being clicked. Commandlines being executed. Addons. Etc) which means that it might not be possible to get the two to align very well. Yup. That said, I totally understand that it's very hard to define behavior to the level of exactness that's currently there, without writing the spec the way it's currently written. But I believe that this is what's making the spec hard to read. What's making the spec hard to read is the same thing that makes the implementations hard to read. The topic in question is complicated. At the end of the day, there's a limit to how simply one can describe something that is fundamentally complicated. But as I said above, I'm very open to any suggestions. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forcing orientation in content
On Fri, 12 Jul 2013, Glenn Maynard wrote: On Fri, Jul 12, 2013 at 2:45 PM, Ian Hickson i...@hixie.ch wrote: Why? As a user on desktop, I can resize my window however I want, to be landscape or portrait. Why wouldn't I be allowed to do the same on any other device? In mobile accelerometer/gyro-based games, you don't want the user's shifting the device around to cause the screen to change orientation while they're playing. This means locking the current orientation, though, rather than a specific orientation (for example, you'd probably want to unlock it when the user is in a menu and not actually playing the game). I could see locking the orientation in full-screen mode, sure (as Kornel suggested in a later e-mail, see below). On Fri, Jul 12, 2013 at 7:07 PM, Ian Hickson i...@hixie.ch wrote: Sure, some orientations might be better -- just like the HTML spec is more readable on a taller large screen than on a landscape phone screen -- but if the user wants to play the other way, it seems wrong to be able to prevent it. In practice, game developers are rarely willing to spend the time to make their games work well in both portrait and landscape. That's certainly true, but the reality is that on the Web a web browser window might be any number of dimensions, so that's a problem you have to deal with regardless. The Web solution is probably not to lock the display, though, but to letterbox the display if the window's aspect ratio is too far off, as with videos. Well, not so much letterbox as just fit in the given width, leaving a lot of space at the bottom (or centering vertically), sure. On Fri, 12 Jul 2013, Jonas Sicking wrote: On Fri, Jul 12, 2013 at 12:45 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 18 Apr 2013, David Bruant wrote: Currently working on a web project where tablet support (iPad especially) is important, I'm facing a need which apparently the platform doesn't support. I would need to lock the screen in landscape mode. Why? As a user on desktop, I can resize my window however I want, to be landscape or portrait. Why wouldn't I be allowed to do the same on any other device? If the content is sized better for portrait or landscape, then it's generally good for the user if the mode is forced by the application. I disagree. The author doens't know better than I do what I want. Otherwise the user will have to scroll, or will see content that is smaller than it otherwise would be. Or rotate the device, which the user will have to do regardless if the application forces it. Users can't always rotate the screen themselves to control this since many times users disable screen rotation controlled by gravity. If the user disables it, the user can just as easily re-enable it... Also, if the user disabled it, I think it's even more of a reason not to rotate the display for the user. Common cases when this is done is if they find that the screen too often erratically rotates due to the user moving around the device. Another scenario is if laying down with the device in bed in which case rotating according to gravity will result in a screen that is off by 90 degrees from the users orientation. Indeed. The reason we don't do this on desktop systems is that desktop platforms generally don't let the user adjust to an application rendering itself sideways to fit in the current window size. On tablets and mobile platforms, there is an established UI paradigm of simply rotating the device when content renders itself sideways. A quite annoying UI paradigm... If we don't provide webplatform support for setting orientation, content will simply use things like CSS transformation to render itself sideways. This results in a much poorer experience for the user since it interacts poorly with for example gravitational orientation. I.e. the user might see the content sideways, then rotate the device in order to see the content correctly, resulting in the device then changing rendering orientation. The page will then detect this and undo the transformation. The result is a lot of back and forth which is disruptive to the user. Any automatic rotation not under the control of the user, or locking of rotation not under the control of the user, is disruptive to the user. Another problem that is likely to occur is authors accidentally applying CSS transformation in on devices where the user can't reorient the device. Not to mention that using CSS transformation will likely result in content that has to use more javascript driven layout with all the downsides that come with that. I'm certainly not advocating for authors manually rotating the content to be at 90 degrees to the device's native orientation. By supporting pages setting the orientation we can put the user more in charge by ignoring that orientation when appropriate. Such as on devices where
Re: [whatwg] Forcing orientation in content
On Tue, Sep 10, 2013 at 10:22 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 15 Jul 2013, Kornel Lesiński wrote:
Since specific, locked screen orientation is mostly needed in games, and
forced rotation is disruptive to other things on the screen (e.g. moving
buttons/addressbar to other physical edge of the screen), maybe it
should be tied to the Fullscreen API?
element.requestFullscreen({orientation:'landscape', autorotation:false})
That makes sense to me. Anne?
Almost missed this!
Filed: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23204
Implementer feedback welcome.
--
http://annevankesteren.nl/
Re: [whatwg] Forcing orientation in content
On Tuesday, September 10, 2013 at 11:22 PM, Ian Hickson wrote:
On Sat, 13 Jul 2013, Tobie Langel wrote:
It is not uncommon for mobile experiences to rely on the accelerometer
as an input mechanism, for example to control page scrolling (e.g.
Instapaper) or for gameplay.
In such cases, auto-rotation of the viewport is completely disruptive to
the user's experience and needs to be inhibited.
Sure, but that's an OS-level feature.
Arguably. Signaling auto-rotation inhibited requirements isn't, though. That's
application-level. Auto-rotation inhibition needs to be automatic and scoped to
the document.
So this isn't so much about forcing orientation as it is about
inhibiting auto-rotation.
This would only work if the page was already in the orientation the user
wants, but how can we ensure that?
The UA is free to provide whatever UI it wants to allow the user to
enable/disable auto-rotation inhibition and/or pick a preferred orientation.
From the use cases can be derived requirements for the content author to be
able to signal to the UA the preference to inhibit auto-roation. Whether the UA
decides to comply to this stated pref, allow its user to override it, etc.
should be implementation-specific.
Your desktop comparison is inadequate, as there aren't comparable
auto-rotation mechanisms there.
It would be equivalent to forcing a particular window size.
No. A better analogy is the autoplay feature of video elements. Merely a hint
that can be overridden by the user/UA.
And frankly even that comparison is dodgy: playing a video doesn't have close
to the discoverability and usability issues inhibiting auto-rotation at the OS
level has.
On Mon, 15 Jul 2013, Kornel Lesiński wrote:
Since specific, locked screen orientation is mostly needed in games, and
forced rotation is disruptive to other things on the screen (e.g. moving
buttons/addressbar to other physical edge of the screen), maybe it
should be tied to the Fullscreen API?
element.requestFullscreen({orientation:'landscape', autorotation:false})
That makes sense to me. Anne?
Agreed these requirements are generally tied to fullscreen/absence of
browser-chrome context. Unfortunately, this is achieved using a variety of AP
across implementations (e.g. iOS/Android?). So this proposition would only
cater to those situation where the fullscreen API was used.
--tobie
Re: [whatwg] Proposal: Media element - add attributes for discovery of playback rate support
On Fri, 19 Jul 2013, Brendan Long wrote: On Jul 19, 2013 3:14 PM, Ian Hickson i...@hixie.ch wrote: What if we added a supportedPlaybackRates attribute, which holds an array of playback rates supported by the server, plus (optionally) any rates the user agent can support due to the currently buffered data (possibly requiring that the user agent have enough data buffered to play at that speed for some amount of time). Wouldn't that be 0.0 .. Infinity, basically? I've been thinking about this more, and it seems like the buffered attribute is enough for a JavaScript application to determine for itself if it's safe to play faster. It does seem useful to expose the rates supported by the server though, so an application can realize that it's safe to play at those rates, even if there's not much buffered yet. How do browsers determine what speeds the server supports? IS that information in the protocol? I'd need to read more about this to figure out how to expose it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Outline style to use for drawSystemFocusRing
We've finished implementing drawSystemFocusRing and drawCustomFocusRing in Chrome. Try it in Chrome 31 or higher (either canary or dev channel should work today). You'll need to go to chrome://flags and enable *experimental canvas features*, then restart the browser. Here's a demo I built that uses drawSystemFocusRing: http://dmazzoni-google.github.io/canvas-focus-ring-demo/ - Dominic
Re: [whatwg] High-density canvases
On Tue, 10 Sep 2013 21:22:51 +0100, Dean Jackson d...@apple.com wrote: I think there are two separate things a developer might want: - the number of actual pixels that correspond to 1 CSS px without zoom - the page zoom If you merge the two, then an unsuspecting developer might think that the user has zoomed in by 2x on an iPhone, and decide to make things smaller. Do you have an example of a page that does make things smaller to counter the zoom? Are you referring to some iPhone-specific workarounds (like position:fixed elements being problematic for zoom?) I assumed that sites which don't like being zoomed in would just block it via meta viewport. -- regards, Kornel
Re: [whatwg] Should video controls generate click events?
On Tue, 20 Aug 2013, Edward O'Connor wrote: [W]e do want users to be able to bring up the native controls via a context menu and be able to use them regardless of what the page does in its event handlers. So, I request that the spec be explicit that interacting with the video controls does not cause the normal script-visible events to be fired. […] I've made the spec say this is a valid (and recommended) implemenation strategy. The change http://html5.org/r/8134 looks good to me, thanks! I don't see why video controls should be any different than, say, button here. If I install an event handler on an ancestor of an element, I'm able to capture events and prevent the descendent element from seeing them. It's more similar to clicking on a context menu (or indeed a menu bar) than clicking on a button, IMHO. Or like clicking on a control in the popup from input type=file. Or clicking in the colour wheel that pops up when you active an input type=color control. A button is an in-page control. A video's controls are not an in-page control -- there's no in-page element for them, they might not even be positioned over the page (they could be on a palette that the user has dragged out of the page). Also, with button the UA and the page are working together. The UA renders the button and shows how it is being pressed; the author makes it do something. The case we're talking about here is where the user presses a button and both the user agent and the author want to do something (and the author has no way to know what the user agent wants to do, or what the user thinks will happen). A UI which allows users to activate a control regardless of what the page does in its event handlers is a general feature not specific to media elements—and may be worth considering—but we shouldn't make a one-off exception to the basic model of DOM events just for video. I agree that it's not specific to video, but I don't think we have to mention it for other things because it's only video where the spec suggests having such a UI model and where browsers have historically also fired an event. On Wed, 21 Aug 2013, Silvia Pfeiffer wrote: The paragraph added in http://html5.org/r/8134 should probably be restricted to the case where the default video controls have been enabled by the user (e.g. through the context menu) rather than by the Web page. It would indeed be bad if the Web page author, who is using the default controls through a video controls attribute could not rely on the events firing. Why? IMHO, the example that Philip provided in http://people.opera.com/~** philipj/click.html http://people.opera.com/~philipj/click.html is not a realistic example of something a JS dev would do. Seem pretty reasonable to me. How else would you make the video play/pause when you click the video frame, yet also have UA controls? On Wed, 21 Aug 2013, Silvia Pfeiffer wrote: What I'm saying is that the idea that the JS developer controls pause/play as well as exposes video controls is a far-fetched example. I don't see why. It's what I'd do. On Tue, 20 Aug 2013, Bob Lund wrote: What about a Web page that uses JS to control pause/play/etc based on external messages, say from a WebSocket? The sender in this case acts as a remote control. That seems unrelated to this issue, unless I'm missing something. On Tue, 20 Aug 2013, Rick Waldron wrote: Firefox actually implements click-to-play video by default. It's unfortunate and all video interaction projects that I've worked on directly or consulted for have been forced to include video surface click - event.preventDefault() calls to stop the behaviour. This may be irrelevant to the current discussion, but I'm trying to get a better understanding for the behavioural changes implied by this spec update, so correction is highly desirable. The change wouldn't affect this as far as I can tell. We're talking about interaction with specific controls enabled by controls= (or manually by the user). On Tue, 20 Aug 2013, Glenn Maynard wrote: It's the behavior users expect when watching videos, which is the case video should optimize for. If you're doing something else where the user interacts with the video in other ways, then it's expected that you need to prevent this behavior explicitly. Unlike browser controls, this is visible to scripts and something that affects authors, so this probably should be in the spec if it isn't. I'm not sure what you want in the spec here. Can you elaborate? On Wed, 21 Aug 2013, Robert O'Callahan wrote: Just to be clear, we only do click-to-play when the controls attribute is set. So if that's causing problems for you, I guess you want most of our built-in controls but not all of them? On Tue, 20 Aug 2013, Rick Waldron wrote: Also, at the time, the surface click to play was non-standard and incredibly annoying because it just
Re: [whatwg] URL resolution of fragment urls in html5 webapps
On Tue, 9 Jul 2013, Igor Minar wrote: The current url resolution as described in the spec results in some unhelpful behavior when the following combination of web technologies are used in a client-side web app: - a combination of path-relative urls (a href=relative/url/to/somewherelink/a) and fragment/anchor urls (a href=#anchorUrllink/a) - history.pushState - used for deep-linking - base[href] - used to properly resolve the relative urls to the root of the application in various deployment environments Once history.pushState is used to change location.href, the path-relative urls resolve correctly as expected against the base[href], but anchor urls that are only useful if resolved against the current document.baseURI also unsurprisingly resolve against the base[href]. The fragment identifiers resolve that way before the pushState(), too. This behavior makes them unsuitable for this kind of applications which is a big loss in developers toolbox and in fact breaks existing web features like svg that depend on anchor urls to reference nodes in the current document. How do they work in SVG with a base with no pushState()? http://hixie.ch/tests/adhoc/svg/use/001-with-base.html In Safari and Firefox, the relative URLs, even in SVG, are affected by base, so again, it seems it's base that is relevant here, not pushState(). (In Chrome, some URLs are resolved locally and some not, which is wacked.) Does anyone have thoughts on how one could build a client-side app that can be deployed in various contexts without any special server-side templating or build-time pre-processing? The base element looks like a perfect solution for this, if only it didn't break anchor urls. Use only site-absolute URLs, and not base, and then everything will work fine, as far as I can tell. On Wed, 10 Jul 2013, Alex Russell wrote: Was just discussing this with Rafael, and it seems like the core issue you're flagging is that if a document has a base element, all #anchor navigations (which would otherwise be document relative) are now full-page navigations to the URL specified in the base, not the document's natural URL. Is that right? If so, we might be able give you some control over this in the Navigation Controller (although it's not currently scoped as many folks didn't want to contemplate in-document navigation for the time being). But perhaps we don't need to do that: is the current behavior the same across browsers? If it's not, we might be able to change the spec. If it is, it'll be harder. It seems pretty consistent. On Wed, 10 Jul 2013, Rafael Weinstein wrote: I'm curious: Is it useful to have fragment URL resolve against anything other than the display url? I.e. when is the current behavior wrt fragments appropriate. It's a good question. I thought the old IETF specs for URLs said you had to do otherwise, but nobody seems to have implemented that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] High-density canvases
On Wed, 11 Sep 2013, Dean Jackson wrote: On 11 Sep 2013, at 12:14 am, Stephen White senorbla...@chromium.org wrote: now that some browsers are including browser zoom (page zoom) in window.devicePixelRatio Ouch. Who is doing this and why? Why ouch? Actually what I really think we should do is also change the window.devicePixelRatio for pinch zoom. Combined with the suggestions for canvas, that would allow (as Rik pointed out on IRC) for high-quality canvas all the way zoomed in, and for cheap canvases when zoomed out. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Should video controls generate click events?
On Tue, Sep 10, 2013 at 6:35 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 20 Aug 2013, Glenn Maynard wrote: It's the behavior users expect when watching videos, which is the case video should optimize for. If you're doing something else where the user interacts with the video in other ways, then it's expected that you need to prevent this behavior explicitly. Unlike browser controls, this is visible to scripts and something that affects authors, so this probably should be in the spec if it isn't. I'm not sure what you want in the spec here. Can you elaborate? The same thing you described: the activation behavior for videos should be to toggle play/pause. If only some browsers do it, it's an interop problem, and it seems like the right default behavior. I'm not sure whether this should only be when browser controls are enabled or not. It might be best to keep them orthogonal, so browser controls are always UI controls that don't generate click events at all. On Wed, 21 Aug 2013, Silvia Pfeiffer wrote: This is why I am saying: Philip's example is not a typical use case. It only happens when the developer made the choice to roll their own, but the user activates the default controls (e.g. through the context menu) as well. This can't happen on YouTube, because YouTube hide away the context menu on the video element. You can't do that. Browsers have options to remove the ability for pages to prevent the context menu from opening. I always use it, since it's disruptive (the browser's context menu belongs to me, not the page). -- Glenn Maynard
Re: [whatwg] High-density canvases
On 9/10/13 4:13 PM, Ian Hickson wrote: I guess we'll just have to treat devicePixelRatio as legacy and introduce a new value that's the real device:pixel ratio, then. I would be interested in some data on what different UAs do with devicePixelRatio... -Boris
Re: [whatwg] High-density canvases
On 9/10/13 4:22 PM, Dean Jackson wrote: I think there are two separate things a developer might want: - the number of actual pixels that correspond to 1 CSS px without zoom What are the use cases for this, as opposed to number of actual pixels that correspond to 1 CSS px? And are you talking about the sort of zoom that changes layout (because it changes the number of CSS px per device px and hence changes font rasterization), or the sort that does not (which basically does a zoom without changing font metrics)? - the page zoom Which one? Indeed. I’m not opposed to exposing this. I am reluctant to change something that has behaved a particular way for a number of years. Shipping UAs already disagree on how devicePixelRatio works with zoom. They also disagree on how zoom behaves in general. -Boris
Re: [whatwg] High-density canvases
On Mon, Sep 9, 2013 at 7:31 PM, Ian Hickson i...@hixie.ch wrote: Right, resetting the context would definitely be part of the deal. This mode would be specifically defined as a mode where you had to listen to onresize or your canvas would almost certainly get cleared sooner or later. In fact, we could go further, and say that canvases that aren't getting rendered at all (e.g. display:none, off-screen, background tab) can get cleared, with the deal being that next time you need to show the canvas you immediately get an onresize. It would be better if the resize didn't happen until the page is actually ready to re-render. That way, the canvas doesn't flicker if it's rendered before the page actually does render (eg. it may need to reload resources to render). Rendering a blurry canvas briefly is better than rendering a blank canvas. For example, add a method resizeToCurrentDPI(), and don't do it automatically at all. Fire an event when calling the method *would* cause a change of canvas size. The page can then load resources asynchronously as needed, and call the method when it's ready to redraw, avoiding any period where a blank canvas might be composited. Yeah, my suggestion, if we do this, would be to not do it until high density displays are even more widely available than now. This is mostly a convenience and performance-improving API, not a critical feature add. High-DPI displays are already widespread in mobile (all Apple devices except for the iPad Mini; the Kindle Fire HD), and by contrast there's no sign of them for desktops, so I think we're either there now or we won't be for a long time. -- Glenn Maynard
Re: [whatwg] High-density canvases
On Tue, Sep 10, 2013 at 6:24 PM, Glenn Maynard gl...@zewt.org wrote: Yeah, my suggestion, if we do this, would be to not do it until high density displays are even more widely available than now. This is mostly a convenience and performance-improving API, not a critical feature add. High-DPI displays are already widespread in mobile (all Apple devices except for the iPad Mini; the Kindle Fire HD), and by contrast there's no sign of them for desktops, so I think we're either there now or we won't be for a long time. High-end laptops have high-dpi screens (the Pixel I'm using right now has one), and they're slowly spreading down the price scale. ~TJ
