| 00:06 | <Hixie> | man i wish people would put blank lines between their paragraphs |
| 00:16 | <Lachy> | I generally don't bother wasting my time trying to read emails that have been formatted poorly |
| 00:17 | <Hixie> | unfortunately i don't have that privilege really |
| 00:20 | <Hixie> | Philip`: fixed set/group for you |
| 00:21 | <Philip`> | Hixie: Thanks - you are too kind |
| 00:22 | <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 :-( |
| 00:23 | <Hixie> | no worries, my unread is at 2677 |
| 00:23 | <Hixie> | http://www.whatwg.org/issues/data.html :-) |
| 00:23 | <Hixie> | (for some definition of "unread" that is really "unreplied") |
| 00:53 | <Lachy> | I'm looking for things to do in Vegas this week. This looks like fun! :-) http://www.vegasindoorskydiving.com/ |
| 00:53 | <Lachy> | it's right next door to my hotel too |
| 00:54 | <jruderman> | Lachy: indoor skydiving? shouldn't that be ceilingdiving? |
| 00:56 | <gavin> | their "celebrity spotting" link points to file:///C|/Users/Cherlyn%20Fields/Desktop/pictures2.php |
| 00:57 | <Lachy> | LOL |
| 00:57 | <jruderman> | i just tried to click that link :( |
| 00:58 | <gavin> | http://www.vegasindoorskydiving.com/pictures2.php works |
| 00:58 | <gavin> | though the thumbnails are full images, judging by how fast they loaded |
| 00:58 | <Lachy> | from one page, it links to http://www.vegasindoorskydiving.com/pictures2.php |
| 01:00 | <Lachy> | I think I might go do that tonight and then head off to one of the casinos for dinner. |
| 01:01 | <Lachy> | But I still need to work out what to do for the rest of the week. |
| 01:01 | <Lachy> | Other than gambling away my life savings, I think I should go see a show or something |
| 01:02 | <Lachy> | any recommendations? |
| 01:02 | <Hixie> | avenue q |
| 01:03 | <Hixie> | though the vegas one is a truncated version |
| 01:04 | <Lachy> | is it still running? |
| 01:04 | <Hixie> | should be |
| 01:04 | <Hixie> | oh maybe not |
| 01:04 | <Lachy> | I found an New York Times article about it from 2006 |
| 01:07 | <Hixie> | spamalot apparently replaced it |
| 01:07 | <Hixie> | i imagine that's probably fun too |
| 01:07 | <Hixie> | but i don't know it |
| 01:11 | <Lachy> | doesn't look like it is http://www.avenueq.com/tour/ |
| 01:12 | <Hixie> | weee, they're coming to san jose in a few months!!! |
| 01:12 | Hixie | marks his calendar for when the tickets go on sale |
| 01:12 | <Hixie> | lol, my girlfriend already marked it |
| 01:22 | <Lachy> | damn, the wifi here is way too slow. I can't even read my email :-( |
| 01:22 | <Lachy> | oh well, I'm off to go dive into a giant fan. :-) |
| 01:23 | <Hixie> | later :-) |
| 03:28 | <Lachy> | I managed to survive my sky dive, that was awesome |
| 03:28 | <Lachy> | it's definitely harder than it looks though |
| 03:46 | <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 |
| 03:48 | <roc> | what context? |
| 03:54 | <Lachy> | roc, see public-html |
| 03:54 | <roc> | oh |
| 03:54 | <roc> | no thanks! |
| 03:55 | <Lachy> | roc, why? Don't you read that list anymore? |
| 03:55 | <roc> | I never have |
| 03:55 | jwalden | was going to type "any more?" |
| 03:56 | <Lachy> | jwalden, yeah, I meant "any more", but I didn't press space properly |
| 03:56 | <jwalden> | no, I was echoing roc, not criticizing a typo -- although I did notice it :-P |
| 03:56 | <Lachy> | oh |
| 03:57 | <jwalden> | always looked like a huge cesspool when I've occasionally skimmed web archives |
| 03:57 | <jwalden> | too many people who think they can cook spoil the broth |
| 03:59 | <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 |
| 03:59 | <jwalden> | actually, casino restaurants may be cheaper, to entice you to come in and make up their loss inside |
| 03:59 | <jwalden> | that's how it was when I was traveling through the west with family a number of years ago |
| 04:01 | <jwalden> | hm, judging by message count public-html may have improved since I last looked at it |
| 04:34 | Lachy | discovers that The Montecito casino featured in Las Vegas (the TV series) was fictional! |
| 04:35 | <Lachy> | until now, I just assumed it was a real one |
| 04:36 | <Lachy> | but at least the Bellagio from Ocean's 11 is real :-) |
| 04:47 | <roc> | for some definition of real |
| 09:00 | <Hixie> | oooh, leap second at the new year |
| 09:02 | hsivonen | still thinks that needing announcement-based coordination for something as fundamental as time sucks big time |
| 09:03 | <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 |
| 09:04 | <Hixie> | i think what it says now is clearer |
| 09:05 | <Hixie> | and how else would you do it? assuming that you want to keep the clocks in sync with the sun, that is |
| 09:05 | <tthorsen> | Couldn't you just adjust the velocity and rotation of the earth? |
| 09:06 | <tthorsen> | giant rocket-engines, maybe |
| 09:06 | <hsivonen> | Hixie: I think keeping solar year and atomic year in sync on that level of accuracy falls in the theoretical purity bucket |
| 09:06 | <hsivonen> | Posix time is sane |
| 09:07 | <hsivonen> | Hixie: I think at this point it's OK to leave sundial legacy UAs as a bit inaccurate |
| 09:08 | <hsivonen> | for the next few thousand years timezones already cause more sundial incompatibility than strict atomic time |
| 09:08 | <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. |
| 09:09 | <hsivonen> | oh. last time I calculated the max drift it was a lot smaller |
| 09:09 | <hsivonen> | perhaps I miscalculated |
| 09:11 | <hsivonen> | there are 3600 seconds in an hour |
| 09:11 | <hsivonen> | you can have at most 2 leap seconds per year |
| 09:11 | <hsivonen> | but the average is closer to one |
| 09:11 | <hsivonen> | so to get an hour of drift, you'd need to wait 3600 years |
| 09:12 | <hsivonen> | what did I calculate wrong? |
| 09:13 | <hsivonen> | and we accept an hour of drift every year. twice |
| 09:18 | <Hixie> | the average is closer to 1 ever 2 or 3 years iirc |
| 09:19 | <Hixie> | every |
| 09:19 | <hsivonen> | Hixie: doesn't that make my point stronger? |
| 09:26 | <Hixie> | drift takes a long time, yes |
| 09:27 | <Hixie> | apparently the average is 1.4 milliseconds per day per century |
| 09:28 | <Hixie> | average deceleraton of time, that is |
| 09:28 | <Hixie> | well, deceleration of earth |
| 09:28 | <Hixie> | (meaning longer days) |
| 09:29 | <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 |
| 09:30 | <hsivonen> | after all, by some accounts, the Earth is now only 6000 years old, so 4000 years is a relative long time |
| 09:34 | <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 |
| 09:34 | <Hixie> | the alternative, replacing leap seconds with leap hours, imho causes even more confusion |
| 09:34 | <Hixie> | and is far more likely to involve painful software bugs |
| 09:35 | <Hixie> | code that runs in production once every 4000 years is unlikely to be bug-free |
| 09:36 | <hsivonen> | Code that depends on external announcements is sure to perform different calculations before and after receiving an announcement |
| 09:36 | <Hixie> | (alternatively, you could just use TAI or GPS time instead of UTC) |
| 09:36 | <Hixie> | most code doesn't need to care about leap seconds |
| 09:37 | <Hixie> | because the clocks are likely to drift by more than that in normal operation anyway |
| 09:37 | <hsivonen> | the concept of civil time sucks |
| 09:37 | <Hixie> | so the normal clock-sync mechanisms will fix leap seconds for you |
| 09:38 | <hsivonen> | Hixie: I think it's acceptable to pretend that the current time is UTC as long as calculations don't implement UTC |
| 09:38 | <hsivonen> | implementing real UTC in software would be crazy |
| 09:38 | <hsivonen> | i.e. it's OK to do Posix time calculations and set the current time UTC |
| 09:39 | <hsivonen> | Hixie: have you seen the serious proposals for smoothing leap second transitions? those are some serious complexity |
| 09:40 | <Hixie> | UTC-SLS? |
| 09:41 | <hsivonen> | yeah |
| 09:41 | <Hixie> | most software wouldn't need to know about it |
| 09:41 | <Hixie> | as far as i can tell |
| 09:44 | <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 |
| 09:45 | <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? |
| 09:45 | <Hixie> | not really, but maybe i don't understand what you mean |
| 09:46 | <jgraham> | roc: Don't forget variations in g |
| 09:46 | <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 |
| 09:47 | <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 |
| 09:47 | <hsivonen> | Hixie: right, so leap seconds make no sense for "civil time" |
| 09:47 | jgraham | wonders h |
| 09:47 | <jgraham> | what |
| 09:47 | <hsivonen> | and military time doesn't use them |
| 09:47 | <hsivonen> | hence, theoretical purity needless complexity bucket |
| 09:47 | <jgraham> | Hixie means by "black-box radiation effects" |
| 09:48 | <zcorpan> | tthorsen: the spec actually matches ie, except that ie hides what's in object |
| 09:48 | <zcorpan> | tthorsen: try <p><object></p></object>x |
| 09:48 | <tthorsen> | how about the extra <p></p>? |
| 09:48 | <hsivonen> | aside, teaching people to say UTC instead of GMT is like teaching them to say URI instead of URL |
| 09:48 | <zcorpan> | tthorsen: stray </p> means <p></p> |
| 09:49 | <zcorpan> | tthorsen: why is it a problem? |
| 09:49 | <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) |
| 09:49 | <Hixie> | jgraham: caesium atomic clocks vary in speed based on ambient temperature |
| 09:50 | <Hixie> | jgraham: i meant blackbody radiation, my bad |
| 09:50 | <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 |
| 09:50 | <Philip`> | 36400 seconds per day would be pretty weird |
| 09:51 | <zcorpan> | tthorsen: that's because firefox and opera don't treat <object> as scoping |
| 09:51 | <Hixie> | er, 86400 |
| 09:51 | <zcorpan> | yet |
| 09:51 | <hsivonen> | Hixie: naively, one would think laws were more malleable than the way Earth's orbit time divides by cesium pulses |
| 09:52 | <tthorsen> | ok, If this is the intended behaviour of the spec, then I'll happily change our test cases |
| 09:52 | <Hixie> | hsivonen: like i said, let me know when you get the laws changed, and we can take it to the ITU. :-) |
| 09:53 | <tthorsen> | after all this means that I get to do nothing, and the guy who's responsible for the tests needs to do all the work :-) |
| 09:53 | <zcorpan> | tthorsen: fwiw we've changed to match the spec (for our next major release) |
| 09:55 | <tthorsen> | zcorpan: sounds good to me. Fwiw we will also match the spec for our next major release. |
| 09:59 | <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? |
| 09:59 | <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 |
| 10:00 | <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. |
| 10:00 | <tthorsen> | s/doesn't really matter/doesn't really matter to me/ |
| 10:00 | <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 :) |
| 10:01 | <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 |
| 10:02 | <tthorsen> | Nah, the normal procedure sounds fine to me. |
| 10:03 | <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) |
| 10:04 | <jgraham> | touched |
| 10:04 | <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 |
| 10:07 | <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. |
| 10:08 | <Hixie> | oldest feedback still pending a reply is from unix time_t 1073954713 |
| 10:08 | <Hixie> | whenever that is |
| 10:09 | <Hixie> | oldest feedback that's going to get a reply any time soon is from unix time_t 1101133613 |
| 10:09 | <Hixie> | (the oldest feedback is about the rendering section) |
| 10:09 | <takkaria> | 13th January |
| 10:09 | <takkaria> | 2004 |
| 10:09 | <Hixie> | wow, that's older than the whatwg |
| 10:10 | <takkaria> | and 22 November 2004 for the "reply any time soon" bit |
| 10:10 | <Hixie> | that makes more sense |
| 10:10 | <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. |
| 10:10 | <takkaria> | yeah, there's definitely something going wrong there |
| 10:11 | <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. |
| 10:12 | takkaria | nods, it looks a mess |
| 10:13 | <Hixie> | ok bed time |
| 10:13 | <Hixie> | nn |
| 10:53 | <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: |
| 10:54 | <tthorsen> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%3EAudio1%3C%2Fp%3E%0A%3Cp%3E%3Cobject%3E%3Cp%3EX%3C%2Fp%3E%3C%2Fp%3E%0A%3Cp%3EAudio2%3C%2Fp%3E%0A%3Cp%3E%3Cobject%3E%3Cp%3EY%3C%2Fp%3E%3C%2Fp%3E%0A%0A |
| 10:55 | <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 |
| 11:23 | <hsivonen> | http://www.opensource.apple.com/darwinsource/10.5.5/autozone-77.1/README.html interesting |
| 11:32 | <Philip`> | hsivonen: Their explanation of "conservative" seems completely unrelated to what I'd usually understand conservative GC to be |
| 11:33 | <hsivonen> | Philip`: the usual conservative being related to guessing whether a word holds a pointer? |
| 11:33 | <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) |
| 11:34 | <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? |
| 11:36 | <Dashiva> | Philip`: That's just half of it |
| 11:37 | <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 |
| 11:38 | <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 |
| 11:39 | <Philip`> | (e.g. Java) |
| 11:40 | <hsivonen> | Philip`: sure, I get that it works with Java, but how does e.g. Boehm ever know what to collect? |
| 11:40 | <Philip`> | Dashiva: That seems to me like it's a consequence of conservatism, and not part of what conservatism itself actually means |
| 11:40 | <Philip`> | but I suppose that's just a matter of definition :-) |
| 11:41 | <hsivonen> | I guess I should read up on C++ garbage collection some time |
| 11:41 | <Philip`> | hsivonen: Boehm doesn't, so it's conservative |
| 11:41 | <hsivonen> | Philip`: so why does it ever collect anything? |
| 11:42 | <hsivonen> | ooh. never mind |
| 11:42 | hsivonen | thought about things the wrong way round |
| 11:42 | <Dashiva> | I'm more confused by how they manage to do useful data flow analysis in c/c++ compilers |
| 11:43 | <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 |
| 11:43 | <Philip`> | Dashiva: Usually they don't, because aliasing breaks everything :-) |
| 11:43 | <Dashiva> | Philip`: Pretty much what you said |
| 11:50 | <Philip`> | C++ is a bit crazy when simply adding a "restrict" to a function argument can make your function go twice as fast |
| 11:50 | <takkaria> | I hope everyone's seen the closure syntax for C++0x |
| 11:51 | <takkaria> | ([](int x) { cout << x; })(3); will be valid C++ |
| 11:52 | <takkaria> | or maybe it's [](int x){ cout << x; }(3);, I can't remember |
| 11:53 | <Philip`> | That doesn't seem excessively crazy |
| 11:54 | Philip` | wasn't previously aware that C++0x had closure syntax |
| 11:54 | <takkaria> | "int main(void) { int x = 2; [=](){ x++; cout << x;}(); cout << x; }" will print "32" (the '=' means "capture by value inside the closure") |
| 11:55 | <zcorpan> | tthorsen: i get http://tinyurl.com/5ahcw7 |
| 11:55 | <takkaria> | they've also added semi-automatic typing, such that "auto x = 3;" will declare x as an int |
| 11:55 | <Dashiva> | ... why |
| 11:56 | <takkaria> | http://blogs.msdn.com/vcblog/archive/2008/10/28/lambdas-auto-and-static-assert-c-0x-features-in-vc10-part-1.aspx |
| 11:56 | <Dashiva> | Have we learned nothing from fortran? |
| 11:56 | <takkaria> | if anyone fancies a read, that's got examples of a bunch of crazy syntax |
| 11:56 | <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 |
| 11:57 | <Philip`> | I've wanted something like "auto" every time I've had to write "for (std::map<std::string, std::string>::iterator = m.begin(); ...)" |
| 11:57 | <zcorpan> | tthorsen: ie6 doesn't allow nested <object>s |
| 11:58 | <zcorpan> | not sure what ie8 does |
| 11:58 | <zcorpan> | tthorsen: firefox does the scoping thing with <applet> i think |
| 12:00 | <hsivonen> | Dashiva: isn't that auto thing more like JS than Fortran? |
| 12:01 | <Dashiva> | hsivonen: Looks to me like it only autotypes the declaration, you can't change types on assignment |
| 12:01 | <Philip`> | Dashiva: It's static typing, not like dynamic var in JS |
| 12:01 | <Philip`> | Uh |
| 12:01 | <hsivonen> | oh |
| 12:01 | <Philip`> | hsivonen: ^ |
| 12:01 | <hsivonen> | doesn't seem useful |
| 12:02 | <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 |
| 12:02 | <Dashiva> | Apparently it's for storing lambdas |
| 12:03 | <hsivonen> | Philip`: as far as templated types go, I think this is a sign of a pretty severe problem: http://www.bdsoft.com/tools/stlfilt.html |
| 12:04 | <Philip`> | hsivonen: That's just a compiler implementation quality issue - they are all rubbish and print horribly verbose error messages :-( |
| 12:04 | <tthorsen> | zcorpan: It's interesting that you get that result. That _is_ certainly the same as what the html5 algorithm outputs. |
| 12:04 | <Philip`> | I got an infinitely long template error message once |
| 12:04 | <hsivonen> | Philip`: "just"? :-) |
| 12:04 | <Philip`> | (or at least the compiler generated a few hundred megabytes of error output before I killed it) |
| 12:05 | <zcorpan> | tthorsen: why is it interesting? |
| 12:06 | <Philip`> | hsivonen: There's no reason they couldn't include functionality equivalent to what stlfilt does |
| 12:07 | 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 |
| 12:07 | <tthorsen> | zcorpan: well, it's not backwards compatible with the current behaviour of any of the browsers |
| 12:08 | <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 |
| 12:08 | <hsivonen> | Philip`: sounds like a shotgun aimed at foot |
| 12:09 | <zcorpan> | tthorsen: it's pretty broken in ie though so probably pages don't depend on any particular behavior. or have you found otherwise? |
| 12:09 | <tthorsen> | no. I only have a testcase. I'm not sure if that testcase is based on something that was found in the wild. |
| 12:09 | <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) |
| 12:12 | <Philip`> | hsivonen: But it works :-) |
| 12:13 | <tthorsen> | zcorpan: wow, you'd think ordering those tags sanely wouldn't be rocket science... |
| 12:14 | <zcorpan> | tthorsen: well, it's the web we're talking about, remember :) |
| 12:15 | hsivonen | finds http://mxr.mozilla.org/mozilla-central/source/content/base/public/nsIDocument.h#729 |
| 12:16 | <Philip`> | Even sane people will do something crazy if you give them a billion chances to mess it up :-) |
| 12:20 | <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 |
| 12:21 | <tthorsen> | I've got "<abbr><p>abbr</abbr></p><acronym><p>acronym</acronym></p>" which doesn't work out quite right |
| 12:22 | <tthorsen> | Both seem to be related to step 3 of the "any other end tag" handling in "in body" |
| 12:23 | <Philip`> | I guess it only works correctly if you've got misnested formatting elements, or something? |
| 12:23 | <Philip`> | (<b><i>...</b></i> etc) |
| 12:24 | Philip` | goes away |
| 12:33 | <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... |
| 12:47 | <zcorpan> | is <code> a formatting element in webkit? |
| 12:48 | <zcorpan> | if you use <span> instead then webkit will nest |
| 12:50 | <zcorpan> | hmm firefox just closes <code> at <pre> |
| 12:51 | <tthorsen> | yeah. Opera and IE do the same thing, though |
| 12:52 | <tthorsen> | (at least my version of Opera does) |
| 12:54 | <zcorpan> | not quite, but yeah |
| 12:56 | <zcorpan> | (try to put some text between the end tags) |
| 13:08 | <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>. |
| 13:10 | <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. |
| 13:10 | <zcorpan> | tthorsen: what we do can't be mimicked without changing css |
| 13:11 | <tthorsen> | really? How does css affect this? |
| 13:11 | <zcorpan> | try http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Ccode%20style%3Dcolor%3Ared%3E%3Cpre%3Ex%3C%2Fcode%3Ey%3C%2Fpre%3E |
| 13:13 | <tthorsen> | the change I proposed just now, would do just that, wouldn't it? |
| 13:14 | <zcorpan> | note that only the "x" is red, not the "y" |
| 13:18 | <tthorsen> | oh, right. That's really weird. I would have thought that css should have been done after, and independently from, the parser. |
| 13:19 | <tthorsen> | ie: <code> has style color: red, y ends up inside <code>, so y should be red |
| 13:20 | <zcorpan> | right |
| 13:21 | <tthorsen> | is this behaviour in Opera considered a bug or a feature? |
| 13:22 | <zcorpan> | well per html5 it's a bug |
| 13:23 | <zcorpan> | i think the closest you can get rendering-wise is to make <code> a formatting element |
| 13:25 | <tthorsen> | yeah. That certainly does produce the same result in our browser |
| 19:28 | Hixie | doesn't think it likely that we'll change the spec for <code><pre></code> |
| 19:28 | <Hixie> | really our only option is making <code> one of the quirky tags |
| 19:28 | <Hixie> | formatting tags |
| 19:28 | <Hixie> | and i'd rather not add more of those |
| 19:36 | <Hixie> | where on earth is zcorpan's dom core draft |
| 19:40 | <hsivonen> | Hixie: http://simon.html5.org/specs/web-dom-core |
| 19:40 | <Hixie> | thanks |
| 19:42 | <Hixie> | hm, his appendChild() definition doesn't prevent elements appended to text nodes |
| 19:42 | <Hixie> | oh well |
| 20:05 | <jgraham> | Does actual badness occur is <code> is a formatting tag? |
| 20:11 | <hober> | Seems like people can just write <pre><code> |
| 20:11 | <hober> | how often does <code><pre> even happen? |
| 20:42 | <Philip`> | Hixie: Not fixing <code><pre></code> is bad PR because it breaks early adopters :-( |
| 20:43 | <Philip`> | (specifically http://planet.intertwingly.net/ in "REST APIs must be hypertext driven") |
| 20:43 | <Hixie> | um, early adopters shouldn't use bad markup? :-) |
| 20:44 | <Philip`> | The early adopter didn't use bad markup; he used html5lib to sanitise other people's markup |
| 20:47 | <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:00 | <Hixie> | Philip`: well, there's not much we can do there since four browsers handle that markup in four different ways |
| 22:02 | <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 :-) |
| 22:23 | <Hixie> | Philip`: maybe. of course, changing this will just result in other bugs, the question is which bugs do we want. |
| 22:25 | <jgraham> | Hixie: The ones that browsers already have :) |
| 22:25 | <Hixie> | they differ |
| 22:29 | <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 |
| 22:30 | <jgraham> | (in agreement for rendering if not for the DOM) |
| 22:36 | <Hixie> | that's what we want to do, yes |
| 22:37 | <Hixie> | my point is that it's not clear that we're not already at a global minimum for that goal. |
| 22:39 | <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 |
| 22:58 | <jgraham> | The rendering of <b><code>foo</b>bar</code> from HTML5 seems to match Firefox but not Safari, Opera or IE7 |
| 22:59 | <jgraham> | I don't remember if someone already mentioned that |
| 23:00 | <Hixie> | yes, because Opera and IE7 make all tags use the AAA or their equivalent, and Safari has a different list of tags that Firefox. |
| 23:00 | <Hixie> | HTML5 uses the intersection of the set of tags from firefox and safari |
| 23:02 | <hsivonen> | hmm. there are JavaFX questions on StackOverflow http://stackoverflow.com/questions/tagged/javafx |
| 23:03 | <jgraham> | Hixie: It seems like copying Safari would be good here |
| 23:03 | <Hixie> | so it is claimed :-) |
| 23:04 | <Hixie> | any change we make changes the total number of bugs, sometimes up, sometimes down. we only know of the bugs that are reported. the judgement we have to make is determining whether there are more bugs introduced by the proposed change that we don't know about than there are left if we don't make the change. |
| 23:05 | <hsivonen> | many more questions tagged silverlight http://stackoverflow.com/questions/tagged/silverlight not surprising |
| 23:05 | <hsivonen> | and even more Flash http://stackoverflow.com/questions/tagged/flash |
| 23:05 | <hsivonen> | even more html http://stackoverflow.com/questions/tagged/html |
| 23:06 | <jgraham> | It seems pretty likely that changes that make us render more like IE and fix issues with actual sites will move the bug count down rather than up. Do you have any specific concerns about the proposed changes? |
| 23:07 | <Hixie> | they make us more like IE for certain snippets, and less like IE for others. |
| 23:08 | <jgraham> | What becomes less like IE? |
| 23:09 | <Hixie> | there start being more <code> elements per <code> token in the DOM than there are in IE, for example. |
| 23:09 | <Hixie> | so scripts depending on a 1:1 mapping start failing |
| 23:10 | <Hixie> | it also changes the performance characteristics to be more expensive, so pages that IE might handle cheaply become expensive |
| 23:10 | <Hixie> | and so on |
| 23:10 | <Hixie> | in general we want to keep the number of formatting elements to an absolute minimum |
| 23:10 | <Hixie> | if we didn't, we'd just remove the difference between formatting elements and phrasing elements and just have them all do the AAA thing |
| 23:11 | <jgraham> | Isn't that generally true with the AAA stuff? It seems like there wouln't be much content that relied on that otherwise it would likely break in Firefox (albeit with different elements) |
| 23:11 | <jgraham> | (I am of course aware of the /topic) |
| 23:11 | <jgraham> | (that === 1:1 mapping) |
| 23:11 | <Hixie> | yes, it is true, and that's why both firefox and safari try to keep the list to a minimum too |
| 23:12 | <Hixie> | firefox doesn't have <code> in its list, you'll note |