Re: [whatwg] Processing the zoom level - MS extensions to window.screen

On 11/23/2010 6:46 PM, Robert O'Callahan wrote: On Wed, Nov 24, 2010 at 3:30 PM, Charles Pritchard > wrote: SVG is a document format. It is not reliably implemented. It's far more expensive to implement SVG on a new environment than Canvas. So? You don't have

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

On 11/23/10 9:30 PM, Charles Pritchard wrote: Most uses of canvas involve keeping state-info around in order to redraw the screen. Quite a number do, yes. A number don't. I'll challenge you on this one: I don't think there are a number of them that don't. We may just have a different idea about

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

On Wed, Nov 24, 2010 at 3:30 PM, Charles Pritchard wrote: > SVG is a document format. It is not reliably implemented. It's far more > expensive to implement SVG on a new environment than Canvas. > So? You don't have to implement it. I can't do much for you here other than explain to you what

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

Message: 1 Date: Mon, 22 Nov 2010 15:27:40 -0500 From: Boris Zbarsky To: whatwg@lists.whatwg.org Subject: Re: [whatwg] Processing the zoom level - MS extensions to window.screen Message-ID:<4cead23c.1000...@mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 11/22/10

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

On 11/23/10 5:06 PM, Robert O'Callahan wrote: On Wed, Nov 24, 2010 at 1:53 PM, Kevin Marks > wrote: Well, if we care about doing video processing with Canvas, understanding anamorphic pixels is needed. You mean the aspect ratio of the video source? Sure, bu

Re: [whatwg] CSS canvas() function

On Wed, Nov 24, 2010 at 2:23 PM, Tab Atkins Jr. wrote: > For example, I've recently been playing with fractals in canvas, and > temporarily set my blog to have a screen-filling canvas z-index'd > below the content, filled with an interactive fractal (the mandelbrot > set, overlaid with the julia s

Re: [whatwg] CSS canvas() function

On Tue, Nov 23, 2010 at 4:59 PM, Robert O'Callahan wrote: > On Wed, Nov 24, 2010 at 1:13 PM, Tab Atkins Jr. > wrote: >> Webkit has for some time now supported using the -webkit-canvas() >> function in CSS anywhere you could use an image >> (, publis

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

On Wed, Nov 24, 2010 at 1:53 PM, Kevin Marks wrote: > Well, if we care about doing video processing with Canvas, understanding > anamorphic pixels is needed. You mean the aspect ratio of the video source? Sure, but here we're talking about the output device. Anyway, adding APIs to help browser

Re: [whatwg] CSS canvas() function

On Wed, Nov 24, 2010 at 1:13 PM, Tab Atkins Jr. wrote: > Webkit has for some time now supported using the -webkit-canvas() > function in CSS anywhere you could use an image > (, published in April > 2008). The function takes an ident, which can then

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

Well, if we care about doing video processing with Canvas, understanding anamorphic pixels is needed. On Tue, Nov 23, 2010 at 4:50 PM, Robert O'Callahan wrote: > On Wed, Nov 24, 2010 at 1:24 PM, Kevin Marks wrote: > >> Most video displays have non-square pixels. Standard definition video >> proc

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

On Wed, Nov 24, 2010 at 1:24 PM, Kevin Marks wrote: > Most video displays have non-square pixels. Standard definition video > processing resolutions are 720 by 480 for NTSC and 720 by 576 for PAL though > both are 4 by 3 aspect ratio. > You can argue whether tv standards count as modern, but ther

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

Most video displays have non-square pixels. Standard definition video processing resolutions are 720 by 480 for NTSC and 720 by 576 for PAL though both are 4 by 3 aspect ratio. You can argue whether tv standards count as modern, but there are a lot out there. On 21 Nov 2010 16:56, "Robert O'Callah

[whatwg] CSS canvas() function

(This is being sent to the WHATWG list, rather than the CSSWG list, as it seems like the sort of thing that should be primarily defined in HTML, with a CSS spec just referring to the HTML definition, like :active and similar things.) Webkit has for some time now supported using the -webkit-canvas(

Re: [whatwg] Canvas gradients color interpolation - change to premultiplied?

On Tuesday 2010-11-23 22:09 +, Philip Taylor wrote: > On Tue, Nov 23, 2010 at 8:43 PM, Tab Atkins Jr. wrote: > > Right now, canvas gradients interpolate their colors in > > non-premultiplied space; that is, the raw values of r, g, b, and a are > > interpolated independently.  This has the unfo

Re: [whatwg] Canvas gradients color interpolation - change to premultiplied?

On Tue, Nov 23, 2010 at 2:09 PM, Philip Taylor wrote: > On Tue, Nov 23, 2010 at 8:43 PM, Tab Atkins Jr. wrote: >> Right now, canvas gradients interpolate their colors in >> non-premultiplied space; that is, the raw values of r, g, b, and a are >> interpolated independently.  This has the unfortun

Re: [whatwg] Canvas gradients color interpolation - change to premultiplied?

On Tue, Nov 23, 2010 at 2:09 PM, Philip Taylor wrote: > On Tue, Nov 23, 2010 at 8:43 PM, Tab Atkins Jr. wrote: >> Right now, canvas gradients interpolate their colors in >> non-premultiplied space; that is, the raw values of r, g, b, and a are >> interpolated independently.  This has the unfortun

Re: [whatwg] Canvas gradients color interpolation - change to premultiplied?

On Tue, Nov 23, 2010 at 8:43 PM, Tab Atkins Jr. wrote: > Right now, canvas gradients interpolate their colors in > non-premultiplied space; that is, the raw values of r, g, b, and a are > interpolated independently.  This has the unfortunate effect that > colors darken as they transition to transp

Re: [whatwg] classList should perhaps move from HTMLElement to Element

On Tue, Nov 23, 2010 at 12:25 PM, Anne van Kesteren wrote: > On Tue, 23 Nov 2010 21:04:37 +0100, Jonas Sicking wrote: >> >> I agree that unless we get other groups in on this change, and get >> things like SVG cross-references and CSS styling reacting to these id >> and class-list changes, then w

[whatwg] Canvas gradients color interpolation - change to premultiplied?

Right now, canvas gradients interpolate their colors in non-premultiplied space; that is, the raw values of r, g, b, and a are interpolated independently. This has the unfortunate effect that colors darken as they transition to transparent, as "transparent" is defined as "rgba(0,0,0,0)", a transpa

Re: [whatwg] classList should perhaps move from HTMLElement to Element

On Tue, 23 Nov 2010 21:04:37 +0100, Jonas Sicking wrote: I agree that unless we get other groups in on this change, and get things like SVG cross-references and CSS styling reacting to these id and class-list changes, then we're just making things more confusing by making the DOM pretend that th

Re: [whatwg] classList should perhaps move from HTMLElement to Element

On Tue, Nov 23, 2010 at 11:06 AM, Boris Zbarsky wrote: > On 11/23/10 2:02 PM, Anne van Kesteren wrote: >> >> So if I set Element.className on an element that is not in a namespace >> and has no attributes. Its attributes collection remains empty or >> something? > > Hmm.  I would think this should

Re: [whatwg] classList should perhaps move from HTMLElement to Element

On 11/23/10 2:08 PM, Anne van Kesteren wrote: I would much rather just make it work. Otherwise moving it to Element does not really seem right. Note that I only suggested moving classList (which I think should return null if the element doesn't actually support classes). -Boris

Re: [whatwg] classList should perhaps move from HTMLElement to Element

On Tue, 23 Nov 2010 20:06:02 +0100, Boris Zbarsky wrote: On 11/23/10 2:02 PM, Anne van Kesteren wrote: So if I set Element.className on an element that is not in a namespace and has no attributes. Its attributes collection remains empty or something? Hmm. I would think this should throw (sin

Re: [whatwg] classList should perhaps move from HTMLElement to Element

On 11/23/10 2:02 PM, Anne van Kesteren wrote: So if I set Element.className on an element that is not in a namespace and has no attributes. Its attributes collection remains empty or something? Hmm. I would think this should throw (since this won't do what you expect; e.g. CSS selectors and g

Re: [whatwg] classList should perhaps move from HTMLElement to Element

On Tue, 23 Nov 2010 19:48:03 +0100, Boris Zbarsky wrote: On 11/23/10 12:58 PM, Anne van Kesteren wrote: So that you do not need namespace knowledge. Namespace knowledge where? As an implementor? Or as an author? Either? The whole point if a universal .classList and .className is to make

Re: [whatwg] classList should perhaps move from HTMLElement to Element

On 11/23/10 12:58 PM, Anne van Kesteren wrote: Why do we want to tie .className to a particular attribute name? I agree it may not be that convenient for authors if a particular language wants to use some other attr name for classes, but presumably they'd have really good reasons for doing that i

Re: [whatwg] classList should perhaps move from HTMLElement to Element

On Tue, 23 Nov 2010 18:50:06 +0100, Jeff Schiller wrote: While we're on the topic of commonizing things at Element - can we introduce an 'inner' property on Element? This would map to innerHTML for HTMLElements. Other languages could introduce parsing rules for getting/setting that property

Re: [whatwg] classList should perhaps move from HTMLElement to Element

On Tue, 23 Nov 2010 18:37:51 +0100, Boris Zbarsky wrote: On 11/23/10 12:20 PM, Anne van Kesteren wrote: My plan is to define Element.id, Element.className, Element.classList, and getElementsByClassName in DOM Core. And tie getElementById to Element.id somehow, tie Element.id to an attribute nam

Re: [whatwg] classList should perhaps move from HTMLElement to Element

While we're on the topic of commonizing things at Element - can we introduce an 'inner' property on Element? This would map to innerHTML for HTMLElements. Other languages could introduce parsing rules for getting/setting that property. Presumably XML grammars would use the rules at http://dev.w3

Re: [whatwg] classList should perhaps move from HTMLElement to Element

On 11/23/10 12:20 PM, Anne van Kesteren wrote: My plan is to define Element.id, Element.className, Element.classList, and getElementsByClassName in DOM Core. And tie getElementById to Element.id somehow, tie Element.id to an attribute named "id", and Element.className to an attribute named "class

Re: [whatwg] need a way to set output format from StreamRecorder

On Fri, 19 Nov 2010 19:50:42 +0100, Per-Erik Brodin wrote: We are about to start implementing stream.record() and StreamRecorder. The spec currently says that “the file must be in a format supported by the user agent for use in audio and video elements” which is a reasonable restriction. H

Re: [whatwg] classList should perhaps move from HTMLElement to Element

On Fri, 19 Nov 2010 17:34:29 +0100, Boris Zbarsky wrote: Given that SVG also has classes, it would make some sense to move classList from HTMLElement to Element. That way SVG, and any other languages that define classes (XUL comes to mind, actually) can benefit from it as well. Note that

Re: [whatwg] DOMTimeStamp in W3C Core 3

Thanks, Anne. That's very helpful. On Tue, Nov 23, 2010 at 2:34 PM, Anne van Kesteren wrote: > On Tue, 23 Nov 2010 15:29:00 +0100, John Knottenbelt > wrote: >> >> Do you know where i can find the WebIDL spec that mentions >> DOMTimeStamp? I couldn't find a reference to it in >> http://www.w3.org

Re: [whatwg] DOMTimeStamp in W3C Core 3

On Tue, 23 Nov 2010 15:29:00 +0100, John Knottenbelt wrote: Do you know where i can find the WebIDL spec that mentions DOMTimeStamp? I couldn't find a reference to it in http://www.w3.org/TR/2010/WD-WebIDL-20101021/ . http://dev.w3.org/2006/webapi/WebIDL/#common-DOMTimeStamp I wonder why the

Re: [whatwg] DOMTimeStamp in W3C Core 3

Many thanks, Anne. Do you know where i can find the WebIDL spec that mentions DOMTimeStamp? I couldn't find a reference to it in http://www.w3.org/TR/2010/WD-WebIDL-20101021/ . On Tue, Nov 23, 2010 at 1:50 PM, Anne van Kesteren wrote: > On Tue, 23 Nov 2010 11:52:12 +0100, John Knottenbelt > wro

Re: [whatwg] DOMTimeStamp in W3C Core 3

On Tue, 23 Nov 2010 11:52:12 +0100, John Knottenbelt wrote: Can anybody hazard a guess as to when the DOM Level 3 TR might be updated with this change? DOMTimeStamp is now defined in Web IDL. DOM Core is now http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html -- Anne van Kesteren h

[whatwg] DOMTimeStamp in W3C Core 3

I was recently tripped up by a difference between published the W3C DOM Level 3 Core TR and standard practice. The issue is that the TR states that DOMTimeStamp should be bound to a Date object in ECMAScript ( http://www.w3.org/TR/DOM-Level-3-Core/core.html#Core-DOMTimeStamp ). But in practice, m