To summarise this thread:
WebGL has the unfortunate problem of being likely to run into hardware
limitations more often that most other features, due to limited GPU
resources. Authors need to be able to distinguish the temporary failure of
a context not being immediately available from the
On Thu, May 12, 2011 at 2:42 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 13 Apr 2011, Glenn Maynard wrote:
Calling canvas.getContext(webgl, {async: true}) will cause it to
discouraged from using this API (deprecating it if possible).
(FYI: while some people have expressed interest in
On 5/12/11 2:25 AM, Robert O'Callahan wrote:
On Thu, May 12, 2011 at 4:45 PM, Jer Noblejer.no...@apple.com wrote:
And your geolocation example actually argues the other way: the existing
geolocation API includes an asynchronous error handler that is explicitly
called when a request is denied.
On May 11, 2011, at 11:25 PM, Robert O'Callahan wrote:
On Thu, May 12, 2011 at 4:45 PM, Jer Noble jer.no...@apple.com wrote:
2. Animating into and out of full screen.
WebKit's current video full-screen support will animate an element between
its full-screen and non-full-screen
On 5/12/11 3:24 AM, Jer Noble wrote:
A) If an author calls requestFullScreen(), at some point in the future they will receive either a
fullscreenchanged event or a fullscreendenied event.
B) If an author calls requestFullScreen(), at some point in the future they may receive a
Yes, I have read that part but what confuses me is that in the link I
sent in my original email MessageEvent is defined as follows:
interface MessageEvent : Event {
readonly attribute any data;
readonly attribute DOMString origin;
readonly attribute DOMString lastEventId;
readonly
On May 12, 2011, at 12:31 AM, Boris Zbarsky wrote:
On 5/12/11 3:24 AM, Jer Noble wrote:
A) If an author calls requestFullScreen(), at some point in the future they
will receive either a fullscreenchanged event or a fullscreendenied
event.
B) If an author calls requestFullScreen(), at some
On 5/11/11 10:00 PM, Ian Hickson wrote:
On Sun, 13 Feb 2011, Charles Pritchard wrote:
Could we remove the optional maxWidth parameter from fillText and strokeText
of CanvasRenderingContext2D.
I don't see them in use anywhere, they're not widely implemented, and I don't
see them fitting any
On May 12, 2011, at 12:54 AM, Jer Noble wrote:
Surely there's a way to achieve the security benefits you're hoping for
without requiring intentionally obtuse API?
Okay, here's another proposal that should work with Firefox's passive
permission system:
Proposal:
- Add a new boolean
On Thu, May 12, 2011 at 11:12 AM, Jer Noble jer.no...@apple.com wrote:
Okay, here's another proposal that should work with Firefox's passive
permission system:
Proposal:
- Add a new boolean Element property canRequestFullScreen. This would map
to Firefox's Never permission choice.
- Add
On 2011-05-12 09:38 CEST, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) wrote:
Yes, I have read that part but what confuses me is that in the link I
sent in my original email MessageEvent is defined as follows:
interface MessageEvent : Event {
readonly attribute any data;
readonly attribute DOMString origin;
Why can't the browser just do the fullscreen in a window behaviour
until/if the user approves?
No need for new events even, although a fullscreen lost, sourced eg. from
some browser UI or loss of focus, might be useful.
I don't see why it would make a difference from the page's perspective
On Thu, May 12, 2011 at 1:46 PM, James May wha...@fowlsmurf.net wrote:
Why can't the browser just do the fullscreen in a window behaviour
until/if the user approves?
I don't see anything wrong with this offhand :)
No need for new events even, although a fullscreen lost, sourced eg. from
some
Ahh, thanks! I thought it was an all or nothing kind of class. Have
now implemented the onmessage using the right event.
/Tommy
On Thu, May 12, 2011 at 11:18, Per-Erik Brodin
per-erik.bro...@ericsson.com wrote:
On 2011-05-12 09:38 CEST, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) wrote:
Yes, I have read that
On 5/12/11 3:54 AM, Jer Noble wrote:
No, that still doesn't make sense. At the time when the user decides to allow
or deny full screen access
The point is this may be never. They might just wake forever to make a
decision.
Saying that fullscreendenied will confuse users is akin to
On 5/12/11 4:12 AM, Jer Noble wrote:
- Add a new boolean Element property canRequestFullScreen. This would map to Firefox's
Never permission choice.
- Add the fullscreendenied event. This would map to Firefox's Not now
permission choice.
So if the user just dismisses the notification
On May 12, 2011, at 1:42 AM, timeless wrote:
Your proposal makes it fairly easy for sites to stick up annoying full
content blocking you must change your settings to proceed elements.
That ability exists in the current API as well. A malicious website would just
require the
On May 12, 2011, at 5:44 AM, Boris Zbarsky wrote:
On 5/12/11 3:54 AM, Jer Noble wrote:
No, that still doesn't make sense. At the time when the user decides to
allow or deny full screen access
The point is this may be never. They might just wake forever to make a
decision.
Saying
On May 12, 2011, at 5:47 AM, Boris Zbarsky wrote:
On 5/12/11 4:12 AM, Jer Noble wrote:
- Add a new boolean Element property canRequestFullScreen. This would map
to Firefox's Never permission choice.
- Add the fullscreendenied event. This would map to Firefox's Not now
permission choice.
On Thu, May 12, 2011 at 2:25 AM, Robert O'Callahan rob...@ocallahan.org wrote:
It seems rational to me: click on fullscreen, the video fills the entire
window (but not the screen), and some browser UI appears to suggest going
the rest of the way.
This sounds really bad to me. The user
Thanks for the feedback!
On Wed, May 11, 2011 at 1:39 PM, Tim Down timd...@gmail.com wrote:
In section 11, the HTML Editing Commands spec says the following:
When execCommand() is invoked, the user agent must take the action
from the list below given by commandId on the context object's first
On 5/12/11 12:48 PM, Jer Noble wrote:
I'm saying that if authors expect to get one or the other but then never do,
that will confuse authors.
Again, I fail to see how this is a problem for the denial event but not for the
change event.
The problem is not for any particular event. The
On 5/12/11 1:16 PM, Jer Noble wrote:
On May 12, 2011, at 5:47 AM, Boris Zbarsky wrote:
On 5/12/11 4:12 AM, Jer Noble wrote:
- Add a new boolean Element property canRequestFullScreen. This would map to Firefox's
Never permission choice.
- Add the fullscreendenied event. This would map to
On 5/12/11 1:43 PM, Aryeh Gregor wrote:
On Thu, May 12, 2011 at 2:25 AM, Robert O'Callahanrob...@ocallahan.org wrote:
It seems rational to me: click on fullscreen, the video fills the entire
window (but not the screen), and some browser UI appears to suggest going
the rest of the way.
This
Behavior for Enter in contenteditable in current browsers seems to be
as follows:
* IE9 wraps all lines in p (including if you start typing in an
empty text box). If you hit Enter multiple times, it inserts empty
ps. Shift-Enter inserts br.
* Firefox 4.0 just uses br _moz_dirty= for Enter and
On Wed, 13 Apr 2011, Kyle Huey wrote:
Gecko 2.0 ships with a non-standard method on canvas named
mozGetAsFile(contentType, fileName). We added this for internal use in
our UI. It retrieves the contents of the canvas as a File object (at
the time Gecko did not supports Blobs) encoded in
On 5/12/11 4:28 PM, Aryeh Gregor wrote:
* Firefox 4.0 just usesbr _moz_dirty= for Enter and Shift-Enter,
always. (What's _moz_dirty for?)
It's used when serializing: things with _moz_dirty are prettyprinted
even if the serialization is trying to preserve the original whitespace
layout of
On Thu, 14 Apr 2011, Hugues De Keyzer wrote:
For the moment, it seems that drawing on canvas is done without
accounting for gamma, actually making wrong assumptions, like a^x + b^x
= (a + b)^x. This gives incorrect results, although they are not always
obvious to perceive. For example,
On 12 May 2011 19:06, Aryeh Gregor simetrical+...@gmail.com wrote:
Really the whole idea of multiple Ranges per Selection is underdefined
right now, since AFAIK only Gecko supports it at all, and the way it
does it is weird and we don't really want to spec it, and other
engines don't seem to
First things first:
On May 12, 2011, at 11:24 AM, Boris Zbarsky wrote:
I believe you have _completely_ misunderstood what I said. I'm describing a
problem in the geolocation API as it stands. You're talking about
something else. Unfortunately, I'm not quite sure how you got there
* IE9 wraps all lines in p (including if you start typing in an
empty text box). If you hit Enter multiple times, it inserts empty
ps. Shift-Enter inserts br.
* Firefox 4.0 just uses br _moz_dirty= for Enter and Shift-Enter,
always. (What's _moz_dirty for?)
* Chrome 12 dev doesn't wrap a
On Fri, May 13, 2011 at 10:15 AM, Jer Noble jer.no...@apple.com wrote:
On May 12, 2011, at 11:24 AM, Boris Zbarsky wrote:
On 5/12/11 12:48 PM, Jer Noble wrote:
I'm saying that if authors expect to get one or the other but then
never do, that will confuse authors.
Again, I fail to see
On Fri, May 13, 2011 at 4:48 AM, Jer Noble jer.no...@apple.com wrote:
I don't consider the following to be a usable UI:
- User clicks a full screen button
- Content resizes to occupy full window
- Browser pops up a permissions dialog
- User has to click the Allow button*
- Window then
[Re-CCing list, hope that's OK.]
On Fri, May 13, 2011 at 11:03 AM, Jer Noble jer.no...@apple.com wrote:
On May 12, 2011, at 3:49 PM, Robert O'Callahan wrote:
On Fri, May 13, 2011 at 10:15 AM, Jer Noble jer.no...@apple.com wrote:
I understand what you're saying. By making the error case
On May 12, 2011, at 4:23 PM, Robert O'Callahan wrote:
That only works if the browser can detect a deferral. If the user simply
ignores the browser's UI, you wouldn't know when to fire the event. And
there's also the issue of a fullscreendenied being followed by a
fullscreenchange, which
On Thu, May 12, 2011 at 1:58 AM, Ian Hickson i...@hixie.ch wrote:
This is something that is rife with serious security concerns: exposing
history, the potential for cross-origin data leakage, introspecting
spelling-checker user dictionaries, inspecting data that is otherwise
hidden such as
On Thu, May 12, 2011 at 2:34 PM, Boris Zbarsky bzbar...@mit.edu wrote:
To be clear, we are NOT designing the UI for this thing here. I'm not a UI
designer. Robert is not a UI designer. As far as I know, you are not a UI
designer.
Definitely correct on that last point.
We are trying to
On 5/12/11 6:15 PM, Jer Noble wrote:
I understand what you're saying. By making the error case deliberately
ambiguous, you're trying to force the author to behave in a certain way.
Not quite. I think Robert handled this in his response to this mail, so
I'll just stick to following that
On 5/12/11 8:29 PM, Aryeh Gregor wrote:
If we can figure out in advance what UIs browsers will want to use in
practice, though, that should inform what API we settle on.
Generality is not always good.
Yes.
If it turns out no one wants to ask the user before fullscreening
I'm 99% sure that
On Fri, May 13, 2011 at 12:29 PM, Aryeh Gregor simetrical+...@gmail.comwrote:
On Thu, May 12, 2011 at 7:02 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
For this case, I think probably a better UI would be what Flash has, to
actually go full-screen immediately but temporarily show a
On Thu, 12 May 2011, Cedric Vivier wrote:
Thanks for your thorough reply and overview of the issue.
In case it slipped through your inbox, I've posted a more up-to-date
(wrt WebGL WG discussions) and actionable proposal at :
On Tue, 3 May 2011, Matthew Delaney wrote:
The paragraph in the canvas spec that reads...
Shadows are only drawn if the opacity component of the alpha component
of the color of shadowColor is non-zero and either the shadowBlur is
non-zero, or the shadowOffsetX is non-zero, or the
On Thu, 12 May 2011, Aryeh Gregor wrote:
On Thu, May 12, 2011 at 1:58 AM, Ian Hickson i...@hixie.ch wrote:
This is something that is rife with serious security concerns:
exposing history, the potential for cross-origin data leakage,
introspecting spelling-checker user dictionaries,
On Fri, 11 Feb 2011, Glenn Maynard wrote:
On Fri, Feb 11, 2011 at 3:24 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 29 Dec 2010, Glenn Maynard wrote:
I hit this problem in a UI I worked on. It rendered into a canvas
the size of the window, which can be zoomed and scrolled around.
On Thu, May 12, 2011 at 11:34 PM, Ian Hickson i...@hixie.ch wrote:
No, ImageData exposes the underlying data, not the data in CSS pixels.
I know. That's what I was responding to: having different backing store
dimensions and dimensions exposed by ImageData doesn't make sense.
If you mean
On Fri, 13 May 2011, Glenn Maynard wrote:
On Thu, May 12, 2011 at 11:34 PM, Ian Hickson i...@hixie.ch wrote:
No, ImageData exposes the underlying data, not the data in CSS pixels.
I know. That's what I was responding to: having different backing store
dimensions and dimensions exposed
On Fri, May 13, 2011 at 3:19 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 4 May 2011, Robert O'Callahan wrote:
4) remove the no-shadow special case, but add a special case to not draw
shadows for operators other than source-over
I think I prefer #4. I have yet to hear of any use-case
On Thu, May 12, 2011 at 9:32 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Fri, May 13, 2011 at 3:19 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 4 May 2011, Robert O'Callahan wrote:
4) remove the no-shadow special case, but add a special case to not draw
shadows for operators other
On Fri, May 13, 2011 at 12:29 AM, Ian Hickson i...@hixie.ch wrote:
It's pretty much the entire point of that API. That's why it has separate
height/width information than the canvas. It has to be that way because
there's no guarantee that CSS pixels will map to device pixels -- and
that's not
On Fri, 13 May 2011, Robert O'Callahan wrote:
Can you put a note in the spec that we're thinking of changing this
behavior, so developers are less likely to start depending on it, and
we've got some cover in case it breaks some esoteric stuff that doesn't
matter for compat?
Done.
On
On Fri, 13 May 2011, Glenn Maynard wrote:
On Fri, May 13, 2011 at 12:29 AM, Ian Hickson i...@hixie.ch wrote:
It's pretty much the entire point of that API. That's why it has
separate height/width information than the canvas. It has to be that
way because there's no guarantee that CSS
51 matches
Mail list logo
