| 00:01 | Hixie | casts around for abarth |
| 00:20 | Philip` | finds that it's pretty trivial to circumvent cross-origin font canvas tainting via timing attacks |
| 00:25 | <Hixie> | Philip`: for the "find which characters are in the font" attack? |
| 00:29 | <Philip`> | Finding the shapes of the glyphs |
| 00:30 | <Hixie> | in that case you should be able to get data from any cross-origin image too, no? |
| 00:33 | <Philip`> | When filling text, if the glyph is outside the clipping area then it doesn't even attempt drawing any pixels |
| 00:33 | <Philip`> | which affects the timing significantly |
| 00:33 | <TabAtkins> | Oh, interesting. |
| 00:33 | <TabAtkins> | So, apply 1px clipping area, and profit. |
| 00:34 | <Philip`> | With images it'll draw every pixel regardless of the value, so any differences would be far more subtle |
| 00:34 | <Hixie> | is there an expensive composite mode or shadow or something that can make it different enough? |
| 00:35 | <TabAtkins> | Given the current canvas operations, I doubt it. |
| 00:35 | <TabAtkins> | None of the mechanics should operate significantly differently based on the color of the canvas. |
| 00:39 | <Philip`> | http://philip.html5.org/demos/canvas/font-timing.html - very rough prototype |
| 00:39 | <Philip`> | In Chromium 9.0 I get a very clear "A" shape after the first iteration |
| 00:40 | <Philip`> | (on Linux) |
| 00:40 | <Philip`> | Opera 11.10 gives a sort of triangle shape that improves over time |
| 00:41 | <roc> | doesn't seem to work on Firefox |
| 00:41 | <Hixie> | i don't really understand what we're protecting against here, personally |
| 00:41 | <Hixie> | wfm on firefox on mac |
| 00:41 | <Philip`> | Firefox just seems to hang my windowing system for tens of seconds until I get impatient and click X and then it closes a minute later |
| 00:43 | <roc> | on windows I mean |
| 00:43 | <roc> | it depends on the font backend I guess |
| 00:43 | Philip` | means on Linux and hasn't tested elsewhere |
| 00:43 | <Hixie> | chrome and firefox on mac seem to very quickly give an A |
| 00:44 | <roc> | on Mac we fall back to explicit path filling for large font sizes and I'm not surprised that that triggers optimizations when the path doesn't intersect the clip |
| 00:44 | <roc> | on Windows we don't do that ourselves, who knows what GDI and D2D do |
| 00:45 | <roc> | anyway, neat demo! |
| 00:45 | <Hixie> | indeed |
| 00:45 | <TabAtkins> | <3 timing channel attacks |
| 00:45 | <roc> | you can't |
| 00:46 | <Philip`> | TabAtkins: I'm sure there's more than 3 |
| 00:46 | <Hixie> | aw man, now you've surely gotten him going through the unicode pages |
| 00:47 | <Philip`> | In Chromium on Linux it seems mostly fill-rate dependent, rather than being dependent on clipping - the difference is much smaller with non-'lighter' compositing |
| 00:47 | <jamesr> | roc: the font size is 10px, there's just a large scale applied |
| 00:47 | <Hixie> | TabAtkins: U+2665, U+2764, or the U+1F491-U+1F49F range |
| 00:47 | <jamesr> | Philip`: try with a large font size |
| 00:47 | <jamesr> | i dunno if we consider the scale when deciding whether to use GDI to raster or grab a path and fill the path |
| 00:47 | <roc> | jamesr: I mean the post-resize scale factor |
| 00:48 | <jamesr> | we probably _should_ be using the post-resize scale factor |
| 00:48 | <Philip`> | jamesr: Browsers seem to care about fontsize * scalefactor, e.g. in Chromium it stops drawing the text if that's more than 12K or something |
| 00:48 | <Philip`> | and in Firefox it seems to clamp the post-scale font size |
| 00:48 | <Philip`> | (in 4.0, on Linux) |
| 00:49 | <Philip`> | (That "12K" isn't a precise figure, I just think it broke after about 12px with scale 1024) |
| 00:50 | <jamesr> | Philip`: try applying a very slight skew |
| 00:51 | <jamesr> | might force you down the path case in more cases |
| 01:11 | <Philip`> | http://philip.html5.org/demos/canvas/img-timing-1.html - works for me in Chromium |
| 01:11 | <Philip`> | http://philip.html5.org/demos/canvas/img-timing-2.html - works for me in Opera |
| 01:12 | <Philip`> | (Warning: artwork may be disturbing) |
| 01:14 | <jamesr> | i'm just getting noise |
| 01:14 | <roc> | interesting |
| 01:14 | <jamesr_> | hm, works better on linux |
| 01:14 | <jamesr_> | so it's testing blend time? |
| 01:15 | <Philip`> | ((This is just drawImageing one pixel of an image at a time, and transparent vs solid makes a difference)) |
| 01:15 | <roc> | their compositing code has special cases for zero alpha? |
| 01:15 | <roc> | I'm surprised that wins |
| 01:15 | <jamesr_> | i wonder what layer is doing that |
| 01:16 | <jamesr_> | we have some special case code for 1x1 transparent images in various bits of the codebase (mostly for spacer.gif) |
| 01:16 | <Philip`> | My Chromium is faster for alpha=255 than for alpha=0 |
| 01:16 | <Philip`> | (in default source-over compositing) |
| 01:16 | <jamesr_> | but is alpha=254 different from alpha=255? |
| 01:16 | <jamesr_> | and what platform are you on? chrome/mac=coregraphics, chrome/win or linux=skia |
| 01:17 | <roc> | Firefox/Linux would be XRender, that would be interesting to test |
| 01:17 | <erlehmann> | i have firefox on linux, what should i test? |
| 01:17 | <jamesr_> | getting noise in Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0a1) Gecko/20110523 Firefox/6.0a1 |
| 01:17 | <erlehmann> | Philip`, am i right with the interpretation that you attempt to read cross origin resources via timing attacks? |
| 01:17 | <Philip`> | Chromium seems to be slow for alpha=0, alpha=1ish, alpha=254ish, fast for alpha=255 |
| 01:17 | <jamesr_> | the values are pretty low - 1/2 |
| 01:18 | <jamesr_> | Philip`, yeah then it's probably a check for full transparent that skips blending |
| 01:18 | <Philip`> | (I'm using Chromium 9.0 on Linux) |
| 01:18 | <jamesr_> | 9.0? wtf |
| 01:18 | <jamesr_> | what museum did you steal chromium 9.0 from? |
| 01:19 | <AryehGregor> | It's probably the default version on Debian or something. |
| 01:19 | <AryehGregor> | They like years-old software. |
| 01:19 | <Philip`> | I installed chromium-bin on Gentoo some time ago, and they stopped updating it |
| 01:19 | <jamesr_> | debian is 6.0 |
| 01:19 | <AryehGregor> | Nice. |
| 01:19 | <Philip`> | and I haven't cared enough to find a new version |
| 01:20 | <roc> | I'll p0wn your system and update you to something reasonable |
| 01:20 | <erlehmann> | I use Chromium 6.0 |
| 01:20 | <erlehmann> | In before owned. |
| 01:20 | <AryehGregor> | Of course, I could easily get some ancient version of Chrome too, on Linux, if the package repository got uninstalled or something. |
| 01:20 | <AryehGregor> | Not just Chromium. |
| 01:20 | <Philip`> | Opera with 'lighter' compositing seems to be fast for alpha=0, slow for everything else |
| 01:21 | <jamesr_> | hah |
| 01:22 | Philip` | hasn't tried other modes |
| 01:22 | <jamesr_> | http://code.google.com/p/skia/source/browse/trunk/src/core/SkDraw.cpp#1113 |
| 01:22 | <Philip`> | erlehmann: Yes, it's trying to extract image data without using getImageData/toDataURL (thus avoiding the cross-origin-information-leakage checks) |
| 01:22 | <jamesr_> | i think that's the early out in question here |
| 01:23 | <Philip`> | erlehmann: and you should get a rough smiley face in the table if it's working (possibly after waiting a while for it to do multiple iterations) |
| 01:23 | <jamesr_> | only useful for fully transparent vs not, though, which is way less useful than the webgl case |
| 01:23 | <jamesr_> | where you can get arbitrary bits from arbitrary color channels |
| 01:23 | <erlehmann> | Philip`, *very* rough. but i see it. hopefully we can all use your timing attacks instead of JSONP now ;P |
| 01:24 | <jamesr_> | hm, if you could somehow apply a color mask before doing this attack then you could get more info out |
| 01:25 | <jamesr_> | roc is probably chuckling evilly about http://weblogs.mozillazine.org/roc/archives/2011/02/distinguishing.html :) |
| 01:25 | <roc> | well |
| 01:25 | <Philip`> | jamesr_: I think you can get arbitrary bits from the alpha channel - draw the image to a temporary canvas with globalAlpha=0.5, then if a pixel was previously non-transparent and is now transparent then you know it must have alpha=1, etc |
| 01:26 | <Philip`> | (I'm assuming drawImage of canvas is the same as drawImage of img, which is false, but anyway) |
| 01:27 | <roc> | jamesr_: I would be chuckling if I wasn't one of the people who are going to be on the hook for solving the problem... |
| 01:27 | <roc> | so I feel more like a deep sigh |
| 01:28 | <roc> | jamesr: is that really your early-exit path here? |
| 01:29 | <roc> | I sort of doubt t |
| 01:29 | <Philip`> | Do any browsers have high-resolution timers yet? |
| 01:29 | <Philip`> | (That'd probably make this much easier than with Date.now()) |
| 01:30 | <jamesr_> | roc, i dunno, i'm just completely guessing |
| 01:33 | <roc> | async rendering, like pretty much any GPU-accelerated canvas, should make these timing attacks much more difficult |
| 01:33 | <roc> | so it'd be interesting to try on FF4/Windows, or IE9, or Chrome with acceleration enabled |
| 01:33 | <jamesr_> | the webgl demos work fine with readback |
| 01:34 | <jamesr_> | or glFinish() |
| 01:34 | <jamesr_> | async is no help |
| 01:34 | <jamesr_> | you can force readback with canvas by doing getImageData |
| 01:34 | <Philip`> | You can't do getImageData if you've drawn cross-origin images |
| 01:34 | <jamesr_> | true, it's tainted |
| 01:34 | <jamesr_> | but you can just repeat the draw a bunch of times and observe throughput |
| 01:34 | <Philip`> | Would doing a drawImage of one canvas onto another cause a readback? |
| 01:34 | <jamesr_> | might add noise but it doesn't stop the fundamental issue |
| 01:35 | <jamesr_> | Philip`, it shouldn't |
| 01:35 | <jamesr_> | in our gpu impl it doesn't, modulo some weird bugs |
| 01:35 | <Philip`> | Is there anything you can do to a canvas to make it impossible to hardware-accelerate so it falls back to software? |
| 01:35 | <jamesr_> | like we have a lower size limit for gpu-backed canvas than for software-backed canvas |
| 01:35 | <jamesr_> | yeah |
| 01:35 | <jamesr_> | make it big but not too big |
| 01:35 | <jamesr_> | we'll probably also have to add some guards so if you make 20,000 canvas contexts some of them go software or something |
| 01:36 | <jamesr_> | i'm pretty sure you can get arbitrary color channels out through svg images somehow |
| 01:36 | Philip` | will add "var c = []; for (var i = 0; i < 20000; ++i) c.push(document.createElement('canvas').getContext('2d'))" to his script, then :-) |
| 01:37 | <jamesr_> | Philip`, in chromium today that is more likely to just crash or something |
| 01:37 | <jamesr_> | we haven't implemented ctx limiting like that |
| 01:37 | <Philip`> | Hmm, so use SVG in <img> which applies filters to an external image, then drawImage that into the canvas? |
| 01:38 | Philip` | guesses that shouldn't be too hard |
| 01:38 | <jamesr_> | assuming that svg allows you to map color channels to transparency somehow |
| 01:38 | <jamesr_> | which i'm sure it must, given that svg specifies everything under the sun |
| 01:39 | <tantek> | greetings. has anyone proposed <input type="identity-url"> in addition to <input type="url"> for use in login forms (possibly with <input type="password"> ) |
| 01:39 | <tantek> | use cases: all the sites out there that have login forms |
| 01:39 | <cgcardona> | TabAtkins: hello. regarding your tweet last night. Like this? http://pastebin.com/index/3gMc8EPY |
| 01:39 | <jamesr_> | heycam might know a way to magick this up in svg |
| 01:39 | <Philip`> | http://www.w3.org/TR/SVG/filters.html#feColorMatrixElement looks slightly powerful |
| 01:40 | <jamesr_> | oh good god |
| 01:40 | <jamesr_> | yup, gg |
| 01:40 | <tantek> | and enabling browsers to autodetect such forms for more reliable identity/password/URL remembering and auto-fill |
| 01:40 | <jamesr_> | Philip`, now i dunno if anyone implements that correctly such that it works (svg <img> in WebKit is super super buggy in general) |
| 01:40 | <jamesr_> | but it seems possible |
| 01:40 | <heycam> | yeah, feColorMatrix probably can do what you want there |
| 01:40 | <tantek> | I'm thinking of writing up a proposal for adding <input type="identity-url"> and wanted to first see if anything similar has already been proposed / rejected, and or if there is any earlier work I should look at and possibly cite. |
| 01:41 | <Philip`> | I suppose there's the possibility of timing attacks on SVG rendering directly, too |
| 01:42 | <roc> | in Gecko we disallow external resource loading in SVG <img> for exactly this reason |
| 01:42 | <roc> | well, for other reasons too |
| 01:42 | <smaug____> | tantek: just curious, what is an identity-url (and shouldn't it be uri?)? and where does user get it? |
| 01:42 | <roc> | but this is one of them |
| 01:43 | <Philip`> | Presumably that wouldn't help if you can time non-canvas non-img SVG rendering sufficiently, though |
| 01:43 | <tantek> | smaug____: in short, identity-url could be an OpenID, could be a RelMeAuth URL, or could be a mailto URL that is paired with a password for email/password login |
| 01:44 | <roc> | Philip`: well, yeah |
| 01:44 | <Philip`> | ...and if any part of SVG rendering is sufficiently sensitive to pixel values |
| 01:44 | Philip` | doesn't really care enough about SVG to see if that's feasible in practice, though |
| 01:44 | <tantek> | and in answer to "shouldn't it be uri?" - the short/easy answer is no, because <input type="url"> already exists in HTML5 (i.e. that bikeshed fight has already been fought - so let's just re-use the existing pattern/decision. |
| 01:44 | smaug____ | has never heard of RelMeAuth :) |
| 01:44 | <tantek> | ) |
| 01:44 | <tantek> | LMGTFY |
| 01:45 | <smaug____> | but apparently someone called tantek has written about it :) |
| 01:45 | <tantek> | http://microformats.org/wiki/RelMeAuth |
| 01:45 | <Hixie> | what's the downside of making canvas drawing always async, anyway? seems like it'd be a perf win in general. |
| 01:46 | <Hixie> | (i mean, other than implementation complexity, obviously) |
| 01:50 | <roc> | in some cases, overhead |
| 01:52 | <roc> | james suggests that it doesn't really help because you can observe throughput |
| 01:52 | <roc> | which I sort of buy, although it increases the cost of the attack considerably |
| 02:16 | <jamesr_> | Hixie, roc: yeah. it is async in our accelerated canvas 2d implementation |
| 02:16 | <jamesr_> | might cut down on the bandwidth of the attack |
| 02:17 | <jamesr_> | any gpu-backed canvas drawing implementation will be async to one degree or another |
| 02:17 | <Hixie> | observe throughput? |
| 02:17 | <jamesr_> | do a bunch of draws instead of just one, see how long it takes |
| 02:17 | <jamesr_> | no matter how much buffering the system does at some point it'll have to actually evaluate the draws |
| 02:17 | <Hixie> | how can you tell? |
| 02:17 | <Hixie> | if it's async, you can't read it back, right? |
| 02:18 | <jamesr_> | lots of ways. force the draw to complete through some indirect method, or just wait until your call is blocked because all the buffers are full |
| 02:18 | <jamesr_> | or let it go to screen (which will force it to evaluate) and observe the screen repaint time |
| 02:18 | <jamesr_> | which you can get indirectly in a number of ways |
| 02:19 | <Hixie> | huh. will have to think about that. bbiab |
| 02:19 | <jamesr_> | you can't defer the draw forever |
| 02:19 | <jamesr_> | later |
| 06:02 | <hsivonen> | So it seems that ICU4J has a bug when it comes to determining if a year has 53 ISO weeks |
| 06:03 | <hsivonen> | I wonder where I could find the math to independently verify/generate the list of 53-week years that is available on Wikipedia: http://en.wikipedia.org/wiki/ISO_week_date#Weeks_per_year |
| 07:02 | <hsivonen> | does the JS Date object implement the proleptic Gregorian calendar all the way back to Year 1 CE? |
| 08:17 | <zcorpan> | so we still haven't published |
| 10:40 | <hsivonen> | the date and time-related input types are still implemented in only Opera, right? |
| 10:40 | <hsivonen> | properly, that is |
| 10:41 | <hsivonen> | Bogus WebKit impls don't count as implemented |
| 10:43 | <Ms2ger> | Sounds right |
| 10:48 | <hsivonen> | Ms2ger: ok |
| 10:48 | <hsivonen> | I'm a bit unhappy about caniuse.com overstating support in Chrome |
| 10:48 | <hsivonen> | so I have to actually check stuff myself instead of trusting caniuse |
| 11:02 | <zcorpan> | hsivonen: ping him about it on twitter |
| 11:15 | <jgraham> | I really wish the spec would drop callers on HTMLCollection |
| 11:15 | <jgraham> | AIUI Gecko doesn't implement them |
| 11:16 | <jgraham> | and the behaviour is undefined in edge cases |
| 11:16 | <jgraham> | and there is no good reason to use them |
| 11:34 | <Ms2ger> | jgraham, implement DOM Core instead? :) |
| 11:38 | <Lachy> | jgraham, it seems that Opera, IE and WebKit all implement callers |
| 11:41 | <jgraham> | Lachy: Yes. They still suck though |
| 11:42 | <jgraham> | And they're not interoperable in edge cases |
| 11:42 | <jgraham> | e.g. my_html_collection(-1) |
| 11:43 | <Lachy> | interop on edge cases can be fixed. The issue is whether the behaviour is needed at all for the common cases. |
| 11:43 | <jgraham> | Well since gecko doesn't implement it it seems like it might well not be needed |
| 11:44 | <jgraham> | We certainly shouldn't add new interfaces with this legacy gunk on |
| 11:44 | <jgraham> | Even if it is more consustent |
| 11:44 | <jgraham> | *consistent |
| 11:44 | <Lachy> | also, it seems the spec definition of HTMLCollection.item() is wrong. Implementations accept either an unsigned long index or DOMString name |
| 11:44 | <jgraham> | Allowing people to be consistently stupid isn't a win |
| 11:45 | <jgraham> | Isn't the DOMString a differnt method? |
| 11:45 | <Lachy> | yes, .namedItem(DOMString) works, but so does .item(DOMString) |
| 11:46 | <jgraham> | Oh ffs |
| 11:46 | Lachy | goes to file a bug |
| 11:50 | <Lachy> | oh, wait. No, my test was incorrect. .item("test") was simply returning the first control, like .item(0). |
| 11:51 | <jgraham> | same as .item() I guess |
| 11:51 | <jgraham> | ? |
| 11:51 | <Lachy> | hmm, no. IE does what I originally thought. |
| 11:52 | <Lachy> | other browsers don't. I guess we don't need that behaviour after all. I'll resolve my bug invalid |
| 11:53 | <hsivonen> | zcorpan: I pinged Fyrc on Twitter |
| 11:58 | <hsivonen> | zcorpan: regarding http://bugzilla.validator.nu/show_bug.cgi?id=817 , should I warn about more stuff than <style scoped>, date and time-related input, <input type=color>, <bdi>, <track>, <details>, <command> and <menu>? |
| 11:58 | <hsivonen> | should I warn about <mark> and <time>? |
| 12:04 | <Ms2ger> | meter? |
| 12:08 | <hsivonen> | Ms2ger: thanks |
| 12:16 | <MikeSmith> | hsivonen: if you are interested in working on http://bugzilla.validator.nu/show_bug.cgi?id=589 feel free to reassign it |
| 12:17 | <MikeSmith> | I had assigned it to myself when I was working a patch but I'm not going to be able to get back it to it til next week at the earliest |
| 12:19 | <hsivonen> | MikeSmith: I'm not in so much hurry that I couldn't wait for your patch :-) |
| 12:19 | <MikeSmith> | heh |
| 12:19 | <MikeSmith> | OK |
| 13:23 | <zcorpan> | hsivonen: type=color is supported by opera too |
| 13:25 | <hsivonen> | zcorpan: whoa. Thanks. (I should always test everything *again* instead of relying on my previous testing.) |
| 13:25 | <zcorpan> | hsivonen: i think <link sizes> is not supported anywhere |
| 13:25 | <hsivonen> | zcorpan: Apple's documentation suggests rel="apple-touch-icon" sizes="..." is supported |
| 13:26 | <hsivonen> | zcorpan: though apple-touch-icon is currently unregistered |
| 13:26 | <zcorpan> | oh, didn't know that |
| 13:27 | <zcorpan> | <blockquote cite>? ;) |
| 13:27 | <hsivonen> | zcorpan: hah. that's a good one. |
| 13:27 | <zcorpan> | <ol reversed> |
| 13:28 | <zcorpan> | <a ping>? what's the status on that? |
| 13:28 | <Ms2ger> | Mozilla has a broken, preffed off implementation since Fx3, I think that's it |
| 13:28 | <hsivonen> | IIRC, <a ping> is disabled in Firefox |
| 13:28 | <hsivonen> | does Chrome support <a ping>? |
| 13:29 | <hsivonen> | Ms2ger: what's broken about the Firefox impl (apart from being preffed off)? |
| 13:29 | <zcorpan> | hsivonen: fwiw <meter> is supported in opera |
| 13:29 | <Ms2ger> | The spec changed under us |
| 13:29 | <hsivonen> | zcorpan: thanks |
| 13:30 | <zcorpan> | crossorigin on img, video, audio |
| 13:30 | <zcorpan> | what's the status on <iframe srcdoc sandbox seamless>? |
| 13:31 | <zcorpan> | <video mediagroup> |
| 13:31 | <zcorpan> | (also on audio) |
| 13:31 | <zcorpan> | (ping is also on area) |
| 13:32 | <zcorpan> | <input dirname> <textarea dirname> |
| 13:33 | <hsivonen> | what's dirname? |
| 13:33 | smaug____ | should start reviewing the patch for <meter> |
| 13:33 | <hsivonen> | I have a vague recollection of Chrome having one or two of the new iframe attributes |
| 13:33 | <smaug____> | not that really understand the reason for progress *and* meter |
| 13:33 | <zcorpan> | contextmenu="" |
| 13:34 | <zcorpan> | dropzone=""? |
| 13:34 | <zcorpan> | itemid |
| 13:34 | <zcorpan> | itemprop |
| 13:34 | <zcorpan> | itemref |
| 13:34 | <zcorpan> | itemscope |
| 13:34 | <zcorpan> | itemtype |
| 13:35 | <zcorpan> | hsivonen: it's a new bidi thing |
| 13:35 | <hsivonen> | zcorpan: I think I'm not going to warn on microdata, since it's not particularly dangerous to use it ahead of browser impls |
| 13:36 | <zcorpan> | that's fair enough |
| 13:36 | <hsivonen> | I didn't add warning for stuff like <footer> for that reason |
| 13:36 | <zcorpan> | <footer> is also implemented these days |
| 13:36 | <hsivonen> | though using <section><h1> might be a bit dangerous, but that ship has sailed so it's not worthwhile to warn about it |
| 13:37 | <hsivonen> | I'm not familiar with the threat scenarios with premature use of dropzone |
| 13:39 | <zcorpan> | dunno |
| 13:41 | <zcorpan> | maybe it's not so much of a treat, but would still be helpful to know why it doesn't work |
| 13:41 | <zcorpan> | s//h/ |
| 13:57 | <hsivonen> | smaug____: progress is for progress bars. meter is for things like disk space usage indicators |
| 13:57 | <hsivonen> | smaug____: different widgets e.g. on Mac |
| 13:57 | <smaug____> | oh, there is a different widget on some system |
| 13:58 | smaug____ | has given up with mac |
| 14:00 | <hsivonen> | it seems that Chrome doesn't support <iframe srcdoc> or <iframe seamless> |
| 14:00 | <hsivonen> | <iframe sandbox> can't be verified visually |
| 14:01 | <hsivonen> | oh. I guess I should add validation of the text/html-sandboxed MIME type, too |
| 14:02 | <hsivonen> | http://blog.chromium.org/2010/05/security-in-depth-html5s-sandbox.html |
| 14:02 | <hsivonen> | looks like they have support |
| 14:10 | <hsivonen> | oh. nice. Opera Mini has a hidden pref for turning off phone number linkification |
| 14:10 | <hsivonen> | (that almost always ends up linkifying something that isn't a phone number) |
| 14:13 | <smaug____> | chrome/linux seems to have different rendering for meter and progress, Opera/linux has the same |
| 14:27 | <hsivonen> | it's sad that CSP uses an X- header |
| 14:28 | <hsivonen> | did Chrome implement CSP with the X- syntax? |
| 14:28 | <hsivonen> | that is, is CSP now more than a product-specific thing_ |
| 14:28 | <hsivonen> | ? |
| 14:44 | <hsivonen> | hmm. bitbucket is down :-( |
| 14:46 | <Philip`> | Their web site looks okay to me |
| 14:50 | <hsivonen> | Philip`: https://bitbucket.org/validator/syntax/changesets fails for me |
| 14:50 | <hsivonen> | "Oops! An error occurred" |
| 14:51 | <hsivonen> | "Someone kicked over the bucket, sadface" |
| 14:51 | <hsivonen> | oh. now it loaded |
| 15:16 | <hsivonen> | wow. provisionally-registered HTTP headers that start with X- http://www.iana.org/assignments/message-headers/prov-headers.html |
| 15:16 | <hsivonen> | my sympathies to whoever fought the fight with the Designated Experts on those ones |
| 15:20 | hsivonen | discovers http://tools.ietf.org/html/draft-mutz-http-attributes-01 |
| 15:47 | <hsivonen> | Hixie: do you have any plans to import X-Content-Security-Policy and X-Frame-Options to HTML without invoking the "applicable specs" clause? |
| 15:53 | <hsivonen> | FWIW, I investigated doing HTTP header validation today |
| 15:54 | <hsivonen> | but decided against it, because real Web content uses unregistered headers too often to make it practical to whine about all unregistered headers |
| 15:54 | <hsivonen> | I did, however, add a warning about X-UA-Compatible as an HTTP header |
| 15:55 | <zcorpan> | hsivonen: what about validating headers without whining about unregistered ones? |
| 15:55 | <hsivonen> | zcorpan: I guess validating their contents would be a possibility |
| 15:56 | <zcorpan> | hsivonen: do you show the headers in Show Source? |
| 15:57 | <hsivonen> | zcorpan: I don't, but showing them would make sense |
| 16:00 | <hsivonen> | Apache has made API-breaking changes to HttpClient |
| 16:00 | <hsivonen> | I wonder if I should continue to use the old version and write more code with that API or migrate existing code to the new API and then add more code... |
| 17:04 | <TabAtkins> | Jeezus, we have to deal with @longdesc *again*? |
| 17:05 | <Ms2ger> | Of course |
| 17:08 | <jgraham> | TabAtkins: longdesc is like the apocalypse. Every time it fails to get in the spec the believers will announce that there was a mistake and it will be delayed a few months |
| 17:10 | <jgraham> | Anyway this time it will probably get in. The politics of the situation make it increasingly unlikely that it will be rejected |
| 17:11 | <TabAtkins> | The politics being "they won't shut up about it"? |
| 17:11 | <jgraham> | Microsoft have supported it all along and are generally pro anything that gets specs along the Rec. track so I doubt Paul will object |
| 17:11 | <jgraham> | I expect Sam to be swayed by the work Laura did |
| 17:12 | <AryehGregor> | Did they actually produce any good reasoning for why it should go in? |
| 17:13 | <AryehGregor> | By the standards the chairs gave in their last decision? |
| 17:13 | <jgraham> | They found a handful of sites that used it |
| 17:13 | <AryehGregor> | Used it usefully? |
| 17:14 | <jgraham> | Dunno |
| 17:14 | <jgraham> | They also made a list of things that supposedly require longdesc |
| 17:15 | <jgraham> | Which were basically "describing" plus any type of image they could think of |
| 17:16 | <jgraham> | This didn't seem like "new" information in any meaningful sense of the word "new", but the WG operates in mysterious ways |
| 17:20 | <jgraham> | My personal plan is to ignore it and hope that if I ever go blind the people working in a11y have become more interested in solutions that work in the real world and less interested in dogmatically clinging to every failed idea |
| 17:30 | <Ms2ger> | jgraham, in that case, I'd try to avoid going blind ;) |
| 17:31 | <TabAtkins> | myakura: There's not. |
| 17:34 | <Philip`> | Ms2ger: I'd have thought you'd try to avoid that in any case |
| 17:41 | <myakura> | hmm. even if html5 gets longdesc but no other vendor's willing to support it, it needs to be dropped otherwise the spec won't proceed. |
| 17:43 | <twisted`> | hmm is it correct that if an input field is set to disabled it's value doesn't get posted? |
| 17:44 | <TabAtkins> | Yes. |
| 17:47 | <twisted`> | cool then I just use readonly |
| 17:47 | <twisted`> | :) |
| 18:14 | <AryehGregor> | Is foo.innerHTML = foo.innerHTML; foo.innerHTML = foo.innerHTML guaranteed to be the same as foo.innerHTML = foo.innerHTML? |
| 18:14 | AryehGregor | doesn't have any real reason to know, is just curious |
| 18:14 | <AryehGregor> | Or rather than "guaranteed to be", I should say "supposed to always be". |
| 18:18 | <Philip`> | As in, should fragmentparse(fragmentserialize(x)) be idempotent? |
| 18:19 | <AryehGregor> | Basically, yeah. |
| 18:27 | <jgraham> | There is some complexity around line breaks in <pre> I think. I seem to recall that the algorithm is such that the above holds though |
| 19:25 | <bga_> | heh is it possible to prevent {if(window !== top )top.location = '' + location}? |
| 19:26 | <bga_> | tried overwrite location setter |
| 19:26 | <bga_> | top getter |
| 19:26 | <jgraham> | Disable scripting? :) |
| 19:26 | <AryehGregor> | You mean, can you stop sites you put in frames from breaking out? Not really, no. |
| 19:26 | <AryehGregor> | Nor should you be able to. |
| 19:27 | <AryehGregor> | Since some sites don't want to be framed for security reasons. |
| 19:27 | <jgraham> | location is magic for security reasons |
| 19:27 | <jgraham> | Even before this it had to be because flash used it or something |
| 19:27 | <bga_> | heh |
| 19:30 | <bga_> | => only iframe's sandbox attribute |
| 19:38 | <JonathanNeal> | I had a javascript-related question about selections, and someone suggested I pop in here and ask about it. |
| 19:39 | <JonathanNeal> | I'm trying to get the raw HTML of the selected content on a page. For the sake of simplicity, I'm sticking with browsers supporting window.getSelection. |
| 19:39 | <JonathanNeal> | AryehGregor: are you speccing this stuff? |
| 19:39 | <AryehGregor> | JonathanNeal, yes. |
| 19:40 | <AryehGregor> | getSelection().getRangeAt(0).cloneContents() should get you something like what you want. |
| 19:40 | <AryehGregor> | If the Selection has only a single Range, it will return a DocumentFragment that clones that range's contents. |
| 19:40 | <JonathanNeal> | I've been looking over the MDC docs for days. I know how to get the normalized HTML, but the raw HTML seems to be much more difficult. |
| 19:41 | <AryehGregor> | What does "raw" mean here? |
| 19:41 | <JonathanNeal> | In your example, the contents would collapse any trailing elements. Say, for example, I had `<p>The <em>quick brown f|ox</em> jumps over the lazy <strong>d|og</strong>.</p> and the area between both | was my selection. I'd be looking to return `ox</em> jumps over the lazy <strong>d`. |
| 19:41 | <AryehGregor> | Not possible, all this stuff is DOM-based. |
| 19:41 | <AryehGregor> | Why do you want it? |
| 19:42 | <AryehGregor> | In general, keep in mind that the input HTML might bear little resemblance to the DOM. |
| 19:42 | <AryehGregor> | For instance, scripts might have changed the DOM, or various HTML parser quirks might have rearranged things. |
| 19:42 | <AryehGregor> | So conceptually, browsers convert the HTML input into a DOM and then throw it away. |
| 19:42 | <JonathanNeal> | Well, I guess you answered my question with "not possible". |
| 19:43 | <Ms2ger> | He had a capital "N", but yes :) |
| 19:43 | <AryehGregor> | E.g., if the raw HTML input is <table><td>foo</td>bar<td>baz</td><table>, the resulting DOM is the same as for bar<table><td>foo</td><td>baz</td></table>. If the user selects "foobar", what would you expect to get back? |
| 19:43 | <AryehGregor> | Anyway, as I said, why do you want it? |
| 19:44 | <JonathanNeal> | I've considered cloning the range into a start and end point, adding an anchor, then reading the common ancestor's HTML and string parsing for the anchors. |
| 19:44 | <JonathanNeal> | AryehGregor, oh you know, the usual, it's a Wednesday, I think I could write a better WYSIWYG. |
| 19:44 | <AryehGregor> | JonathanNeal, how do you read the common ancestor's HTML? |
| 19:44 | <JonathanNeal> | I had this going for a while http://sandbox.thewikies.com/content-editable/ |
| 19:44 | <AryehGregor> | innerHTML? That doesn't return the original HTML either. |
| 19:44 | <AryehGregor> | It returns a serialization of the DOM. |
| 19:44 | <JonathanNeal> | AryehGregor: I read the common ancestor's HTML with innerHTML |
| 19:45 | <AryehGregor> | Okay, so you don't actually want the original HTML that was given to the browser. |
| 19:45 | <AryehGregor> | (because innerHTML is not that) |
| 19:45 | <AryehGregor> | There's no API to create partial fragments of HTML like that, with mismatched tags and all. |
| 19:45 | <JonathanNeal> | I see. |
| 19:46 | <AryehGregor> | cloneContents() will get you "<em>ox</em> jumps over the lazy <strong>d</strong>", in your example. |
| 19:46 | <AryehGregor> | JonathanNeal, is that good enough for your purposes? |
| 19:47 | <JonathanNeal> | No, I'm looking for the partial fragment. It's okay, you're made it clear that there is nothing in the API to get this. |
| 19:48 | <JonathanNeal> | When I use the approach I mentioned earlier with the injected anchors, I notice that it messes with the appearance of the selection until I press a key or refocus the window. Lemme see if I can post an example --- I'm not sure if it's a browser bug or a "feature" that is supposed to be happening. |
| 19:48 | <AryehGregor> | Hmm. Is there a way to serialize the HTML of a DocumentFragment? |
| 19:49 | <JonathanNeal> | That would be awesome, though I've been assuming that the fragment was already normalized. |
| 19:49 | AryehGregor | dumps it into a div |
| 19:50 | <AryehGregor> | If by "normalized" you mean "opening and closing tags are paired up", yes, the DOM is always "normalized". |
| 19:50 | <AryehGregor> | JonathanNeal, see the log at the bottom here: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1005 |
| 19:50 | <AryehGregor> | It has the extra opening/closing tags. |
| 19:51 | <AryehGregor> | But you might be able to strip them off more easily than whatever you're doing now. |
| 19:51 | <AryehGregor> | Anyway, feel free to tell me about the injected anchors thing you're talking about. |
| 19:54 | <JonathanNeal> | I'm looking at what you mentioned. |
| 19:55 | <JonathanNeal> | I don't get what I was supposed to learn from the log, I guess. |
| 19:56 | <Hixie> | hsivonen: no current plans to spec those two headers, but if everyone implements them then i guess someone's gonna have to spec them |
| 19:56 | <AryehGregor> | JonathanNeal, the code I gave does what you asked for, just with extra opening tags at the start and closing tags at the end. |
| 19:56 | <AryehGregor> | You should be able to use that code and strip the leading/trailing tags you don't want much more easily than trying to parse innerHTML or whatnot. |
| 19:57 | <AryehGregor> | (I'm still not sure why you want such fragments; I suspect you don't) |
| 19:58 | <JonathanNeal> | Well, I want to write a WYSIWYG editor that inspects the HTML more like selectionStart for a textarea. |
| 19:59 | <AryehGregor> | As opposed to using the DOM? Why? |
| 19:59 | <AryehGregor> | It might look simpler, but it will cause all sorts of headaches if you try fiddling with innerHTML instead of the DOM. |
| 19:59 | <JonathanNeal> | Well, look at the example @ http://sandbox.thewikies.com/content-editable/ and use some of the buttons. It's just an idea. |
| 20:01 | <AryehGregor> | So when you do "bold source selection" it just sticks <b> at the start point and </b> at the endpoint in the HTML source. |
| 20:01 | <AryehGregor> | That's going to have unpredictable results. |
| 20:01 | <JonathanNeal> | AryehGregor: yea, and I understand how big of a problem that might be. |
| 20:01 | <AryehGregor> | Well, as long as you realize. |
| 20:02 | <JonathanNeal> | I do realize, and I was thinking of creating fake ranges and taking advantage of that "normalizing" to generate the proper HTML. |
| 20:02 | <Hixie> | what's that law about how the more groups you have working on technologies the more the techs are going to have friction points? |
| 20:03 | <Ms2ger> | Hixie's Law? |
| 20:03 | <Hixie> | no someone else came up with it |
| 20:03 | <Hixie> | hsivonen quotes it often |
| 20:04 | <hober> | Conway's Law? |
| 20:04 | <JonathanNeal> | AryehGregor: here's the weird selection "bug" I've been seeing @ http://sandbox.thewikies.com/selection/ |
| 20:04 | <Hixie> | conway! thanks |
| 20:05 | <AryehGregor> | JonathanNeal, I'm not seeing anything. Do I need to do something special? What browser are you using? |
| 20:05 | <JonathanNeal> | Select "ick brown fox jumps over the la" and it will suddenly change the selection to look like you selected something different, like " jumps over the la" |
| 20:05 | <JonathanNeal> | Firefox 4. |
| 20:05 | <hsivonen> | Hixie: the good thing is the X-Content-Security-Policy already has a spec |
| 20:05 | <JonathanNeal> | Yea, it must be a Firefox bug.] |
| 20:05 | <hsivonen> | Hixie: X-Frame-Options might have some near-spec-worthy docs |
| 20:05 | <AryehGregor> | I suspect I know what's happening. Just a sec. |
| 20:06 | <AryehGregor> | JonathanNeal, you're doing splitText() implicitly here somewhere, probably by calling insertNode(). |
| 20:06 | <AryehGregor> | DOM 2 Range mandates the behavior you're seeing. |
| 20:06 | <Hixie> | hsivonen: cool |
| 20:07 | <AryehGregor> | The definition I gave for range mutation follows WebKit, which is smarter about it. |
| 20:07 | <JonathanNeal> | :D Well thanks for using the smart one. |
| 20:07 | <JonathanNeal> | Is there a way to patch Firefox back into happiness and unsplit? |
| 20:10 | <JonathanNeal> | AryehGregor: is there a way I can clone the range to a cloned element? |
| 20:10 | <AryehGregor> | JonathanNeal, what do you mean, clone the range to a cloned element? |
| 20:10 | <AryehGregor> | Here's a more minimal test-case of the effect you're seeing, BTW: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%20%0A%3Cp%3EAbc%3C%2Fp%3E%0A%3Cscript%3E%0AgetSelection().collapse(document.querySelector(%22p%22).firstChild%2C%201)%3B%0AgetSelection().extend(document.querySelector(%22p%22).firstChild%2C%203)%3B%0Adocument.querySelector(%22p%22).firstChild.splitText(2)%3B%0A%3C%2Fscript%3E |
| 20:11 | <JonathanNeal> | `<p>The <em>quick brown f|ox</em> jumps over the lazy <strong>d|og</strong>.</p>` and I clone the common ancestor, and then re-create the range on that clone. |
| 20:12 | <AryehGregor> | No, no simple way to do that. |
| 20:12 | <AryehGregor> | The clone has no relationship to the original nodes. |
| 20:12 | <JonathanNeal> | Yea. |
| 20:12 | <AryehGregor> | You'd have to do it manually, by figuring out the correct start and end points and setting the range to those. |
| 20:12 | <jgraham> | Hixie: Does it sound at all plausible to kill the getters on new HTML*Collections? |
| 20:13 | <Hixie> | i assume you mean the callers |
| 20:13 | <JonathanNeal> | In the content-editable example you saw earlier, I map the way to the selection from the common ancestor and then reverse the mapping to recreate the selection. It's way complicated. I'd rather just inject nodes. |
| 20:13 | <Hixie> | not the fetters |
| 20:13 | <Hixie> | getters |
| 20:13 | <jgraham> | Yeah, callers |
| 20:13 | <jgraham> | Sorry |
| 20:13 | <Hixie> | because killing the getters doesn't sound even remotely plausible :-P |
| 20:13 | <Hixie> | i dunno, don't pages depend on this? IE does it right? |
| 20:13 | <jgraham> | No, that would be stupid and insane :) |
| 20:13 | <jgraham> | IE does it for the ones it implements yeah |
| 20:14 | <jgraham> | I was hoping that at least for the new ones we could do better |
| 20:14 | <Hixie> | well it seems pretty harmless to me, so consistency seems worth it |
| 20:14 | <jgraham> | It would be inconsistent but the best thing would be to never use them anywhere |
| 20:14 | <JonathanNeal> | but injecting nodes makes Firefox hate the selection. |
| 20:14 | <Hixie> | but you know the drill, i'll follow the browsers, basically |
| 20:14 | <Hixie> | so if browsers don't do it, i'll remove it |
| 20:14 | <jgraham> | It's not really harmless, there's a ton of undefined edge cases |
| 20:14 | <Hixie> | oh? |
| 20:15 | <Hixie> | like what? |
| 20:15 | <Hixie> | it's in the spec purely for back compat, it's not an intentional api design, so really the only consideration for me is how it affects implementations |
| 20:15 | <jgraham> | Like if you have callers for multiple types and pass in an object that can be coerced to more than one type |
| 20:16 | <jgraham> | e.g. {valueOf:2, toString:"foo"} |
| 20:16 | <jgraham> | It's not clear which order you should try the callers in |
| 20:16 | <Hixie> | doesn't webidl define that? |
| 20:17 | <jgraham> | No, it leaves it explicitly undefined afaict |
| 20:17 | <Hixie> | surely we need to define that for overloading in general |
| 20:17 | <jgraham> | In this case it is totally differnet underlying functions that get called |
| 20:18 | <jgraham> | so it's not like normal overloading where it is one function with multipleargument types |
| 20:18 | <Hixie> | even if it's one function with multiple argument types, the order has to be defines |
| 20:18 | <Hixie> | since |2| and "foo" aren't the same thing |
| 20:18 | <jgraham> | I think it is in that case |
| 20:18 | <Hixie> | oh well why is this different? |
| 20:18 | <jgraham> | But not for the case where it is multiple functions |
| 20:18 | <Hixie> | we should use the same overloading algorithm |
| 20:19 | <jgraham> | It *could* be defined by WebIDL |
| 20:19 | <jgraham> | But in any case it seems sad to keep propogating the bad pattern into new APIs |
| 20:20 | <jgraham> | Where indexing and calling are synonyms |
| 20:20 | <jgraham> | s/indexing/getting properties/ |
| 20:21 | <jgraham> | (it also makes QAs sad because they end up having to test everything three times, once for the function one for the index and once for the call) |
| 20:21 | <JonathanNeal> | AryehGregor: thanks so much for your input and help so far. |
| 20:21 | <jgraham> | (which is not such a great argument) |
| 20:21 | <jgraham> | (but still) |
| 20:21 | <Hixie> | well like i said |
| 20:22 | <Hixie> | back compat is the motivation |
| 20:22 | <AryehGregor> | JonathanNeal, no problem. |
| 20:22 | <jgraham> | OK. I doubt I will get any buy-in for not doing this for old APIs (though Gecko doesn't). But for new ones maybe |
| 20:23 | <Ms2ger> | How about you drop support :) |
| 20:24 | <jgraham> | Ms2ger: That's the buy-in I won't get for old APIs :) |
| 20:24 | <Hixie> | jgraham: do file a bug on webidl or html if there are undefined bits though. we shouldn't have undefined stuff. |
| 20:24 | <Ms2ger> | Pff, I've removed enough stuff without waiting or buy-in |
| 20:25 | <Hixie> | jgraham: this one sounds pretty straightforward though |
| 20:25 | <jgraham> | Ms2ger: Well I could probably change the code, but I wouldn't get it through review :) |
| 20:25 | <Ms2ger> | How about you hire sicking? :) |
| 20:25 | <JonathanNeal> | AryehGregor: does getSelection support a reverse selection? |
| 20:26 | <AryehGregor> | JonathanNeal, what do you mean by reverse? |
| 20:26 | <Hixie> | what WebIDL type is an interface object? |
| 20:26 | <Hixie> | Object? |
| 20:26 | <jgraham> | Ms2ger: Seems like quite the roundabout solution :) |
| 20:26 | <JonathanNeal> | AryehGregor: where the carest finished at the earlier point. |
| 20:26 | <JonathanNeal> | *caret |
| 20:26 | <jgraham> | Either Object or Function I guess |
| 20:26 | <jgraham> | I don't remember which way that went |
| 20:26 | <AryehGregor> | JonathanNeal, in Firefox and WebKit, yes. In IE9, no. |
| 20:27 | <AryehGregor> | Check whether the focusNode/focusOffset matches the start or end of the first range. |
| 20:27 | <JonathanNeal> | `ipsu|2|m dolar si|1|t` where |1| was the starting point and |2| was the ending point. |
| 20:28 | <JonathanNeal> | Ah, that's good to know that I can check. I tried just saving and restoring a selection, and noticed that it forgot which way it was going. |
| 20:31 | <JonathanNeal> | Oi, I hope it's not a lot of code just to check which way my selection is going. |
| 20:39 | <JonathanNeal> | I guess it is as easy as `ltr = selection.anchorNode == selectionRange.startContainer && selection.anchorOffset == selectionRange.startOffset;` |
| 20:54 | <kling> | Ms2ger: ping, did you take over the canvas test suite? |
| 20:54 | <Ms2ger> | Still Philip` |
| 20:54 | <kling> | righto :) |
| 20:55 | <Ms2ger> | Anything in particular? |
| 20:56 | <kling> | Ms2ger: was wondering about createPattern tests wrt TYPE_MISMATCH_ERR, IIUC there's a conflict between WebIDL and HTML5, in that no overload should match, leading to TypeError |
| 20:57 | <kling> | Ms2ger: when passing a string or null as the first argument to createPattern() |
| 20:57 | <Ms2ger> | Which test? |
| 20:58 | <kling> | Ms2ger: 2d.pattern.image.null.html |
| 21:00 | <kling> | Ms2ger: nevermind the string part, i see philip already fixed that in 56:465ada6e6262, so just null :) |
| 21:01 | <Ms2ger> | Actually, WebIDL just changed, and we do want a TypeError there |
| 21:01 | <Ms2ger> | Care to file a bug? |
| 21:01 | <kling> | Ms2ger: sure. for html5, you mean? |
| 21:02 | <Ms2ger> | On the test suite |
| 21:02 | <kling> | Ms2ger: TYPE_MISMATCH_ERR is explicitly specified in html5, though. that's the confusing part |
| 21:02 | <Hixie> | i can change the html spec if it's wrong |
| 21:03 | <Ms2ger> | Hixie, that's the bug you called the definition of not urgent :) |
| 21:03 | <kling> | :D |
| 21:03 | <Hixie> | yeah i was about to say, looks like the only problem is that you want null to throw TypeError instead of TYPE_MISMATCH_ERR |
| 21:03 | <Hixie> | right now the spec that's wrong is webidl :-P |
| 21:03 | <Hixie> | because it changed the meaning of all the idl in the html spec :-P |
| 21:04 | <Hixie> | you should assume every single object type in idls in HTML has a "?" after it until webidl is fixed |
| 21:04 | <Ms2ger> | That's what you get for normatively referencing unstable drafts :) |
| 21:05 | <Hixie> | ain't no such thing as a "stable" draft |
| 21:05 | <Hixie> | q.v. SVG referencing CSS2 REC |
| 21:05 | <kling> | where is the webidl version control? :$ |
| 21:05 | <Ms2ger> | dev.w3.org |
| 21:06 | <kling> | righto. i'll file a bug for the test suite, then. thank you gentlemen |
| 21:09 | <Hixie> | does IE support ArrayBuffer? |
| 21:10 | <Hixie> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1007 - Chrome/Mac gives me 0:0:192:255, Firefox/Mac gives me 0:0:192:127 |
| 21:10 | <hsivonen> | Hixie: btw, if ArrayBuffers are de facto becoming little-endian, wy annoy people by making Web Socket ArrayBuffers big endian? |
| 21:10 | <Hixie> | can anyone find any other results? |
| 21:11 | <Hixie> | hsivonen: websocket data comes from the network, which is big endian |
| 21:11 | <Hixie> | hsivonen: also, arraybuffers aren't defacto little endian, they're whatever the platform gpu uses |
| 21:11 | <hsivonen> | Hixie: not if the other end sends little-endian |
| 21:11 | <Hixie> | hsivonen: so big endian on arm, little endian on intel |
| 21:11 | <Hixie> | as i understand it |
| 21:11 | <hsivonen> | Hixie: I thought ARM was little-endian as well |
| 21:12 | <Hixie> | it's configurable |
| 21:12 | <Hixie> | but as i understand it it is usually big-endian |
| 21:12 | <Hixie> | i could be wrong |
| 21:12 | <AryehGregor> | ARM is usually little-endian, AFAIK. |
| 21:12 | <Hixie> | in any case, the webgl api only works if it matches the gpu |
| 21:12 | <AryehGregor> | I remember looking it up once and finding out that the iPhone is little-endian. |
| 21:12 | <AryehGregor> | Also, a while back someone here said that ARM is de facto little-endian these days. |
| 21:13 | <Hixie> | (the test above has nothing to do with endianness, btw) |
| 21:14 | <hsivonen> | Hixie: I believe Maemo on ARM is little-endian |
| 21:14 | <hsivonen> | Hixie: I'd be very surprised if Android was big-endian |
| 21:14 | <zewt> | ... websocket data is big-endian? why? heh |
| 21:14 | <Hixie> | i would assume android is endianness-neutral |
| 21:14 | <zewt> | tcp headers, yeah, but payloads? |
| 21:15 | <zewt> | (sorry, not familiar with the websocket protocol) |
| 21:15 | <Hixie> | zewt: everything over the network is big-endian by convention. in practice it's up to the author, obviously |
| 21:15 | <zewt> | low-level network stack headers are big-endian by convention; i've never seen any such convention for anything higher up the stack |
| 21:16 | <AryehGregor> | Hixie, is that still the case if we restrict ourselves to things visible to web authors? |
| 21:16 | <AryehGregor> | As opposed to implementers? |
| 21:16 | <zewt> | granted, most higher-level, standard protocols aren't binary protocols, so the sample set is smaller |
| 21:16 | <Hixie> | AryehGregor: not sure what you mean |
| 21:17 | <AryehGregor> | Hixie, I mean, for our purposes it doesn't matter if TCP headers are big- or little-endian, say. Because we're talking about something visible to web authors, and web authors don't get direct access to TCP headers, so those don't affect their expectations. |
| 21:17 | <Hixie> | oh this is all moot anyway, it seems. The typed array spec lets the author pick the endianess when using DataView. |
| 21:17 | <zewt> | i think people have android running on MIPS, so i imagine android the platform can go either way |
| 21:17 | <Hixie> | AryehGregor: i don't think i've mentioned tcp headers |
| 21:18 | <AryehGregor> | What do you mean by "everything over the network"? |
| 21:18 | Philip` | wonders how many CPU cycles the world has wasted by having every x86 CPU do loads of ntohl calls for every network packet |
| 21:19 | <zewt> | heh i was just thinking the same thing (and concluded: probably not much, at least in recent times) |
| 21:20 | <Hixie> | AryehGregor: it seems pretty self-explanatory? |
| 21:20 | <AryehGregor> | Not really? |
| 21:21 | <Hixie> | which part is confusing? everything, or network? |
| 21:22 | <AryehGregor> | I mean, people can send whatever they want over the network. If I send a file over HTTP whose format specifies that it's little-endian, it doesn't get transformed to big-endian and then back when I send it. |
| 21:22 | <Hixie> | sure |
| 21:22 | <AryehGregor> | So I guess I want to know what "everything" is supposed to mean, yeah. |
| 21:22 | <AryehGregor> | Since it apparently doesn't actually mean "everything". |
| 21:22 | <hsivonen> | Hixie: you could avoid endianness altogether in the API by giving people ArrayBuffers of bytes |
| 21:22 | <Hixie> | i mean that the convention is that binary network protocols use big-endianness regardless of the endianness of the platforms involved. |
| 21:22 | <hsivonen> | and making it the app programmer's problem to convert the bytes to wider types |
| 21:22 | <Hixie> | hsivonen: that's not how ArrayBuffer works |
| 21:23 | <hsivonen> | Hixie: how do they work? why would a buffer of bytes have endianness? |
| 21:23 | <Hixie> | hsivonen: ArrayBuffer is opaque |
| 21:23 | <Hixie> | hsivonen: you then create readers of different widths from the ArrayBuffer |
| 21:24 | <AryehGregor> | Hixie, okay, but web authors aren't exposed to that convention, right? So shouldn't we be going for whatever will make the most sense for authors, even if that violates some convention? |
| 21:24 | <AryehGregor> | And if there are some things that we already expose to authors that are the same endianness as the CPU, that means de facto little-endian, so we should stick to little-endian. |
| 21:25 | <jgraham> | Before gsnedders points it out I will point out that ARM is almost always LE but can theoretially be either and MIPS os almost always BE but can theoretically be either |
| 21:25 | <AryehGregor> | Or is this endianness not directly exposed to authors? |
| 21:25 | AryehGregor | isn't quite sure what's being discussed . . . |
| 21:26 | <Hixie> | AryehGregor: right now, the typed array spec, when used to read a wide integer from an ArrayBuffer, uses the platform convention for endianness. This obviously is a non-starter on a platform-neutral metaplatform like the web, since it would mean that if you happened to be on a system that didn't match the author's test system, your data would be corrupted. |
| 21:27 | <AryehGregor> | Right. |
| 21:28 | <jgraham> | Hixie: I personally expect that problem to be solved by everyone converging on LE hardware |
| 21:28 | <Philip`> | Looks like internet traffic is roughly 30EB/month, and if each of those is a 1500 byte packet and it takes (wild guess) a hundred x86 CPU cycles to do all the byte flipping on send/receive for all the layers of protocols, that's like 400 CPU-months per month |
| 21:28 | <Philip`> | which I suppose isn't that bad |
| 21:28 | <zewt> | i'd say it's closer to zero CPU cycles--when you take into account modern CPU pipelining and so on |
| 21:29 | <Hixie> | lunch, bbl |
| 21:30 | <jgraham> | (and people that don't use LE hardware will have to be careful to fake it to look like they are which will be slow so there will be a good incentive for convergence) |
| 21:31 | <zewt> | personally I'm happy if big-endian people get to waste lots of time, because right now we're all wasting our time bending over backwards making things work for them, the needlessly incompatible rare variant |
| 21:31 | <zewt> | if they won't get along with the rest of the civilized world, let them figure out how to deal with it. heh |
| 21:32 | <gsnedders> | jgraham: MIPS is mostly LE nowadays, apart from products from one major vendor, AFAIK |
| 21:34 | Philip` | wonders what happened to Blefuscu in the end, and whether it provides useful insight into resolving these problems |
| 21:35 | <gsnedders> | Itanium is almost all LE, PPC (and hence also POWER nowadays) is almost all BE |
| 21:36 | <gsnedders> | SuperH I have no idea about in actual usage — it is almost bi-endian |
| 22:42 | <abarth> | Hixie: quick question: are you sure HTMLImageElement::crossOrigin should have a capitalized "O" ? |
| 22:43 | <abarth> | http://www.whatwg.org/specs/web-apps/current-work/#the-img-element |
| 22:43 | <TabAtkins> | I suspect that's a legacy of when it was called cross-origin. |
| 22:43 | <abarth> | its consistent iwth useMap and isMap |
| 22:43 | <abarth> | but seems slightly odd |
| 22:43 | <abarth> | https://bugs.webkit.org/show_bug.cgi?id=61015 |
| 22:43 | <abarth> | now's the time to fix it if he wants it changed :) |
| 22:48 | zcorpan | notes it's also consistent with formNoValidate |
| 22:49 | <abarth> | ok |
| 22:49 | <abarth> | then it's probably right |
| 22:49 | <abarth> | sorry for the noise |
| 23:35 | <jamesr> | heycam: yo |
| 23:35 | <jamesr> | heycam: what's ISSUE-6? |
| 23:42 | <Hixie> | abarth: it's intentional |
| 23:45 | <heycam> | jamesr, that's asking to define what happens when you call requestAnimationFrame twice with the same callback before the next animation tick |
| 23:46 | <jamesr> | should be just like settimeout |
| 23:46 | <jamesr> | the callback is invoked twice |
| 23:46 | <jamesr> | why's that ambiguous? |
| 23:46 | <jamesr> | well i guess since we haven't defined a processing model, it's unclear from the spec |
| 23:46 | <jamesr> | but seems pretty obvious |
| 23:46 | <heycam> | right, I think Jatinder just wants it to be clear whether it's invoked once or twice |
| 23:47 | <jamesr> | sure |
| 23:47 | <jamesr> | processing model is on my todo list for this week |
| 23:47 | <heycam> | great! |
| 23:47 | <heycam> | we talked in the call today about publication |
| 23:47 | <heycam> | plh and jatinder would like to publish the FPWD on thursday next week. they (and I) don't mind if not all of the issues have been resolved before publication. |
| 23:48 | <heycam> | but it would be good to get as many of them knocked down as possible |
| 23:49 | <jamesr> | i think the microsoft folks care a lot more about publication, etc than i do |
| 23:49 | <heycam> | :) |
| 23:49 | <jamesr> | so if they feel strongly that something should or shouldn't be published then i'm generally not gonna want to fight about it |
| 23:49 | <heycam> | ok |
| 23:50 | <jamesr> | well currently it isn't really a specification of anything |
| 23:50 | <heycam> | I think it's good to get something published so that the spec gets more attention |
| 23:50 | <jamesr> | because it doesn't say how anything works |
| 23:50 | <heycam> | well, sure |
| 23:50 | <jamesr> | but i'm not opposed to publishing at any time |
| 23:50 | <heycam> | right, neither am I |
| 23:50 | <jamesr> | i think ost of the feedback will probably be "hey, you didn't specify anything!" |
| 23:50 | <jamesr> | which we can then fix :) |
| 23:52 | <heycam> | yep. I think it's reasonably common in W3C land for first public working drafts not to be terribly complete, anyway. |
| 23:53 | <heycam> | so I'll take a look early next week after you've worked on the processing model and see if I can resolve any of the other open issues |