/irc-logs / freenode / #whatwg / 2011-05-25 / end

Options:

# Session Start: Wed May 25 00:00:00 2011
# Session Ident: #whatwg
# [00:03] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [00:05] * Quits: nessy (~Adium@58-6-47-56.dyn.iinet.net.au) (Quit: Leaving.)
# [00:07] * Joins: miketaylr (~miketaylr@12.22.138.2)
# [00:18] * Quits: boaz (~boaz@75-150-66-249-NewEngland.hfc.comcastbusiness.net) (Quit: boaz)
# [00:25] * Joins: Akilo (~kristof@89-159-215-142.rev.numericable.fr)
# [00:25] * Quits: Akilo (~kristof@89-159-215-142.rev.numericable.fr) (Client Quit)
# [00:30] * Quits: ifette (~ifette@nat/google/x-ynvinkpwoqsywtxg) (Quit: ifette)
# [00:32] * Joins: Yuhong (~chatzilla@50-47-173-54.evrt.wa.frontiernet.net)
# [00:33] * ako is now known as aho
# [00:39] * Quits: benschwarz (~benschwar@59.167.185.148) (Quit: Linkinus - http://linkinus.com)
# [00:46] * Quits: Jon47 (~jon47@204.56.125.50) (Quit: Leaving.)
# [00:46] * Quits: RichardJ (~richard@node.liefcoden.nl) (Remote host closed the connection)
# [00:48] * Quits: miketaylr (~miketaylr@12.22.138.2) (Quit: miketaylr)
# [00:50] * Joins: RichardJ (~richard@node.liefcoden.nl)
# [00:53] * Joins: riven` (~riven@53518387.cm-6-2c.dynamic.ziggo.nl)
# [00:54] * Joins: ifette (~ifette@nat/google/x-pdnyegllemhjzxig)
# [00:54] * bga_ is now known as bga_|away
# [00:55] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
# [00:55] * Quits: ifette (~ifette@nat/google/x-pdnyegllemhjzxig) (Client Quit)
# [00:55] * Joins: ifette (~ifette@nat/google/x-foaxnxbhidpxpkth)
# [00:57] * Quits: riven (~riven@pdpc/supporter/professional/riven) (Ping timeout: 246 seconds)
# [00:57] * Quits: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
# [00:57] * Joins: Rik`_ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
# [00:57] * Quits: jdaggett (~jdaggett@y227145.dynamic.ppp.asahi-net.or.jp) (Quit: jdaggett)
# [01:00] * Joins: erlehmann (~erlehmann@89.204.137.125)
# [01:03] * Quits: ifette (~ifette@nat/google/x-foaxnxbhidpxpkth) (Quit: ifette)
# [01:05] * Joins: othermaciej_ (~mjs@17.246.18.135)
# [01:05] * Joins: ifette (~ifette@nat/google/x-ebvuctfbkphvleqj)
# [01:07] * Quits: othermaciej (~mjs@17.203.15.180) (Ping timeout: 255 seconds)
# [01:07] * othermaciej_ is now known as othermaciej
# [01:09] * Hixie casts around for abarth
# [01:11] * Quits: dave_levin (~dave_levi@nat/google/x-opozjnfbuwbzsbtg) (Quit: dave_levin)
# [01:14] * bga_|away is now known as bga_
# [01:16] * Quits: FireFly (~firefly@unaffiliated/firefly) (Quit: swatted to death)
# [01:16] * riven` is now known as riven
# [01:16] * Quits: riven (~riven@53518387.cm-6-2c.dynamic.ziggo.nl) (Changing host)
# [01:16] * Joins: riven (~riven@pdpc/supporter/professional/riven)
# [01:21] * Quits: stefan-_ (~music@swhpet3041.uni-trier.de) (Remote host closed the connection)
# [01:21] * Joins: nessy (~Adium@74.125.56.18)
# [01:24] * Joins: seventh (seventh@31.6.22.252)
# [01:25] * Quits: Amorphous (jan@unaffiliated/amorphous) (Ping timeout: 258 seconds)
# [01:28] * Philip` finds that it's pretty trivial to circumvent cross-origin font canvas tainting via timing attacks
# [01:29] * Quits: chriseppstein (~chris@dsl092-049-179.sfo4.dsl.speakeasy.net) (Quit: chriseppstein)
# [01:32] * Joins: chriseppstein (~chris@209.119.65.162)
# [01:33] <Hixie> Philip`: for the "find which characters are in the font" attack?
# [01:37] <Philip`> Finding the shapes of the glyphs
# [01:38] <Hixie> in that case you should be able to get data from any cross-origin image too, no?
# [01:40] * Joins: Amorphous (jan@unaffiliated/amorphous)
# [01:41] <Philip`> When filling text, if the glyph is outside the clipping area then it doesn't even attempt drawing any pixels
# [01:41] <Philip`> which affects the timing significantly
# [01:41] <TabAtkins> Oh, interesting.
# [01:41] <TabAtkins> So, apply 1px clipping area, and profit.
# [01:42] <Philip`> With images it'll draw every pixel regardless of the value, so any differences would be far more subtle
# [01:42] <Hixie> is there an expensive composite mode or shadow or something that can make it different enough?
# [01:43] <TabAtkins> Given the current canvas operations, I doubt it.
# [01:43] <TabAtkins> None of the mechanics should operate significantly differently based on the color of the canvas.
# [01:47] <Philip`> http://philip.html5.org/demos/canvas/font-timing.html - very rough prototype
# [01:47] <Philip`> In Chromium 9.0 I get a very clear "A" shape after the first iteration
# [01:48] <Philip`> (on Linux)
# [01:48] <Philip`> Opera 11.10 gives a sort of triangle shape that improves over time
# [01:49] <roc> doesn't seem to work on Firefox
# [01:49] <Hixie> i don't really understand what we're protecting against here, personally
# [01:49] <Hixie> wfm on firefox on mac
# [01:49] * Quits: MrOpposite (~mropposit@unaffiliated/mropposite) (Remote host closed the connection)
# [01:49] <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
# [01:51] <roc> on windows I mean
# [01:51] <roc> it depends on the font backend I guess
# [01:51] * Philip` means on Linux and hasn't tested elsewhere
# [01:51] <Hixie> chrome and firefox on mac seem to very quickly give an A
# [01:52] <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
# [01:52] <roc> on Windows we don't do that ourselves, who knows what GDI and D2D do
# [01:53] <roc> anyway, neat demo!
# [01:53] <Hixie> indeed
# [01:53] <TabAtkins> <3 timing channel attacks
# [01:53] <roc> you can't
# [01:54] <Philip`> TabAtkins: I'm sure there's more than 3
# [01:54] <Hixie> aw man, now you've surely gotten him going through the unicode pages
# [01:55] <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
# [01:55] <jamesr> roc: the font size is 10px, there's just a large scale applied
# [01:55] <Hixie> TabAtkins: U+2665, U+2764, or the U+1F491-U+1F49F range
# [01:55] <jamesr> Philip`: try with a large font size
# [01:55] <jamesr> i dunno if we consider the scale when deciding whether to use GDI to raster or grab a path and fill the path
# [01:55] <roc> jamesr: I mean the post-resize scale factor
# [01:56] <jamesr> we probably _should_ be using the post-resize scale factor
# [01:56] <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
# [01:56] <Philip`> and in Firefox it seems to clamp the post-scale font size
# [01:56] <Philip`> (in 4.0, on Linux)
# [01:57] <Philip`> (That "12K" isn't a precise figure, I just think it broke after about 12px with scale 1024)
# [01:58] <jamesr> Philip`: try applying a very slight skew
# [01:58] * Quits: lhnz (~lhnz@188-223-83-48.zone14.bethere.co.uk) (Ping timeout: 250 seconds)
# [01:59] * Joins: lhnz (~lhnz@188-223-83-48.zone14.bethere.co.uk)
# [01:59] <jamesr> might force you down the path case in more cases
# [02:16] * Joins: wolfman2000 (~wolfman20@rrcs-70-63-208-211.midsouth.biz.rr.com)
# [02:17] * Quits: ifette (~ifette@nat/google/x-ebvuctfbkphvleqj) (Quit: ifette)
# [02:19] <Philip`> http://philip.html5.org/demos/canvas/img-timing-1.html - works for me in Chromium
# [02:19] <Philip`> http://philip.html5.org/demos/canvas/img-timing-2.html - works for me in Opera
# [02:20] <Philip`> (Warning: artwork may be disturbing)
# [02:22] <jamesr> i'm just getting noise
# [02:22] <roc> interesting
# [02:22] <jamesr_> hm, works better on linux
# [02:22] <jamesr_> so it's testing blend time?
# [02:23] <Philip`> ((This is just drawImageing one pixel of an image at a time, and transparent vs solid makes a difference))
# [02:23] <roc> their compositing code has special cases for zero alpha?
# [02:23] <roc> I'm surprised that wins
# [02:23] <jamesr_> i wonder what layer is doing that
# [02:24] <jamesr_> we have some special case code for 1x1 transparent images in various bits of the codebase (mostly for spacer.gif)
# [02:24] <Philip`> My Chromium is faster for alpha=255 than for alpha=0
# [02:24] <Philip`> (in default source-over compositing)
# [02:24] <jamesr_> but is alpha=254 different from alpha=255?
# [02:24] <jamesr_> and what platform are you on? chrome/mac=coregraphics, chrome/win or linux=skia
# [02:25] <roc> Firefox/Linux would be XRender, that would be interesting to test
# [02:25] <erlehmann> i have firefox on linux, what should i test?
# [02:25] <jamesr_> getting noise in Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0a1) Gecko/20110523 Firefox/6.0a1
# [02:25] <erlehmann> Philip`, am i right with the interpretation that you attempt to read cross origin resources via timing attacks?
# [02:25] <Philip`> Chromium seems to be slow for alpha=0, alpha=1ish, alpha=254ish, fast for alpha=255
# [02:25] <jamesr_> the values are pretty low - 1/2
# [02:26] <jamesr_> Philip`, yeah then it's probably a check for full transparent that skips blending
# [02:26] <Philip`> (I'm using Chromium 9.0 on Linux)
# [02:26] <jamesr_> 9.0? wtf
# [02:26] <jamesr_> what museum did you steal chromium 9.0 from?
# [02:27] <AryehGregor> It's probably the default version on Debian or something.
# [02:27] <AryehGregor> They like years-old software.
# [02:27] <Philip`> I installed chromium-bin on Gentoo some time ago, and they stopped updating it
# [02:27] <jamesr_> debian is 6.0
# [02:27] <AryehGregor> Nice.
# [02:27] <Philip`> and I haven't cared enough to find a new version
# [02:28] <roc> I'll p0wn your system and update you to something reasonable
# [02:28] <erlehmann> I use Chromium 6.0
# [02:28] <erlehmann> In before owned.
# [02:28] <AryehGregor> Of course, I could easily get some ancient version of Chrome too, on Linux, if the package repository got uninstalled or something.
# [02:28] * Quits: ZombieLoffe (~e@unaffiliated/zombieloffe)
# [02:28] <AryehGregor> Not just Chromium.
# [02:28] <Philip`> Opera with 'lighter' compositing seems to be fast for alpha=0, slow for everything else
# [02:29] <jamesr_> hah
# [02:30] * Philip` hasn't tried other modes
# [02:30] <jamesr_> http://code.google.com/p/skia/source/browse/trunk/src/core/SkDraw.cpp#1113
# [02:30] <Philip`> erlehmann: Yes, it's trying to extract image data without using getImageData/toDataURL (thus avoiding the cross-origin-information-leakage checks)
# [02:30] <jamesr_> i think that's the early out in question here
# [02:31] <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)
# [02:31] <jamesr_> only useful for fully transparent vs not, though, which is way less useful than the webgl case
# [02:31] <jamesr_> where you can get arbitrary bits from arbitrary color channels
# [02:31] <erlehmann> Philip`, *very* rough. but i see it. hopefully we can all use your timing attacks instead of JSONP now ;P
# [02:32] <jamesr_> hm, if you could somehow apply a color mask before doing this attack then you could get more info out
# [02:33] <jamesr_> roc is probably chuckling evilly about http://weblogs.mozillazine.org/roc/archives/2011/02/distinguishing.html :)
# [02:33] <roc> well
# [02:33] <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
# [02:34] <Philip`> (I'm assuming drawImage of canvas is the same as drawImage of img, which is false, but anyway)
# [02:35] <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...
# [02:35] <roc> so I feel more like a deep sigh
# [02:36] * Quits: chriseppstein (~chris@209.119.65.162) (Quit: chriseppstein)
# [02:36] <roc> jamesr: is that really your early-exit path here?
# [02:37] <roc> I sort of doubt t
# [02:37] <Philip`> Do any browsers have high-resolution timers yet?
# [02:37] <Philip`> (That'd probably make this much easier than with Date.now())
# [02:38] <jamesr_> roc, i dunno, i'm just completely guessing
# [02:39] * Quits: hij1nx (~hij1nx@207.239.107.3) (Quit: hij1nx)
# [02:41] <roc> async rendering, like pretty much any GPU-accelerated canvas, should make these timing attacks much more difficult
# [02:41] <roc> so it'd be interesting to try on FF4/Windows, or IE9, or Chrome with acceleration enabled
# [02:41] <jamesr_> the webgl demos work fine with readback
# [02:42] <jamesr_> or glFinish()
# [02:42] <jamesr_> async is no help
# [02:42] <jamesr_> you can force readback with canvas by doing getImageData
# [02:42] <Philip`> You can't do getImageData if you've drawn cross-origin images
# [02:42] <jamesr_> true, it's tainted
# [02:42] * Joins: agektmr (~Adium@220.109.219.244)
# [02:42] <jamesr_> but you can just repeat the draw a bunch of times and observe throughput
# [02:42] <Philip`> Would doing a drawImage of one canvas onto another cause a readback?
# [02:42] <jamesr_> might add noise but it doesn't stop the fundamental issue
# [02:42] * Quits: ap (~ap@17.203.14.199) (Quit: ap)
# [02:43] <jamesr_> Philip`, it shouldn't
# [02:43] <jamesr_> in our gpu impl it doesn't, modulo some weird bugs
# [02:43] <Philip`> Is there anything you can do to a canvas to make it impossible to hardware-accelerate so it falls back to software?
# [02:43] <jamesr_> like we have a lower size limit for gpu-backed canvas than for software-backed canvas
# [02:43] <jamesr_> yeah
# [02:43] <jamesr_> make it big but not too big
# [02:43] <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
# [02:44] <jamesr_> i'm pretty sure you can get arbitrary color channels out through svg images somehow
# [02:44] * Philip` will add "var c = []; for (var i = 0; i < 20000; ++i) c.push(document.createElement('canvas').getContext('2d'))" to his script, then :-)
# [02:45] <jamesr_> Philip`, in chromium today that is more likely to just crash or something
# [02:45] <jamesr_> we haven't implemented ctx limiting like that
# [02:45] <Philip`> Hmm, so use SVG in <img> which applies filters to an external image, then drawImage that into the canvas?
# [02:46] * Philip` guesses that shouldn't be too hard
# [02:46] * Joins: tantek (~tantek@2620:101:8003:200:5a55:caff:fef3:c447)
# [02:46] <jamesr_> assuming that svg allows you to map color channels to transparency somehow
# [02:46] <jamesr_> which i'm sure it must, given that svg specifies everything under the sun
# [02:47] <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"> )
# [02:47] * Joins: cgcardona (~cgcardona@unaffiliated/cgcardona)
# [02:47] <tantek> use cases: all the sites out there that have login forms
# [02:47] <cgcardona> TabAtkins: hello. regarding your tweet last night. Like this? http://pastebin.com/index/3gMc8EPY
# [02:47] <jamesr_> heycam might know a way to magick this up in svg
# [02:47] <Philip`> http://www.w3.org/TR/SVG/filters.html#feColorMatrixElement looks slightly powerful
# [02:48] <jamesr_> oh good god
# [02:48] <jamesr_> yup, gg
# [02:48] <tantek> and enabling browsers to autodetect such forms for more reliable identity/password/URL remembering and auto-fill
# [02:48] <jamesr_> Philip`, now i dunno if anyone implements that correctly such that it works (svg <img> in WebKit is super super buggy in general)
# [02:48] <jamesr_> but it seems possible
# [02:48] * Joins: nattokirai (~nattokira@rtr.mozilla.or.jp)
# [02:48] <heycam> yeah, feColorMatrix probably can do what you want there
# [02:48] <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.
# [02:49] <Philip`> I suppose there's the possibility of timing attacks on SVG rendering directly, too
# [02:50] <roc> in Gecko we disallow external resource loading in SVG <img> for exactly this reason
# [02:50] <roc> well, for other reasons too
# [02:50] <smaug____> tantek: just curious, what is an identity-url (and shouldn't it be uri?)? and where does user get it?
# [02:50] <roc> but this is one of them
# [02:51] <Philip`> Presumably that wouldn't help if you can time non-canvas non-img SVG rendering sufficiently, though
# [02:51] <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
# [02:52] * Joins: ben_h (~ben@128.250.195.138)
# [02:52] <roc> Philip`: well, yeah
# [02:52] <Philip`> ...and if any part of SVG rendering is sufficiently sensitive to pixel values
# [02:52] * Philip` doesn't really care enough about SVG to see if that's feasible in practice, though
# [02:52] <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.
# [02:52] * smaug____ has never heard of RelMeAuth :)
# [02:52] <tantek> )
# [02:52] <tantek> LMGTFY
# [02:53] <smaug____> but apparently someone called tantek has written about it :)
# [02:53] <tantek> http://microformats.org/wiki/RelMeAuth
# [02:53] <Hixie> what's the downside of making canvas drawing always async, anyway? seems like it'd be a perf win in general.
# [02:53] * Joins: ryanseddon (~RSeddon@202.126.98.210)
# [02:54] <Hixie> (i mean, other than implementation complexity, obviously)
# [02:55] * Joins: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
# [02:58] <roc> in some cases, overhead
# [03:00] <roc> james suggests that it doesn't really help because you can observe throughput
# [03:00] <roc> which I sort of buy, although it increases the cost of the attack considerably
# [03:02] * Quits: agektmr (~Adium@220.109.219.244) (Quit: Leaving.)
# [03:05] * Joins: agektmr (~Adium@220.109.219.244)
# [03:06] * Quits: lhnz (~lhnz@188-223-83-48.zone14.bethere.co.uk) (Ping timeout: 248 seconds)
# [03:08] * Joins: lhnz (~lhnz@188-223-83-48.zone14.bethere.co.uk)
# [03:08] * Joins: hij1nx (~hij1nx@cpe-66-65-124-111.nyc.res.rr.com)
# [03:12] * Joins: cying (~cying@c-24-6-96-149.hsd1.ca.comcast.net)
# [03:15] * Quits: smaug____ (~chatzilla@78.41.210.66) (Ping timeout: 260 seconds)
# [03:24] <jamesr_> Hixie, roc: yeah. it is async in our accelerated canvas 2d implementation
# [03:24] <jamesr_> might cut down on the bandwidth of the attack
# [03:25] <jamesr_> any gpu-backed canvas drawing implementation will be async to one degree or another
# [03:25] <Hixie> observe throughput?
# [03:25] <jamesr_> do a bunch of draws instead of just one, see how long it takes
# [03:25] <jamesr_> no matter how much buffering the system does at some point it'll have to actually evaluate the draws
# [03:25] <Hixie> how can you tell?
# [03:25] <Hixie> if it's async, you can't read it back, right?
# [03:26] <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
# [03:26] <jamesr_> or let it go to screen (which will force it to evaluate) and observe the screen repaint time
# [03:26] <jamesr_> which you can get indirectly in a number of ways
# [03:27] <Hixie> huh. will have to think about that. bbiab
# [03:27] <jamesr_> you can't defer the draw forever
# [03:27] <jamesr_> later
# [03:30] * Joins: F1LT3R (~F1LT3R@c-76-19-149-201.hsd1.ma.comcast.net)
# [03:32] * Quits: F1LT3R (~F1LT3R@c-76-19-149-201.hsd1.ma.comcast.net) (Client Quit)
# [03:37] * Joins: MikeSmith_ (~MikeSmith@EM114-48-149-86.pool.e-mobile.ne.jp)
# [03:39] * Quits: ezoe (~ezoe@203-140-88-240f1.kyt1.eonet.ne.jp) (Ping timeout: 252 seconds)
# [03:41] * Quits: MikeSmith (~MikeSmith@EM1-113-116-19.pool.e-mobile.ne.jp) (Ping timeout: 264 seconds)
# [03:41] * MikeSmith_ is now known as MikeSmith
# [03:50] * Quits: jacobolus (~jacobolus@208-90-212-203.PUBLIC.monkeybrains.net) (Remote host closed the connection)
# [03:55] * Quits: tantek (~tantek@2620:101:8003:200:5a55:caff:fef3:c447) (Quit: tantek)
# [03:59] * Quits: dbaron (~dbaron@nat/mozilla/x-yutfsjukcjlgeobf) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [04:06] * Quits: agektmr (~Adium@220.109.219.244) (Quit: Leaving.)
# [04:06] * Joins: ezoe (~ezoe@112-68-244-241f1.kyt1.eonet.ne.jp)
# [04:06] * Quits: jwalden (~waldo@2620:101:8003:200:222:68ff:fe15:af5c) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.2.17/20110428205629])
# [04:07] * Quits: The_8472 (~stardive@azureus/The8472) (Ping timeout: 255 seconds)
# [04:08] * Joins: agektmr (~Adium@220.109.219.244)
# [04:09] * Joins: miketaylr (~miketaylr@user-160vrg5.cable.mindspring.com)
# [04:11] * Joins: jacobolus (~jacobolus@199.83.221.18)
# [04:13] * Joins: The_8472 (~stardive@azureus/The8472)
# [04:18] * Quits: nessy (~Adium@74.125.56.18) (Quit: Leaving.)
# [04:19] * Quits: jamesr (~jamesr@nat/google/x-jfdqoqocxtkoolkw) (Quit: jamesr)
# [04:20] * Quits: tomasf (~tom@c-5ed9e555.024-204-6c6b7012.cust.bredbandsbolaget.se) (Quit: tomasf)
# [04:22] * Quits: ben_h (~ben@128.250.195.138) (Quit: ben_h)
# [04:24] * Quits: othermaciej (~mjs@17.246.18.135) (Quit: othermaciej)
# [04:32] * Joins: othermaciej (~mjs@67.218.104.237)
# [04:35] * Joins: Transformer (~Transform@ool-4a59e397.dyn.optonline.net)
# [04:37] * Quits: Transformer (~Transform@ool-4a59e397.dyn.optonline.net) (Excess Flood)
# [04:38] * Quits: weinig (~weinig@2620:149:4:401:223:32ff:feaf:7f36) (Quit: weinig)
# [04:42] * Quits: sicking (~chatzilla@2620:101:8003:200:226:bbff:fe05:3fe1) (Ping timeout: 255 seconds)
# [04:53] * Joins: nessy (~Adium@74.125.56.18)
# [04:55] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 260 seconds)
# [04:56] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
# [04:59] * Quits: Yuhong (~chatzilla@50-47-173-54.evrt.wa.frontiernet.net) (Quit: ChatZilla 0.9.86.1 [Firefox 4.0.1/20110413222027])
# [05:06] * Quits: tndH (~Rob@cpc11-seac19-2-0-cust116.7-2.cable.virginmedia.com) (Quit: ChatZilla 0.9.86.1-rdmsoft [XULRunner 1.9.0.1/2008072406])
# [05:08] * Joins: weinig (~weinig@c-24-130-56-198.hsd1.ca.comcast.net)
# [05:08] * Quits: weinig (~weinig@c-24-130-56-198.hsd1.ca.comcast.net) (Client Quit)
# [05:19] * Joins: ben_h (~ben@128.250.195.138)
# [05:21] * Quits: jacobolus (~jacobolus@199.83.221.18) (Remote host closed the connection)
# [05:21] * Joins: jacobolus (~jacobolus@199.83.221.18)
# [05:23] * Quits: othermaciej (~mjs@67.218.104.237) (Quit: othermaciej)
# [05:23] * Quits: erlehmann (~erlehmann@89.204.137.125) (Quit: Ex-Chat)
# [05:25] * Quits: ezoe (~ezoe@112-68-244-241f1.kyt1.eonet.ne.jp) (Ping timeout: 248 seconds)
# [05:36] * Joins: othermaciej (~mjs@c-24-6-209-6.hsd1.ca.comcast.net)
# [05:41] * Joins: nonge_ (~nonge@p5082B25B.dip.t-dialin.net)
# [05:45] * Quits: nonge__ (~nonge@p5082BB51.dip.t-dialin.net) (Ping timeout: 244 seconds)
# [05:51] * Quits: miketaylr (~miketaylr@user-160vrg5.cable.mindspring.com) (Quit: miketaylr)
# [06:04] * Quits: temp01 (~temp01@unaffiliated/temp01) (Ping timeout: 260 seconds)
# [06:08] * Joins: temp01 (~temp01@unaffiliated/temp01)
# [06:12] * Quits: hij1nx (~hij1nx@cpe-66-65-124-111.nyc.res.rr.com) (Quit: hij1nx)
# [06:13] * Quits: temp01 (~temp01@unaffiliated/temp01) (Ping timeout: 260 seconds)
# [06:16] * Joins: temp01 (~temp01@unaffiliated/temp01)
# [06:16] * Quits: jacobolus (~jacobolus@199.83.221.18) (Remote host closed the connection)
# [06:19] * Quits: sephr (~Eli@c-98-235-63-240.hsd1.pa.comcast.net) (Ping timeout: 250 seconds)
# [06:31] * Joins: CvP (CvP@180.234.68.114)
# [06:36] * Quits: CvP (CvP@180.234.68.114) (Disconnected by services)
# [06:36] * Joins: xCG (CvP@180.234.88.218)
# [06:37] * Quits: aho (~nya@fuld-590c6783.pool.mediaWays.net) (Quit: EXEC_over.METHOD_SUBLIMATION)
# [06:37] * xCG is now known as CvP
# [06:58] * Quits: nonge_ (~nonge@p5082B25B.dip.t-dialin.net) (Ping timeout: 255 seconds)
# [06:59] * Joins: davidwalsh (~davidwals@65.91.54.2)
# [06:59] * Quits: davidwalsh (~davidwals@65.91.54.2) (Client Quit)
# [07:00] * Quits: temp01 (~temp01@unaffiliated/temp01) (Quit: Poof.)
# [07:04] * Joins: temp01 (~temp01@unaffiliated/temp01)
# [07:06] * Quits: temp01 (~temp01@unaffiliated/temp01) (Quit: Poof.)
# [07:09] * Joins: temp01 (~temp01@unaffiliated/temp01)
# [07:10] <hsivonen> So it seems that ICU4J has a bug when it comes to determining if a year has 53 ISO weeks
# [07:10] * Joins: nonge_ (~nonge@p5B326EE7.dip.t-dialin.net)
# [07:11] <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:11] * heycam is now known as heycam|away
# [07:11] * Joins: sicking (~chatzilla@c-98-210-155-80.hsd1.ca.comcast.net)
# [07:13] * Quits: temp01 (~temp01@unaffiliated/temp01) (Quit: Poof.)
# [07:13] * Joins: temp01 (~temp01@unaffiliated/temp01)
# [07:28] * Joins: jacobolus (~jacobolus@208-90-212-203.PUBLIC.monkeybrains.net)
# [07:33] * Joins: ezoe (~ezoe@203-140-88-36f1.kyt1.eonet.ne.jp)
# [07:36] * Quits: temp01 (~temp01@unaffiliated/temp01) (Quit: Poof.)
# [07:40] * Joins: temp01 (~temp01@unaffiliated/temp01)
# [07:43] * Joins: maikmerten (~merten@ls5dhcp197.cs.uni-dortmund.de)
# [07:43] * Joins: Ankheg (~Ankheg@fs91-201-3-30.dubna-net.ru)
# [07:45] * bga_ is now known as bga_|away
# [07:47] * Quits: nessy (~Adium@74.125.56.18) (Quit: Leaving.)
# [07:47] * Joins: hdhoang (~hdhoang@hdhoang.broker.freenet6.net)
# [07:51] * Joins: Akilo (~kristof@lit75-1-81-57-239-230.fbx.proxad.net)
# [08:08] * Joins: shinyak (~shinyak@220.109.219.244)
# [08:10] <hsivonen> does the JS Date object implement the proleptic Gregorian calendar all the way back to Year 1 CE?
# [08:24] * Joins: MrOpposite (~mropposit@unaffiliated/mropposite)
# [08:32] * Quits: riven (~riven@pdpc/supporter/professional/riven) (Read error: Connection reset by peer)
# [08:32] * Joins: riven (~riven@pdpc/supporter/professional/riven)
# [08:34] * Quits: hdhoang (~hdhoang@hdhoang.broker.freenet6.net) (Quit: Leaving.)
# [08:36] * dglazkov is now known as dglazkov|away
# [08:38] * Joins: hdhoang (~hdhoang@203.210.155.205)
# [08:42] * Quits: ben_h (~ben@128.250.195.138) (Quit: ben_h)
# [08:43] * Quits: temp01 (~temp01@unaffiliated/temp01) (Quit: Poof.)
# [08:45] * Joins: temp01 (~temp01@unaffiliated/temp01)
# [08:45] * Quits: cgcardona (~cgcardona@unaffiliated/cgcardona) (Quit: zzzzz)
# [08:54] * Joins: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie)
# [08:54] * Joins: rimantas (~rimliu@93.93.57.193)
# [08:55] * Joins: mhausenblas_ (~mhausenbl@wg1-nat.fwgal01.deri.ie)
# [08:58] * Joins: Necrathex (~nectop@dhcp-077-249-098-024.chello.nl)
# [08:59] * Quits: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) (Ping timeout: 246 seconds)
# [08:59] * mhausenblas_ is now known as mhausenblas
# [08:59] * Quits: shinyak (~shinyak@220.109.219.244) (Remote host closed the connection)
# [09:04] * Joins: nessy (~Adium@58-6-47-56.dyn.iinet.net.au)
# [09:05] * Joins: shinyak (~shinyak@2401:fa00:4:1012:129a:ddff:febe:ed11)
# [09:05] * Quits: shinyak (~shinyak@2401:fa00:4:1012:129a:ddff:febe:ed11) (Remote host closed the connection)
# [09:06] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Quit: Leaving...)
# [09:07] * Joins: shinyak (~shinyak@220.109.219.244)
# [09:20] * Joins: virtuelv (~virtuelv_@pat-tdc.opera.com)
# [09:20] * Joins: kor (~kor@ip146-53-210-87.adsl2.static.versatel.nl)
# [09:21] * Joins: erlehmann (~erlehmann@89.204.137.125)
# [09:24] * Joins: matjas (~matjas@91.182.178.25)
# [09:25] * Joins: zcorpan (~zcorpan@c-8798e355.410-6-64736c14.cust.bredbandsbolaget.se)
# [09:25] <zcorpan> so we still haven't published
# [09:26] * Joins: homata_ (~homata_@58x158x182x50.ap58.ftth.ucom.ne.jp)
# [09:30] * Quits: CvP (CvP@180.234.88.218) (Quit: DOTA > your mom.)
# [09:36] * Quits: temp01 (~temp01@unaffiliated/temp01) (Quit: Poof.)
# [09:37] * Joins: MikeSmith_ (~MikeSmith@EM114-48-162-248.pool.e-mobile.ne.jp)
# [09:38] * Joins: msucan (~robod@92.86.247.27)
# [09:38] * Joins: temp01 (~temp01@unaffiliated/temp01)
# [09:40] * Quits: nessy (~Adium@58-6-47-56.dyn.iinet.net.au) (Ping timeout: 246 seconds)
# [09:40] * Quits: MikeSmith (~MikeSmith@EM114-48-149-86.pool.e-mobile.ne.jp) (Ping timeout: 246 seconds)
# [09:40] * MikeSmith_ is now known as MikeSmith
# [09:44] * Quits: cying (~cying@c-24-6-96-149.hsd1.ca.comcast.net) (Quit: cying)
# [09:47] * Joins: nessy (~Adium@124-149-37-204.dyn.iinet.net.au)
# [09:48] * Quits: temp01 (~temp01@unaffiliated/temp01) (Ping timeout: 248 seconds)
# [09:51] * Joins: temp01 (~temp01@unaffiliated/temp01)
# [09:52] * Parts: ryanseddon (~RSeddon@202.126.98.210)
# [09:55] * Quits: temp01 (~temp01@unaffiliated/temp01) (Client Quit)
# [09:55] * Joins: temp01 (~temp01@unaffiliated/temp01)
# [10:03] * Quits: sicking (~chatzilla@c-98-210-155-80.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
# [10:07] * Joins: richt (~richt@pat-tdc.opera.com)
# [10:08] * Joins: micheil (~micheil@124-149-63-232.dyn.iinet.net.au)
# [10:08] * Quits: micheil (~micheil@124-149-63-232.dyn.iinet.net.au) (Client Quit)
# [10:15] * Joins: jeremyselier (~Jeremy@92.103.127.226)
# [10:15] * Quits: virtuelv (~virtuelv_@pat-tdc.opera.com) (Quit: Ex-Chat)
# [10:15] * Joins: virtuelv (~virtuelv_@pat-tdc.opera.com)
# [10:16] * Quits: Akilo (~kristof@lit75-1-81-57-239-230.fbx.proxad.net) (Ping timeout: 276 seconds)
# [10:18] * Quits: shinyak (~shinyak@220.109.219.244) (Remote host closed the connection)
# [10:20] * bga_|away is now known as bga_
# [10:21] * Joins: shinyak (~shinyak@220.109.219.244)
# [10:22] * Quits: shinyak (~shinyak@220.109.219.244) (Remote host closed the connection)
# [10:23] * Quits: homata_ (~homata_@58x158x182x50.ap58.ftth.ucom.ne.jp) (Remote host closed the connection)
# [10:23] * Joins: CvP (CvP@180.234.48.79)
# [10:23] * Joins: mpt (~mpt@91.189.88.12)
# [10:23] * Quits: mpt (~mpt@91.189.88.12) (Changing host)
# [10:23] * Joins: mpt (~mpt@canonical/mpt)
# [10:25] * Joins: oknoway (~oknoway@173-8-201-137-Oregon.hfc.comcastbusiness.net)
# [10:26] * Quits: MrOpposite (~mropposit@unaffiliated/mropposite) (Read error: Connection reset by peer)
# [10:26] * Quits: ry (~ry@static-71-183-64-28.nycmny.fios.verizon.net) (Read error: Operation timed out)
# [10:26] * Quits: mpilgrim_ (~pilgrim@rrcs-24-206-36-125.midsouth.biz.rr.com) (Read error: Connection reset by peer)
# [10:26] * Joins: mpilgrim__ (~pilgrim@rrcs-24-206-36-125.midsouth.biz.rr.com)
# [10:28] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
# [10:32] * Quits: agektmr (~Adium@220.109.219.244) (Quit: Leaving.)
# [10:33] * Joins: danbri (~danbri@athedsl-4566690.home.otenet.gr)
# [10:35] * Joins: agektmr (~Adium@220.109.219.244)
# [10:38] * Joins: shinyak (~shinyak@2401:fa00:4:1012:129a:ddff:febe:ed11)
# [10:38] * Quits: nattokirai (~nattokira@rtr.mozilla.or.jp) (Quit: nattokirai)
# [10:39] * Joins: smaug____ (~chatzilla@78.41.210.66)
# [10:40] * Quits: kor (~kor@ip146-53-210-87.adsl2.static.versatel.nl) (Quit: kor)
# [10:40] * Quits: Rik`_ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Remote host closed the connection)
# [10:41] * Joins: ry (~ry@static-71-183-64-28.nycmny.fios.verizon.net)
# [10:41] * Joins: Rik` (~Rik`@2a01:e34:ec0f:1570:daa2:5eff:fe97:85ed)
# [10:43] * Quits: Rik` (~Rik`@2a01:e34:ec0f:1570:daa2:5eff:fe97:85ed) (Remote host closed the connection)
# [10:51] * Joins: Ms2ger (~Ms2ger@91.181.47.87)
# [10:51] * Quits: Necrathex (~nectop@dhcp-077-249-098-024.chello.nl) (Read error: Connection reset by peer)
# [10:52] * Joins: Necrathex (~nectop@dhcp-077-249-098-024.chello.nl)
# [10:54] * Quits: shinyak (~shinyak@2401:fa00:4:1012:129a:ddff:febe:ed11) (Remote host closed the connection)
# [10:54] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Quit: Leaving...)
# [11:03] * Joins: ttepasse (~ttepasse@ip-109-90-161-169.unitymediagroup.de)
# [11:04] * Joins: kor (~kor@83.160.149.179)
# [11:05] * Joins: tomasf (~tom@c-5ed9e555.024-204-6c6b7012.cust.bredbandsbolaget.se)
# [11:05] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
# [11:09] * Joins: Rik` (~Rik`@mozilla-paris-253-99.cnt.nerim.net)
# [11:10] * Joins: ZombieLoffe (~e@unaffiliated/zombieloffe)
# [11:11] * Joins: Akilo (~kristof@lit75-1-81-57-239-230.fbx.proxad.net)
# [11:14] * bga_ is now known as bga_|away
# [11:17] * bga_|away is now known as bga_
# [11:25] * Quits: agektmr (~Adium@220.109.219.244) (Quit: Leaving.)
# [11:29] * Quits: roc (~chatzilla@203-97-204-82.dsl.clear.net.nz) (Ping timeout: 258 seconds)
# [11:32] * Joins: livath (~livath@ix.ceid.upatras.gr)
# [11:43] * Joins: agektmr (~Adium@220.109.219.244)
# [11:46] * Quits: beowulf (u116@pdpc/supporter/professional/beowulf) (Remote host closed the connection)
# [11:46] * Quits: Scorchin (u1242@gateway/web/irccloud.com/x-xrxkfnigzbkqivfy) (Remote host closed the connection)
# [11:47] * Quits: Phae (u455@gateway/web/irccloud.com/x-rafnzphvwpthetbw) (Remote host closed the connection)
# [11:47] * Quits: mkwst (u395@gateway/web/irccloud.com/x-pgmudwidocugmlrv) (Remote host closed the connection)
# [11:47] * Joins: beowulf (u116@pdpc/supporter/professional/beowulf)
# [11:47] * Quits: beowulf (u116@pdpc/supporter/professional/beowulf) (Remote host closed the connection)
# [11:47] * Joins: Scorchin (u1242@gateway/web/irccloud.com/x-xdtgmifnoqqszwer)
# [11:48] <hsivonen> the date and time-related input types are still implemented in only Opera, right?
# [11:48] <hsivonen> properly, that is
# [11:49] <hsivonen> Bogus WebKit impls don't count as implemented
# [11:51] <Ms2ger> Sounds right
# [11:51] * Quits: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no) (Quit: This computer has gone to sleep)
# [11:53] * Joins: beowulf (u116@pdpc/supporter/professional/beowulf)
# [11:55] * Quits: smaug____ (~chatzilla@78.41.210.66) (Ping timeout: 258 seconds)
# [11:56] <hsivonen> Ms2ger: ok
# [11:56] * Joins: MrOpposite (~mropposit@unaffiliated/mropposite)
# [11:56] <hsivonen> I'm a bit unhappy about caniuse.com overstating support in Chrome
# [11:56] <hsivonen> so I have to actually check stuff myself instead of trusting caniuse
# [11:58] * Quits: danbri (~danbri@athedsl-4566690.home.otenet.gr) (Remote host closed the connection)
# [11:59] * Quits: yijun (~yijun@2001:250:208:1666:21f:f3ff:fe52:9714) (Quit: yijun)
# [12:01] * Quits: livath (~livath@ix.ceid.upatras.gr) (Quit: livath)
# [12:02] * Quits: ezoe (~ezoe@203-140-88-36f1.kyt1.eonet.ne.jp) (Read error: Connection reset by peer)
# [12:05] * Quits: MrOpposite (~mropposit@unaffiliated/mropposite) (Remote host closed the connection)
# [12:07] * Joins: livath (~livath@ix.ceid.upatras.gr)
# [12:07] * Joins: Lachy (~Lachlan@guest.opera.com)
# [12:09] * Joins: Phae (u455@gateway/web/irccloud.com/x-uewyoymmqvmekvor)
# [12:10] <zcorpan> hsivonen: ping him about it on twitter
# [12:11] * Quits: temp01 (~temp01@unaffiliated/temp01) (Ping timeout: 260 seconds)
# [12:14] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Quit: Leaving...)
# [12:15] * Joins: mkwst (u395@gateway/web/irccloud.com/x-fthyrqzapcbnhfvt)
# [12:20] * Joins: homata__ (~homata_@58x158x182x50.ap58.ftth.ucom.ne.jp)
# [12:22] * Quits: homata__ (~homata_@58x158x182x50.ap58.ftth.ucom.ne.jp) (Remote host closed the connection)
# [12:23] <jgraham> I really wish the spec would drop callers on HTMLCollection
# [12:23] <jgraham> AIUI Gecko doesn't implement them
# [12:24] * Joins: myakura (~myakura@FL1-118-111-219-27.tky.mesh.ad.jp)
# [12:24] <jgraham> and the behaviour is undefined in edge cases
# [12:24] <jgraham> and there is no good reason to use them
# [12:25] * Quits: agektmr (~Adium@220.109.219.244) (Quit: Leaving.)
# [12:29] * Joins: agektmr (~Adium@220.109.219.244)
# [12:31] * Quits: Lachy (~Lachlan@guest.opera.com) (Quit: Leaving)
# [12:31] * Joins: Lachy (~Lachlan@guest.opera.com)
# [12:31] * Joins: charlvn (~charlvn@41.0.48.54)
# [12:36] * Quits: lhnz (~lhnz@188-223-83-48.zone14.bethere.co.uk) (Ping timeout: 255 seconds)
# [12:37] * Joins: lhnz (~lhnz@188-223-83-48.zone14.bethere.co.uk)
# [12:39] * Quits: kor (~kor@83.160.149.179) (Quit: kor)
# [12:40] * Quits: Necrathex (~nectop@dhcp-077-249-098-024.chello.nl) (Quit: Necrathex)
# [12:41] * Joins: temp01 (~temp01@unaffiliated/temp01)
# [12:41] * Quits: livath (~livath@ix.ceid.upatras.gr) (Read error: Connection reset by peer)
# [12:42] <Ms2ger> jgraham, implement DOM Core instead? :)
# [12:45] * Joins: Necrathex (~nectop@dhcp-077-249-098-024.chello.nl)
# [12:45] * Quits: temp01 (~temp01@unaffiliated/temp01) (Ping timeout: 246 seconds)
# [12:46] * Joins: temp02 (~temp01@unaffiliated/temp01)
# [12:46] <Lachy> jgraham, it seems that Opera, IE and WebKit all implement callers
# [12:49] <jgraham> Lachy: Yes. They still suck though
# [12:50] <jgraham> And they're not interoperable in edge cases
# [12:50] <jgraham> e.g. my_html_collection(-1)
# [12:51] <Lachy> interop on edge cases can be fixed. The issue is whether the behaviour is needed at all for the common cases.
# [12:51] <jgraham> Well since gecko doesn't implement it it seems like it might well not be needed
# [12:52] <jgraham> We certainly shouldn't add new interfaces with this legacy gunk on
# [12:52] <jgraham> Even if it is more consustent
# [12:52] <jgraham> *consistent
# [12:52] <Lachy> also, it seems the spec definition of HTMLCollection.item() is wrong. Implementations accept either an unsigned long index or DOMString name
# [12:52] <jgraham> Allowing people to be consistently stupid isn't a win
# [12:53] * Joins: kor (~kor@83.160.149.179)
# [12:53] <jgraham> Isn't the DOMString a differnt method?
# [12:53] <Lachy> yes, .namedItem(DOMString) works, but so does .item(DOMString)
# [12:54] <jgraham> Oh ffs
# [12:54] * Lachy goes to file a bug
# [12:58] <Lachy> oh, wait. No, my test was incorrect. .item("test") was simply returning the first control, like .item(0).
# [12:59] <jgraham> same as .item() I guess
# [12:59] <jgraham> ?
# [12:59] <Lachy> hmm, no. IE does what I originally thought.
# [13:00] <Lachy> other browsers don't. I guess we don't need that behaviour after all. I'll resolve my bug invalid
# [13:00] * Joins: _bga (~bga@95-55-40-219.dynamic.avangarddsl.ru)
# [13:01] <hsivonen> zcorpan: I pinged Fyrc on Twitter
# [13:03] * Quits: bga_ (~bga@95-55-42-35.dynamic.avangarddsl.ru) (Ping timeout: 276 seconds)
# [13:04] * Quits: ttepasse (~ttepasse@ip-109-90-161-169.unitymediagroup.de) (Ping timeout: 240 seconds)
# [13:06] <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>?
# [13:06] <hsivonen> should I warn about <mark> and <time>?
# [13:08] * Joins: agektmr1 (~Adium@220.109.219.244)
# [13:08] * Quits: agektmr (~Adium@220.109.219.244) (Read error: Connection reset by peer)
# [13:09] * Parts: charlvn (~charlvn@41.0.48.54)
# [13:09] * Joins: smaug____ (~chatzilla@78.41.210.66)
# [13:12] <Ms2ger> meter?
# [13:16] <hsivonen> Ms2ger: thanks
# [13:21] * Quits: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Quit: Leaving...)
# [13:22] * Joins: eikaas_ (~eikaas@79.161.4.102)
# [13:23] * Quits: eikaas (~eikaas@79.161.4.102) (Read error: Operation timed out)
# [13:23] * eikaas_ is now known as eikaas
# [13:24] <MikeSmith> hsivonen: if you are interested in working on http://bugzilla.validator.nu/show_bug.cgi?id=589 feel free to reassign it
# [13:25] <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
# [13:25] * Quits: Lachy (~Lachlan@guest.opera.com) (Quit: Leaving)
# [13:27] <hsivonen> MikeSmith: I'm not in so much hurry that I couldn't wait for your patch :-)
# [13:27] <MikeSmith> heh
# [13:27] <MikeSmith> OK
# [13:35] * Joins: tndH (~Rob@cpc11-seac19-2-0-cust116.7-2.cable.virginmedia.com)
# [13:36] * Joins: Lachy (~Lachlan@pat-tdc.opera.com)
# [13:39] * Quits: seventh (seventh@31.6.22.252) (Quit: ...)
# [13:49] * Quits: shepazu (~schepers@108-70-132-46.lightspeed.rlghnc.sbcglobal.net) (Ping timeout: 250 seconds)
# [13:50] * Quits: agektmr1 (~Adium@220.109.219.244) (Quit: Leaving.)
# [14:05] * _bga is now known as bga_|away
# [14:06] * bga_|away is now known as bga_
# [14:09] * Joins: agektmr (~Adium@220.109.219.244)
# [14:10] * Quits: agektmr (~Adium@220.109.219.244) (Client Quit)
# [14:17] * Joins: tbassetto (~tbassetto@2a01:e35:2eec:80a0:f2b4:79ff:fe15:3589)
# [14:18] * Joins: shinyak (~shinyak@2401:fa00:4:1012:129a:ddff:febe:ed11)
# [14:22] * Quits: mpilgrim__ (~pilgrim@rrcs-24-206-36-125.midsouth.biz.rr.com) (Ping timeout: 246 seconds)
# [14:26] * Quits: CvP (CvP@180.234.48.79) (Ping timeout: 240 seconds)
# [14:27] * Quits: shinyak (~shinyak@2401:fa00:4:1012:129a:ddff:febe:ed11) (Remote host closed the connection)
# [14:31] * Quits: nessy (~Adium@124-149-37-204.dyn.iinet.net.au) (Quit: Leaving.)
# [14:31] <zcorpan> hsivonen: type=color is supported by opera too
# [14:32] * Joins: demet8 (~demet8@7.186.8.67.cfl.res.rr.com)
# [14:33] <hsivonen> zcorpan: whoa. Thanks. (I should always test everything *again* instead of relying on my previous testing.)
# [14:33] <zcorpan> hsivonen: i think <link sizes> is not supported anywhere
# [14:33] <hsivonen> zcorpan: Apple's documentation suggests rel="apple-touch-icon" sizes="..." is supported
# [14:34] <hsivonen> zcorpan: though apple-touch-icon is currently unregistered
# [14:34] <zcorpan> oh, didn't know that
# [14:35] <zcorpan> <blockquote cite>? ;)
# [14:35] <hsivonen> zcorpan: hah. that's a good one.
# [14:35] <zcorpan> <ol reversed>
# [14:36] <zcorpan> <a ping>? what's the status on that?
# [14:36] <Ms2ger> Mozilla has a broken, preffed off implementation since Fx3, I think that's it
# [14:36] <hsivonen> IIRC, <a ping> is disabled in Firefox
# [14:36] <hsivonen> does Chrome support <a ping>?
# [14:37] <hsivonen> Ms2ger: what's broken about the Firefox impl (apart from being preffed off)?
# [14:37] <zcorpan> hsivonen: fwiw <meter> is supported in opera
# [14:37] <Ms2ger> The spec changed under us
# [14:37] <hsivonen> zcorpan: thanks
# [14:38] <zcorpan> crossorigin on img, video, audio
# [14:38] <zcorpan> what's the status on <iframe srcdoc sandbox seamless>?
# [14:39] <zcorpan> <video mediagroup>
# [14:39] <zcorpan> (also on audio)
# [14:39] <zcorpan> (ping is also on area)
# [14:40] <zcorpan> <input dirname> <textarea dirname>
# [14:41] <hsivonen> what's dirname?
# [14:41] * smaug____ should start reviewing the patch for <meter>
# [14:41] <hsivonen> I have a vague recollection of Chrome having one or two of the new iframe attributes
# [14:41] * Joins: nimbupani (~Adium@c-24-18-47-160.hsd1.wa.comcast.net)
# [14:41] * nimbupani is now known as nimbu
# [14:41] <smaug____> not that really understand the reason for progress *and* meter
# [14:41] <zcorpan> contextmenu=""
# [14:42] <zcorpan> dropzone=""?
# [14:42] <zcorpan> itemid
# [14:42] <zcorpan> itemprop
# [14:42] <zcorpan> itemref
# [14:42] <zcorpan> itemscope
# [14:42] <zcorpan> itemtype
# [14:43] * Parts: nimbu (~Adium@c-24-18-47-160.hsd1.wa.comcast.net)
# [14:43] <zcorpan> hsivonen: it's a new bidi thing
# [14:43] <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
# [14:44] <zcorpan> that's fair enough
# [14:44] <hsivonen> I didn't add warning for stuff like <footer> for that reason
# [14:44] <zcorpan> <footer> is also implemented these days
# [14:44] <hsivonen> though using <section><h1> might be a bit dangerous, but that ship has sailed so it's not worthwhile to warn about it
# [14:45] <hsivonen> I'm not familiar with the threat scenarios with premature use of dropzone
# [14:47] <zcorpan> dunno
# [14:49] <zcorpan> maybe it's not so much of a treat, but would still be helpful to know why it doesn't work
# [14:49] <zcorpan> s//h/
# [14:56] * Joins: chriseppstein (~chris@99-34-231-235.lightspeed.sntcca.sbcglobal.net)
# [14:58] * Joins: danbri (~danbri@athedsl-4566690.home.otenet.gr)
# [14:59] * Joins: shepazu (~schepers@108-70-132-46.lightspeed.rlghnc.sbcglobal.net)
# [15:01] * Quits: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie) (Quit: brb)
# [15:01] * Joins: hij1nx (~hij1nx@cpe-66-65-124-111.nyc.res.rr.com)
# [15:04] * Joins: simplicity- (~simpli@unaffiliated/simplicity-)
# [15:05] <hsivonen> smaug____: progress is for progress bars. meter is for things like disk space usage indicators
# [15:05] <hsivonen> smaug____: different widgets e.g. on Mac
# [15:05] <smaug____> oh, there is a different widget on some system
# [15:06] * smaug____ has given up with mac
# [15:08] <hsivonen> it seems that Chrome doesn't support <iframe srcdoc> or <iframe seamless>
# [15:08] <hsivonen> <iframe sandbox> can't be verified visually
# [15:09] <hsivonen> oh. I guess I should add validation of the text/html-sandboxed MIME type, too
# [15:10] <hsivonen> http://blog.chromium.org/2010/05/security-in-depth-html5s-sandbox.html
# [15:10] <hsivonen> looks like they have support
# [15:14] * Quits: wakaba__ (~wakaba@57.72.102.121.dy.bbexcite.jp) (Quit: Leaving...)
# [15:15] * Joins: miketaylr (~miketaylr@206.217.92.186)
# [15:17] * Joins: wakaba (~wakaba@57.72.102.121.dy.bbexcite.jp)
# [15:18] <hsivonen> oh. nice. Opera Mini has a hidden pref for turning off phone number linkification
# [15:18] <hsivonen> (that almost always ends up linkifying something that isn't a phone number)
# [15:21] <smaug____> chrome/linux seems to have different rendering for meter and progress, Opera/linux has the same
# [15:21] * Joins: mpilgrim__ (~pilgrim@rrcs-24-206-36-125.midsouth.biz.rr.com)
# [15:29] * Quits: eikaas (~eikaas@79.161.4.102) (Read error: Connection reset by peer)
# [15:29] * Joins: eikaas (~eikaas@79.161.4.102)
# [15:31] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 240 seconds)
# [15:35] <hsivonen> it's sad that CSP uses an X- header
# [15:36] <hsivonen> did Chrome implement CSP with the X- syntax?
# [15:36] <hsivonen> that is, is CSP now more than a product-specific thing_
# [15:36] <hsivonen> ?
# [15:37] * Joins: MikeSmith_ (~MikeSmith@EM111-188-37-103.pool.e-mobile.ne.jp)
# [15:40] * Quits: MikeSmith (~MikeSmith@EM114-48-162-248.pool.e-mobile.ne.jp) (Ping timeout: 244 seconds)
# [15:40] * MikeSmith_ is now known as MikeSmith
# [15:41] * Quits: Ankheg (~Ankheg@fs91-201-3-30.dubna-net.ru) (Read error: Connection reset by peer)
# [15:42] * Joins: matjas_ (~matjas@91.182.178.25)
# [15:42] * matjas is now known as Guest56899
# [15:42] * Quits: matjas_ (~matjas@91.182.178.25) (Read error: Connection reset by peer)
# [15:42] * Joins: matjas_ (~matjas@91.182.178.25)
# [15:43] * Quits: Guest56899 (~matjas@91.182.178.25) (Ping timeout: 250 seconds)
# [15:49] * Joins: boaz_ (~boaz@75-150-66-249-NewEngland.hfc.comcastbusiness.net)
# [15:52] * Joins: cying (~cying@c-24-6-96-149.hsd1.ca.comcast.net)
# [15:52] <hsivonen> hmm. bitbucket is down :-(
# [15:54] <Philip`> Their web site looks okay to me
# [15:55] * Quits: matjas_ (~matjas@91.182.178.25) (Remote host closed the connection)
# [15:58] * Quits: danbri (~danbri@athedsl-4566690.home.otenet.gr) (Remote host closed the connection)
# [15:58] <hsivonen> Philip`: https://bitbucket.org/validator/syntax/changesets fails for me
# [15:58] <hsivonen> "Oops! An error occurred"
# [15:59] <hsivonen> "Someone kicked over the bucket, sadface"
# [15:59] <hsivonen> oh. now it loaded
# [16:02] * Quits: Necrathex (~nectop@dhcp-077-249-098-024.chello.nl) (Read error: Connection reset by peer)
# [16:02] * Joins: Necrathex (~nectop@dhcp-077-249-098-024.chello.nl)
# [16:04] * Quits: smaug____ (~chatzilla@78.41.210.66) (Ping timeout: 240 seconds)
# [16:06] * Quits: hdhoang (~hdhoang@203.210.155.205) (Ping timeout: 260 seconds)
# [16:11] * Joins: hdhoang (~hdhoang@203.210.199.182)
# [16:12] * Quits: ZombieLoffe (~e@unaffiliated/zombieloffe)
# [16:15] * Joins: mpt (~mpt@91.189.88.12)
# [16:15] * Quits: mpt (~mpt@91.189.88.12) (Changing host)
# [16:15] * Joins: mpt (~mpt@canonical/mpt)
# [16:24] <hsivonen> wow. provisionally-registered HTTP headers that start with X- http://www.iana.org/assignments/message-headers/prov-headers.html
# [16:24] * Joins: jochen___ (~jochen@nat/google/x-uzlrqliealtgfkwd)
# [16:24] <hsivonen> my sympathies to whoever fought the fight with the Designated Experts on those ones
# [16:25] * Quits: jochen__ (~jochen@nat/google/x-socuxjpxppxjjtmf) (Ping timeout: 248 seconds)
# [16:25] * jochen___ is now known as jochen__
# [16:28] * hsivonen discovers http://tools.ietf.org/html/draft-mutz-http-attributes-01
# [16:28] * Joins: CvP (CvP@180.234.104.105)
# [16:29] * Joins: Jon47 (~jon47@204.56.125.50)
# [16:29] * Joins: ezoe (~ezoe@112-68-245-87f1.kyt1.eonet.ne.jp)
# [16:32] * Joins: sicking (~chatzilla@c-98-210-155-80.hsd1.ca.comcast.net)
# [16:47] * Quits: miketaylr (~miketaylr@206.217.92.186) (Quit: miketaylr)
# [16:47] * Quits: richt (~richt@pat-tdc.opera.com) (Remote host closed the connection)
# [16:48] * Joins: FireFly (~firefly@unaffiliated/firefly)
# [16:51] * Quits: sicking (~chatzilla@c-98-210-155-80.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
# [16:55] <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?
# [17:00] * Joins: bentruyman (~bentruyma@li159-104.members.linode.com)
# [17:01] <hsivonen> FWIW, I investigated doing HTTP header validation today
# [17:02] <hsivonen> but decided against it, because real Web content uses unregistered headers too often to make it practical to whine about all unregistered headers
# [17:02] * Joins: cm (~callumacr@69.175.32.132)
# [17:02] <hsivonen> I did, however, add a warning about X-UA-Compatible as an HTTP header
# [17:03] <zcorpan> hsivonen: what about validating headers without whining about unregistered ones?
# [17:03] <hsivonen> zcorpan: I guess validating their contents would be a possibility
# [17:04] <zcorpan> hsivonen: do you show the headers in Show Source?
# [17:04] * Parts: cm (~callumacr@69.175.32.132) ("Leaving...")
# [17:05] <hsivonen> zcorpan: I don't, but showing them would make sense
# [17:06] * Quits: maikmerten (~merten@ls5dhcp197.cs.uni-dortmund.de) (Remote host closed the connection)
# [17:07] * Joins: Martijnc (~Martijnc@d54C02C64.access.telenet.be)
# [17:08] <hsivonen> Apache has made API-breaking changes to HttpClient
# [17:08] * Quits: ezoe (~ezoe@112-68-245-87f1.kyt1.eonet.ne.jp) (Ping timeout: 240 seconds)
# [17:08] <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:12] * Joins: shichuan (~Shi_Chuan@cm182.eta124.maxonline.com.sg)
# [17:20] * Quits: Rik` (~Rik`@mozilla-paris-253-99.cnt.nerim.net) (Remote host closed the connection)
# [17:23] * Joins: Bass10 (~Bass10@c-76-113-194-7.hsd1.mn.comcast.net)
# [17:24] * Quits: Bass10 (~Bass10@c-76-113-194-7.hsd1.mn.comcast.net) (Max SendQ exceeded)
# [17:26] * Quits: zcorpan (~zcorpan@c-8798e355.410-6-64736c14.cust.bredbandsbolaget.se) (Quit: zcorpan)
# [17:31] * Quits: hij1nx (~hij1nx@cpe-66-65-124-111.nyc.res.rr.com) (Quit: hij1nx)
# [17:34] * Parts: shichuan (~Shi_Chuan@cm182.eta124.maxonline.com.sg)
# [17:43] * Joins: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
# [17:44] * Joins: smaug____ (~chatzilla@195.166.51.3)
# [17:44] * Quits: Lachy (~Lachlan@pat-tdc.opera.com) (Quit: This computer has gone to sleep)
# [17:47] * Quits: cying (~cying@c-24-6-96-149.hsd1.ca.comcast.net) (Quit: cying)
# [17:49] * Quits: hdhoang (~hdhoang@203.210.199.182) (Ping timeout: 260 seconds)
# [17:50] * Joins: hdhoang (~hdhoang@203.210.152.9)
# [17:55] * Joins: ezoe (~ezoe@61-205-124-213f1.kyt1.eonet.ne.jp)
# [17:56] * Quits: Necrathex (~nectop@dhcp-077-249-098-024.chello.nl) (Read error: Connection reset by peer)
# [17:57] * Joins: Necrathex (~nectop@dhcp-077-249-098-024.chello.nl)
# [17:59] * Joins: sicking (~chatzilla@2620:101:8003:200:226:bbff:fe05:3fe1)
# [18:01] * Joins: MrOpposite (~mropposit@unaffiliated/mropposite)
# [18:01] * Quits: hdhoang (~hdhoang@203.210.152.9) (Quit: Leaving.)
# [18:01] * Joins: eric_carlson_ (~eric_carl@17.203.15.27)
# [18:02] * Quits: eric_carlson (~ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net) (Disconnected by services)
# [18:02] * eric_carlson_ is now known as eric_carlson
# [18:03] * Joins: zdobersek (~zan@cpe-46-164-27-101.dynamic.amis.net)
# [18:03] * Joins: hij1nx (~hij1nx@207.239.107.3)
# [18:03] * Quits: sicking (~chatzilla@2620:101:8003:200:226:bbff:fe05:3fe1) (Ping timeout: 248 seconds)
# [18:06] * Joins: sicking (~chatzilla@nat/mozilla/x-rcoypkisanwmhrjw)
# [18:07] * bga_ is now known as bga_|away
# [18:09] * Joins: Jackneill (~root@unaffiliated/jackneill)
# [18:11] * Joins: kling (~kling@nat/trolltech/x-kyhndvlbbhsdldsy)
# [18:12] * Quits: sicking (~chatzilla@nat/mozilla/x-rcoypkisanwmhrjw) (Ping timeout: 248 seconds)
# [18:12] <TabAtkins> Jeezus, we have to deal with @longdesc *again*?
# [18:13] <Ms2ger> Of course
# [18:14] * Joins: dave_levin (~dave_levi@74.125.59.65)
# [18:16] <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
# [18:17] * dglazkov|away is now known as dglazkov
# [18:18] <jgraham> Anyway this time it will probably get in. The politics of the situation make it increasingly unlikely that it will be rejected
# [18:19] <TabAtkins> The politics being "they won't shut up about it"?
# [18:19] <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
# [18:19] <jgraham> I expect Sam to be swayed by the work Laura did
# [18:20] <AryehGregor> Did they actually produce any good reasoning for why it should go in?
# [18:21] <AryehGregor> By the standards the chairs gave in their last decision?
# [18:21] <jgraham> They found a handful of sites that used it
# [18:21] * Joins: matjas (~matjas@91.182.178.25)
# [18:21] * bga_|away is now known as bga_
# [18:21] <AryehGregor> Used it usefully?
# [18:22] <jgraham> Dunno
# [18:22] <jgraham> They also made a list of things that supposedly require longdesc
# [18:23] <jgraham> Which were basically "describing" plus any type of image they could think of
# [18:23] * Quits: Akilo (~kristof@lit75-1-81-57-239-230.fbx.proxad.net) (Quit: Ex-Chat)
# [18:23] -myakura:#whatwg- wonders if there's any browsers (except Opera) which supports longdesc
# [18:24] <jgraham> This didn't seem like "new" information in any meaningful sense of the word "new", but the WG operates in mysterious ways
# [18:28] <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
# [18:28] * Joins: tantek (~tantek@2620:101:8003:200:5a55:caff:fef3:c447)
# [18:28] * Quits: erlehmann (~erlehmann@89.204.137.125) (Quit: Ex-Chat)
# [18:30] * Quits: rimantas (~rimliu@93.93.57.193) (Quit: Leaving)
# [18:33] * Quits: smaug____ (~chatzilla@195.166.51.3) (Read error: Connection reset by peer)
# [18:34] * Joins: cying (~cying@173-13-176-101-sfba.hfc.comcastbusiness.net)
# [18:37] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
# [18:38] <Ms2ger> jgraham, in that case, I'd try to avoid going blind ;)
# [18:39] <TabAtkins> myakura: There's not.
# [18:42] <Philip`> Ms2ger: I'd have thought you'd try to avoid that in any case
# [18:48] * Joins: jgv_ (~jgv@pool-108-41-134-165.nycmny.fios.verizon.net)
# [18:49] <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.
# [18:51] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 240 seconds)
# [18:51] * Quits: matjas (~matjas@91.182.178.25) (Remote host closed the connection)
# [18:51] <twisted`> hmm is it correct that if an input field is set to disabled it's value doesn't get posted?
# [18:52] <TabAtkins> Yes.
# [18:52] * Quits: chriseppstein (~chris@99-34-231-235.lightspeed.sntcca.sbcglobal.net) (Quit: chriseppstein)
# [18:53] * Joins: maikmerten (~maikmerte@port-92-201-152-46.dynamic.qsc.de)
# [18:53] * Quits: tbassetto (~tbassetto@2a01:e35:2eec:80a0:f2b4:79ff:fe15:3589) (Quit: tbassetto)
# [18:55] <twisted`> cool then I just use readonly
# [18:55] <twisted`> :)
# [18:56] * Joins: matjas (~matjas@91.182.178.25)
# [18:56] * Quits: MrOpposite (~mropposit@unaffiliated/mropposite) (Remote host closed the connection)
# [18:57] * Quits: jgv_ (~jgv@pool-108-41-134-165.nycmny.fios.verizon.net) (Quit: Computer has gone to sleep.)
# [18:58] * Joins: _bga (~bga@95-55-40-219.dynamic.avangarddsl.ru)
# [19:01] * Quits: bga_ (~bga@95-55-40-219.dynamic.avangarddsl.ru) (Ping timeout: 244 seconds)
# [19:02] * Quits: matjas (~matjas@91.182.178.25) (Ping timeout: 246 seconds)
# [19:04] * Quits: myakura (~myakura@FL1-118-111-219-27.tky.mesh.ad.jp) (Remote host closed the connection)
# [19:08] * Quits: kor (~kor@83.160.149.179) (Quit: kor)
# [19:09] * Joins: matjas (~matjas@134.246-242-81.adsl-dyn.isp.belgacom.be)
# [19:11] * Joins: sicking (~chatzilla@2620:101:8003:200:226:bbff:fe05:3fe1)
# [19:13] * Quits: Jon47 (~jon47@204.56.125.50) (Ping timeout: 258 seconds)
# [19:14] * _bga is now known as bga_|away
# [19:14] * bga_|away is now known as bga_
# [19:19] * Joins: jamesr (~jamesr@nat/google/x-ynjcfbtjhlrkudqc)
# [19:19] * Joins: Jon47 (~jon47@204.56.125.50)
# [19:22] <AryehGregor> Is foo.innerHTML = foo.innerHTML; foo.innerHTML = foo.innerHTML guaranteed to be the same as foo.innerHTML = foo.innerHTML?
# [19:22] * AryehGregor doesn't have any real reason to know, is just curious
# [19:22] <AryehGregor> Or rather than "guaranteed to be", I should say "supposed to always be".
# [19:26] <Philip`> As in, should fragmentparse(fragmentserialize(x)) be idempotent?
# [19:27] * Quits: othermaciej (~mjs@c-24-6-209-6.hsd1.ca.comcast.net) (Quit: othermaciej)
# [19:27] <AryehGregor> Basically, yeah.
# [19:27] * Quits: jacobolus (~jacobolus@208-90-212-203.PUBLIC.monkeybrains.net) (Remote host closed the connection)
# [19:29] * Joins: jacobolus (~jacobolus@208-90-212-203.PUBLIC.monkeybrains.net)
# [19:35] <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:37] * Joins: othermaciej (~mjs@67.218.107.37)
# [19:45] * Joins: dbaron (~dbaron@nat/mozilla/x-cjaqvtvzpafduubx)
# [19:47] * Joins: hdhoang (~hdhoang@203.210.152.9)
# [19:53] * Quits: Jon47 (~jon47@204.56.125.50) (Ping timeout: 258 seconds)
# [19:53] * Joins: chriseppstein (~chris@209.119.65.162)
# [19:56] * Joins: jgv_ (~jgv@pool-108-41-134-165.nycmny.fios.verizon.net)
# [20:00] * Joins: Jon47 (~jon47@204.56.125.50)
# [20:01] * Quits: tantek (~tantek@2620:101:8003:200:5a55:caff:fef3:c447) (Quit: tantek)
# [20:05] * Joins: aho (~nya@fuld-590c7b6b.pool.mediaWays.net)
# [20:08] * Quits: jamesr (~jamesr@nat/google/x-ynjcfbtjhlrkudqc) (Quit: jamesr)
# [20:11] * Joins: miketaylr (~miketaylr@206.217.92.186)
# [20:14] * Joins: kor (~kor@ip146-53-210-87.adsl2.static.versatel.nl)
# [20:17] * Joins: jamesr (~jamesr@216.239.45.19)
# [20:17] * Joins: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no)
# [20:26] * Joins: MrOpposite (~mropposit@unaffiliated/mropposite)
# [20:26] * Quits: hdhoang (~hdhoang@203.210.152.9) (Quit: Leaving.)
# [20:28] * Quits: jacobolus (~jacobolus@208-90-212-203.PUBLIC.monkeybrains.net) (Ping timeout: 276 seconds)
# [20:33] <bga_> heh is it possible to prevent {if(window !== top )top.location = '' + location}?
# [20:34] <bga_> tried overwrite location setter
# [20:34] <bga_> top getter
# [20:34] <jgraham> Disable scripting? :)
# [20:34] <AryehGregor> You mean, can you stop sites you put in frames from breaking out? Not really, no.
# [20:34] <AryehGregor> Nor should you be able to.
# [20:35] <AryehGregor> Since some sites don't want to be framed for security reasons.
# [20:35] <jgraham> location is magic for security reasons
# [20:35] <jgraham> Even before this it had to be because flash used it or something
# [20:35] <bga_> heh
# [20:38] <bga_> => only iframe's sandbox attribute
# [20:42] * Quits: othermaciej (~mjs@67.218.107.37) (Quit: othermaciej)
# [20:42] * Joins: JonathanNeal (~Jonathan@rrcs-76-79-114-213.west.biz.rr.com)
# [20:46] <JonathanNeal> I had a javascript-related question about selections, and someone suggested I pop in here and ask about it.
# [20:47] <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.
# [20:47] <JonathanNeal> AryehGregor: are you speccing this stuff?
# [20:47] <AryehGregor> JonathanNeal, yes.
# [20:47] * Quits: jeremyselier (~Jeremy@92.103.127.226) (Ping timeout: 260 seconds)
# [20:48] <AryehGregor> getSelection().getRangeAt(0).cloneContents() should get you something like what you want.
# [20:48] <AryehGregor> If the Selection has only a single Range, it will return a DocumentFragment that clones that range's contents.
# [20:48] <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.
# [20:49] <AryehGregor> What does "raw" mean here?
# [20:49] <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`.
# [20:49] <AryehGregor> Not possible, all this stuff is DOM-based.
# [20:49] <AryehGregor> Why do you want it?
# [20:50] <AryehGregor> In general, keep in mind that the input HTML might bear little resemblance to the DOM.
# [20:50] <AryehGregor> For instance, scripts might have changed the DOM, or various HTML parser quirks might have rearranged things.
# [20:50] <AryehGregor> So conceptually, browsers convert the HTML input into a DOM and then throw it away.
# [20:50] <JonathanNeal> Well, I guess you answered my question with "not possible".
# [20:51] <Ms2ger> He had a capital "N", but yes :)
# [20:51] <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?
# [20:51] <AryehGregor> Anyway, as I said, why do you want it?
# [20:52] <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.
# [20:52] <JonathanNeal> AryehGregor, oh you know, the usual, it's a Wednesday, I think I could write a better WYSIWYG.
# [20:52] <AryehGregor> JonathanNeal, how do you read the common ancestor's HTML?
# [20:52] <JonathanNeal> I had this going for a while http://sandbox.thewikies.com/content-editable/
# [20:52] <AryehGregor> innerHTML? That doesn't return the original HTML either.
# [20:52] <AryehGregor> It returns a serialization of the DOM.
# [20:52] <JonathanNeal> AryehGregor: I read the common ancestor's HTML with innerHTML
# [20:52] * Joins: othermaciej (~mjs@17.246.17.1)
# [20:53] * Quits: othermaciej (~mjs@17.246.17.1) (Remote host closed the connection)
# [20:53] <AryehGregor> Okay, so you don't actually want the original HTML that was given to the browser.
# [20:53] <AryehGregor> (because innerHTML is not that)
# [20:53] * Joins: othermaciej (~mjs@17.203.15.180)
# [20:53] <AryehGregor> There's no API to create partial fragments of HTML like that, with mismatched tags and all.
# [20:53] <JonathanNeal> I see.
# [20:53] * Quits: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no) (Quit: Leaving)
# [20:54] <AryehGregor> cloneContents() will get you "<em>ox</em> jumps over the lazy <strong>d</strong>", in your example.
# [20:54] * Joins: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no)
# [20:54] <AryehGregor> JonathanNeal, is that good enough for your purposes?
# [20:55] <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.
# [20:56] <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.
# [20:56] <AryehGregor> Hmm. Is there a way to serialize the HTML of a DocumentFragment?
# [20:57] <JonathanNeal> That would be awesome, though I've been assuming that the fragment was already normalized.
# [20:57] * AryehGregor dumps it into a div
# [20:58] <AryehGregor> If by "normalized" you mean "opening and closing tags are paired up", yes, the DOM is always "normalized".
# [20:58] * Quits: Martijnc (~Martijnc@d54C02C64.access.telenet.be) (Quit: Martijnc)
# [20:58] <AryehGregor> JonathanNeal, see the log at the bottom here: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1005
# [20:58] <AryehGregor> It has the extra opening/closing tags.
# [20:59] <AryehGregor> But you might be able to strip them off more easily than whatever you're doing now.
# [20:59] <AryehGregor> Anyway, feel free to tell me about the injected anchors thing you're talking about.
# [21:00] * Joins: jacobolus (~jacobolus@208-90-212-203.PUBLIC.monkeybrains.net)
# [21:00] * Joins: hij1nx_ (~hij1nx@207.239.107.3)
# [21:01] * Quits: bentruyman (~bentruyma@li159-104.members.linode.com) (Quit: bentruyman)
# [21:02] <JonathanNeal> I'm looking at what you mentioned.
# [21:03] <JonathanNeal> I don't get what I was supposed to learn from the log, I guess.
# [21:04] <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
# [21:04] * Quits: hij1nx (~hij1nx@207.239.107.3) (Ping timeout: 252 seconds)
# [21:04] * hij1nx_ is now known as hij1nx
# [21:04] <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.
# [21:04] <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.
# [21:05] <AryehGregor> (I'm still not sure why you want such fragments; I suspect you don't)
# [21:06] <JonathanNeal> Well, I want to write a WYSIWYG editor that inspects the HTML more like selectionStart for a textarea.
# [21:07] <AryehGregor> As opposed to using the DOM? Why?
# [21:07] <AryehGregor> It might look simpler, but it will cause all sorts of headaches if you try fiddling with innerHTML instead of the DOM.
# [21:07] <JonathanNeal> Well, look at the example @ http://sandbox.thewikies.com/content-editable/ and use some of the buttons. It's just an idea.
# [21:09] <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.
# [21:09] * Joins: sephr (~Eli@c-98-235-63-240.hsd1.pa.comcast.net)
# [21:09] <AryehGregor> That's going to have unpredictable results.
# [21:09] <JonathanNeal> AryehGregor: yea, and I understand how big of a problem that might be.
# [21:09] <AryehGregor> Well, as long as you realize.
# [21:10] <JonathanNeal> I do realize, and I was thinking of creating fake ranges and taking advantage of that "normalizing" to generate the proper HTML.
# [21:10] <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?
# [21:11] <Ms2ger> Hixie's Law?
# [21:11] <Hixie> no someone else came up with it
# [21:11] <Hixie> hsivonen quotes it often
# [21:12] <hober> Conway's Law?
# [21:12] <JonathanNeal> AryehGregor: here's the weird selection "bug" I've been seeing @ http://sandbox.thewikies.com/selection/
# [21:12] <Hixie> conway! thanks
# [21:13] <AryehGregor> JonathanNeal, I'm not seeing anything. Do I need to do something special? What browser are you using?
# [21:13] <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"
# [21:13] <JonathanNeal> Firefox 4.
# [21:13] * Quits: Jackneill (~root@unaffiliated/jackneill) (Remote host closed the connection)
# [21:13] <hsivonen> Hixie: the good thing is the X-Content-Security-Policy already has a spec
# [21:13] <JonathanNeal> Yea, it must be a Firefox bug.]
# [21:13] <hsivonen> Hixie: X-Frame-Options might have some near-spec-worthy docs
# [21:13] <AryehGregor> I suspect I know what's happening. Just a sec.
# [21:14] <AryehGregor> JonathanNeal, you're doing splitText() implicitly here somewhere, probably by calling insertNode().
# [21:14] <AryehGregor> DOM 2 Range mandates the behavior you're seeing.
# [21:14] <Hixie> hsivonen: cool
# [21:15] <AryehGregor> The definition I gave for range mutation follows WebKit, which is smarter about it.
# [21:15] <JonathanNeal> :D Well thanks for using the smart one.
# [21:15] <JonathanNeal> Is there a way to patch Firefox back into happiness and unsplit?
# [21:17] * Quits: maikmerten (~maikmerte@port-92-201-152-46.dynamic.qsc.de) (Remote host closed the connection)
# [21:18] <JonathanNeal> AryehGregor: is there a way I can clone the range to a cloned element?
# [21:18] <AryehGregor> JonathanNeal, what do you mean, clone the range to a cloned element?
# [21:18] <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
# [21:19] <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.
# [21:20] <AryehGregor> No, no simple way to do that.
# [21:20] <AryehGregor> The clone has no relationship to the original nodes.
# [21:20] <JonathanNeal> Yea.
# [21:20] <AryehGregor> You'd have to do it manually, by figuring out the correct start and end points and setting the range to those.
# [21:20] <jgraham> Hixie: Does it sound at all plausible to kill the getters on new HTML*Collections?
# [21:21] <Hixie> i assume you mean the callers
# [21:21] <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.
# [21:21] <Hixie> not the fetters
# [21:21] <Hixie> getters
# [21:21] <jgraham> Yeah, callers
# [21:21] <jgraham> Sorry
# [21:21] <Hixie> because killing the getters doesn't sound even remotely plausible :-P
# [21:21] <Hixie> i dunno, don't pages depend on this? IE does it right?
# [21:21] <jgraham> No, that would be stupid and insane :)
# [21:21] <jgraham> IE does it for the ones it implements yeah
# [21:22] <jgraham> I was hoping that at least for the new ones we could do better
# [21:22] <Hixie> well it seems pretty harmless to me, so consistency seems worth it
# [21:22] <jgraham> It would be inconsistent but the best thing would be to never use them anywhere
# [21:22] <JonathanNeal> but injecting nodes makes Firefox hate the selection.
# [21:22] <Hixie> but you know the drill, i'll follow the browsers, basically
# [21:22] <Hixie> so if browsers don't do it, i'll remove it
# [21:22] <jgraham> It's not really harmless, there's a ton of undefined edge cases
# [21:22] <Hixie> oh?
# [21:23] <Hixie> like what?
# [21:23] <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
# [21:23] <jgraham> Like if you have callers for multiple types and pass in an object that can be coerced to more than one type
# [21:24] <jgraham> e.g. {valueOf:2, toString:"foo"}
# [21:24] <jgraham> It's not clear which order you should try the callers in
# [21:24] <Hixie> doesn't webidl define that?
# [21:25] <jgraham> No, it leaves it explicitly undefined afaict
# [21:25] <Hixie> surely we need to define that for overloading in general
# [21:25] <jgraham> In this case it is totally differnet underlying functions that get called
# [21:26] * Quits: hij1nx (~hij1nx@207.239.107.3) (Quit: hij1nx)
# [21:26] <jgraham> so it's not like normal overloading where it is one function with multipleargument types
# [21:26] <Hixie> even if it's one function with multiple argument types, the order has to be defines
# [21:26] <Hixie> since |2| and "foo" aren't the same thing
# [21:26] <jgraham> I think it is in that case
# [21:26] * Quits: sicking (~chatzilla@2620:101:8003:200:226:bbff:fe05:3fe1) (Ping timeout: 255 seconds)
# [21:26] <Hixie> oh well why is this different?
# [21:26] <jgraham> But not for the case where it is multiple functions
# [21:26] <Hixie> we should use the same overloading algorithm
# [21:27] <jgraham> It *could* be defined by WebIDL
# [21:27] <jgraham> But in any case it seems sad to keep propogating the bad pattern into new APIs
# [21:28] <jgraham> Where indexing and calling are synonyms
# [21:28] <jgraham> s/indexing/getting properties/
# [21:29] <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)
# [21:29] <JonathanNeal> AryehGregor: thanks so much for your input and help so far.
# [21:29] <jgraham> (which is not such a great argument)
# [21:29] <jgraham> (but still)
# [21:29] <Hixie> well like i said
# [21:30] <Hixie> back compat is the motivation
# [21:30] <AryehGregor> JonathanNeal, no problem.
# [21:30] <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
# [21:31] <Ms2ger> How about you drop support :)
# [21:32] <jgraham> Ms2ger: That's the buy-in I won't get for old APIs :)
# [21:32] <Hixie> jgraham: do file a bug on webidl or html if there are undefined bits though. we shouldn't have undefined stuff.
# [21:32] <Ms2ger> Pff, I've removed enough stuff without waiting or buy-in
# [21:33] <Hixie> jgraham: this one sounds pretty straightforward though
# [21:33] <jgraham> Ms2ger: Well I could probably change the code, but I wouldn't get it through review :)
# [21:33] <Ms2ger> How about you hire sicking? :)
# [21:33] <JonathanNeal> AryehGregor: does getSelection support a reverse selection?
# [21:34] <AryehGregor> JonathanNeal, what do you mean by reverse?
# [21:34] <Hixie> what WebIDL type is an interface object?
# [21:34] <Hixie> Object?
# [21:34] <jgraham> Ms2ger: Seems like quite the roundabout solution :)
# [21:34] <JonathanNeal> AryehGregor: where the carest finished at the earlier point.
# [21:34] <JonathanNeal> *caret
# [21:34] <jgraham> Either Object or Function I guess
# [21:34] <jgraham> I don't remember which way that went
# [21:34] <AryehGregor> JonathanNeal, in Firefox and WebKit, yes. In IE9, no.
# [21:35] <AryehGregor> Check whether the focusNode/focusOffset matches the start or end of the first range.
# [21:35] <JonathanNeal> `ipsu|2|m dolar si|1|t` where |1| was the starting point and |2| was the ending point.
# [21:36] <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.
# [21:36] * Quits: ezoe (~ezoe@61-205-124-213f1.kyt1.eonet.ne.jp) (Ping timeout: 255 seconds)
# [21:37] * Joins: MikeSmith_ (~MikeSmith@EM114-48-184-78.pool.e-mobile.ne.jp)
# [21:38] * Joins: Akilo (~kristof@89-159-215-142.rev.numericable.fr)
# [21:38] * Joins: matijsb (~matijsb@5353CD69.cm-6-4d.dynamic.ziggo.nl)
# [21:39] <JonathanNeal> Oi, I hope it's not a lot of code just to check which way my selection is going.
# [21:40] * Quits: MikeSmith (~MikeSmith@EM111-188-37-103.pool.e-mobile.ne.jp) (Ping timeout: 246 seconds)
# [21:40] * Quits: MikeSmith_ (~MikeSmith@EM114-48-184-78.pool.e-mobile.ne.jp) (Read error: Connection reset by peer)
# [21:40] * Joins: MikeSmith (~MikeSmith@EM114-48-184-78.pool.e-mobile.ne.jp)
# [21:47] <JonathanNeal> I guess it is as easy as `ltr = selection.anchorNode == selectionRange.startContainer && selection.anchorOffset == selectionRange.startOffset;`
# [21:55] * Quits: oknoway (~oknoway@173-8-201-137-Oregon.hfc.comcastbusiness.net) (Quit: oknoway)
# [21:58] * Joins: stevela_ (~stevela@74.125.59.1)
# [22:00] * Joins: sicking (~chatzilla@2620:101:8003:200:226:bbff:fe05:3fe1)
# [22:02] * Joins: zdobersek1 (~zan@90.157.247.80)
# [22:02] <kling> Ms2ger: ping, did you take over the canvas test suite?
# [22:02] <Ms2ger> Still Philip`
# [22:02] <kling> righto :)
# [22:03] <Ms2ger> Anything in particular?
# [22:03] * Quits: CvP (CvP@180.234.104.105) (Quit: [ UPP ] > all)
# [22:03] * Quits: zdobersek (~zan@cpe-46-164-27-101.dynamic.amis.net) (Ping timeout: 240 seconds)
# [22:04] <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
# [22:05] <kling> Ms2ger: when passing a string or null as the first argument to createPattern()
# [22:05] <Ms2ger> Which test?
# [22:06] <kling> Ms2ger: 2d.pattern.image.null.html
# [22:08] * Quits: kor (~kor@ip146-53-210-87.adsl2.static.versatel.nl) (Quit: kor)
# [22:08] <kling> Ms2ger: nevermind the string part, i see philip already fixed that in 56:465ada6e6262, so just null :)
# [22:09] <Ms2ger> Actually, WebIDL just changed, and we do want a TypeError there
# [22:09] <Ms2ger> Care to file a bug?
# [22:09] <kling> Ms2ger: sure. for html5, you mean?
# [22:10] <Ms2ger> On the test suite
# [22:10] <kling> Ms2ger: TYPE_MISMATCH_ERR is explicitly specified in html5, though. that's the confusing part
# [22:10] <Hixie> i can change the html spec if it's wrong
# [22:11] <Ms2ger> Hixie, that's the bug you called the definition of not urgent :)
# [22:11] <kling> :D
# [22:11] <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
# [22:11] <Hixie> right now the spec that's wrong is webidl :-P
# [22:11] <Hixie> because it changed the meaning of all the idl in the html spec :-P
# [22:12] <Hixie> you should assume every single object type in idls in HTML has a "?" after it until webidl is fixed
# [22:12] <Ms2ger> That's what you get for normatively referencing unstable drafts :)
# [22:13] <Hixie> ain't no such thing as a "stable" draft
# [22:13] <Hixie> q.v. SVG referencing CSS2 REC
# [22:13] <kling> where is the webidl version control? :$
# [22:13] <Ms2ger> dev.w3.org
# [22:14] <kling> righto. i'll file a bug for the test suite, then. thank you gentlemen
# [22:14] * Quits: matijsb (~matijsb@5353CD69.cm-6-4d.dynamic.ziggo.nl) (Quit: Leaving.)
# [22:17] <Hixie> does IE support ArrayBuffer?
# [22:18] <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
# [22:18] <hsivonen> Hixie: btw, if ArrayBuffers are de facto becoming little-endian, wy annoy people by making Web Socket ArrayBuffers big endian?
# [22:18] <Hixie> can anyone find any other results?
# [22:19] <Hixie> hsivonen: websocket data comes from the network, which is big endian
# [22:19] <Hixie> hsivonen: also, arraybuffers aren't defacto little endian, they're whatever the platform gpu uses
# [22:19] <hsivonen> Hixie: not if the other end sends little-endian
# [22:19] <Hixie> hsivonen: so big endian on arm, little endian on intel
# [22:19] <Hixie> as i understand it
# [22:19] <hsivonen> Hixie: I thought ARM was little-endian as well
# [22:20] <Hixie> it's configurable
# [22:20] <Hixie> but as i understand it it is usually big-endian
# [22:20] <Hixie> i could be wrong
# [22:20] <AryehGregor> ARM is usually little-endian, AFAIK.
# [22:20] <Hixie> in any case, the webgl api only works if it matches the gpu
# [22:20] <AryehGregor> I remember looking it up once and finding out that the iPhone is little-endian.
# [22:20] <AryehGregor> Also, a while back someone here said that ARM is de facto little-endian these days.
# [22:21] <Hixie> (the test above has nothing to do with endianness, btw)
# [22:22] <hsivonen> Hixie: I believe Maemo on ARM is little-endian
# [22:22] <hsivonen> Hixie: I'd be very surprised if Android was big-endian
# [22:22] <zewt> ... websocket data is big-endian? why? heh
# [22:22] <Hixie> i would assume android is endianness-neutral
# [22:22] * Quits: Akilo (~kristof@89-159-215-142.rev.numericable.fr) (Ping timeout: 240 seconds)
# [22:22] <zewt> tcp headers, yeah, but payloads?
# [22:23] <zewt> (sorry, not familiar with the websocket protocol)
# [22:23] <Hixie> zewt: everything over the network is big-endian by convention. in practice it's up to the author, obviously
# [22:23] <zewt> low-level network stack headers are big-endian by convention; i've never seen any such convention for anything higher up the stack
# [22:24] <AryehGregor> Hixie, is that still the case if we restrict ourselves to things visible to web authors?
# [22:24] <AryehGregor> As opposed to implementers?
# [22:24] <zewt> granted, most higher-level, standard protocols aren't binary protocols, so the sample set is smaller
# [22:24] <Hixie> AryehGregor: not sure what you mean
# [22:25] <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.
# [22:25] <Hixie> oh this is all moot anyway, it seems. The typed array spec lets the author pick the endianess when using DataView.
# [22:25] <zewt> i think people have android running on MIPS, so i imagine android the platform can go either way
# [22:25] <Hixie> AryehGregor: i don't think i've mentioned tcp headers
# [22:26] * Joins: tantek (~tantek@2620:101:8003:200:5a55:caff:fef3:c447)
# [22:26] <AryehGregor> What do you mean by "everything over the network"?
# [22:26] * Philip` wonders how many CPU cycles the world has wasted by having every x86 CPU do loads of ntohl calls for every network packet
# [22:27] <zewt> heh i was just thinking the same thing (and concluded: probably not much, at least in recent times)
# [22:28] <Hixie> AryehGregor: it seems pretty self-explanatory?
# [22:28] <AryehGregor> Not really?
# [22:29] <Hixie> which part is confusing? everything, or network?
# [22:29] * Joins: robreact (~chatzilla@smtp1bos2.globalmediaxchange.com)
# [22:30] <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.
# [22:30] <Hixie> sure
# [22:30] <AryehGregor> So I guess I want to know what "everything" is supposed to mean, yeah.
# [22:30] <AryehGregor> Since it apparently doesn't actually mean "everything".
# [22:30] <hsivonen> Hixie: you could avoid endianness altogether in the API by giving people ArrayBuffers of bytes
# [22:30] <Hixie> i mean that the convention is that binary network protocols use big-endianness regardless of the endianness of the platforms involved.
# [22:30] <hsivonen> and making it the app programmer's problem to convert the bytes to wider types
# [22:30] <Hixie> hsivonen: that's not how ArrayBuffer works
# [22:31] <hsivonen> Hixie: how do they work? why would a buffer of bytes have endianness?
# [22:31] <Hixie> hsivonen: ArrayBuffer is opaque
# [22:31] <Hixie> hsivonen: you then create readers of different widths from the ArrayBuffer
# [22:32] <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?
# [22:32] <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.
# [22:33] <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
# [22:33] <AryehGregor> Or is this endianness not directly exposed to authors?
# [22:33] * AryehGregor isn't quite sure what's being discussed . . .
# [22:33] * Joins: ttepasse (~ttepasse@ip-109-90-161-169.unitymediagroup.de)
# [22:33] * Quits: JonathanNeal (~Jonathan@rrcs-76-79-114-213.west.biz.rr.com) (Quit: Leaving.)
# [22:34] <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.
# [22:35] <AryehGregor> Right.
# [22:36] <jgraham> Hixie: I personally expect that problem to be solved by everyone converging on LE hardware
# [22:36] <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
# [22:36] <Philip`> which I suppose isn't that bad
# [22:36] <zewt> i'd say it's closer to zero CPU cycles--when you take into account modern CPU pipelining and so on
# [22:36] * Joins: Akilo (~kristof@89-159-215-142.rev.numericable.fr)
# [22:37] <Hixie> lunch, bbl
# [22:38] <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)
# [22:39] <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
# [22:39] <zewt> if they won't get along with the rest of the civilized world, let them figure out how to deal with it. heh
# [22:40] * Quits: tantek (~tantek@2620:101:8003:200:5a55:caff:fef3:c447) (Quit: tantek)
# [22:40] <gsnedders> jgraham: MIPS is mostly LE nowadays, apart from products from one major vendor, AFAIK
# [22:42] * Philip` wonders what happened to Blefuscu in the end, and whether it provides useful insight into resolving these problems
# [22:43] <gsnedders> Itanium is almost all LE, PPC (and hence also POWER nowadays) is almost all BE
# [22:43] * heycam|away is now known as heycam
# [22:44] <gsnedders> SuperH I have no idea about in actual usage — it is almost bi-endian
# [22:45] * Quits: Akilo (~kristof@89-159-215-142.rev.numericable.fr) (Ping timeout: 258 seconds)
# [22:46] * Joins: jwalden (~waldo@2620:101:8003:200:222:68ff:fe15:af5c)
# [22:49] * Joins: vfaronov (~vasiliy@89.31.94.44)
# [22:49] * Joins: JonathanNeal (~Jonathan@76.89.240.7)
# [22:50] * Quits: zdobersek1 (~zan@90.157.247.80) (Quit: Leaving.)
# [22:53] * Quits: JonathanNeal (~Jonathan@76.89.240.7) (Client Quit)
# [23:02] * Joins: zcorpan (~zcorpan@c-8798e355.410-6-64736c14.cust.bredbandsbolaget.se)
# [23:03] * Quits: miketaylr (~miketaylr@206.217.92.186) (Quit: miketaylr)
# [23:08] * Parts: demet8 (~demet8@7.186.8.67.cfl.res.rr.com)
# [23:10] * Joins: roc (~chatzilla@203-97-204-82.dsl.clear.net.nz)
# [23:10] * Quits: matjas (~matjas@134.246-242-81.adsl-dyn.isp.belgacom.be) (Quit: Computer has gone to sleep.)
# [23:12] * Quits: robreact (~chatzilla@smtp1bos2.globalmediaxchange.com) (Ping timeout: 252 seconds)
# [23:12] * Quits: msucan (~robod@92.86.247.27) (Quit: .)
# [23:13] * Quits: simplicity- (~simpli@unaffiliated/simplicity-) (Quit: simplicity-)
# [23:15] * Quits: Necrathex (~nectop@dhcp-077-249-098-024.chello.nl) (Read error: Connection reset by peer)
# [23:16] * Joins: Necrathex (~nectop@dhcp-077-249-098-024.chello.nl)
# [23:22] * Quits: nw` (eero@heaven.unlink.org) (Read error: Operation timed out)
# [23:22] * Quits: Necrathex (~nectop@dhcp-077-249-098-024.chello.nl) (Read error: Connection reset by peer)
# [23:23] * Joins: Necrathex (~nectop@dhcp-077-249-098-024.chello.nl)
# [23:24] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [23:25] * Quits: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
# [23:26] * Joins: smaug____ (~chatzilla@cs181139127.pp.htv.fi)
# [23:26] * Joins: tantek (~tantek@2620:101:8003:200:5a55:caff:fef3:c447)
# [23:28] * Joins: nessy (~Adium@124-168-8-33.dyn.iinet.net.au)
# [23:29] * Joins: stefan-_ (~music@trir-4d0d9290.pool.mediaWays.net)
# [23:30] * Quits: Ms2ger (~Ms2ger@91.181.47.87) (Quit: nn)
# [23:42] * Quits: boaz_ (~boaz@75-150-66-249-NewEngland.hfc.comcastbusiness.net) (Quit: boaz_)
# [23:42] * jer|afk is now known as jernoble
# [23:45] * Quits: vfaronov (~vasiliy@89.31.94.44)
# [23:49] * Joins: nw` (eero@heaven.unlink.org)
# [23:50] * Joins: abarth (~abarth@nat/google/x-fgfvhnrtcicyszpw)
# [23:50] <abarth> Hixie: quick question: are you sure HTMLImageElement::crossOrigin should have a capitalized "O" ?
# [23:51] <abarth> http://www.whatwg.org/specs/web-apps/current-work/#the-img-element
# [23:51] <TabAtkins> I suspect that's a legacy of when it was called cross-origin.
# [23:51] * Quits: Necrathex (~nectop@dhcp-077-249-098-024.chello.nl) (Read error: Connection reset by peer)
# [23:51] <abarth> its consistent iwth useMap and isMap
# [23:51] <abarth> but seems slightly odd
# [23:51] <abarth> https://bugs.webkit.org/show_bug.cgi?id=61015
# [23:51] * Joins: Necrathex (~nectop@dhcp-077-249-098-024.chello.nl)
# [23:51] <abarth> now's the time to fix it if he wants it changed :)
# [23:55] * Quits: Smylers1 (~smylers@host109-157-249-110.range109-157.btcentralplus.com) (Quit: Leaving.)
# [23:56] * zcorpan notes it's also consistent with formNoValidate
# [23:57] <abarth> ok
# [23:57] <abarth> then it's probably right
# [23:57] <abarth> sorry for the noise
# [23:58] * Joins: othermaciej_ (~mjs@17.246.17.73)
# [23:59] * Joins: hij1nx (~hij1nx@cpe-66-65-124-111.nyc.res.rr.com)
# Session Close: Thu May 26 00:00:00 2011

The end :)