| 02:21 | <wirepair> | ugh, why won't black berry let me set a frame/iframe's src attribute in a loop |
| 03:53 | <boblet> | hey all, anyone know how I could get a rough snapshot of how many Japanese pages declare their language (without having to take a random sample and check each one)? |
| 07:59 | jgraham | watches the tumbleweed roll past |
| 09:38 | <foolip> | bah, it looks like MIME for <video> is irreparably broken already |
| 09:44 | <jgraham> | foolip: And you are surprised why? |
| 09:45 | <jgraham> | It's not like Content-Type has a glorious history of success |
| 09:45 | <foolip> | because Safari and Chrome have been broken all along and I never noticed |
| 09:45 | <foolip> | so I thought the state of things were good |
| 09:46 | <foolip> | not so |
| 09:47 | <Philip`> | By "good" I guess you mean "good for theoretical purity", not "good for users"? |
| 09:48 | <foolip> | mostly good as in "can point browser to URL without getting a window-full of garbled text" |
| 09:48 | <foolip> | as that tends to happen with things served as text/plain |
| 09:48 | <foolip> | (at least in Opera) |
| 09:49 | <jgraham> | In general I think |
| 09:49 | <jgraham> | But "I want to reload this <video> as a top-level resource" seems like rather a minor use0case compared to "I want to serve some video and I have no idea how to configure my server" |
| 09:50 | <jgraham> | Unless you believe that only qualified professionals will host <video> I guess |
| 09:50 | <foolip> | indeed, and many questions on e.g. stack overflow have turned out to be due to MIME |
| 09:50 | <jgraham> | the "youtube" scenario |
| 09:50 | <foolip> | still, no one has argued this point on the lists, as far as I remember |
| 09:51 | <jgraham> | Which point? |
| 09:51 | <foolip> | that we should simply ignore the MIME type because it's easier |
| 09:51 | <jgraham> | Maybe people don't like getting into pointless discussions with Julian |
| 09:52 | <jgraham> | It is easier if you point out that it is a compatibility requirement and so driven by market forces |
| 09:52 | <foolip> | I guess it's easier to just slide down the slippery slope and blame market forces when we have to change the spec to match reality |
| 09:52 | <foolip> | hehe, right |
| 09:54 | <foolip> | who is Julian, by the way? |
| 09:55 | foolip | Googles |
| 09:56 | <foolip> | conclusion: someone who makes a WebDAV client for the iPhone |
| 09:56 | <Workshiva> | Julian Reschke (+/- spelling) |
| 09:58 | <Workshiva> | He's the most active participant coming from the IETF side of things, more or less |
| 09:58 | <othermaciej> | foolip, jgraham: honestly a large part of our motivation was actual experience with people trying to move from the QuickTime plugin to <video>... they never even knew their server was configured wrong |
| 09:59 | <foolip> | othermaciej, was this communicated to the list? |
| 09:59 | <othermaciej> | I mentioned that it was for compatibility with content originally created for QuickTime in a public-html post |
| 09:59 | <foolip> | othermaciej, perhaps it was before my time |
| 09:59 | <othermaciej> | but anyway, it was more for existing video content than for new content |
| 09:59 | <othermaciej> | oh, you mean was it communicated before just now? |
| 09:59 | <foolip> | yes |
| 10:00 | <othermaciej> | I dunno |
| 10:00 | <foolip> | anyway, placing blame isn't the point, I'm just trying to figure out what to do now |
| 10:00 | <othermaciej> | when we first implemented <video> we were not following public-html much |
| 10:00 | <foolip> | the easiest is of course to always ignore the MIME type |
| 10:00 | <othermaciej> | IMO <video> should have the same "ignore MIME type always sniff" policy as <img> |
| 10:00 | <foolip> | is it even remotely possible to remove support for text/plain in Safari now? |
| 10:01 | <othermaciej> | I am also ok with reducing <video> sniffing to a few specific types |
| 10:01 | <foolip> | othermaciej, wouldn't that break deployed content? |
| 10:01 | <zcorpan_> | i kind of like that 'open video in new tab' in the context menu would play the video in a new tab and not show garbage in a new tab |
| 10:01 | <zcorpan_> | but maybe we should sniff there too |
| 10:01 | <othermaciej> | foolip: my guess is that there are only 3 kinds of errors that are remotely common |
| 10:02 | <othermaciej> | (a) video improperly served as application/octet-stream |
| 10:02 | <othermaciej> | (b) video improperly served as text/plain |
| 10:02 | <foolip> | zcorpan_, yeah, more sniffing would solve it, but that would mean duplicating the same sniffing in the browsers network layer and in the media framework |
| 10:02 | <othermaciej> | (or audio in both these cases!) |
| 10:02 | <othermaciej> | (c) audio/video served with a MIME type for some different audio/video type |
| 10:03 | <foolip> | right, I can't imagine there's anything outside of those that are relevant |
| 10:03 | <zcorpan_> | the spec currently doesn't support text/plain from that list |
| 10:03 | <othermaciej> | does the spec support (c)? |
| 10:03 | <zcorpan_> | yes |
| 10:03 | <zcorpan_> | if the other type is supported at least |
| 10:04 | <zcorpan_> | there's also the issue of which audio/video mime types should be supported |
| 10:04 | <othermaciej> | we could maybe do experiments to see if limiting sniffing to (a)+(c) or (a)+(b)+(c) is viable |
| 10:04 | <foolip> | right, the spec already implicitly requires sniffing after getting through the load-time "canPlayType" |
| 10:04 | <zcorpan_> | e.g. audio/mp3 ? |
| 10:04 | <othermaciej> | I know that at the time we first implemented <video>, that video content served as text/plain was alarmingly common |
| 10:05 | <othermaciej> | my guess would be that the proportion is now lower but the absolute amount, maybe not |
| 10:06 | <foolip> | what you're saying is effectively that Safari will keep ignoring the MIME type |
| 10:06 | <zcorpan_> | newer apaches don't send text/plain by default for unknown types |
| 10:06 | <foolip> | there's no point in limiting to video/known, application/octet-stream and text/plain, IMO |
| 10:06 | <othermaciej> | what do newer apaches send, nothing? |
| 10:06 | <othermaciej> | or application/octet-stream? |
| 10:07 | <zcorpan_> | i think they moved from text/plain to application/octet-stream to no content-type header at all |
| 10:07 | <zcorpan_> | don't know which versions |
| 10:07 | <othermaciej> | foolip: what would your preference be? no sniffing at all? current spec (a/o-s + video/known)? |
| 10:08 | <foolip> | othermaciej, my absolute preference would be Firefox's behavior, but it seems unlikely Safari could match that |
| 10:08 | <othermaciej> | what does Firefox do? |
| 10:08 | <foolip> | it only accepts its known media types and fails to play e.g. Ogg served as audio/wav |
| 10:08 | <foolip> | that's harder to do when using GStreamer/QuickTime, but possible |
| 10:09 | <foolip> | uh, I don't know why I said "absolute preference" |
| 10:09 | <othermaciej> | I guess they are less interested in mpeg-2, mpeg-4 or legacy QuickTime being served with wrong MIME types |
| 10:09 | <foolip> | indeed |
| 10:09 | <othermaciej> | presumably for ogg, there is no/less legacy of mislabeled content |
| 10:09 | <foolip> | but the day that Safari + everyone else support a common media type, this problem will show up |
| 10:10 | <othermaciej> | (or for WebM) |
| 10:14 | foolip | writes mail |
| 11:14 | <Philip`> | hsivonen: "I don't know if it is even *possible* to make Apache omit the Content-Type header" - like 'DefaultType none'? (http://httpd.apache.org/docs/2.2/mod/core.html#defaulttype) |
| 11:14 | <Philip`> | (That took about one minute of documentation-reading to find) |
| 11:17 | <Workshiva> | Philip`: Does that work now? |
| 11:18 | <Philip`> | It says "DefaultType None is only available in httpd-2.2.7 and later." so any version from January 2008 onwards should support it |
| 11:18 | <Philip`> | (Confusingly 2.2.7 was never actually released) |
| 11:23 | <Workshiva> | Philip`: Considering the upgrade rate on apache installs, it will be useful around 2015 then :) |
| 11:27 | <Philip`> | Workshiva: Do you have data for that? :-) |
| 11:28 | <Smylers> | Even people who upgrade Apache may keep their existing config. |
| 11:29 | <Workshiva> | Philip`: No, just personal bitterness from having to use apache 1.x as recently as this year |
| 11:29 | <Smylers> | And DefaultType none isn't the default, so people setting up sites with a sufficiently new Apache still need to know to change it. |
| 11:30 | <Philip`> | Smylers: hsivonen was talking about not knowing how to configure Apache's default, not about what the default default is |
| 11:30 | <Philip`> | Workshiva: http://philip.html5.org/data/server-versions-2.txt |
| 11:31 | <Philip`> | Workshiva: Hmm, the 2.2s look fairly evently distributed before and after 2.2.7 |
| 11:31 | <Philip`> | plus there's still loads of 2.0 and 1.3 |
| 11:32 | <Workshiva> | Yeah, those numbers don't surprise me |
| 11:32 | <Philip`> | (in data from early 2009) |
| 11:32 | <Workshiva> | Apache 3.5.1, though? That's a surprise |
| 11:32 | <Smylers> | Yeah, I know. I was just pointing out that Workshiva's 2015 estimate may still be optimistic for being able to expect sites to be configured correctly. |
| 11:33 | <Workshiva> | Smylers: The estimate for sites being configured correctly is and will remain Infinity |
| 11:34 | Philip` | notes that Apache looks much more common that IIS (by over 3x), which seems significantly different to Netcraft's figures |
| 11:35 | <Smylers> | So the choice is between waiting for infinity, or deciding that if an author has used the <video> element and its contents are identifiable as being a video then the intention is to play it as a video? |
| 11:35 | <Smylers> | Do Netcraft tally up pages or websites or IP addresses or servers? |
| 11:36 | <roc> | what have I done |
| 11:37 | <Philip`> | Workshiva: One of Apache/3.5.1 was on www.61.gov.cn, so presumably it's a secret project being developed for the Chinese government |
| 11:40 | <Philip`> | Smylers: They count something complex |
| 11:40 | <Philip`> | http://news.netcraft.com/active-sites/ |
| 11:41 | <Philip`> | The third graph in http://news.netcraft.com/archives/2010/07/16/july-2010-web-server-survey-16.html doesn't look good for Microsoft |
| 11:42 | <roc> | foolip: I'll continue that thread tomorrow after I've talked to Chris Double and got our story straight |
| 11:43 | <Philip`> | and looks closer to the wildly inaccurate numbers that I have |
| 11:44 | <Philip`> | so I guess one can conclude that the graphs are pretty meaningless as indicators of market share, since there's huge jumps when a single large provider changes or when the methodology changes |
| 11:47 | <hsivonen> | Philip`: thanks |
| 11:48 | <Smylers> | Alternatively, you can conclude that a wide range of graphs are available to pick from, to support your choice of view point... |
| 11:48 | <hsivonen> | Philip`: to split hairs, I didn't talk about not knowing how to configure the default. I was talking about how to take the header away by default. |
| 11:50 | <hsivonen> | aside: at one point, I configured hsivonen.iki.fi to default to application/octet-stream but somehow it has regressed to text/plain... |
| 11:51 | <Philip`> | hsivonen: I thought you talked about how to "configure to send no type as the fallback", i.e. configuring the default that will be sent (or rather not sent) when no other type has been specified for the file |
| 11:52 | <Workshiva> | hsivonen: I'm sure the distros have a hand in the pie as well |
| 11:53 | <hsivonen> | Philip`: I know how to change it from text/plain to application/octet-stream. I didn't know how to change it to "no type" |
| 11:53 | <hsivonen> | Workshiva: they sure do |
| 11:55 | <Philip`> | hsivonen: That makes it sound like you didn't know "DefaultType none", so I'm slightly confused as to what hairs are being split |
| 11:58 | <Philip`> | (I think my original thought was just that claiming to not personally know something that's trivially findable in the documentation didn't seem like a compelling or relevant argument, and didn't seem like a reason to non-historically blame Apache for anything) |
| 11:59 | <Philip`> | (I may just be misunderstanding the argument, though) |
| 12:00 | <hsivonen> | Philip`: the argument is that you need to know or bother to find out stuff to make Apache behave |
| 12:05 | <foolip> | Apache probably can't change the default for compat reasons anyway |
| 12:05 | <foolip> | wouldn't e.g. README files get the default? |
| 12:06 | <foolip> | roc, OK, I'm holding off any changes, but thanks for taking the time |
| 12:06 | <hsivonen> | foolip: yes |
| 12:08 | <foolip> | is there any successful standard with lots of implementors and users that isn't a big pile of cruft? |
| 12:08 | <foolip> | maybe PNG? or maybe it's just the same if one looks closer... |
| 12:09 | <hsivonen> | I was thinking of Western Continental European electrical sockets, but even they have at least 3 points of compat cruft |
| 12:10 | <foolip> | hsivonen, the kind we have in Sweden and presumably Finland? |
| 12:10 | <hsivonen> | foolip: right |
| 12:10 | <hsivonen> | (but, insanely, not in Denmark!) |
| 12:10 | <foolip> | the double ground is a bit odd, is that one of the 3? |
| 12:12 | <hsivonen> | foolip: I was thinking: 1) German ground, 2) French ground, 3) support for ungrounded devices in an Italian-compatible way |
| 12:12 | <hsivonen> | foolip: though one might argue that's only 2 pieces of cruft, since one grounding method has to count as non-cruft |
| 12:12 | <foolip> | oh, looks like I'm blissfully unaware of the inner workings of electrical sockets :) |
| 12:13 | <hsivonen> | and actually, these are plug features, not socket features, to be precise |
| 12:14 | hsivonen | thinks the EU should fine Denmark for the environmental waste of vendors having to ship different plugs there |
| 12:14 | <hsivonen> | it makes *no* sense for Denmark to have differently shaped plugs |
| 12:14 | <foolip> | I say fine Denmark regardless :) |
| 17:56 | <jgraham> | hsivonen: I note that the wiring laws in Sweden are insane (or have been so historically) and the design of the plug allows unsafe wiring |
| 17:57 | <jgraham> | Specifically grounding sockets is distressingly uncommon in residential properties (I think it is now required in new-build) |
| 17:58 | <jgraham> | And the plug fails-unsafe if you plug into a non-grounded socket (i.e. it is possible to plug an appliance that should be grounded into a non-grounded socket and have it work, just without grounding) |
| 17:59 | <jgraham> | So I would not really call that ideal design |
| 18:01 | <jgraham> | (by contrast the UK plug design with a mandatoy ground pin seems safer) |
| 18:04 | <hober> | UK shaver/bathroom plugs only have two pins |
| 18:05 | <jgraham> | Indeed |
| 18:05 | <jgraham> | They are low volatge though |
| 18:06 | <jgraham> | (in general we don't have much in the way of electrics in the bathroom) |
| 18:06 | <jgraham> | (because, uh, we don't like dying) |
| 18:08 | <tabatkins> | We just make sure that bathroom sockets have a breaker built-in, so they'll cut out quicker. |
| 18:08 | <Workshiva> | Swiss use three plugs, but apparently the middle one is optional because standard two-plug plugs work fine with three-hole sockets |
| 18:10 | <TabAtkins> | Yeah, that's American sockets too. |
| 18:10 | TabAtkins | high-fives the swiss. |
| 18:12 | <jgraham> | TabAtkins: OTOH the US plugs fricking *spark* when you insert them |
| 18:12 | <TabAtkins> | jgraham: They do! It's kinda cool. |
| 18:12 | <jgraham> | So you have nothing to be proud of |
| 18:14 | <TabAtkins> | I have never known anyone to have ever actually been shocked by the sparking, so shrug. |
| 18:14 | <Workshiva> | Standard European plugs are the only worthwhile ones |
| 18:14 | <Workshiva> | Everyone else needs to get in line |
| 18:18 | jgraham | hopes like crazy Sweden at least has radial wiring |
| 18:20 | <jgraham> | umm... I'm not sure if that's what I mean |
| 18:20 | jgraham | reads more |
| 18:21 | <hsivonen> | jgraham: yeah, the plug design isn't ideal |
| 18:22 | <hsivonen> | but I assume the ability to plug to a non-grounded socket is a deliberate design decision |
| 18:22 | <hsivonen> | IIRC, the North American gounding pin has the opposite design |
| 18:24 | <TabAtkins> | Yes. |
| 18:24 | <hsivonen> | (it blew my mind when I learned that the UK design isn't electrically equivalent to the continental design) |
| 18:24 | <Smylers> | jgraham: I misread that as “because, uh, we don't like drying” — which also kind-of works as an explanation. |
| 18:24 | <TabAtkins> | non-grounded plugs can go to a grounded socket, but not the other way around. |
| 18:25 | <hsivonen> | (that is, in UK and Ireland, there's a device-side fuse in each plug, while the Continental design puts the fuse in a fuse box on the socket side) |
| 18:25 | <jgraham> | hsivonen: In what way "not electrically equivalent" the ring main vs radial thing? Or something else? |
| 18:25 | <hsivonen> | jgraham: fuse placement. see above |
| 18:25 | <hsivonen> | jgraham: and whatever ring vs. radial stuff comes with that |
| 18:25 | jgraham | notes that the UK also typically has circuit breakers on the whole circuit |
| 18:26 | <jgraham> | AFAICT from wikipedia the whole UK design was inspired by a need to save copper when everything was rebuild post WW2 |
| 18:27 | <jgraham> | It seems that a ring main is a way to achieve that but you have to also have fuses in the appliances |
| 18:28 | <jgraham> | (because the saving coppewr thing means that you are running lots of appliances off the same circuit) |
| 18:29 | <TabAtkins> | Is there a name for rgb color units? The things that there are 255 of in each channel? |
| 18:29 | <hsivonen> | putting the fuse on the plug side implies that the treat model assumes the devices are trusted and cooperative |
| 18:29 | <jgraham> | hsivonen: Howso? |
| 18:30 | <hsivonen> | I was aware that European voltages saved copper compared to American, but I wasn't aware that the UK design saved even more |
| 18:30 | <hsivonen> | jgraham: if the design requires a device-side fuse, the system isn' fused right if you plug in a rogue (cheap?) device that doesn't have a fuse |
| 18:31 | <jgraham> | hsivonen: The whole circuit is still fused |
| 18:31 | hsivonen | has seen cheap adapters that allow fuseless devices to be plugged into UK sockets |
| 18:31 | Philip` | thought it was a legal requirement that devices do things correctly (i.e. have fuses, and are grounded or double-insulated) |
| 18:31 | <jgraham> | Philip`: I think so too |
| 18:32 | <jgraham> | I guess maybe you could buy an unfused travel adaptor and bring it to the UK |
| 18:32 | <Smylers> | hsivonen: And the adapters themselves don't have fuses in them? |
| 18:32 | <hsivonen> | Smylers: proper ones have, but I've seen bogus ones |
| 18:33 | <jgraham> | hsivonen: Yes, in that specific case you are in marginally more danger. Although wikipedia claims that modern circuit breakers are likely to trip before the fuse blows anyway |
| 18:33 | <hsivonen> | Smylers: the bogus ones are a piece of plastic that has an extended that goes into the grounding hole openin the other slots for a continental plug |
| 18:33 | <hsivonen> | s/extended/extender/ |
| 18:34 | <jgraham> | In the common case (UK devices on a UK circuit) you are marginally better off since you can set the fuse to the right level for the device |
| 18:35 | <Philip`> | I guess it's also easier to replace the fuse when it's in the plug |
| 18:35 | <hsivonen> | Philip`: nope |
| 18:36 | <jgraham> | No one uses real fuses now anyway |
| 18:36 | <TabAtkins> | I'd assume just the opposite. |
| 18:36 | <jgraham> | Except in plugs |
| 18:36 | <Smylers> | hsivonen: A plastic earth pin just means it isn't earthed. Double-insulated devices are allowed to do that anyway. But they can still have a fuse, which is in the connection to the live pin. |
| 18:37 | <hsivonen> | the UK design has merit, but the most annoying part is that the plugs are so big, so a person with a UK laptop power supply plus an adapter takes up 2 or 3 sockets at a conference |
| 18:38 | <jgraham> | Yeah, the bigness is unfortunate |
| 18:38 | <hsivonen> | the same problem repeats with continental plugs in American conferences, though it tends to be less serious |
| 18:38 | jgraham | has that problem a lot at home :) |
| 18:41 | <hsivonen> | I guess the only redeeming feature of the Danish plug is that the gounding pin is on the plug side as in North America |
| 21:12 | <JonathanNeal> | so if hidden indicates that the element is not visible or perceivable to any user, what do you call something visually hidden but not hidden to screen readers? |
| 21:12 | <TabAtkins> | "visually hidden". |
| 21:13 | <TabAtkins> | Btw, if anyone's going to be at OSCON, I'm now going to be giving part of a talk there tomorrow. |
| 21:13 | <JonathanNeal> | Bummer, I had no desire to be there this year and didn't try to go. |
| 21:13 | <JonathanNeal> | I wonder if some Liferay peeps will be there. |
| 21:57 | <hober> | TabAtkins: filling in for mark p? |
| 22:01 | <TabAtkins> | hober: Yeah. |
| 22:08 | <hsivonen> | are iframes that are not inserted into a document supposed to be able to navigate? |
| 22:10 | <hsivonen> | Hixie: if an iframe that has been in a document is removed from a document, is it supposed to be able to navigate? |
| 22:10 | <hsivonen> | it being the detached iframe that is |
| 22:11 | <Hixie> | sure, why wouldn't it? |
| 22:11 | <Hixie> | (no browsers except chrome currently do this) |
| 22:11 | <hsivonen> | Hixie: it doesn't navigate before it has been inserted |
| 22:11 | <hsivonen> | Hixie: well, then, maybe it shouldn't! |
| 22:12 | <Hixie> | possibly not. It's worth noting that gmail actually uses that feature to make gmail faster in chrome. |
| 22:13 | <Hixie> | not sure how that affects things. |
| 22:13 | <hsivonen> | interesting... |
| 22:13 | <Hixie> | the spec would have to be changed to somehow kill the nested browsing context when the iframe is removed from the document |
| 22:13 | <Hixie> | would you want it to survive being removed then reinserted? |
| 22:13 | <hsivonen> | so does window.parent of the iframe point to the window of the owner doc, still? |
| 22:14 | <hsivonen> | Hixie: I'm not sure what I want yet, but Gecko misbehaves if it is tricked into loading into a detached iframe |
| 22:14 | <hsivonen> | via location.reload() |
| 22:15 | <Hixie> | the answer to that rests on the interpretation of "in" in the context of an element being in a document |
| 22:15 | <Hixie> | ah |
| 22:15 | <hsivonen> | Hixie: a detached element still has the owner doc, right? |
| 22:15 | <Hixie> | yeah |
| 22:16 | <Hixie> | ah, i define "in a document" |
| 22:16 | <Hixie> | so the answer is window.parent === window when the iframe is removed from the parent doc |
| 22:16 | <hsivonen> | currently, if Gecko is tricked into loading into a detached iframe, the inner window in the iframe is null |
| 22:16 | <Hixie> | that seems bad |
| 22:17 | <zcorpan_> | Hixie: are you going to work on websockets this week? |
| 22:17 | <Hixie> | zcorpan_: yp, starting now |
| 22:17 | <Hixie> | yup, even |
| 22:17 | <zcorpan_> | Hixie: cool |
| 22:17 | <hsivonen> | window.parent === window looks like "top level" to me |
| 22:17 | <jgraham> | vwls r vrrtd |
| 22:17 | <hsivonen> | I wonder if accidents happen if an iframe looks too much like "top level" |
| 22:18 | <gsnedders> | jgraham: rlly? |
| 22:18 | <hsivonen> | if chome gets perf benefits, maybe we should make the window exist in that case (as opposed to disallowing the load) |
| 22:19 | <hsivonen> | *chrome |
| 22:19 | <jgraham> | zcorpan_: You decided not to file the ws:foo bug on browsers? |
| 22:19 | <Hixie> | hsivonen: a lot of this stuff was defined by accident, as a side-effect of the spec covering all bases, and not intentionally |
| 22:19 | jgraham | realises it looks like he is talking about web services |
| 22:19 | <zcorpan_> | jgraham: no i filed it |
| 22:20 | <zcorpan_> | https://bugzilla.mozilla.org/show_bug.cgi?id=580234 |
| 22:20 | <zcorpan_> | https://bugs.webkit.org/show_bug.cgi?id=42636 |
| 22:20 | <jgraham> | zcorpan_: OK. So what is the behaviour you expect in the WebSockets case? |
| 22:20 | <Hixie> | hsivonen: my understanding is that what gmail is actually doing is grafting the iframe into a new document and having that work |
| 22:21 | <jgraham> | (I assume you filed bug 10213) |
| 22:21 | <Hixie> | hsivonen: not so much when the frame is an orphan |
| 22:21 | <Hixie> | hsivonen: though it'd be a bit weird to prevent the orphan case from working |
| 22:21 | <zcorpan_> | jgraham: bz filed it |
| 22:21 | <hsivonen> | Hixie: ah. slightly different case |
| 22:21 | <Hixie> | hsivonen: yeah |
| 22:21 | <jgraham> | zcorpan_: Oh |
| 22:21 | <Hixie> | hsivonen: i'm not 100% familiar with it |
| 22:22 | <zcorpan_> | jgraham: i'd be fine with either syntax_err or implied // |
| 22:22 | <Hixie> | zcorpan_: re bugs, if they're in the websocket component i'll see them |
| 22:23 | <zcorpan_> | Hixie: what's the websocket component? other hixie drafts? |
| 22:26 | <Hixie> | it's whatever my script picks when you file a bug on the websockets part of the complete.html spec |
| 22:26 | <Hixie> | "WebSocket API (editor: Ian Hickson)" in product "WebAppsWG" |
| 22:29 | <zcorpan_> | changed |
| 22:32 | <Hixie> | ta |
| 22:48 | <TabAtkins> | Hixie: <canvas> composite question. We're all arguing about the interpretation of a term in the spec. ^_^ |
| 22:49 | <TabAtkins> | in the globalCompositeOperation stuff, the term "source image" is used. Is the source image a conceptually infinite canvas containing what is being drawn, or is it just the actual pixels dirtied by the latest draw operation? |
| 22:49 | <Philip`> | Which term? |
| 22:50 | <Philip`> | TabAtkins: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#drawing-model |
| 22:50 | <Philip`> | The source image in the composite step is A |
| 22:50 | <jamesr> | that drawing model is awkward |
| 22:50 | <Philip`> | which is an infinite bitmap |
| 22:51 | <Hixie> | what Philip` said |
| 22:51 | <TabAtkins> | Ok. |
| 22:53 | <TabAtkins> | We're arguing because Safari/Chrome treat it as just the dirtied pixels, and will probably have difficulty changing. |
| 22:53 | <Philip`> | "pixels dirtied" seems a difficult thing to define, when you can have transparent images and shadows and antialiasing |
| 22:54 | <Hixie> | not to mention that some of the path routines can result in conceptually near-infinite lines iirc |
| 22:54 | <Philip`> | The clipping region is finite so that doesn't seem like a problem |
| 22:56 | <othermaciej> | tabatkins: I believe the IE team prefers the Safari/Chrome interpretation of globalCompositeOperation |
| 22:56 | <Philip`> | TabAtkins: Compute the bounding box of the dirtied pixels, draw the shape onto a layer of that size, draw the layer onto the canvas, then draw some conceptually transparent-black rectangles (in an efficient way) over the rest of the clipping region? |
| 22:56 | <othermaciej> | I advised them to post about this, I do not know if they did |
| 22:57 | <TabAtkins> | Philip`: CoreGraphics does the dirtied-pixel thing, and Skia does the same (presumably for platform compat). |
| 22:58 | <Philip`> | TabAtkins: I don't see why it would be hard to emulate the spec behaviour |
| 22:58 | <TabAtkins> | Philip`: The spec's definition of globalCompositeOperation requires most methods other than the defualt source-over to recompute every pixel in the canvas. |
| 22:58 | <Philip`> | Only 4 of the methods, I think |
| 22:58 | <Philip`> | Oh, 5 |
| 22:59 | <Philip`> | (The ones in http://philip.html5.org/tests/canvas/suite/tests/index.2d.composite.uncovered.html) |
| 22:59 | <TabAtkins> | the two in/outs, and destinatop-atop. |
| 22:59 | <Philip`> | In the common case (globalAlpha=1) the "recompute" is just "clear to 0" |
| 23:04 | <TabAtkins> | othermaciej: Who'd you talk to on IE, if you remember? |
| 23:08 | <Philip`> | Oh, that's not just the common case |
| 23:08 | <othermaciej> | tabatkins: I think they ended up posting to the canvas api list that almost no one is on |
| 23:08 | <Philip`> | That's every case |
| 23:08 | <Philip`> | because the alpha multiplication happens before the compositing |
| 23:08 | <Philip`> | so I think if the composite mode is one of the 5 then you can always just clear the whole canvas before drawing onto it |
| 23:09 | <othermaciej> | tabatkins: http://lists.w3.org/Archives/Public/public-canvas-api/2010AprJun/0046.html |
| 23:09 | <Philip`> | which seems like it ought to be pretty trivial to implement |
| 23:09 | <Philip`> | (unless I'm missing something important) |
| 23:09 | <othermaciej> | they emailed us privately after that, not sure if I should say who specifically (they are sensitive about private communication at times) |
| 23:12 | <jamesr> | othermaciej: the reply to that email on public-canvas-api appears to say that roc is switching to match safari |
| 23:12 | <jamesr> | which presumably means the spec is also changing? |
| 23:12 | <othermaciej> | jamesr: sounds like the spec should probably switch, then, if it says the other thing or is ambiguous |
| 23:13 | <Philip`> | What does Safari do for http://software.hixie.ch/utilities/js/live-dom-viewer/saved/571 ? |
| 23:13 | Philip` | only has a Chromium on Linux which doesn't support shadows |
| 23:14 | <zcorpan_> | Philip`: i see just an image with the cats in safari |
| 23:14 | <roc> | jamesr: you misunderstand |
| 23:14 | <jamesr> | i think i do, the reply doesn't make much sense |
| 23:14 | <roc> | we have some bugs where we don't currently follow the spec |
| 23:15 | <roc> | particularly on Mac |
| 23:15 | <roc> | I have patches to fix those bugs so we follow the spec always |
| 23:15 | <jamesr> | Philip`: in firefox i see odd blue stuff on the left and cats on the right. in safari i just see some cats on the right |
| 23:15 | <TabAtkins> | Yeah, following the email in Pritchard's email suggests that the spec was revised *to the current text*, describing FF/Opera's behavior. |
| 23:15 | <TabAtkins> | It looks like Pritchard just totally misunderstood what the IE team email was talking about. |
| 23:15 | <Philip`> | jamesr: In Firefox it breaks because of image compositing bugs |
| 23:15 | <jamesr> | roc: ok. the post from the microsoft fellow was suggesting that the spec be changed, and then the reply implied that you were going to change firefox |
| 23:15 | <roc> | othermaciej is right that the IE team prefers the source-bounded (Safari/Chrome) approach |
| 23:15 | <jamesr> | so that reply is just wrong |
| 23:16 | <Philip`> | zcorpan_: Hmm, that seems odd |
| 23:16 | <Philip`> | zcorpan_: What do you get if you remove the shadow lines? |
| 23:16 | <roc> | jamesr: I actually think you're misunderstanding Charles' email, maybe |
| 23:17 | <jamesr> | Philip`: i don't think that it is as simple as "just clear the whole canvas before drawing onto it" |
| 23:17 | <roc> | I think Charles is just saying that the spec unambiguously defines the behavior of globalCompositeOperation, and that Firefox will change to follow the spec, which is true |
| 23:17 | <TabAtkins> | roc: Correct, we are (though I think it's because his email was phrased very badly). |
| 23:17 | <roc> | sure |
| 23:17 | <zcorpan_> | Philip`: then i get half the cats as blue and a blue rectangle below it |
| 23:18 | <jamesr> | Philip`: you would have to calculate the compositing results, stick that somewhere (in a buffer on the side presumably), clear the canvas, then put the compositing results into the canvas |
| 23:18 | <Philip`> | jamesr: I think I should have said "just clear the whole region of the canvas which is outside the area you're drawing pixels into" |
| 23:18 | <roc> | the main problem with the Safari/Chrome(/IE?) approach is that you would need to add to the spec a definition of what the bounds of the source actually are, in all cases |
| 23:18 | <roc> | and no-one has done that |
| 23:18 | <Philip`> | jamesr: Yeah, but the buffer only needs to be the size of the dirtied pixels, not the whole canvas |
| 23:18 | <roc> | and it doesn't seem particularly easy |
| 23:18 | <othermaciej> | roc: would you or anyone else at Mozilla be likely to object to changing the spec to the Safari/Chrome/IE-preferred behavior (assuming it was well-defined)? |
| 23:18 | <jamesr> | it's not consistent in safari in all cases |
| 23:18 | <roc> | it may add considerable complexity to spec |
| 23:19 | <jamesr> | for example, imho drawing a circle should be the same as drawing an image that contains a circle with a transparent background |
| 23:19 | <jamesr> | currently they render differently in safari |
| 23:19 | <TabAtkins> | roc: Apparently, the definition is "for images [and other things drawn onto the canvas, suitably defined], dirty region is the size of the image. Everything else, it's all non-transparent pixels." |
| 23:19 | <TabAtkins> | That's the definition that Safari/Chrome is using right now. |
| 23:19 | <Philip`> | zcorpan_: Okay, that's what I see in Chromium |
| 23:19 | <TabAtkins> | (Though the image case is dumb, for the reason that jamesr mentions.) |
| 23:20 | <Philip`> | TabAtkins: That doesn't seem to work for shadows |
| 23:20 | <Philip`> | If I'm not mistaken, http://software.hixie.ch/utilities/js/live-dom-viewer/saved/571 really ought to at least draw some blue where the rectangle and image and shadow overlap |
| 23:20 | <TabAtkins> | Philip`: Maybe not - we didn't look at shadows yet. |
| 23:21 | <roc> | TabAtkins: so you're saying that for the "copy" operator, for every pixel in the source with alpha > 0, the corresponding destination pixel is set to the source pixel, but for every pixel in the source with alpha == 0, the corresponding destination pixel is unchanged? |
| 23:21 | <roc> | that sounds very strange |
| 23:22 | <TabAtkins> | I think so, yeah. |
| 23:22 | <roc> | that doesn't match the behavior of any graphics library I know |
| 23:23 | <TabAtkins> | I'm not looking at it right now, but I think that's precisely what CG does. |
| 23:23 | <Hixie> | (also sounds far less efficient than just copying the data over) |
| 23:23 | TabAtkins | goes to mock up that for himself to verify again. |
| 23:23 | <roc> | it's certainly not what cairo does |
| 23:23 | <TabAtkins> | Yeah, Cairo does all the composite operations correctly. |
| 23:24 | <roc> | I'm also not sure what you mean by "[and other things drawn onto the canvas, suitably defined]" |
| 23:26 | <Philip`> | TabAtkins: (I think it does copy wrong, at least in some version of Firefox on Linux) |
| 23:26 | <TabAtkins> | roc: I mean drawing video and such on. I haven't tested video drawing, but I suspect it's treated the same as image drawing. |
| 23:26 | <roc> | oh, you mean everything drawn with the drawImage API? |
| 23:27 | <roc> | In general, defining exactly what the source bounds are seems rather subtle. For example if you have a stroked path, the bounds can't just be the path bounds, they have to be inflated to include the stroke, but do you just include the stroke or the interior as well? What if the stroke is dashed? You can go with your definition, weird as it is, but it won't necessarily match what authors expect |
| 23:27 | <roc> | and it certainly won't match with what graphics libraries do, other than CG if what you say is correct |
| 23:28 | <TabAtkins> | Okay, yeah, copy is identical to source-over in CG and Skia. |
| 23:29 | <roc> | so pixels with alpha==0 are transferred to the destination? |
| 23:29 | <TabAtkins> | Yes. |
| 23:29 | <roc> | phew |
| 23:29 | <roc> | ok |
| 23:29 | <TabAtkins> | Wait. |
| 23:29 | <Philip`> | That's not what source-over does |
| 23:30 | <TabAtkins> | What I mean is that if I draw a red rectangle, set composite to "copy", then draw a partially overlapping blue circle, what I get is a red rectangle overlapped by a blue circle, exactly the same as source-over. |
| 23:30 | <roc> | othermaciej: if someone comes up with a proper definition for how source-bounded operators should behave, and that definition is simple and useful, then sure, we'd change |
| 23:30 | <Hixie> | and if someone comes up with a proper definition for how source-bounded operators should behave, and that definition is simple and useful, i'd be happy to spec it |
| 23:30 | <Hixie> | but so far nobody has |
| 23:30 | <Hixie> | so... |
| 23:31 | <jamesr> | otherwise, though, i'm not sure how we these composite operations will ever become interoperable |
| 23:31 | <TabAtkins> | roc: Okay, yeah, alpha=0 pixels are copied over. so it is different from source-over. |
| 23:31 | <roc> | TabAtkins: what if you fill the circle with a gradient which is completely transparent in some region, then what? |
| 23:32 | Philip` | still doesn't see why WebKits can't emulate the Firefox/Opera/spec behaviour easily, which would achieve interoperability |
| 23:32 | <roc> | I refuse to believe that any graphics library would just drop the transparent region out of the source bounds |
| 23:32 | <TabAtkins> | The difference in behavior is completely described by CG/Skia doing the composite operation correctly, but in a *local* region rather than globally. |
| 23:32 | <roc> | TabAtkins: sure, but you need to precisely define the bounds of that local region. That is the entire issue. |
| 23:33 | <TabAtkins> | Right. |
| 23:33 | <TabAtkins> | Just clarifying what our behavior is. ^_^ |
| 23:33 | <roc> | Philip`: it is quite easy. I did it for the cairo CoreGraphics backend. |
| 23:33 | <jamesr> | roc: where's the code? |
| 23:34 | <jamesr> | othermaciej: if you want to change this in coregraphics webkit ports then we'd change the skia backend to match |
| 23:35 | <jamesr> | of course microsoft also prefers the safari version, but they haven't proposed a tight definition of the source image bounds |
| 23:35 | <Hixie> | jamesr: chrome could also lead the way, no need to follow apple on this :-P |
| 23:35 | <roc> | I can accept that the source-bounded version is more intuitive for authors |
| 23:36 | <jamesr> | yeah i find the firefox behavior bizarre honestly. if i draw a 20x20 rectangle why would all the other pixels in the canvas change |
| 23:36 | <TabAtkins> | Hixie: We have to have the same behavior on both CG and Skia, so having Apple fix CG is just easier. ^_^ |
| 23:36 | <roc> | although, sometimes results that are "more intuitive" are actually less intuitive if you look at them closely |
| 23:36 | <Hixie> | TabAtkins: lame :-P |
| 23:36 | <jamesr> | TabAtkins: i'm not suggesting that someone at apple be forced to do the work, i'm wondering if that would make sense for the other folks who ship coregraphics webkit ports |
| 23:36 | <TabAtkins> | I think the FF behavior is fine. It's just something you generally have to use backing canvases to take proper advantage of. |
| 23:37 | <Philip`> | jamesr: The other pixels would all change because you explicitly chose a composite operation that causes pixels to change :-) |
| 23:37 | <TabAtkins> | But backing canvases are already an established technique in <canvas> use, so that seems fine. |
| 23:37 | <jamesr> | i also think that it's likely nobody uses these modes given how non-interoperable the existing implementations are |
| 23:37 | <Philip`> | If you don't want that to happen, don't use those composite operations |
| 23:38 | <TabAtkins> | It would be somewhat nice to be able to spawn off a backing canvas directly from a single <canvas> tag, rather than creating and inserting a new canvas, but that can be fixed later. |
| 23:38 | <roc> | jamesr: my cairo-quartz code is here: https://bugzilla.mozilla.org/show_bug.cgi?id=522859 |
| 23:39 | <roc> | the actual fix hasn't landed yet |
| 23:39 | <roc> | TabAtkins: you don't need to insert a temporary canvas anywhere |
| 23:40 | <TabAtkins> | roc: For some uses you do. Frex, if you already have an image, and you want to draw some lines over it with, say, source-atop. You can't just set globalCompositeOperation to source-atop and start drawing lines. |
| 23:40 | <Hixie> | TabAtkins: (why can't you just clone it?) |
| 23:40 | <TabAtkins> | WEll, actually, with source-atop you could. |
| 23:40 | <roc> | I mean you don't ned to insert it in the DOM |
| 23:40 | <roc> | from an implementors point of view, the current spec wins |
| 23:40 | <TabAtkins> | roc: Oh, for some reason I thought you needed to insert it into the document before it would work. Shrug. |
| 23:42 | <roc> | I'm pretty sure that if we went with a source-bounded approach and nailed down exactly what the source bounds are in all cases, all but possibly one implementation/port would need significant changes |
| 23:43 | <jamesr> | well, to implement the current spec also requires several implementations to make some changes (webkit/coregraphics webkit/skia and whatever IE has). i don't know if they would be significant in terms of code |
| 23:46 | <jamesr> | roc: do you have a d2d backend for canvas yet in firefox? |
| 23:46 | <roc> | yep |
| 23:46 | <roc> | I don't know how compliant it is with this stuff |
| 23:46 | <roc> | however |
| 23:47 | <roc> | D2D does not really support compositing modes at all |
| 23:47 | <roc> | you have to drop down to D3D/shaders |
| 23:47 | <jamesr> | presumably you'll hit the same issues the IE9 team has |
| 23:47 | <roc> | (in Gecko we don't have "canvas backends", there's just cairo which we use for everything) |
| 23:51 | <roc> | jamesr: what issues are those? |
| 23:53 | <jamesr> | well, to do something like fillRect() the most natural (to me) way to do that on a gfx card is to create a quad and draw it, using a fragment shader to implement the blending |
| 23:54 | <jamesr> | but that doesn't work if you also have to do some composite operation on pixels that land outside the quad |
| 23:58 | <roc> | that's probably why D2D doesn't support blend modes |
| 23:59 | <roc> | the thing is, in shaders you generally don't get to read the destination pixel |
| 23:59 | <roc> | so blend modes are a pain either way |