# [00:00] <roc> I wonder if XHR will be enough to drive deployment of AC, or we'll be stuck in a chicken-and-egg situation
# [00:03] <hsivonen> How common is it today with plug-in-based solutions that people have videos neither on same origin nor on a video-specializing site like youtube?
# [00:03] <hsivonen> I wonder how onerous it would be to put AC on Akamai-hosted Stevenotes
# [00:04] <roc> Getting this resolved is a super-high priority issue for us, by the way. We're shipping soon and if we're going to have restrictions, we need to implement them now, or we'll never be able to
# [00:05] <Hixie> i don't think <video> uptake is going to be so fast that we couldn
# [00:05] <Hixie> 't add restrictions in the next cycle
# [00:06] <roc> maybe you're right, we've already identified some sites that would break if we added same-origin restrictions right now, and that's only going to get bigger
# [00:14] <Hixie> i guess what we should do is not have cross-site restrictions for now, but when we add them to make it so that if there is AC metadata and it is negative, to block everything
# [00:14] <Hixie> allowing opt-out of all video access, and opt-in to full metadata access
# [00:14] <Hixie> defaulting to basically the current API set
# [00:15] <Hixie> but we should be prepared to block that altogether if someone comes up with an unexpected attack vector
# [00:16] <doublec> is it worth not exposing anything about the media until metadata loaded?
# [00:16] <doublec> so progress events, etc don't get fired until after that?
# [00:17] <Hixie> but if you disagree with that, or aren't comfortable with it, then implement AC, and then you'll make the de-facto decision be to have access limitations :-)
# [01:24] <Lachy> I generally don't bother wasting my time trying to read emails that have been formatted poorly
# [01:25] <Hixie> unfortunately i don't have that privilege really
# [01:28] <Hixie> Philip`: fixed set/group for you
# [01:29] <Philip`> Hixie: Thanks - you are too kind
# [01:30] <Lachy> I have too many emails to read. I've been trying to get through my whatwg folder, but given all my travelling and poor quality internet access while not at home, it's difficult to even keep the unread messages below 900 :-(
# [01:31] <Hixie> no worries, my unread is at 2677
# [04:54] <Lachy> I'm guessing Chris Wilson thinks the term vendor-lock-in is offensive in this contenxt because its companies like Microsoft that always get accused of it
# [05:05] <jwalden> always looked like a huge cesspool when I've occasionally skimmed web archives
# [05:05] <jwalden> too many people who think they can cook spoil the broth
# [05:07] <Lachy> I wonder where I should go for dinner tonight. I suppose there will be restaurants around in the casinos, if not cheaper ones elsewhere
# [05:07] <jwalden> actually, casino restaurants may be cheaper, to entice you to come in and make up their loss inside
# [10:08] <Hixie> oooh, leap second at the new year
# [10:10] * hsivonen still thinks that needing announcement-based coordination for something as fundamental as time sucks big time
# [10:11] <hsivonen> HTML5 should probably say that the system clocks are supposed to observe UTC but the calculations happen as if the numbers were UT1 times
# [10:12] <Hixie> i think what it says now is clearer
# [10:13] <Hixie> and how else would you do it? assuming that you want to keep the clocks in sync with the sun, that is
# [10:13] <tthorsen> Couldn't you just adjust the velocity and rotation of the earth?
# [10:15] <hsivonen> Hixie: I think at this point it's OK to leave sundial legacy UAs as a bit inaccurate
# [10:16] <hsivonen> for the next few thousand years timezones already cause more sundial incompatibility than strict atomic time
# [10:16] <Hixie> if you don't do this, then a few decades or centuries from now, you'll be a few hours off, and after a few thousand years, your noon will be at midnight.
# [10:17] <hsivonen> oh. last time I calculated the max drift it was a lot smaller
# [10:37] <hsivonen> Hixie: it seems to me that an hour of drift in the cultural notation over 4000 years or so is less of a problem than trying to accommodate leap seconds in software
# [10:38] <hsivonen> after all, by some accounts, the Earth is now only 6000 years old, so 4000 years is a relative long time
# [10:42] <Hixie> well, if you can convince the relevant governments to decouple their civil time from astronomical measurements, then we'll go talk to the ITU
# [10:42] <Hixie> the alternative, replacing leap seconds with leap hours, imho causes even more confusion
# [10:42] <Hixie> and is far more likely to involve painful software bugs
# [10:43] <Hixie> code that runs in production once every 4000 years is unlikely to be bug-free
# [10:52] <roc> the whole notion of simultaneity is flawed. Each processor must maintain its own local time and compensate for relative velocities when translating times into other frames of reference
# [10:53] <hsivonen> Hixie: doesn't it bother you that different pieces of software would do different conversions so if you use midnight to represent dates you get random-looking *day*-level drift?
# [10:54] <jgraham> roc: Don't forget variations in g
# [10:54] <hsivonen> Hixie: the usual practice for representing dates to the precision of a day is to store seconds from a reference point and zero the least-significant seconds
# [10:55] <Hixie> between hardware limitations (and, to a far lesser extent, relativistic, gravitational, and black-box radiation effects) and configuration errors, i doubt most consumer computers ever get anywhere near accurate enough for leap seconds to matter
# [10:55] <hsivonen> Hixie: right, so leap seconds make no sense for "civil time"
# [10:56] <hsivonen> aside, teaching people to say UTC instead of GMT is like teaching them to say URI instead of URL
# [10:56] <zcorpan> tthorsen: stray </p> means <p></p>
# [10:57] <zcorpan> tthorsen: why is it a problem?
# [10:57] <Hixie> hsivonen: civil time in many countries is legally defined in terms of astronomical state. if we're going to use SI seconds and 36400 seconds-per-day, then that breaks. so we either have to change the laws, or have leap seconds (or hours, or whatever)
# [10:57] <Hixie> jgraham: caesium atomic clocks vary in speed based on ambient temperature
# [10:58] <Hixie> jgraham: i meant blackbody radiation, my bad
# [10:58] <tthorsen> It's not really a problem for me, but I thought it was a bug in the spec. Firefox and opera usually makes empty <p> elements when they see stray </p>'s but not in this case
# [10:58] <Philip`> 36400 seconds per day would be pretty weird
# [10:59] <zcorpan> tthorsen: that's because firefox and opera don't treat <object> as scoping
# [11:07] <tthorsen> zcorpan: The thing we talked about yesterday - about ignoring cdata in select tags. Do you know whether the spec will be changed or not?
# [11:07] <jgraham> hsivonen: Per wikipedia leap seconds will be needed much more frequently in the future, although it seemes there is a plan to vote on the issue in 2011
# [11:08] <tthorsen> I that case too, it doesn't really matter if the spec changes or not, but I'd like some kind of confirmation before I go ahead and get all our tests changed.
# [11:08] <tthorsen> s/doesn't really matter/doesn't really matter to me/
# [11:08] <jgraham> tthorsen: What usually happens is that we wait for Hixie to read the feedback, he makes a judgement call and then we complain again if we think he used faulty logic :)
# [11:09] <jgraham> If it's a high priority for you then I suggest that you make him aware of that so he can schedule his priorities accordingly
# [11:10] <tthorsen> Nah, the normal procedure sounds fine to me.
# [11:11] <jgraham> (I should note that there is sometimes a multi-year delay between the feedback being recieved and it being considered in detail, although I guess the parsing section will be ouched much sooner than that)
# [11:12] <takkaria> fwiw, NetSurf (browser using Hubbub) has had no reported problems with the current HTML5 algorithm, but it has a very small number of users and no scripting support
# [11:15] <tthorsen> well, a couple of the things I mentioned were mere clarification issues. A couple of things turned out to be the intended behaviour, and not a bug, after all. So in the end we don't see a lot of real problems either.
# [11:16] <Hixie> oldest feedback still pending a reply is from unix time_t 1073954713
# [11:18] <tthorsen> takkaria: But, for instance the nested forms issue on http://bankrate.com, i think you'd be able to see in the NetSurf browser too. It's certainly very visible if you parse the html with html5lib and open it in firefox.
# [11:18] <takkaria> yeah, there's definitely something going wrong there
# [11:19] <tthorsen> the page is laid out in two floated columns, and when the two columns don't end up with the same parent, they don't end up next to each other.
# [12:01] <tthorsen> zcorpan: You say that the next version of Opera will deal with scoping like in the html5 spec; how does the new Opera like this markup:
# [12:03] <tthorsen> The current Firefox and Opera makes sense of this - IE produces something really strange, and the html5 parser puts the two objects inside one another
# [12:40] <Philip`> hsivonen: Their explanation of "conservative" seems completely unrelated to what I'd usually understand conservative GC to be
# [12:41] <hsivonen> Philip`: the usual conservative being related to guessing whether a word holds a pointer?
# [12:41] <Philip`> (where I'd usually understand to mean that it doesn't always know whether some piece of memory is a pointer or an integer, so it conservatively assumes it's a pointer)
# [12:42] <hsivonen> how does a garbage collector looking at the heap of a C++ process ever know that something is an integer and not a pointer?
# [12:44] <Dashiva> Philip`: That's just half of it
# [12:45] <Dashiva> The other half is that you can't move memory, because then you're either not updating pointers, or you are updating integers that aren't pointers, either way it's a loss
# [12:46] <Philip`> hsivonen: In general, it can't; but you could restrict the language a bit, and make the compiler cleverer so it retains all the necessary type information at runtime, and then it could work
# [12:50] * hsivonen thought about things the wrong way round
# [12:50] <Dashiva> I'm more confused by how they manage to do useful data flow analysis in c/c++ compilers
# [12:51] <Philip`> I guess it just scans the stack for pointer-like things, and then scans the pointed-at memory regions for pointer-like things, until it's run out of things to scan, or something like that
# [12:51] <Philip`> Dashiva: Usually they don't, because aliasing breaks everything :-)
# [12:51] <Dashiva> Philip`: Pretty much what you said
# [12:59] <takkaria> ([](int x) { cout << x; })(3); will be valid C++
# [13:00] <takkaria> or maybe it's [](int x){ cout << x; }(3);, I can't remember
# [13:01] <Philip`> That doesn't seem excessively crazy
# [13:02] * Philip` wasn't previously aware that C++0x had closure syntax
# [13:02] <takkaria> "int main(void) { int x = 2; [=](){ x++; cout << x;}(); cout << x; }" will print "32" (the '=' means "capture by value inside the closure")
# [13:04] <Dashiva> Have we learned nothing from fortran?
# [13:04] <takkaria> if anyone fancies a read, that's got examples of a bunch of crazy syntax
# [13:04] <Philip`> Hmm, I suppose they're not really closures, because they don't hang onto stack frames and you'll just end up crashing if you try to return them from functions and aren't careful
# [13:05] <Philip`> I've wanted something like "auto" every time I've had to write "for (std::map<std::string, std::string>::iterator = m.begin(); ...)"
# [13:10] <Philip`> As far as I'm aware, it just saves you having to type out the (often quite long, if it's using templates) type name on the LHS of a declaration when the compiler already knows the RHS's type
# [13:10] <Dashiva> Apparently it's for storing lambdas
# [13:12] <Philip`> (or at least the compiler generated a few hundred megabytes of error output before I killed it)
# [13:13] <zcorpan> tthorsen: why is it interesting?
# [13:14] <Philip`> hsivonen: There's no reason they couldn't include functionality equivalent to what stlfilt does
# [13:15] * Philip` has been working with someone who's written a compiler that converts certain arbitrarily-complex algebraic expressions into executable code, which works by stringing together a whole load of templated library functionality into a single C++ type that performs the whole computation
# [13:15] <tthorsen> zcorpan: well, it's not backwards compatible with the current behaviour of any of the browsers
# [13:16] <Philip`> and the error messages are crazy, but otherwise it's actually pretty nice, and works much better than the other approaches that have been tried
# [13:16] <hsivonen> Philip`: sounds like a shotgun aimed at foot
# [13:17] <zcorpan> tthorsen: it's pretty broken in ie though so probably pages don't depend on any particular behavior. or have you found otherwise?
# [13:17] <tthorsen> no. I only have a testcase. I'm not sure if that testcase is based on something that was found in the wild.
# [13:17] <zcorpan> tthorsen: we found a site before that depended on this behavior for <applet> (the markup was something like <p><applet></p>foo</applet> where the "foo" wasn't expected to be rendered)
# [13:24] <Philip`> Even sane people will do something crazy if you give them a billion chances to mess it up :-)
# [13:28] <tthorsen> Philip`: btw, I looked at the thing you posted yesterday with the "<code><pre>...</code></pre>...". It's kinda related to a problem I'm seeing myself
# [13:29] <tthorsen> I've got "<abbr><p>abbr</abbr></p><acronym><p>acronym</acronym></p>" which doesn't work out quite right
# [13:30] <tthorsen> Both seem to be related to step 3 of the "any other end tag" handling in "in body"
# [13:31] <Philip`> I guess it only works correctly if you've got misnested formatting elements, or something?
# [13:41] <tthorsen> Philip`: Yes. Removing step 3 completely (or replacing it with a step that makes sure we don't go out of bounds on the stack of open elements) fixes these cases, but I don't feel very confident it's the right fix...
# [14:16] <tthorsen> I think Opera's result looks nice, but I'm not sure how to write the html5 spec to mimic that. When we get to the </code> we can't pop our way out to the <code> because that would remove the <pre>.
# [14:18] <tthorsen> This actually reminds me of what I proposed for both the nested forms case and the script handling in "after head" case. When we see the </code>, if there's a <code> in the stack of open elements, we just remove it.
# [14:18] <zcorpan> tthorsen: what we do can't be mimicked without changing css
# [14:19] <tthorsen> really? How does css affect this?
# [21:51] <Hixie> um, early adopters shouldn't use bad markup? :-)
# [21:52] <Philip`> The early adopter didn't use bad markup; he used html5lib to sanitise other people's markup
# [21:55] <Philip`> (under the assumption that html5lib would parse HTML in a way that's largely compatible with browsers; and browsers all handle <code><pre></code></pre> and get the 'correct' output)
# [22:10] * Quits: maikmerten (n=maikmert@Lb11c.l.pppool.de) (Remote closed the connection)
# [23:10] <Philip`> Hixie: That means there's four ways that all result in the paragraph after the code being rendered properly (not monospaced text etc), so there's plenty of choices for HTML5 to copy :-)
# [23:19] * Quits: Lachy (n=Lachlan@lvcc-66-78-202-167.smartcity.com) ("This computer has gone to sleep")
# [23:37] <jgraham> Hixie: Well what I actually mean is that we want to pick something that will result in the rendering observed in browsers in cases where they are in agreement and try to limit our differences to cases where browsers differ
# [23:38] <jgraham> (in agreement for rendering if not for the DOM)
# [23:45] <Hixie> my point is that it's not clear that we're not already at a global minimum for that goal.
# [23:47] <Philip`> It's clear that we're not, because you could rewrite the algorithm to say "if the document is equal to this multi-kilobyte string then return this particular DOM, else continue with the standard parser algorithm", which would result in the algorithm handling more pages correctly and wouldn't make any more be handled incorrectly