| 02:19 | <Hixie> | othermaciej: yt? |
| 02:19 | <othermaciej> | hey Hixie |
| 02:19 | <Hixie> | did you say webkit had plans to do something about blocking script on stylesheets? |
| 02:20 | <othermaciej> | I believe we currently block script execution when there are pending stylesheets |
| 02:20 | <othermaciej> | I believe that has been true since shortly after we added speculative loading of scripts |
| 02:21 | <Hixie> | http://www.hixie.ch/tests/adhoc/html/parsing/script-style-blocking/001.html says otherwise |
| 02:22 | <othermaciej> | I could be mis-remembering |
| 02:22 | <othermaciej> | or it could be buggy (though that case seems exceptionally simple) |
| 02:22 | <othermaciej> | it's possible we only block external scripts on stylesheets, even though that would be really stupid |
| 02:22 | <Hixie> | hm, let me test externals only |
| 02:23 | <Hixie> | ooh, yes, that blocked |
| 02:25 | <othermaciej> | so yeah, that's kinda dumb - not sure if it was intentional |
| 02:28 | <Hixie> | i'm concerned about http://www.hixie.ch/tests/adhoc/html/parsing/script-style-blocking/002.html if we make internals block also |
| 03:07 | <mpilgrim> | any opera employees around? |
| 03:07 | <mpilgrim> | i am aware that http://diveintohtml5.org/ renders very badly in Opera 10.0.0 |
| 03:07 | <mpilgrim> | due to wacky rendering of embedded fonts |
| 03:08 | <mpilgrim> | i wonder if there is something i can do to fix my fonts, or if there is something y'all can do to fix opera, or some combination of both |
| 03:09 | <mpilgrim> | an opera user sent me this (unconfirmed) report: "I got some further information about the bug. It would appear that the styles are only properly applied to the first document if I open multiple tabs. As long as I look at the documents one by one, the styles work fine." |
| 04:31 | Hixie | wishes someone would take over CSSOM already |
| 04:31 | <Hixie> | not having someone working on CSSOM is really making my life harder |
| 04:37 | <othermaciej> | Hixie: concerned in what way (about that test case) |
| 04:38 | <Hixie> | bz and i talked it out |
| 10:11 | <Hixie> | !@#^&* |
| 10:12 | <Hixie> | HTTP "Link:" headers screw me over again |
| 10:12 | <Hixie> | i hate that Mark refuses to define their processing model |
| 10:13 | <Hixie> | it leaves them in a dumb limbo with no spec that defines their interaction with other features like html parsing |
| 10:13 | <Hixie> | not that xml-stylesheet does much better |
| 10:15 | <othermaciej> | what did Link do to you? |
| 10:15 | <Hixie> | how am i suppose to define how they block <script> processing? |
| 10:15 | <Hixie> | there's no spec that actually makes them part of the CSSOM model |
| 10:16 | <othermaciej> | do browsers actually support loading a stylesheet via a Link header? |
| 10:16 | <Hixie> | firefox does |
| 10:16 | <Hixie> | i wish other browsers would :-) |
| 10:17 | <othermaciej> | sure, I'd love to implement a feature that's complicated, useless, and has no spec that defines processing requirements |
| 10:21 | <Hixie> | it's not useless |
| 10:21 | <Hixie> | i actually used it just the other day with the microdata study |
| 10:24 | <othermaciej> | what are the use cases for using the Link header to apply a stylesheet (or really for any other purpose) that are not served by <link rel="stylesheet">? |
| 10:25 | <stevierabie> | when us html5 out |
| 10:25 | <othermaciej> | I'm going to assume the cases where you cannot under any circumstances alter the document fail the 80/20 rule |
| 10:26 | <Hixie> | othermaciej: what are the use cases for using a <link> header to apply a style sheet that are not served by <style>@import ? |
| 10:26 | <Hixie> | othermaciej: Link: lets you apply a style sheet to a whole site with one line in an .htaccess file |
| 10:27 | <Hixie> | othermaciej: with the microdata study, I used a Link: header and a data: URL to style <img> elements without having to include anything into the files that would interfere with the study, for instance |
| 10:27 | <Hixie> | stevierabie: what do you mean by "out"? it's been public since we started, at http://whatwg.org/html5 |
| 10:27 | <othermaciej> | Hixie: whether <link> has an independent use case from @import is no longer a relevant consideration, since it is required for compatibility |
| 10:28 | <Hixie> | (Link: is also useful as a hack for applying styles to text/plain documents, but that's probably not something i'd want to advertise. :-) ) |
| 10:28 | <othermaciej> | that sounds like a bug |
| 10:29 | <Hixie> | HTML5 defines the DOM that text/plain files generate in browsers |
| 10:29 | <Hixie> | so not really |
| 10:31 | <othermaciej> | I remember back in the day when we discovered for Safari that we had to generate an HTML DOM for plain text files |
| 10:31 | <othermaciej> | for compatibility |
| 10:31 | <othermaciej> | that was a sad day |
| 10:31 | <Hixie> | hehe |
| 10:32 | <othermaciej> | does HTML5 require making a DOM for images or plugin content as a top-level resource? |
| 10:32 | <Hixie> | yes |
| 10:32 | <othermaciej> | we do it in that case too, though not yet for PDF |
| 10:33 | <Hixie> | there are certain dispensations for cases like PDF |
| 10:33 | <Hixie> | though i think you have to have a Document in all cases, even if it's a fake one |
| 10:34 | <Hixie> | i wonder if <?xml-stylesheet?> is the target of a 'load' event when its style sheet loads |
| 10:34 | <Hixie> | anyone know? |
| 10:39 | <othermaciej> | it does not appear to dispatch a "load" event in WebKit |
| 10:39 | <Hixie> | k |
| 10:39 | <othermaciej> | (though, oddly, hyatt made it dispatch the "beforeload" thing he came up with) |
| 10:39 | <Hixie> | thanks |
| 10:39 | gavin | would be surprised if it did in gecko |
| 10:39 | <Hixie> | beforeload? |
| 10:39 | <othermaciej> | it should probably dispatch "load" |
| 10:40 | <othermaciej> | I wonder if "beforeload" matches the semantics of any of the Progress Events |
| 10:40 | <othermaciej> | in which case I should suggest he change it |
| 10:40 | Hixie | added this to the Companion Specs wiki page |
| 10:41 | <othermaciej> | it's dispatched before an element starts loading, you can preventDefault() on it to stop the load |
| 10:42 | <othermaciej> | intended for scripts that want to alter the behavior of sites to prevent certain kinds of content from loading |
| 10:42 | <othermaciej> | I should propose it for Progress Events |
| 10:42 | <Hixie> | sounds like it would add a lot of complexity |
| 10:42 | <Hixie> | to the spec |
| 10:43 | <othermaciej> | making loadstart cancelable would be sufficient |
| 10:43 | <othermaciej> | bizzarely, the current Editor's Draft of Progress Events does not define whether the events bubble or are cancelable |
| 10:45 | <othermaciej> | so I guess making loadstart cancelable would be a suggestion for HTML5, not Progress Events |
| 10:46 | <Hixie> | i don't really understand progress events |
| 10:46 | <othermaciej> | is it a suggestion I should make (in which case I'd ask hyatt to get rid of "beforeload") or should we keep our nonstandard thing for now? |
| 10:46 | <Hixie> | as far as i can tell, it should just define the interface, and suggest a few event names |
| 10:46 | <othermaciej> | Progress Events has a weird combination of exacting detailed requirements and totally undefined things |
| 10:46 | <Hixie> | but instead it has a ton of requirements i don't understand |
| 10:46 | <Hixie> | yeah |
| 10:46 | <Hixie> | you should send review comments |
| 10:47 | <Hixie> | chaals hasn't been very responsive to my own |
| 10:47 | <Hixie> | but virtually nobody else has sent him review comments |
| 10:47 | <othermaciej> | I sent a bunch long ago |
| 10:47 | <Hixie> | re beforeload, i would like to defer new features like that from html5 at this stage |
| 10:47 | <othermaciej> | maybe it could use a fresh round of review |
| 10:47 | <Hixie> | but it could make sense for html6 |
| 10:47 | <othermaciej> | I don't want to suggest adding beforeload to html5 |
| 10:48 | <othermaciej> | but I would consider suggesting making "loadstart" cancelable in HTML5, if you thought that was a reasonable option |
| 10:48 | <othermaciej> | (in which case we'd get rid of "beforeload") |
| 10:51 | <othermaciej> | Hixie: so should I file a bug that suggests making "loadstart" cancelable, or is that a dumb idea? |
| 10:51 | <othermaciej> | or I can just file the bug and wait for the answer if you are not sure right now |
| 10:52 | <othermaciej> | hmm, it looks like loadstart only applies to media elements in HTML5 |
| 10:57 | <annevk42> | fwiw, there were a bunch of comments on posts stuck in moderation (in particular for "Usability testing HTML5") -- I just approved them |
| 10:59 | <Hixie> | othermaciej: the name of the event doesn't really matter to me, i just meant the feature :-) |
| 10:59 | <Hixie> | othermaciej: i only fire progress events for media elements at the moment (and for appcache, but there i'm totally violating the progress events spec anyway) |
| 11:00 | <othermaciej> | Hixie: the reason I bring up the name is that HTML5 currently renders it noncomforming to make "loadstart" cancelable, so we have to introduce a new event |
| 11:14 | gsnedders_ | ponders why he cannot get any WHATWG email |
| 11:17 | <annevk42> | othermaciej, fwiw, version is not new; it was a deprecated feature of HTML4 iirc |
| 11:18 | <othermaciej> | ah, you're right |
| 11:18 | <othermaciej> | although HTML4 does not define the syntax |
| 11:18 | <othermaciej> | and I'm not sure what the pre-HTML4 syntax was |
| 11:19 | <othermaciej> | what it said was: "The value of this attribute specifies which HTML DTD version governs the current document. This attribute has been deprecated because it is redundant with version information provided by the document type declaration." |
| 11:19 | <othermaciej> | that's obviously not applicable to HTML5 though and does not seem to be what the new version attribute does |
| 11:20 | <annevk42> | yeah, it's a bit sad that every now and then people try to invent some kind of versioning for the Web |
| 11:20 | <othermaciej> | HTML3.2 does not seem to have a version attribute |
| 11:20 | <Hixie> | othermaciej: i don't really see the use case for canceling loadstart on <video> or appcache |
| 11:21 | <othermaciej> | was it added to HTML4 and immediately deprecated? |
| 11:22 | <othermaciej> | Hixie: it's that same as our use case for beforeload, namely to give script that may not be closely tied to the site to prevent a resource from loading |
| 11:22 | <othermaciej> | though granted, much more likely uses will be for <script>, <object> and <img> |
| 11:23 | <Hixie> | why doesn't it just remove the element |
| 11:24 | <annevk42> | othermaciej, it seems it was part of the HTML 3.2 DTD at least |
| 11:24 | <othermaciej> | how would it be able to find out about the element soon enough? mutation events don't fire during parsing |
| 11:25 | <othermaciej> | maybe I misread the DTD |
| 11:26 | <Hixie> | annevk42: how much do i need to pay you to get you to work on CSSOM? :-) |
| 11:27 | <Hixie> | oh hey, CSSOM has a section on Link:, awesome |
| 11:27 | <othermaciej> | I see, its in the DTD for HTML 3.2 but not documented at all in prose |
| 11:27 | <othermaciej> | and OMG, HTML 3.2 makes HTML 4.01 look like a good spec |
| 11:28 | <othermaciej> | it is documented in HTML 3.0 and says "This is fixed by the DTD as the string "-//W3O//DTD W3 HTML 3.0//EN"" |
| 11:29 | <annevk42> | Hixie, I guess I should get back to it after XHR/CORS are somewhat more stable |
| 11:29 | <Hixie> | annevk42: oooh |
| 11:29 | <Hixie> | othermaciej: why are we even still talking about versioning |
| 11:29 | <Hixie> | othermaciej: didn't we throw that out half a decade ago? |
| 11:29 | <annevk42> | not everyone got the memo :/ |
| 11:30 | <Hixie> | sigh |
| 11:30 | <othermaciej> | Hixie: it was not my idea to make a spec supposedly for the profile attribute where 90% of the content is about the version attribute |
| 11:32 | <annevk42> | Hixie, did you ever discuss CORS with Mark Miller? |
| 11:32 | <Hixie> | yes, but i never really understood what his concern was |
| 11:32 | <othermaciej> | what does #FIXED in a DTD mean? |
| 11:33 | <Hixie> | othermaciej: that the attribute is optional but if present must have the given value |
| 11:33 | <Hixie> | othermaciej: and that the attribute has the given value even if omitted |
| 11:33 | <othermaciej> | Hixie: I think Mark Miller hates origin-based security and loves capabilities-based security |
| 11:33 | <Hixie> | that is certainly the case |
| 11:33 | <Hixie> | but the web is origin-based |
| 11:34 | <othermaciej> | I think that is the root of his concern about CORS |
| 11:34 | <othermaciej> | retrofitting capabilities-based security on the web seems like a fool's errand |
| 11:34 | <Hixie> | seems more dangerous to have a hybrid model than a single bad model |
| 11:34 | <othermaciej> | I wonder how things like Caja and ADSafe enable content to get added to the DOM |
| 11:35 | <othermaciej> | it seems almost impossible to make a safe capabilities facade on top of the DOM |
| 11:35 | <Hixie> | nah, it's pretty easy |
| 11:35 | <Hixie> | but you can't do it with existing web content |
| 11:36 | <othermaciej> | if you're willing to have your facade not look anything like the DOM API that exists today, then sure |
| 11:36 | <Hixie> | right |
| 11:36 | <othermaciej> | ADSAFE seems to essentially expose a postMessage-like interface for injected content to interact with the page |
| 11:37 | <othermaciej> | it seems like it would be easier (and possibly safer) to just use an iframe and postMessage |
| 11:37 | <annevk42> | it does seem like most sites and such move to a capability-based model with OAuth |
| 11:38 | <othermaciej> | OAuth is not the kind of object-capability scheme that Mark Miller (and Doug Crockford) are interested in |
| 11:40 | <othermaciej> | I'm trying to figure out what OAuth actually does, from the spec |
| 11:40 | <othermaciej> | is it expected that you make the OAuth authorization request from the server side? |
| 11:41 | <annevk42> | though it seems to me you can do the things they want on top of CORS if you just view CORS as necessary infrastructure |
| 11:41 | <othermaciej> | i.e. it's a server-to-server cross-site scheme? |
| 11:42 | <othermaciej> | the spec doesn't say, but it looks like it has to be |
| 11:42 | <annevk42> | are you sure it's not what they're talking about? |
| 11:43 | <annevk42> | the example Tyler gave looks a lot like the OAuth abstract example |
| 11:43 | <othermaciej> | oh, I'm not saying Mark Miller doesn't like OAuth (I have no idea), just that it's not an object-capability scheme |
| 11:43 | <annevk42> | I'm not very familiar with OAuth myself unfortunately |
| 11:43 | <othermaciej> | as far as I can tell, it's a way of formalizing one-time secret tokens |
| 11:44 | <othermaciej> | I don't think OAuth is implementable on the client on top of XHR+CORS |
| 11:44 | <othermaciej> | because it requires the service provider and consumer to have a shared secret which is used in the protocol, and you can't be sending out your shared secret in client-side JS |
| 11:46 | <stevierabie> | lol |
| 11:46 | <stevierabie> | :D |
| 11:46 | <stevierabie> | :| |
| 11:46 | <othermaciej> | CORS would replace the use of a consumer secret with the Origin header plus something to verify that the request is coming from the user's browser (e.g. a cookie) |
| 11:49 | <othermaciej> | you also have to sign requests with an RSA private key |
| 11:49 | <annevk42> | they're no fan of cookies either |
| 11:50 | <othermaciej> | OAuth as designed seems to require server-to-server communication for cross-site requests |
| 11:50 | <othermaciej> | I'm not sure how you would apply this model to a client-to-server cross-site mechanism |
| 11:59 | <annevk42> | It seems like use stuff such as ADSafe and Caja is also solved by sandboxed iframes |
| 11:59 | <annevk42> | it would actually be good to get that implemented |
| 12:00 | <annevk42> | though if only a few browsers do it there's less of a benefit of course |
| 12:12 | <othermaciej> | I don't think I really understand how Caja works |
| 12:16 | <othermaciej> | omg it really does have a DOM wrapper |
| 12:19 | <Hixie> | doesn't it have to? |
| 12:20 | <annevk42> | I'm always somewhat worried that CORS is completely the wrong solution. It is certainly a lot more complex than desired. But then the critique has been vague and not quite compelling... |
| 12:22 | <Hixie> | as maciej said earlier, the critique has been basically "the web's security model sucks" |
| 12:22 | <Hixie> | which is true |
| 12:22 | <Hixie> | but doesn't do much to help us come up with a solution |
| 12:23 | <annevk42> | an alternative model I could imagine is that you do not have the origin and the server simply states whether it accepts cross-origin requests |
| 12:24 | <annevk42> | and there's never cookies or authentication involved I guess |
| 12:24 | <Hixie> | then how do you do things on behalf of the user? |
| 12:25 | <annevk42> | with some key exchange I suppose |
| 12:25 | <Hixie> | if you can't send cookies to the third party site, how do you do that? |
| 12:25 | <Hixie> | even things like openid rely on being able to send cookies to teh third party host, though they do it at the top level or in iframes, not with XHR |
| 12:26 | <othermaciej> | omg, Caja actually has its own HTML parser |
| 12:26 | <Hixie> | is it html5-compliant? |
| 12:27 | <othermaciej> | I'm pretty sure it's not |
| 12:28 | <othermaciej> | I do see a comment: "TODO(mikesamuel): validate sanitizer regexs against the HTML5 grammar" |
| 12:28 | <Hixie> | they use regexps?! |
| 12:28 | <othermaciej> | so it seems |
| 12:29 | <Hixie> | jesus, making style sheets block scripts in the parser is turning into quite the gigantic rewrite |
| 12:33 | <Hixie> | well i'm sure glad English supports continuations |
| 12:34 | <Hixie> | it's gonna make describing how to spin an event loop while waiting for something a lot easier |
| 12:37 | <annevk42> | for algorithms like this I certainly don't envy the person trying to test it |
| 12:37 | <Hixie> | actually testing that is relatively easy, compared to implementing it |
| 12:38 | <othermaciej> | Hixie: how is waiting for style sheets any different than waiting for the script itself (in the external script case)? |
| 12:39 | <gsnedders_> | annevk42, jgraham: get my email? |
| 12:39 | <othermaciej> | Caja also has a CSS parser (for style= values) which amounts to splitting on ; and then splitting on : |
| 12:39 | <Hixie> | othermaciej: i have to trigger the run based on either the last style sheet completing its fetching algorithm _or_ the script completing _its_, whichever comes last |
| 12:39 | <Hixie> | othermaciej: also, i'm taking this opportunity to change the way the parser is specified so that it doesn't hang the browser while waiting for the script to load |
| 12:40 | <Hixie> | othermaciej: but instead spins the event loop while waiting |
| 12:40 | <stevierabie> | SHUT UP |
| 12:40 | <stevierabie> | plz |
| 12:40 | <Hixie> | othermaciej: (that's a big part of the rewrite) |
| 12:40 | <annevk42> | gsnedders_, I did; so no movie? |
| 12:40 | <othermaciej> | Hixie: all you have to do is test for whether execution can continue when the script finishes loading, and every time a stylesheet finishes loading |
| 12:40 | <Hixie> | stevierabie: hm? |
| 12:40 | <gsnedders_> | annevk42: right |
| 12:40 | <stevierabie> | lol |
| 12:40 | <annevk42> | gsnedders_ :/ |
| 12:40 | <gsnedders_> | annevk42: Unless you want to see something else |
| 12:40 | <othermaciej> | Hixie: ah, that would be a major bug in the old way it was specified |
| 12:40 | <annevk42> | gsnedders_, I've no idea what they're showing |
| 12:41 | <annevk42> | gsnedders_, we could maybe do movie/food here at Arjan's place |
| 12:41 | <gsnedders_> | annevk42: Dunno if jgraham knows where that is though |
| 12:41 | <annevk42> | gsnedders_, he's still a bit sleepy though, but prolly up for it |
| 12:41 | <Hixie> | othermaciej: "all you have to do" makes it sound easy, but it's a lot harder to have two different tasks trigger something to resume rather than just having no task at all and hanging until something is ready :-) |
| 12:41 | <annevk42> | gsnedders_, are you at jgraham's place? |
| 12:42 | <gsnedders_> | annevk42: No, but I'm quite close to it |
| 12:42 | <othermaciej> | Hixie: well the hanging was a bug anyway |
| 12:42 | <annevk42> | Arjan's place is downtown, real easy to find |
| 12:42 | <Hixie> | othermaciej: indeed |
| 12:42 | <othermaciej> | fixing the hanging is the only plausibly hard part |
| 12:43 | <othermaciej> | having two tasks trigger something instead of one just needs state |
| 12:43 | <othermaciej> | (i.e. each task updates state, checks the other's output state, and resumes if both things are complete) |
| 12:43 | <gsnedders_> | annevk42: Yeah, I know where it is. Been there before. |
| 12:43 | <gsnedders_> | annevk42: Coco - livet före Chanel, Det enda rationella, Fame, Flickan som lekte med elden, Harry Potter och halvblodspri, Inglourious Basterds, Julie & Julia, Kalas Alfons!, Michael Jackson's - This is it, Surrogates, Taking Woodstock, The Ugly Truth, Äntligen Midsommar! |
| 12:43 | <gsnedders_> | annevk42: That's what's on |
| 12:44 | <othermaciej> | I wonder if hsivonen implemented hanging in Mozilla's html5 parser |
| 12:44 | <othermaciej> | I can't imagine he did |
| 12:44 | <Hixie> | othermaciej: because of the hanging part, it used to be that there were no tasks triggering state |
| 12:44 | <Hixie> | i don't think he did |
| 12:44 | <othermaciej> | I'm kinda surprised no one spotted the bug - maybe he just assumed stopping parsing and resuming later was equivalent |
| 12:45 | <othermaciej> | (which it isn't, since events can be processed) |
| 12:45 | <annevk42> | gsnedders_, hmm, of those that I haven't seen Taking Woodstock seems kind of interesting |
| 12:45 | <Hixie> | i believe this bug has been brought to my attention before |
| 12:45 | <Hixie> | but maybe only on irc |
| 12:46 | <gsnedders_> | annevk42: I don't really mind what we do |
| 12:50 | <annevk42> | try to think of something :) |
| 12:50 | <gsnedders_> | annevk42: Me? Decisive? :P |
| 12:58 | <othermaciej> | I think I found at least two obvious security bugs in Caja's DOM facade just by code inspection |
| 13:00 | <Hixie> | ok i did it |
| 13:00 | <Hixie> | i'll review it tomorrow |
| 13:00 | <Hixie> | nn |
| 13:20 | <annevk42> | gsnedders_, see pm |
| 17:19 | <erlehmann> | is the timeline for last call still oct 2009 (this month ?) |
| 20:53 | <foolip> | does anyone know a script hacks to cause unknown element to be parsed as void elements? |
| 20:54 | <foolip> | in IE they are by default and the document.createElement hack can make them be parsed as element with end tags |
| 20:55 | <foolip> | for all other browsers something to cause e.g. <source> or <itemref> as void elements would be nice |
| 20:56 | <foolip> | *to be parsed as |
| 21:48 | <annevk42> | foolip, don't think there's such a thing |
| 21:58 | <Philip`> | foolip: No sane browser allows scripts to change parser behaviour |
| 22:15 | <foolip> | Philip`: no, I guess that might be strange |
| 22:16 | <gsnedders_> | annevk42: http://en.wiktionary.org/wiki/Anne#Dutch |
| 22:19 | <foolip> | http://en.wiktionary.org/wiki/Anne#Swedish |
| 22:27 | <Philip`> | foolip: Well, browsers do lots of things that could be considered "strange" |
| 22:29 | <Philip`> | but changing the parser by calling createElement seems to go beyond that and is exposing implementation details in a crazy way |
| 22:31 | <foolip> | Philip`: IEs behavior could hardly have been intentional as a service to those who want the choice between void/non-void parsing for new elements |
| 22:32 | <Philip`> | Indeed |
| 22:32 | <foolip> | hmmm, is http://livedom.validator.nu/ actually a JS implementation of the HTML5 parsing algorithm? |
| 22:34 | Philip` | assumes it indicates something like IE having a per-document map of element names, initialised with standard HTML elements with the 'parse as HTML' flag enabled, and createElement accidentally inserts the named element in that map (with the parse-as-XML behaviour (like it uses for 'namespaced' elements) instead of parse-as-HTML), and the parser looks in that map to work out how to parse things |
| 22:34 | <Philip`> | or something roughly along those lines |
| 22:34 | <Philip`> | foolip: Yes |
| 22:34 | <Philip`> | foolip: (It's a Java implementation compiled to JS using GWT) |
| 22:37 | <foolip> | wow, that was not pretty code |
| 22:38 | <foolip> | (http://livedom.validator.nu/nu.validator.htmlparser.HtmlParser.nocache) |
| 22:40 | <Philip`> | foolip: http://philip.html5.org/tools/parser/ has a partial parser with readable code |
| 22:40 | <foolip> | yeah, I've tried that before, but assume that "old and unfinished and broken" is true |
| 22:41 | <Philip`> | It is :-) |
| 22:41 | <Dashiva> | http://www.engadget.com/2009/10/10/t-mobile-we-probably-lost-all-your-sidekick-data/ |
| 22:41 | <Dashiva> | "oops" |
| 22:42 | <Philip`> | It could be made to work, but I expect it would take quite a bit of effort :-( |
| 22:42 | <Philip`> | (Most of the work could be reusable for generating parsers in other languages though) |
| 22:45 | <Philip`> | Dashiva: With all this talk of cloud computing, I presumed someone would have noticed that atmospheric clouds tend to be quite short-lived phenomena |
| 22:45 | <Dashiva> | Or, you know, that backups are a good idea |
| 22:46 | <Philip`> | (Actually, how do clouds die?) |
| 22:46 | <Dashiva> | How can you kill that which has no life? |
| 22:47 | <Philip`> | (Do they usually precipitate away, or do they just disperse or something?) |
| 22:47 | <Philip`> | (Wikipedia doesn't seem to have any details on the full lifecycle of a cloud) |
| 22:47 | <Philip`> | Dashiva: I was speaking metaphorically :-p |
| 22:48 | <Philip`> | Anyway, zombies aren't alive and you can kill them with cricket bats |
| 22:48 | <Dashiva> | I think the proper term is deanimate |
| 22:50 | <Philip`> | During a zombie invasion, I bet you'd be shouting "kill them!" and not "deanimate them!" |
| 22:50 | <Dashiva> | Sure, but proper rules are the first victims of any war |
| 22:50 | <Dashiva> | Especially the zombie apocalypse kind |
| 22:54 | <Dashiva> | "This multicell cloud structure exists until a cold downdraft preceding the cumulonimbus at ground level flows before the cloud at a distance sufficient to disrupt updraft (5–10 kilometers). From this moment on the cumulonimbus cloud quickly degrades and dissipates, forming cirrus spissatus, dense anvil-like cirrus, stratocumulus diurnalis or stratocumulus vesperalis." |
| 22:57 | <Philip`> | Well, duh |
| 22:58 | <Philip`> | I thought that was obvious |
| 22:59 | <Philip`> | but that's just saying how they change, not how they finally disappear |
| 23:19 | <Dashiva> | Philip`: Just apply the same method to the resulting cloud until the result isn't a cloud anymore :) |
| 23:24 | <Philip`> | Dashiva: But that method will result in an infinite number of clouds |
| 23:25 | <Philip`> | which is clearly not the answer, because we would all drown |
| 23:25 | <Dashiva> | Well, the results aren't always clouds |
| 23:25 | <Philip`> | Okay, an infinite number of clouds plus a lot of anvils |
| 23:25 | <Philip`> | if I'm reading your quote correctly |
| 23:26 | <Dashiva> | No, no |
| 23:26 | <Dashiva> | The quote only describes the result when input is cumulonimbus |
| 23:26 | <Dashiva> | A dissipating cirrus spissatus would result in something else |
| 23:27 | <Philip`> | Could you be more specific? |
| 23:27 | <Philip`> | For all I know, it results in another cumolonimbus, twice the size of the original one |
| 23:29 | <Dashiva> | Philip`: I don't think that jives with "dissipating" |