| 00:01 | <Hixie> | 24 <canvas> mails left |
| 00:01 | <Hixie> | (not counting text issues) |
| 08:22 | <annevk> | Hixie, what would be nice if .fillStyle returned a four-digit array instead |
| 08:23 | <annevk> | and the same for .strokeStyle |
| 08:23 | <annevk> | that would be much more trivial to parse |
| 08:23 | <Hixie> | it would also make it impossible to do .fillStyle = .fillStyle |
| 08:24 | <Hixie> | unless we added yet another way of assigning colour |
| 08:24 | <Hixie> | but anyway, who the heck is parsing these colours |
| 08:24 | <Hixie> | you had to set them yourself |
| 08:24 | <Hixie> | you KNOW what the colour is |
| 08:33 | <annevk> | people parse it |
| 08:33 | <annevk> | apparently |
| 08:33 | <annevk> | and yes, it would mean assigning would have to accept a four-digit array |
| 08:36 | <annevk> | I guess I raised some problems multiple times because I don't keep track of the e-mails I have already sent |
| 08:53 | <Hixie> | :-) |
| 08:53 | <Hixie> | i wasn't criticising |
| 08:53 | <Hixie> | just thought it was amusing :-) |
| 08:54 | <annevk> | btw, as for dropping features, did anyone implement shadows already? |
| 09:05 | <Hixie> | safari, i assume |
| 09:05 | <Hixie> | that was in their initial description |
| 09:05 | <annevk> | oh ok |
| 09:10 | <othermaciej> | we do shadows? |
| 09:10 | <othermaciej> | cool |
| 09:10 | <Hixie> | i haven't tested it |
| 09:10 | <Hixie> | at l0east not recently |
| 09:11 | <annevk> | heh |
| 09:12 | <annevk> | the primary use case for having totally global id= is getting the requirement for xml:id out of SVG |
| 09:12 | <Hixie> | why? |
| 09:12 | <Hixie> | svg already has id="" |
| 09:12 | <Hixie> | it only uses xml:id in svg 1.2, no? and svg 1.2 is a waste of time anyway. |
| 09:13 | <othermaciej> | svg added xml:id on the theory that it would be play nicer with embedding markup in other languages |
| 09:13 | <othermaciej> | (apparently xhtml 1.0 and xhtml 1.1 were not considered among the important languages to embed) |
| 09:13 | <othermaciej> | does MathML have any attributes of type ID? |
| 09:13 | <othermaciej> | RSS? Atom? |
| 09:13 | <annevk> | SVG Tiny 1.2 is happing at least for Opera |
| 09:13 | <hsivonen> | the way SVG 1.2 specs IDness assignment is crazy |
| 09:13 | annevk | doesn't have time to do SVG fights atm |
| 09:14 | <hsivonen> | can be please get it repealed somehow? |
| 09:14 | <Hixie> | annevk: sorry to hear that |
| 09:14 | <othermaciej> | we probably won't implement SVG 1.2 in WebKit, maybe selected parts, but likely not the whole thing |
| 09:14 | annevk | isn't sure about SVG 1.2 though |
| 09:14 | <Hixie> | annevk: who's doing the qa? |
| 09:15 | <annevk> | not sure |
| 09:17 | <annevk> | Seems Acid3 has some script issues btw which causes it not to run |
| 09:17 | <hsivonen> | it would be nice to have a spec for the subset of SVG that Opera, Apple and Mozilla implement |
| 09:18 | <annevk> | That would be a tutorial |
| 09:18 | <hsivonen> | annevk: I mean SVG5 |
| 09:19 | <hsivonen> | annevk: something realistic you could check conformance against |
| 09:19 | <hsivonen> | annevk: If I support SVG 1.1 but browsers support pieces of SVG 1.2, those pieces get flagged |
| 09:20 | <annevk> | Someone just has to free up his time for the foreseeable future and do it... I suppose |
| 09:20 | <hsivonen> | annevk: If I supported SVG 1.2, I'd fail to flag stuff that authors should avoid |
| 09:20 | annevk | doesn't know much about vector graphics and doesn't have much free time |
| 09:23 | <Hixie> | acid3 isn't ready yet |
| 09:25 | <annevk> | maikmerten, hi, Opera's implementation of <video> is experimental |
| 09:26 | <maikmerten> | annevk, yup |
| 09:26 | <annevk> | as such, we don't support all members of HTMLMediaElement |
| 09:26 | <maikmerten> | yeah, only a basic subset |
| 09:27 | <maikmerten> | I expected nothing else - doing a full scale implementation only makes sense once the <video> part of the spec is considered stable |
| 09:28 | <annevk> | Our submission along with the work from Apple actually made Hixie draft that part of the spec as I understand it |
| 09:28 | <maikmerten> | annevk, by the way, any plans to expose the Theora postprocessing options in Opera? |
| 09:28 | <Hixie> | that could be a problem, since it won't be stable until there are at least two implementations :-) |
| 09:28 | <annevk> | And it basically consisted of .play() .pause() and .stop() if I remember correctly |
| 09:29 | <maikmerten> | I did write howcome and told him about the new Theora code (improved encoder, complete and safe decoder) but I guess that the mail was eaten by a spam filter ;) |
| 09:29 | <maikmerten> | yeah, and stop() more or less vanished, so it seems |
| 09:29 | <annevk> | I believe .stop() is not part of the specification, not sure |
| 09:29 | <annevk> | right |
| 09:29 | <annevk> | oh, also in the implementation? |
| 09:29 | <maikmerten> | nope |
| 09:29 | <maikmerten> | the experimental build has stop() |
| 09:30 | <maikmerten> | after finding out that the spec only has pause() the wikimedia player was altered to honor this |
| 09:30 | <annevk> | ah ok |
| 09:31 | <annevk> | if you guys would like a bit more than play() and pause() I suppose you could post that somewhere and I'll see what I can do |
| 09:31 | <maikmerten> | well, a stop() would be cool ;) - but that can be mimicked with pause() and start set to zero, I guess |
| 09:32 | <annevk> | Hixie, any reason there's no stop()? |
| 09:32 | <Hixie> | what would it do? |
| 09:32 | <maikmerten> | stop playback and set the playback position to zero |
| 09:32 | <maikmerten> | (which can be achieved with the current draft in two steps already.... so...) |
| 09:32 | <Hixie> | ah. then there is. it's just spelt a bit longer: m.pause(); m.duration = 0; |
| 09:32 | <annevk> | (Although what I meant was features missing in Opera.) |
| 09:33 | <annevk> | you actually mean the more horrible currentTime |
| 09:33 | <Hixie> | right |
| 09:33 | <Hixie> | m.pause(); m.currentTime = 0; |
| 09:34 | annevk | would like to have stop() back |
| 09:34 | <annevk> | It was also on Audio() |
| 09:35 | <Hixie> | if it did something that you couldn't otherwise do... |
| 09:35 | <Hixie> | i'm not a fan of adding shortcuts before we know if anyone will use them |
| 09:35 | <maikmerten> | oh, one thing: A reliable way to find out if <video> is supported would be nice. Currently I'm just embedding a <video> element without src, fetch that with getElementById and see if that has a play method |
| 09:36 | <maikmerten> | don't know if that is how it's supposed to be |
| 09:36 | <maikmerten> | and in the long term a way to query mime types supported by audio/video may be nice, too |
| 09:37 | <Hixie> | if (video.play) is one way to find out |
| 09:37 | <Hixie> | anyway, i'm off hame |
| 09:37 | <Hixie> | nn |
| 09:37 | <annevk> | g'night |
| 09:37 | <maikmerten> | night |
| 09:39 | <annevk> | Hixie, hmm, Wikipedia would use them :) |
| 09:40 | <othermaciej> | maikmerten: the intent is that you specify multiple sources with <source> elements instead of querying |
| 09:40 | <maikmerten> | as for the mime type querying: Sooner or later as codec development goes on user agents may pick up new codecs (on the free side Ogg Ghost + Ogg Dirac or whatever, on the other side the future MPEG codecs) and content providers may want to be able to see what's supported. Plus as Ogg is a SHOULD some implementations may not implement it and then the either a fallback should be able to kick in or just tell the user |
| 09:40 | <maikmerten> | ah, k |
| 09:40 | <maikmerten> | that's an even better solution that's scripting independent |
| 09:40 | <othermaciej> | maikmerten: video codec support also is in general more fine-grained than mime types |
| 09:40 | <maikmerten> | fair point |
| 09:41 | <maikmerten> | currently e.g. the Wikimedia player queries the mime types and if it finds application/ogg (VLC plugin, totem plugin) it just assumes that Ogg plugin will also support video |
| 09:41 | <othermaciej> | and the <source> element supports that via the MIME type codecs parameter |
| 09:41 | <othermaciej> | it would be hard for a plugin to report all combos of the codecs parameter it supports |
| 09:41 | <maikmerten> | true |
| 09:42 | <maikmerten> | <annevk> Hixie, hmm, Wikipedia would use them :) <-- well, Wikipedia will adapt to whatever is specified here, it shouldn't be the other way round |
| 09:43 | <maikmerten> | the fact it's already having experimental <video> support is more to give a real-life testing ground for implementations and to voice support for the idea |
| 09:43 | annevk | was lobbying for less changes to Opera :) |
| 09:44 | <annevk> | but yeah |
| 09:44 | <maikmerten> | haha, right, standard procedure when several vendors come together... "Why not adapt to what we already have?" ;-) |
| 09:45 | <maikmerten> | I nominate <layer> ;) |
| 09:45 | <hsivonen> | I have now readjusted truthiness regarding the WHATWG and HTML5 |
| 09:45 | <hsivonen> | on wikipedia, that is |
| 09:46 | <maikmerten> | I parse that as "I edited the whatwg article on wikipedia", correct? |
| 09:46 | <hsivonen> | maikmerten: and HTML5 and HTML |
| 09:46 | <maikmerten> | ah, nice |
| 09:47 | <annevk> | I like http://en.wikipedia.org/wiki/HTML5 |
| 09:47 | <annevk> | "The HTML5 language is defined by a draft specification called “HTML 5” (note the space)." |
| 09:47 | <hsivonen> | maikmerten: the article was called truthy last night, because it had some bogus stuff in it |
| 09:47 | <maikmerten> | well, as usual ;) |
| 09:48 | <maikmerten> | (I *like* Wikipedia, but at times the strangest conceptions make it into articles because no real expert monitors them) |
| 09:48 | <annevk> | It's also hard to get some articles changed, like HTML |
| 09:49 | <annevk> | Although now HTML5 is done at the W3C it should be more easy I guess |
| 09:49 | <hsivonen> | annevk: I cited emails on lists.w3.org to avoid immediate reverts to the old accepted truth |
| 09:49 | <maikmerten> | (by the way: Is there a reliable way to see if Java is *working* apart from embedding an applet and seeing if JavaScript can interact with that?) |
| 09:50 | <annevk> | you might not have to embed it |
| 09:50 | <annevk> | you could create the elements (such as <video> simply through script) |
| 09:50 | <annevk> | and then do the check |
| 09:51 | <annevk> | video = document.createElement('video'); if(video.play) { etc. } |
| 09:53 | <maikmerten> | oh, sweet |
| 09:53 | <maikmerten> | my JavaScript skills sorta cover whatever came with Netscape 3.0 ;-) |
| 09:53 | <annevk> | nice |
| 09:53 | <maikmerten> | (and with "cover" I mean "I think I know 10% of that") ;) |
| 09:54 | <maikmerten> | time to educate myself on the DOM |
| 09:55 | <othermaciej> | hmm, the WHATWG article still mentions microsoft |
| 09:55 | <othermaciej> | http://en.wikipedia.org/wiki/Whatwg |
| 09:57 | <hsivonen> | othermaciej: but now accurately, I hope |
| 09:57 | <annevk> | othermaciej, what it says there is correct though, right? |
| 09:57 | <othermaciej> | what I see is "The key contributing groups in the WHATWG are Google, the Mozilla Foundation, Opera Software, Apple Inc. and Microsoft." |
| 09:57 | <hsivonen> | othermaciej: reload |
| 09:58 | <hsivonen> | othermaciej: I guess you have an old cached version |
| 09:58 | <hsivonen> | othermaciej: either in your caches or in wikipedia's |
| 09:58 | <othermaciej> | hsivonen: just did; perhaps I'm a victim of too aggressive caching somewhere |
| 09:59 | <othermaciej> | hsivonen: seems to be in my browser cache |
| 10:00 | annevk | wonders why Wikipedia doesn't do redirects "better" |
| 10:01 | <othermaciej> | I wonder why the description of the WHATWG membership in the Discuss page for that article says "Maciej Stachowiak [ worked on Safari ]" |
| 10:01 | <othermaciej> | none of the others are in the past tense |
| 10:03 | <annevk> | dunno |
| 10:03 | <maikmerten> | I don't consider the discuss pages to be "canon" information |
| 10:04 | <maikmerten> | (wow, I just sounded like a Star Trek fan) |
| 10:04 | <othermaciej> | whoever wrote the post saying that was confused I think |
| 10:05 | <othermaciej> | damn, I screwed up the comment threading |
| 10:05 | <othermaciej> | maikmerten: is it considered bad form for someone closely associated with a product / project to edit the articles about it a lot? |
| 10:06 | <maikmerten> | othermaciej, good question - depends. Rule of thumb would say it's bad style |
| 10:06 | <othermaciej> | maikmerten: I really want to make a bunch of changes to the WebCore and WebKit articles (mainly merge most of the content into the WebKit one and change all the rendering engine list/comparison pages to point to WebKit instead of WebCore) but I'm worried this would be considered inappropriate |
| 10:07 | <maikmerten> | well, if the content is on a purely technical level I don't see why developers shouldn't be able to contribute |
| 10:07 | <maikmerten> | after all that is not the usual company propaganda thing that is controversial |
| 10:08 | <maikmerten> | err, semantics were wrong on the last sentence |
| 10:08 | <othermaciej> | I do have a lot of personal expert information which might not be based on published info |
| 10:08 | <maikmerten> | as long as it stays on a technical level it's okay, I'd guess. Problematic would be company propaganda |
| 10:08 | <othermaciej> | like what apps link to WebCore directly vs linking to WebKit |
| 10:09 | <othermaciej> | but that is easily verifiable |
| 10:09 | <othermaciej> | (at least for people who have access to the app) |
| 10:09 | <maikmerten> | oh, and disclaimer: I'm not part of the Wikipedia project, just assist a bit with video technology related stuff |
| 10:09 | <annevk> | Are you part of the Theora project? |
| 10:10 | <maikmerten> | well, yes and no. Not official member of xiph.org but I'm hanging around in the #theora channel and contributed a bit on the encoder |
| 10:10 | <annevk> | k |
| 10:11 | <maikmerten> | the border is a bit unclear as xiph.org isn't a real company but more a group of free media technology guys |
| 10:14 | <maikmerten> | (well, to be precise: It is a legal entity complete with a board etc. - but that doesn't mean you have to be "member" of some sort to contribute) |
| 11:23 | <Philip`> | About accepting [r,g,b,a] as input to fillStyle/strokeStyle, that'd be kind of handy since normally I have to write a [r,g,b,a]-to-"rgba(...)" function every time I do anything with colours, and have to worry about silly things like r,g,b being 0-255 while a is 0-1. (Not exceptionally handy and maybe not worth the cost, though.) |
| 11:25 | <annevk> | is "a" in ImageData.data 0-225? |
| 11:25 | <annevk> | I think you should mention the above on the list |
| 11:25 | <Philip`> | It is |
| 11:25 | <annevk> | cool |
| 11:26 | <annevk> | currently it accepts CSS for ease of use, but if you actually need to convert to CSS first it's not really "easy" anymore and just adds to the processing cost |
| 11:27 | <Philip`> | It's possibly nice that you can do HSL the same way as RGB when it's through CSS, which would no longer be the same if you had [r,g,b(,a)] arrays, but I don't know if anybody actually wants to use HSL |
| 11:29 | <annevk> | you want ,a to be optional? |
| 11:29 | <annevk> | it would still accept CSS I think |
| 11:31 | <Philip`> | Is there any reason not to make it optional? People will want solid colours more than they want transparent colours, so it would seem nicer to simplify that case rather than requiring a redundant ',255' every time |
| 11:31 | <othermaciej> | maybe functions to make and parse color strings would be more useful |
| 11:31 | <othermaciej> | the array could only support a limited number of color formats |
| 11:32 | <annevk> | Philip`, fair enough |
| 11:32 | <annevk> | othermaciej, thought about that... yet more global methods? |
| 11:32 | <othermaciej> | but makeRGB, makeRGBA, makeHSL, makeHSLA, etc could do it |
| 11:32 | <othermaciej> | they don't necessarily need to be global |
| 11:32 | <othermaciej> | could be part of the CSSOM |
| 11:32 | <othermaciej> | method on CSSColorValue constructor maybe |
| 11:33 | <annevk> | that might work |
| 11:33 | annevk | thought of having CSSColorValue.data[0,0,0,0] as opposed to .red, .green .blue and .alpha |
| 11:35 | <othermaciej> | .rgbaData might make more sense |
| 11:35 | <othermaciej> | but I'm not sure it is more clear than named properties |
| 11:36 | <annevk> | me neither |
| 12:14 | <annevk> | nice Philip` |
| 13:53 | <hsivonen> | cool. my HTML5 revisions to wikipedia are still standing after 4 hours |
| 13:55 | <annevk> | heh |
| 13:57 | <annevk> | ooh, those are pretty controversial |
| 13:58 | annevk | had only seen the first |
| 14:09 | <hsivonen> | annevk: what's controversial? |
| 14:09 | <hsivonen> | annevk: I tried to stick to stating facts |
| 14:10 | <annevk> | controversial facts, if you wish |
| 15:38 | <annevk> | http://en.wikipedia.org/wiki/XHTML might need updates as well |
| 15:48 | <hsivonen> | annevk: feel free to edit :-) |
| 15:49 | <annevk> | It's been said that I hate XHTML |
| 15:49 | <annevk> | Any edit would immediately be reverted |
| 15:49 | <met_> | edit it anonymously |
| 15:51 | <hsivonen> | ooh. they cite the Mozilla Web Author FAQ |
| 15:52 | <annevk> | I'm sure someone else will fix it in due course |
| 15:53 | <Philip`> | http://en.wikipedia.org/w/index.php?title=XHTML&oldid=129295550 - I prefer that version of the facts |
| 15:56 | <annevk> | :) |
| 15:57 | <hsivonen> | :-) |
| 15:57 | <zcorpan_> | hsivonen: "Namespace at-rules are supported." they are supported in HTML mode too |
| 15:57 | <zcorpan_> | (from the faq) |
| 15:58 | <hsivonen> | zcorpan_: do you mean they work right if you introduce other namespaces via DOM manipulation? |
| 15:58 | <zcorpan_> | yes. or if you just declare a bogus namespace then it won't match html elements |
| 15:59 | <hsivonen> | zcorpan_: OK. I take your word for it. |
| 15:59 | <zcorpan_> | html elements are in the xhtml namespace as far as css selectors are concerned |
| 15:59 | <zcorpan_> | in mozilla and opera and safari too iirc |
| 15:59 | <zcorpan_> | (even though they are in the null namespace in the DOM) |
| 16:02 | <hsivonen> | zcorpan_: fix checked in. should appear in the next site rebuild |
| 16:02 | <hsivonen> | zcorpan_: thanks for the report |
| 16:02 | <zcorpan_> | "Other namespaces are supported." and "xml:base is observed when following links." also are no different from HTML, except that you can't use them declaratively |
| 16:03 | <hsivonen> | hmm. I wonder if the point is too subtle for the FAQ |
| 16:03 | <zcorpan_> | perhaps... i realise it's intended to say "you can't use this" |
| 16:04 | <annevk> | not useful to mention I think |
| 16:04 | <annevk> | you can't use them in HTML, you can use them in the DOM |
| 16:05 | <zcorpan_> | yeah, fair enough |
| 16:06 | annevk | wonders what should happen with var imagedata = { height:1, width:2, data=[...], example:3 } |
| 16:07 | <annevk> | the other question is whether it's useful that you're able to create your own objects... |
| 16:07 | <annevk> | as <canvas> represents a grid that doesn't reflect device pixels |
| 16:08 | <annevk> | it seems extremely easy to get it wrong |
| 16:09 | <Philip`> | It might make extensibility a bit harder too, if ImageData is modified in the future (e.g. to say how many device pixels per canvas pixel, or to indiciate a non-RGB colour space, or whatever) but people are passing in objects with those new attributes missing |
| 16:09 | <Philip`> | s/indiciate/indicate/ |
| 16:12 | <Philip`> | It doesn't seem unreasonable to have people write var d; with (document.createElement('canvas')) { width = 100; height = 100; d = getContext('2d').getImageData(0, 0, width, height); } |
| 16:12 | <Philip`> | ...assuming every canvas has the same device pixel / canvas pixel mapping |
| 16:13 | <annevk> | yeah |
| 16:13 | <Philip`> | (I guess there's already an assumption that that mapping doesn't change over time, e.g. if you do getImageData then the user changes their desktop resolution then you do putImageData) |
| 16:14 | <Dashiva> | Philip`: Let's not encourage use of with too much |
| 16:14 | <annevk> | especially since people tend to test only one browser... |
| 16:14 | <annevk> | nothing wrong with with |
| 16:14 | <Philip`> | Dashiva: I generally hate with because it seems confusing and error-prone, but I didn't want to bother declaring another variable :-) |
| 16:15 | <annevk> | this feature allows you to imlement filters and I suppose that in theory you don't really care about the canvas pixels then but authors will break stuff |
| 16:16 | <Philip`> | For image filtering, it would be quite nice if the browser could JIT your JS code into optimised SIMD array operations... |
| 16:17 | <Philip`> | (Actually, I have no idea how fast it is with plain JS operating on arrays of integers) |
| 16:20 | <Philip`> | Oh, one problem with implementing filters... |
| 16:20 | <Philip`> | Normally you want access to both the old and new arrays of pixels |
| 16:20 | <Philip`> | (because you need all the old values in order to compute the new ones) |
| 16:21 | <Philip`> | but that doesn't seem easy with ImageData - you have to somehow copy the .data array into a new array, then modify the values in .data |
| 16:22 | <Philip`> | whereas it'd seem more natural (and more efficient) to use the old values from .data and create a new array, then swap that new array back into the ImageData |
| 16:22 | <Philip`> | (but you can't because the array reference is readonly) |
| 16:25 | <annevk> | you could simply create a new object it seems |
| 16:25 | <annevk> | but given that you can do that it doesn't make much sense for .data to be readonly imo |
| 16:26 | <annevk> | although the design is quite clear I don't think I particularly like these methods |
| 16:26 | <annevk> | I'm pretty sure authors will almost directly rely on them returning specific results |
| 16:30 | <annevk> | cool, bbc guys will show up at XTech |
| 16:31 | annevk | hopes they can give some info on Dirac |
| 16:33 | <hsivonen> | annevk: do they have a session? |
| 16:34 | <annevk> | dunno, just saw some guy from bbc commenting on molly.com |
| 16:36 | <maikmerten> | I hope Dirac's bitstream specification will be declared stable in a foreseeable timeframe so useful implementation can be assembled |
| 16:36 | <maikmerten> | (that'd be schrodinger.sf.net - dirac's real-life implementation) |
| 16:37 | <Philip`> | annevk: Oh, oops, I forgot you could create a new one |
| 16:38 | <Philip`> | http://canvex.lazyilluminati.com/misc/filter.html - takes about 1.5 seconds to do the simplest useful filter on 300x150 pixels |
| 16:39 | <Philip`> | (...in FF3) |
| 16:42 | <Dashiva> | I didn't know crashing my opera was a useful filter, but okay |
| 16:42 | annevk | will file the bug |
| 16:42 | <Philip`> | Oh, that's not quite the intent |
| 16:43 | <annevk> | it's good |
| 16:43 | <Philip`> | Opera 9.20 avoids crashing, which is good :-) |
| 16:43 | <annevk> | better to discover it now |
| 16:45 | Philip` | still forgot about imgdata.width != canvas.width when he first wrote this code |
| 16:45 | <annevk> | right |
| 16:47 | <Philip`> | (At least the filter algorithm doesn't care about that issue, but I was looping over the wrong array range) |
| 16:49 | annevk | e-mails the list |
| 16:52 | <Philip`> | It would be alright if imgdata.width != canvas.width all the time in every browser, because then everybody would notice when they first tried testing |
| 16:52 | <annevk> | or simply assume it's 2* |
| 16:52 | <Philip`> | (but that would be silly for implementations which have one canvas pixel per device pixel) |
| 16:53 | <annevk> | the thing is that can paint on half a pixel in theory |
| 16:53 | <annevk> | because everything is float (ugh! thanks Apple) based |
| 16:54 | <annevk> | if that wasn't the case you could just force 1 = 1 i suppose |
| 16:55 | <Philip`> | http://canvaspaint.org/paint.js - their getPixel assumes imgd.width == canvas.width |
| 16:55 | <Philip`> | (Not sure why they commented out that code, though...) |
| 16:56 | <Philip`> | (unless it was just because nobody had implemented getImageData when they wrote that page) |
| 16:56 | <annevk> | didn't work maybe? |
| 16:57 | <annevk> | Opera getPixel() actually assumes 1=1 as well in some way though I suppose it returns slightly weird things if you painted half a pixel before invoking it or something |
| 16:58 | annevk | wonders if anybody actually uses the floats |
| 16:59 | <Philip`> | http://svn.sourceforge.net/viewvc/*checkout*/jsmsx/trunk/msx.js?revision=20 - they get it wrong too |
| 16:59 | <annevk> | can you maybe cite those on the list? |
| 16:59 | <annevk> | otherwise I'm willing to do it |
| 17:00 | <Philip`> | I will do - I'll just see if I can find anybody doing it right first :-) |
| 17:00 | <annevk> | (i really like that people are doing MS Paint in <canvas> btw, really nice :) ) |
| 17:00 | <annevk> | next: photoshop :) |
| 17:02 | <Philip`> | I noticed there was some new Adobe application where they're written most of the code in Lua, and that kind of thing could work just as well in JS. But I guess they cheated and wrote optimised image-processing code in C++ instead :-( |
| 17:02 | <annevk> | (drawing rectangles seems kind of messed up) |
| 17:03 | <annevk> | <canvas> + XMLHttpRequest could do that :) |
| 17:03 | <annevk> | well, once it supports sending bytes over the wire better |
| 17:04 | Dashiva | is reminded of ajax <blink> |
| 17:11 | <Philip`> | Ooh, I found one using it correctly |
| 17:11 | <annevk> | oh cool |
| 17:13 | <annevk> | which one? |
| 17:17 | <Philip`> | http://tech.groups.yahoo.com/group/canvas-developers/files/buttons.html - might need to register/login to access that, though |
| 17:18 | <Philip`> | Hmm, it would be easier to find people use canvas getImageData if it didn't use horribly common terms like "canvas" and "getImageData" so searches find people using dozens of other graphics libraries instead |
| 17:20 | <Philip`> | Oh, perhaps http://f1.grp.yahoofs.com/v1/gORFRoOLlxuXtJddXwdSyravD-aFfgNuYoSzjI8vUevuBxus3V1sXs5xckiHKd1osiUpDE_bku-vtGMFPV_M-2JZkLKXTqc/buttons.html works without logging in |
| 17:21 | <annevk> | yeah |
| 17:24 | <annevk> | I wonder what the expected rendering is... |
| 17:25 | <annevk> | The last one and a half button should be blue? |
| 17:25 | <Philip`> | Yep, it switches the red and blue components for the square (2000,0)-(3000,500) |
| 17:26 | <Philip`> | (I've no idea why it does that) |
| 17:26 | <Philip`> | (More precisely, I've no idea why the author decided to make it do that) |
| 17:32 | <annevk> | maybe just a test |
| 19:36 | Philip` | realises that drawImage(toDataURL) won't work as expected because it'll convert device pixels into image pixels, then draw image pixels as canvas pixels |
| 20:38 | <annevk> | Philip`, images are drawn as CSS pixels |
| 20:38 | <annevk> | actually, isn't that defined? |
| 20:38 | <annevk> | treat an image pixel as a canvas pixel or something? |
| 20:38 | <annevk> | yeah, that's defined |
| 20:38 | <annevk> | "interpreted such that one CSS pixel in the image is treated as one unit in the canvas coordinate space" |
| 20:39 | <Philip`> | Oh, right |
| 20:39 | <Philip`> | That's quite confusing - I expected it was equivalent to drawImage(img, 0, 0, img.width, img.height) because anything else is weird |
| 20:40 | <Philip`> | That also means sw,sh and dw,dh are different units, which is confusing |
| 20:41 | <annevk> | huh? |
| 20:41 | <Philip`> | Actually, not sure what I mean |
| 20:41 | <annevk> | it should be equivalent to that... |
| 20:42 | Philip` | is confused more now |
| 20:42 | <annevk> | one image pixel is mapped to a canvas pixel |
| 20:42 | <Philip`> | If I have <canvas width=100 height=100> and want to draw img to fill it, would I say ctx.drawImage(img, 0, 0, 100, 100)? |
| 20:43 | <Philip`> | (and img is a 100x100 PNG or something) |
| 20:43 | <Philip`> | Oh |
| 20:43 | <Philip`> | but img.width is in CSS pixels too, not real pixels |
| 20:43 | <annevk> | that should work |
| 20:43 | <Philip`> | so img.width is not necessarily 100 |
| 20:43 | <annevk> | it is |
| 20:44 | <annevk> | one image pixel is one CSS pixel |
| 20:44 | <Philip`> | Still confused :-) |
| 20:45 | <annevk> | you have device pixels, CSS pixels, canvas pixels and image pixels |
| 20:45 | <annevk> | the latter is really equivalent to CSS pixels for the purposes of visual browsers aiui |
| 20:45 | <annevk> | drawImage() takes one CSS pixel and makes it a canvas pixel |
| 20:46 | <annevk> | so a 100x100 PNG would fill a 100x100 canvas |
| 20:46 | <annevk> | and styling an image using CSS with 'width:200px' would also not modify a 200px width image (ever) |
| 20:46 | <annevk> | s/width image/wide image/ |
| 20:47 | <Philip`> | I think what I expect is that <img src="some-100x100-image.png"><canvas width=100 height=100>...ctx.drawImage(img, 0, 0, img.width, img.height) would fill the canvas, and ctx.drawImage(img, 0, 0) would do exactly the same, regardless of whatever the browser decides to do |
| 20:47 | <Philip`> | ...which seems to be what is specified, so that's alright, unless I'm wrong |
| 20:47 | <annevk> | that's what the spec says |
| 20:48 | <Philip`> | Okay - then it still leaves the problem of converting device pixels to image pixels in toDataURL (which doesn't seem specified), and then treating image pixels = CSS pixels = canvas pixels when drawImaging again |
| 20:49 | <Philip`> | (I'd assume toDataURL isn't meant to lose all the high-res data if you've got >1 device pixel per canvas pixel, because that wouldn't be nice, so it has to map device pixels onto image pixels) |
| 20:49 | <annevk> | toDataURL makes a PNG |
| 20:49 | <annevk> | oh you mean that 1 canvas pixel must become 1 image pixel? |
| 20:49 | <Philip`> | Will toDataURL on a <canvas width=100 height=100> always make a 100x100 PNG? Or does that depend on how many device pixels are in the canvas? |
| 20:50 | <annevk> | 1 canvas pixel becomes 1 image pixel imo |
| 20:50 | <Philip`> | So toDataURL/drawImage will lose data? |
| 20:50 | <annevk> | might |
| 20:50 | <Philip`> | That would seem quite annoying if you're trying to use toDataURL to implement a 'save image' button |
| 20:51 | <annevk> | make a high res <canvas> |
| 20:51 | <annevk> | and scale it down using CSS |
| 20:51 | <annevk> | I'm actually all for going completely in that direction |
| 20:51 | <annevk> | and have getImageData and putImageData do the same |
| 20:51 | <annevk> | far more predictable |
| 20:52 | <Philip`> | Have the author explicitly make a high-res canvas when they want to support users with high-res displays? |
| 20:52 | <annevk> | no, when they want to support high-res output |
| 20:53 | <annevk> | <canvas height="1000" width="1000" style="height:100px;width:100px"> |
| 20:53 | <Philip`> | And then toDataURL would give a 1000x1000 image |
| 20:54 | <annevk> | yeah |
| 20:54 | <annevk> | I think it does now |
| 20:54 | <Philip`> | What if the user already has a clever browser and a really high-res display, so it puts 10x10 device pixels per canvas pixel? |
| 20:54 | <annevk> | same |
| 20:54 | <Philip`> | and then it ends up with 10000x10000 device pixels for that canvas |
| 20:54 | <annevk> | no |
| 20:55 | <annevk> | well, maybe if it does some clever subpixel rendering... |
| 20:55 | <Philip`> | Otherwise it would have to depend on the CSS computed size |
| 20:55 | <Philip`> | Or it would have to always have 1 device pixel = 1 canvas pixel |
| 20:55 | <Philip`> | (where the latter case makes everything easy, as far as I can see :-) ) |
| 20:55 | <annevk> | no it wouldn't |
| 20:56 | <annevk> | CSS pixel != device pixel |
| 20:56 | <annevk> | you'd get weird styling effects and such |
| 20:57 | <Philip`> | If I have <canvas width=1000 height=1000> and a browser with 10x10 device pixels per canvas pixels, then the "size of the coordinate space" is 1000x1000, so that would give 10000x10000 device pixels? |
| 20:57 | <annevk> | it depends on display |
| 20:57 | <annevk> | on the device, really |
| 20:58 | <annevk> | device pixels = actual rendering |
| 20:58 | <annevk> | so it's not really about the browser |
| 20:58 | <Philip`> | However many device pixels it gives, does <canvas width=1000 height=1000 style="width:100px; height:100px"> give the same number? |
| 20:59 | <annevk> | unlikely |
| 20:59 | <annevk> | actually, no |
| 20:59 | <Philip`> | If it depends on the computed CSS size, what would happen with <canvas style="width:100%"> when the user resizes their browser and the computed CSS size changes? |
| 21:00 | <annevk> | the canvas pixel to CSS pixel ratio would change? |
| 21:00 | <annevk> | (amount of canvas pixels is always fixed) |
| 21:00 | <Philip`> | But the number of device pixels in the canvas would stay the same? |
| 21:01 | <annevk> | (as in, unsigned integer) |
| 21:01 | <annevk> | Philip`, no, device pixels is the amount of pixels used to render the canvas on the screen (= device) |
| 21:02 | <Philip`> | How can the browser change the number of device pixels being used to store the image in the canvas, without making a mess of the canvas's contents? |
| 21:03 | <annevk> | Philip`, I would think the browser stores the data internally and eventually scales it based on CSS provided and puts it on the screen |
| 21:04 | <annevk> | that's sort of what happens with scaled images iirc |
| 21:04 | <Philip`> | With things like getImageData, "device pixels" is used for the underlying pixel data that's stored internally |
| 21:05 | <annevk> | it's all a bit confusing |
| 21:05 | <Philip`> | I would tend to agree ;-) |
| 21:05 | <annevk> | but if that's your point I agree with your earlier suggestion about 1 device pixel = 1 canvas pixel |
| 21:06 | <annevk> | and by default 1 canvas pixel would be 1 css pixel |
| 21:07 | <Philip`> | The only way that seems to make sense to me is if the underlying pixel data stores exactly one pixel of data per canvas pixel, and getImageData/putImageData/toDataURL/drawImage act on that pixel data, and then that bitmap just gets rescaled by CSS or whatever at the final render-to-screen stage |
| 21:08 | <annevk> | http://twitter.com/annevk/statuses/61777592 |
| 21:08 | <annevk> | yeah |
| 21:08 | <annevk> | I wonder what other implementors would think |
| 21:09 | <annevk> | it would also allow us to get rid of all the floats... |
| 21:09 | <Philip`> | so a browser never has a higher-resolution bitmap to store the canvas data - it just scales up and looks a bit blurry |
| 21:09 | <Philip`> | (or the author makes canvas.width/height larger so there's more canvas pixels per monitor pixel) |
| 21:09 | <Philip`> | (if the author cares enough and makes sure they're not doing it all wrong) |
| 21:10 | <Philip`> | (and if the author has some way of determining that a certain user would benefit from a bigger canvas) |
| 21:10 | <annevk> | not sure if you can forbid UAs to do anti-alias |
| 21:11 | <annevk> | but getting the basics more consistent would be good |
| 21:11 | <Philip`> | Not sure why they'd be forbidden to anti-alias... |
| 21:11 | <annevk> | well, if you don't allow "subpixel" rendering |
| 21:11 | <annevk> | it might be tricky to smooth things now and then |
| 21:12 | <annevk> | (given that UAs actually do that now, dunno) |
| 21:12 | <Philip`> | They could do subpixel rendering inside a function, but the result would just be four bytes in a bitmap somewhere, so you could always retrieve and save and redraw the pixels without losing any information |
| 21:13 | <Philip`> | I suppose that would disallow supersampling antialiasing, where you just render to a big bitmap then scale down, but I didn't think anyone does that since it uses far too much memory |
| 21:17 | <Philip`> | Ah, an email - I think I agree with that, assuming I'm not mixing the terminology up again :-) |
| 21:19 | annevk | wonders if Apple guys would agree to getting rid of floats |
| 21:20 | <Philip`> | Which floats do you mean? |
| 21:20 | <Philip`> | It's still useful being able to draw to subpixel locations, because antialiasing does the right thing |
| 21:20 | <Philip`> | It's only really getImageData/putImageData where you want actual real pixels, not subpixels |
| 21:20 | <annevk> | hmm ok |
| 21:21 | <annevk> | but what if you put four different color subpixels into one pixel |
| 21:21 | <annevk> | what would getImageData do? |
| 21:21 | annevk | ponders |
| 21:22 | <Philip`> | If you draw a solid 0.5x0.5 green rectangle inside one pixel, it will modify the internal bitmap to have a rgba(0, 255, 0, 0.25) value there |
| 21:22 | <Philip`> | (because the antialiasing algorithm decides that pixel has 25% coverage by what you're drawing, which it approximates by giving 25% alpha across the whole pixel) |
| 21:22 | <annevk> | feel free to follow-up there with that |
| 21:25 | <annevk> | I suppose your idea might make it more acceptable |
| 21:32 | <Philip`> | http://canvex.lazyilluminati.com/misc/subpixel.html - 0.5x0.5 rectangles are drawn the same as 1x1 alpha=0.25 rectangles |
| 21:33 | <annevk> | you get vastly different results in Firefox and Opera |
| 21:36 | <annevk> | I think Opera does indeed do what you suggest |
| 21:36 | <annevk> | Firefox doesn't |
| 21:37 | <Philip`> | That's the effects of their CSS image resizing - Opera seems to be just repeating each pixel 100x100 times, Firefox 3 is doing smooth scaling (like Opera normally does with resized images), but in both cases the actual canvas is just a 3x3 array of pixels (which is what I want) |
| 21:39 | <annevk> | oh ok |
| 21:39 | <annevk> | so the actual back end does indeed do 1 <canvas> device pixel = 1 canvas pixel |
| 21:40 | <annevk> | I suppose that makes sense |
| 21:51 | <annevk> | some people actually think the HTML4 spec is more clear |
| 21:51 | <annevk> | see http://www.456bereastreet.com/archive/200705/is_html_5_a_slippery_slope/#comment17 |
| 21:51 | annevk | hopes he will give some suggestions on how to improve the text |
| 21:52 | annevk | is totally fine with the current text |
| 21:52 | <annevk> | well, the reading bit of it |
| 21:55 | <annevk> | (I was quite confused above. Confusing the internal <canvas> with the output on screen...) |
| 21:55 | <annevk> | (It just hit my why the difference in rendering is hardly an indicator of what's going on in this case :) ) |
| 22:01 | <annevk> | Philip`, can't the anti-aliasing algorithm differ per browser though? |
| 22:06 | <Philip`> | In theory it could, but in practice everyone seems to implement it in the standard way - a pixel of which a fraction 'n' is covered by (r,g,b,a) is just treated the same as a pixel entirely covered by (r,g,b,a*n) |
| 22:07 | <Philip`> | I don't know of any other ways to do it, without storing extra data (e.g. lots of subpixels) per pixel |
| 22:07 | <Philip`> | (and people don't really do the latter, in my experience) |
| 22:07 | <Philip`> | (*limited experience) |
| 22:07 | <annevk> | k |
| 22:08 | <annevk> | nice follow-up e-mail |
| 22:09 | <Philip`> | There are differences in how you decide how much of a pixel is covered by whatever's being drawn if you're e.g. drawing a gradient or a smoothly-filtered image (so it's not a single colour covering some fraction of the pixel), but still the output is a single (r,g,b,a) per pixel, and those differences don't matter much |
| 22:09 | <annevk> | I suppose height and width are still useful on ImageData |
| 22:10 | <Philip`> | I think they're still useful since otherwise you'd usually have to remember the width and height in extra variables somewhere, because you're going to be looping over them or multiplying by them |
| 22:11 | <annevk> | do you have tests on imagedata = {} not matching the actual definition? |
| 22:12 | <Philip`> | (In that button-drawing site I found where they actually used ImageData.width/height correctly, I think that was probably accidental and they just used width/height because they were convenient ways to access the numbers) |
| 22:13 | <Philip`> | I've not done any tests with ImageData |
| 22:13 | <annevk> | k |
| 22:13 | <annevk> | just have to catch a Hixie to update the spec |
| 22:16 | <Philip`> | http://www.w3.org/TR/html401/present/graphics.html#edef-B - I think the list there (TT/I/B/...) makes HTML4 far more readable, compared to HTML5 where the definitions are spread all over the place |
| 22:19 | <annevk> | Elements could supposedly have an introduction chapter with such informative descriptions... |
| 22:20 | <annevk> | the only thing it says is that they must be properly nested |
| 22:20 | <annevk> | no other requirements... |
| 22:21 | <Philip`> | The lack of requirements and of precision is probably what makes it readable :-) |
| 22:21 | <annevk> | id and class have no user agent requirements either |
| 22:22 | <annevk> | I suppose :) |
| 22:22 | <annevk> | it's a tutorial for authors :) |
| 22:22 | <annevk> | with a spec sticker on top and some DTD grammar here and there |
| 22:28 | <annevk> | I also believe that authors are better served with more interoperability than with a spec. Some vocal authors seem to disagree though |
| 22:29 | <annevk> | They are somehow under the impression that a clearer specification will improve authoring practices... |
| 22:29 | <annevk> | "Let me hit you with the specification-clue-stick" |