On Fri, 13 May 2011, Glenn Maynard wrote:
> On Fri, May 13, 2011 at 12:29 AM, Ian Hickson 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
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, May 13, 2011 at 12:29 AM, Ian Hickson 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 theoretic
On Thu, May 12, 2011 at 9:32 PM, Robert O'Callahan wrote:
> On Fri, May 13, 2011 at 3:19 PM, Ian Hickson 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
>> >
>>
On Fri, May 13, 2011 at 3:19 PM, Ian Hickson 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 that nee
On Fri, 13 May 2011, Glenn Maynard wrote:
> On Thu, May 12, 2011 at 11:34 PM, Ian Hickson 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 Imag
On Thu, May 12, 2011 at 11:34 PM, Ian Hickson 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 that getImageDa
On Fri, 11 Feb 2011, Glenn Maynard wrote:
> On Fri, Feb 11, 2011 at 3:24 PM, Ian Hickson 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.
> > > At
On Thu, 12 May 2011, Aryeh Gregor wrote:
> On Thu, May 12, 2011 at 1:58 AM, Ian Hickson 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 da
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 sha
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 :
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-Ma
On Fri, May 13, 2011 at 12:29 PM, Aryeh Gregor wrote:
> On Thu, May 12, 2011 at 7:02 PM, Robert O'Callahan
> 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 message
> telling
> > the user they're in
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 s
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 subt
On Thu, May 12, 2011 at 2:34 PM, Boris Zbarsky 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 design an API th
On Thu, May 12, 2011 at 1:58 AM, Ian Hickson 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 user theme pr
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",
[Re-CCing list, hope that's OK.]
On Fri, May 13, 2011 at 11:03 AM, Jer Noble wrote:
> On May 12, 2011, at 3:49 PM, Robert O'Callahan wrote:
>
> On Fri, May 13, 2011 at 10:15 AM, Jer Noble wrote:
>
>>
>>
>> I understand what you're saying. By making the error case deliberately
>> ambiguous, you
On Fri, May 13, 2011 at 4:48 AM, Jer Noble 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 becomes full
On Fri, May 13, 2011 at 10:15 AM, Jer Noble 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 how th
> * IE9 wraps all lines in (including if you start typing in an
> empty text box). If you hit Enter multiple times, it inserts empty
> s. Shift-Enter inserts .
> * Firefox 4.0 just uses for Enter and Shift-Enter,
> always. (What's _moz_dirty for?)
> * Chrome 12 dev doesn't wrap a line when you st
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
On 12 May 2011 19:06, Aryeh Gregor 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 want to implement it a
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 5/12/11 4:28 PM, Aryeh Gregor wrote:
* Firefox 4.0 just uses 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 the HTML in gene
On Wed, 13 Apr 2011, Kyle Huey wrote:
>
> Gecko 2.0 ships with a non-standard method on 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 th
Behavior for Enter in contenteditable in current browsers seems to be
as follows:
* IE9 wraps all lines in (including if you start typing in an
empty text box). If you hit Enter multiple times, it inserts empty
s. Shift-Enter inserts .
* Firefox 4.0 just uses for Enter and Shift-Enter,
always.
On 5/12/11 1:43 PM, Aryeh Gregor wrote:
On Thu, May 12, 2011 at 2:25 AM, Robert O'Callahan 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 m
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
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
Thanks for the feedback!
On Wed, May 11, 2011 at 1:39 PM, Tim Down 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
> range."
>
On Thu, May 12, 2011 at 2:25 AM, Robert O'Callahan 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 shouldn't have to be prom
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"
>> pe
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.
>
>>
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 "fullscreench
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 notificatio
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 say
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
wrote:
> On 2011-05-12 09:38 CEST, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) wrote:
>>
>> Yes, I have read that part but what confuses me
On Thu, May 12, 2011 at 1:46 PM, James May 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 browser UI o
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
wh
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;
On Thu, May 12, 2011 at 11:12 AM, Jer Noble 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 the "fu
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 Elem
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 p
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 requestFullScree
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 attribut
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
"fullscreench
On May 11, 2011, at 11:25 PM, Robert O'Callahan wrote:
> On Thu, May 12, 2011 at 4:45 PM, Jer Noble 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 states. This ha
On 5/12/11 2:25 AM, Robert O'Callahan wrote:
On Thu, May 12, 2011 at 4:45 PM, Jer Noble 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. This would be a sim
49 matches
Mail list logo
