/irc-logs / freenode / #whatwg / 2010-07-21 / end

Options:

# Session Start: Wed Jul 21 00:00:00 2010
# Session Ident: #whatwg
# [00:00] * Quits: Smylers (~smylers@host81-151-154-200.range81-151.btcentralplus.com) (Ping timeout: 245 seconds)
# [00:01] <TabAtkins> We're arguing because Safari/Chrome treat it as just the dirtied pixels, and will probably have difficulty changing.
# [00:01] <Philip`> "pixels dirtied" seems a difficult thing to define, when you can have transparent images and shadows and antialiasing
# [00:02] <Hixie> not to mention that some of the path routines can result in conceptually near-infinite lines iirc
# [00:02] <Philip`> The clipping region is finite so that doesn't seem like a problem
# [00:04] <othermaciej> tabatkins: I believe the IE team prefers the Safari/Chrome interpretation of globalCompositeOperation
# [00:04] <Philip`> TabAtkins: Compute the bounding box of the dirtied pixels, draw the shape onto a layer of that size, draw the layer onto the canvas, then draw some conceptually transparent-black rectangles (in an efficient way) over the rest of the clipping region?
# [00:04] <othermaciej> I advised them to post about this, I do not know if they did
# [00:05] <TabAtkins> Philip`: CoreGraphics does the dirtied-pixel thing, and Skia does the same (presumably for platform compat).
# [00:06] <Philip`> TabAtkins: I don't see why it would be hard to emulate the spec behaviour
# [00:06] <TabAtkins> Philip`: The spec's definition of globalCompositeOperation requires most methods other than the defualt source-over to recompute every pixel in the canvas.
# [00:06] <Philip`> Only 4 of the methods, I think
# [00:06] <Philip`> Oh, 5
# [00:07] <Philip`> (The ones in http://philip.html5.org/tests/canvas/suite/tests/index.2d.composite.uncovered.html)
# [00:07] <TabAtkins> the two in/outs, and destinatop-atop.
# [00:07] <Philip`> In the common case (globalAlpha=1) the "recompute" is just "clear to 0"
# [00:10] * Joins: daedb_ (~daed@78-72-108-100-no178.tbcn.telia.com)
# [00:12] <TabAtkins> othermaciej: Who'd you talk to on IE, if you remember?
# [00:12] * Quits: daedb (~daed@78-72-108-100-no178.tbcn.telia.com) (Ping timeout: 240 seconds)
# [00:16] <Philip`> Oh, that's not just the common case
# [00:16] <othermaciej> tabatkins: I think they ended up posting to the canvas api list that almost no one is on
# [00:16] <Philip`> That's every case
# [00:16] <Philip`> because the alpha multiplication happens before the compositing
# [00:16] <Philip`> so I think if the composite mode is one of the 5 then you can always just clear the whole canvas before drawing onto it
# [00:17] <othermaciej> tabatkins: http://lists.w3.org/Archives/Public/public-canvas-api/2010AprJun/0046.html
# [00:17] <Philip`> which seems like it ought to be pretty trivial to implement
# [00:17] <Philip`> (unless I'm missing something important)
# [00:17] <othermaciej> they emailed us privately after that, not sure if I should say who specifically (they are sensitive about private communication at times)
# [00:20] <jamesr> othermaciej: the reply to that email on public-canvas-api appears to say that roc is switching to match safari
# [00:20] <jamesr> which presumably means the spec is also changing?
# [00:20] <othermaciej> jamesr: sounds like the spec should probably switch, then, if it says the other thing or is ambiguous
# [00:21] <Philip`> What does Safari do for http://software.hixie.ch/utilities/js/live-dom-viewer/saved/571 ?
# [00:21] * Philip` only has a Chromium on Linux which doesn't support shadows
# [00:22] <zcorpan_> Philip`: i see just an image with the cats in safari
# [00:22] <roc> jamesr: you misunderstand
# [00:22] <jamesr> i think i do, the reply doesn't make much sense
# [00:22] <roc> we have some bugs where we don't currently follow the spec
# [00:23] <roc> particularly on Mac
# [00:23] <roc> I have patches to fix those bugs so we follow the spec always
# [00:23] <jamesr> Philip`: in firefox i see odd blue stuff on the left and cats on the right. in safari i just see some cats on the right
# [00:23] <TabAtkins> Yeah, following the email in Pritchard's email suggests that the spec was revised *to the current text*, describing FF/Opera's behavior.
# [00:23] <TabAtkins> It looks like Pritchard just totally misunderstood what the IE team email was talking about.
# [00:23] <Philip`> jamesr: In Firefox it breaks because of image compositing bugs
# [00:23] <jamesr> roc: ok. the post from the microsoft fellow was suggesting that the spec be changed, and then the reply implied that you were going to change firefox
# [00:23] <roc> othermaciej is right that the IE team prefers the source-bounded (Safari/Chrome) approach
# [00:23] <jamesr> so that reply is just wrong
# [00:24] <Philip`> zcorpan_: Hmm, that seems odd
# [00:24] <Philip`> zcorpan_: What do you get if you remove the shadow lines?
# [00:24] <roc> jamesr: I actually think you're misunderstanding Charles' email, maybe
# [00:25] <jamesr> Philip`: i don't think that it is as simple as "just clear the whole canvas before drawing onto it"
# [00:25] <roc> I think Charles is just saying that the spec unambiguously defines the behavior of globalCompositeOperation, and that Firefox will change to follow the spec, which is true
# [00:25] <TabAtkins> roc: Correct, we are (though I think it's because his email was phrased very badly).
# [00:25] <roc> sure
# [00:25] <zcorpan_> Philip`: then i get half the cats as blue and a blue rectangle below it
# [00:25] * Quits: meandi (~meandi@dynadsl-080-228-79-143.ewetel.net) (Quit: Nettalk6 - www.ntalk.de)
# [00:26] <jamesr> Philip`: you would have to calculate the compositing results, stick that somewhere (in a buffer on the side presumably), clear the canvas, then put the compositing results into the canvas
# [00:26] <Philip`> jamesr: I think I should have said "just clear the whole region of the canvas which is outside the area you're drawing pixels into"
# [00:26] <roc> the main problem with the Safari/Chrome(/IE?) approach is that you would need to add to the spec a definition of what the bounds of the source actually are, in all cases
# [00:26] * Joins: ap_ (~ap@17.246.17.28)
# [00:26] <roc> and no-one has done that
# [00:26] <Philip`> jamesr: Yeah, but the buffer only needs to be the size of the dirtied pixels, not the whole canvas
# [00:26] <roc> and it doesn't seem particularly easy
# [00:26] <othermaciej> roc: would you or anyone else at Mozilla be likely to object to changing the spec to the Safari/Chrome/IE-preferred behavior (assuming it was well-defined)?
# [00:26] <jamesr> it's not consistent in safari in all cases
# [00:26] <roc> it may add considerable complexity to spec
# [00:27] <jamesr> for example, imho drawing a circle should be the same as drawing an image that contains a circle with a transparent background
# [00:27] <jamesr> currently they render differently in safari
# [00:27] * Quits: ap (~ap@2620:0:1b00:1191:226:4aff:fe14:aad6) (Read error: Operation timed out)
# [00:27] * ap_ is now known as ap
# [00:27] * Quits: Smylers1 (~smylers@host81-151-158-29.range81-151.btcentralplus.com) (Remote host closed the connection)
# [00:27] <TabAtkins> roc: Apparently, the definition is "for images [and other things drawn onto the canvas, suitably defined], dirty region is the size of the image. Everything else, it's all non-transparent pixels."
# [00:27] * Quits: ap (~ap@17.246.17.28) (Client Quit)
# [00:27] <TabAtkins> That's the definition that Safari/Chrome is using right now.
# [00:27] <Philip`> zcorpan_: Okay, that's what I see in Chromium
# [00:27] <TabAtkins> (Though the image case is dumb, for the reason that jamesr mentions.)
# [00:28] <Philip`> TabAtkins: That doesn't seem to work for shadows
# [00:28] <Philip`> If I'm not mistaken, http://software.hixie.ch/utilities/js/live-dom-viewer/saved/571 really ought to at least draw some blue where the rectangle and image and shadow overlap
# [00:28] * Quits: eighty4 (~eighty4@c-76c8e455.012-403-6c6b701.cust.bredbandsbolaget.se) (Remote host closed the connection)
# [00:28] <TabAtkins> Philip`: Maybe not - we didn't look at shadows yet.
# [00:28] * Joins: Smylers (~smylers@host81-151-158-29.range81-151.btcentralplus.com)
# [00:29] * Quits: zcorpan_ (~zcorpan@pat.se.opera.com) (Quit: zcorpan_)
# [00:29] <roc> TabAtkins: so you're saying that for the "copy" operator, for every pixel in the source with alpha > 0, the corresponding destination pixel is set to the source pixel, but for every pixel in the source with alpha == 0, the corresponding destination pixel is unchanged?
# [00:29] <roc> that sounds very strange
# [00:30] * Quits: boaz (~boaz@64.119.159.231) (Quit: boaz)
# [00:30] <TabAtkins> I think so, yeah.
# [00:30] * Quits: Rik` (~Rik`@213.41.141.234) (Remote host closed the connection)
# [00:30] <roc> that doesn't match the behavior of any graphics library I know
# [00:31] <TabAtkins> I'm not looking at it right now, but I think that's precisely what CG does.
# [00:31] <Hixie> (also sounds far less efficient than just copying the data over)
# [00:31] * TabAtkins goes to mock up that for himself to verify again.
# [00:31] <roc> it's certainly not what cairo does
# [00:31] <TabAtkins> Yeah, Cairo does all the composite operations correctly.
# [00:32] <roc> I'm also not sure what you mean by "[and other things drawn onto the canvas, suitably defined]"
# [00:34] <Philip`> TabAtkins: (I think it does copy wrong, at least in some version of Firefox on Linux)
# [00:34] <TabAtkins> roc: I mean drawing video and such on. I haven't tested video drawing, but I suspect it's treated the same as image drawing.
# [00:34] <roc> oh, you mean everything drawn with the drawImage API?
# [00:35] <roc> In general, defining exactly what the source bounds are seems rather subtle. For example if you have a stroked path, the bounds can't just be the path bounds, they have to be inflated to include the stroke, but do you just include the stroke or the interior as well? What if the stroke is dashed? You can go with your definition, weird as it is, but it won't necessarily match what authors expect
# [00:35] <roc> and it certainly won't match with what graphics libraries do, other than CG if what you say is correct
# [00:36] <TabAtkins> Okay, yeah, copy is identical to source-over in CG and Skia.
# [00:36] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 276 seconds)
# [00:37] <roc> so pixels with alpha==0 are transferred to the destination?
# [00:37] <TabAtkins> Yes.
# [00:37] <roc> phew
# [00:37] <roc> ok
# [00:37] <TabAtkins> Wait.
# [00:37] <Philip`> That's not what source-over does
# [00:38] <TabAtkins> What I mean is that if I draw a red rectangle, set composite to "copy", then draw a partially overlapping blue circle, what I get is a red rectangle overlapped by a blue circle, exactly the same as source-over.
# [00:38] <roc> othermaciej: if someone comes up with a proper definition for how source-bounded operators should behave, and that definition is simple and useful, then sure, we'd change
# [00:38] <Hixie> and if someone comes up with a proper definition for how source-bounded operators should behave, and that definition is simple and useful, i'd be happy to spec it
# [00:38] <Hixie> but so far nobody has
# [00:38] <Hixie> so...
# [00:39] <jamesr> otherwise, though, i'm not sure how we these composite operations will ever become interoperable
# [00:39] <TabAtkins> roc: Okay, yeah, alpha=0 pixels are copied over. so it is different from source-over.
# [00:39] <roc> TabAtkins: what if you fill the circle with a gradient which is completely transparent in some region, then what?
# [00:40] * Philip` still doesn't see why WebKits can't emulate the Firefox/Opera/spec behaviour easily, which would achieve interoperability
# [00:40] <roc> I refuse to believe that any graphics library would just drop the transparent region out of the source bounds
# [00:40] <TabAtkins> The difference in behavior is completely described by CG/Skia doing the composite operation correctly, but in a *local* region rather than globally.
# [00:40] <roc> TabAtkins: sure, but you need to precisely define the bounds of that local region. That is the entire issue.
# [00:41] <TabAtkins> Right.
# [00:41] <TabAtkins> Just clarifying what our behavior is. ^_^
# [00:41] <roc> Philip`: it is quite easy. I did it for the cairo CoreGraphics backend.
# [00:41] * Joins: gavin_ (~gavin@CPE001346f5db49-CM0018c0db9a8a.cpe.net.cable.rogers.com)
# [00:41] * Quits: gavin_ (~gavin@CPE001346f5db49-CM0018c0db9a8a.cpe.net.cable.rogers.com) (Changing host)
# [00:41] * Joins: gavin_ (~gavin@firefox/developer/gavin)
# [00:41] <jamesr> roc: where's the code?
# [00:42] <jamesr> othermaciej: if you want to change this in coregraphics webkit ports then we'd change the skia backend to match
# [00:43] <jamesr> of course microsoft also prefers the safari version, but they haven't proposed a tight definition of the source image bounds
# [00:43] <Hixie> jamesr: chrome could also lead the way, no need to follow apple on this :-P
# [00:43] <roc> I can accept that the source-bounded version is more intuitive for authors
# [00:44] <jamesr> yeah i find the firefox behavior bizarre honestly. if i draw a 20x20 rectangle why would all the other pixels in the canvas change
# [00:44] <TabAtkins> Hixie: We have to have the same behavior on both CG and Skia, so having Apple fix CG is just easier. ^_^
# [00:44] <roc> although, sometimes results that are "more intuitive" are actually less intuitive if you look at them closely
# [00:44] <Hixie> TabAtkins: lame :-P
# [00:44] <jamesr> TabAtkins: i'm not suggesting that someone at apple be forced to do the work, i'm wondering if that would make sense for the other folks who ship coregraphics webkit ports
# [00:44] <TabAtkins> I think the FF behavior is fine. It's just something you generally have to use backing canvases to take proper advantage of.
# [00:45] <Philip`> jamesr: The other pixels would all change because you explicitly chose a composite operation that causes pixels to change :-)
# [00:45] <TabAtkins> But backing canvases are already an established technique in <canvas> use, so that seems fine.
# [00:45] <jamesr> i also think that it's likely nobody uses these modes given how non-interoperable the existing implementations are
# [00:45] <Philip`> If you don't want that to happen, don't use those composite operations
# [00:46] <TabAtkins> It would be somewhat nice to be able to spawn off a backing canvas directly from a single <canvas> tag, rather than creating and inserting a new canvas, but that can be fixed later.
# [00:46] <roc> jamesr: my cairo-quartz code is here: https://bugzilla.mozilla.org/show_bug.cgi?id=522859
# [00:47] <roc> the actual fix hasn't landed yet
# [00:47] <roc> TabAtkins: you don't need to insert a temporary canvas anywhere
# [00:48] <TabAtkins> roc: For some uses you do. Frex, if you already have an image, and you want to draw some lines over it with, say, source-atop. You can't just set globalCompositeOperation to source-atop and start drawing lines.
# [00:48] <Hixie> TabAtkins: (why can't you just clone it?)
# [00:48] <TabAtkins> WEll, actually, with source-atop you could.
# [00:48] <roc> I mean you don't ned to insert it in the DOM
# [00:48] <roc> from an implementors point of view, the current spec wins
# [00:48] <TabAtkins> roc: Oh, for some reason I thought you needed to insert it into the document before it would work. Shrug.
# [00:50] <roc> I'm pretty sure that if we went with a source-bounded approach and nailed down exactly what the source bounds are in all cases, all but possibly one implementation/port would need significant changes
# [00:51] <jamesr> well, to implement the current spec also requires several implementations to make some changes (webkit/coregraphics webkit/skia and whatever IE has). i don't know if they would be significant in terms of code
# [00:54] <jamesr> roc: do you have a d2d backend for canvas yet in firefox?
# [00:54] <roc> yep
# [00:54] <roc> I don't know how compliant it is with this stuff
# [00:54] <roc> however
# [00:55] <roc> D2D does not really support compositing modes at all
# [00:55] <roc> you have to drop down to D3D/shaders
# [00:55] <jamesr> presumably you'll hit the same issues the IE9 team has
# [00:55] <roc> (in Gecko we don't have "canvas backends", there's just cairo which we use for everything)
# [00:56] * Quits: micheil (~micheil@124-170-55-41.dyn.iinet.net.au) (Quit: micheil)
# [00:58] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
# [00:59] <roc> jamesr: what issues are those?
# [01:00] * Joins: Rik` (~Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
# [01:01] <jamesr> well, to do something like fillRect() the most natural (to me) way to do that on a gfx card is to create a quad and draw it, using a fragment shader to implement the blending
# [01:01] * Joins: sicking (~chatzilla@nat/mozilla/x-tkgboxermoynpfgb)
# [01:02] <jamesr> but that doesn't work if you also have to do some composite operation on pixels that land outside the quad
# [01:06] * daedb_ is now known as daedb
# [01:06] <roc> that's probably why D2D doesn't support blend modes
# [01:07] <roc> the thing is, in shaders you generally don't get to read the destination pixel
# [01:07] <roc> so blend modes are a pain either way
# [01:08] <jamesr> in gl there's a set of built in blend modes that conceptually work the same way
# [01:09] * Joins: GarethAdams|Home (~GarethAda@pdpc/supporter/active/GarethAdams)
# [01:09] <roc> true
# [01:10] <roc> still
# [01:11] <roc> in your example, you can just draw a quad that fills the entire clip rect
# [01:11] <roc> anyway, just come up with the right spec and we can change
# [01:15] <jamesr> do we have any idea what modes people really want to use?
# [01:15] <TabAtkins> I doubt it. ^_^
# [01:15] <jamesr> roc: to be honest i'm not sure the safari behavior is strictly speaking better
# [01:16] <Hixie> you could pretty easily find out, just instrument the operator attribute in chrome and let it loose
# [01:16] <jamesr> that might be biased behind if(WebKit) sniffing
# [01:16] <jamesr> but that is a good idea
# [01:16] <TabAtkins> Hixie: That could easily be biased towards "wtf why is this mode different in Chrome and Firefox?" issues.
# [01:17] <TabAtkins> Though, still, maybe useful.
# [01:17] <roc> we changed 'copy' from source-bounded to source-unbounded and got one bug filed against us, for some Chrome experiemnt
# [01:17] <jamesr> if it turns out that nobody uses anything except for source-over then i'd suggest removing the other modes from the spec until someone wants to use them and then requiring that proposed modes have compatible implementations that browser vendors are happy with
# [01:18] <jamesr> it sucks to have a big matrix of modes that do not interoperate at all without any evidence that people want them
# [01:18] <roc> 'copy' is clearly used
# [01:19] * Quits: roc (~roc@121.98.230.221) (Quit: roc)
# [01:19] <TabAtkins> Hmm. 'copy' is equivalent to just clearing the canvas and then drawing onto it, right?
# [01:20] * Quits: cyphase_ (~cyphase@adsl-99-191-72-252.dsl.pltn13.sbcglobal.net) (Remote host closed the connection)
# [01:21] * Quits: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com) (Remote host closed the connection)
# [01:22] * Joins: cyphase (~cyphase@adsl-99-191-72-252.dsl.pltn13.sbcglobal.net)
# [01:30] <othermaciej> tabatkins: I think copy is equivalent to srcover on top of a 0-alpha background but not totally sure w/o doing the math
# [01:30] <TabAtkins> The spec description of 'copy' is just "draw A. B is ignored". Which seems to be precisely the same as clearing the canvas and drawing A.
# [01:30] <TabAtkins> "Display the source image instead of the destination image."
# [01:36] * Quits: oal (~oal@5.79-160-122.customer.lyse.net) (Remote host closed the connection)
# [01:36] * Joins: ako (~nya@fuld-4d00d7e3.pool.mediaWays.net)
# [01:36] * Quits: aho (~nya@fuld-4d00d377.pool.mediaWays.net) (Ping timeout: 240 seconds)
# [01:37] * Quits: dglazkov (~dglazkov@nat/google/x-mmiufarkkwidzwvi) (Ping timeout: 265 seconds)
# [01:38] <othermaciej> it just copies the pixels
# [01:38] <Hixie> TabAtkins: what's normative in that list is the Porter-Duff definitions, not the prose
# [01:39] <othermaciej> it doesn't really matter if the background is cleared
# [01:39] * Quits: erlehmann (~erlehmann@dslb-188-103-028-197.pools.arcor-ip.net) (Read error: Operation timed out)
# [01:39] * Joins: erlehmann_ (~erlehmann@dslb-092-078-142-243.pools.arcor-ip.net)
# [01:39] <jamesr> othermaciej: it does for regions outside the bounds of the source
# [01:39] * Joins: roc (~roc@203-97-204-82.dsl.clear.net.nz)
# [01:40] <jamesr> (if you have a notion of bounds of the source)
# [01:40] <TabAtkins> othermaciej: Right. I'm just saying that, if people are using 'copy', they can equivalently just clear the canvas (the usual trick is by doing a null-resize) then drawing as normal.
# [01:40] <jamesr> TabAtkins: null-resize dumps all other state
# [01:40] <jamesr> not quite the same
# [01:40] <TabAtkins> jamesr: Ah, right. Forgot about that.
# [01:41] <othermaciej> tabatkins: you might also not be copying over the whole canvas
# [01:41] <othermaciej> (or is that what the globalCompositeOperation debate is about?)
# [01:41] <jamesr> othermaciej: with copy you actually are
# [01:41] <TabAtkins> Right, when clip regions are considered.
# [01:41] <TabAtkins> othermaciej: That's what the debate is about. ^_^
# [01:41] <othermaciej> that makes copy pretty useless
# [01:41] <jamesr> a 'copy' is over the entire canvas (respecting clip region) in ffx
# [01:42] <othermaciej> one way you may want to use it is to clone chunks of a canvas to tile, or to draw an image that you know has no alpha into some region in the canvas, but that is pretty useless if it clears the whole canvas
# [01:43] <jamesr> for that you can set a clip
# [01:46] <TabAtkins> Unrelated: goddammit we need different terms for "absolute or fixed position" and "absolute or fixed position or floating".
# [01:51] <roc> actually I think coming up with a reasonable definition for source-bounded operators is easy
# [01:51] * Joins: dglazkov (~dglazkov@75-37-194-175.lightspeed.lsatca.sbcglobal.net)
# [01:52] <roc> just do it
# [01:53] <Hixie> i don't think "just do it" will pass by quality bar :-P
# [01:53] <Hixie> s/by/my/
# [01:53] * Joins: bentruyman (~bentruyma@c-71-194-42-115.hsd1.il.comcast.net)
# [01:53] <roc> that was an instruction, not proposed specification text :-)
# [01:54] <Hixie> TabAtkins: "positioned" and "out-of-flow"?
# [01:54] <TabAtkins> Hixie: "positioned" includes relpos.
# [01:54] <Hixie> oh right
# [01:55] <TabAtkins> Floats are in-flow for any layout mode except static flow. But this isn't expressed anywhere. >_<
# [01:56] <TabAtkins> (Whereas abspos/fixpos are out-of-flow for all layout modes.)
# [01:57] * Joins: estellevw (~estelle@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net)
# [01:57] <Hixie> yeah i have to admit i don't mind having to work on html5 instead of css :-P
# [01:58] <estellevw> what is the shortest valid HTML5 document?
# [01:58] <estellevw> <!DOCTYPE html><meta charset=utf-8><title>Ugliest</title><p>valid html5 file</p>
# [01:58] <estellevw> is that valid? and if so, it the meta required?
# [01:58] <TabAtkins> You don't *need* the meta.
# [01:58] <jamesr> <!DOCTYPE html>
# [01:58] <TabAtkins> Otherwise, yeah, valid.
# [01:58] <jamesr> ?
# [01:58] <TabAtkins> jamesr: No, you need a title.
# [01:58] <TabAtkins> But you don't need anything in the body.
# [01:59] <TabAtkins> So <!DOCTYPE html><title></title> is the shortest possible, iirc.
# [01:59] <estellevw> thanks
# [02:00] <Hixie> are we not counting iframe srdoc documents as HTML5 documents?
# [02:00] <TabAtkins> Probably not?
# [02:00] <TabAtkins> What requirements are dropped from @srcdoc?
# [02:00] <Hixie> because teh shortest iframe srdoc document is the empty string, but it has to be in a srcdoc="" attribute. :-)
# [02:00] <TabAtkins> Ah, kk.
# [02:00] <Hixie> doctype and title are optional in those
# [02:00] <Hixie> <!DOCTYPE html><title></title> is probably non-conforming though
# [02:00] <TabAtkins> I didn't know you'd dropped the title requirement.
# [02:01] * Quits: roc (~roc@203-97-204-82.dsl.clear.net.nz) (Read error: No route to host)
# [02:01] <Hixie> since <title> represents the document's title, and the empty string isn't a good title
# [02:01] <Hixie> and the spec says you have to use elements appropriately to be conforming
# [02:01] <Hixie> :-P
# [02:01] <TabAtkins> Valid by validator.nu. ^_^
# [02:01] <TabAtkins> I'd say the empty string is a good title for the empty document.
# [02:02] <Hixie> yeah i was thinking that as i was writing it
# [02:03] * Quits: gratz|home (~gratz@gratz.gotadsl.co.uk) (Quit: Leaving)
# [02:04] * Joins: roc (~roc@203-97-204-82.dsl.clear.net.nz)
# [02:05] <estellevw> :)
# [02:06] <TabAtkins> <!DOCTYPE html><title>This document intentionally left blank</title>
# [02:07] * Quits: karlcow (~karl@nerval.la-grange.net) (Ping timeout: 240 seconds)
# [02:07] * Quits: dglazkov (~dglazkov@75-37-194-175.lightspeed.lsatca.sbcglobal.net) (Quit: dglazkov)
# [02:09] * Quits: aroben (~aroben@unaffiliated/aroben) (Quit: aroben)
# [02:13] * Quits: estellevw (~estelle@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net) (Quit: estellevw)
# [02:14] * Quits: cardona507 (~cardona50@c-24-130-129-16.hsd1.ca.comcast.net) (Quit: zzzzz)
# [02:15] * Joins: Lelu (~Is@unaffiliated/sirjoker)
# [02:16] * Joins: dglazkov (~dglazkov@75-37-194-175.lightspeed.lsatca.sbcglobal.net)
# [02:19] * Parts: Lelu (~Is@unaffiliated/sirjoker)
# [02:21] * Joins: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
# [02:21] * Joins: wakaba_0 (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
# [02:25] * Joins: wakaba_1 (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
# [02:25] * Joins: wakaba_2 (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
# [02:25] * Quits: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
# [02:26] * Quits: wakaba_0 (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
# [02:27] * Quits: dglazkov (~dglazkov@75-37-194-175.lightspeed.lsatca.sbcglobal.net) (Quit: dglazkov)
# [02:28] * Joins: yutak_home (~kee@U017209.ppp.dion.ne.jp)
# [02:32] * Joins: kennyluck_ (~kennyluck@EM114-48-36-112.pool.e-mobile.ne.jp)
# [02:35] * Quits: kennyluck (~kennyluck@EM111-188-32-100.pool.e-mobile.ne.jp) (Ping timeout: 240 seconds)
# [02:35] * kennyluck_ is now known as kennyluck
# [02:35] * Quits: bobchao (~cctw@112.105.101.98) (Quit: Leaving.)
# [02:35] * Joins: bobchao (~cctw@112.105.101.98)
# [02:38] * Joins: karlcow (~karl@nerval.la-grange.net)
# [02:39] * Quits: deepthawtz (~deepthawt@c-24-130-129-16.hsd1.ca.comcast.net) (Remote host closed the connection)
# [02:45] * Quits: jlebar (~jlebar@nat/mozilla/x-bfpxlamhummpukhg) (Quit: Leaving)
# [02:48] * Quits: kennyluck (~kennyluck@EM114-48-36-112.pool.e-mobile.ne.jp) (Ping timeout: 265 seconds)
# [02:52] * Joins: nicktick (debian-tor@gateway/tor-sasl/nicktick)
# [02:56] * Quits: bobchao (~cctw@112.105.101.98) (Quit: Leaving.)
# [03:03] * Quits: yutak_home (~kee@U017209.ppp.dion.ne.jp) (Quit: Ex-Chat)
# [03:03] * Quits: FireFly (~firefly@unaffiliated/firefly) (Quit: swatted to death)
# [03:17] * Quits: sicking (~chatzilla@nat/mozilla/x-tkgboxermoynpfgb) (Ping timeout: 276 seconds)
# [03:21] * Quits: jwalden (~waldo@adsl-70-131-107-7.dsl.emhril.sbcglobal.net) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.2.4/20100622203044])
# [03:25] * Quits: jamesr (~jamesr@nat/google/x-zntwzaltphwnuiyg) (Quit: jamesr)
# [03:28] * Quits: wakaba_2 (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
# [03:28] * Quits: wakaba_1 (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
# [03:29] * Joins: wakaba_ (~wakaba_@203-140-90-184.eonet.ne.jp)
# [03:29] * Joins: wakaba_0 (~wakaba_@203-140-90-184.eonet.ne.jp)
# [03:36] <AryehGregor> If you have a File object, can you slice it up into multiple Blobs if you want to fiddle with it and don't want the whole thing to be in memory at once?
# [03:36] * Joins: jamesr (~jamesr@nat/google/x-ruqtncxyrebtmyej)
# [03:39] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 240 seconds)
# [03:42] * Joins: gavin_ (~gavin@firefox/developer/gavin)
# [03:43] * Quits: dave_levin (~dave_levi@74.125.59.73) (Quit: dave_levin)
# [03:47] * Quits: weinig (~weinig@2620:0:1b00:1191:223:32ff:feaf:7f36) (Quit: weinig)
# [04:01] * Joins: erlehmann__ (~erlehmann@dslb-188-102-048-076.pools.arcor-ip.net)
# [04:04] * Quits: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de) (Quit: ⌘Q)
# [04:05] * Quits: erlehmann_ (~erlehmann@dslb-092-078-142-243.pools.arcor-ip.net) (Ping timeout: 264 seconds)
# [04:18] * Joins: estellevw (~estelle@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net)
# [04:21] * Quits: othermaciej (~mjs@17.246.16.89) (Quit: othermaciej)
# [04:27] * Joins: bobchao (~cctw@DHCP-21061.iis.sinica.edu.tw)
# [04:29] * Joins: justicefries (~gerred@c-67-173-239-97.hsd1.co.comcast.net)
# [04:30] * Joins: kennyluck (~kennyluck@133.27.228.170)
# [04:38] * Quits: justicefries (~gerred@c-67-173-239-97.hsd1.co.comcast.net) (Quit: justicefries)
# [04:38] * Joins: miketaylr (~miketaylr@24.42.95.108)
# [04:43] * Joins: m_W (~mwilcox56@c-68-38-230-216.hsd1.nj.comcast.net)
# [04:46] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 246 seconds)
# [04:52] * Quits: jamesr (~jamesr@nat/google/x-ruqtncxyrebtmyej) (Quit: jamesr)
# [04:53] * Joins: gavin_ (~gavin@firefox/developer/gavin)
# [04:54] * Quits: wakaba_0 (~wakaba_@203-140-90-184.eonet.ne.jp) (Quit: Leaving...)
# [04:55] * Quits: estellevw (~estelle@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net) (Quit: estellevw)
# [05:03] * Quits: MikeSmith (~MikeSmith@110.8.254.11) (Quit: Till kicked and torn and beaten out he lies, and leaves his hold and crackles, groans, and dies.)
# [05:07] * Quits: erlehmann__ (~erlehmann@dslb-188-102-048-076.pools.arcor-ip.net) (Quit: Ex-Chat)
# [05:10] * Joins: dglazkov (~dglazkov@75-37-194-175.lightspeed.lsatca.sbcglobal.net)
# [05:16] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
# [05:20] * Joins: micheil (~micheil@124-170-55-41.dyn.iinet.net.au)
# [05:25] * Joins: MikeSmith (~MikeSmith@110.8.254.11)
# [05:27] * Quits: MikeSmith (~MikeSmith@110.8.254.11) (Client Quit)
# [05:27] * Joins: MikeSmith (~MikeSmith@110.8.254.11)
# [05:34] * Quits: Heimidal (~heimidal@unaffiliated/heimidal) (Ping timeout: 240 seconds)
# [05:39] * Quits: nicktick (debian-tor@gateway/tor-sasl/nicktick) (Remote host closed the connection)
# [05:42] * Joins: Heimidal (~heimidal@unaffiliated/heimidal)
# [05:42] * Quits: dglazkov (~dglazkov@75-37-194-175.lightspeed.lsatca.sbcglobal.net) (Quit: dglazkov)
# [05:47] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 264 seconds)
# [05:48] * Joins: gavin_ (~gavin@firefox/developer/gavin)
# [05:54] * ako is now known as aho
# [06:09] * Joins: dglazkov (~dglazkov@75-37-194-175.lightspeed.lsatca.sbcglobal.net)
# [06:12] * Quits: aho (~nya@fuld-4d00d7e3.pool.mediaWays.net) (Quit: EXEC_over.METHOD_SUBLIMATION)
# [06:26] * Quits: bzed (~bzed@devel.recluse.de) (Read error: Operation timed out)
# [06:28] * Joins: bzed (~bzed@devel.recluse.de)
# [06:34] * Joins: nicktick (debian-tor@gateway/tor-sasl/nicktick)
# [06:35] <micheil> Hixie: you about?
# [06:38] <Hixie> yo
# [06:39] * Quits: MikeSmith (~MikeSmith@110.8.254.11) (Quit: Till kicked and torn and beaten out he lies, and leaves his hold and crackles, groans, and dies.)
# [06:41] <micheil> Hixie: question.. on websockets
# [06:41] <Hixie> sure
# [06:41] <micheil> if I can remember exactly what it was >_>
# [06:42] <micheil> oh, right, would it be an idea to change the client side interface to show if there was actually a problem contacting the websocket server
# [06:42] <micheil> eg, if there's a proxy in the way that allows you to load the client, but you get a 403 when you try to access the ws server
# [06:43] <micheil> so that this type of state can be handled in browser more correctly
# [06:43] <Hixie> by interface, do you mean exposing to the JS, or exposing to the user?
# [06:43] <micheil> exposing to the front-end developer
# [06:44] <micheil> so, things that could be exposed: timeout, 403 etc.
# [06:44] <micheil> but not actually expose what the error was on server
# [06:45] <micheil> just if the client can't actually connect to server
# [06:45] <micheil> and also if the client gets disconnected from server prematurely
# [06:45] <micheil> eg, on a network connection such as WiFi on an iPhone
# [06:46] <micheil> the user goes into say a tunnel, then there's no network coverage, it would be good to be able to check on the client side for this case
# [06:46] <Hixie> do you mean to the developer, or to the script the developer writes?
# [06:46] <micheil> so, really it's a case of problem between client and server connection, not a problem the server has with a connection
# [06:46] <micheil> the script the developer writes.
# [06:46] * Quits: micheil (~micheil@124-170-55-41.dyn.iinet.net.au) (Quit: micheil)
# [06:46] <Hixie> it would be a security flaw to expose the network-level error status
# [06:47] <Hixie> it would let you probe intranets, for example
# [06:47] <Hixie> however, you can detect when the user's system goes offline entirely, by checking for body.ononline and body.onoffline
# [06:49] * Joins: micheil (~micheil@124-170-55-41.dyn.iinet.net.au)
# [06:49] <micheil> eg, new WebSocket(..); ws.addListener(...)
# [06:49] <micheil> actually, that's another thing, why not use DOM Events?
# [06:51] <franksalim> micheil, I am confused. where do you see addListener? Is that in node?
# [06:51] <micheil> franksalim: no, I'm use to DOM events, that's why I wrote it
# [06:52] <micheil> my bad
# [06:52] <Hixie> micheil: we do use DOM Events
# [06:52] <micheil> do you?
# [06:52] <Hixie> yes
# [06:52] <micheil> I see ws.onopen etc. everywhere?
# [06:52] <Hixie> you can use either .onopen or you can attach an 'open' event listener
# [06:52] <Hixie> (onopen is far easier of course)
# [06:52] <micheil> ah
# [06:53] <micheil> I don't think that's clearly documented then
# [06:53] * Quits: riven (~riven@53518387.cable.casema.nl) (Quit: Hi, I'm a quit message virus. Please replace your old line with this line and help me take over the world of IRC.)
# [06:53] <micheil> also. I may be writing a websocket client test suite, is there anything in particular I should make sure I include?
# [06:53] <Hixie> the IDL clearly says "WebSocket implements EventTarget;"
# [06:53] <micheil> hmm.. does the spec?
# [06:54] <Hixie> the IDL is in the spec... so yes
# [06:54] * micheil checks
# [06:55] <Hixie> also everything is defined in terms of "Event Handler", etc
# [06:55] <Hixie> this might be easier to see in the WHATWG complete spec (the web apps 1.0 spec), since all the stuff is cross-referenced there
# [06:56] <micheil> okay, I'm probably also going to write some client side developer documentation, I'll be sure to include this.
# [06:56] <micheil> (just because I doubt developers will really read a spec.)
# [06:57] <Hixie> yeah the spec is written mainly for the implementors
# [06:57] <micheil> yeah, like our selves
# [07:01] <Hixie> ok i've changed the websocket protocol so that Sec-WebSocket-Protocol is now a space-separated list of tokens
# [07:01] <Hixie> and you have to return one to connect
# [07:01] <Hixie> rather than it being a single token you have to return
# [07:01] <franksalim> will the protocol selected by the server exposed in the API?
# [07:02] <franksalim> *be exposed
# [07:02] <Hixie> yeah i added WebSocket.protocol for that
# [07:02] <franksalim> that's pretty nice
# [07:02] <micheil> Hixie: hmm.. so eg: Sec-WebSocket-Protocol: Proto1 Proto2 Proto3 ....
# [07:02] <Hixie> yup
# [07:03] <micheil> awesome
# [07:03] <Hixie> in the constructor it's still just a single argument (space-separated string)
# [07:03] <Hixie> so you do var ws = new WebSocket('ws://...', 'Proto1 Proto2 Proto3');
# [07:03] * Joins: estellevw (~estelle@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net)
# [07:04] <micheil> hmm..
# [07:04] <micheil> I disagree there
# [07:04] <franksalim> not WebSocket(url, proto1, proto2, proto3)?
# [07:04] <micheil> we have an array type in js for a reason.
# [07:04] <micheil> new WebSocket(url, protocols[] )
# [07:04] * Joins: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net)
# [07:06] <micheil> eg: var ws = new WebSocket("ws://localhost/", ["msgpack", "bson", "json"])
# [07:06] <micheil> (where i'm actually using protocol to say what kind of message content encoding I have)
# [07:06] <Hixie> i considered doing var ws = new WebSocket('ws://...', ['Proto1', 'Proto2', 'Proto3']);
# [07:06] <micheil> why not?
# [07:06] <micheil> it makes most sense to a front-end developer
# [07:06] <Hixie> it would need changes to implementations
# [07:07] <micheil> and the current doesn't?
# [07:07] <micheil> if( Array.isArray(protocol)) { protocol = Array.prototype.join.call(protocol, " "); }
# [07:07] <Hixie> only minor ones
# [07:07] <micheil> not that hard to change.
# [07:07] <franksalim> ...and using variable arity would prevent us from adding a meaningful third parameter
# [07:08] <franksalim> but i would prefer not to have space separated strings in an API
# [07:08] <micheil> I'd say that protocol can be either a string or array type
# [07:08] <micheil> which is a perfectly decent way of declaring an API for a js interface, commonly used by developers
# [07:09] * Joins: robb1e (~robb1e@host86-161-128-62.range86-161.btcentralplus.com)
# [07:10] * Quits: robb1e (~robb1e@host86-161-128-62.range86-161.btcentralplus.com) (Client Quit)
# [07:10] <micheil> and then, if a browser doesn't support the array, then it throws an array of bad arguments
# [07:10] <micheil> * throws an error
# [07:10] <micheil> try {} catch(e) {} it, handle it appropriately / try again with string
# [07:12] <franksalim> i hope developers will list meaningful protocols or start specifying new protocols on top of json instead of just sending a format like "json"
# [07:13] <Hixie> i guess i could make it an array
# [07:13] <Hixie> is anyone using that argument yet?
# [07:13] * Quits: dglazkov (~dglazkov@75-37-194-175.lightspeed.lsatca.sbcglobal.net) (Quit: dglazkov)
# [07:13] <micheil> no, not here
# [07:13] <franksalim> Hixie, at least not widely. It is really going to be useful when there are public cross-origin websocket services, and there aren't many of those
# [07:13] <micheil> I currently don't even support it on the server-side
# [07:14] <micheil> there's actually two franksalim
# [07:14] <franksalim> two is not many :-)
# [07:14] <micheil> Pusher App and some one else.
# [07:14] <micheil> as for Pusher, I speak with the developers regularly, and they subscribe to hybi, so changes should be good.
# [07:15] <micheil> I'll try and contact the other company and get them to watch the list if they don't.
# [07:15] <Hixie> i'll prod the browser vendors, see what they say
# [07:15] <Hixie> if everyone's ok with changing, then i'm ok with it
# [07:15] <Hixie> but for such a minor thing, i'm also happy to go with a space-separated list
# [07:15] <Hixie> after all, that's what the protocol uses
# [07:16] <micheil> protocol should never influence the browser implementation.
# [07:16] <micheil> we want it easy enough for anyone to be able to write a client.
# [07:16] <micheil> servers should still be easy, but require technical knowledge
# [07:16] <micheil> reason: then you can have websockets as a service (Software as a Service anyone?)
# [07:17] <Hixie> you mean write a script that uses websockets, right? as opposed to an actual websockets client
# [07:17] <franksalim> writing a client to support one specified protocol requires technical knowledge, much less 2+ protocols and negotiation
# [07:17] <micheil> Hixie: client as in say a chat app or something.
# [07:17] <franksalim> i mean a protocol client for a protocol over websocket
# [07:17] <micheil> so, application?
# [07:18] <Hixie> right
# [07:18] <Hixie> yeah dunno what you'd call it
# [07:18] <Hixie> "script" maybe :-)
# [07:18] <franksalim> protocol client
# [07:18] <micheil> Hixie: I'll try to standardise on that from now on.
# [07:18] <franksalim> or client
# [07:18] <Hixie> subprotocol client maybe
# [07:18] * micheil hates the word "script" it sounds so "script-kiddy-ish"
# [07:18] <Hixie> "protocol client" sounds like the actual browser
# [07:18] * Quits: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net) (Quit: nimbupani)
# [07:18] <micheil> application
# [07:18] <franksalim> i'm not sure i like the term subprotocol. everything can layer on anything else
# [07:18] <micheil> that works., no?
# [07:19] <franksalim> xmpp/websocket is essentially the same protocol as xmpp/tcp
# [07:19] <Hixie> micheil: yeah that works too
# [07:19] <franksalim> Hixie, it is recursive. it is like the 'actual' browser :-)
# [07:19] <micheil> actually, interesting thing, there's a webworkers implementation in Node.js that uses WebSockets as the underlying communication medium
# [07:20] <franksalim> Hixie, it doesn't stop being a protocol just because it is in a soft layer
# [07:20] <Hixie> franksalim: yeah
# [07:20] <Hixie> franksalim: i just use "subprotocol" because it's easier to grep for in the spec :-)
# [07:20] <micheil> also, from that other day Hixie, the time for websockets is seriously now. I've currently got two job opps where websockets are wanted.
# [07:20] <Hixie> franksalim: (you'll notice i don't call it that in the protocol or the api)
# [07:20] <micheil> one from a startup, one from a large well established company
# [07:20] <franksalim> Hixie, that _should_ have also cleared up the intent of subprotocol vs. alternative upgrade framing, too
# [07:21] <franksalim> (on HyBi)
# [07:21] <Hixie> micheil: it would have been five years ago if we'd been at this stage then
# [07:21] <Hixie> micheil: there's been pent-up demand for this for years
# [07:21] <micheil> Hixie: five years ago, and I wouldn't have been here ;P
# [07:21] <Hixie> franksalim: not sure what you mean
# [07:21] <micheil> Hixie: infact.. five years, that's almost mid-webstandards movement, no?
# [07:22] <franksalim> calling it subprotocol indicates layering not alternative framing syntax, i think. there was some misunderstanding about that
# [07:22] <micheil> (not webstandards for browser, but for developers)
# [07:22] <Hixie> "webstandards movement"?
# [07:22] <Hixie> franksalim: ah, maybe
# [07:22] <franksalim> someone should write a history book :-)
# [07:22] <Hixie> franksalim: i didn't understand -- still don't understand -- many of the discussions on hybi
# [07:23] <Hixie> i get the feeling there are two very distinct desires
# [07:23] <Hixie> and yet we're working on the same protocol
# [07:24] <franksalim> at least two
# [07:24] <Hixie> yeah, maybe more
# [07:24] <franksalim> although fewer now than when half the list was talking about reverse http
# [07:25] <Hixie> i just wish that the people who aren't trying to design a trivially implementable TCP-for-browsers protocol would design their own protocol instead of trying to warp websockets to their needs
# [07:29] <micheil> Hixie: actually, there's talk in the dev community that when websockets support high bit data, people want to use them for transporting everything like images & binary data
# [07:29] <micheil> (by support, I mean, in both server and browser)
# [07:30] <Hixie> yeah
# [07:30] <Hixie> binary data over websockets should be available later this year, i expect
# [07:30] <micheil> cool
# [07:30] * micheil has his parser ready to do it, but isn't yet
# [07:31] <micheil> Hixie: do you use something like svn or git to manage the document versions for the specs?
# [07:31] <Hixie> svn
# [07:31] <Hixie> svn.whatwg.org
# [07:31] <micheil> could you publish the diffs?
# [07:31] <Hixie> svn.whatwg.org/webapps/source specifically
# [07:31] <Hixie> the repo is public
# [07:31] * Quits: dbaron (~dbaron@nat/mozilla/x-qtdqkoxdoipuntoc) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [07:31] <Hixie> you can see the differs also at http://html5.org/tools/web-apps-tracker
# [07:32] <Hixie> diffs, even
# [07:32] * Quits: estellevw (~estelle@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net) (Quit: estellevw)
# [07:32] <micheil> yeah, that's not so awesome though :P
# [07:32] * Joins: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie)
# [07:32] <Hixie> (the web-apps-tracker page is what i use, personally, rather than svn directly)
# [07:33] <micheil> Hixie: I'd go for git style patch files.
# [07:33] <franksalim> i leave for a minute, and i see you've been talking about one of my favorite things: binary data over websockets
# [07:33] <micheil> Hixie: could I have permission to actually mirror the document on github?
# [07:33] <micheil> (they have a useful git -> svn thing)
# [07:33] <micheil> or svn -> git
# [07:34] <franksalim> that's when the subprotocol aspect will be _killer_
# [07:34] <micheil> franksalim: agreed
# [07:35] <Hixie> micheil: sure, feel free to do whatever. The doc is under the license shown at the top of the WHATWG spec, which is pretty liberal.
# [07:36] <micheil> okay.
# [07:39] * Quits: jaacob (~jaacob@67.170.138.140) (Ping timeout: 260 seconds)
# [07:40] <micheil> Hixie: do you have a Github account by any chance?
# [07:40] <Hixie> no
# [07:40] * Quits: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
# [07:40] <micheil> okay
# [07:40] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
# [07:41] <micheil> Hixie: let me know if you ever create one, that way I can correctly get the attribution right
# [07:41] * Joins: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net)
# [07:41] <Hixie> k
# [07:43] <micheil> just waiting on github to import it.
# [07:43] <micheil> http://github.com/miksago/whatwg-webapps-mirror
# [07:43] * Joins: jaacob (~jaacob@67.170.138.140)
# [07:52] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 252 seconds)
# [07:53] * Joins: gavin_ (~gavin@firefox/developer/gavin)
# [07:54] * Quits: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net) (Quit: weinig)
# [08:01] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [08:12] * Quits: nicktick (debian-tor@gateway/tor-sasl/nicktick) (Remote host closed the connection)
# [08:13] * Joins: myakura (d2e8220d@gateway/web/freenode/ip.210.232.34.13)
# [08:14] * Joins: robb1e (~robb1e@host86-161-128-62.range86-161.btcentralplus.com)
# [08:18] <myakura> http://f1results.socialminds.com.br/ uses <progress> and <meter> but i don't think it uses them in a conforming way.
# [08:25] * Disconnected
# [08:26] * Attempting to rejoin channel #whatwg
# [08:26] * Rejoined channel #whatwg
# [08:26] * Topic is 'WHATWG: http://www.whatwg.org/ -- logs: http://krijnhoetmer.nl/irc-logs/ -- stats: http://gavinsharp.com/irc/whatwg.html -- Please leave your sense of logic at the door, thanks!'
# [08:26] * Set by annevk42 on Mon Oct 19 23:03:06
# [08:26] * Quits: krijnh (~krijnhoet@83.160.77.30) (Read error: Connection reset by peer)
# [08:29] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 276 seconds)
# [08:29] * Joins: gavin_ (~gavin@firefox/developer/gavin)
# [08:37] * Joins: Maurice (~ano@a80-101-46-164.adsl.xs4all.nl)
# [08:39] * Quits: Amorphous (jan@unaffiliated/amorphous) (Ping timeout: 245 seconds)
# [08:43] * Joins: baba (~sallabanc@69.50.70.12)
# [08:48] * Quits: robb1e (~robb1e@host86-161-128-62.range86-161.btcentralplus.com) (Quit: robb1e)
# [08:49] * Joins: robb1e (~robb1e@host86-161-128-62.range86-161.btcentralplus.com)
# [08:49] * Quits: robb1e (~robb1e@host86-161-128-62.range86-161.btcentralplus.com) (Client Quit)
# [08:55] * Joins: Amorphous (jan@unaffiliated/amorphous)
# [08:58] * Joins: boblet (~boblet@p47239-ipbffx02marunouchi.tokyo.ocn.ne.jp)
# [09:01] * Quits: roc (~roc@203-97-204-82.dsl.clear.net.nz) (Quit: roc)
# [09:03] * Quits: kennyluck (~kennyluck@133.27.228.170) (Quit: kennyluck)
# [09:05] * Joins: davidhund (~davidhund@78-27-27-74.dsl.alice.nl)
# [09:11] * Joins: kennyluck (~kennyluck@2001:200:1c0:2900:225:ff:fe4d:f8c7)
# [09:11] * Joins: sicking (~chatzilla@c-98-210-155-80.hsd1.ca.comcast.net)
# [09:11] <baba> omg, so html5 isn't going to be official till 2022 probably?
# [09:12] <Hixie> "official"?
# [09:12] <baba> W3 Recommendation
# [09:12] <Hixie> according to the W3C, it'll be a W3C recommendation before the end of september.
# [09:12] <baba> W3C
# [09:13] <micheil> Hixie: hmm.. "html5" vs ?
# [09:13] <Hixie> (then again, according to the W3C, it'll be in last call before the end of June 2008, and it's still not in last call there)
# [09:13] <baba> http://en.wikipedia.org/wiki/HTML5
# [09:13] <micheil> would it be an idea to give a timeline guide as to when we can start using various things under the umbrella "html5"
# [09:13] <baba> it says "Ian Hickson, editor of the HTML5 specification, expects the specification to reach the Candidate Recommendation stage during 2012, and become a W3C Recommendation in the year 2022 or later."
# [09:13] <Hixie> baba: ah, yeah, my guess is it'll be a REC around then.
# [09:14] <micheil> eg, WebSockets are available in some browsers from February 2010 onwards
# [09:14] <Hixie> baba: not sure that that's a particularly interesting milestone though
# [09:14] <Hixie> baba: REC for a Web spec at this point is basically when the technology dies
# [09:14] <baba> lol
# [09:14] * Quits: Heimidal (~heimidal@unaffiliated/heimidal) (Remote host closed the connection)
# [09:14] * Quits: kennyluck (~kennyluck@2001:200:1c0:2900:225:ff:fe4d:f8c7) (Client Quit)
# [09:14] <Hixie> that wasn't meant to be a joke :-)
# [09:14] <Hixie> specs that are useful are in active maintenance
# [09:15] <micheil> Hixie: agreed.
# [09:15] <micheil> also, I like that there may be some drive behind some specs that they are being designed based off implementation
# [09:16] <baba> Hixie, how are you/did you go about learning html5?
# [09:17] <Hixie> well i basically wrote it
# [09:17] <Hixie> so...
# [09:17] <baba> http://www.w3schools.com/html5/default.asp ?
# [09:17] <baba> what?
# [09:17] <baba> really?
# [09:17] <micheil> baba: yeah
# [09:17] <Hixie> i guess i did it the hard way
# [09:17] <baba> oh, speaking with the big boys, didn't know
# [09:17] <Hixie> :-)
# [09:17] <micheil> Hixie == Ian Hickson, the guy that writes a lot of the specs
# [09:17] <Hixie> this is where the sausage is made
# [09:17] <Hixie> well, this is where we talk about how the sausage is made
# [09:17] <Hixie> it actually gets made in emacs
# [09:18] <baba> gotcha
# [09:18] <micheil> Hixie: and where we argue about how vim is better.
# [09:18] <Hixie> pah
# [09:18] <baba> lol
# [09:18] <micheil> >_>
# [09:18] <micheil> Hixie: how.. uh.. big is that svn repo?
# [09:18] <baba> i'm waiting to graduate before i reinstall ubuntu
# [09:18] <micheil> Hixie: github's been fetching it for the past 2-3 hours, I'm sure.
# [09:18] <baba> forces me to play too much with customization
# [09:19] <Hixie> micheil: there's only a few files in there, but one of them is 4MB and has >4000 revisions
# [09:19] <micheil> or not. only 1.4hrs
# [09:19] * Joins: eighty4 (~eighty4@h-112-7.A163.corp.bahnhof.se)
# [09:19] <Hixie> and the other main one is 5MB and has the same number of revisions
# [09:19] <micheil> hmm..
# [09:19] <micheil> k, so, like, 4000x4000+4000x5000+3000
# [09:20] <micheil> so, uh, pretty damn massive.
# [09:20] <Hixie> and i wasn't even using it for the first few years :-)
# [09:20] <micheil> >_>
# [09:21] <micheil> eh' hopefully the github guys won't lynch me for doing this.
# [09:21] * Joins: kmq (~kmq@85.159.13.90)
# [09:21] * Joins: estellevw (~estelle@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net)
# [09:21] <Hixie> micheil: heh
# [09:23] * Joins: dbaron (~dbaron@c-98-234-51-190.hsd1.ca.comcast.net)
# [09:24] * Joins: nicktick (debian-tor@gateway/tor-sasl/nicktick)
# [09:24] <baba> so who forks the bill for html5 development?
# [09:25] <Hixie> depends what you mean
# [09:25] <Hixie> if you mean who pays for whatwg.org's hosting, i do
# [09:25] <Hixie> if you mean who pays for the browser vendors to implement the spec, they pay the cost themselves
# [09:26] <micheil> and if you mean who pays hixie to write them, well, Hixie ? :P
# [09:26] <Hixie> if you mean who pays us to take part in the process, well, many of us are employed by various companies, and many others are just volunteers
# [09:26] <baba> yeah, but Ian, who's compensating you for all your time developing the html5 specs
# [09:26] <Hixie> i'm a google employee
# [09:26] <baba> oh, didn't realize you still were
# [09:26] <Hixie> and they pay me to work on this pretty much fulltime
# [09:26] <micheil> but google's not the only party.
# [09:26] <Hixie> before that opera paid me about 50% time to work on this
# [09:26] <baba> guess it's to everyone's advantage to implement this
# [09:26] <Hixie> but all the browser vendors are involved, as are many other companies
# [09:26] <baba> including MS?
# [09:27] <Hixie> and other organisations
# [09:27] <Hixie> yup
# [09:27] <baba> they send someone there to slow u down?
# [09:27] <Hixie> the w3c html wg has been chaired by a microsoft person since inception
# [09:27] * Quits: miketaylr (~miketaylr@24.42.95.108) (Ping timeout: 240 seconds)
# [09:27] <micheil> while I don't do things financially, I'm an implementor of a few parts, so, I often ask questions & provide feedback
# [09:27] <Hixie> (different person then than now, and they're not the only chair, but still, it's pretty high-profile involvement for microsoft)
# [09:27] <micheil> and really, microsoft aren't slow, it's just adoption
# [09:28] <micheil> I could say Firefox and Safari are slow, because they don't support WebSockets at draft76, but that'd be stupidity.
# [09:28] <Hixie> microsoft have definitely not been responsible for any slowness in html5's development so far
# [09:29] <micheil> and without implementation, a spec doesn't really mean much
# [09:29] <baba> then why does IE always have issues
# [09:29] <baba> with even the current standards
# [09:29] * Joins: kennyluck (~kennyluck@133.27.228.170)
# [09:29] <micheil> baba: even people who aren't microsoft don't do things to standards
# [09:29] <Hixie> i gotta go to bed
# [09:29] <Hixie> nn
# [09:30] <baba> goodnight
# [09:30] <micheil> Hixie: good point, it is 3am
# [09:30] <micheil> Night'
# [09:31] <baba> didn't mean to start a MS bashing session, just curious why I always have to adjust what I do so my css or whatever works on IE
# [09:32] <micheil> baba: two words: corporate adoption
# [09:32] <micheil> IE is such that if there's anything that's a massive change, the adoption is massively slow.
# [09:33] <micheil> most government departments in australia, for instance, still use IE 6 or below
# [09:33] <micheil> because there's ghosts from the browser wars.
# [09:33] <estellevw> baba: lack of auto updating too
# [09:34] <estellevw> if IE6 autoupdated to IE7, then to IE8, we wouldn't see 4% of people still using IE6
# [09:34] <micheil> but then again, IE aren't the only ones that don't implement things correctly, for instance, Safari 5 doesn't handle the response handshake in websockets correctly
# [09:34] <micheil> iirc,.
# [09:35] <micheil> estellevw: you'd still have apps written to target IE6 which would need compleete rewrites to work on IE > 6, so, consequentially, IT admins disable automatic updates
# [09:37] <baba> hmm, good point
# [09:37] <baba> it does ask you to update though in windows
# [09:37] <baba> ...btw, is there a solution for Pasting into the browser with html5?
# [09:37] <baba> from the clipboard
# [09:38] <baba> an image
# [09:40] * Joins: zcorpan_ (~zcorpan@pat.se.opera.com)
# [09:40] <micheil> umm.. no, but you could use I think the HTML5 drag and drop (only in some browsers)
# [09:41] <micheil> morning zcorpan_
# [09:41] <baba> hmm
# [09:41] <baba> micheil, so flash is still the only solution for that?
# [09:41] <micheil> flash isn't the only solution
# [09:41] <micheil> and I'd say it's not a solution.
# [09:42] <baba> mhtml
# [09:42] * Joins: nessy (~Adium@124-168-156-153.dyn.iinet.net.au)
# [09:42] <micheil> HTML has always had the <input type="file"> for a long long time
# [09:42] <micheil> use it, it's there for a reason.
# [09:42] <baba> but how about pasting from the clipboard
# [09:42] <baba> an image from the clipboard
# [09:42] <zcorpan_> morning micheil
# [09:43] <micheil> baba: not possible.
# [09:44] <baba> because there's still no where to store the image?
# [09:44] <micheil> no
# [09:44] <micheil> think about it, if you could programatically pull something from a visitors clip board, without their permission, then you'd have a big big security problem
# [09:45] <baba> only if they choose to paste
# [09:45] <micheil> but how do you know if they are pasting?
# [09:45] <micheil> document.addEventListener("paste", fn) ?
# [09:45] <micheil> I don't think so. What are they pasting into? a textarea, a canvas element, etc
# [09:51] * Joins: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
# [09:55] * Quits: sicking (~chatzilla@c-98-210-155-80.hsd1.ca.comcast.net) (Remote host closed the connection)
# [09:55] * Quits: dbaron (~dbaron@c-98-234-51-190.hsd1.ca.comcast.net) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [09:58] <zcorpan_> Hixie: why did you ban U+0020 in subprotocol?
# [10:00] <zcorpan_> Hixie: oh, nm
# [10:00] <baba> micheil, just how you know if they are pasting text
# [10:01] <micheil> baba: well, in Mozilla code base, I can actually listen for it
# [10:01] <micheil> baba: via an API that's private to the Chrome (not accesible from pages), which is provided using a technology called XPCom
# [10:01] <micheil> it's basically a C / C++ api accessor
# [10:09] * Joins: abarth (~abarth@c-98-210-108-185.hsd1.ca.comcast.net)
# [10:14] * Quits: boblet (~boblet@p47239-ipbffx02marunouchi.tokyo.ocn.ne.jp) (Quit: boblet)
# [10:19] * Joins: foolip (~foolip@83.218.67.122)
# [10:23] * Joins: phrearch (~phrearch_@82-136-229-19.ip.telfort.nl)
# [10:23] <phrearch> hi
# [10:23] * Joins: Smylers1 (~smylers@host86-163-20-223.range86-163.btcentralplus.com)
# [10:24] * Quits: GarethAdams|Home (~GarethAda@pdpc/supporter/active/GarethAdams) (Quit: GarethAdams|Home)
# [10:25] * Quits: Smylers (~smylers@host81-151-158-29.range81-151.btcentralplus.com) (Ping timeout: 245 seconds)
# [10:26] <estellevw> when did <a> lose the ping attribute?
# [10:26] <estellevw> or was i mistaken that it was ever there?
# [10:26] * Joins: oal (~oal@5.79-160-122.customer.lyse.net)
# [10:28] <estellevw> i see it http://www.w3.org/TR/2010/WD-html5-diff-20100624/ but not http://dev.w3.org/html5/markup/a.html
# [10:31] <jgraham> estellevw: It lost it when people complained about it. It is still in the WHATWG copy though
# [10:33] <estellevw> see it http://dev.w3.org/html5/html-author/#the-a-element too. Wondering if i should file a bug.
# [10:33] * Joins: maikmerten (~maikmerte@port-92-201-94-144.dynamic.qsc.de)
# [10:34] <hsivonen> the /html-author/ doc isn't active being worked on
# [10:34] <hsivonen> I guess Lachy has been busy with other stuff
# [10:35] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
# [10:35] * Joins: payman_s (~payman@77.72.99.119)
# [10:37] <zcorpan_> yay hybi are +1ing
# [10:38] * Quits: oal (~oal@5.79-160-122.customer.lyse.net) (*.net *.split)
# [10:38] * Quits: abarth (~abarth@c-98-210-108-185.hsd1.ca.comcast.net) (*.net *.split)
# [10:38] * Quits: Necrathex (~bleptop@212-123-163-12.ip.telfort.nl) (*.net *.split)
# [10:39] * Joins: oal (~oal@5.79-160-122.customer.lyse.net)
# [10:39] * Joins: abarth (~abarth@c-98-210-108-185.hsd1.ca.comcast.net)
# [10:39] * Joins: Necrathex (~bleptop@212-123-163-12.ip.telfort.nl)
# [10:41] * Joins: mat_t (~mattomasz@91.189.88.12)
# [10:42] * Joins: ROBOd (~robod@89.123.178.63)
# [10:42] <Lachy> hsivonen, I'm waiting to be assigned time to work on that stuff
# [10:43] * Joins: Phae (~Phae@chimera.macmillan.com)
# [10:44] * Joins: homata__ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
# [10:46] * Joins: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net)
# [10:48] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 248 seconds)
# [10:50] <baba> micheil, what I meant was, how come it's not dangerous for text to be able to be pasted in, but it is for images?
# [10:50] * Joins: akamike (~akamike@94-193-106-14.zone7.bethere.co.uk)
# [10:52] * Quits: kennyluck (~kennyluck@133.27.228.170) (Quit: kennyluck)
# [10:53] * Parts: estellevw (~estelle@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net)
# [10:54] * Quits: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no) (Quit: Leaving)
# [10:57] <micheil> baba: because, text is what it's always been
# [10:58] <micheil> also, it's really quite complicated to handle any clipboard data, eg, how do you know what mime-type to show it with?
# [11:03] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
# [11:05] * Quits: myakura (d2e8220d@gateway/web/freenode/ip.210.232.34.13) (Quit: Page closed)
# [11:05] * Quits: homata__ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
# [11:06] <baba> micheil, by trial-error?
# [11:07] <micheil> too expensive to process.
# [11:08] * Joins: Lachy (~Lachlan@pat-tdc.opera.com)
# [11:08] <baba> hmm
# [11:08] <baba> how does flash do it?
# [11:12] * Quits: Rik` (~Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Remote host closed the connection)
# [11:14] <micheil> no idea.
# [11:16] <kbrosnan> http://www.adobe.com/livedocs/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00002187.html ?
# [11:16] <baba> k
# [11:16] <baba> oh wow
# [11:16] <baba> thanks kbrosnan
# [11:17] <baba> kbrosnan, question is, if there is an image in the clipboard, how does it know to paste an image
# [11:17] <baba> how does it "check"
# [11:17] <kbrosnan> no idea, just used $search_engine for flash clipboard api
# [11:19] <baba> gotcha
# [11:20] <jgraham> abarth: yt? The webkit parser tests Just Work now you have added them to the test directory. So that's fine.
# [11:20] <abarth> jgraham: cool
# [11:20] <jgraham> I don't know how to sync. What are your requirements
# [11:20] <jgraham> ?
# [11:20] <abarth> don't know
# [11:21] <abarth> the question is whether we should continue to modify those files in the webkit tree
# [11:21] <abarth> and upload them periodically
# [11:21] <abarth> or whether you want the ability to edit them in the code.google.com repo
# [11:21] <abarth> in which case we should probably make new dat files for new tests
# [11:22] <jgraham> I am happy to not touch those files if you want to edit them locally and then periodically resync
# [11:22] <abarth> ok, let's try that for a while
# [11:23] <jgraham> I am also happy if you always edit in the html5lib repository and just resync to the webkit repository when needed
# [11:23] <jgraham> But I guess that might be harder for you
# [11:24] <abarth> jgraham: yeah, that doesn't integrate with our process that well
# [11:24] <jgraham> OK
# [11:27] <hsivonen> fwiw, I edit in html5lib first and then sync to mozilla-central
# [11:27] <jgraham> (I guess the only problem is if you accidentially add buggy tests. In that case being able to make fixes fast is good.)
# [11:28] * Quits: tyoshino (~tyoshino@220.109.219.244) (Read error: Connection reset by peer)
# [11:28] <abarth> we're getting to the ned of implementing the parser, so we'll be done with these tests soon
# [11:28] * Joins: tyoshino (~tyoshino@220.109.219.244)
# [11:28] <abarth> the stuff i'm fixing now is fiddly webkit stuff that's not visible in the DOM
# [11:29] <abarth> we also need to implement ian's latest round of changes to the spec
# [11:29] * hsivonen spent the vast majority of time fixing Mochitests and Gecko stuff (as opposed to writing the parser core)
# [11:29] <jgraham> Oh yeah, spec changes are another problematic case
# [11:30] <jgraham> hsivonen: You implemented off-the-main-thread parsing at the same time, which I guess didn;t make it easier
# [11:30] <jgraham> :)
# [11:30] <hsivonen> jgraham: yeah, that, too
# [11:30] * Quits: ukai (~ukai@220.109.219.244) (Ping timeout: 240 seconds)
# [11:30] * Joins: ukai (~ukai@220.109.219.244)
# [11:30] <abarth> we're down to 80 tests that have different expectations between the new and old parser
# [11:30] <abarth> but we've been able to explain most of those differences
# [11:30] <hsivonen> a big part of the mochitest failures arose from off-the-main-thread parsing
# [11:31] <hsivonen> abarth: 80 tests makes me feel a bit better :-)
# [11:31] <abarth> well, we used to fail some 15k tests
# [11:31] <abarth> so it's a big improvement :)
# [11:32] <abarth> hsivonen: i don't really understand off the main thread parsing
# [11:32] <hsivonen> abarth: do you have HTML5-compliant about:blank timing?
# [11:32] <abarth> dunno
# [11:32] <abarth> probably not
# [11:33] <hsivonen> I postponed that to after Firefox 4.0
# [11:33] <abarth> how does one test taht?
# [11:33] <hsivonen> so Gecko's about:blank currently isn't compliant
# [11:33] <abarth> the problem with working on the parser is you need to decide where to stop implementing the spec
# [11:33] <abarth> because, in principle, you could do the whole thing from that foundation
# [11:33] <hsivonen> abarth: you poke the document of an iframe or of a window.open()ed window at various points in time to see what's there
# [11:34] <abarth> oh, i'm sure that's not right
# [11:34] <abarth> that stuff is crazy
# [11:34] <abarth> the parser runs really slowly in debug mode
# [11:34] <abarth> because we've loaded it up with so many asserts
# [11:35] <abarth> we'll probably have to take a bunch of those out
# [11:35] <abarth> which is kind of too bad
# [11:35] <hsivonen> I'm planning on putting more asserts in :-)
# [11:35] <hsivonen> currently, the Java asserts are carried over to C++, which isn't nice
# [11:37] <abarth> ok, bed time for me
# [11:38] <abarth> more triage in the morning :)
# [11:38] * abarth is now known as abarth|zZz
# [11:45] * Quits: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie) (Quit: brb)
# [11:48] * Joins: Rik` (~Rik`@213.41.141.234)
# [11:51] * Quits: nessy (~Adium@124-168-156-153.dyn.iinet.net.au) (Quit: Leaving.)
# [11:56] * Joins: homata__ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
# [11:58] <jgraham> Hmm some of these webkit tests seem to rely on scripting
# [11:58] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
# [12:01] * Quits: homata__ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Quit: Leaving...)
# [12:04] * Quits: nicktick (debian-tor@gateway/tor-sasl/nicktick) (Remote host closed the connection)
# [12:06] * Joins: mpt (~mpt@canonical/mpt)
# [12:06] * Quits: masterov (~masterov@93.153.167.74) (Quit: masterov)
# [12:09] * Joins: masterov (~masterov@93.153.167.74)
# [12:09] * Joins: boblet (~boblet@zz2004300023769bf059.userreverse.dion.ne.jp)
# [12:18] * Quits: foolip (~foolip@83.218.67.122) (Ping timeout: 240 seconds)
# [12:25] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 240 seconds)
# [12:35] * Joins: mpt (~mpt@canonical/mpt)
# [12:42] * Quits: wakaba_ (~wakaba_@203-140-90-184.eonet.ne.jp) (Ping timeout: 248 seconds)
# [12:42] * Joins: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
# [12:47] <karlcow> I wonder how many sites are sending the optional "Comment=comment" with cookies
# [12:48] * Joins: foolip (~foolip@83.218.67.122)
# [12:49] <Philip`> karlcow: Very few
# [12:50] <Philip`> and half of them are Comment=Sun+ONE+Application+Server+Session+Tracking+Cookie and the other half are Comment=1-800-Volunteer.org
# [13:03] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 240 seconds)
# [13:11] * Joins: miketaylr (~miketaylr@24.42.95.108)
# [13:15] <hsivonen> what happened to being able to request more context in the Web Apps Tracker?
# [13:17] <jgraham> hsivonen: I think anne removed it and waited to see if you complained
# [13:18] <hsivonen> I'm complaining now
# [13:19] <hsivonen> sooo...
# [13:20] <hsivonen> suppose we have <svg><foreignObject><math><u>
# [13:21] <hsivonen> the spec now says that upon <u>, you pop elements until either math or svg has been popped, switch to the secondary insertion mode and reprocess
# [13:21] <hsivonen> is that really right?
# [13:21] <hsivonen> hmm. maybe it is
# [13:22] <hsivonen> but what about <math><annotation-xml><svg><u>
# [13:22] <hsivonen> is it right in that case?
# [13:22] <hsivonen> or in <svg><svg><u>
# [13:22] <hsivonen> ?
# [13:23] <hsivonen> I can't recall why I've implemented it in another way
# [13:23] <hsivonen> but I've made it pop until the top of the stack is an HTML element
# [13:25] <zcorpan_> hsivonen: seems it's not really right in all cases
# [13:26] * Joins: aroben (~aroben@c-71-58-77-15.hsd1.pa.comcast.net)
# [13:26] * Quits: aroben (~aroben@c-71-58-77-15.hsd1.pa.comcast.net) (Changing host)
# [13:26] * Joins: aroben (~aroben@unaffiliated/aroben)
# [13:26] <zcorpan_> hsivonen: the intent was to not pop so far for e.g. <svg><foreignContent><math><u>
# [13:28] <zcorpan_> hsivonen: i guess the spec should revert that change or come up with something else that works better
# [13:28] <hsivonen> sigh. http://html5.org/tools/web-apps-tracker?from=5154&to=5155 is going to result in another unreviewable patch for sicking to review
# [13:29] * Joins: erlehmann (~erlehmann@dslb-188-102-048-076.pools.arcor-ip.net)
# [13:30] * Joins: Martijnc (~Martijnc@91.176.127.112)
# [13:30] <jgraham> hsivonen: I guess if there are bugs filing them with testcases that the revised spec should pass is the way forward
# [13:32] * Quits: boblet (~boblet@zz2004300023769bf059.userreverse.dion.ne.jp) (Quit: boblet)
# [13:32] <jgraham> This bit of the spec seems to be enormously fragile
# [13:33] <jgraham> I'm not sure if there is something to learn from that
# [13:34] * Joins: Matjas (5bb64371@gateway/web/freenode/ip.91.182.67.113)
# [13:34] <zcorpan_> hsivonen: i reopened http://www.w3.org/Bugs/Public/show_bug.cgi?id=8966
# [13:35] <Matjas> I have an input field ‘slug’ which indicates part of an URL that will be generated. I’d like to preview that URL. Which markup to use? <samp>http://domain.ext/<var>slug</var></samp>?
# [13:36] <hsivonen> zcorpan_: thanks
# [13:36] <Matjas> s/preview that URL/show a preview of that URL/
# [13:36] <hsivonen> I wonder if it still holds that reprocessing an end tag token can never cause reprocessing in the 'in foreign content' mode...
# [13:37] <Smylers1> Matjas: <var>slug</var> makes sense when you literally have the word ‘slug’ in there as a placeholder. But not for an actual slug.
# [13:37] <zcorpan_> hsivonen: maybe we could have breakout bookmarks in the stack of open elements or so?
# [13:38] <Matjas> Smylers1: I see. So as soon as it’s an actual slug, use <span> instead?
# [13:38] <Matjas> Smylers1: Or is there a better alternative?
# [13:38] <Smylers1> Why does it need anything?
# [13:39] <Smylers1> If you wish it to be styled differently from the fixed part of the URL, you could use <b>.
# [13:39] <Matjas> Smylers1: I’d like to use JS to dynamically change the preview based on the input, so I figured perhaps it would be a good idea to visually indicate the difference from the fixed URL part
# [13:39] <Smylers1> <b> sounds right then.
# [13:40] <hsivonen> zcorpan_: or maybe we should have the same scope check in this case that we have in the case where an end tags has been processed according to the rules of the secodary insertion mode
# [13:40] <Smylers1> Or possibly <mark>, to highlight the part of the URL you're drawing readers' attention to.
# [13:41] <Matjas> Smylers1: Oh yes, can’t believe I forgot about <mark>!
# [13:41] <Matjas> Smylers1: And <samp> would be okay to use as a wrapper for the entire URL?
# [13:41] <Smylers1> Those both have the advantage over <span> of conveying something even to users without CSS.
# [13:41] <karlcow> Philip`: interesting thanks
# [13:42] * Quits: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Quit: Leaving...)
# [13:42] <Smylers1> I've only ever considered <samp> for output of text-based programs, but it seems OK to use here too.
# [13:42] <Smylers1> If you need anything at all there.
# [13:47] <hsivonen> it's ridiculous how much http://html5.org/tools/web-apps-tracker?from=5154&to=5155 simplifies code
# [13:55] * Quits: Matjas (5bb64371@gateway/web/freenode/ip.91.182.67.113) (Ping timeout: 252 seconds)
# [13:58] * Quits: miketaylr (~miketaylr@24.42.95.108) (Remote host closed the connection)
# [13:58] * Quits: bobchao (~cctw@DHCP-21061.iis.sinica.edu.tw) (Ping timeout: 265 seconds)
# [14:00] * Joins: davidb_ (~davidb@mozca02.ca.mozilla.com)
# [14:08] * Joins: FireFly (~firefly@unaffiliated/firefly)
# [14:09] * Joins: mpt (~mpt@canonical/mpt)
# [14:11] <jgraham> zcorpan_: Maybe it would be good to add the expected DOM trees to that comment?
# [14:16] * Joins: KaOSoFt (~maxzagato@unaffiliated/kaosoft)
# [14:17] * aroben is now known as aroben|away
# [14:19] * Joins: remysharp (~remysharp@vinov2.gotadsl.co.uk)
# [14:19] * Joins: BlurstOfTimes (~blurstoft@168.203.117.112)
# [14:19] * Quits: remysharp (~remysharp@vinov2.gotadsl.co.uk) (Remote host closed the connection)
# [14:22] * Joins: remysharp (~remysharp@vinov2.gotadsl.co.uk)
# [14:28] * Quits: bentruyman (~bentruyma@c-71-194-42-115.hsd1.il.comcast.net) (Quit: I will always love you.)
# [14:30] * Quits: KaOSoFt (~maxzagato@unaffiliated/kaosoft)
# [14:31] * Joins: KaOSoFt (~maxzagato@190.24.156.162)
# [14:31] * Quits: KaOSoFt (~maxzagato@190.24.156.162) (Changing host)
# [14:31] * Joins: KaOSoFt (~maxzagato@unaffiliated/kaosoft)
# [14:31] * Quits: jmb (~jmb@login.ecs.soton.ac.uk) (Ping timeout: 240 seconds)
# [14:36] <jgraham> """the amateur programmer requirement has been
# [14:36] <jgraham> widely rejected"""
# [14:36] <jgraham> that's news to me
# [14:36] <jgraham> (re: websockets)
# [14:37] <jgraham> Am I just not following along enough?
# [14:38] <othermaciej> lots of people said they don't like it
# [14:39] <othermaciej> I don't know if that counts as "widely rejected"
# [14:40] * Joins: jmb (~jmb@login.ecs.soton.ac.uk)
# [14:42] <hsivonen> Web specs also need to be resient against professionals who aren't careful enough
# [14:48] * aroben|away is now known as aroben
# [14:53] <jgraham> I wonder if it is worth my while saying that I believe in that requirement
# [14:54] * Joins: miketaylr (~miketaylr@38.117.156.163)
# [14:54] * Quits: zcorpan_ (~zcorpan@pat.se.opera.com) (Quit: zcorpan_)
# [14:55] * Quits: miketaylr (~miketaylr@38.117.156.163) (Remote host closed the connection)
# [14:55] * Joins: miketaylr (~miketaylr@38.117.156.163)
# [15:12] * Joins: bobchao (~cctw@112.105.101.98)
# [15:15] * Quits: mpt (~mpt@canonical/mpt) (Quit: Ex-Chat)
# [15:24] * Quits: remysharp (~remysharp@vinov2.gotadsl.co.uk) (Remote host closed the connection)
# [15:28] <jgraham> There is no reason I am missing that <!DOCTYPE potato SYSTEM 'taco"'> should parse to anything other than a DOCTYPE with name html and system id taco" is there?
# [15:29] <jgraham> s/html/potato/
# [15:30] <jgraham> These webkit tests seem to assume no public id or system id, but I think they are wrong
# [15:30] * Quits: hendry (~hendry@webconverger.org) (Ping timeout: 260 seconds)
# [15:32] <gsnedders> jgraham: Yeah, the rest is as the DOCTYPE is created (i.e., the public identifier is missing)
# [15:32] <jgraham> Yeah I think the html5lib format doesn't distinguish missing from empty string
# [15:35] * Joins: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net)
# [15:36] <hsivonen> what's the best way to search one's own tweets?
# [15:37] <jgraham> hsivonen: I thought it was a write-only medium...
# [15:37] <hsivonen> apparently inurl: on Google
# [15:39] <jgraham> Does http://search.twitter.com/advanced do what you want? I don't know if it time-limits...
# [15:40] <jgraham> (but possibly the answerr to "best" is "have a local backup that can be conveniently grepped")
# [15:41] <jgraham> That search page seems to be useless...
# [15:43] <hsivonen> jgraham: nope, it doesn't do what I want
# [15:43] <hsivonen> I wanted to find the tweet I mentioned in my latest email to the whatwg list
# [15:46] <Lachy> is there a way on twitter to extract your entire history of tweets in one long file?
# [15:47] <gsnedders> No, you can only get a three-digit number at a time
# [15:53] * Joins: wakaba (~wakaba@35.72.102.121.dy.bbexcite.jp)
# [15:54] * Joins: wakaba_ (~wakaba@35.72.102.121.dy.bbexcite.jp)
# [15:54] * Quits: wakaba_ (~wakaba@35.72.102.121.dy.bbexcite.jp) (Client Quit)
# [15:54] * Joins: hendry (~hendry@webconverger.org)
# [15:54] * Joins: smaug___ (~chatzilla@cs181150024.pp.htv.fi)
# [15:58] <Smylers1> Lachy: http://tweetbackup.com/ will do that.
# [15:58] * Joins: smaug_ (~chatzilla@cs181150024.pp.htv.fi)
# [15:59] <Smylers1> Sign up, using Twitter's oauth, then you can get an export of all your tweets in a text file (including tweets from before you signed up).
# [16:00] * Quits: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Quit: othermaciej)
# [16:01] * Joins: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net)
# [16:04] <Lachy> Smylers1, thanks. Trying it out now.
# [16:04] <Lachy> hopefully I have fewer than 3200 posts, which seems likely given my relatively infrequent usage
# [16:22] <erlehmann> „So I heard you like Ogg, so i implemented it to toll you that I haven't implemen- OH WAIT :D“
# [16:25] * Joins: plainhao (~plainhao@mail.xbiotica.com)
# [16:26] <Lachy> erlehmann, where is that quote from?
# [16:27] <erlehmann> Lachy, I invented it after reading mike shavers suggestion on the list that implementors should implement basic ogg support to determine if it is ogg to then tell that they do not support it.
# [16:30] <jgraham> A warning that you're about to open a 5MB "text" document might be
# [16:30] <jgraham> humane anyway.
# [16:30] <jgraham> (Mike Shaver)
# [16:31] <jgraham> Yeah "Warning: you appear to be reading the HTML5 spec. Are you sure you want to continue? (y/n)"
# [16:31] * Joins: doublec (~doublec@li30-216.members.linode.com)
# [16:31] * Joins: mpt (~mpt@conference/ubuntu/x-hmxavrpmvahhrcuq)
# [16:31] * Quits: mpt (~mpt@conference/ubuntu/x-hmxavrpmvahhrcuq) (Changing host)
# [16:31] * Joins: mpt (~mpt@canonical/mpt)
# [16:31] <jgraham> I guess it is strictly html rather than text, but that doesn't obviously make it better...
# [16:33] <erlehmann> jgraham, i thought that too. after all, with text/html, its major type is "text" ;)
# [16:33] * Quits: FireFly (~firefly@unaffiliated/firefly) (Quit: swatted to death)
# [16:34] * Joins: kennyluck (~kennyluck@EM114-48-72-43.pool.e-mobile.ne.jp)
# [16:35] <erlehmann> I hereby humbly suggest that "HTML5 spec" should now be abbreviated as "HTML5MB".
# [16:35] <jgraham> We could just version it according to size
# [16:35] <erlehmann> BRILLIANT
# [16:35] <jgraham> Once it reaches 6Mb it is HTML6
# [16:36] <jgraham> (cutting stuff out could be a problem of course)
# [16:36] <erlehmann> http://www.nioutaik.fr/images/galerie/brilliant.jpg
# [16:37] <jgraham> hsivonen: Do you remember what was decided about coalescing adjacent character tokens in cases like <table>a<tr></tr>b ?
# [16:38] <jgraham> Oh I found it
# [16:38] <jgraham> The spec says not to coalese
# [16:38] <jgraham> hsivonen: Do you agree with the spec? :)
# [16:39] <jgraham> (it seems that Mimefield disagrres with the spec)
# [16:39] <jgraham> *disagrees
# [16:44] <erlehmann> Mimefield. Hehe.
# [16:44] <erlehmann> The silent browser!
# [16:44] <gsnedders> All I'm saying <http://gsnedders.html5.org/html5.txt> is a number of megabytes of text
# [16:45] <jgraham> Oh, that is a horrible typo
# [16:47] <hsivonen> jgraham: it was easier to implement coalescing in all cases than to special-case something
# [16:48] <jgraham> hsivonen: That is my feeling too. But webkit appear to be implementing coaleascing
# [16:48] <hsivonen> jgraham: so I guess I disagree with the spec until someone demonstrates that this is an actual DoS-by-author-incompetence problem against Gecko
# [16:48] <hsivonen> (there are other ways to mount deliberate DoS attacks on Gecko)
# [16:48] <hsivonen> jgraham: do you mean non-coalescing?
# [16:48] <jgraham> hsivonen: Yes
# [16:48] <Philip`> What about deliberate DoS attacks on other users of the parser, e.g. the validator?
# [16:49] <hsivonen> Philip`: the validator uses SAX, so the question isn't applicable
# [16:49] <Philip`> Ah
# [16:49] <hsivonen> Philip`: and, IIRC, the Java tree builders don't coalesce, but my memory may be failing
# [16:50] <hsivonen> Coalescing in Gecko is needed, because there are discretionary flushes
# [16:50] <hsivonen> and because there's document.write
# [16:50] <hsivonen> hooray to document.write
# [16:58] * Joins: dglazkov (~dglazkov@nat/google/x-hixrgixedkmznwqf)
# [16:58] * Quits: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Quit: othermaciej)
# [16:59] * Joins: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net)
# [17:00] * Joins: weinig (~weinig@2620:0:1b00:1191:223:32ff:feaf:7f36)
# [17:00] <hsivonen> huh? so mkv doesn't have a magic within a constant amount of bytes
# [17:00] <hsivonen> that seems like a terrible design decision
# [17:01] <jgraham> hsivonen: Is the hadling of whitespace characters in the table text mode a) different from the spec and b) if so, deliberate?
# [17:02] <jgraham> It seems different to me, but I guess I could be confused
# [17:02] <jgraham> e.g. in <TABLE><center><font>a</center> <img> <tr><td></td> </tr> </table>
# [17:03] <hsivonen> jgraham: not deliberate if actually different
# [17:04] <jgraham> hsivonen: It seems to me that the spec requires hat whitespace-only text is not foster parented but only inserted into the current node
# [17:04] <jgraham> *that
# [17:05] <jgraham> Gecko seems to foster parent
# [17:05] <jgraham> But I might be missing something crucial
# [17:05] * Quits: Maurice (~ano@a80-101-46-164.adsl.xs4all.nl) (Quit: Disconnected...)
# [17:06] <erlehmann> hsivonen, i would like to see the design rationale for the webm container :/
# [17:07] <Lachy> hsivonen, MKV always has the EBML magic number in the first 4 octets. It's just the doctype that can vary slightly in position, depending on the presence of some other EBML header elements
# [17:08] <foolip> right, sniffing it is not difficult
# [17:11] * Joins: MikeSmith (~MikeSmith@EM114-48-38-123.pool.e-mobile.ne.jp)
# [17:12] <Lachy> foolip, has google changed their mind about insisting on the right mime type for webm, despite insisting to us long ago that they would only support webm with the right type?
# [17:13] <foolip> Lachy, I guess they never checked the MIME type at all, it's just used for canPlayType
# [17:13] <foolip> I tested an Ogg video with the wrong MIME type, but it's hard to imagine it's different for WebM
# [17:13] <erlehmann> weird
# [17:14] <foolip> perhaps they've fixed it in their snapshots, but I doubt that too
# [17:14] <Lachy> oh, wtf? I'm sure I mentioned that bug to them on sea otters, and I assumed they would fix it
# [17:14] <foolip> are any of the Chrome engineers actually active on the lists?
# [17:14] <foolip> It'd be easier to not have to guess
# [17:15] <foolip> or, um, test it yourself, I mean :)
# [17:19] <AryehGregor> Sea otters?
# [17:20] <AryehGregor> (also, Chrome developers are active in #chromium and #webkit, in my experience)
# [17:20] <foolip> AryehGregor, a private list prior to the public launch of WebM
# [17:20] <AryehGregor> Oh.
# [17:20] <AryehGregor> Fascinating.
# [17:23] * Quits: MikeSmith (~MikeSmith@EM114-48-38-123.pool.e-mobile.ne.jp) (Quit: Till kicked and torn and beaten out he lies, and leaves his hold and crackles, groans, and dies.)
# [17:24] * Joins: MikeSmith (~MikeSmith@EM114-48-38-123.pool.e-mobile.ne.jp)
# [17:24] <hsivonen> do Carakan and Nitro support JITting to PPC?
# [17:24] <AryehGregor> MikeSmith, is it supposed to be "crackles" or "cackles"? When I Googled it I found both, but "cackles" makes much more sense to me.
# [17:26] <MikeSmith> AryehGregor: dunno.. could be I typed it in wrong, or could be that it's ambiguous in John Clare's manuscript, and different editors transcribe it differently
# [17:26] * MikeSmith checks now
# [17:27] <MikeSmith> my Norton Anthology of Poetry has "crackles"
# [17:28] <hsivonen> looks like Carakan has PPC support
# [17:28] <MikeSmith> AryehGregor: which I like better than "cackles", even if it makes less sense
# [17:28] <MikeSmith> AryehGregor: I think Clare was in an insane asylum when he wrote that poem
# [17:29] <AryehGregor> In that case, the less sane one is probably correct, and the more sane one probably arose due to some helpful person like me assuming a copyist made a mistake.
# [17:29] <foolip> hsivonen, I doubt it produces PPC machine code, on PPC it ought to be running the interpreter only
# [17:29] * Quits: MikeSmith (~MikeSmith@EM114-48-38-123.pool.e-mobile.ne.jp) (Read error: Connection timed out)
# [17:29] <AryehGregor> (this is a general principle when reconciling variant texts, the one that makes less sense is probably correct)
# [17:29] <jgraham> hsivonen: Carakan doesn't do JIT/PPC
# [17:29] * Joins: MikeSmith (~MikeSmith@EM114-48-38-123.pool.e-mobile.ne.jp)
# [17:29] <jgraham> I wonder if V8 works at all on PPC
# [17:30] <jgraham> Because it doesn't have an interpreter
# [17:30] <foolip> it doesn't?
# [17:30] <foolip> can it run on ARM?
# [17:30] <jgraham> foolip: Yeah, they have ARM support
# [17:30] <foolip> well, that seems less insane then :)
# [17:31] <jgraham> (for people not keeping up, Carakan also has JIT-for-ARM: http://labs.opera.com/news/2010/07/21/ )
# [17:32] <MikeSmith> AryehGregor: yeah -- even with sane poets, overzealous editors have "corrected" a lot of stuff they would have been better left untampered with
# [17:32] <hsivonen> jgraham, foolip: oh, ok. Lots of misleading reporting about PPC and Carakan then
# [17:32] * Quits: kmq (~kmq@85.159.13.90) (Quit: WeeChat 0.2.6.3)
# [17:32] <jgraham> hsivonen: What are you reading?
# [17:32] <hsivonen> Nitro assembler source code doesn't appear to have PPC support
# [17:33] * Quits: karlushi (~karlushi@fw.vdl2.ca) (Ping timeout: 265 seconds)
# [17:34] <hsivonen> jgraham: C|Net
# [17:34] <hsivonen> jgraham: but looing closer, they didn't say JIT
# [17:34] <hsivonen> just put Caracan and PPC in the title
# [17:35] <hsivonen> so no one has a JS JIT for PPC?
# [17:35] <foolip> developing that would be a waste of time
# [17:35] <foolip> PPC is going away
# [17:35] <hsivonen> curiously, Nitro assembler has a MIPS back end
# [17:36] <jgraham> hsivonen: I hear MIPS is used on some devices, but I have no idea what (actually I know nothing about it)
# [17:36] * Quits: Lachy (~Lachlan@pat-tdc.opera.com) (Quit: This computer has gone to sleep)
# [17:36] <AryehGregor> Why do you care about JITing to PPC?
# [17:37] <Philip`> Maybe you want fast JavaScript in a web browser on a games console
# [17:37] * Joins: dbaron (~dbaron@c-98-234-51-190.hsd1.ca.comcast.net)
# [17:37] <AryehGregor> JIT to Cell!!!
# [17:38] <hsivonen> AryehGregor: I don't really *care*. I'm just curious.
# [17:38] <Philip`> AryehGregor: Cell is kind of just PPC plus some extra data processing units
# [17:39] <AryehGregor> Maybe everyone should JIT to LLVM and thus support everything that does. (Note: LLVM seems to be some new trendy technology, so it's appropriate for me to advocate it without understanding whether it would be remotely appropriate for this purpose)
# [17:39] * Joins: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de)
# [17:40] * Joins: pauld (~chatzilla@194.102.13.2)
# [17:41] * Quits: akamike (~akamike@94-193-106-14.zone7.bethere.co.uk) (Quit: akamike)
# [17:42] * Joins: justicefries_ (~gerred@173-14-6-4-Colorado.hfc.comcastbusiness.net)
# [17:43] * Quits: davidhund (~davidhund@78-27-27-74.dsl.alice.nl) (Quit: davidhund)
# [17:43] * Philip` supposes Opera could care, because the Wii is PPC and it'd be nice if you could play JS games in Opera on there
# [17:44] * Quits: eighty4 (~eighty4@h-112-7.A163.corp.bahnhof.se) (Remote host closed the connection)
# [17:47] * Joins: justicefries__ (~gerred@173-14-6-4-Colorado.hfc.comcastbusiness.net)
# [17:48] * Quits: justicefries_ (~gerred@173-14-6-4-Colorado.hfc.comcastbusiness.net) (Ping timeout: 240 seconds)
# [17:50] * Quits: JonathanNeal (~JonathanN@99-59-124-67.lightspeed.irvnca.sbcglobal.net) (Read error: Connection reset by peer)
# [17:55] <hsivonen> https://bugzilla.mozilla.org/show_bug.cgi?id=579846 hooray for abstraction layer violations
# [17:56] <hsivonen> Hixie: is it intentional that caching related pragmas aren't in HTML5?
# [18:01] * Joins: justicefries_ (~gerred@173-14-6-4-Colorado.hfc.comcastbusiness.net)
# [18:01] * Joins: jlebar (~jlebar@nat/mozilla/x-pjadbvlxwhxzbnxl)
# [18:02] * Quits: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Quit: othermaciej)
# [18:02] * Quits: justicefries__ (~gerred@173-14-6-4-Colorado.hfc.comcastbusiness.net) (Ping timeout: 240 seconds)
# [18:04] * Quits: justicefries_ (~gerred@173-14-6-4-Colorado.hfc.comcastbusiness.net) (Client Quit)
# [18:12] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 240 seconds)
# [18:15] * KaOSoFt is now known as AndresBotero
# [18:23] <Hixie> hsivonen: only insofar as i was trying to keep it to a mininmum. If it's compat-needed, file a bug, I'll add whatever you say is needed.
# [18:23] * Quits: pauld (~chatzilla@194.102.13.2) (Ping timeout: 245 seconds)
# [18:23] * Joins: jwalden (~waldo@adsl-70-131-107-7.dsl.emhril.sbcglobal.net)
# [18:29] * Joins: pauld (~chatzilla@194.102.13.2)
# [18:32] * Quits: Rik` (~Rik`@213.41.141.234) (Remote host closed the connection)
# [18:35] * Quits: Phae (~Phae@chimera.macmillan.com) (Quit: Leaving.)
# [18:39] * Joins: JonathanNeal (~JonathanN@rrcs-76-79-114-210.west.biz.rr.com)
# [18:39] * Quits: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de) (Quit: ⌘Q)
# [18:40] * Joins: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de)
# [18:43] * workmad3 is now known as wm3|food
# [18:45] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
# [18:45] * Joins: ap (~ap@2620:0:1b00:1191:226:4aff:fe14:aad6)
# [18:46] * Joins: boogyman (~boogy@unaffiliated/boogyman)
# [18:53] * Quits: pauld (~chatzilla@194.102.13.2) (Ping timeout: 245 seconds)
# [18:55] * Joins: Maurice (copyman@5ED573FA.cable.ziggo.nl)
# [18:58] * Quits: baba (~sallabanc@69.50.70.12) (Ping timeout: 260 seconds)
# [18:59] * Joins: dave_levin (~dave_levi@nat/google/x-wcfnteillvnpmsur)
# [19:01] * Joins: weinig_ (~weinig@17.246.19.141)
# [19:05] * Quits: weinig (~weinig@2620:0:1b00:1191:223:32ff:feaf:7f36) (Ping timeout: 276 seconds)
# [19:05] * weinig_ is now known as weinig
# [19:07] * Joins: othermaciej (~mjs@17.246.16.89)
# [19:09] * Joins: sicking (~chatzilla@nat/mozilla/x-nsbrgivqfgbzofev)
# [19:09] * Joins: ap_ (~ap@17.246.17.28)
# [19:10] * Joins: cardona507 (~cardona50@c-24-130-129-16.hsd1.ca.comcast.net)
# [19:13] * Quits: ap (~ap@2620:0:1b00:1191:226:4aff:fe14:aad6) (Ping timeout: 276 seconds)
# [19:13] * ap_ is now known as ap
# [19:15] * Joins: deepthawtz (~deepthawt@c-24-130-129-16.hsd1.ca.comcast.net)
# [19:26] * Joins: aho (~nya@fuld-4d00d439.pool.mediaWays.net)
# [19:30] <gsnedders> Yay for WebKit behavioural changes linked to Radar issues!
# [19:33] * Quits: tndH (~Rob@86.10.208.3) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.0.1/2008072406])
# [19:37] * Quits: mat_t (~mattomasz@91.189.88.12) (Quit: This computer has gone to sleep)
# [19:39] * Joins: tndH (~Rob@86.10.208.3)
# [19:42] * Joins: apucacao (~apucacao@S010600226b6dbc54.vc.shawcable.net)
# [19:43] * Quits: BlurstOfTimes (~blurstoft@168.203.117.112) (Remote host closed the connection)
# [19:43] <JonathanNeal> Unless I missed it @ http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#annotations-for-assistive-technology-products-(aria) the paragraph element <p> doesn't have an implicit aria role?
# [19:44] * Quits: weinig (~weinig@17.246.19.141) (Remote host closed the connection)
# [19:45] * Joins: weinig (~weinig@2620:0:1b00:1191:223:32ff:feaf:7f36)
# [19:47] * Joins: karlushi (~karlushi@fw.vdl2.ca)
# [19:55] * abarth|zZz is now known as abarth
# [19:59] * Quits: payman_s (~payman@77.72.99.119) (Quit: Leaving)
# [20:02] * Quits: phrearch (~phrearch_@82-136-229-19.ip.telfort.nl) (Quit: Leaving)
# [20:03] * Joins: maikmerten_ (~maikmerte@port-92-201-254-64.dynamic.qsc.de)
# [20:05] * Quits: maikmerten (~maikmerte@port-92-201-94-144.dynamic.qsc.de) (Ping timeout: 265 seconds)
# [20:14] * Quits: Peter- (~peter@5ED0FB51.cable.ziggo.nl) (Read error: Connection reset by peer)
# [20:16] * Joins: robb1e (~robb1e@host86-161-128-62.range86-161.btcentralplus.com)
# [20:18] * Quits: dbaron (~dbaron@c-98-234-51-190.hsd1.ca.comcast.net) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [20:22] * Quits: robb1e (~robb1e@host86-161-128-62.range86-161.btcentralplus.com) (Quit: robb1e)
# [20:23] * Joins: Peter- (~peter@5ED0FB51.cable.ziggo.nl)
# [20:27] <AryehGregor> Does anyone here know about the File API spec? It seems to have no way to look at pieces of a large file without loading the whole thing into memory.
# [20:27] <AryehGregor> I'm trying to figure out if 1) this is true, and 2) it's been discussed before.
# [20:31] <AryehGregor> I guess I'll just post to public-webapps.
# [20:40] * Joins: robb1e (~robb1e@86.161.128.62)
# [20:48] * Quits: erlehmann (~erlehmann@dslb-188-102-048-076.pools.arcor-ip.net) (Quit: Ex-Chat)
# [20:51] * Joins: dbaron (~dbaron@nat/mozilla/x-dlyiiioipvfdxszj)
# [20:53] * Quits: kbrosnan (~kbrosnan@ip24-250-54-36.ri.ri.cox.net) (Quit: leaving)
# [20:54] * Quits: MikeSmith (~MikeSmith@EM114-48-38-123.pool.e-mobile.ne.jp) (Ping timeout: 245 seconds)
# [20:54] * Quits: JonathanNeal (~JonathanN@rrcs-76-79-114-210.west.biz.rr.com) (Ping timeout: 258 seconds)
# [20:57] * Joins: JonathanNeal (~JonathanN@rrcs-76-79-114-210.west.biz.rr.com)
# [21:08] <JonathanNeal> <nav> still need headings, yes?
# [21:08] <jgraham> Not "needs"
# [21:08] <jgraham> But it is a section it can have a heading
# [21:08] <jgraham> Otherwise a reasonable UA would make something up
# [21:10] * Joins: boaz (~boaz@10.sub-75-193-78.myvzw.com)
# [21:10] * Joins: MikeSmith (~MikeSmith@EM114-48-139-187.pool.e-mobile.ne.jp)
# [21:11] * Quits: maikmerten_ (~maikmerte@port-92-201-254-64.dynamic.qsc.de) (Remote host closed the connection)
# [21:13] <JonathanNeal> So, it's safe to abandon a heading for a <nav>
# [21:13] <JonathanNeal> Is that written anywhere, though?
# [21:13] <AryehGregor> It's not written anywhere that you have to have a heading for a <nav>.
# [21:13] <boogyman> abandon? wtf
# [21:13] <AryehGregor> So, you can infer that you don't.
# [21:14] <boogyman> <nav> spec states that it's for some sort of page navigation, there's no reference to required pre-req encapsulation
# [21:15] <JonathanNeal> boogyman, well, the last time I asked about it, I seem to remember there being strong consensus to include it. So, I would be abandoning a previous paradigm I thought to follow.
# [21:16] * Quits: dustinbrewer (~dustinbre@99-17-42-25.lightspeed.okcbok.sbcglobal.net) (Ping timeout: 264 seconds)
# [21:16] <JonathanNeal> I just have to get over the fact that gsnedders gonna call my navigation an Untitled Section.
# [21:16] <gsnedders> JonathanNeal: Well, yeah
# [21:16] <gsnedders> I'm lazy :P
# [21:17] <gsnedders> (I was going to fix it, then I realized how much effort it would be.)
# [21:17] * Quits: plainhao (~plainhao@mail.xbiotica.com) (Quit: plainhao)
# [21:17] <boogyman> The nature of the <nav> implies it would be encapsulated by <header>, however it's not 'technically' wrong
# [21:17] <JonathanNeal> gsnedders, it is difficult to have it say something like "Navigation" if it comes from a nav?
# [21:17] * Quits: boaz (~boaz@10.sub-75-193-78.myvzw.com) (Ping timeout: 245 seconds)
# [21:18] * JonathanNeal activates gsnedders encouragement mode.
# [21:20] <gsnedders> JonathanNeal: Yes
# [21:22] * Quits: GPHemsley (~GPHemsley@pdpc/supporter/student/GPHemsley) (Ping timeout: 240 seconds)
# [21:23] * Joins: Ms2ger (~Ms2ger@91.181.0.66)
# [21:27] * Joins: GPHemsley (~GPHemsley@pdpc/supporter/student/GPHemsley)
# [21:31] * Joins: kbrosnan (~kbrosnan@ip24-250-54-36.ri.ri.cox.net)
# [21:33] <AryehGregor> I see references to being able to slice a File into Blobs.
# [21:33] <AryehGregor> Am I just missing that somewhere?
# [21:35] * Joins: jamesr (~jamesr@nat/google/x-rmcdpefmypbsfcjc)
# [21:37] * Quits: cardona507 (~cardona50@c-24-130-129-16.hsd1.ca.comcast.net) (Quit: zzzzz)
# [21:42] <AryehGregor> Bingo! http://dev.w3.org/2006/webapi/FileAPI/#dfn-slice
# [21:51] * Quits: sicking (~chatzilla@nat/mozilla/x-nsbrgivqfgbzofev) (Read error: Operation timed out)
# [21:59] * Joins: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no)
# [22:01] <gsnedders> jgraham: I'm not sure it's possible to implement LysKOM as a Thunderbird extension
# [22:01] * Joins: zcorpan_ (~zcorpan@c-879ae355.410-6-64736c14.cust.bredbandsbolaget.se)
# [22:02] * Quits: cyphase (~cyphase@adsl-99-191-72-252.dsl.pltn13.sbcglobal.net) (*.net *.split)
# [22:03] <gsnedders> "Conferences hold articles. They are represented in the protocol as a data type called Conference. Each conference has a creator, the person who created the conference, and a supervisor, a conference whose members can modify the conference. If the supervisor is a person, the members of that person's mailbox are supervisors, which in most cases is only that person."
# [22:03] <gsnedders> WTH?
# [22:05] <othermaciej> I hope most nouns in that paragraph are terms of art
# [22:05] <gsnedders> Are people conferences?
# [22:05] <gsnedders> Or how else can a supervisor be a conference and a person?
# [22:06] * Joins: cyphase (~cyphase@adsl-99-191-72-252.dsl.pltn13.sbcglobal.net)
# [22:06] <Philip`> That sounds like a typo to me
# [22:06] <Philip`> (Should be "a person whose members")
# [22:06] <jgraham> Argh
# [22:07] <Philip`> Oh, maybe not
# [22:07] <gsnedders> (For the curiour, that's from the LysKOM spec)
# [22:07] <Philip`> because then "If the supervisor is a person" wouldn't make sense
# [22:07] <jgraham> I just lost an email
# [22:07] <gsnedders> The spec also contains, "Long live FORTRAN!".
# [22:07] <jgraham> Stupid web browser
# [22:07] * Joins: aliok (55672cf2@gateway/web/freenode/ip.85.103.44.242)
# [22:07] * Philip` decides to happily not understand it
# [22:08] <jgraham> gsnedders: This is #whatwg we don't talk about legacy internet technologies that should have died years ago but mysteriously linger on here
# [22:08] <jgraham> Oh wait...
# [22:09] * Joins: cardona507 (~cardona50@c-24-130-129-16.hsd1.ca.comcast.net)
# [22:09] <aliok> HI all, can anyone point me to some document where I can learn styling Html5 date picker?
# [22:09] * Quits: davidb_ (~davidb@mozca02.ca.mozilla.com) (Quit: davidb_)
# [22:09] <jgraham> gsnedders: (FWIW I assume that the underlying model is that "everything's a conference")
# [22:10] <jgraham> (but I could be wrong)
# [22:10] <gsnedders> jgraham: This isn't mentioned in the spec
# [22:10] <jgraham> gsnedders: What isn't?
# [22:10] <gsnedders> And it's implied People are a separate type to Conference and Text-Stat
# [22:11] <zcorpan_> micheil: array won't throw. it'll just be converted to a string
# [22:11] * Quits: foolip (~foolip@83.218.67.122) (Ping timeout: 265 seconds)
# [22:12] <jgraham> gsnedders: From reading the above I would assume that People are a subtype of Conference
# [22:12] <AryehGregor> aliok, you can't, basically.
# [22:12] <jgraham> But what do I know
# [22:12] <AryehGregor> Not yet, anyway.
# [22:12] * Quits: zcorpan_ (~zcorpan@c-879ae355.410-6-64736c14.cust.bredbandsbolaget.se) (Remote host closed the connection)
# [22:12] <gsnedders> jgraham: I'd assume that if it weren't for the next section in the spec
# [22:13] <aliok> AryehGregor, thanks anyway.
# [22:14] <jgraham> gsnedders: Oh
# [22:14] <aliok> BTW, if anyone interested we're implementing Html5 enabled JSF components. A live demo is deployed at http://html5-comp-lib-showcase-snapshot.latest.aliok-com-tr-test.appspot.com/index.jsf
# [22:14] <jgraham> gsnedders: (I don't see why what you said precludes the thunderbird extension, although I am not sure how one would implement "mark all messages with the same id as read")
# [22:14] <jgraham> (maybe the feed support already does that?)
# [22:15] <gsnedders> jgraham: I don't see how you can implement a new incoming and outcoming protocol in an extension
# [22:15] <gsnedders> But maybe the docs are just bad
# [22:16] * Quits: boogyman (~boogy@unaffiliated/boogyman) (Quit: ChatZilla 0.9.86 [Firefox 3.6.6/20100625231939])
# [22:17] * Joins: BlurstOfTimes (~blurstoft@168.203.117.112)
# [22:20] <jgraham> gsnedders: jcranmer had some blog posts
# [22:20] <jgraham> They didn't implement a new protocol I guess
# [22:24] <aliok> AryehGregor, styling of those is written somehere in some spec but not implemented yet, right?
# [22:31] <jgraham> abarth, hsivonen: Filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=10221 on the text node coalescing behaviour
# [22:33] * Joins: kennyluck_ (~kennyluck@EM111-188-31-21.pool.e-mobile.ne.jp)
# [22:36] * Quits: kennyluck (~kennyluck@EM114-48-72-43.pool.e-mobile.ne.jp) (Ping timeout: 245 seconds)
# [22:36] * kennyluck_ is now known as kennyluck
# [22:40] * Joins: meandi (~meandi@dynadsl-080-228-69-213.ewetel.net)
# [22:42] * Joins: eighty4 (~eighty4@c-76c8e455.012-403-6c6b701.cust.bredbandsbolaget.se)
# [22:47] * Quits: robb1e (~robb1e@86.161.128.62) (Ping timeout: 245 seconds)
# [22:52] <jamesr> Philip`: is there any way to get the output from your canvas conformance suite in a more machine-parsable way? i want to compare the output of http://philip.html5.org/tests/canvas/suite/tests/index.2d.html between two different builds and i can't see any way to do that other than looking at all the squares
# [22:52] * Joins: robb1e (~robb1e@host86-161-128-62.range86-161.btcentralplus.com)
# [22:55] <Philip`> jamesr: If you use http://philip.html5.org/tests/canvas/suite/reportgenentry.html then it'll generate YAML code in the textarea at the bottom
# [22:55] <Philip`> The submit button won't work so don't click that
# [22:55] <Philip`> but it should be possible to diff the outputs
# [22:56] <jamesr> ok
# [22:56] <jamesr> why YAML?
# [22:56] <Philip`> Why not?
# [22:57] <Philip`> It's easy to generate and easy to read and easy to parse (given suitable libraries)
# [22:57] * Quits: BlurstOfTimes (~blurstoft@168.203.117.112) (Remote host closed the connection)
# [22:57] <jamesr> but <insert markup system here> is clearly superior!
# [22:57] <jamesr> Philip`: thanks, i think that'll do the trick
# [22:57] <Philip`> and I was already using it for writing the test cases since it's concise and human-writable
# [22:58] <Philip`> and it's complex and crazy enough to be fun
# [22:58] * Joins: FireFly (~firefly@unaffiliated/firefly)
# [22:59] * Quits: meandi (~meandi@dynadsl-080-228-69-213.ewetel.net) (Ping timeout: 245 seconds)
# [22:59] * Quits: eighty4 (~eighty4@c-76c8e455.012-403-6c6b701.cust.bredbandsbolaget.se) (Remote host closed the connection)
# [23:03] <jcranmer> gsnedders: with a bit of pain
# [23:03] <gsnedders> jcranmer: So a bit of pain there, and a lot of pain at the badly documented protocol? Nice.
# [23:03] * Quits: miketaylr (~miketaylr@38.117.156.163) (Remote host closed the connection)
# [23:04] <jcranmer> if you're doing a wire protocol, you're likely using C++ already, which is easier
# [23:04] <jcranmer> it basically lacks documentation on the receiving end
# [23:04] <gsnedders> s/$/ if you know C++/
# [23:04] <jcranmer> binary protocol stuff in JS is not fun
# [23:04] <gsnedders> I wasn't really thinking about using JS
# [23:05] <gsnedders> JS doesn't work that well for binary data
# [23:05] <jcranmer> for TB, you pretty much have a choice of JS or C++
# [23:06] <gsnedders> I know.
# [23:06] <gsnedders> I, uh, wasn't entirely convinced I wanted to implement it in TB anyway
# [23:06] <jcranmer> fortunately, it should become easier in the future
# [23:06] <gsnedders> jgraham is the once convinced of that.
# [23:06] <gsnedders> :)
# [23:06] <gsnedders> (I think a more radical UI would be better, but oh well)
# [23:07] * Joins: baba (~sallabanc@69.50.70.12)
# [23:09] <AryehGregor> aliok, I don't know if a spec even exists at this point.
# [23:09] * Quits: ROBOd (~robod@89.123.178.63) (Quit: .)
# [23:10] * Joins: kangax_ (~kangax@208.82.12.210)
# [23:16] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [23:16] * Joins: sicking (~chatzilla@nat/mozilla/x-vwxhzdltbnzahkpr)
# [23:19] * Quits: robb1e (~robb1e@host86-161-128-62.range86-161.btcentralplus.com) (Quit: robb1e)
# [23:22] * Quits: Maurice (copyman@5ED573FA.cable.ziggo.nl)
# [23:38] * Joins: eric_carlson (~ericc@2620:0:1b00:1191:223:32ff:feb1:5d30)
# [23:38] * Joins: weinig_ (~weinig@17.246.19.141)
# [23:39] * Quits: weinig (~weinig@2620:0:1b00:1191:223:32ff:feaf:7f36) (Read error: Operation timed out)
# [23:39] * weinig_ is now known as weinig
# [23:40] * Quits: franksalim (~frank@adsl-75-61-93-123.dsl.pltn13.sbcglobal.net) (Ping timeout: 276 seconds)
# [23:47] * Quits: smaug___ (~chatzilla@cs181150024.pp.htv.fi) (Quit: ChatZilla 0.9.86 [Firefox 4.0b2pre/20100719125338])
# [23:54] * Joins: ZdenekKostal (~kostal_zd@zakaznici.it-help.cz)
# [23:58] * Parts: ZdenekKostal (~kostal_zd@zakaznici.it-help.cz)
# [23:59] * Quits: eric_carlson (~ericc@2620:0:1b00:1191:223:32ff:feb1:5d30) (Quit: eric_carlson)
# [23:59] * Joins: franksalim (~frank@adsl-75-61-93-123.dsl.pltn13.sbcglobal.net)
# Session Close: Thu Jul 22 00:00:00 2010

The end :)