| 00:10 | <Hixie> | parsing rules written. |
| 00:11 | <Hixie> | next is... the processing model, i guess |
| 00:13 | <Dashiva> | Hixie: Re:database names and paths, how about making them default to the active path (as a name prefix, or input parameter, or whatnot), but allow an override? That way they won't conflict by accident, and they can still be shared if needed |
| 00:14 | <Hixie> | so moving an application around on a host breaks it? |
| 00:14 | <Hixie> | i guess we could |
| 00:15 | <Dashiva> | Moving an application is rarely a non-breaking operation anyhow |
| 00:15 | <Hixie> | really? |
| 00:15 | <Dashiva> | There's always some URL that should've been absolute and was relative |
| 00:15 | <Hixie> | fair enough |
| 00:16 | <Hixie> | the problem i see though is that i think duplicate installs of the same software on a host are going to be at least as likely as moving installed software around on a host |
| 00:16 | <Hixie> | so you're just trading conflicts for breakages |
| 00:16 | <Hixie> | (and in both cases the software can be written/configured to work around it) |
| 00:16 | <Dashiva> | True |
| 00:17 | <Dashiva> | I guess I consider it better to support the case where several parties are involved, since it's much harder to coordinate |
| 00:17 | <Hixie> | but it's only gonna be an issue when you install the same software, and software can already just use location.path as part of their database name if they want |
| 00:18 | <Dashiva> | Yes, but that requires every user to make that effort, rather than one user in the case of moving an app |
| 00:18 | <Hixie> | it requires one application software author to make the effort, instead of every user moving apps around |
| 00:19 | <Hixie> | s/apps/that app/ |
| 00:19 | <Dashiva> | No, if the author does it, it will break users moving apps |
| 00:19 | <Hixie> | my point is i don't really see it as being much of a gain in either direction |
| 00:19 | <Hixie> | there are tradeoffs and i don't really see either as being better than the other |
| 00:19 | <Hixie> | (except that the status quo is simpler to spec and implement) |
| 00:22 | <Dashiva> | That matters too, yeah |
| 01:11 | <Hixie> | othermaciej_: yt? |
| 01:11 | <Hixie> | othermaciej_: if i am at a page that's offline |
| 01:11 | <othermaciej_> | Hixie: yep what's up |
| 01:11 | <Hixie> | but i'm online |
| 01:11 | <Hixie> | and the page has an <iframe> that references a page that's not in the cache |
| 01:11 | <Hixie> | right now the spec says to fail the load. |
| 01:11 | <Hixie> | (unless the page is whitelisted) |
| 01:12 | <Hixie> | but what if the page is one that isn't in the cache but has a defined fallback page? |
| 01:12 | <Hixie> | should we fetch it and cache it and display it, since we're online? |
| 01:12 | <Hixie> | or should we fail it? or show the fallback page? |
| 01:13 | <Hixie> | i guess we should fetch it |
| 01:45 | <Hixie> | an even more complicated problem is what to do if you go to the same page in two different tabs, if that page needs to be cached but it hasn't been cached yet |
| 01:54 | <Hixie> | sometimes i wish i could just write the spec in code |
| 01:54 | <Hixie> | there are some things that are just so much simpler to explain in code |
| 02:06 | <Hixie> | ugh |
| 02:07 | <Hixie> | what happens if you go to A, which has manifest M, which downloads files B and C, where C takes a long time |
| 02:07 | <Hixie> | and before C finishes, but after B is added to the cache, you go to B, which has by this point changed to B' |
| 02:07 | <Hixie> | and B' also points to M |
| 02:08 | <Hixie> | right now B gets overridden by B' |
| 02:27 | <Hixie> | much of the processing model is now defined too |
| 02:28 | <Hixie> | this is gonna be one almighty checkin once it goes in |
| 02:28 | <Hixie> | probably gonna take me an hour just to write the checkin message |
| 02:33 | <Hixie> | (it's a 2680 line patch so far) |
| 02:34 | <Hixie> | three major big-issues to fix before i check it in |
| 02:34 | <Hixie> | but those are gonna be relatively easy |
| 04:36 | <othermaciej> | Hixie: sorry, had to run off suddenly earlier |
| 04:36 | <othermaciej> | Hixie: I think anything with a fallback page defined should be implicitly online whitelisted as well |
| 08:29 | <virtuelv> | yuck, a document with two bodies, two dtd's |
| 11:45 | <zcorpan> | does anyone know how IE handles <object>? just the parsing/DOM bit? |
| 11:47 | <zcorpan> | i can't figure it out |
| 11:51 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cobject%3Ex%3C%2Fobject%3E%0D%0A%3Cscript%3E%0D%0Aw(document.getElementsByTagName(%22object%22)%5B0%5D)%3B%0D%0Awindow.setTimeout(%22w(document.getElementsByTagName('object')%5B0%5D)%22%2C%20100)%3B%0D%0A%3C%2Fscript%3E |
| 11:53 | <zcorpan> | ok, so ie replaces the object with its contents after the "load" event (if it is to do so) |
| 11:55 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cobject%3E%3Ciframe%3E%3C%2Fobject%3Ex%0D%0A%3Cobject%3E%3Ciframe%3E%3Cparam%3E%3C%2Fobject%3Ey |
| 11:57 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cobject%3E%3Ciframe%3E%3C%2Fobject%3Ex%0D%0A%3Cobject%3E%3Ciframe%3E%3Cparam%3E%3C%2Fobject%3Ey%0D%0A%3Cobject%3E%3Ciframe%3E%20%3Cparam%3E%3C%2Fobject%3Ez |
| 12:08 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cobject%3Ex%3Cparam%20name%3D%22x%22%3Ex%3Cbr%3E%3C%2Fobject%3E%0D%0A%3Cscript%3E%20w(document.getElementsByTagName(%22object%22)%5B0%5D.innerHTML)%20%3C%2Fscript%3E |
| 12:08 | <zcorpan> | vs |
| 12:08 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cobject%3Ex%3Cparam%20name%3D%22%22%3Ex%3Cbr%3E%3C%2Fobject%3E%0D%0A%3Cscript%3E%20w(document.getElementsByTagName(%22object%22)%5B0%5D.innerHTML)%20%3C%2Fscript%3E |
| 12:09 | <zcorpan> | it seems ie has a special tokenization rules for <object> |
| 13:30 | <beowulf> | hi |
| 13:30 | <zcorpan> | hi beowulf |
| 13:31 | <beowulf> | could someone point me to any discussion on mobile profiles in html5? the position paper said they were a bad idea and i just wondered if iI could read the arguments for/against that? |
| 13:33 | <zcorpan> | http://lists.w3.org/Archives/Public/public-bpwg-comments/2007OctDec/thread.html |
| 13:34 | <zcorpan> | though those comments don't really discuss why profiling is good or bad |
| 13:34 | <hsivonen> | beowulf: profiling assumes that content should adapt to clients that suck |
| 13:35 | <hsivonen> | beowulf: the only property of handhelds that should be expected to suck permanently is the physical screen size |
| 13:35 | <hsivonen> | beowulf: and that's a CSS-level problem |
| 13:35 | <hsivonen> | beowulf: that is, media queries, not profiling HTML |
| 13:36 | <hsivonen> | beowulf: also, serving less content doesn't mean cutting down the language but cutting the content |
| 13:38 | <beowulf> | ok, i agree with that from the point of view of content authors |
| 13:38 | <beowulf> | but html5 isn't only aimed at content authors, it's aimed at browser manufacturers, no? |
| 13:39 | <beowulf> | s/html5/the html5 spec/ |
| 13:39 | <hsivonen> | beowulf: yes, but there are browser vendors who make capable mobile browsers |
| 13:40 | <beowulf> | true, there are also browser manufacturers who make really incapbale mobile browsers, and i'm wondering if something can be done to help them focus on the right thing |
| 13:40 | <beowulf> | it's not neccessarily a html5 thing though |
| 13:41 | <hsivonen> | beowulf: why shouldn't they be expected to develop capable and competitive products instead of using a profile as an excuse not to? |
| 13:41 | <beowulf> | well that's fine as an ideal |
| 13:41 | <beowulf> | it doesn't seem to be working though |
| 13:42 | <zcorpan> | users can stop using browsers that suck |
| 13:42 | <beowulf> | not that mobile profiles are neccessarily the answer |
| 13:42 | <zcorpan> | then either they have to improve or they die |
| 13:42 | <hsivonen> | I don't buy mobile hardware that doesn't run at least one browser that's based on Gecko, WebKit or Opera |
| 13:43 | <hsivonen> | (Opera Mini counts as Opera in this case) |
| 13:43 | <beowulf> | i'm not convinced the majority make their mobile buying decisions in the same way |
| 13:43 | <beowulf> | though it would be nice for me |
| 13:44 | <zcorpan> | no, the majority don't use their mobile's browser at all |
| 13:44 | <zcorpan> | (i think) |
| 13:44 | <beowulf> | yes, in some cases because it sucks |
| 13:44 | <hsivonen> | from the user point of view, a browser that doesn't work with the real Web is utterly uninteresting |
| 13:45 | <hsivonen> | so either you don't use the Web from a mobile or get a browser that can deal with the Web |
| 13:46 | <hsivonen> | the browser on my old phone was good for two things: 1) running test cases that showed that the browser lacks a real XML parser and 2) downloading a better browser |
| 13:46 | <beowulf> | :) |
| 13:46 | <beowulf> | (your point on XML parsers is well made) |
| 13:52 | <zcorpan> | hsivonen: does minimo use an xml parser? |
| 13:52 | <hsivonen> | zcorpan: I don't know, but MicroB does |
| 13:52 | <beowulf> | MicroB? |
| 13:52 | <hsivonen> | beowulf: Nokia's Gecko port to Maemo |
| 13:53 | <zcorpan> | hsivonen: ok, interesting |
| 13:55 | <beowulf> | so that's 3... |
| 13:55 | <hsivonen> | zcorpan: though the current version has a bug that can cause the YSoD on well-formed pages |
| 13:57 | <zcorpan> | hsivonen: have you tracked down the bug? :) |
| 14:00 | <hsivonen> | zcorpan: no, but I have reported it. |
| 14:01 | <hsivonen> | https://bugs.maemo.org/show_bug.cgi?id=2040 |
| 14:11 | <hsivonen> | Hixie: I notice that you now allow event-source as block or inline. What's the compat story with the lack of end tag? |
| 14:15 | <zcorpan> | hsivonen: gotta love that editorial suggestions get bikeshedded :) |
| 14:16 | <hsivonen> | zcorpan: I just wanted to record a note with Hixie so that the spec is more useful for me in the future as I intend to scrape the element definitions for UI text |
| 14:17 | <zcorpan> | yep |
| 14:19 | <beowulf> | thanks for your help guys |
| 14:19 | <beowulf> | :) |
| 14:20 | <hsivonen> | hmm. the content model for datalist is weird |
| 14:22 | <zcorpan> | why? |
| 14:24 | <zcorpan> | empty options or transparent |
| 14:25 | <hsivonen> | zcorpan: typo. I meant datagrid |
| 14:26 | <hsivonen> | any block level but not table as the first child is weird |
| 14:26 | <hsivonen> | as it only bans trailing block content after a table |
| 14:26 | <hsivonen> | but otherwise you could have whatever where a table occurs somewhere |
| 14:29 | <zcorpan> | i haven't wrapped my head around datagrid yet |
| 14:56 | <zcorpan> | hmm, about e4x and <!-- |
| 14:56 | <zcorpan> | what's the value of being able to represent comment nodes with e4x? |
| 14:58 | <zcorpan> | i mean, it's incompatible with "<!--" being a js comment |
| 14:59 | <hsivonen> | zcorpan: isn't that handled by the script type parameter? |
| 15:00 | <zcorpan> | yeah. i don't like it |
| 15:03 | <hsivonen> | hmm. was <command> in <head> forbidden earlier? |
| 15:04 | <zcorpan> | don't think so |
| 15:04 | <hsivonen> | I've marked <command> in <head> nonHTMLizable but I don't find explanation in the spec. |
| 15:05 | hsivonen | writes test case |
| 15:05 | <zcorpan> | the parsing section doesn't say what to do with it yet :) |
| 15:05 | <zcorpan> | treating unknown tags as empty elements when found in head (like firefox does) makes <command> in head nicer for legacy UAs |
| 15:06 | <zcorpan> | though i don't like firefox's way of deciding whether something is "in head" or not |
| 15:07 | <zcorpan> | which depends on whether there was an actual <head> start tag |
| 15:07 | <hsivonen> | yeah, this explains it: http://parsetree.validator.nu/?doc=http%3A%2F%2Fhsivonen.iki.fi%2Ftest%2Fmoz%2Fcommand-in-head.html&submit=Print+Tree |
| 15:08 | <hsivonen> | I guess I should mark <event-source> in <head> nonHTMLizable as well |
| 15:08 | <hsivonen> | Hixie: it would really help if the spec had notes about non-obvious implications like this |
| 15:10 | <zcorpan> | http://validator.nu/?doc=http%3A%2F%2Fhsivonen.iki.fi%2Ftest%2Fmoz%2Fcommand-in-head.html&showsource=yes |
| 15:10 | <zcorpan> | isn't there an error message missing? |
| 15:11 | <hsivonen> | whoa. |
| 15:11 | <hsivonen> | I've done something bad |
| 15:12 | <hsivonen> | I should prioritize regression testing |
| 15:21 | <hsivonen> | zcorpan: fixed. thanks |
| 15:31 | <hsivonen> | Hixie: I think the content model of datalist is not well-defined when used as a child of datagrid |
| 15:32 | <hsivonen> | Hixie: I'm guessing it is the same as in static block context |
| 15:43 | <hsivonen> | I guess regression testing for validator.nu should exercise the whole thing through the Web service API |
| 15:43 | <hsivonen> | previous attemps to test only parser / schemas have failed to catch differences between the harness and actual deployment |
| 16:56 | <Hixie> | hsivonen: the new elements and their integration with the parser and old elements hasn't been explained at all yet |
| 16:57 | <Hixie> | hsivonen: re datalist, send mail |
| 16:57 | Hixie | goes to a meeting |
| 18:33 | <Hixie> | hey, last call for role="" is out |
| 18:34 | <Hixie> | i wonder if it defines what role="" does |
| 19:36 | <Hixie> | ok the offline stuff is now basically defined. |
| 19:36 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#offline |
| 19:36 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/multipage/section-offline.html#offline |
| 19:36 | <Hixie> | oh no wait i haven't defined the API yet. |
| 19:36 | <Hixie> | crap. |
| 19:36 | <Hixie> | duh |
| 19:37 | <Hixie> | but that's pretty trivial |
| 19:37 | <Hixie> | so if people want to start reviewing it, now's a good time. |
| 19:40 | <jwalden> | Hixie: did any Moz people ever write up and propose navigator.isLocallyAvailable()? |
| 22:05 | <Hixie> | jwalden: no |