| 07:28 | <mitsuhiko> | is there a way to tell the html5lib sanitizer to strip script tags instead of escaping them? |
| 07:28 | <mitsuhiko> | i have to aggregate some blog posts that are using digg/reddit buttons .) |
| 08:18 | <zcorpan> | hello internet |
| 08:24 | <hsivonen> | zcorpan: hello! |
| 08:25 | <zcorpan> | hi hsivonen |
| 08:25 | <zcorpan> | what have i missed? |
| 08:42 | <hsivonen> | zcorpan: ARIA discussion for starters |
| 08:43 | <hsivonen> | zcorpan: also, FPWD publication has been delayed over charter and patent policy concerns |
| 08:46 | <zcorpan> | fun |
| 09:34 | <mitsuhiko> | is the conversion between <font size="..."> to css em/% defined somewhere? |
| 09:36 | <zcorpan> | css2.1 has something informative, i think |
| 09:37 | <mitsuhiko> | zcorpan: thanks a lot |
| 09:37 | <mitsuhiko> | found it |
| 11:21 | <mitsuhiko> | anyone has a "powered by html5lib" logo? :D |
| 11:41 | hsivonen | is very unhappy about the effects of upgrading to Leopard |
| 11:41 | hsivonen | seeks to do something productive now |
| 11:57 | <mitsuhiko> | hsivonen: i'm switching to the ubuntu ltls soon :) |
| 11:57 | <mitsuhiko> | (next february. until then tiger) |
| 11:58 | <hsivonen> | mitsuhiko: yeah, the point of using Mac OS X is not having to do the kind of tweaking one would do on Ubuntu |
| 11:59 | <hsivonen> | mitsuhiko: so when Leopard starts requiring tweaking, one might as well tweak Ubuntu |
| 11:59 | <mitsuhiko> | i have to tweak my os x more than i tweak my ubuntu |
| 11:59 | <mitsuhiko> | i just say port, mysql, and mud-mousing |
| 12:00 | <hsivonen> | (I'm most unhappy about calendar changes made on my phone no longer syncing to the Mac despite numerous troubleshooting attempts) |
| 12:00 | <hsivonen> | this is the first OS X release that is a step backwards |
| 12:01 | <hsivonen> | looks like the UI fashion reached its peak in Tiger |
| 12:01 | <hsivonen> | the new menubar, folder icons and Dock appearance are all worse than what Tiger had |
| 12:22 | <virtuelv> | does this mean that operating systems have a half-life, where every subsequent release only gets worse? |
| 12:22 | <virtuelv> | Windows peaked with Windows 2000 |
| 12:22 | <virtuelv> | XP was a giant step backwards, and I never installed it |
| 12:23 | <OmegaJunior> | It's an iterative cycle: up, down, up, down, needing continuous feedback. |
| 12:27 | <hsivonen> | virtuelv: I think the data isn't sufficient for predicting a trend |
| 12:28 | <virtuelv> | might be, but both versions of windows since 2k has been downhill |
| 12:48 | <zcorpan> | http://james.html5.org/cgi-bin/parsetree/parsetree.py?source=%3Cdiv%3E%3Cb%3Ex%3C%2Fdiv%3Ey -- i can't find in the spec where it says that the B element should be reopened |
| 13:09 | <zcorpan> | 475 emails to go... from 914 this morning |
| 13:15 | <zcorpan> | no wait, i have more emails left |
| 13:16 | <zcorpan> | 660 |
| 13:17 | <zcorpan> | plus the html5 log i just marked as read without reading it (will use the tracker) |
| 13:19 | <Lachy> | hey zcorpan |
| 13:20 | <Lachy> | zcorpan, where have you been lately? On holidays or something? |
| 13:21 | <zcorpan> | hi Lachy |
| 13:21 | <zcorpan> | yeah, thailand |
| 13:21 | <Lachy> | oh, cool |
| 13:22 | <Lachy> | I made those test case videos you asked for while you were gone, you should have an email about them somewhere |
| 13:22 | <zcorpan> | yep, replied |
| 13:23 | <zcorpan> | they're perfect :) |
| 13:23 | <Lachy> | yeah, almost. There's a few things I need to change in them |
| 14:36 | <zcorpan> | Hixie: about <bdo>, "For example, an HTML+CSS user agent should implement these requirements by implementing the CSS unicode-bidi property." -- is that intended to be a SHOULD? |
| 15:01 | <hsivonen> | oh great. XML 1.0, CSS and HTML5 all have different notions of whitespace |
| 16:47 | <dglazkov> | hello whatwg |
| 16:47 | <dglazkov> | have a question about client-side storage section |
| 16:49 | <zcorpan> | hello dglazkov |
| 16:50 | <dglazkov> | hello zcorpan |
| 16:50 | <dglazkov> | actually, it's about async execution |
| 16:50 | <dglazkov> | specifically, the degree of async execution |
| 16:51 | <dglazkov> | does tx run in: |
| 16:51 | <dglazkov> | a) separate thread |
| 16:51 | <dglazkov> | b) uses setTimeout-style continuation model |
| 17:07 | zcorpan | doesn't really know |
| 17:07 | <dglazkov> | :) me neither |
| 17:37 | <Hixie> | dglazkov:b) |
| 17:37 | <Hixie> | dglazkov: it uses a callback |
| 17:37 | <dglazkov> | great! |
| 17:38 | <dglazkov> | that's easy |
| 17:39 | <Hixie> | yup |
| 17:39 | <dglazkov> | but what about "long epilogue" problem? what if there's a long-running bit of code right after the .transaction is called? |
| 17:39 | <Hixie> | then the sql takes a while to run |
| 17:40 | <dglazkov> | that kind of stinks, don't it? |
| 17:43 | <Hixie> | having any script that takes a long time is likely to block the user's UI, which is far worse anyway |
| 17:44 | <dglazkov> | right |
| 17:45 | <dglazkov> | ok, another quick question: |
| 17:46 | <dglazkov> | what's the utility of having the tx callback? Because it runs asynchronously and calls in turn asynchronous method(s), you can't really control the flow based on the data you're receiving. Couldn't an array of prepared statements be more logical? |
| 17:47 | <dglazkov> | Couldn't => Wouldn't |
| 17:50 | <dglazkov> | this is because of the chaining, isn't it? |
| 17:51 | <dglazkov> | i.e. function(tx) { tx.executeSql(..., function(tx, rs) { .. tx.executeSql() } } |
| 17:55 | <Hixie> | the only reason it's asynchronous is because the method might take a long time, and we don't want to block the UI while the method runs |
| 17:55 | <Hixie> | same reason executeSql() is async |
| 17:56 | <dglazkov> | what would you put in tx callback, other than a list of tx.executeSql statements? |
| 17:57 | <Hixie> | not much |
| 17:57 | <dglazkov> | here's where I am going with this |
| 17:58 | <dglazkov> | if tx callback is replaced with an array of prepared statements, I can execute statements truly asynchronously, without waiting on the main thread to finish |
| 17:59 | <dglazkov> | granted, the results will still be delivered via a queue |
| 17:59 | <dglazkov> | when the thread is done |
| 17:59 | <Hixie> | you could, but i'm not convinced the loss of expressibility is worth the potential performance gain |
| 18:00 | <dglazkov> | me neither -- just providing feedback |
| 18:00 | dglazkov | has a partially working implementation of the updated HTML5 spec |
| 18:00 | <dglazkov> | I will try to share it with the list later this week |
| 18:02 | <dglazkov> | Hixie, are you planning to add workerPool stuff to the HTML5 spec? |
| 18:03 | <Hixie> | yeah, eventually. right now the spec has so many new features I don't want to add stuff, for fear of the browsers getting lost and either giving up or implementing random stuff instead of staying mostly in sync. |
| 18:03 | <dglazkov> | good |
| 18:04 | <Hixie> | worker pools and communication pipes that can carry communication pipes are the two features i'm aware of that are currently waiting |
| 18:05 | <dglazkov> | .. and they are --- by far -- the coolest, IMHO |
| 18:06 | <Hixie> | possibly |
| 18:06 | <Hixie> | offline is probably better imho :-) |
| 18:07 | <dglazkov> | everybody has a favorite pet in the zoo that is HTML5 spec |
| 18:08 | <Hixie> | :-) |
| 18:10 | <dglazkov> | do you have a feeling that a lot of HTML5 spec is really a DOM API? |
| 18:10 | <dglazkov> | I mean, there is a format, and there is a set of APIs |
| 18:10 | <dglazkov> | all in one big pile |
| 18:11 | dglazkov | wants everything neatly in their proper partitions |
| 18:11 | <Hixie> | HTML5 as a platform |
| 18:12 | <Hixie> | which involves two syntaxes, a language, and APIs for that language |
| 18:12 | <Hixie> | splitting the API from the language is artificial and just leads to ambiguities |
| 18:12 | <Hixie> | just look at DOM2 HTML |
| 18:12 | <Hixie> | the spec was originally called Web Applications 1.0, which is probably a more accurate name |
| 18:12 | <dglazkov> | right |
| 18:13 | <dglazkov> | what's wrong with DOM2? |
| 18:14 | <dglazkov> | what I see is a lot of tension on public-html between people who came to work on the format and people who came to work on the APIS |
| 18:15 | <Hixie> | look at the definition of things in DOM2 HTML and then compare them to the detail we have in HTML5 |
| 18:15 | <Hixie> | the DOM2 HTML and HTML4 specs were written by groups of people who didn't want to write markup languages and didn't want to write APIs, respectively |
| 18:16 | <Hixie> | and we ended up with poor APIs and a poor markup language |
| 18:16 | <Hixie> | the two absolutely have to be designed in tandem |
| 18:18 | <othermaciej> | hey y'all |
| 18:18 | <alp> | heya othermaciej |
| 18:18 | <Lachy_> | hi |
| 18:19 | <othermaciej> | to be effective for applications, HTML5 has to include a rich API |
| 18:19 | <othermaciej> | much of the API is tied to the markup |
| 18:19 | <othermaciej> | the idea of separating them does not make sense |
| 18:19 | <othermaciej> | and the charter requires us to do both |
| 18:19 | <othermaciej> | so I don't think it is even really worth thinking about |
| 18:20 | Lachy_ | challenges those who think APIs should be specified in a separate spec from markup, to explain how they would even consider doing that for video, audio and canvas |
| 18:21 | <dglazkov> | ok, how does Web API WG fit into this, then? |
| 18:21 | <Lachy_> | they work together with us where appropriate |
| 18:21 | <dglazkov> | but.. aren't they an attempt to do exactly what you're advocating not to do? |
| 18:21 | <Lachy_> | in fact, we share some of the same members and some web api specs have been taken from older versions of HTML5 spec |
| 18:22 | <Lachy_> | dglazkov, not all APIs need to be specified with markup |
| 18:22 | <Lachy_> | some APIs aren't related to specific markup at all |
| 18:22 | <Lachy_> | like XHR or Window |
| 18:22 | <dglazkov> | like client-side storage spec? |
| 18:23 | <Lachy_> | maybe, but there's also the problem of finding competent editors in webapi to do it |
| 18:25 | <dglazkov> | ah.. |
| 18:26 | <dglazkov> | maybe they can borrow a certain part of Hixie's brain? :) |
| 18:27 | <Hixie> | i don't have the bandwidth to work on two specs |
| 18:27 | <Lachy_> | there's another advantage with doing it within the HTML spec though. a lot more people will review it there |
| 18:27 | <dglazkov> | definitely true, Lachy_ |
| 18:31 | <dglazkov> | thanks for the primer, folks. |
| 20:55 | Hixie | summons othermaciej |
| 20:57 | gsnedders | watches othermaciej appear from a lantern |
| 20:57 | <gsnedders> | (slowly) |
| 20:59 | <Hixie> | woot, it worked |
| 20:59 | <gsnedders> | :D |
| 21:00 | <Hixie> | othermaciej: so, what's wrong with ES ed 3 proposals? I need technical details to do my mojo here. |
| 21:02 | <Lachy_> | Hixie, apparently there are some problems with it degrading gracefully in current implemnetations |
| 21:03 | <gavin__> | what ES ed 3 proposals? do you mean ed 4? |
| 21:03 | <Lachy_> | I don't know much though, I just spoke to him about it briefly earlier and that's what othermaciej said |
| 21:03 | <Hixie> | er right, ed 4 |
| 21:03 | <othermaciej> | Hixie: I'm about to send a review of the language overview whitepaper |
| 21:03 | <Hixie> | ok cool |
| 21:04 | <othermaciej> | Hixie: I am still trying to figure out all the technical issues worth pursuing |
| 21:04 | <othermaciej> | the ones that worry me are: |
| 21:04 | <roc> | http://www.ecmascript.org/es4/spec/incompatibilities.pdf for what it's worth |
| 21:04 | <othermaciej> | 1) does not address compatibility from the "degrades gracefully" perspective |
| 21:04 | <othermaciej> | (easily fixable, I will make a concrete proposal) |
| 21:04 | <othermaciej> | 2) slightly excessive in feature additions, some seem redundant |
| 21:05 | <othermaciej> | (unneeded features are bad for developers, bad for interop, and bad for small devices) |
| 21:05 | <othermaciej> | 3) unclear if it will hurt or improve performance in online implementations (I think this can probably be determined better with some experimentation and maybe some modest spec changes) |
| 21:05 | <othermaciej> | mainly I am worried about wether Brendan will be open to change proposals at all, since he seems to be in defensive mode |
| 21:06 | <gavin> | I'm sure he will be open to concret change proposals |
| 21:06 | <othermaciej> | anyway, I am going to turn this into real specific points |
| 21:06 | <othermaciej> | and proposals |
| 21:06 | <othermaciej> | and we'll see what happens |
| 21:06 | <othermaciej> | I do think the objections so far have not been concrete enough |
| 21:07 | <othermaciej> | anyway, I'm gonna go back to typing in my margin comments on the whitepaper |
| 21:07 | <Hixie> | ok |
| 21:07 | gavin | awaits othermaciej's comments with great anticipation :) |
| 21:08 | <Hixie> | othermaciej: i'm happy to persue very specific technical concerns, i just don't have the bandwidth to figure out what they are myself |
| 21:08 | <othermaciej> | gavin: they are very rough so far - I almost literally typed in my notes in the margins from a printed copy I read on the plane |
| 21:08 | <Hixie> | othermaciej: i look forward to further e-mail |
| 21:08 | <othermaciej> | Hixie: roger that |
| 21:09 | <gavin> | othermaciej: that's fine, I'm still looking forward to seeing them :) |
| 21:18 | <Hixie> | othermaciej: btw does ES4 define the semantics of 'replaceable' properties? |
| 21:19 | <othermaciej> | Hixie: I don't think so - I am not sure ES4 would be the right level to define that in any case |
| 21:20 | <othermaciej> | Hixie: actually, I'm not up to speed on how exactly they act in various browsers |
| 21:20 | <othermaciej> | but it seems like they can be modelled at the ES4 level as an untyped read-write property even though the IDL makes them a typed read-only attribute |
| 21:20 | <othermaciej> | Hixie: investigating how replaceable properties (and shadowing a window property with var) is high on our agenda to investigate though |
| 21:21 | <othermaciej> | I think ggaren is working on it |
| 21:21 | <othermaciej> | I will try to make sure the right thing ends up in the right spec (whether that is Bindings4DOM or ES4) |
| 21:31 | <Hixie> | , |
| 21:32 | <Hixie> | er, "k" even |
| 21:34 | <gsnedders> | similar is meaning really. |
| 21:39 | <Hixie> | so does ES4 require an explicit flag right now to enable it? |
| 21:39 | <Hixie> | as in, type="text/javascript;es4=1" or something? |
| 21:39 | <Hixie> | like e4x in firefox? |
| 21:39 | <Hixie> | cos the whole e4x=1 thing was clearly a failure... |
| 21:40 | <Lachy_> | if there needs to be some switch to turn on es4 features, it should be within the script itsself, not the mime type |
| 21:40 | <Philip`> | Firefox does all the JS1.8 features without an explicit flag, so I assume that's at least part of ES4 |
| 21:41 | <gavin> | there's a proposal for a flag for certain incompatible features to be enabled |
| 21:41 | <gavin> | aiui |
| 21:41 | <Lachy_> | HTML5 fixed the issue with the required <script type=> in HTML4, it would be terrible if it were required anyway just to use es4 |
| 21:41 | <gavin> | it's not required to use es4 |
| 21:42 | <Lachy_> | AIUI, there are problems with hiding the new syntax features from current es3 implementations |
| 21:42 | <Philip`> | Oh, I'm wrong, FF doesn't do 'let' expressions without an explicit flag |
| 21:44 | <Hixie> | gavin: so how does the implementation know whether "yield" is a keyword or not? |
| 21:48 | <gavin> | I don't really know the details |
| 21:48 | <gavin> | https://bugzilla.mozilla.org/show_bug.cgi?id=336376 was landed for Firefox 2, it allows reserved keywords as property names |
| 21:48 | <Hixie> | what i've heard from other people on the committee is that you'd need a flag like type="" |
| 21:49 | <Hixie> | i don't see how else you'd handle something like: function () { var yield = 1; yield; } |
| 21:51 | <gavin> | I really don't know enough about the ES4 proposals to comment |
| 21:51 | <gavin> | http://wiki.ecmascript.org/doku.php?id=discussion:versioning and http://wiki.ecmascript.org/doku.php?id=proposals:versioning seem relevant |
| 21:53 | <gavin> | (I'm not sure whether those accurately reflect current thinking) |
| 21:53 | <gavin> | they seem to be fairly recent |
| 21:53 | <Hixie> | k |
| 21:55 | <Philip`> | http://philip.html5.org/demos/js/jsversion.html - oh, quite a few things need the flag, though quite another few don't |
| 21:56 | <othermaciej> | gavin: giant email sent |
| 21:56 | <othermaciej> | Hixie: it requires a version=4 flag |
| 21:56 | <Hixie> | that sucks giant, and i mean giant, ass |
| 21:56 | <othermaciej> | Lachy_: agreed on in-script switches, I have a specific proposal for that comming semi-shortly |
| 21:57 | <Hixie> | that would basically make it impossible for cross-domain APIs to ever upgrade |
| 21:57 | <Hixie> | brb, cycling to the other building |
| 21:57 | <othermaciej> | Hixie: basically you have to write your script twice if you want to use ES4 features and still work in ES3 browsers |
| 22:05 | <Hixie> | othermaciej: that's not gonna fly |
| 22:05 | <othermaciej> | Hixie: what's not gonna fly? the Big Switch model of compatibility? |
| 22:06 | <othermaciej> | Hixie: I agree that it won't fly and have told Brendan that in so many words on multiple occasions |
| 22:06 | <Hixie> | othermaciej: yes |
| 22:06 | <Hixie> | e4x showed that |
| 22:06 | <Hixie> | though the lack of easy conversion to/from DOM nodes also killed that |
| 22:10 | <Philip`> | E4X almost entirely works without any switch, so that doesn't seem relevant to its success |
| 22:12 | <roc> | I don't think we can draw any conclusions from E4X |
| 22:12 | <hsivonen> | Hixie: was the DOM integration problem a spec problem or an impl problem? |
| 22:12 | <Hixie> | impl |
| 23:30 | <marl> | heya |
| 23:30 | <marl> | those web applications include things like gmail? |
| 23:31 | <Hixie> | yup |
| 23:36 | <marl> | Hixie: is this related to that 'web 2.0' ? |
| 23:38 | <Hixie> | i guess |
| 23:38 | <Hixie> | not sure what web 2.0 is |
| 23:39 | <othermaciej> | web 2.0 should be rescinded, we need to fix all of the compat issues in web 2.1 |
| 23:40 | <roc> | heh |
| 23:41 | <roc> | of course some people think that. "Why are you releasing new features when you haven't fixed all the bugs yet" |
| 23:42 | <othermaciej> | yes, that is a charmingly naiive point of view |
| 23:45 | <Dashiva> | othermaciej: Didn't you get the SP yet? |
| 23:53 | <othermaciej> | SP? |