[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, most existing implementations bind DOMTimeStamp to a Number. This was observed on what-wg before: http://www.mail-archive.com/whatwg@lists.whatwg.org/msg13626.html And there is an intention to change the DOM Core 3 so that DOMTimeStamp be bound to a number for ECMAScript: http://www.w3.org/TR/DOM-Level-3-Events/#changes-DOMLevel2to3Changes Event.timeStamp is now a Number in the ECMAScript binding; a proposed correction to make the same change in [DOM3 Core] is forthcoming. and an action here: http://www.w3.org/2008/webapps/track/actions/417 Can anybody hazard a guess as to when the DOM Level 3 TR might be updated with this change? Many thanks John
Re: [whatwg] DOMTimeStamp in W3C Core 3
On Tue, 23 Nov 2010 11:52:12 +0100, John Knottenbelt jknot...@chromium.org 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 http://annevankesteren.nl/
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 ann...@opera.com wrote: On Tue, 23 Nov 2010 11:52:12 +0100, John Knottenbelt jknot...@chromium.org 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 http://annevankesteren.nl/
Re: [whatwg] DOMTimeStamp in W3C Core 3
On Tue, 23 Nov 2010 15:29:00 +0100, John Knottenbelt jknot...@chromium.org 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 TR/ version does not include a link there. TR/ is almost always out of date. -- Anne van Kesteren http://annevankesteren.nl/
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 ann...@opera.com wrote: On Tue, 23 Nov 2010 15:29:00 +0100, John Knottenbelt jknot...@chromium.org 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 TR/ version does not include a link there. TR/ is almost always out of date. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Fri, 19 Nov 2010 17:34:29 +0100, Boris Zbarsky bzbar...@mit.edu 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 Gecko's current classList implementation lives on Element. 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. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] need a way to set output format from StreamRecorder
On Fri, 19 Nov 2010 19:50:42 +0100, Per-Erik Brodin per-erik.bro...@ericsson.com 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. However, there is currently no way to set the output format of the resulting File that you get from recorder.stop(). It is unlikely that specifying a default format would be sufficient if you in addition to container formats and codecs consider resolution, color depth, frame rate etc. for video and sample size and rate, number of channels etc. for audio. Perhaps an argument should be added to record() that specifies the output format from StreamRecorder as a MIME type with parameters? Since record() should probably throw when an unsupported type is supplied, it would perhaps be useful to have a canRecordType() or similar to be able to test for supported formats. But if we want interoperability for streams, also taking into account P2P messaging, we need a single format. Otherwise users with different browsers could end up not being able to communicate. -- Anne van Kesteren http://annevankesteren.nl/
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. 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 if they do it at all? -Boris
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.org/html5/spec/apis-in-html-documents.html#innerhtml Jeff On Tue, Nov 23, 2010 at 9:20 AM, Anne van Kesteren ann...@opera.com wrote: On Fri, 19 Nov 2010 17:34:29 +0100, Boris Zbarsky bzbar...@mit.edu 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 Gecko's current classList implementation lives on Element. 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. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Tue, 23 Nov 2010 18:37:51 +0100, Boris Zbarsky bzbar...@mit.edu 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 named id, and Element.className to an attribute named class. 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 if they do it at all? So that you do not need namespace knowledge. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Tue, 23 Nov 2010 18:50:06 +0100, Jeff Schiller codedr...@gmail.com 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. Presumably XML grammars would use the rules at http://dev.w3.org/html5/spec/apis-in-html-documents.html#innerhtml http://html5.org/specs/dom-parsing.html It's simply called Element.innerHTML. -- Anne van Kesteren http://annevankesteren.nl/
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 if they do it at all? So that you do not need namespace knowledge. Namespace knowledge where? As an implementor? Or as an author? The whole point if a universal .classList and .className is to make authors not have to deal with namespace knowledge, imo. And it doesn't require mapping to a specific attr name for that. -Boris
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Tue, 23 Nov 2010 19:48:03 +0100, Boris Zbarsky bzbar...@mit.edu 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 authors not have to deal with namespace knowledge, imo. And it doesn't require mapping to a specific attr name for that. 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? -- Anne van Kesteren http://annevankesteren.nl/
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 getElemetsByClassName won't start matching it). -Boris
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Tue, 23 Nov 2010 20:06:02 +0100, Boris Zbarsky bzbar...@mit.edu 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 (since this won't do what you expect; e.g. CSS selectors and getElemetsByClassName won't start matching it). I would much rather just make it work. Otherwise moving it to Element does not really seem right. -- Anne van Kesteren http://annevankesteren.nl/
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, Nov 23, 2010 at 11:06 AM, Boris Zbarsky bzbar...@mit.edu 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 (since this won't do what you expect; e.g. CSS selectors and getElemetsByClassName won't start matching it). 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 the class changed, when no other systems agree. / Jonas
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Tue, 23 Nov 2010 21:04:37 +0100, Jonas Sicking jo...@sicking.cc 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 the class changed, when no other systems agree. Well yes, obviously .class notation, #id, etc. would all have to remain functioning. To me it makes sense to define ID/class-ness at the DOM level. CSS operates on that level too. -- Anne van Kesteren http://annevankesteren.nl/
[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 transparent black. Under this scheme, the color halfway between yellow and transparent is rgba(127,127,0,.5), a partially-transparent dark yellow, rather than rgba(255,255,0,.5).* The rest of the platform has switched to using premultiplied colors for interpolation, because they react better in cases like this**. CSS transitions and CSS gradients now explicitly use premultiplied colors, and SVG ends up interpolating similarly (they don't quite have the same problem - they track opacity separate from color, so transitioning from color:yellow;opacity:1 to color:yellow;opacity:0 gives you color:yellow;opacity:.5 in the middle, which is the moral equivalent of rgba(255,255,0,.5)). It would be unfortunate for canvas gradients to be the only part of the platform that interpolates colors in a different and generally uglier way here. I suspect that this can be changed without any real compat impact; the change will be a minor visual tweak to the middle half of gradients that go from a solid color to transparent (the initial and final quarter won't be noticeably different, solid-solid transitions aren't affected, and other transitions trace a shorter line and thus diverge from the pretty behavior less). I realize that this basically just depends on whether browsers are willing to change their current implementation. Implementors, does this sounds like a change you can get behind? We already changed canvas shadows to match behavior with CSS shadows; this is a much smaller change for spec-equivalence. ~TJ * An even more obvious example can be seen by drawing a white-transparent gradient in a white rect on canvas. This should pretty obviously just result in more white, right? Instead, you get a symmetrical fade from white to gray and back to white. (The reason it reverses halfway through is because it's now less than half opacity, so the background white is winning when it's composed with the gradient color. The gradient is actually still getting darker until it hits black at the end, it just contributes less and less of that darkness to the final color of the pixels.) ** Quick primer for those who don't understand color math well enough to follow the conversation (like me from a few days ago): Premultiplied means that you multiply the color components by the alpha component before doing compositing operations. It turns out that this lets you get away with some simpler and faster math when compositing partially-transparent colors while getting equivalent results, so it's a common optimization. The effect of this is that the space of colors gets compressed as the alpha shrinks. If the alpha is .5, then the total value range for the color components is only 0-127. If the alpha is .1, the range is 0-25. This doesn't produce a material change in behavior, due to the way the compositing math works. The only downside is that if you lose precision in the exact color, if you want to extract that back out from the premultiplied version - there are only 26^3 possible colors at alpha=.1, as opposed to the 255^3 colors at alpha=1. A nice benefit of this, though, is that tracing a straight line between two colors in premultiplied space gives you a more attractive transitions than doing so in non-premultiplied (that is, normal rgba) space. As I noted above, the color halfway between yellow and transparent (defining transparent as transparent black, or rgba(0,0,0,0)) is rgba(127,127,0,.5) in non-premultiplied space, which has a dark yellow as its color component. In premultiplied space, the midpoint is the 4-tuple (127,127,0,.5), which translates to the color rgba(255,255,0,.5) when you extract it back into normal rgba space. Of course, in normal rgba space you could fix this by explicitly transitioning from yellow to transparent yellow (in other words, from rgba(255,255,0,1) to rgba(255,255,0,0)), but that's more work. In premultiplied space, all fully-transparent colors are equivalent, and naive transitions always do the right thing. ~TJ
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Tue, Nov 23, 2010 at 12:25 PM, Anne van Kesteren ann...@opera.com wrote: On Tue, 23 Nov 2010 21:04:37 +0100, Jonas Sicking jo...@sicking.cc 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 the class changed, when no other systems agree. Well yes, obviously .class notation, #id, etc. would all have to remain functioning. To me it makes sense to define ID/class-ness at the DOM level. CSS operates on that level too. Right; CSS doesn't care what the underlying language is doing; it only cares that, when mapping from the underlying language to the CSS element-tree, there are things called elements arranged in a tree structure, which have ids, classes, and attributes. It just so happens that in HTML, the mapping is trivial. Theoretically CSS isn't tied in any way to HTML or XML. The WebSRT mapping to CSS, for example, shows how a language that isn't explicitly tree-based can still be mapped into a CSS element-tree and then styled. ~TJ
Re: [whatwg] Canvas gradients color interpolation - change to premultiplied?
On Tue, Nov 23, 2010 at 8:43 PM, Tab Atkins Jr. jackalm...@gmail.com 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 transparent, as transparent is defined as rgba(0,0,0,0), a transparent black. Under this scheme, the color halfway between yellow and transparent is rgba(127,127,0,.5), a partially-transparent dark yellow, rather than rgba(255,255,0,.5).* If you define the gradient as interpolating from solid yellow to transparent black, I'd expect that it *should* be semi-transparent blackish-yellow in the middle. If you want it to be pure yellow, don't use a keyword which is explicitly specified as transparent black - define the gradient from rgba(255,255,0,1) to rgba(255,255,0,0) instead. Then you'll get rgba(255,255,0,0.5) in the middle. The rest of the platform has switched to using premultiplied colors for interpolation, because they react better in cases like this**. CSS transitions and CSS gradients now explicitly use premultiplied colors, and SVG ends up interpolating similarly (they don't quite have the same problem - they track opacity separate from color, so transitioning from color:yellow;opacity:1 to color:yellow;opacity:0 gives you color:yellow;opacity:.5 in the middle, which is the moral equivalent of rgba(255,255,0,.5)). That sounds like SVG gradients *can't* be using premultiplied colours. A transition from color:yellow;opacity:1 to color:black;opacity:0 will have rgba(127,127,0,0.5) in the middle, and it's impossible to get that if you are using premultiplied colours. You'd have to have A=1 at the start and A=0 at the end, so (with premultiplied colour) the end would be interpreted as rgba(0,0,0,0), so you'd get the same as interpolating to color:yellow;opacity:0 (i.e. rgba(255,255,0,0.5) in the middle), which is not what SVG does. http://www.w3.org/TR/SVGTiny12/painting.html#Gradients says explicitly its behaviour is the non-premultiplied behaviour we currently get with canvas. (gradient from fully transparent red, via partly transparent dark yellow, to fully opaque lime - the RGB components of fully transparent colours are preserved.) Maybe CSS should have originally used the keyword transparentblack instead of transparent (though the distinction didn't matter before gradients existed) - changing the gradient algorithm solely to work more intuitively when people happen to use that one particular incorrectly-named keyword seems backwards, and a mistake in CSS. (Perhaps CSS gradients could avoid this problem by overriding the meaning of the transparent keyword, so that instead of rgba(0,0,0,0) it means A=0 with the mean RGB of the adjacent colour stops. That would let it work as people naturally expect when they use that keyword, and they can use the rgba() syntax if they really want transparent black or transparent yellow or transparent red etc.) -- Philip Taylor exc...@gmail.com
Re: [whatwg] Canvas gradients color interpolation - change to premultiplied?
On Tue, Nov 23, 2010 at 2:09 PM, Philip Taylor excors+wha...@gmail.com wrote: On Tue, Nov 23, 2010 at 8:43 PM, Tab Atkins Jr. jackalm...@gmail.com 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 transparent, as transparent is defined as rgba(0,0,0,0), a transparent black. Under this scheme, the color halfway between yellow and transparent is rgba(127,127,0,.5), a partially-transparent dark yellow, rather than rgba(255,255,0,.5).* If you define the gradient as interpolating from solid yellow to transparent black, I'd expect that it *should* be semi-transparent blackish-yellow in the middle. If you want it to be pure yellow, don't use a keyword which is explicitly specified as transparent black - define the gradient from rgba(255,255,0,1) to rgba(255,255,0,0) instead. Then you'll get rgba(255,255,0,0.5) in the middle. For what it's worth, I suspect most people don't think of transparent as transparent black, but rather as fully see-through. / Jonas
Re: [whatwg] Canvas gradients color interpolation - change to premultiplied?
On Tue, Nov 23, 2010 at 2:09 PM, Philip Taylor excors+wha...@gmail.com wrote: On Tue, Nov 23, 2010 at 8:43 PM, Tab Atkins Jr. jackalm...@gmail.com 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 transparent, as transparent is defined as rgba(0,0,0,0), a transparent black. Under this scheme, the color halfway between yellow and transparent is rgba(127,127,0,.5), a partially-transparent dark yellow, rather than rgba(255,255,0,.5).* If you define the gradient as interpolating from solid yellow to transparent black, I'd expect that it *should* be semi-transparent blackish-yellow in the middle. If you want it to be pure yellow, don't use a keyword which is explicitly specified as transparent black - define the gradient from rgba(255,255,0,1) to rgba(255,255,0,0) instead. Then you'll get rgba(255,255,0,0.5) in the middle. The fact that transparent means transparent black is a technical detail that is usually irrelevant. A fully transparent color doesn't really have a color at all. I'm highly technical, involved in the relevant specs, and understand the underlying math, and I *still* get tripped up over the fact that transparent is black. The rest of the platform has switched to using premultiplied colors for interpolation, because they react better in cases like this**. CSS transitions and CSS gradients now explicitly use premultiplied colors, and SVG ends up interpolating similarly (they don't quite have the same problem - they track opacity separate from color, so transitioning from color:yellow;opacity:1 to color:yellow;opacity:0 gives you color:yellow;opacity:.5 in the middle, which is the moral equivalent of rgba(255,255,0,.5)). That sounds like SVG gradients *can't* be using premultiplied colours. A transition from color:yellow;opacity:1 to color:black;opacity:0 will have rgba(127,127,0,0.5) in the middle, and it's impossible to get that if you are using premultiplied colours. You'd have to have A=1 at the start and A=0 at the end, so (with premultiplied colour) the end would be interpreted as rgba(0,0,0,0), so you'd get the same as interpolating to color:yellow;opacity:0 (i.e. rgba(255,255,0,0.5) in the middle), which is not what SVG does. Luckily I didn't say that SVG used premultiplied colors. ^_^ I said they end up interpolating in a similar way, if you do the obvious thing and just adjust the opacity. When using CSS colors, the obvious thing is to use the transparent keyword, which gives unsatisfactory behavior most of the time if you transition in plain rgba space. Maybe CSS should have originally used the keyword transparentblack instead of transparent (though the distinction didn't matter before gradients existed) - changing the gradient algorithm solely to work more intuitively when people happen to use that one particular incorrectly-named keyword seems backwards, and a mistake in CSS. Possibly, but that can't be fixed now, and so as a result both Transitions/Animations and Gradients use premultiplied colors, and won't likely change (I know that Apple and Moz support using premultiplied colors in transitions and gradients). Making canvas gradients match CSS seems like a better idea than the reverse at this point, and seems more likely to have implementor support. (Perhaps CSS gradients could avoid this problem by overriding the meaning of the transparent keyword, so that instead of rgba(0,0,0,0) it means A=0 with the mean RGB of the adjacent colour stops. That would let it work as people naturally expect when they use that keyword, and they can use the rgba() syntax if they really want transparent black or transparent yellow or transparent red etc.) This is incompatible with both gradients and transitions (actually, animations), because transparent can be simultaneously the endpoints of two different color interpolations. An animation or a gradient can go from a solid color to transparent to a solid color again. While it's theoretically possible in a red-transparent-blue animation/gradient to have transparent mean rgba(255,0,0,0) when going from red-transparent, and then mean rgba(0,0,255,0) when going from transparent-blue, that's hacky and weird. Doing it in premultiplied space makes it all happen cleanly and automatically. ~TJ
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. jackalm...@gmail.com 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 transparent, as transparent is defined as rgba(0,0,0,0), a transparent black. Under this scheme, the color halfway between yellow and transparent is rgba(127,127,0,.5), a partially-transparent dark yellow, rather than rgba(255,255,0,.5).* If you define the gradient as interpolating from solid yellow to transparent black, I'd expect that it *should* be semi-transparent blackish-yellow in the middle. If you want it to be pure yellow, don't use a keyword which is explicitly specified as transparent black - define the gradient from rgba(255,255,0,1) to rgba(255,255,0,0) instead. Then you'll get rgba(255,255,0,0.5) in the middle. Sure, you can solve that particular case. However, if neither of the endpoints is precisely transparent, and you're changing both color and alpha components, you'll still get an ugly effect with the current rules, and one that you can't work around. (I experimented with both methods when implementing CSS transitions of colors, and went with premultiplied. http://dbaron.org/css/test/2009/transitions/transitions-alpha makes it look like WebKit has now switched to premultiplied.) That sounds like SVG gradients *can't* be using premultiplied colours. Yes, because SVG doesn't have RGBA colors; it has RGB colors (in stop-color) and a separate stop-opacity property/attribute. So the choice doesn't apply to SVG. Maybe CSS should have originally used the keyword transparentblack instead of transparent (though the distinction didn't matter before gradients existed) - changing the gradient algorithm solely to work more intuitively when people happen to use that one particular incorrectly-named keyword seems backwards, and a mistake in CSS. It's not only the 'transparent' keyword; it affects all cases of gradients between colors with different alpha values and different color values. And in cases where one of the endpoint alphas is not 0, it's not possible to get the correct (premultiplied) result with a gradient computed in nonpremultiplied space. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
[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() function in CSS anywhere you could use an image (http://webkit.org/blog/176/css-canvas-drawing/, published in April 2008). The function takes an ident, which can then be used in the window.getCSSCanvasContext() function in javascript to grab a context keyed to that ident. Drawing on that context is then reflected everywhere on the page that references that canvas. In essence, this is defining a scriptable paint server, which seems useful enough that we'd really like it in the platform. I'm willing to define a canvas() function in the CSS Image Values specification, but since this relies explicitly on an HTML feature, it feels like the full definition should exist in the HTML spec. Thoughts? ~TJ
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 Oapos;Callahan rob...@ocallahan.org wrote: On Mon, Nov 22, 2010 at 1:40 PM, Charles Pritchard ch...@jumis.com wrote: I would point out that the MS proposal has an independent X and Y scaling mechanism. Does anyone know of any modern displays which have different X and Y resolution? I believe that dpi ratio is simply set to 2 (or .5... sorry a bit rusty) on the iOS 4 retina ... There will be cases where zooming doesn't change device-pixel-ratio. Mobile browsers tend to have a fast zoom out which doesn't change the layout (mostly), and that might not change device-pixel-ratio. I think that's OK for your use cases as long as device-pixel-ratio reports the ratio as if the page is zoomed in. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received th...
Re: [whatwg] Processing the zoom level - MS extensions to window.screen
On Wed, Nov 24, 2010 at 1:53 PM, Kevin Marks kevinma...@gmail.com 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 browsers display better quality output on NTSC or PAL TVs seems like a waste of time to me. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] CSS canvas() function
On Tue, Nov 23, 2010 at 4:59 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Wed, Nov 24, 2010 at 1:13 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Webkit has for some time now supported using the -webkit-canvas() function in CSS anywhere you could use an image (http://webkit.org/blog/176/css-canvas-drawing/, published in April 2008). The function takes an ident, which can then be used in the window.getCSSCanvasContext() function in javascript to grab a context keyed to that ident. Drawing on that context is then reflected everywhere on the page that references that canvas. In essence, this is defining a scriptable paint server, which seems useful enough that we'd really like it in the platform. Out of interest, what use-cases do you have for this? Mozilla people couldn't think of many that aren't already addressed by other means. The same use-cases addressed below by using setImageElement and a canvas. 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 set for the point your mouse was over). It would be better/cleaner/easier/more semantic to just draw directly into the body background, which is what I was faking with abspos and z-index. I'm willing to define a canvas() function in the CSS Image Values specification, but since this relies explicitly on an HTML feature, it feels like the full definition should exist in the HTML spec. One of our goals for element() was to subsume canvas(). Is there a reason to have an independent canvas() feature if we have element()? Note that the setImageElement() API lets you render elements that are not in a document, so you can get the effect of window.getCSSCanvasContext(type, id, width, height) with var c = document.createElement(canvas); c.width = width; c.height = height; window.setImageElement(id, c); return c.getContext(type); http://hacks.mozilla.org/2010/08/mozelement/ Ah, right, I'd forgotten about that. I think the *idea* of setImageElement() is great, but the particular implementation is really weird. Why does it override the id? This is CSS, we have other namespaces for a reason. This also interferes with the extension of element() to accept an arbitrary selector, which I'd like to see (it would select the first element that matches the selector). I'd say that we could just let element() take an ident as well and have that refer to a setImageElement()-set value, but that would also interfere with element() taking arbitrary selectors (a tagname selector looks like an ident). How about just using canvas() to refer to setImageElement() things? This retains the flexibility that setImageElement has over getCSSCanvasContext, while removing the weirdness of transparently overriding #ids and keeping element() open to accept arbitrary selectors? (Possibly a different name than canvas(), since you can use setImageElement with any element. The point is just not to step on the toes of element().) ~TJ
Re: [whatwg] CSS canvas() function
On Wed, Nov 24, 2010 at 2:23 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: 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 set for the point your mouse was over). It would be better/cleaner/easier/more semantic to just draw directly into the body background, which is what I was faking with abspos and z-index. OK. How about just using canvas() to refer to setImageElement() things? This retains the flexibility that setImageElement has over getCSSCanvasContext, while removing the weirdness of transparently overriding #ids and keeping element() open to accept arbitrary selectors? Special syntax to refer to setImageElement elements would be OK, but I wouldn't choose canvas(), since the element can also be a video or img. How about element(ident) to refer to setImageElements, element(#id) for DOM IDs, and element(first(selector)) for selectors? (I don't necessarily endorse the idea of extending to selectors, FWIW, but I appreciate the desire to keep the possibility open.) Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
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 kevinma...@gmail.com mailto:kevinma...@gmail.com 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 browsers display better quality output on NTSC or PAL TVs seems like a waste of time to me. TV use-cases seem like they'll become more prevalent, with Apple and Google and their devices. I could imagine that some window managers might introduce strange pixel-bending effects; but that's just imagination. I don't think we can speculate that much on output devices of the future... In any case, I think we're just talking about limiting the scope of support to exposing an X and Y ratio, instead of just exposing a single value. If the scope goes further, yes it may be a waste of time. Otherwise though, I think it's more a concern about precision/conciseness than it is about an investment of time/resources. That said, display technologies are over my head.
Re: [whatwg] Processing the zoom level - MS extensions to window.screen
Message: 1 Date: Mon, 22 Nov 2010 15:27:40 -0500 From: Boris Zbarskybzbar...@mit.edu 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 12:22 AM, Charles Pritchard wrote: OpenGL has an immediate-mode which does not require a bitmap backend. Sure. But if it's going to be resolution independent, then there needs to be a retained mode somewhere in the stack, even if it's not exposed to the original caller (e.g. you GL could be outputting to postscript). That is, to have resolution independence, you _have_ to retain more information about the logical structure of your image than just pixel color values. Animated digital imagery usually requires retained data, otherwise it'd be analog. For the topic at hand, canvas, near-all canvas apps retain state data in the scripting environment. They have to, to perform a repaint. 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 what the state-info is. The scripting environment likely keeps around a function, that, when called, will re-draw to the canvas. The output may change, based on environment, but the scripting environment is a retained environment. The browser event loop is intrinsic to the way canvas operates. It's a requirement for apps which use the full width and height of the window, as the canvas state resets when the element size is changed. Sure. This is the first mention of you resizing your canvas to use the full width and height of the window, which sounds like the sort of constraint I asked about in my previous mail Sorry I missed that one... Resizing a canvas within an element is another use case, or otherwise animating the canvas in any way not covered by CSS. Right, so you're trying to build a retained-mode something using canvas as the rendering backend, no? I'm getting the impression that you don't use the API in your work. Well, most of my work related to the API is on the C++ end of the API, making it work (or more precisely, making it work faster). The time I spend on that is far greater than the time I spend using it, for sure. I _have_ used it, of course; just not for my work. But I'll note that an ad-hominem attack in response to a technical question doesn't really get us further towards mutual understanding. It is a legitimate statement, and relevant to the discussion, though I could have phrased it more gently. The 2D API, as it relates to implementation details -- is a very different item than the actual use of that API. You're looking at fill methods, path checking, clipping, masking, etc. I understand that. I've produced several implementations. I've also produced a substantial body of work using the API; and so, speaking from that place, I can say with some credibility that programming the API is radically different than using the API. I appreciate your candor, and can now, better understand your perspective/misunderstandings on some of the issues I've brought up. In this thread, I've only brought up the fact that usingcanvas with fillText requires fetching the current DPI ratio, so that the text is clear and crisp. How is that reinventing the wheel? Your specific proposal is for achieving resolution-independent rendering by using canvas + fillText + DPI ratio + firing resize revents on zoom (and a few you left out, like firing resize events on non-zoom DPI change when I switch to an external monitor and so forth, but which are clearly needed to make this whole approach actually work well). I did consider that use case; it's a corner-case, and I don't think we have the proper support in DOM Windows to even begin to support multiple-monitors. I do have some ideas on it, but I think that there are more important issues in the present. In terms of reinventing the wheel, we are talking about a minimum of lines of code. We're talking about ~6 lines of code here. Believe me, I've reinvented wheels. It takes a lot more work. At the same time, there are existing web technologies whose entire reason for existence is resolution-independent graphics and text rendering (SVG, specifically). SVG is a document format. It is not reliably implemented. It's far more expensive to implement SVG on a new environment than Canvas. Disagreeing with my use case is your choice, but it's about as useful as telling the Skywriter team that they're wasting their lives. What I'm trying to understand is what specific issues with SVG prevent its use in your situation, and whether those are the implementations just suck issues or whether they're intrinsic
Re: [whatwg] Processing the zoom level - MS extensions to window.screen
On Wed, Nov 24, 2010 at 3:30 PM, Charles Pritchard ch...@jumis.com 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 I'm hearing.
a) Why are you using our Canvas implementation instead of our SVG
implementation.
b) Why are you using ctx.fillText('Test') instead of
element.appendChild(document.createElement('text')).textContent = 'Test'.
For answers
a: I'm using it because I work across a variety of browser platforms.
Canvas is far better supported.
It doesn't make sense to request entirely new features (that by definition
aren't currently supported) because existing features aren't widely
supported.
Anyway, I'm not sure why you think canvas is far better supported than
SVG. What browser supports canvas but not SVG?
Sure, but there are plenty of canvas uses that aren't animating all the
time (I've seen image editing apps, sites that use canvas as their
_input_, not their output, etc).
1. Name one.
http://arewefastyet.com
http://www.simile-widgets.org/timeplot/
http://jwf.us/blog_apps/mandelbrot_canvas/
Robert's suggestion would radically alter the existing functionality of
canvas
Only in a way that maintains compatibility with existing content. Otherwise
I wouldn't have suggested it.
and require a whole lot of work from other vendors.
Not really.
Rob
--
Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true. [Acts 17:11]
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 what the state-info is.
The scripting environment likely keeps around a function, that, when
called, will re-draw to the canvas.
Are you including things like http://detexify.kirelabs.org/classify.html
under this classification?
The browser event loop is intrinsic to the way canvas operates.
Um... no. Not really, no. You can render stuff (e.g. incoming video
data) into the canvas, then grab out the resulting PNG data and move on
without ever keeping any of the state around in your script or the
canvas or painting it back to the canvas
Unless we're _really_ using different definitions of event loop and
intrinsic (or operates?).
The API footprint I'm requesting is about the size of a flea.
The thing is, if we add one separate flea for every use case we end up
with a whole bunch of fleas... Even if the special API addition is
small, asking whether it's needed or whether a more general approach is
preferred is worth it. The answer will depend on the details, of course
(like whether there _is_ a sane general approach).
Further, you're still thinking of SVG as though it's software... It's
not. It's a document format.
SVG is just a particular retained-mode representation. In particular,
you can script it. What, precisely, is the difference between
software and document format, here?
Heck, HTML is a document format; gmail is software that happens to use
HTML as a presentation layer, right?
I can't do much for you here other than explain to you what I'm hearing.
a) Why are you using our Canvas implementation instead of our SVG
implementation.
... for this specific use case of needing resolution-independent
rendering. That last part is key.
b) Why are you using ctx.fillText('Test') instead of
element.appendChild(document.createElement('text')).textContent = 'Test'.
You mean element.appendChild(document.createTextNode(Test)). But yes,
that's how you'd script SVG.
a: I'm using it because I work across a variety of browser platforms.
Canvas is far better supported.
OK. And you think the timeframe for getting convergence on the things
you need for resolution-independence in canvas is shorter than the
timeframe for better SVG support, presumably?
b: Because it's shorter
It's pretty easy to set up a helper function... But yes, the DOM does
tend to be verbose.
and wrapping from Canvas to SVG automatically is inefficient.
This I'm not sure I follow.
Sure, but there are plenty of canvas uses that aren't animating all the
time (I've seen image editing apps, sites that use canvas as their
_input_, not their output, etc).
1. Name one.
See link above. I can dig around more if you do want more examples.
2. Flash is a fine technology.
No, not really.
3. Using canvas means having an entry point;
typically in window.onload. They're authored to re-render based on user
input.
See link above.
And, these aren't great lengths. It's about 6 lines of javascript.
Uh... That depends on how your drawing path is set up. If I understand
correctly what you're doing, you have to get the DPI ration (call it N),
change the canvas width/height by a factor of N, and change all
coordinates in all your drawing calls by a factor of N, right?
Canvas programmers have, necessarily, an understanding of how Canvas
works. It's an API where nothing is done for you.
This last isn't quite true (e.g. there are plenty of examples of Canvas
dwim that leads to some weirdness from my point of view). And it's not
clear that it must be true; if there are ways to make the API easier to
use, we should make use of them.
You've got great expectations for the great lengths I'm willing to go.
Wish you had some of that faith in other developers. Canvas coders work
very hard at their craft.
I'm sure they do.
I'm sure HTML coders work hard too. And JS coders, too.
I have approximately zero faith in JS coders and HTML coders doing
things right, after fairly extensive exposure to the results of their
work.
My faith in canvas coders is closer to 0.2 (on a 0-1 scale), largely
because it's not quite as mainstream yet, so only the more competent
folks are doing it.
I'm all for easy, but I'm not for restricting users, nor breaking
existing apps.
OK, another point of agreement.
Using that data requires very few lines of code.
Again, that seems to depend on how your drawing is set up, unless I'm
really misunderstanding what you're doing.
-Boris
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 ch...@jumis.com
mailto:ch...@jumis.com 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.
Google, Microsoft, Apple, do, have to implement it.
As an app designer, my app should work on ~ four different browsers. I
need my app to work, with what's out there in practice.
And for other environments, I would have to. I've implemented for JVM,
Active X (thanks Vlad/Mozilla), Flash and .Net.
I can't do much for you here other than explain to you what I'm
hearing.
a) Why are you using our Canvas implementation instead of our SVG
implementation.
b) Why are you using ctx.fillText('Test') instead of
element.appendChild(document.createElement('text')).textContent =
'Test'.
For answers
a: I'm using it because I work across a variety of browser
platforms. Canvas is far better supported.
It doesn't make sense to request entirely new features (that by
definition aren't currently supported) because existing features
aren't widely supported.
It's currently supported by Microsoft, and to a lesser extent, WebKit.
It's not features, it's one feature.
And as you pointed out, it may be supported in FF4; though it's behavior
is not standardized.
Anyway, I'm not sure why you think canvas is far better supported
than SVG. What browser supports canvas but not SVG?
AFAIK, FF is the only to support SVG FE.
SVG is a large spec, even SVG Tiny is unevenly implemented.
WebKit had terribly slow SVG support; IEs was non-existent, though it
was a reasonable task to bring canvas in. I can barely do a nice thing
in SVG on the iPhone. It takes 20 seconds to load a rendering that takes
less than one in canvas. These are the reasons why I think canvas is
better supported. Further, when there are holes, it's easier to work
around them in Canvas than SVG.
One gaping hole in SVG is repeated elements. I can not reasonably
implement InkML rendering in SVG. I need David Dailey's replicate tag to
do it with any real performance:
http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/replicate.htm
In many ways, SVG has some of the same shortcomings as VML.
When it comes to the canvas standard, there are a few holes, no doubt,
but they are minor. There are some globalCompositionModes that aren't
touchable, text support needs a backup library for legacy clients,
shadow isn't a reliable module. That's what I work with.
Again, I don't see SVG/Canvas as at all exclusive. One is high level,
one is low level, and the high level work takes quite a bit of work.
Sure, but there are plenty of canvas uses that aren't
animating all the
time (I've seen image editing apps, sites that use canvas as their
_input_, not their output, etc).
1. Name one.
http://arewefastyet.com
Uses a second canvas layer for animation.
http://www.simile-widgets.org/timeplot/
I don't know what was meant by sites use canvas as their _input_, not
their output, but anyway, it does fit the challenge.
Here's a case where no Canvas animation happens. The state is retained,
but all the repainting is done by either clicking a link to go to a new
page, or by abusing HTML DIVs.
It has inefficient use of DOM+HTML. The doc is a lot heavier than it
needs to be. For their code setup, SVG is a better use case. They do
support VML. They're only using Canvas to draw lines, likely for
compatibility reasons. Thus the VML hooks.
They do keep a state, and setup to plot live data. They don't use it,
they have separate links instead. Turning their Live Examples links
into a select element would have made good sense.
Here's a better implementation of a time plot. Hold shift to click+drag.
http://timepedia.org/chronoscope/
Anyway, I agree, you've named an example.
http://jwf.us/blog_apps/mandelbrot_canvas/
Re-draw button, right there. State vars in private zoom variable. It
outputs to Canvas.
Robert's suggestion would radically alter the existing
functionality of canvas
Only in a way that maintains compatibility with existing content.
Otherwise I wouldn't have suggested it.
Existing apps targeting mobile devices (android/iphone) and scaling for
those devices with the pixel ratio / dpi density variables would be
broken. It violates a clearly defined separation of roles with CSS and
Canvas.
and require a whole lot of work from other vendors.
Not really.
Implement it as an extension, let us know how much time was involved. It
may help other vendors budget their resources.
I'm very uncomfortable with it being used as the standard behavior for
the existing HTML Canvas element.
-Charles
