| 00:23 | <Hixie> | <script charset> |
| 00:23 | <andersca> | roc: looks like there is a bug in that offline app demo |
| 00:23 | <Hixie> | what do we think |
| 00:23 | <Hixie> | do we need it? |
| 00:23 | <roc> | andersca: yeah? |
| 00:23 | <Hixie> | or what |
| 00:23 | <andersca> | roc: I think todo-server.php should be added to the online whitelist |
| 00:24 | <Hixie> | i guess i should look at who is using it |
| 00:24 | <andersca> | roc: otherwise it will fail to load once the page has been cached |
| 00:24 | <roc> | andersca: better let Mark know |
| 00:24 | <andersca> | roc: will do! |
| 00:24 | <roc> | thanks |
| 00:37 | <Lachy> | LOL http://twitter.com/webconverger/statuses/810611186 |
| 01:43 | <andersca> | Hixie? |
| 01:49 | <Hixie> | yo |
| 01:52 | <andersca> | If there is already an application cache identified by this manifest URI, and the most up to date version of that application cache contains a resource with the URI of the manifest, and that resource is categorised as a manifest, then: store the resource in the matching cache, categorised as an implicit entry, associate the Document with that cache, invoke the application cache update process, and abort these steps. |
| 01:52 | <andersca> | Hixie: was it resolved how to handle the load of the implicit resource being cancelled here? |
| 01:53 | <Hixie> | yes |
| 01:53 | <Hixie> | it's in the application cache update process algorithm |
| 01:53 | <Hixie> | step 9 |
| 01:56 | <andersca> | Hixie: ah |
| 01:57 | <andersca> | Hixie: so the end result will be that the document will be associated with the cache |
| 01:57 | <andersca> | Hixie: but the implicit resource will not be in the cache |
| 01:58 | <Hixie> | yeah |
| 01:58 | <andersca> | Hixie: also, what if the load is canceled before the manifest has finished loading |
| 01:58 | <andersca> | cancelled |
| 01:58 | <Hixie> | step 8 |
| 01:58 | <Hixie> | oops, there's a cross-reference error in that paragraph |
| 01:58 | <Hixie> | let me fix that |
| 02:00 | <Hixie> | ok where it says "run just to the caching failure steps" assume it says "run the cache failure steps" and links to the cache failure steps paragraph below |
| 02:00 | <Hixie> | i'm in the middle of an edit so i can't make the change right now |
| 02:03 | <andersca> | OK! |
| 02:03 | <andersca> | Hixie: thanks |
| 02:03 | <Hixie> | np |
| 02:04 | <Hixie> | search for "canceled" in that section, i added it explicitly in a few places (and in a few places, added it explicitly as NOT being something that would trigger failure mode) |
| 02:04 | <Hixie> | as to the end result if you cancel the document and it being associated with the cache anyway -- that seemed the most consistent thing to do |
| 02:05 | <Hixie> | it's what happens if the cache update fails, too |
| 02:29 | <andersca> | Hixie: yeah |
| 02:37 | <jwalden> | mcarter: SSE? |
| 02:40 | <Hixie> | <event-source> |
| 03:11 | <jwalden> | ah |
| 03:11 | <jwalden> | oh, server-sent events |
| 03:12 | jwalden | is dumb |
| 03:12 | jwalden | proposes <interlocution/> |
| 04:01 | <inimino> | foreach ($_FILES["pictures"]["error"] as $key => $error) { |
| 04:01 | <inimino> | if ($error == UPLOAD_ERR_OK) { |
| 04:01 | <inimino> | $tmp_name = $_FILES["pictures"]["tmp_name"][$key]; |
| 04:01 | <inimino> | $name = $_FILES["pictures"]["name"][$key]; |
| 04:01 | <inimino> | move_uploaded_file($tmp_name, "data/$name"); |
| 04:01 | <inimino> | } |
| 04:01 | <inimino> | erm, sorry |
| 04:01 | <inimino> | disregard that... |
| 04:33 | <MikeSmith> | Hixie: just now read back to your ping about the http://www.w3.org/2000/11/DOM-Level-2-errata.html doc |
| 04:34 | <MikeSmith> | cvs log shows plehegar was the one to make the latest edit to it |
| 04:35 | <othermaciej> | oh hmm I did not realize there were errata up |
| 04:35 | <MikeSmith> | I wonder whether maybe ownership of that doc should move the Web API WG |
| 04:36 | <othermaciej> | it should, if Web API WG doesn't own it already |
| 04:37 | <othermaciej> | though really I'd rather see a redone DOM Core 3 w/ conformance requirements stated properly and bogus non-browser-relevant stuff removed or moved to an appendix |
| 04:38 | <MikeSmith> | othermaciej: yeah, but short of that I reckon that we ought to keep that errata up to date |
| 04:39 | <MikeSmith> | unless/until we get something done that supersedes it |
| 04:39 | <othermaciej> | I guess DOM levels don't supersede each other |
| 04:39 | <othermaciej> | though when HTML5 comes out it should obsolete the older HTML DOM specs |
| 04:40 | <MikeSmith> | yeah |
| 04:44 | <MikeSmith> | For now, I'm assuming Hixie has a specific change that needs to be made. For record-keeping purposes, perhaps the process we should follow is to send a heads-up about it to the Web API mailing list, decide what the wording should be, record some resolution that we agreed it needed to be changed, then Doug or I can add it to that page. |
| 04:52 | <othermaciej> | MikeSmith: I vaguely recall that there was some minor inconsistency between DOM2 Core and DOM3 Core about exceptions |
| 04:52 | <othermaciej> | which should probably be errata'd |
| 04:52 | <othermaciej> | one of the dom 2 core test suite tests checks for it (though weirdly checks for the dom3 behavior) |
| 04:53 | <MikeSmith> | othermaciej: please write something up about it if/when you have time, send to public-webapi⊙wo |
| 04:53 | <othermaciej> | yeah, I'll have to find what the issue is |
| 04:56 | <Hixie> | MikeSmith: so you recommend mailing public-webapi⊙wo and what, getting wg consensus somewhow? |
| 04:57 | <Hixie> | i guess that works |
| 05:00 | <MikeSmith> | Hixie: yeah, if it's an obvious erratum, I think it's not so much a matter of getting consensus, it's more just having a record in the list archives that a new change was made and when |
| 05:01 | <Hixie> | k |
| 05:10 | <MikeSmith> | Hixie: btw, do you have a rough idea of when you might add section, header, footer, etc. to the parsing algorithm? |
| 05:11 | <Hixie> | probably the next time i work on the parser |
| 05:11 | <Hixie> | since i've added mathml now there's not much point delaying further |
| 05:11 | <MikeSmith> | OK, I ask just because of the issue of html5lib reporting "Undefined behaviour for end tag" for those |
| 05:12 | <Hixie> | yeah |
| 08:10 | <annevk> | vlad_, pong... |
| 08:10 | annevk | wonders if vlad_ is still awake, now it's 0:00 over there :D |
| 08:30 | <jwalden> | annevk: Opera needs to implement Date.now(), defined as function() { return new Date().getTime(); } -- I think you'd be the remaining non-IE browser without it given WebKit added support earlier today :-) |
| 08:31 | <weinig> | annevk: you haven't by any chance written any tests for the Access Control spec have you? |
| 08:32 | <Hixie> | so people want <script type="some proprietary stuff">...</script> to be a conforming way of smuggling proprietary data into a web app |
| 08:33 | <virtuelv> | jwalden: mind filing a bug on that, and give me the bug number? |
| 08:33 | <jwalden> | virtuelv: point me to a location and I will |
| 08:33 | <Hixie> | i wonder what to do abotu that |
| 08:34 | <virtuelv> | jwalden: https://bugs.opera.com/wizard |
| 08:35 | <annevk> | weinig, not yet, sorry |
| 08:35 | <weinig> | annevk: ok, no worries |
| 08:35 | <annevk> | ah, vlad requests that web-apps-tracker has an option to "strip" HTML from the diff |
| 08:36 | <annevk> | if anyone has time to implement that in a way that does not expose us to script injection attacks from Hixie, feel free :) |
| 08:36 | <Hixie> | btw anne |
| 08:37 | <Hixie> | i noticed the gears icons aren't showing properly |
| 08:39 | <annevk> | hmm, all those change requests to access control |
| 08:40 | <annevk> | if it doesn't stop i might argue for some more simplification of the server side syntax |
| 08:45 | <jwalden> | virtuelv: filed as bug 329986 |
| 08:45 | <annevk> | Hixie, browsers support type=text/javascript1.3 too |
| 08:46 | <annevk> | Hixie, some do anyway |
| 08:46 | <Hixie> | really? |
| 08:46 | <Hixie> | oh |
| 08:46 | <Hixie> | well then |
| 08:46 | <annevk> | i think that makes more sense |
| 08:46 | <Hixie> | i can just strip all that crap then |
| 08:48 | <virtuelv> | jwalden: thanks |
| 08:48 | <jwalden> | virtuelv: I think that goes both ways -- speed and arithmetic usage improvements will be welcome :-) |
| 08:53 | <virtuelv> | jwalden: I presume (but can't actually promise, since it's not my call) that this will be trivial to add |
| 08:54 | <jwalden> | implementation-wise I have very little doubt it is, the question's resource allocation and prioritization |
| 08:55 | <annevk> | weinig, Hixie, since we have Access-Control-Origin, maybe having a space separated list of URIs from which requests are allowed (only checking the origin bits, similar to postMessage) is enough for the Access-Control / <?access-control?> case |
| 08:55 | <Hixie> | hm? |
| 08:55 | <Hixie> | what's the problem? |
| 08:56 | <annevk> | Access-Control: <http://opera.com:800>; <https://w3.org/ignored>; |
| 08:56 | <annevk> | it being quite complicated currently |
| 08:56 | <Hixie> | what's wrong with what we have now |
| 08:56 | <Hixie> | i thought we needed deny rules |
| 08:56 | <Hixie> | did we decide to get rid of the use cases for that? |
| 08:57 | <annevk> | deny rules are gone anyhow |
| 08:57 | <Hixie> | (and ignoring stuff in something security related is dangerous -- fail, don't ignore) |
| 08:57 | <Hixie> | they are? |
| 08:57 | <weinig> | annevk: exclude is the new deny |
| 08:57 | <Hixie> | so what does it look like now? |
| 08:57 | <Hixie> | that's what i meant by deny |
| 08:57 | <annevk> | oh ok |
| 08:57 | <weinig> | annevk: what about the wildcarding? |
| 08:58 | <annevk> | now we have Access-Control: allow <*.opera.com:*> <*.w3.org> exclude <evil.opera.com> |
| 08:58 | <annevk> | i guess it isn't too bad either |
| 08:59 | <Hixie> | i don't understand why we suddenly want to get rid of exclude rules |
| 08:59 | <annevk> | the main thing is that the majority case is probably whitelisting a few domains or using * and not doing anything this complex |
| 08:59 | <annevk> | and the real complex cases can be done using Access-Control-Origin |
| 09:00 | <Hixie> | well i'm all for making things simpler, but then i have to wonder why we didn't do them simple in the first place |
| 09:00 | <Hixie> | getting rid of "exclude" (and removing the "allow" keyword) is fine by me |
| 09:01 | <Hixie> | we still need the wildcards though |
| 09:01 | <annevk> | Hixie, wildcards for domains? |
| 09:01 | <Hixie> | protocols, domains, and ports |
| 09:01 | <Hixie> | same as now |
| 09:02 | <Hixie> | i'm just talking about just dropping the "exclude" part and the "allow" keyword |
| 09:03 | <annevk> | ok |
| 09:04 | <annevk> | i guess still allowing 'example.org' isn't too much trouble then either |
| 09:04 | <Hixie> | it's not trouble at all, you've already specified it |
| 09:04 | <annevk> | :) |
| 09:05 | <Hixie> | every time you make a change to a specification that isn't a change that fixes an actual error or that adds a new important feature, you lose a bit of credibility as a spec editor |
| 09:05 | <Hixie> | churn is bad |
| 09:05 | <Hixie> | people get frustrated if the spec keeps changing in non-obvious ways for apparently no reason |
| 09:07 | <Hixie> | especially when they have already implemented it |
| 09:07 | <annevk> | true, i'm just trying to figure out if we can reduce complexity because people have been complaining about that and i sort of agree it's quite complex |
| 09:07 | <Hixie> | i'd concentrate on getting the header story straightened out before worrying about that :-) |
| 09:08 | <annevk> | and given that the implementors (apart from WebKit so far) have been proposing changes as well during implementation... |
| 09:08 | <weinig> | I am not sure I see the benefit to users of removing exclude, as it is already optional |
| 09:08 | <annevk> | for instance, now Mozilla wants header/method opt-in |
| 09:08 | <annevk> | weinig, yeah, I guess i'll just keep all that in |
| 09:09 | <weinig> | ok |
| 09:09 | <Hixie> | did sicking ever send the second e-mail he said he would send? |
| 09:10 | <weinig> | annevk: what do you mean by header/method opt-in? |
| 09:10 | <annevk> | Hixie, no, he hasn't |
| 09:10 | <Hixie> | odd |
| 09:11 | <annevk> | weinig, http://lists.w3.org/Archives/Public/public-appformats/2008May/0034.html |
| 09:11 | <weinig> | ah, I list I am not on :) |
| 09:12 | <annevk> | access-control / xhr2 is currently developed on two separate lists unfortunately :( |
| 09:12 | <annevk> | once people get their act together it will be on one, but i'm not sure how long that'll take |
| 09:15 | <weinig> | will read the relevant back log of that list tomorrow |
| 09:17 | Philip` | forgets why <dialog> can't just be spelt as <dl> |
| 09:19 | takkaria | boggles what happened to the alt thread overnight |
| 09:19 | <othermaciej> | annevk: hmm, I don't get how "Access-Control-Extra-Headers" addresses the stated problem |
| 09:20 | <othermaciej> | annevk: doesn't XHR2+AC already whitelist to a short list of headers? |
| 09:20 | <othermaciej> | or am I confused? |
| 09:20 | <othermaciej> | I guess I should get on public-appformats |
| 09:22 | <Hixie> | Philip`: different content models, different basic idea |
| 09:22 | <Hixie> | Philip`: a dialog is not a set of one-or-more-names/one-or-more-values tuples |
| 09:23 | <Hixie> | though maybe it should allow multiple names per "quote" |
| 09:25 | <annevk> | othermaciej, it whitelists a short list of headers for the request, but if you go outside that list and the server responds positively to a preflight request the headers will get through |
| 09:25 | <annevk> | (apart from the blacklisted headers of course) |
| 09:26 | <othermaciej> | annevk: ok I see |
| 09:26 | <Philip`> | Hixie: Since you removed the new bit about language=javascript1.x, where is that handled now? |
| 09:27 | <Hixie> | see mail to public-html |
| 09:27 | <Hixie> | it's handled by turning it into type=text/language/javascript1.x |
| 09:27 | <Hixie> | which browsers support already |
| 09:27 | <annevk> | well, some do |
| 09:27 | <annevk> | such as WebKit iirc |
| 09:28 | <Philip`> | I think my point was that it's not obvious to a UA implementor that they should support those in addition to text/javascript |
| 09:28 | <Hixie> | ah well maybe we should update the relevant rfc |
| 09:28 | <Hixie> | it needs updating anyway, right now it dumbly obsolete text/javascript |
| 09:28 | <Philip`> | The "Scripting languages" section already mentions "text/javascript", so it'd be helpful for implementors if that mentioned the typical aliases too |
| 09:28 | <Hixie> | and it doesn't define the e4x parameter, and it looks like the ES4 group is planning on making all kinds of mistakes with a version= parameter, too, which will also need defining |
| 09:29 | <Hixie> | yeah, that could work |
| 09:29 | <Hixie> | reply to the thread :-) |
| 09:29 | <Philip`> | Hixie: By "see mail to public-html", do you mean the mail which says "Done" when actually the final result to the spec was no change? :-) |
| 09:30 | <Hixie> | no, the reply to that one |
| 09:31 | <Philip`> | I don't see a reply |
| 09:31 | <Philip`> | ...but that's not your problem |
| 09:31 | <Hixie> | http://lists.w3.org/Archives/Public/public-html/2008May/0292.html |
| 09:31 | <Philip`> | since it's just the list/Gmail being slow |
| 09:37 | <takkaria> | I'd forgotten quite how frustrating being a participant in the alt debate is |
| 09:37 | <Hixie> | i'd forgotten why i never reply in real time to threads |
| 09:37 | <annevk> | <interplay> |
| 09:37 | <Hixie> | i'm now relearning this with the <dialog> issue |
| 09:37 | <takkaria> | :) |
| 09:39 | <Hixie> | ok |
| 09:39 | <Hixie> | you may now vote on the next thing i work on |
| 09:39 | <Hixie> | should it be: |
| 09:39 | <Hixie> | <iframe> features |
| 09:39 | <Hixie> | or |
| 09:39 | <Hixie> | <video> |
| 09:39 | <Hixie> | you decide! |
| 09:39 | <takkaria> | video! |
| 09:40 | <takkaria> | I hope you're not expecting rationales |
| 09:41 | <annevk> | are we going to add <iframe> features for HTML5? |
| 09:41 | annevk | is silently hoping we push the sandbox issue out of HTML5 |
| 09:41 | <annevk> | hah, so much for silently |
| 09:42 | <Hixie> | i'm expecting us to add iframe sandboxing features |
| 09:42 | <othermaciej> | I have heard someone from Microsoft claim that <iframe> is not a strong enough sandbox as-is and therefore iframe+postMessage was not a good enough solution for "mashups" |
| 09:43 | <othermaciej> | but he refused to say what the specific issues are |
| 09:43 | <othermaciej> | (why does this sound so familiar?) |
| 09:43 | <annevk> | parent.location.href = '...' is an issue |
| 09:43 | <Hixie> | in particular see the end of http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-May/011198.html for what i expect to look at adding |
| 09:43 | <annevk> | (from Douglas Crockford) |
| 09:44 | <othermaciej> | Hixie: <script sandbox="">? |
| 09:44 | <Hixie> | ? |
| 09:44 | <othermaciej> | I hope that's not the proposal you expect to look at adding |
| 09:45 | <Hixie> | "the end of" was a key part of what i wrote just now :-) |
| 09:45 | <othermaciej> | then I have a lot of reading to do to get to the bottom! |
| 09:46 | <Hixie> | sorry :-) |
| 09:46 | <Hixie> | my bit starts from the line that just says "PROBLEMS" |
| 09:46 | <annevk> | you could just press "End" |
| 09:46 | <Hixie> | the rest is me mostly telling people their ideas suck |
| 09:46 | <Hixie> | (about 70% down) |
| 09:46 | <Hixie> | aybe 60% |
| 09:48 | <othermaciej> | Hixie: I think you dismissed the md5= possibility too readily - you just keep reading characters until the checksum matches, that works even if the content contains a malicious </sandbox> |
| 09:48 | <othermaciej> | faking the hash is a risk |
| 09:48 | <othermaciej> | another possibility is to require a psuedo-attribute on the end tag |
| 09:49 | <othermaciej> | <sandbox token="13498564123"><!-- that was a random number --> </sandbox token="13498564123"> |
| 09:49 | <Hixie> | yeah i believe i have that feedback from you in the pile |
| 09:50 | <othermaciej> | I don't remember if I said this specific stuff before |
| 09:50 | <othermaciej> | though I vaguely remember this being discussed |
| 09:51 | <Philip`> | <sandbox13498564123><!-- now you don't even have to change the parser much --></sandbox13498564123> |
| 09:51 | <othermaciej> | client-side filtering of script could be done with less chance of time-of-check time-of-use errors, since browsers know exactly when they will run script |
| 09:51 | <othermaciej> | Philip`: or use a colon |
| 09:51 | <Philip`> | othermaciej: I assume this ought to work in XHTML too |
| 09:51 | <othermaciej> | <sandbox:13498564123><!-- now you don't even have to change the parser much --></sandbox:13498564123> |
| 09:52 | <othermaciej> | Philip`: I am not sure premature close is the same kind of problem in XHTML since it renders the document not well formed |
| 09:52 | <othermaciej> | Philip`: but I guess scripts could have run by the time you find that out |
| 09:52 | <annevk> | all this sandboxing seems rather fragile |
| 09:52 | <othermaciej> | and I'm sure Hixie won't want to invent a sandbox: namespace |
| 09:53 | <Hixie> | the biggest problem with a checksum thing is that if you get it wrong, your document ends up all in the sandbox |
| 09:53 | <Hixie> | well maybe no the biggest problem |
| 09:53 | <Hixie> | a big problem |
| 09:53 | <othermaciej> | annevk: basically the main benefit is that it lets sites be lazy and not do whitelist content filtering; and it avoids the possibility of a whitelist that is too lenient |
| 09:53 | <Philip`> | othermaciej: You should be able to take any HTML document and reserialise it as XHTML without any fancy transformations, even if some of the HTML features are redundant in XML, otherwise hsivonen will be unhappy |
| 09:54 | <Hixie> | not being able to provide this feature in xhtml is not imho any kind of blocker |
| 09:54 | <Hixie> | :-) |
| 09:54 | <othermaciej> | Hixie: my idea and Phillip's variant both do not have the possibility of getting a checksum wrong (though it is possible the magic random token will be copied wrong) |
| 09:54 | <Hixie> | othermaciej: how so? |
| 09:55 | <othermaciej> | there is no checksum |
| 09:55 | <othermaciej> | the token is arbitrary - the defense is that hostile content cannot predict it |
| 09:55 | <Philip`> | I assume XHTML5 would still want the safe script sandbox behaviour, even though the parser issue is only relevant for HTML |
| 09:55 | <Hixie> | othermaciej: oh the random number idea doesn't work at all, you're totally dependent on the site making unpredictable choices of random numbers |
| 09:56 | <Hixie> | othermaciej: given that we couldn't even depend on openssl's security experts making unpredictable ssl certs, i don't think we can rely on joe author making unpredictable magic numbers |
| 09:56 | <annevk> | and if people are allowed to edit their comments you would have to regenerate the magic number and you might forget to do that, etc. |
| 09:57 | <othermaciej> | generating a random number is certainly something you can fail at, but so is whitelist content filtering (the current best practice for injecting unknown content) |
| 09:57 | <zcorpan> | i know a name for <dialog>... <dl> |
| 09:57 | <zcorpan> | short for DiaLog |
| 09:57 | <zcorpan> | (or DiaLogue) |
| 09:57 | <othermaciej> | zcorpan: cute |
| 09:58 | <Hixie> | othermaciej: whitelist filtering is far easier to understand than random number generation, which is basically a black art |
| 09:59 | <Philip`> | Hixie: OpenSSL's security experts did it right, it was just the Debian developers who commented out all the entropy |
| 10:00 | <Hixie> | Philip`: for the recent case, yeah, but wasn't there a case long ago that was a real bug? |
| 10:00 | <Philip`> | Hixie: Oh, no idea |
| 10:00 | <Hixie> | Philip`: or alternatively, consider than win2k, winxp, and vista all had a system RNG that was proved predictable after something like 8 years |
| 10:00 | <othermaciej> | Hixie: well on Mac OS X you just call arc4random, but yeah you can screw it up |
| 10:01 | <othermaciej> | though a random token, unlike a checksum, would be easily fixable w/ no browser changes needed in case the algorithm is found to be vulnerable |
| 10:02 | <othermaciej> | though I guess it could turn comment spam into a CPU hogging attack generating all that entropy |
| 10:02 | <othermaciej> | anyway, I am not sure safe markup injection via a client-side feature is feasible, but if it were there would clearly be some advantages |
| 10:02 | <Philip`> | You'd probably generate the entropy on (uncached) page views, not on comment posting |
| 10:03 | <Philip`> | s/generate/use/ |
| 10:03 | <othermaciej> | Philip`: I don't think you would want to generate a different random number every time, though maybe every time you generate the page if you cache static copies |
| 10:03 | <Philip`> | Fortunately thermodynamics guarantees that entropy won't decrease, so you'll never permanently run out |
| 10:05 | <othermaciej> | thank goodness |
| 10:06 | <zcorpan> | Hixie: experience with <address> should suggest that the element name matters more than its definition in terms of what authors will use it for |
| 10:06 | <othermaciej> | Hixie: styles cascading through a browsing context boundary (wait, do you mean cascading or inheriting or both) sounds like an interesting implementation challenge |
| 10:07 | <othermaciej> | Hixie: I do like <iframe noscript> and <iframe restrict> though (well, depending on specific restrictions) |
| 10:08 | <othermaciej> | Hixie: though restrict seems better for embedded "gadgets" than for comment fields |
| 10:08 | <Hixie> | yeah the stuff at the end is mostly just random ideas |
| 10:09 | <Hixie> | i haven't thought through exactly what the needs are |
| 10:11 | <othermaciej> | I think the real answer to the JSON case is cross-site XHR plus a native JSON API |
| 10:12 | <othermaciej> | trying to run scripts in the same browsing context but with special restrictions sounds like disasterville |
| 10:12 | <othermaciej> | I know you agree and all |
| 10:12 | <othermaciej> | I just had to say it |
| 10:15 | <jgraham> | Hixie: FWIW I think zcorpan is right, and I think enough people have complained about <dialog> to suggest it is a real issue |
| 10:15 | <Hixie> | what was the JSON case again? |
| 10:15 | <Hixie> | jgraham: the difference is that you could use <address> to include an address and nothing would go wrong. Using <dialog> for a dialog box makes no sense. |
| 10:16 | <zcorpan> | Hixie: makes about as much sense to me as using <div class=dialog> |
| 10:17 | <zcorpan> | Hixie: consider that dialog boxes would mostly be scripted and so would bypass validation |
| 10:17 | <jgraham> | Well nothing will happen but then nothing happens when you use <nav> for navigation either |
| 10:17 | <Hixie> | i don't understand what <div class="dialog"> would do either |
| 10:17 | <othermaciej> | Hixie: people embed semi-untrusted off-site script to transfer JSON data (the script is expected to just assign to a var) |
| 10:17 | <jgraham> | People are used to the idea that elements exist for no function other than "semantics" |
| 10:17 | <zcorpan> | Hixie: it wouldn't do anything except provide a hook for scripting and styling for the author to implement the dialog box |
| 10:21 | <zcorpan> | Hixie: (i'm just being a bitch here, i actually couldn't care less about the name) |
| 10:23 | <Hixie> | othermaciej: xhr2 is the solution to that |
| 10:24 | <Hixie> | jgraham: well i'd use a better name, but frankly i haven't seen one that wouldn't have worse problems than <dialog> |
| 10:24 | <Hixie> | zcorpan: :-) |
| 10:24 | <othermaciej> | Hixie: I mention native JSON API because ideally people would also stop using eval for this purpose (sometimes, awfully enough, eval without the proper preflight regexp) |
| 10:24 | <zcorpan> | Hixie: what's the problem with <dl>? |
| 10:26 | <Lachy> | Hixie, you could just allow <dl> to be used for dialog as well, and drop <dialog> |
| 10:26 | <jgraham> | Hixie: I know all the alternatives suck in their own special ways :( |
| 10:26 | <Hixie> | othermaciej: i recommend xml :-) |
| 10:26 | <othermaciej> | Hixie: no you don't |
| 10:26 | <Hixie> | zcorpan: it's inappropriate? it'd be like using <ol> for a set of paragraphs |
| 10:26 | <Hixie> | othermaciej: over json? sure it do |
| 10:26 | <Hixie> | i |
| 10:26 | jgraham | dislikes <dl> even more than <dialog> |
| 10:26 | <othermaciej> | I meant, generally speaking |
| 10:27 | <zcorpan> | Hixie: why is it inappropriate if the spec says it's appropriate? |
| 10:27 | <Hixie> | othermaciej: for proprietary sending data across servers, xml is often a fine thing |
| 10:27 | <Lachy> | how about <transcript> |
| 10:27 | <othermaciej> | I think JSON is nicer than XML for dumb data though to be fair adding a native API misses the point that it was just a built-in language construct |
| 10:27 | <jgraham> | <transcript> sounds pretty nice, although it's not strictly right |
| 10:27 | <Hixie> | zcorpan: because it would be dumb for hte spec to say it's appropriate. it'd be like using <ol> for lists and paragraphs, or something equally bogus |
| 10:28 | <Lachy> | nah, that's work too well |
| 10:28 | <Hixie> | othermaciej: well, maybe. not html5's problem, either way. |
| 10:28 | <othermaciej> | I'll agree with that |
| 10:35 | <Hixie> | i'm more tired than i should be at this time, so i'll just go to bed. |
| 10:35 | <Hixie> | nn! |
| 12:26 | <zcorpan> | annevk: can html5.org please link to the tracker? |
| 12:31 | <zcorpan> | i wonder if the requirement that <script src> elements must be empty is helpful or not |
| 12:32 | <zcorpan> | i've seen pages that use comments in <script src>, either <!--pseudo-comments--> or /* js comments */ |
| 12:33 | <Dashiva> | It keeps the future open for allowing something there? |
| 12:34 | <gsnedders> | Dashiva: But that'd need be defined in HTML 2π, so requiring it to be empty in HTML 5 changes nothing |
| 12:34 | <zcorpan> | Dashiva: i don't think so -- html4 allows stuff there and people don't care whether the spec allows it or not anyway |
| 12:34 | gsnedders | really hopes the next revision _is_ 2π |
| 12:35 | <zcorpan> | Dashiva: what would you allow there in the future anyway? |
| 12:36 | <Dashiva> | zcorpan: Nested script elements for fallback |
| 12:36 | <zcorpan> | Dashiva: that doesn't work in legacy browsers so not particularly good fallback story |
| 12:37 | <zcorpan> | Dashiva: <script type=unknown>..</script> <script> fallback </script> works |
| 12:37 | <Dashiva> | zcorpan: Not if you support both scripts |
| 12:37 | <zcorpan> | Dashiva: they might be able to communicate with each other |
| 12:37 | <zcorpan> | Dashiva: so the new script can set a flag that it has executed |
| 12:37 | <Dashiva> | That's a big might |
| 12:38 | <zcorpan> | maybe but <script type=unknown> .. <script> fallback </script> </script> is guarenteed to *not* work |
| 12:39 | <Dashiva> | You're nesting the wrong way |
| 12:40 | <Dashiva> | Old browsers ignore the contents, so they use the outer element's src. New browsers check the contents for another script element and use that if possible |
| 12:40 | <zcorpan> | nesting doens't work either way |
| 12:41 | <zcorpan> | Dashiva: script is cdata parsing, can't have elements in there at all. changing that would break legacy content |
| 12:41 | <Philip`> | Dashiva: That might hurt with <script language=unknown>/* legacy content */ document.write('<script>'); </script> |
| 12:42 | <Dashiva> | Philip`: This is only with @src |
| 12:42 | <Philip`> | Ah |
| 12:43 | <zcorpan> | i'd rather design a new script language for the web in such a way that it's possible to communicate with javascript |
| 12:44 | <zcorpan> | (like flash can communicate with javascript, at least i think it can) |
| 12:44 | <annevk> | zcorpan, added |
| 12:44 | <zcorpan> | annevk: thanks |
| 12:47 | <zcorpan> | Dashiva: in practice, authors just put harmless stuff in there and the validator will complain about it, and they have to move the comment out of the script element, which seems pointless |
| 12:48 | <zcorpan> | Dashiva: moreover, if the legacy script is external, why not let the new script be external too and have another attribute for the new script? |
| 12:48 | <zcorpan> | <script src=fallback newsrc=new> |
| 12:48 | <Dashiva> | zcorpan: And duplicate all the other attributes as well? |
| 12:49 | <zcorpan> | Dashiva: what other attributes? |
| 12:50 | <Dashiva> | You'd want type, to make sure you actually support the new script. |
| 12:51 | <zcorpan> | why? |
| 12:51 | <zcorpan> | you know you support it since you support the newsrc='' attribute |
| 12:52 | <zcorpan> | of course this doesn't scale to many new scripting languages |
| 12:52 | <zcorpan> | btw, can vbscript talk to javascript? |
| 12:52 | <Dashiva> | Well, yeah, if you make one new src for each language, that'd work, but that's kinda crazy :) |
| 12:53 | <zcorpan> | let's solve this problem when a new scripting language actually is introduced :) |
| 12:54 | <Dashiva> | But until then, keeping our script elements neat and tidy doesn't hurt :P |
| 12:55 | <zcorpan> | Philip`: whenever you're bored enough, could you dig for data about pages that use <script src>..nonwhitespace..</script> ? :) |
| 13:01 | <zcorpan> | btw, <script src=my-interpreter id=myscript>my custom syntax script</script> could work |
| 13:02 | <zcorpan> | instead of <script type=my/custom>syntax script</script> <script src=my-interpreter></script> |
| 13:02 | <zcorpan> | (with id..) |
| 13:04 | <zcorpan> | although i guess that's less intiutive and so authors don't do it anyway, so might be pointless to allow it |
| 13:27 | <Philip`> | I would guess the most common case of content in srced scripts is when people write <script src="..." />[rest of page content] |
| 13:29 | <zcorpan> | Philip`: i guess it would be interesting to know how common that is too :) |
| 13:30 | Philip` | wishes Eclipse didn't crash immediately after loading |
| 13:56 | Philip` | has too many pages to process them all in a reasonable time :-( |
| 13:58 | <Philip`> | Ah, only 10424 left |
| 14:01 | <Philip`> | zcorpan: http://philip.html5.org/data/nonempty-scripts.html |
| 14:15 | <zcorpan> | Philip`: thanks! |
| 14:16 | <zcorpan> | ah, ";" is something i've seen as a way to prevent xslt to convert it to <script src='...'/> |
| 14:20 | <Philip`> | A couple of princeton.edu pages have a literal nbsp character inside their <script> |
| 14:20 | <Philip`> | I don't know if that's for the same kind of reason |
| 14:23 | <zcorpan> | i wonder if http://weather.noaa.gov/cgi-bin/iwszone?Sites=:njz024:njz023 put tags in script as a way to comment them out or if it actually was a mistake to put them there |
| 14:23 | <zcorpan> | they're duplicated before the script tag |
| 14:28 | <zcorpan> | hsivonen: in http://validator.nu/?doc=http%3A%2F%2Fwww.agl1985.org%2F&parser=html5&showsource=yes , group messages and look at "Error: Text not allowed in element script in this context." |
| 14:29 | <zcorpan> | hsivonen: notice that it seems to split up the text node and complain several times about the same <script> element containing text |
| 14:31 | <zcorpan> | i guess that page would be helped by the requirement since it has <script src><script src></script> where it was probably intended to have 2 script elements |
| 14:32 | <zcorpan> | but a conformance checker might be able to detect that anyway |
| 14:32 | <zcorpan> | and give a warning |
| 14:33 | <zcorpan> | i.e., if a script element contains "<script" that is not in an escaped text span |
| 14:36 | <zcorpan> | i guess authors would be stumped when the validator says to (re)move "/* ... This notice MUST stay intact for legal use ... */" |
| 15:15 | <hsivonen> | zcorpan: thanks. that's an undesirable but technically understandable feature of Jing |
| 15:15 | <hsivonen> | zcorpan: I'll see what I can do about it |
| 15:46 | <hsivonen> | <discourse> might actually be better than <dialog> |
| 15:50 | <Philip`> | Maybe it'd be better to drop the element entirely, since very few people will ever use it |
| 15:50 | <hsivonen> | oh sure |
| 15:51 | <Philip`> | When people are arguing over the colour of the bikeshed, the simplest solution is a bulldozer |
| 16:10 | <hsivonen> | which reminds me that I want the SVG parsing stuff unbulldozed |
| 16:10 | <shepazu> | then help out |
| 16:11 | <shepazu> | we aren't bulldozing, we are working on a proposal |
| 16:11 | zcorpan | would like to have a list of requirements and a list of objections to the proposal that was in the spec |
| 16:13 | <zcorpan> | or rather i think it would be helpful for the interested parties |
| 16:14 | <Philip`> | shepazu: Is that work happening anywhere open/public? |
| 16:15 | <shepazu> | http://www.w3.org/Graphics/SVG/WG/wiki/SVG_in_text-html |
| 16:16 | <shepazu> | mind, I've been on vacation for the last 2 weeks |
| 16:17 | <shepazu> | and I prefer the previous revision |
| 16:19 | <Philip`> | "Should be able to take a conforming SVG document and paste its contents into an HTML document and have it be the same DOM" - is that talking about at least one SVG document (which would be useless) or all SVG documents (which would be impossible because of the DTD stuff)? |
| 16:20 | <Philip`> | I suppose it should be talking about the subset of SVG documents that can be generated by Inkscape and Illustrator, i.e. unprefixed element names and no fancy DTD stuff except some namespace strings (I hope) |
| 16:20 | <Lachy> | Yay! it's about time the W3C started investigating the copyright licence for the authoring guide. :-) |
| 16:21 | <Lachy> | http://lists.w3.org/Archives/Public/public-html/2008May/0295.html |
| 16:22 | <Lachy> | I don't understand what he means by this point: "that this is a copyright and not a licensing issue" |
| 16:22 | <Lachy> | what's the difference? |
| 16:22 | <hsivonen> | shepazu: the main SVG WG objection that I am aware of is an objection that I think is misguided and should be fixed by removing the objection |
| 16:22 | <shepazu> | hsivonen: and the rest of us differ |
| 16:23 | <hsivonen> | shepazu: so how would I help out? |
| 16:23 | <shepazu> | in a telcon, brb |
| 16:50 | <zcorpan> | why is it a requirement that it produces the same DOM? HTML and XHTML have slightly different DOMs. shouldn't it be a requirement that the image renders the same as it would in XML? |
| 16:51 | <zcorpan> | e.g. it would render the same even if RDF doesn't survive |
| 16:54 | <zcorpan> | "Should be able to provide some sort of fallback mechanism for the SVG-in-HTML so that UAs that don’t know how to handle these SVG fragments will display the fallback." |
| 16:54 | <zcorpan> | i think that's orthogonal to text/html integration since it equally applies to application/xhtml+xml |
| 16:55 | <annevk> | can't even require rendering the same way |
| 16:55 | <annevk> | quirks mode baby |
| 16:55 | <zcorpan> | although text/html parsing can do some tricks to help, e.g. support cdata sections in some places but not others |
| 16:55 | <Philip`> | zcorpan: The most relevant UAs that support application/xhtml+xml also support SVG, so that's a mostly theoretical concern, whereas fallback for SVG-in-text/html is a practical concern |
| 16:55 | <Lachy> | why does quirks mode have to have any effect upon the rendering of SVG? |
| 16:56 | <zcorpan> | Lachy: case sensitivity of class |
| 16:57 | <Lachy> | but does the case insenstivity need to apply to SVG elements? Why can't it just apply to HTML elements? |
| 16:58 | <zcorpan> | Lachy: in firefox, opera and safari, it applies to svg as well |
| 16:59 | <zcorpan> | Lachy: it doesn't need to |
| 16:59 | <Lachy> | ah, crap :-( |
| 16:59 | <zcorpan> | but consistency is nice ;) |
| 16:59 | <zcorpan> | i think class should be case insensitive in getElementsByClassName and querySelector too |
| 16:59 | <zcorpan> | in quirks mode |
| 17:00 | <Lachy> | zcorpan, mail public-webapi about that |
| 17:00 | <zcorpan> | Lachy: ok |
| 17:00 | <Lachy> | oh, but that probably doesn't need to be specced in there |
| 17:01 | <Lachy> | if the case insensitivity is defined in HTML5, and Selectors defines the semantics of the class selector, it can be safely left up to those specs. |
| 17:01 | <Lachy> | but send mail anyway, just incase I'm wrong about it. |
| 17:01 | <zcorpan> | yeah i concluded the same (that html5 can define it) |
| 17:01 | <zcorpan> | but ok |
| 17:05 | <Lachy> | oh, crap :-( |
| 17:06 | <Lachy> | IE8 doesn't even support querySelector in quirks mode |
| 17:06 | <zcorpan> | sad but not very surprising |
| 17:07 | <Lachy> | true, since they're using the IE5.5 quirks mode engine. |
| 17:09 | <Lachy> | hmm. WebKit won't uppercase class names at all in quirks mode. |
| 17:10 | <Lachy> | <p class="FOO"> won't be matched by document.querySelector(".FOO"); (but it does match if both are lowercase) |
| 17:10 | Lachy | goes to file a bug |
| 17:10 | <Philip`> | zcorpan: About <script src>: Did you count number of script elements, or number of pages? |
| 17:12 | Philip` | notes that he doesn't guarantee his output doesn't interleave elements from different pages, since it depends on what the thread scheduler decided to do |
| 17:43 | <takkaria> | ha! |
| 17:43 | <takkaria> | the TAG wants to make people use aria: rather than aria- |
| 17:46 | <Philip`> | The cost-benefit analysis seems to be missing that the 'colon' approach is a "new paradigm for 'namespace'" |
| 17:47 | <krijn> | Iria:tating :/ |
| 17:47 | <Philip`> | where the new paradigm involves using getAttribute instead of getAttributeNS, and not requiring xmlns, and not allowing the prefix to be variable |
| 17:48 | <Philip`> | i.e. whatever it is, it's not XML Namespaces |
| 17:49 | <Philip`> | (but is close enough to confuse people into thinking that it is) |
| 17:49 | <BenMillard> | takkaria, krijn and Philip` are discussin the Q&A blog entry here, I take it? http://www.w3.org/QA/2008/05/syntax_for_aria_costbenefit_an.html |
| 17:50 | <krijn> | I have no idea, people should not notice my comments in here ;) |
| 17:50 | <Philip`> | BenMillard: I think so, via http://lists.w3.org/Archives/Public/public-html/2008May/0308.html |
| 17:50 | <takkaria> | that's what I was referring to, yes |
| 17:50 | <smedero> | there's also the last TAG minutes: http://www.w3.org/2001/tag/2008/05/08-minutes |
| 17:51 | <BenMillard> | looks like the author of the Q&A entry pasted the HTML output of a word processor document instead of conforming with the Q&A style and structure |
| 17:52 | <Philip`> | The colon thing would make more sense in a world that was going to transition away from text/html and to application/xhtml+xml, since then we'd end up with a relatively clean architecture and everything |
| 17:52 | <Philip`> | but that's not going to happen, and we'd be stuck with a colon mess in text/html |
| 17:53 | <takkaria> | Philip`: you think it's not going to happen, I daresay that the TAG think/hope it will... |
| 17:54 | <BenMillard> | from the minutes they consider this part of tagSoupIntegration-54 :( |
| 17:54 | <BenMillard> | so they look dead set on deprecating text/html as quickly as possible...still |
| 17:55 | <Philip`> | takkaria: There's a petabyte of legacy content that disagrees |
| 17:55 | <takkaria> | Philip`: your argument is invalid (that people haven't yet does not mean that they will) as well you know |
| 17:55 | <takkaria> | however true the conclusion is. :) |
| 17:56 | <zcorpan_> | Hixie: shouldn't it be degrade gracefully rather than fail gracefully, since the application still works in the given example? |
| 17:56 | <Philip`> | takkaria: The argument is that even if everyone in the world started producing XHTML, there's just too much HTML for it to ever go away |
| 17:59 | <takkaria> | hmm, the minutes are interesting |
| 17:59 | <Philip`> | (Of course that's untrue since there won't still be humans using HTML a million years from now; but I would hope at that point the transition is to something far more radical than XHTML) |
| 18:01 | <takkaria> | hmm, the minutes are interesting reading |
| 18:01 | <takkaria> | about the SVG WG: "I think they're the obvious case to lean on for a uniform solution. They're in XML and they already have a story that says it's ok to add new attributes in foreign namespaces anywhere you like." |
| 18:06 | <BenMillard> | takkaria, I agree |
| 18:07 | <shepazu> | takkaria: he said that about the SVG community, not the SVG WG |
| 18:08 | <takkaria> | shepazu: ah, my bad |
| 18:10 | <shepazu> | and I'm not sure I agree with him... it's now implemented, for better or worse, and that's the important thing |
| 18:12 | <zcorpan_> | Philip`: i counted number of script elements |
| 18:15 | <MikeSmith> | takkaria: btw, any update on your plans for HTML5 parsing implementation? |
| 18:15 | <takkaria> | MikeSmith: yeah, I have a position to start |
| 18:15 | <takkaria> | MikeSmith: as in, I was accepted |
| 18:16 | <takkaria> | I have a printout of the relevant bits of the spec now too |
| 18:16 | <takkaria> | it's exam period though, so I'm only really playing around with the existing code in my breaks |
| 18:18 | <hsivonen> | Philip`: Henry and I disagree on which is worse: colon but no NS processing or having a non-colon delimiter |
| 18:19 | <hsivonen> | Philip`: I think colon without NS processing is worse than going to non-NS processing using an untainted delimiter |
| 18:19 | <hsivonen> | people with Member access may be interested in http://lists.w3.org/Archives/Member/tag/2008May/0026.html |
| 18:20 | <Philip`> | People without Member access could be interested too :-) |
| 18:20 | <hsivonen> | yeah :-( |
| 18:21 | <MikeSmith> | Bobby "Blue" Bland had a great song called "Members Only" |
| 18:24 | <MikeSmith> | and Jimi Hendrix had a great song called "Castles Made of Sand" |
| 18:25 | <takkaria> | yeah, that's a fantastic song |
| 18:26 | <takkaria> | I'm trying to work out what could possibly end the permathread |
| 18:26 | <MikeSmith> | good luck with that |
| 18:26 | <takkaria> | I think some people just have yet to be convinced that there are cases where alt text is genuinely not available |
| 18:26 | <Philip`> | I imagine the one thing that won't end the thread is posting to it :-) |
| 18:26 | takkaria | grins |
| 18:27 | <Philip`> | Of course the other thing that won't end it is not posting to it |
| 18:28 | <takkaria> | the straw men make having a decent debate hard :( |
| 18:28 | <takkaria> | IME, this kind of thing is best resolved by sitting down and negotiating one-on-one, at least in real life |
| 18:29 | <Philip`> | You can defeat the straw men by starting a flamewar |
| 18:29 | <takkaria> | personally I find the a11y people including personal insults all the time to be on par with trying to start a flamewar |
| 18:30 | <Philip`> | I think "all the time" is quite an exaggeration |
| 18:31 | <Philip`> | and "the a11y people" is quite a term which I've forgotten |
| 18:31 | <Philip`> | Uh, a generalisation? |
| 18:33 | <takkaria> | well, of the posts I've made on that topic since I started it, I think most of the replies to me included some implications that I was thoughtless, naive, ignorant, presumptious etc |
| 18:33 | <takkaria> | (not all of the above in any one post, but one of them in most) |
| 18:34 | <MikeSmith> | I can imagine that some might say that the whole should-alt-be-required discussion is massive waste of time that could have been completely prevented by some better judgement on the part of the editor |
| 18:37 | <Philip`> | MikeSmith: Better technical judgement, or better appease-everyone-so-they-stop-arguing judgement? |
| 18:38 | <MikeSmith> | neither |
| 18:43 | <takkaria> | I increasingly think that asking a photographer-for-a-living to provide alt text for e.g. a portfolio website is actually insane, because the purpose of the portfolio is to show photographs |
| 18:43 | <Dashiva> | At least the strawmen are accessible strawmen :) |
| 18:44 | <hsivonen> | this is a reply to me but I don't understand its point: http://lists.w3.org/Archives/Public/public-html/2008May/0303.html can someone help me understand it? |
| 18:45 | <Philip`> | hsivonen: Not me, I'm afraid |
| 18:45 | takkaria | adds that posts to his list of reasons top-posting is bad |
| 18:45 | <hsivonen> | what's a 'lambda user'? |
| 18:46 | <Philip`> | takkaria: He could have put his reply at the bottom and it would not have made any more sense |
| 18:46 | <takkaria> | Philip`: no, but as a consequence of not top-posting, people tend to actually reply to points more than just go off on one |
| 18:47 | <Dashiva> | Philip`: The opposite to top-posting isn't bottom-posting, but context-posting |
| 18:47 | <takkaria> | that is, I believe inline quotes make people actually think about what they want to say. :) |
| 18:47 | <Philip`> | Dashiva: That seems an odd definition of "opposite" |
| 18:47 | <BenMillard> | Dashiva, it is the opposite in terms of position but not in terms of usefulness |
| 18:47 | <Philip`> | I'd just say it's one of several alternatives |
| 18:48 | <Philip`> | (and the non-context-based ones of those alternatives make messages hard to understand) |
| 18:48 | <Dashiva> | Philip`: Well, top-posting is really just outside-posting with the reply put at the bottom by the client as default |
| 18:49 | <Philip`> | Hmm, how about two-column email? Put the original in the left and line up your replies on the right |
| 18:50 | <Dashiva> | I've tried doing that in lecture notes. Code in one column, and comments to it in the other |
| 18:50 | <Dashiva> | The comment column got really easily out of sync, when a preceding comment linewrapped or similar. Needs quality UI to work :) |
| 18:50 | hsivonen | now sees the TAG posted the ARIA stuff to the WG |
| 18:50 | <hsivonen> | sigh |
| 18:51 | <Dashiva> | Philip`: Then again, you are the person who didn't fix Hixie's graph, so surely you can not do it |
| 18:53 | <Philip`> | Dashiva: I'm too busy to not do anything useful now, since I'm waiting to see if an order delivery status will change from "With Delivery Driver" to something more useful before I get bored and go home, and that takes up all my concentration |
| 18:54 | <Philip`> | (The delivery driver has had it for 11 hours now, so I don't see why it's taking them so long...) |
| 18:54 | <hsivonen> | I notice that the "cost/benefit analysis" was not amended to take into account feedback I gave f2f |
| 18:55 | <MikeSmith> | hsivonen: so please take some time to e-mail HT and point that out |
| 18:55 | <MikeSmith> | instead of bitching about it here |
| 18:56 | <hsivonen> | ok. here we go again |
| 18:57 | <MikeSmith> | hsivonen: yeah, I understand. I just don't know what the alternative is |
| 18:58 | <MikeSmith> | what I do know is that the alternative of me communicating to others about it by proxy is not practical alternative |
| 19:07 | <hsivonen> | MikeSmith: sure. I'm just not particularly happy about finding myself writing email about this again after thinking I already communicated f2f |
| 19:09 | <MikeSmith> | hsivonen: there are many things these days that I find myself needing to do that I'm not particularly happy about |
| 19:10 | <Philip`> | ("Delivered: 14/05/2008 10:50:45" - oh, thanks for telling me eight hours later) |
| 19:14 | <Dashiva> | Well, I for one am pleased nobody has pulled the formal complaint thing again. |
| 19:14 | <Philip`> | They probably noticed that it wasn't very effective last time |
| 19:29 | <Dashiva> | Ooh, bad voiceover diss in that mail |
| 19:29 | <Dashiva> | It's too bad AT doesn't compete on who's the best rather than who's the worst :) |
| 19:32 | <hsivonen> | MikeSmith: email sent |
| 19:34 | <takkaria> | hsivonen: you have a bias against making your own content accessible, did you know? |
| 19:35 | <MikeSmith> | hsivonen: thanks. as always |
| 19:35 | <hsivonen> | takkaria: do I? |
| 19:36 | <takkaria> | hsivonen: according to a reply to your last-but-one post on public-html |
| 19:44 | <zcorpan_> | hsivonen: do you agree with my <script src> analysis? would it make sense to implement the suggested checks? |
| 20:04 | <zcorpan_> | hsivonen: hmm, i never understood it as dispatching on qname and ignoring namespace, but rather support both {null, 'aria-foo'} and {...aria namespace..., 'foo'} |
| 20:05 | <zcorpan_> | hsivonen: although he's just been talking about the colon, not how it'd actually be implemented, so it's a bit unclear |
| 20:05 | <zcorpan_> | er |
| 20:05 | <zcorpan_> | s/aria-foo/aria:foo/ |
| 20:12 | <virtuelv> | why can't we have aria*foo or aria _m_O~o_m_foo |
| 20:12 | <zcorpan_> | virtuelv: they are not well-formed in xml, unfortunately |
| 20:12 | <virtuelv> | pity |
| 20:12 | <zcorpan_> | indeed |
| 20:20 | <virtuelv> | I particularily like _m_O~o_m_ |
| 20:20 | <virtuelv> | on an unrelated note: How far is CSS 2.1 from exiting CR state? |
| 20:21 | <zcorpan_> | a couple of thousand test cases away maybe? i don't know what happens with css these days |
| 20:21 | <virtuelv> | (provided we could drop the aural stuff, and say "CSS 3 module" for it |
| 20:22 | <virtuelv> | heh, which is only optional in the spec, I see |
| 20:22 | <zcorpan_> | speaking of which, i should check the status of the magic body stuff |
| 21:09 | <Hixie> | what's the law that hsivonen refers to sometimes to the effect that a technology ends up having as many components as working groups? |
| 21:10 | <Philip`> | Sounds like http://en.wikipedia.org/wiki/Conway's_Law |
| 21:10 | <hsivonen> | that's it |
| 21:11 | <Hixie> | aha! |
| 21:12 | <Hixie> | it's not in the list of adages on wikipedia |
| 21:12 | Hixie | adds it |
| 21:12 | <Philip`> | It's in http://en.wikipedia.org/wiki/List_of_adages_named_after_people |
| 21:12 | <Philip`> | Clearly there needs to be a list of lists of adages |
| 21:12 | <Hixie> | heh |
| 22:16 | <Dashiva> | Pragmatism, the lost art |
| 22:27 | <weinig> | annevk: ping |
| 22:37 | <gsnedders> | jgraham__: how do you get what Element.textContent would using lxml? |
| 22:40 | <hsivonen> | following implication arrows in the wrong direction seems to be too common |
| 22:40 | <jgraham__> | gsnedders: Recursion |
| 22:40 | <gsnedders> | jgraham__: k. so there is no simpler way :( |
| 22:40 | <jgraham__> | (or similar) |
| 22:41 | <jgraham__> | gsnedders: I don't know of a simpler way. There might be one I guess |
| 22:41 | <jgraham__> | hsivonen: Gez? |
| 22:46 | <Dashiva> | So much struggle to gain a tiny potential bit of accessibility for conforming documents, at the cost of so many non-conforming documents... |
| 22:47 | <gsnedders> | jgraham__: OK, I give in. lxml is quick enough :) |
| 22:48 | <Philip`> | gsnedders: If it's quick enough, your data set is too small |
| 22:48 | <gsnedders> | Philip`: I'm just operating on a couple month old copy of HTML 5 |
| 22:48 | <gsnedders> | Philip`: And I doubt anything larger will be using it |
| 22:49 | <hsivonen> | jgraham__: among others |
| 22:50 | <Philip`> | gsnedders: What about HTML6? |
| 22:50 | gsnedders | wonders whether implementing DOM on top of lxml would be sane |
| 22:50 | <Philip`> | Given the way HTML5 is developed, the spec can never get smaller, because that would involve being less precise or dropping features |
| 22:51 | <Philip`> | so you need to be sufficiently forward-looking when developing tools |
| 22:51 | <takkaria> | Philip`: unless Hixie gets cloned and he can split out bits HTML5 into another spec, whilst still editing it all |
| 22:51 | <Philip`> | else you'll get the same problem that the W3C tools get when trying to process the HTML5 spec |
| 22:51 | <zcorpan_> | Philip`: it could drop non-normative stuff without being less precise or dropping features |
| 22:51 | <takkaria> | it's a possibility, anyway |
| 22:52 | <Philip`> | zcorpan_: Oh, yes |
| 22:52 | Philip` | wonders what the ratio of normative to non-normative text is |
| 22:52 | <zcorpan_> | Philip`: in terms of file size, it could also use less whitespace and less markup and less comments |
| 22:52 | <gsnedders> | Philip`: No, you get the problem of the real spec gen when you try and parse it multiple times |
| 22:52 | <Philip`> | (or, equivalently, the ratio of informative to uninformative text) |
| 22:53 | <zcorpan_> | Philip`: you could count paragraphs that contain normative keywords |
| 22:54 | <Hixie> | Philip`: dropping features happens |
| 22:59 | <Philip`> | zcorpan_: Hmm, only 36% |
| 22:59 | <Philip`> | (counting <p> elements that match /\b(must|required|should|recommended|may|optional)\b/i) |
| 22:59 | <gsnedders> | jgraham__: I'm getting a lot of errors with latest lxml and html5lib SVN |
| 22:59 | <zcorpan_> | Philip`: i meant "paragraphs" as defined in html5! not <p> elements! ;) |
| 23:00 | <Hixie> | you'd have to count sentences, not paragraphs |
| 23:00 | <Hixie> | and unfortunately some sentences make entire sections normative |
| 23:00 | <Hixie> | e.g. the algorithms introduced by "must do this" |
| 23:00 | <Hixie> | or the entities table |
| 23:00 | <gsnedders> | jgraham__: Actually, if I svn up, then it works. Remembering to do that helps :P |
| 23:01 | <Philip`> | zcorpan_: Get a browser to implement document.getParagraphs() and then I'll count that |
| 23:01 | <zcorpan_> | Philip`: if you file a bug on that i can buy a beer to the relevant developer to get it implemented in opera |
| 23:03 | <gsnedders> | 16.032 seconds on my 2.4GHz Core 2 Duo laptop to parse html5 (the source version, not the postprocessed version) into a lxml structure |
| 23:03 | <gsnedders> | my only issue is the lack of support of XPath 2 :P |
| 23:04 | <Philip`> | gsnedders: If you save it as XML, how long does it take to parse it back again? |
| 23:04 | <gsnedders> | Philip`: next to nothing |
| 23:04 | <Hixie> | uh |
| 23:04 | <Hixie> | that's a long time |
| 23:04 | <Hixie> | that's probably about as long as the current processor |
| 23:05 | <Philip`> | Hixie: You should write the spec as XHTML |
| 23:05 | <jgraham__> | gsnedders: For postprocessing, saving it to a python pickle is possibly even faster than saving to XML |
| 23:05 | <Hixie> | Philip`: people should write better parsers :-P |
| 23:05 | <gsnedders> | Philip`: The bottleneck is html5parser.py:141(normalizedTokens) |
| 23:05 | <jgraham__> | gsnedders: ?! Really? |
| 23:06 | <jgraham__> | Surely the bottleneck is in the input stream? |
| 23:06 | <gsnedders> | jgraham__: I'm doing this locally, so no |
| 23:06 | <Philip`> | Seems it'd be quickest to have an external HTML-to-XHTML tool written in a real language, and then Python code can quickly load it and do whatever fancy processing it wants |
| 23:07 | <jgraham__> | gsnedders: Even for local disk access I expect getChar or charsUntill to take most of the time |
| 23:07 | <hsivonen> | zcorpan_: I haven't yet developed an opinion about the script issue, although I don't like the suggestion as a knee-jerk reaction |
| 23:07 | <jgraham__> | Because they are slooow and get called a lot of times |
| 23:07 | <gsnedders> | jgraham__: charsUtil takes 6 secs |
| 23:08 | <hsivonen> | zcorpan_: as for dispatch on qName, I'm very convinced based on information not in email that dispatch on qName is being put forth |
| 23:08 | <jgraham__> | So that's 1/3 of the time. How much does notmalizeToken take? |
| 23:08 | <jgraham__> | normalize |
| 23:08 | <hsivonen> | based on f2f info that is |
| 23:09 | gsnedders | reruns it, so he can just pastebin it |
| 23:09 | <gsnedders> | jgraham__: http://pastebin.ca/1018429 |
| 23:09 | <gsnedders> | Now, back to working for my English exam in 12.75 hours |
| 23:10 | <gsnedders> | s/12/9/ |
| 23:11 | <jgraham__> | gsnedders: You're reading the wrong column |
| 23:11 | gsnedders | looks again |
| 23:11 | <gsnedders> | seemingly yes :) |
| 23:11 | <jgraham__> | The first column is the interesting one |
| 23:12 | <gsnedders> | and charsUntil is the only significant one |
| 23:12 | <jgraham__> | (the third column includes time in code called by that function, so for normalizedTokens that's the whole tokenizer |
| 23:12 | <gsnedders> | jgraham__: yeah, I know |
| 23:12 | <gsnedders> | jgraham__: I was looking quickly :) |
| 23:12 | <gsnedders> | (too quickly) |
| 23:12 | <jgraham__> | Did you get this from parse.py? |
| 23:13 | jgraham__ | wonders why the output isn't sorted |
| 23:13 | <Philip`> | The first column seems misleading since you could make the bottleneck not be the bottleneck by splitting it into lots of small functions |
| 23:13 | <gsnedders> | jgraham__: see the top line |
| 23:13 | <jgraham__> | gsnedders: Ah, OK |
| 23:14 | <jgraham__> | Philip`: Still if a single function is taking 1/3 of the total runtime is is a bottleneck... |
| 23:14 | <gsnedders> | Hixie: Can I just ignore your edge case until we have a html5 parser as a python extension? :P |
| 23:17 | Hixie | invites the tag to review html5 so that they don't come back in three years saying "you didn't invite us to review it! that's why we're sending you this feedback so late!" |
| 23:17 | <Hixie> | gsnedders: depends if you want me to use your script or not :-P |
| 23:18 | gsnedders | doesn't have strong feelings either way |
| 23:18 | gsnedders | just used you to get a subset of features that is actually used :P |
| 23:25 | <Lachy> | jgraham__, yt? |
| 23:25 | <jgraham__> | Lachy: Yep |
| 23:25 | <Lachy> | re the title for our presentation |
| 23:26 | <Lachy> | HTML5: From Use Cases to Solutions was ok, but I'd prefer to find something a little better |
| 23:26 | <jgraham__> | Lachy: Yeah, I agree it's not great |
| 23:28 | <jgraham__> | Do you have any ideas? |
| 23:28 | <Lachy> | these are the areas the talk will cover, and we need a title that sort of reflects them: |
| 23:28 | <Lachy> | 1. Introduction to HTML5 - discuss the aims and objectives (5 min) |
| 23:28 | <Lachy> | 2. The design principles (10 min) |
| 23:28 | <Lachy> | 3. Constructing web sites with HTML5 - use cases, markup and DOM APIs (20 min) |
| 23:28 | <Lachy> | 4. Talk about the HTML WG, WHATWG and the community surrounding it (10 min) |
| 23:31 | <Lachy> | Understanding HTML5: [insert subtitle] |
| 23:32 | <Hixie> | i recommend "HTML5" |
| 23:32 | <Lachy> | that's a bit boring |
| 23:33 | <Hixie> | if the excitement of your talk is dependent on the excitement of your title, you've got bigger problems :-) |
| 23:33 | <jgraham__> | Hixie: Whilst the title isn't really important for making the talk good, it might be important for making people turn up |
| 23:34 | <jgraham__> | This conference seems to be for people who value aesthetics |
| 23:34 | <Hixie> | "HTML5: Sex, Drugs, and Rock and Roll"? |
| 23:35 | <Lachy> | LOL |
| 23:35 | <jgraham__> | Glad it's worked like that for you, Hixie |
| 23:35 | <jgraham__> | :) |
| 23:36 | <jgraham__> | Something about moving the web forward? |
| 23:37 | <gsnedders> | "No sex, no drugs, no rock, no roll, when it comes to today" |
| 23:38 | <Hixie> | "HTML5: Why everyone else is wrong and we're right" |
| 23:38 | <Hixie> | you'd probably get people in for that one |
| 23:38 | <gsnedders> | "HTML5: It's not XHTML2" |
| 23:38 | <Lachy> | "HTML5: It's not that bad" |
| 23:38 | <Philip`> | "HTML5: Free money if you come to our talk" |
| 23:39 | <jgraham__> | How I learnt to stop worrying and love HTML5 |
| 23:39 | <Lachy> | The HTML5 Generation |
| 23:39 | <jgraham__> | Or maybe just HTML5: How I learnt to stop worrying and love endless tedious arguments about alt |
| 23:39 | <gsnedders> | "HTML5: Not quite yet 2π" |
| 23:40 | <Dashiva> | jgraham__: ow |
| 23:40 | <Lachy> | HTML5: More Bikesheds than Anyone Else |
| 23:40 | <Dashiva> | How about just sticking to the classic? Understanding HTML5: 5 > 2 |
| 23:40 | <Hixie> | we by far don't have more bikesheds than anyone else |
| 23:40 | <Hixie> | html5 has fewer bikesheds than most wgs i've been involved in |
| 23:40 | <Hixie> | by some quite wide margin |
| 23:40 | <Lachy> | yeah, I guess |
| 23:41 | <takkaria> | HTML5: Architectually Inconsistent, as declared by the TAG |
| 23:41 | <Dashiva> | What's your top three list, Hixie? |
| 23:41 | <jgraham__> | No architecture astronauts please, we're HTML5 |
| 23:41 | <Hixie> | Dashiva: everyone else is tired for first spot. :-P |
| 23:41 | <zcorpan_> | "HTML5: More Powerplants than Anyone Else" |
| 23:41 | <Philip`> | How ironic that http://code.google.com/doctype/ has a broken doctype |
| 23:41 | <Lachy> | "Painting HTML5: Design, Development and the Community" |
| 23:41 | <takkaria> | 2005: An HTML5 Odyssey |
| 23:42 | <gsnedders> | "HTML5: Hixie is God" |
| 23:42 | <Dashiva> | HTML5: A whitespace odyssey? |
| 23:42 | <jgraham__> | Lachy: That is almost good |
| 23:42 | <Lachy> | takkaria, it's 2008 now :-) |
| 23:42 | <takkaria> | I must have missed the year change again |
| 23:42 | <jgraham__> | HTML5: Hixie's Text Markup Language |
| 23:42 | <Hixie> | hah |
| 23:42 | <Dashiva> | +1 |
| 23:43 | <gsnedders> | jgraham__: No, s/Text/Tough/ |
| 23:43 | <jgraham__> | Toy? |
| 23:43 | <Dashiva> | Terrible? |
| 23:43 | <jgraham__> | Terrible? |
| 23:43 | gsnedders | expects we can come up with loads |
| 23:43 | <Dashiva> | Wait, there's that word |
| 23:43 | gsnedders | falls asleep |
| 23:43 | <Dashiva> | Someone used it in a mail... transigent! |
| 23:43 | <takkaria> | HTML5: With Added RFC2119 Goodness |
| 23:44 | <Philip`> | Dashiva: Is that really a word? |
| 23:44 | <Lachy> | HTML5: You MUST Come" |
| 23:44 | <Dashiva> | Philip`: It's intransigent without in |
| 23:44 | <Hixie> | bbl |
| 23:44 | <Lachy> | are you sure you didn't mean transient? |
| 23:44 | <Philip`> | The closest thing in my dictionary is transignification |
| 23:44 | <Dashiva> | Lachy: http://www.merriam-webster.com/dictionary/intransigent |
| 23:45 | <Dashiva> | I find the meaning fits really well too |
| 23:46 | <Lachy> | oh good, cause one definition of transient is "Decaying with time" |
| 23:46 | <Dashiva> | Hixie's Transsiberian Markup Language |
| 23:47 | <Lachy> | HTML5: Building the Foundation of the Web |
| 23:47 | <Philip`> | "Satanism manifests itself in different countries under various forms and names, such as Nihilism, Intransigentism, Petrolean Communism." |
| 23:48 | <Philip`> | Uh, does anyone happen to know what 'Petrolean' is? |
| 23:48 | <jgraham__> | Lachy: It would be good to get the idea across that we're not just going to blather on for an hour about the process but we're going to give people an idea of how they can use bits of HTML5 today |
| 23:48 | <Dashiva> | Venezuela? |
| 23:48 | <Dashiva> | HTML5: What will it do for you lately? |
| 23:49 | <j4_james> | suck |
| 23:49 | <Lachy> | Dashiva, ask not what HTML5 can do for you, ask what you can do for HTML5! |
| 23:50 | <Dashiva> | Lachy: Sure, but that's after you get them into the room |
| 23:50 | <jgraham__> | HTML The Second Coming |
| 23:51 | jgraham__ | wonders what fraction of the audience you could offend with that |
| 23:52 | <Dashiva> | You could always smooth it over with Second Parsing or something like that |
| 23:52 | <Lachy> | nothing wrong with offending people. It helps get people talking. |
| 23:52 | <Philip`> | The "browser compatibility" tables in e.g. http://code.google.com/docreader/#p(doctype)s(doctype)t(DialogElement) seem totally bogus |
| 23:52 | <Dashiva> | Again, after you get them into the room :) |
| 23:54 | <jgraham__> | So are we any closer to a serious idea? |
| 23:55 | <Dashiva> | "HTML5: Who, what and why" |
| 23:56 | <Lachy> | I liked "HTML5: Building the Foundation of the Web" (maybe s/Building/Developing/) |
| 23:56 | <Dashiva> | That sounds really like "replacing what we already had with something new and better" rather than "formalizing what we have and making it better" to me |
| 23:57 | <Lachy> | How about just "HTML5 Development" |
| 23:57 | <takkaria> | how about HTML5? :) |
| 23:58 | <jgraham__> | Lachy: My main problem with "Building the foundation of the web" is that it doesn't communicate the practical aspect of how to use it |
| 23:58 | <jgraham__> | HTML 5: A kickstart guide |
| 23:59 | <jgraham__> | Getting your hands dirty with HTML5 |
| 23:59 | <Lachy> | yeah, that one is ok |