| 00:00 | <Hixie> | assuming your "(btw,...)" was to me, i don't understand the question |
| 00:00 | <annevk> | Hixie, oh, see your inbox in that case |
| 00:00 | <sicking> | annevk: case sensitivity is tricky since methods get normalized |
| 00:00 | <annevk> | sicking, that sounds like a bug |
| 00:00 | <annevk> | in theory methods are case sensitive |
| 00:01 | annevk | ponders |
| 00:01 | <sicking> | right, but people use "post" as well as "POST" |
| 00:01 | <sicking> | and probably "Post" too |
| 00:01 | sicking | wants to use "P057" |
| 00:02 | <annevk> | "9051" |
| 00:03 | <annevk> | sicking, in XMLHttpRequest we made a limited set of HTTP methods case-insensitive |
| 00:04 | <annevk> | although I believe implementations differ from that |
| 00:04 | <annevk> | maybe we should just defy the HTTP gods and make them all case insensitive US-ASCII strings... |
| 00:09 | <sicking> | hmm.. looks like we never change the case |
| 00:09 | <sicking> | we must be somewhere... |
| 00:10 | <annevk> | sicking, btw, ideas non same-origin stuff for XHR1 is also appreciated, especially the last open issue with respect to data:, javascript: etc. |
| 00:10 | <annevk> | I think that's the only thing apart from the Microsoft comment that's blocking a new draft |
| 00:10 | <sicking> | annevk: i think data should always be allowed, and javascript never |
| 00:10 | <sicking> | annevk: well.. |
| 00:11 | <annevk> | except after a redirect? |
| 00:11 | <annevk> | the redirects make it annoying |
| 00:11 | <Hixie> | you mean redirect to data: ? |
| 00:12 | <annevk> | Hixie, yeah |
| 00:12 | <Hixie> | you should basically abort as soon as you redirect out of the origin, as far as i can tell |
| 00:12 | <sicking> | Hixie: why? |
| 00:12 | <annevk> | not with XHR2 |
| 00:12 | <Hixie> | with xhr1 i mean |
| 00:12 | <sicking> | ah |
| 00:12 | <sicking> | yeah |
| 00:12 | <sicking> | well |
| 00:13 | <sicking> | i don't really care much about xhr1 there as we already support xhr2 for same-origin stuff |
| 00:13 | <Hixie> | if example.com has a page that redirects to data: to show sensitive data, we don't want evil.invalid to redirect to the page that redirects to data: |
| 00:13 | <Hixie> | yeah i'm just saying for anne's blocking issue |
| 00:14 | <annevk> | for xhr2 you'd need an out-of-origin flag that gets set once you go out of origin which you check the moment you hit a data: URI |
| 00:14 | <annevk> | i think there's such a flag already |
| 00:15 | <annevk> | it would prolly be good to publish xhr2 too, even though it's not done yet |
| 00:17 | <Hixie> | origin->data: should be ok |
| 00:17 | <Hixie> | only origin->remote->data: is bad (and origin->remote is the step that makes it "bad") |
| 00:17 | <Hixie> | origin->remote->origin is also "bad" |
| 00:18 | <sicking> | bad meaning what? |
| 00:18 | <Hixie> | yeah, not sure how to handle that one |
| 00:18 | <sicking> | that you need AC checks? |
| 00:19 | <Hixie> | doing AC checks against the origin is pointless since you're supposing that the origin is evil |
| 00:19 | <annevk> | i think origin->remote->origin is handled by doing ac checks on origin which is kind of pointless |
| 00:19 | <Hixie> | hm, origin->remote->origin is an interesting way of doing cross-origin xhr with UA-provided credentials today |
| 00:20 | <Hixie> | i assume we block that at the moment |
| 00:20 | <Hixie> | but it's unclear to me what XHR2 should do in that case |
| 00:20 | <sicking> | no, today we bail as soon as we get the origin->remote redirect |
| 00:20 | <Hixie> | right |
| 00:20 | <sicking> | yeah |
| 00:20 | <Hixie> | xhr2 should definitely mention that in the security section |
| 00:20 | <Hixie> | not sure how to solve it though |
| 00:20 | sicking | ponders disabling cross-origin redirects in initial release |
| 00:21 | <sicking> | so one way of solving it is this: |
| 00:21 | <annevk> | there's a flag that tells you whether the initial request is same-origin or not |
| 00:22 | <sicking> | if you have origin->site A->site B->site C redirects |
| 00:22 | <sicking> | check all of origin, site A and site B against the AC rules |
| 00:22 | <Hixie> | jgraham: you still there? if so, i'm not sure how to handle "http://example.com/#comment"; vs "http://example.com/ #comment" in the manifest, if we use # as the comment separator |
| 00:22 | <sicking> | and only if all pass allow the content |
| 00:22 | <Hixie> | jgraham: for similar reasons we can't use // as the comment delimiter |
| 00:23 | <Hixie> | so the redirects have to do what? include Access-Control: headers? |
| 00:23 | <annevk> | what's the attack scenario btw? |
| 00:24 | <sicking> | the redirects are normal. but the final doc would have to have AC rules allowing origin, A and B |
| 00:24 | <annevk> | what if site C is origin though |
| 00:24 | <sicking> | fine |
| 00:24 | <annevk> | you're thinking of another problem |
| 00:25 | <Hixie> | i can't really see any attack scenarios here that aren't already a problem with <img> to be honest |
| 00:25 | <sicking> | you check AC rules for origin anyway |
| 00:25 | <Hixie> | since the only data you get back is in the uri, and the origin has access to its own uris |
| 00:25 | <sicking> | Hixie: how so? with <img> you can never read the actual data |
| 00:25 | <Hixie> | there's no data to read here |
| 00:25 | <Hixie> | i'm talking about origin->a->origin |
| 00:25 | <Hixie> | or any case of evil->victim->evil |
| 00:25 | <annevk> | there's data in the URI |
| 00:26 | <annevk> | not? |
| 00:26 | <sicking> | no, i'm thinking victim->evil->vicitm |
| 00:26 | <Hixie> | annevk: right but you can read the uri |
| 00:26 | <Hixie> | sicking: why would victim redirect to evil? |
| 00:26 | <annevk> | with <img>? maybe with <iframe> |
| 00:27 | <Hixie> | yeah, with iframe |
| 00:27 | <sicking> | Hixie: out of curiosity, can you read the final uri of an <img> redirect? |
| 00:27 | <Hixie> | with an <iframe> you can |
| 00:27 | <sicking> | you can? |
| 00:27 | <Hixie> | (on another note, why does rfc3986 have a stick figure in the diagram in section 3) |
| 00:27 | <sicking> | you can't read iframe.contentWindow.location |
| 00:27 | <Hixie> | sure, just read contentDocument.location |
| 00:27 | <Hixie> | you can, it's yours |
| 00:27 | <sicking> | nope, it's write-only |
| 00:28 | <sicking> | iirc |
| 00:28 | <sicking> | i should add :) |
| 00:28 | <Hixie> | we're talking about the case where you've redirected back to yourself, right? |
| 00:28 | <sicking> | ah, ok, in that case |
| 00:28 | <sicking> | sorry, got side tracked |
| 00:28 | <Hixie> | the cases when you don't redirect to yourself, we've already taken care of |
| 00:28 | <Hixie> | as far as i can tell |
| 00:28 | <sicking> | yeah, sorry, i was talking about something else |
| 00:29 | <annevk> | ok, so origin->foobar->origin does not need an access check and is ok |
| 00:29 | <annevk> | as it has the same risks that <iframe> already has |
| 00:29 | <annevk> | fun |
| 00:30 | <sicking> | hmm.. |
| 00:30 | <sicking> | i'm not entirely convinced |
| 00:31 | <Hixie> | what's the attack scenario that you can't already do? |
| 00:31 | <sicking> | but i don't have the attack scenario entierly clear |
| 00:32 | <sicking> | why do we have a flag for has-been-crossorigin? |
| 00:32 | <annevk> | sicking, because at some point we deemed this to be a problem |
| 00:33 | <annevk> | and solved it wrongly |
| 00:36 | <annevk> | (There is a flag in the current spec for initially same-origin that helps with a non same-origin redirect for non-GET requests.) |
| 00:37 | <annevk> | sicking, btw, user/password can't be included in redirects, or do you mean as part of the URI? |
| 00:39 | <sicking> | yeah, as part of the uri |
| 00:39 | <sicking> | you can redirect to http://foo:bar⊙eo/ |
| 00:40 | <annevk> | yup, k |
| 00:40 | <Hixie> | blimey URIs use a lot of symbols. ok if we're to allow comments at end of lines we have to have a comment delimited that isn't one of + - . : / @ _ ~ % ! $ & ' ( ) * , ; = [ ] ? # |
| 00:40 | <Hixie> | what does that leave |
| 00:40 | <annevk> | Hixie, why would fragment identifiers be part of the URIs in the manifest? |
| 00:40 | <sicking> | sol |
| 00:40 | <annevk> | a pipe? |
| 00:41 | <annevk> | http://test | comment |
| 00:41 | <sicking> | hmm.. it's on my swedish keyboard, but on the US one |
| 00:41 | <sicking> | ¤ |
| 00:41 | <annevk> | \\ |
| 00:41 | <Hixie> | annevk: i have no idea, but it would be confusing if we disallowed it since it wouldn't look disallowed |
| 00:41 | <Dashiva> | § :) |
| 00:42 | <annevk> | " comment |
| 00:42 | <annevk> | { comment } |
| 00:42 | <sicking> | ok kids, gotta profile stuff, so closing un-needed apps |
| 00:42 | <sicking> | see ya l8er |
| 00:43 | <Hixie> | the punctuation we have left in ASCII is: " < > \ ^ ` { | } |
| 00:43 | <Hixie> | we could use {...} like in pascal |
| 00:44 | <Philip`> | Why can't the comment just require a space before it? |
| 00:44 | <Dashiva> | An end delimiter seems annoying for end-of-line comments |
| 00:45 | <Hixie> | Philip`: because the space doesn't look important |
| 00:45 | <annevk> | http://example.org/test test/ |
| 00:45 | <Hixie> | that'd be a valid line in the fallback section |
| 00:45 | <Philip`> | I mean a space before a #, so http://example.org/#test is still a single URI but http://example.org/ #test is a comment |
| 00:46 | <Dashiva> | Seems prone to errors |
| 00:46 | <Philip`> | unless #test might be interpreted as a relative URI |
| 00:46 | <annevk> | Hixie, oh interesting, so %20 is required |
| 00:46 | <Dashiva> | I'd prefer | or maybe >> |
| 00:46 | <Dashiva> | Looks delimiter-ish |
| 00:46 | <Hixie> | Philip`: beacuse it would mean that "http://example.org/# unimportant" was a fallback line instead of one URI with a comment, despite looking like the latter |
| 00:47 | <Hixie> | (because "http://example.org/#"; and "unimportant" are both valid URIs) |
| 00:47 | <kingryan> | what about '*' ? |
| 00:47 | <Hixie> | kingryan: the punctuation we have left in ASCII is: " < > \ ^ ` { | } |
| 00:48 | <kingryan> | oh, I missed that |
| 00:48 | kingryan | has no idea where * is used in URLs |
| 00:48 | <Hixie> | kingryan: me either, but there we go |
| 00:48 | <kingryan> | " would be like VB, right? |
| 00:48 | <kingryan> | or was that a single quote? |
| 00:49 | <kingryan> | http://example.com/ "an example url |
| 00:49 | <Philip`> | http://search.cpan.org/~kane/Acme-Comment/lib/Acme/Comment.pm lists some current comment syntaxes |
| 00:49 | <annevk> | file names and such can include most of those characters btw so URIs could include them... |
| 00:50 | <Philip`> | "Pilot: Single-line comments in the syntax \/\/ are supported." - that starts with an acceptable character |
| 00:50 | Dashiva | ponders HTML comments |
| 00:50 | <Dashiva> | They start with a non-URL char |
| 00:50 | annevk | isn't sure whether URI legalness is cared much for and whether the current syntax should be loosened |
| 00:51 | <kingryan> | why don't we put a special character in the 7th column, like cobol? |
| 00:51 | <annevk> | yeah, lets introduce the insane comment parsing everywhere! |
| 00:51 | <Hixie> | well this discussion is pretty much cementing my conclusion to avoid end-of-line comments :-P |
| 00:52 | <kingryan> | Hixie: aren't you concerned that people will use them anyway? |
| 00:52 | <Philip`> | We could have a table at the end of the file which lists the byte ranges in the earlier part of the file that should be interpreted as comments |
| 00:52 | <Hixie> | kingryan: if they do, the entire line will be ignored |
| 00:52 | <kingryan> | until some browser decides to be more liberal in their parsing :) |
| 00:53 | <Hixie> | Philip`: if we do that, i'd want the offsets expressed relative to 12-bit words |
| 00:53 | <Dashiva> | annevk: Well, browsers have to be able to parse them anyway :P |
| 00:53 | <Hixie> | kingryan: since the spec will define error handling too, it'll be less likely to happen. but yes, if we get implementation feedback to the effect that we must change the rules, then that's a different matter. |
| 00:54 | <Dashiva> | Besides, it would just be a check for <!-- like in JS, since it goes to the end of the line anyway. The --> would just become part of the comment if included |
| 00:55 | <karlUshi> | Dashiva: which might break some CMS |
| 00:55 | <karlUshi> | <!-- begin content --> |
| 00:55 | <Philip`> | Dashiva: That sounds evil, since people would expect they could put <!-- ... --> on separate lines surrounding a block they want to remove |
| 00:55 | <Dashiva> | Philip`: Then they haven't used enough JS >:D |
| 00:57 | <Dashiva> | What about a heredoc-ish thing? The manifest can define its own comment delimiter |
| 00:57 | annevk | -> bed |
| 00:59 | <Hixie> | lol http://bugs.webkit.org/show_bug.cgi?id=5909#c30 |
| 01:05 | <Dashiva> | About time they admitted it :P |
| 01:11 | <othermaciej> | annevk, Hixie: sorry meeting |
| 01:11 | <othermaciej> | if it just replies with what methods are allowed, shouldn't it be a different method, not a different header? |
| 01:12 | <othermaciej> | if it never actually gives you the entity body then it seems to me the behavior is more header-like than method-like |
| 06:53 | <hsivonen> | hmm. so John Foliot considers suing people "social engineering"... |
| 06:54 | <othermaciej> | indeed, an unusual point of view |
| 07:23 | <hsivonen> | Hixie: should inline data templates be outright non-conforming in text/html inputs, then? |
| 07:24 | <hsivonen> | Hixie: Re: one possible context: do you mean the rule content model should be bimorphic, embedded, metadata or any table slice? |
| 07:25 | <hsivonen> | Hixie: I don't think I can agree at present (without examples to the contrary) that datatemplates were simpler than repetition templates for either authors or UA implementors |
| 07:26 | <hsivonen> | Hixie: were there cases where repetition templates sucked badly and that data templates address? |
| 07:28 | <othermaciej> | I still don't really understand the use cases for repetition templates |
| 07:29 | <othermaciej> | people usually mention online store shopping carts but they are clearly not useful for that |
| 07:29 | <hsivonen> | off-hand, I remember implementing repeating forms twice: |
| 07:30 | <hsivonen> | 1) a simple task tracking app |
| 07:30 | <hsivonen> | 2) an app for authoring online questionnaires |
| 07:31 | <hsivonen> | though the latter was too ajaxy to be really done without JS |
| 07:31 | <hsivonen> | but I guess it could have been done without JS with repetition templates |
| 07:32 | <othermaciej> | I guess I really wonder how often a button that just does add or remove of a repetition item is useful; it would have to be a case where you don't want to do anything else with script when adding or removing a repeat item |
| 07:32 | <hsivonen> | othermaciej: yes, I guess most often you want to do something else as well |
| 07:32 | <othermaciej> | it seems weird to me to have specialized kinds of button controls just for these two actions |
| 07:33 | <hsivonen> | with data templates, I get an even stronger feeling that it is something complex that only deals with simple cases and real apps will have to work around the limitations anyway |
| 07:34 | <hsivonen> | which is why I asked on the list why querySelector() and E4X tree literals aren't the answer |
| 07:34 | <othermaciej> | well, having a clear model for escaping to script helps |
| 07:34 | <othermaciej> | I don't think any current E4X implementation has good integration with the DOM |
| 07:34 | <othermaciej> | maybe I am wrong on this |
| 07:34 | <othermaciej> | in any case E4X is hardly less complex than datatemplate |
| 07:35 | <hsivonen> | Hixie: anyway, my intuitive reaction to repetition templates was positive and my intuitive reaction to data templates was very negative (regardless of RELAX NG considerations). I'd like to see more examples. |
| 07:35 | <hsivonen> | othermaciej: E4X isn't less complex, but it solves the problem of DOM fragment literals in the right place |
| 07:36 | <othermaciej> | hsivonen: you think the JavaScript level is the right place for DOM fragment literals? |
| 07:37 | <othermaciej> | (and really E4X only gives you XML fragment literals, converting them to DOM form is an excercise left to the reader) |
| 07:37 | <hsivonen> | othermaciej: yes, because for JS, DOM fragments are very common (like strings and hashtables) |
| 07:37 | <hsivonen> | othermaciej: yeah, that's a problem |
| 07:38 | <othermaciej> | hsivonen: I guess the current state of the art is for JS to store DOM fragments as strings |
| 07:38 | <othermaciej> | and use stuff like innerHTML to get them into the tree |
| 07:38 | <hsivonen> | yes |
| 07:38 | <othermaciej> | sadly that is both much easier and much more performant than using DOM APIs |
| 07:38 | <othermaciej> | referring to fragments declared elsewhere does seem like a pain |
| 07:38 | <othermaciej> | hyatt tells me XUL's similar template feature was used to good effect |
| 07:39 | <hsivonen> | also vulnerable against unescaped data under concatenation |
| 07:39 | <othermaciej> | I guess it is mainly useful for data binding type use cases, but where your data model may change over time so XSLT is not suitable |
| 07:39 | <hsivonen> | othermaciej: did you see anne's link to the anti-XUL template article? |
| 07:41 | <othermaciej> | hsivonen: well, hyatt clearly has reason to be biased about things XULish |
| 07:42 | <othermaciej> | one thing that datatemplates seemed like they might be nice for is <datalist> used with an <input>; if the data source is external, you can convert it to the needed format client side |
| 07:43 | <othermaciej> | it would also be nice to have some way to get datagrid to bind to data |
| 07:43 | <othermaciej> | I did not see the link |
| 07:43 | <othermaciej> | is it in the logs? |
| 07:43 | <hsivonen> | I'm still entirely unconvinced that just writing JS binding glue isn't a better solution considering that it is backwards compatible and can do anything that is computable without having to escape to another solution |
| 07:44 | <hsivonen> | othermaciej: yes, it the logs. but here it is: http://www.jerf.org/resources/xblinjs/whyNotMozilla/notXulTemplates.html |
| 07:46 | <othermaciej> | the idea of general-purpose templating does sound kind of cool, but to be fair it also seems like the area is littered with half-assed failures |
| 07:47 | <hsivonen> | (even though querySelector() and E4X tree literals aren't backwards compatible, Prototype and jQuery plus innerHTML are Good Enough substitutes) |
| 07:47 | <othermaciej> | maybe better to stick to adopting solutions where there is no script-based alternative and/or where an appropriate solution is clear |
| 07:55 | <othermaciej> | reading that reminds me of using XSLT vs. a perl script and regexps for document transforms for some reason |
| 07:55 | <othermaciej> | "clever" declarative solution that makes simple things into a mind puzzle |
| 07:55 | <othermaciej> | some people find that sort of thing fun |
| 08:03 | <hsivonen> | Hixie: your blog front page seems to have so have Pingback-related UTF-8 badness (lone byte 0xC2 for example) |
| 08:05 | <othermaciej> | hsivonen: I'm asking hyatt to tell me about templates on #webkit |
| 08:30 | <othermaciej> | hello hyatt |
| 08:31 | <hyatt> | hi |
| 08:32 | <hsivonen> | hi |
| 08:34 | <hsivonen> | hyatt: do we expect Web apps to have multiple view of a data source often enough to engineer a built-in feature for that case? |
| 08:34 | <hyatt> | yeah that's a good question |
| 08:36 | <hsivonen> | when I did the "remarkably short" manual binding, I had code that loaded the model tree via XHR and looped over it to copy the data to the view tree. at the same time, as each view chunk was created, I added closures that captured model references as view onchange handlers, so changes to the view were immediately reflected in the model |
| 08:36 | <hsivonen> | then I used XHR for sending the model back |
| 08:36 | <hyatt> | those closures would take up a lot of memory |
| 08:37 | <hyatt> | if you mean you had 1 for each "data item" basically |
| 08:37 | <hsivonen> | yes, one for each item that needed to be synced back to the model |
| 08:38 | <othermaciej> | I can see how that might hurt if you had thousands of editable items (like a bookmarks list or something) |
| 08:38 | <hyatt> | thats the kind of stuff that xul templates would avoid |
| 08:38 | <hyatt> | having 3000 JS objects for closures |
| 08:38 | <hyatt> | for example |
| 08:40 | <hsivonen> | if I hadn't created new closures but had shared the same syncing function instance on each item and had a separate plain object reference to the model on each item would that have been acceptable? |
| 08:40 | <hsivonen> | does a custom object reference on a DOM node have such a memory overhead that creating new HTML language features is justified to avoid it? |
| 08:41 | <hyatt> | well some of this also depends on how well the template feature is implemented too |
| 08:41 | <hyatt> | it may take up a lot of memory also in order to efficiently transmit changes |
| 08:41 | <hsivonen> | especially considering that desktops already have abundant RAM and handheld resource grow all the time |
| 08:42 | <hyatt> | yeah |
| 08:42 | <hsivonen> | hyatt: what was the "yeah" in reference to? |
| 08:42 | <hyatt> | yeah i see your point |
| 08:43 | <hsivonen> | ok |
| 08:43 | <hyatt> | is there some way to observe changes in sqlite databases in whatwg's spec |
| 08:43 | <hyatt> | i don't think this feature is just about binding to XML DOM data back ends |
| 08:44 | <hyatt> | but should be about binding to a database |
| 08:44 | <othermaciej> | the whatwg spec doesn't have a way to observe changes on the database |
| 08:44 | <hyatt> | even if we never do something like datatemplate, we should make sure it's easy to observe database changes in JS |
| 08:44 | <othermaciej> | I'm not sure databases with sql-based APIs have that |
| 08:44 | <othermaciej> | I was thinking about it just now though |
| 08:44 | <hyatt> | i'm sure they must have something since i think mozilla is moving to that kind of database |
| 08:44 | <hyatt> | and xul templates have to work |
| 08:45 | <othermaciej> | seems like you can't just use the database as a data model if it doesn't have change notification, you need something on top |
| 08:45 | <hsivonen> | hyatt: can there be anything but the app itself modifying the database? wouldn't the right hand of the app effectively be observing what the left hand does with the db as an intermediate? |
| 08:45 | <othermaciej> | hsivonen: if the app is multiple windows and you can't observe, you need to make an ad-hoc change notification protocol |
| 08:45 | <hsivonen> | othermaciej: ok |
| 08:45 | <othermaciej> | you might even be running multiple instances that have no way (currently) to rendezvous |
| 08:46 | <othermaciej> | the Storage API does have change notifications |
| 08:46 | <othermaciej> | so you could use that for notification and the database for storage |
| 08:46 | <othermaciej> | but that seems crappy |
| 08:46 | <othermaciej> | I will ask the Safari team's local SQL experts about this tomorrow |
| 08:47 | <hyatt> | i really think you should be able to build UI easily from a local SQL database |
| 08:47 | <hyatt> | that might be modified dynamically |
| 08:47 | <hyatt> | e.g., maybe facebook dumps your friends list in there |
| 08:47 | <hyatt> | and updates it when you yank a friend |
| 08:48 | <hyatt> | would be cool if it was easy for the web page to just fix up the UI |
| 08:48 | <hyatt> | anywhere friends are being displayed |
| 08:49 | <aroben> | othermaciej: I think SQLite has callbacks for when data is changed |
| 08:49 | <hsivonen> | intuitively, the ability to register JS change listeners to a data source seems more complete than templating |
| 08:50 | <hyatt> | i certainly think it should be there |
| 08:50 | <hyatt> | regardless of whether templating is around |
| 08:50 | <aroben> | othermaciej: http://www.sqlite.org/capi3ref.html#sqlite3_update_hook |
| 08:50 | <hyatt> | (register change listeners to an SQL data source i mean) |
| 08:51 | <othermaciej> | aroben: ok, I'll get Brady to look at it and see if we can propose something |
| 08:51 | <hyatt> | the biggest negative i think about templates |
| 08:52 | <hyatt> | is that they can be rocket science |
| 08:52 | <hyatt> | to the average web site developer |
| 08:52 | <hyatt> | not many people at netscape could understand them |
| 08:52 | <hyatt> | but then again not many people at netscape could understand much of anything |
| 08:52 | <hsivonen> | basically, my concern with templates is this: the solution for easy cases and the solution for complex cases should not be separate but on the same continuum so that if you start with an easy case and find that you need to add something, you don't need to from the solution for easy cases go back to zero and restart with the solution for complex cases. |
| 08:53 | <hyatt> | yes i agree with that statement |
| 08:55 | <hyatt> | so here's some of what made templates nasty in xul |
| 08:55 | <hyatt> | templates were basically built on top of something called RDF |
| 08:55 | <hyatt> | RDF's job was to aggregate data from multiple data sources |
| 08:55 | <hyatt> | into a graph |
| 08:56 | <hyatt> | thus you could think of data as being a collection of "assertions" made between nodes in some universe |
| 08:56 | <hyatt> | much of the complexity and headaches of xul templates |
| 08:57 | <hyatt> | arose from having to talk to a graph rather than a tree |
| 08:57 | <hyatt> | e.g., it wasn't clear what relationships would constitute "parent/child" relationships |
| 08:57 | <hyatt> | and which would be "attributes" |
| 08:58 | <hyatt> | RDF also had funny performance limitations |
| 08:58 | <hyatt> | because it produces a graph |
| 08:58 | <hyatt> | it's actually very bad at say removing an item from an ordered sequence |
| 08:58 | <hyatt> | because what you have is arcs labeled 1, 2, 3, 4, 5 etc. |
| 08:58 | <hyatt> | so inserting an item could force a renumbering to occur |
| 08:59 | <hyatt> | in other words conventional "DOM"-like trees are actually very clumsy to operate on or manipulate when represented via RDF |
| 08:59 | <hyatt> | and yet much of the data that XUL wanted to operate on was more naturally representable as a tree rather than a graph |
| 08:59 | <hyatt> | e.g., bookmarks |
| 09:00 | <hyatt> | so RDF can be blamed for a lot of the performance troubles that XUL templates have |
| 09:00 | <hyatt> | it's not really the template that is slow, it's the RDF updating |
| 09:01 | <hyatt> | so anyway if the back end is more of a tree model |
| 09:01 | <hyatt> | or even a list model where items can be updated and indexed efficiently |
| 09:02 | <hyatt> | the syntax and performance of a template should be much better than in XUL |
| 09:03 | <hyatt> | i think the big question is, will web pages be producing apps of such complexity that they would benefit from templates |
| 09:03 | <hyatt> | most of the time, the answer is "probably not" |
| 09:14 | <hsivonen> | yeah, there's the problem that the application needs to match the level of complexity templates assume. If it is too simple, templates don't help. If it is too complex, templates don't help, either (without growing into an awkward programming language like XSLT) |
| 09:14 | <hyatt> | there is something XSLT-like about templates |
| 09:14 | <hyatt> | but i do think they are simpler |
| 09:14 | <hyatt> | than XSLT at least |
| 09:14 | <hsivonen> | zcorpan: HTML 4.0 is now special-cased: http://validator.nu/?doc=http%3A%2F%2Fln.hixie.ch%2F |
| 09:14 | <hyatt> | you can think of the firefox "web app" as being incredibly complex :) |
| 09:14 | <hyatt> | hsivonen: this is kind of a feeble argument |
| 09:14 | <hyatt> | hsivonen: but other languages like flex do have these features |
| 09:14 | <hyatt> | hsivonen: i.e., it may be perceived as something we should have in the language to "keep up" with other RIA alternatives |
| 09:14 | <hyatt> | i guess i convinced hixie that this feature is cool |
| 09:14 | <hyatt> | :) |
| 09:15 | <hyatt> | i'll look at the thread soon hopefully |
| 09:15 | <hyatt> | and see what was actually proposed |
| 09:15 | hsivonen | googles for flex bindings |
| 09:16 | <hyatt> | yeah i need to research those also |
| 09:16 | <hyatt> | i am stating that they are similar |
| 09:16 | <hyatt> | but could be totally mistaken |
| 09:16 | <hyatt> | hsivonen: i think at some point it might be worthwhile tryign to pick some of the html5 features to punt to html6 |
| 09:16 | <hyatt> | or 5.1 |
| 09:17 | <hyatt> | or whatever the next version will be |
| 09:17 | <hyatt> | html5 is just huge and intimidating at this point |
| 09:17 | <hyatt> | so much new stuff |
| 09:17 | <hsivonen> | hyatt: yeah |
| 09:18 | hsivonen | notes that Adobe has copied the year-in-namespace-URI anti-pattern from the W3C |
| 09:18 | <hyatt> | bedtime for me |
| 09:18 | <hyatt> | night |
| 09:22 | <hsivonen> | hmm. the first Flex examples Adobe offers don't have anything in them explaining why you wouldn't want to use an onchange event handler plus a matching initializer (except you avoid the part of having to write the matching initializer) |
| 09:23 | <hsivonen> | heh. the Flex reference is like javadocs after a treatment by a graphic designer |
| 09:26 | <hsivonen> | wow, flex is huge. I wonder how many person-centuries Adobe has put into this proprietary platform |
| 09:57 | <mpt> | othermaciej, with special types of buttons for add/remove, WebKit can know to draw them as (–)(+) in Mac OS X rather than as [–][+] :-) |
| 09:59 | <othermaciej> | mpt: huh? |
| 10:00 | <mpt> | <othermaciej> it seems weird to me to have specialized kinds of button controls just for these two actions |
| 10:01 | <othermaciej> | mpt: yes, but I don't understand what you are saying about (-)(+) vs [-][+] |
| 10:02 | <mpt> | I mean circular (like all the add/remove row buttons in Mac OS X), rather than rectangular (like typical <button>s) |
| 10:10 | <annevk> | anyone here who happens to know how to limit a <Files foo> to the current directory in Apache? |
| 10:11 | <annevk> | I'm confused, why does http://www.whatwg.org/specs/web-apps/current-work/ have the W3C specification layout? |
| 10:21 | <mpt> | It's a conspiracy |
| 10:22 | <mpt> | Either that, or a CVS error |
| 10:22 | <annevk> | WHATWG uses SVN |
| 10:22 | <annevk> | maybe Hixie's script messed up |
| 10:26 | <mpt> | I get a 502 Proxy Error on the w3.org version, but not on the rest of w3.org |
| 10:27 | <annevk> | dev.w3.org seems down |
| 10:37 | <annevk> | it's up again |
| 12:05 | <zcorpan> | hmm. is the [[Get]] method on HTMLDocument defined in html5? |
| 12:07 | <annevk> | don't think so |
| 12:08 | zcorpan | reverse engineers the others |
| 12:51 | <zcorpan> | hmm, role in svg eh |
| 12:51 | <zcorpan> | then html:role might as well be dropped altogether? |
| 12:52 | <annevk> | yeah |
| 12:52 | <annevk> | it's of no use in languages that have no notion of focusability anyway |
| 12:54 | <zcorpan> | indeed |
| 12:54 | <zcorpan> | post this to the list? |
| 12:54 | <annevk> | and making that global too just leads to people using the wrong format |
| 12:56 | <zcorpan> | although allowing it for any format makes it easier to support in a particular format; just add a way to make elements focusable |
| 12:57 | <annevk> | that depends on how you implement it |
| 12:58 | <annevk> | another way would be: just add a namespace URI to some list |
| 13:59 | gsnedders | laughs at rumours that Apple is working on something to rival Google Gears |
| 14:12 | <zcorpan> | annevk: could you rephrase? i don't follow |
| 14:14 | <annevk> | i'm saying that the cost of adding support for these attributes on n-formats does not have to be big |
| 14:20 | <zcorpan> | annevk: ok. indeed |
| 14:21 | <zcorpan> | we'd still have to support aaa:foo="" though |
| 14:21 | <zcorpan> | i think |
| 14:22 | <zcorpan> | unless we can convince dojo to use both aria-foo and aaa:foo |
| 14:25 | <annevk> | lets hope we can |
| 14:33 | <zcorpan> | i've emailed aaronlev and anders, let's see what they think |
| 15:53 | <Philip`> | It's slightly irritating that when I find a nice technique in SVG to achieve some effect, I then find that the implementations of that feature are unusably buggy |
| 16:23 | <zcorpan> | man, ie's handling of <object> is harier than i thought |
| 16:25 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cbody%3E%3Cobject%20name%3Dx%3E%3Cembed%20name%3Dx%3E%3C%2Fobject%3E%0D%0A%3Cscript%3E%0D%0Aw(%22document.x.length%3A%20%22%20%2B%20document.x.length)%0D%0Aw(%22tagName%3A%20%22%20%2B%20document.x.tagName)%0D%0Aw(%22innerHTML%3A%20%22%20%2B%20document.x.innerHTML)%0D%0Aw(%22firstChild%3A%20%22%20%2B%20document.x.firstChild)%0D%0A%3C%2Fscript%3E |
| 16:47 | <hsivonen> | Any advice whether I should bother to insist on my mobileOK comments or just let it be? |
| 17:02 | <zcorpan> | hsivonen: depends on whether you like wasting your time ;) |
| 17:03 | <hsivonen> | zcorpan: I take that as a "let it be" |
| 17:04 | <zcorpan> | yeah |
| 17:04 | <hsivonen> | though I find it *absurd* to say that XML 1.1 is OK but PNG isn't |
| 17:04 | <zcorpan> | indeed |
| 17:04 | <zcorpan> | or to pretend that XML is being dealt with in the first place |
| 17:04 | <zcorpan> | it's just harmful to XML |
| 17:05 | <zcorpan> | it might force opera to also use the html parser for xml content |
| 17:08 | <hsivonen> | Also, this imaginary profile doesn't make sense. |
| 17:09 | <hsivonen> | I have 2 mobile devices currently and both only host browsers based on engines that you can expose to real Web content |
| 17:16 | <hsivonen> | hmm. reading the XHTML 1.0 RNG schema I find some presentational attributes I didn't remember even existed |
| 17:16 | <hsivonen> | frame and rules |
| 17:32 | <zcorpan> | on <table> right |
| 17:48 | <hsivonen> | zcorpan: Regarding the HTML 4.0 request: do you have an opinion on treating all quirky doctypes as html4? |
| 17:48 | <hsivonen> | or should I just special-case HTML 4.0 doctypes? |
| 17:50 | hsivonen | special-cases HTML 4.0 |
| 18:19 | <zcorpan> | hsivonen: just 4.0 |
| 18:23 | <hsivonen> | zcorpan: ok |
| 19:51 | <Hixie> | wow i've no idea how the whatwg page ended up with the w3c stylesheet |
| 19:51 | <Hixie> | that's screwed up |
| 20:18 | <hsivonen> | zcorpan: I think I've nailed HTML 4.0 support now: http://validator.nu/?doc=http%3A%2F%2Fln.hixie.ch%2F |
| 20:19 | <zcorpan> | hsivonen: nice! |
| 20:28 | <hsivonen> | zcorpan: Re: the way duplicate IDs on imageshack are reported as two errors as opposed to error plus info: that comes from the bowels of Jing, which doesn't know about info |
| 20:28 | <hsivonen> | zcorpan: I think I should move the XHTML 1.0 ID duplicate checking to a new mechanism when I write a new mechanism for HTML5 |
| 20:35 | <hsivonen> | am I reading correcly that XSD regexps don't have \u escapes? |
| 20:37 | hsivonen | still doesn't like white space differences between HTML5 and XML |
| 20:40 | <hsivonen> | Hixie: just checking: enumerated values are now ASCII-case-insensitive for both HTML5 and XHTML5, right? (this appears to have changed when I wasn't looking) |
| 22:11 | <Philip`> | "A date or time string is a valid date or time string if the following algorithm, when run on the string, doesn't say the string is invalid." - that's totally helpful |
| 22:11 | Philip` | tries reading the 67-step algorithm |
| 22:22 | <gsnedders> | Philip`: that and the parsing algorithm are the only two sections I've yet to review |
| 22:45 | <Philip`> | ^\s*(\d\d\d\d-\d\d-\d\d\s*T?\s*\d\d:\d\d(:\d+\.?\d*)?\s*(Z|[+-]\d\d:\d\d)|\d\d:\d\d(:\d+\.?\d*))\s*$ |
| 22:45 | <Philip`> | Much easier to read |
| 22:46 | <Philip`> | but it seems odd that you can't have a valid date (no time) string, so maybe I'm missing something |
| 22:50 | <Philip`> | ^\s*(\d\d\d\d-\d\d-\d\d(\s+|\s*T?\s*)\d\d:\d\d(:\d+\.?\d*)?\s*(Z|[+-]\d\d:\d\d)|\d\d:\d\d(:\d+\.?\d*))\s*$ - oops, bugfix |
| 22:50 | <Philip`> | Ugh |
| 22:50 | <Philip`> | ^\s*(\d\d\d\d-\d\d-\d\d(\s+|\s*T\s*)\d\d:\d\d(:\d+\.?\d*)?\s*(Z|[+-]\d\d:\d\d)|\d\d:\d\d(:\d+\.?\d*))\s*$ |
| 22:51 | <Hixie> | are you have connection issues? |
| 22:51 | <Hixie> | :-P |
| 22:54 | <Philip`> | ^\s*(\d\d\d\d-\d\d-\d\d(\s+|\s*T\s*)\d\d:\d\d(:\d+\.?\d*)?\s*(Z|[+-]\d\d:\d\d)|\d\d:\d\d(:\d+\.?\d*)?)\s*$ |
| 22:55 | <Philip`> | Sorry, I think there's a newt in my keyboard that's typing regexps at me :-( |
| 22:55 | <Hixie> | looks like an ISO-8601 regexp to me, but i recommend perl's /x option |
| 22:56 | <Philip`> | Pfah! Whitespace is for Python programmers |
| 22:56 | <Hixie> | lol |
| 23:03 | <Dashiva> | I'd recommend quantifiers |
| 23:03 | <Hixie> | i want the part of my brain that knows all the http response codes off by heart back. |
| 23:04 | <Dashiva> | 404 |
| 23:04 | <Dashiva> | Actually, probably 410 |
| 23:04 | <Hixie> | (as in, i want to reclaim that part of my brain, as i don't think it's something i actually need to remember) |
| 23:04 | <Hixie> | it just seems wrong to me that i just instinctively know it's "304 Not Modified". |
| 23:04 | <Hixie> | and not 305... or 303... or whatever. |
| 23:04 | <Philip`> | Dashiva: Like \d{2}? That's longer than just typing \d\d |
| 23:05 | <Dashiva> | It's more readable, and it's shorter for n>2 |
| 23:05 | <Hixie> | (Use Proxy... See Other...) |
| 23:05 | <Dashiva> | 207? |
| 23:05 | <Philip`> | There's only one value in datetime with n>2, and far more with n<=2 :-) |
| 23:05 | <Dashiva> | Still more readable :) |
| 23:06 | <Hixie> | 207? |
| 23:06 | <Dashiva> | What's that one? |
| 23:06 | <Hixie> | probably webdav or something |
| 23:06 | <Hixie> | i don't know of a 207 in http 1.1 |
| 23:06 | <Hixie> | the google says 207 MULTISTATUS |
| 23:06 | <Dashiva> | Impressive |
| 23:08 | <Hixie> | RFC4918:11.1 says 207 Multi-Status |
| 23:08 | <Hixie> | defined in section 13 |
| 23:09 | <Hixie> | jesus wept, webdav needs to crawl down a hole and die |
| 23:09 | Hixie | goes back to defining manifest parsing |