[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 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
> telli
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
On Sat, May 14, 2011 at 7:51 AM, Aryeh Gregor wrote:
> On Fri, May 13, 2011 at 3:38 PM, Boris Zbarsky wrote:
> > I _think_ we consider that a bug in Gecko.
>
> It does violate a "should" in HTML5, added a while back in reply to that
> bug:
>
> "A br element should separate paragraphs for the purp
On Fri, May 13, 2011 at 11:35 PM, Philip Jägenstedt wrote:
> I wasn't asking how to work around the problem once you know it exists, I
> was wondering if any browser vendors have done anything to make this problem
> less likely to happen on pages like http://html5demos.com/video that don't
> do th
On Fri, May 13, 2011 at 8:52 PM, Maciej Stachowiak wrote:
> Limited or no keyboard input also greatly mitigates the risk of a full OS
> UI spoofing attack. I think there are better ways to address this than
> prompting the user. For example, for apps requesting full keyboard access,
> there could
Amazingly, our line breaking rationale is actually quite well documented!
https://wiki.mozilla.org/Gecko:Line_Breaking
Some comments on UAX#14:
http://www.cs.tut.fi/~jkorpela/unicode/linebr.html
Rob
--
"Now the Bereans were of more noble character than the Thessalonians, for
they received the mes
On Tue, May 17, 2011 at 9:09 PM, Philip Jägenstedt wrote:
> To target this specific pattern, one hypothetical solution would be to
> special-case the first script that attaches event handlers to a
> element. After it has run, all events that were already fired before the
> script are fired again.
On Wed, May 18, 2011 at 7:09 AM, Robert O'Callahan wrote:
> Sure! For certain kinds of events ("load", the video events, maybe more),
> delay the firing of such events until, say, after DOMContentLoaded has
> fired. If you're careful you might be able to make
On Wed, May 18, 2011 at 1:11 PM, Ian Hickson wrote:
> This is only a first draft, I'm not sure it's perfect. In particular,
> right now cross-origin media is not allowed at all without this attribute
> (this is not a new change, but I'm not sure it's what implementations do).
>
What exactly do y
On Thu, May 19, 2011 at 9:34 PM, Philip Jägenstedt wrote:
> Regarding user prompts, I am tentatively in favor of the approach that Jer
> appears to be arguing for, which is to never prompt the user but rather
> simply require direct user interaction in order to go to fullscreen
The rest sounds r
On Fri, May 13, 2011 at 5:53 PM, Ian Hickson wrote:
> 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
> > w
Consider this testcase:
http://people.mozilla.org/~roc/SingularCanvasMatrix.html
It sets up a rectangle to fill, then sets the current matrix to a singular
matrix (yy=0 in this case), then fills with different fillStyles. It's not
clear from the spec how this is supposed to behave, and there's not
PS, ignore the "zero-sized gradients" part of the subject. Sorry.
Rob
--
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not si
On Sat, Jun 25, 2011 at 5:38 AM, Aryeh Gregor wrote:
> I'm not familiar enough with the canvas API to have an informed
> opinion on what should happen here, but mathematically it makes sense
> to me that nothing should be drawn ever if the transform matrix is
> singular. Everything will be collap
On Sat, Jun 25, 2011 at 5:38 AM, Aryeh Gregor wrote:
> If you define different behavior for solid colors or gradients,
> doesn't that mean that they'll behave differently from if you used an
> image that looked exactly the same? That seems bad.
>
If you set up a path covering the entire canvas,
Gradients already aren't continuous where the start and end points are
equal. I think it would be OK to draw nothing as Aryeh suggests. At least
it's easy to spec and implement, and I doubt authors will care (they haven't
cared about the browser behaviors so far AFAIK).
On Mon, Jun 27, 2011 at 2:11 PM, Boris Zbarsky wrote:
> On 6/26/11 8:18 PM, Robert O'Callahan wrote:
>
>> Gradients already aren't continuous where the start and end points are
>> equal. I think it would be OK to draw nothing as Aryeh suggests. At
>> least it&#
On Wed, Jun 29, 2011 at 6:19 AM, Tab Atkins Jr. wrote:
> On Sun, Jun 26, 2011 at 5:18 PM, Robert O'Callahan
> wrote:
> > Gradients already aren't continuous where the start and end points are
> > equal. I think it would be OK to draw nothing as Aryeh suggests. At lea
On Fri, Jul 1, 2011 at 4:59 AM, Aaron Colwell wrote:
> I've also been looking at the WebRTC MediaStream API and was wondering if
> it
> makes more sense to create an object similar to the LocalMediaStream
> object.
> This has the benefits of unifying how media streams are handled independent
> of
On Sat, Jul 2, 2011 at 2:51 AM, Aaron Colwell wrote:
> On Thu, Jun 30, 2011 at 4:13 PM, Robert O'Callahan
> wrote:
>
>> On Fri, Jul 1, 2011 at 4:59 AM, Aaron Colwell wrote:
>>
>>> I've also been looking at the WebRTC MediaStream API and was wondering if
On Tue, May 31, 2011 at 9:40 AM, Robert O'Callahan wrote:
> On Fri, May 13, 2011 at 5:53 PM, Ian Hickson wrote:
>
>> On Fri, 13 May 2011, Robert O'Callahan wrote:
>> >
>> > Can you put a note in the spec that we're thinking of changing this
>>
I don't think browsers need to prompt for registerProtocolHandler. Instead,
I would simply allow any site to register as a protocol handler for almost
anything, and remember all such registrations. When the user navigates to a
URI whose protocol has had an app newly registered for it since the last
On Thu, Jul 7, 2011 at 6:41 AM, Olli Pettay wrote:
> On 07/06/2011 07:51 AM, Robert O'Callahan wrote:
>
>> I don't think browsers need to prompt for registerProtocolHandler.
>> Instead,
>> I would simply allow any site to register as a protocol handler for al
On Thu, Jul 7, 2011 at 12:53 PM, Robert O'Callahan wrote:
> On Thu, Jul 7, 2011 at 6:41 AM, Olli Pettay wrote:
>
>> On 07/06/2011 07:51 AM, Robert O'Callahan wrote:
>>
>>> I don't think browsers need to prompt for registerProtocolHandler.
>>> Ins
I like it so far, module bikeshedding. (I might call it window.currentTime.)
One question is whether you allow the value to change while a script runs.
When using the value to schedule animations, it would be helpful for the
value to only change between stable states.
If you refer to this value d
, On Fri, Jul 8, 2011 at 2:54 PM, James Robinson wrote:
> On Thu, Jul 7, 2011 at 7:36 PM, Robert O'Callahan wrote:
>
>>
>> Using this value as a clock for media synchronization sounds appealing but
>> is complicated by audio clock drift. When you play N secon
It seems to me that the spec is written assuming only one media element is
consuming the MediaSource. But nothing stops multiple elements consuming the
same URL simultaneously. Maybe instead of going through a URL you should add
API directly to media elements.
bytesAvailable is for flow control? I
On Tue, Jul 12, 2011 at 7:23 AM, Chris Rogers wrote:
> In the CoreAudio case, the AudioTimeStamp contains *both* the host-time
> (system clock) and the sample time (based on audio hardware). This creates
> a relationship between the two clocks. As an example of how these two
> clocks can be use
On Tue, Jul 12, 2011 at 1:02 PM, Glenn Maynard wrote:
> On Mon, Jul 11, 2011 at 8:57 PM, Robert O'Callahan
> wrote:
>
>> Suppose we wanted to sync animation (either scripted animation or CSS
>> animation) to audio. We'd want them to use the audio clock, right?
&g
On Wed, Jul 13, 2011 at 8:45 AM, Aaron Colwell wrote:
> I thought about adding an attribute to HTMLMediaElement that provided a URL
> for signalling MediaSource usage. That mechanism would allow you to create a
> URL that only works with that element. When this URL is specified, a
> MediaSource a
On Wed, Jul 13, 2011 at 11:14 AM, Aaron Colwell wrote:
>
> I'm open to that. In fact that is how my current prototype is implemented
> because it was the least painful way to test these ideas in WebKit. My
> prototype only implements append() and uses existing media element events as
> proxies fo
On Wed, Jul 13, 2011 at 11:30 AM, Aaron Colwell wrote:
> I'm doing WebM demuxing and media fetching in JavaScript. When a seek
> occurs, I look at currentTime to see where we are seeking to. I then look at
> the CUES index data I've fetched to find the file offset for the closest
> seek point to
On Wed, Jul 13, 2011 at 12:00 PM, Aaron Colwell wrote:
> On Tue, Jul 12, 2011 at 4:44 PM, Robert O'Callahan
> wrote:
>
>> I had imagined that this API would let the author feed in the same data as
>> you would load from some URI. But that can't be what's
On Thu, Jul 14, 2011 at 4:35 AM, Aaron Colwell wrote:
> I am open to suggestions. My intent was that the browser would not attempt
> to cache any data passed into append(). It would just demux the buffers that
> are sent in. When a seek is requested, it flushes whatever it has and waits
> for mor
On Sat, Sep 10, 2011 at 11:01 PM, Ryosuke Niwa wrote:
> Have implementors actively opposed to this idea? It seems like sticking to
> RFC is a cleaner option if possible.
>
Yeah. Will you fix it in Webkit? :-)
Rob
--
"If we claim to be without sin, we deceive ourselves and the truth is not in
On Wed, Oct 12, 2011 at 9:58 PM, Anne van Kesteren wrote:
> Is the event dispatched in the same task that makes the element or document
> go full screen?
>
No. We want to allow for asynchronous UI.
Rob
--
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we co
Thanks for working on this.
When you say "No longer any attempts at integrating with "F11 fullscreen"",
do you mean to rule out the possibility that UAs do that? E.g., would you
allow UAs to have UI that makes the current document fullscreen and sets the
fullscreen element to the root element?
I'
On Wed, Oct 19, 2011 at 11:57 PM, James Graham wrote:
> On 10/19/2011 06:40 AM, Anne van Kesteren wrote:
>
> Is that an acceptable limitation? Alternatively we could postpone the
>> nested fullscreen scenario for now (i.e. make requestFullscreen fail if
>> already fullscreen).
>>
>
> I think pun
On Tue, Nov 1, 2011 at 7:52 AM, James Graham wrote:
> On Sat, 29 Oct 2011, Robert O'Callahan wrote:
>
>> I don't think punting on nested fullscreen is a good idea. It's not some
>> edge case that most applications can't hit. For example, it will come u
On Sat, Oct 29, 2011 at 10:47 PM, Robert O'Callahan wrote:
> I don't think punting on nested fullscreen is a good idea. It's not some
> edge case that most applications can't hit. For example, it will come up
> with any content that can go full-screen and can contai
http://www.whatwg.org/specs/web-apps/current-work/#the-object-element
"The above algorithm is independent of CSS properties (including 'display',
'overflow', and 'visibility'). For example, it runs even if the element is
hidden with a 'display:none' CSS style, and does not run again if the
element'
I should add that the patch that uncovered this issue hasn't even landed on
Firefox nightlies yet (well, it was in one nightly and got reverted) so we
haven't had much testing. It seems unlikely we have found the only site
that's broken.
Rob
--
"If we claim to be without sin, we deceive ourselves
One more thing. I added a "hide and show plugin with flush" test that sets
the plugin to display:none, causes a "layout flush" (by requesting
body.getBoundingClientRect()) and then sets the plugin back to
display:inline. On Firefox, Chrome and Opera this restarts the plugin
instance; on IE9 it does
http://www.whatwg.org/specs/web-apps/current-work/#read-media
Can we allow the UA to add custom vendor-prefixed attributes to the
and/or elements? Alternatively, a vendor-prefixed class? We want to
be able to use a style sheet with rules matching custom attributes to
indicate various situations (
On Tue, Nov 15, 2011 at 1:38 AM, Anne van Kesteren wrote:
> I have removed background:black as the way the rendering is defined at the
> moment is that it cannot be overridden unless !important is used. That's
> not ideal for backgrounds.
Can you elaborate on this?
> Since no color was define
On Tue, Nov 15, 2011 at 9:25 AM, Robert O'Callahan wrote:
> Having the rest of the page visible under the fullscreen element is not
> expected and I think we should default to avoiding it. background:black
> seemed like the right thing for video and a reasonable default for ot
On Tue, Nov 15, 2011 at 1:27 AM, Anne van Kesteren wrote:
> Sorry for the late reply. Getting to and from TPAC and TPAC itself is
> basically the reason. I hope you understand.
Yeah no worries mate.
About your nested-fullscreen proposal, I do not see how
>
> To fix the nested cases, I suggest
On Tue, Nov 15, 2011 at 11:22 AM, Jeremy Apthorp wrote:
> One problem with the existing implementation in WebKit of fullscreen is
> that it is possible to focus with Tab elements that are not contained
> within the fullscreened element. This is a problem for assistive devices in
> particular.
>
>
On Tue, Nov 15, 2011 at 10:54 AM, Tab Atkins Jr. wrote:
> I think we should go the route that the element did in Ted's
> change proposal and have a pseudo-element that gets created when an
> element is fullscreened. Simple and easy, and trivial for the author
> to manipulate to get most effects
On Tue, Nov 15, 2011 at 12:38 PM, Tab Atkins Jr. wrote:
> Hm, why would it require stacking-level changes? One obvious way to
> get it to act "correctly" is to make it wrap around the element, like
> the old ::outside pseudo-element proposal. Then it's trivial.
>
The CP says "The dialog and its
On Tue, Nov 15, 2011 at 12:06 PM, Jeremy Apthorp wrote:
> On Tue, Nov 15, 2011 at 9:59 AM, Robert O'Callahan
> wrote:
>
>> On Tue, Nov 15, 2011 at 11:22 AM, Jeremy Apthorp wrote:
>>
>>> One problem with the existing implementation in WebKit of fullscreen is
&g
On Wed, Nov 16, 2011 at 12:06 AM, Henri Sivonen wrote:
> On Thu, Nov 10, 2011 at 2:03 AM, Robert O'Callahan
> wrote:
> > http://www.whatwg.org/specs/web-apps/current-work/#read-media
> > Can we allow the UA to add custom vendor-prefixed attributes to the
>
> >
On Wed, Nov 16, 2011 at 12:06 PM, Tab Atkins Jr. wrote:
> On Tue, Nov 15, 2011 at 2:07 PM, Robert O'Callahan
> wrote:
> > So I propose that a "toplevel" class be set on the root element of a
> media
> > resource document in a toplevel browsing context.
>
&
Very well then, I propose that a "toplevel" attribute be added to the root
element of media resource documents in toplevel browsing contexts :-).
Rob
--
"If we claim to be without sin, we deceive ourselves and the truth is not
in us. If we confess our sins, he is faithful and just and will forgiv
On Thu, Nov 17, 2011 at 8:20 AM, Edward O'Connor wrote:
> It seems like we shouldn't assume that these are the only two features
> that will ever need this sort of rendering support. I'll get a www-style
> thread going.
>
Thanks. If multiple specs (or even multiple running instances of the same
On Thu, Nov 17, 2011 at 3:41 AM, Anne van Kesteren wrote:
> On Wed, 26 Oct 2011 04:06:28 +0200, Robert O'Callahan <
> rob...@ocallahan.org> wrote:
>
>> I'm not comfortable with punting the nested-fullscreen cases. It means
>> that if you have a document w
On Tue, Jan 10, 2012 at 12:52 PM, Ian Hickson wrote:
> Should we still make shadows only work in source-over mode, or should we
> leave the spec as is in this area?
>
It's probably not worth changing the spec at this time.
I think it would be a bit simpler, and if we run into problems with shad
On Thu, Jan 19, 2012 at 4:09 PM, Boris Zbarsky wrote:
> Whether other UAs can fix this bug on their end faster than they can add
> various canvas APIs is an interesting discussion, I suppose.
>
Of course it's vastly better for the Web platform for browsers to fix their
bugs than add new APIs to
On Thu, Jan 19, 2012 at 4:30 PM, Elliott Sprehn wrote:
> Gecko completely punts rendering foreignObject to a canvas
>
I don't think it does. See
http://robert.ocallahan.org/2011/11/drawing-dom-content-to-canvas.html and
http://people.mozilla.org/~roc/rendering-HTML-elements-to-canvas.html. The
d
On Tue, Jan 31, 2012 at 11:10 AM, Ian Hickson wrote:
> Is there any reason you can't just put whatever styles you want into a
>
On Wed, Mar 28, 2012 at 3:43 PM, Kenneth Russell wrote:
> Production browsers already implement typed arrays with their current
> semantics. It is not possible to change them and have WebGL continue
> to function. I will go so far as to say that the semantics will not be
> changed.
>
What's the
On Wed, Mar 28, 2012 at 5:33 PM, Charles Pritchard wrote:
> It does seem like a bigger "warning" in the spec may benefit developers.
> A warning and an example of how to check for big-endian results.
>
Asking developers to write extra code paths for users that don't exist is
futile. Even if you
On Wed, Mar 28, 2012 at 8:59 PM, Charles Pritchard wrote:
> I consider your position one of benevolent paternalism. You are free to
> stick with it, and to apply it in your patch submissions.
>
> I've no desire to coddle low-level coders. They know what they're getting
> into.
>
I'm not sure wha
On Wed, Mar 28, 2012 at 9:14 PM, Charles Pritchard wrote:
> When you or Robert disparage developers as a class, that is harmful.
>
I apologise for being careless in my language. I don't intend to cast
aspersions on developers, and I should choose my words more carefully to
make that clear.
To b
On Thu, Mar 29, 2012 at 8:08 AM, Kenneth Russell wrote:
> Once DataView is available everywhere then the top priority should be
> to write educational materials regarding binary I/O. It should be
> possible to educate the web development community about correct
> practices with only a few high pr
On Thu, Mar 29, 2012 at 2:21 PM, John Tamplin wrote:
> a = someFunctionReturningUint16ArrayWhichMightBeLEorBE();
> a[4] = 100;
>
> the call to store into a might need to call Uint16LEArray or
> Uint16BEArray.storeInto under the hood. If you only ever use one, then the
> JIT'er can just assume th
On Tue, Apr 3, 2012 at 9:28 PM, Philip Jägenstedt wrote:
> AFAIK, no browser supports any format for that does not have
> timestamps.
I have patches being reviewed that add support for using MediaStreams as
sources. These do not have timestamps.
Rob
--
“You have heard that it was said, ‘Lov
This seems reasonable to me.
On Wed, Apr 4, 2012 at 11:14 AM, Ian Hickson wrote:
> This layer consists of a stack of elements, which each CSS viewport
> maintains. These stacks are initially empty. When the layer is painted,
> the elements in the stack are rendered in the order that they were
We encountered an app that uses "canplaythrough" on a video element to
trigger execution of the app "so we don't start playing the video until we
can do so without stuttering".
http://gaiamobile.org/apps/cubevid/
This approach works fine on desktop browsers. On mobile browsers, we want a
smaller li
On Thu, May 31, 2012 at 5:37 AM, Andrew Scherkus wrote:
> Rob: when you say to suspend a download indefinitely would this coincide
> with dropping the networkState to NETWORK_IDLE and subsequently firing a
> suspend event?
>
Yes.
I'm not sure whether we want to require that the readyState go to
On Tue, Jun 5, 2012 at 9:13 AM, Jer Noble wrote:
> On Jun 1, 2012, at 6:45 PM, Chris Pearce wrote:
>
> > Because we exit fullscreen when the fullscreen element is removed from
> the document, so if you dispatch events to the context element, the
> "fullscreenchange" event never bubbles up to the
On Tue, Jun 5, 2012 at 5:57 PM, Jer Noble wrote:
> > Actually, in WebKit, we explicitly also message the document from which
> the element was removed in that case. I don't see why this behavior
> couldn't be standardized.
> >
> > Did you inform the spec editor(s) when you decided to make this c
What do you do when element A goes fullscreen and then element B in the
same document goes fullscreen on top of it? Do you fire a single
fullscreenchange event at B? Or do you fire a fullscreenchange event at A
and then at B? Or something else?
Rob
--
“You have heard that it was said, ‘Love your
On Tue, Jun 26, 2012 at 8:22 AM, Tab Atkins Jr. wrote:
> The ability to capture sound and video from the user's devices and
> manipulate it in the page is already being exposed by the getUserMedia
> function. Theoretically, a Kinect can provide this information.
>
> More advanced functionality li
On Tue, Jul 17, 2012 at 4:34 PM, Rik Cabanier wrote:
> I agree that it would be great to have filter effects in Canvas. It should
> be fairly efficient if you have a GPU backend since the effects can all be
> done with shaders so it should take up too much memory.
> This workflow could even suppo
On Wed, Aug 1, 2012 at 10:33 AM, Adam Barth wrote:
> It's not clear to me from the spec how the allowfullscreen attribute
> works. It appears to be mentioned only in the security and privacy
> considerations section. For example, suppose I have three frames:
>
> Main frame: a.html
> ->
>
On Sat, May 17, 2014 at 4:18 AM, Anne van Kesteren wrote:
> Maybe we should have .srcObject similar to what we're doing for
> media elements. .src can simply return about:imagebitmap or some
> such. That way you can also assign a Blob to an element without
> having to do the weird createObjectUR
On Sat, May 31, 2014 at 3:44 AM, Justin Novosad wrote:
> My point is, we need a proper litmus test for the "just do it in script"
> argument because, let's be honnest, a lot of new features being added to
> the Web platform could be scripted efficiently, and that does not
> necessarily make them
[Resurrecting old thread]
On Tue, Sep 10, 2013 at 12:00 PM, Ian Hickson wrote:
> 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
I just discovered
https://svgwg.org/svg2-draft/embedded.html
This looks very problematic. It ties SVG and HTML5 together in
uncomfortable ways. For example, SVGIframeElement as specced has two
"width" attributes. It's unclear how to keep this making sense as SVG and
HTML5 evolve, e.g. as new attrib
On Thu, Jun 19, 2014 at 3:30 AM, Justin Novosad wrote:
> I am currently trying an experimental approach where canvases that are
> drawn to, but never read from (no toDataURL or getImageData calls) have
> their contents stored as a command buffer, rather than a pixel buffer.
>
There must be a cli
On Thu, Jun 19, 2014 at 11:52 AM, Robert O'Callahan
wrote:
> On Thu, Jun 19, 2014 at 3:30 AM, Justin Novosad wrote:
>
>> I am currently trying an experimental approach where canvases that are
>> drawn to, but never read from (no toDataURL or getImageData calls) have
>
On Fri, Jun 20, 2014 at 2:54 AM, Stephen White
wrote:
> I assume that the size change event would fire:
>
>- on browser page zoom
>- on pinch-zoom
>- when a CSS animation (e.g., scale) changes the canvas size in CSS
>pixels
>
> For browsers that implement the latter two off the ma
On Fri, Jun 20, 2014 at 7:32 AM, Justin Novosad wrote:
> +1 from me too. But I have one concern in terms of future proofing, because
> I would like to keep the door open for auto-resizing as a possible future
> improvement. In an eventual auto-resize proposal, we will want to make
> the "preferre
On Fri, Jun 20, 2014 at 6:06 AM, Kenneth Russell wrote:
> It is a little unfortunate that a canvas-specific solution is needed.
> Is it known whether document.getBoxQuads solves this problem in
> Firefox?
>
It doesn't.
Gecko (and I assume other engines) typically snaps CSS box edges to device
p
On Tue, Jun 24, 2014 at 8:54 AM, Kenneth Russell wrote:
> It's hard to predict. A more general API would be better than a
> canvas-specific one, assuming it solves the problem. getBoxQuads can
> return different types of CSS boxes (content, padding, border, margin)
> -- will it be obvious to web
On Tue, Jun 24, 2014 at 11:44 AM, Kenneth Russell wrote:
> If there's no concern about potential duplicated functionality then
> let's add the attributes to the canvas element. They'll be easier for
> developers to understand and easier to verify as obviously correct.
>
> How should we proceed? W
On Tue, Jun 24, 2014 at 12:27 PM, Robert O'Callahan
wrote:
> I'll do that now.
>
Done.
http://wiki.whatwg.org/wiki/CanvasRenderedPixelSize
Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r&qu
On Thu, Jun 19, 2014 at 4:33 AM, Tab Atkins Jr.
wrote:
> Yes, increasing the set of name-alikes between html and svg is absolutely
> not something we'll support. (I've unfortunately been out of the loop with
> the svgwg for a while, or else I would have prevented this from showing up
> in the fir
On Wed, Jun 25, 2014 at 3:30 PM, Rik Cabanier wrote:
> Add a new event renderedsizechange to HTMLCanvasElement. This event does
> not bubble and is not cancelable. Whenever the value that would be returned
> by renderedPixelWidth orrenderedPixelHeight changes, queue a task to fire
> renderedsizec
On Thu, Jun 26, 2014 at 2:49 AM, Justin Novosad wrote:
> I was wondering if there is anything we can do with this feature to prevent
> web apps from creating layout feedback loops. What I mean is that if the
> event listener for renderedsizechange changes the layout of the page in a
> way that d
On Thu, Jun 26, 2014 at 10:10 AM, Robert O'Callahan
wrote:
> On Thu, Jun 26, 2014 at 2:49 AM, Justin Novosad wrote:
>
>> I was wondering if there is anything we can do with this feature to
>> prevent
>> web apps from creating layout feedback loops. What I mean is
On Thu, Jun 26, 2014 at 10:13 AM, Robert O'Callahan
wrote:
> To clarify, I think a version of option #1 would be the best way to go.
> renderedPixelWidth would return the current canvas buffer width when the
> canvas element's CSS specified value for 'width' is &#x
On Fri, Jun 27, 2014 at 2:00 AM, Justin Novosad wrote:
> Hadn't thought of that. object-fit seems smells dangerous. I think we may
> need to define explicit behaviors for renderedPixelWidth/Height for the
> different object fit modes.
I don't think so. Given renderedPixelWidth/Height returns th
On Sat, Jun 28, 2014 at 3:41 AM, Justin Novosad wrote:
> Example of a problematic renderedsizechange event listener:
>
> canvas.width = Math.floor(canvas.renderedPixelWidth * myPixelScale);
> canvas.height = Math.floor(canvas.renderedPixelHeight * myPixelScale);
>
I don't know why anyone would a
On Thu, Jul 3, 2014 at 3:03 AM, Justin Novosad wrote:
> On Fri, Jun 27, 2014 at 6:42 PM, Robert O'Callahan
> wrote:
> This behavior seems sound at first glance, but because that arithmetic may
> >> induce a change to the intrinsic aspect ratio due to rounding, step 3)
If you want jank-free canvas rendering, you probably really want WebGL
drawing from a Worker.
Rob
--
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oa
It looks reasonable to me.
How do these calls interact with globalAlpha etc? You talk about
decomposing them to individual drawImage calls; does that mean each image
draw is treated as a separate composite operation?
Currently you have to choose between using a single image or passing an
array wi
On Mon, Sep 29, 2014 at 2:12 PM, Rik Cabanier wrote:
> Can we limit it to just the set of CSS filter shorthands for now?
> I think other UA's are further behind in their implementation of
> integrating SVG filters in their rendering pipeline.
>
How about we put CSS + SVG filters into the one spe
601 - 700 of 747 matches
Mail list logo
