Re: [whatwg] Minor addition/rewording for canvas section
Anne van Kesteren wrote: On Sun, 13 Jan 2008 14:13:52 +0100, Oliver Hunt [EMAIL PROTECTED] wrote: I did wonder about why other origins could read anything myself, so you're not alone -- it just seemed especially odd to allow images to be written safely but not ImageData. ImageData is always safe as you create it yourself. To clarify this very point: An ImageData is always safe because: * getImageData(...) must throw a Security Violation exception when called on a tainted Canvas. * it is created manually, and other same origin policies prevent information leak in to it. -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] Reverse ordered lists
I am not quite sure whether this should be covered by html at all. List numbering should be a matter of CSS I think. Using an ol only means that it's items are ordered, not in what way. There is a difference between ordinal value (which might be specified by the value attribute of an li element) and things like, say, ranking, score and numbering Regards, Rikkert Koppes Siemova wrote: Daniel Glazman wrote: Usually, the answer is because nobody uses it anyway Perhaps so, but I certainly wouldn't say nobody wants to use reverse-ordered lists. I've seen plenty of them across the web (whether non-HTML or hacked via CSS, tables, etc.), and more than a few complaints that there's no easy, standardized way to make them. Besides, designing and implementing such a feature ought to be so easy for W3C and UA's that the (admittedly minor) benefit would be entirely worth the small trouble. I'd never claim my proposal to be earth-shattering, but it's not much less worthwhile than the start attribute. They're both useful in certain infrequent-but-not-improbable situations, and stay out of the way when not needed. :) - Jason (Siemova)
[whatwg] Colour correction (was: Canvas ImageData comments)
Philip Taylor wrote on January 18th, 2008: On 18/01/2008, Ian Hickson [EMAIL PROTECTED] wrote: On Sat, 16 Jun 2007, Philip Taylor wrote: Colour spaces are not dealt with at all, but are particularly relevant for getImageData (else you have no idea what the values mean). Fixed, in theory. But since I have no idea what I'm talking about here, you'll have to check closely to make sure I didn't babble incoherently. I don't know much about colour spaces either, so someone else should check that it's sane :-) It's worthwhile to think about what colour spaces are for: Colour correction tries to solve a simple problem: Alice wants to send an image to Bob, but their screens are not guaranteed to show the same colour when presented with the exact same RGB triple, so Bob might not be seeing the same image Alice does. The solution to this problem is obvious: Both Alice and Bob have their screen's properties measured. Alice sends her screen's properties along to Bob, who can then transform the image to fit his screen's properties. This whole measuring business is rather expensive. It's necessary even today in many cases when you want to print stuff with accurate colours, but on the web, it's far easier: Alice transforms her image to a standard colour space before sending it to Bob, tweaking the actual RGB triples such that the image still looks right to her. The effect still is the same for Bob though: He gets an image and is informed of the properties of the screen that would make this image look right. At this point, Bob can make this image look right on his screen / if/ he knows his screen's properties (a. k. a. colour space). If he was a professional print designer, he might know them. But most web users aren't. Some consumer-oriented operating systems make it possible to calibrate one's screen, i. e. to estimate it's properties through an heuristic interactive process. Few users that I've known ever go through this trouble. Most don't even know what this colour calibration stuff is all about. Now, for web pages, this whole mess enters the next level: Unlike images, they consist of colours coming from multiple sources, including legacy HTML, CSS, scripts and HTML-embedded images. In order for colour correction to be of any use, /all/ of these colour sources need to be properly tagged! I'm not sure where all of this leads us. I mean, we can't expect that the authors tag all their colours, but neither can we expect all users to calibrate their screens. This entire colour correction problem seems to be too big for this spec to handle. Having said that, we need to specify a sensible behaviour for user agents that doesn't prevent this problem to be handled in other places (perhaps the operating system, perhaps some future spec, ...). Opinions are welcome. Perhaps I have time next week to check out what current browsers actually do today. From past experience I expect that it's not consistent in every situation; I recall some serious trouble working with Safari in particular. [...] I'd also like: - fillStyle = 'rgb(r, g, b)'; fillRect(...); getImageData returns exactly [r, g, b, 255]. mainly because that makes it possible to write test cases that use getImageData to check the results. Yeah, that sounds good: There should be no colour conversion in normal method calls. Not sure how to make that work well with regards to the operating system though. [...] And I have no idea if this is trivial for implementors, or if it's impossible. So I don't have any useful suggestions. Same here, at least at this time. -- Arne Johannessen
Re: [whatwg] Canvas ImageData comments
Dnia 18-01-2008, Pt o godzinie 13:19 +, Philip Taylor pisze: Oops, I was wrong to mention that - 'different than' seems to be common in some Englishes, and I don't want to complain when it's just dialect variations. To me, different from is closer to dissimilar and corresponds to the question What are the difference between… whereas different than is closer to unequal. In other words, a swan is different from a goose but the height of Mount Everest is different than the height of Mont Blanc. (Note, however, that 0 is different from 3: adding 0 does not change the result, etc.)
Re: [whatwg] Canvas ImageData comments
On 18/01/2008, Ian Hickson [EMAIL PROTECTED] wrote:
On Sat, 16 Jun 2007, Philip Taylor wrote:
Colour spaces are not dealt with at all, but are particularly relevant
for getImageData (else you have no idea what the values mean).
Fixed, in theory. But since I have no idea what I'm talking about here,
you'll have to check closely to make sure I didn't babble incoherently.
I don't know much about colour spaces either, so someone else should
check that it's sane :-)
maybe it's safest to just say that all colours throughout the canvas API
must be handled consistently in the same colour space (without saying
exactly which it is).
Wouldn't that mean that different browsers could have different effects
when rendering external images -- with gamma -- to the canvas?
I guess so; and things like gradients wouldn't work consistently if
the colour space wasn't consistent.
Maybe the desired properties are:
- drawImage(img) onto a displayed canvas should look the same as
the original img, regardless of whether the image has gamma etc.
- toDataURL should return the same raw pixel data as getImageData, at
least for image/png (though other formats might make that impossible),
for consistency.
- drawImage(toDataURL()) should have no effect.
I'd also like:
- fillStyle = 'rgb(r, g, b)'; fillRect(...); getImageData returns
exactly [r, g, b, 255].
mainly because that makes it possible to write test cases that use
getImageData to check the results.
I don't know if any of these are wrong, or if others are missing. And
I have no idea if this is trivial for implementors, or if it's
impossible. So I don't have any useful suggestions.
The putImageData(image, dx, dy) method must take the given ImageData
structure, and draw it at the specified location dx,dy in the canvas
coordinate space, mapping each pixel represented by the ImageData
structure into one device pixel. - how should it 'draw it'? Given the
requirement on putImageData(getImageData(...)), it has to be replacing
the pixels in that area rather than doing anything like normal drawing,
but that isn't explicit.
Is it better now?
It looks clear enough to me.
In the example code:
[...]
function FillCload(data, x, y) { ... } - should be function
FillCloud(data, x, y) { ... }.
That error was replaced with function AddCload(data, x, y) { ... } - s/a/u/
The width and height (w and h) might be different than the sw and sh
arguments to the function - 'different than' sounds a bit odd to me
here; maybe I'd prefer 'different from'.
Oops, I was wrong to mention that - 'different than' seems to be
common in some Englishes, and I don't want to complain when it's just
dialect variations.
--
Philip Taylor
[EMAIL PROTECTED]
