| 00:02 | <TabAtkins> | You don't seem to understand how much people hate A/a. |
| 00:02 | <TabAtkins> | They're *horrible* API for most use-cases. |
| 00:02 | <TabAtkins> | Anyway, your encouragement won't do much, since it's Dirk who'll be doing it for us. ^_^ |
| 00:03 | <Hixie_> | i have no trouble understanding that A/a is bad |
| 00:03 | <Hixie_> | i have no trouble with the idea of adding new ways of doinh arcs |
| 00:03 | <Hixie_> | my problem is with this idea of adding new names for each command |
| 00:04 | <Hixie_> | or adding any names that aren't short one-letter names |
| 00:05 | <TabAtkins> | There are no reasonable letters left for new arc commands. |
| 00:06 | <TabAtkins> | I mean, the fact that a smooth quadratic uses T shows that we're out of reasonable letters already. ^_^ |
| 00:06 | <Hixie_> | i don't understand the concern |
| 00:07 | <Hixie_> | why does it matter what the letters are? |
| 00:07 | <Hixie_> | you just find a mnemonic and go with it |
| 00:07 | <Hixie_> | e.g. E for ellipse |
| 00:07 | <TabAtkins> | ?_? You're asserting that we should continue with the practice of adding single-letter command names. I'm claiming that there are no reasonable single-letter names for those commands. |
| 00:07 | <Hixie_> | or R for rounded corner |
| 00:07 | <Hixie_> | or O for circle |
| 00:08 | <Hixie_> | or V for curVe |
| 00:08 | <Hixie_> | you don't double the size of a language because of lack of imagination |
| 00:08 | <TabAtkins> | Separately, I assert that the single-letter names are stupid. Syntax minimization at its worst. |
| 00:08 | <Hixie_> | that's fine, but that boat sailed years ago |
| 00:08 | <TabAtkins> | Yup, and it's returned, and we're changing the rigging on it now. |
| 00:08 | <Hixie_> | this is bad language design |
| 00:09 | <Hixie_> | if you're gonna start adding replacement features for everything SVG screwed up, you're gonna end up with the world's most confusing language |
| 00:09 | <Hixie_> | adding features doesn't simplify |
| 00:09 | <TabAtkins> | It's consistent with the names of the subpath *elements* we're adding. |
| 00:09 | <Hixie_> | it only makes things worse |
| 00:09 | <Hixie_> | oh god, you're adding elements too? |
| 00:09 | <TabAtkins> | I understand that you think that. I agree some of the time. |
| 00:26 | <Hixie_> | TabAtkins: why is it not true here? |
| 00:38 | <jamesr_> | TabAtkins, y u n l c s? |
| 01:29 | <TabAtkins> | Hixie: Consistency is a virtue, but not an absolute one. One must balance it against the benefits of whatever is breaking consistency. Also, being consistent with the future and pushing the past to the side can mitigate a lot of the pain of inconsistency. |
| 01:29 | <TabAtkins> | Basically, it's just an error to reject something solely because it's inconsistent with the present. |
| 01:31 | SamB_MacG5 | wonders why http://dev.w3.org/html5/spec/the-canvas-element.html#the-canvas-element suggests XBL as somehow being something you could use ... |
| 01:31 | <TabAtkins> | It was written a while ago. |
| 01:32 | <Hixie> | TabAtkins: i'm not talking about being consistent, though, i'm talking about adding redundant features |
| 01:32 | <TabAtkins> | Redundancy is fine! Redundancy can be author-friendly. |
| 01:34 | <Hixie> | if you're starting from that assumption, i think it's unlikely we'll agree :-) |
| 01:34 | <TabAtkins> | I think it is obviously untrue that redundancy is an absolute bad. |
| 01:35 | <TabAtkins> | And when there is a choice between redundancy and inconsistency, redundancy should probably win. |
| 01:36 | <Hixie> | i think following that line of reasoning would easily double the API surface of the web |
| 01:36 | <Hixie> | which imho is _clearly_ a negative |
| 01:36 | <TabAtkins> | It would only double if you're adding redundant version of everything. |
| 01:37 | <TabAtkins> | Increasing the surface area of the web by 20% or so, in return for making shitty legacy things more consistent with the more glorious future, is a cost I'm willing to pay. |
| 01:38 | <Hixie> | but it doesn't make the old features more consistent with the future -- it makes a new feature consistent with the feature, while also keeping the old inconsistent features |
| 01:38 | <Hixie> | (and given how we don't know what the future is, it's unclear that one can be consistent with it) |
| 01:38 | <TabAtkins> | Yes? We can't get rid of the old features, and twisting the future to be consistent with them just produces something horrible. |
| 01:41 | <Hixie> | having old+newold+new is worse than old+new (where newold = the new redundant feature) |
| 01:41 | <Hixie> | because basically the more you have, the more complicated it is, the harder it is to teach, to write tutorials, to test, to spec, to implement, to learn, etc |
| 01:42 | <Hixie> | it's arguable whether a new feature that isn't consistent with a bad old feature is better or worse than being consistent, given the cost of inconsistency, but that's a case-by-case thing |
| 03:25 | <Hixie> | othermaciej: htmlwg question -- if i notice an htmlwg bug that might be valid has been marked invalid without any comment (no boilerplate, rationale, etc), is this something anyone cares about that i should raise somewhere? i don't personally care but if i notice it and there's something trivial i can do to help, i'm happy to do so |
| 03:29 | <othermaciej> | Hixie: if you point such bugs out to an editor and/or a chair, it would be helpful |
| 03:29 | <Hixie> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=18223 https://www.w3.org/Bugs/Public/show_bug.cgi?id=16512 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=16022 |
| 03:30 | <Hixie> | (fyi, see also https://www.w3.org/Bugs/Public/show_bug.cgi?id=15042 ) |
| 03:30 | <Hixie> | othermaciej: ^ |
| 03:30 | <othermaciej> | I don't understand how to interpret "how do you set up the tracks in the html?" as spec feedback |
| 03:31 | <othermaciej> | if you understand what it means, I would appreciate if you could add a clarifying comment |
| 03:31 | <Hixie> | i presume it's asking for examples of <track> |
| 03:31 | <othermaciej> | likewise "I first saw this code suggested by Jeremy Keith in his excellent book ‘HTML5 |
| 03:31 | <othermaciej> | For Web Designers’ (" |
| 03:31 | <othermaciej> | is it? it might be asking for an example, or the person might be confused, or they might think there is a bug with <track> |
| 03:32 | <Hixie> | well like i said, "might be" |
| 03:32 | <Hixie> | not saying they are :-) |
| 03:32 | <othermaciej> | what about the one citing Jeremy Keith? |
| 03:32 | <Hixie> | yeah that one is less clear |
| 03:32 | <othermaciej> | what does that mean? |
| 03:32 | <Hixie> | dunno. probably cut off. seemed likely to be an intentional question, though, not just invalid |
| 03:33 | <othermaciej> | seems invalid to me, or needs info at best |
| 03:33 | <Hixie> | oh definitely isn't directly actionable |
| 03:33 | <othermaciej> | I personally feel that one is of the same status as "asdfgh asdfgh" |
| 03:33 | <Hixie> | k |
| 03:34 | <othermaciej> | in that it does not even suggest either a problem with the spec or a proposed change |
| 03:34 | <othermaciej> | for 16022, I also am not really sure what it means |
| 03:34 | <othermaciej> | do you understand what it is saying? |
| 03:34 | <Hixie> | haven't studied it closely enough |
| 03:35 | <Hixie> | but if someone filed it and is watching the bug, it seems polite to ask for more info rather than just closing it without following the process :-) |
| 03:35 | <othermaciej> | I find myself unable to parse it |
| 03:35 | <Hixie> | given that the bug system is the w3c's main feedback mechanism |
| 03:35 | <Hixie> | it's like with the whatwg list, i promise replies to all feedback on the spec, even nonsensical feedback |
| 03:36 | <othermaciej> | the HTML WG policy is that INVALID may be applied if "Bug is obvious junk or spam. Or, originator decides upon reconsideration that the comment is wrong. Does not require a full Editor's response." |
| 03:36 | <othermaciej> | NEEDSINFO is "Additional information is required to accept or reject this comment. Editor's response required. Editor should be clear on what additional info is required. It is strongly recommended that bug reporters should provide the requested additional information, if the request is reasonable, before they consider escalating." |
| 03:36 | <othermaciej> | I would consider either acceptable for those three bugs |
| 03:36 | <Hixie> | i guess my definition of "junk" is less wide than yours :-) |
| 03:36 | <othermaciej> | as the required info would be "please clearly state a problem with the spec or identify a suggested change" |
| 03:37 | <Hixie> | (as editor i basically didn't mark any invalid, iirc) |
| 03:37 | <Hixie> | (so i was a bit surprised to see it being used) |
| 03:38 | <othermaciej> | I don't think your recollection is correct |
| 03:39 | <othermaciej> | I found 183 bugs in the "HTML5 spec" component that were marked INVALID while you were editor |
| 03:39 | <Hixie> | any of them marked that way by me? |
| 03:39 | <Hixie> | without boilerplate? |
| 03:40 | <othermaciej> | that's harder to do a quick query for |
| 03:41 | <othermaciej> | I see many marked as such by the editorial assistants or by Msg2er |
| 03:41 | <othermaciej> | in random sampling |
| 03:41 | <Hixie> | (search within that set for bugs closed by me, then search again for bugs closed by me with the boilerplate, and subtract the counts, that should do it. not that you need to bother :-) ) |
| 03:41 | <othermaciej> | I can't readily search for bugs closed without the boilerplate |
| 03:42 | <Hixie> | right, search for them all, then with it |
| 03:42 | <Hixie> | the difference is those without |
| 03:42 | <Hixie> | (if you wanted the actual bugs, you could grab the IDs from the second set and list them as IDs to exclude in the first search, or something) |
| 03:42 | <Hixie> | (but that's getting messy) |
| 03:43 | <othermaciej> | point being, it has been accepted process that bugs which do not appear to state an issue and instead appear to be a copy/paste error, random typing, a non-bug question, or the like can be resolved w/o boilerplate |
| 03:43 | <Hixie> | anyway, it's no big deal |
| 03:43 | <Hixie> | k |
| 03:43 | <othermaciej> | I'm willing to believe you never personally used INVALID since I can't find any counter-examples |
| 03:43 | <Hixie> | the fourth one was a separate thing, just fyi. https://www.w3.org/Bugs/Public/show_bug.cgi?id=15042 |
| 03:44 | <Hixie> | hopefully it'll solve itself. |
| 03:44 | <othermaciej> | it does seem to me the test suite bug you cited was probably wrongly closed, but the spec bug rules don't apply there and I have not followed test suite development, so I am not in a good position to comment further |
| 03:44 | <Hixie> | yeah i wasn't saying that one was part of the same issue. |
| 03:44 | <Hixie> | just making sure you had it on your radar. |
| 03:44 | <Hixie> | more in your role as webkit guy than htmlwg guy. |
| 03:45 | <othermaciej> | ok |
| 03:46 | <othermaciej> | it does seem necessary to figure out the answer to what toDataURL does for hi-res backing stores |
| 03:46 | <Hixie> | the whatwg spec is clear on that topic |
| 03:46 | <othermaciej> | perhaps it needs the "HD" treatment like getImageData and putImageData |
| 03:46 | <Hixie> | it has had that treatment in the whatwg spec. |
| 03:46 | <othermaciej> | ah, ok |
| 03:46 | <Hixie> | this is one of the areas where tho two specs have forked. |
| 03:46 | <othermaciej> | I believe our canvas implementors are tracking the whatwg spec more than the htmlwg spec on this |
| 03:46 | <Hixie> | yeah, i expect everyone but microsoft is in that boat. |
| 03:46 | <othermaciej> | it would be nice if the w3c version was at least not contrary to the high-res-compatible edition |
| 03:46 | <Hixie> | (sadly it was microsoft people who wontfixed the bug) |
| 03:47 | <Hixie> | agreed |
| 03:47 | <othermaciej> | is the canvas toBlob method a fork point? |
| 03:48 | <Hixie> | dunno |
| 03:48 | <othermaciej> | (wondering if toBlobHD or toBlob is the fork, to determine if this same issue applies) |
| 03:48 | <Hixie> | i'm guessing it's all the HD stuff |
| 03:48 | <Hixie> | i think we had toBlob long ago |
| 03:48 | <Hixie> | i definitely didn't add toBlob at the same time as the HD stuff |
| 03:48 | <Hixie> | the HD stuff is relatively new |
| 03:48 | <Hixie> | (in response to safari feedback, mainly) |
| 03:49 | <othermaciej> | yes, I'm aware, and I'm glad it was added |
| 03:49 | <othermaciej> | as you can see, all of Apple's product line is moving to 2x displays |
| 03:49 | <othermaciej> | so we got to be the first ones to test how the old spec worked in the face of 1x-only-tested content |
| 03:49 | <Hixie> | yeah |
| 03:49 | <Hixie> | (love the retina macbook btw) |
| 03:50 | <othermaciej> | I wish I had one, trying to order them for my engineers first though |
| 03:52 | <Hixie> | yeah, i don't have one personally, but i got one for my partner |
| 04:01 | <Hixie> | in other news, man, w3c bugzilla is being slow today |
| 04:01 | <Hixie> | keep getting 502s |
| 04:02 | <othermaciej> | me too :-( |
| 04:40 | SamB_MacG5 | is surprised to discover that he is in the XSL or XQuery working group |
| 04:41 | <SamB_MacG5> | (well, that's what bugzilla thinks, anyway!) |
| 04:51 | <othermaciej> | Hixie: why did you move this bug to the whatwg product? https://www.w3.org/Bugs/Public/show_bug.cgi?id=10912 |
| 04:51 | <othermaciej> | Hixie: are you going to back-clone it? |
| 04:52 | <othermaciej> | (HTML WG needs copies of resolved bugs in our product to be able to provide a record of responses to comments) |
| 05:02 | <nessy> | it's happening to many bugs - looks like all of the ones that were resolved later... |
| 05:05 | <kennyluck> | Can we have a QA contact (a mailing list) for all bugs in the WHATWG component? I'd like to subscribe to that list. |
| 05:46 | <Hixie> | othermaciej: oh, didn't realise you wanted the closed ones also. i moved all the bugs assigned to me that were marked LATER to the WHATWG component. |
| 05:46 | <Hixie> | othermaciej: so i wouln't lose them. |
| 05:48 | <Hixie> | othermaciej: there have been many bugs that get reassigned to other components, e.g. HTML.next, rather than get resolved, fwiw. so i don't know that it's possible to make such a list currently. |
| 05:49 | <Hixie> | kennyluck: contributor⊙wo should be that, iirc |
| 05:49 | <Hixie> | kennyluck: just follow that |
| 05:49 | <othermaciej> | Hixie: can you clone them in one direction or another please? |
| 05:49 | <Hixie> | othermaciej: yeah, send me a mail to remind me |
| 05:50 | <kennyluck> | Hixie, how to? Is that a mailing list? |
| 05:50 | <Hixie> | should be easy enough to set up my script to do that |
| 05:50 | <Hixie> | kennyluck: in bugzilla, you should be able to set your account to follow that one |
| 05:50 | <kennyluck> | oh, you mean Bugzilla following? |
| 05:50 | <Hixie> | https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email |
| 05:50 | <Hixie> | yeah |
| 05:50 | <Hixie> | gotta go, bbl |
| 07:17 | <jgraham> | othermaciej: BTW your more minimal filesystem API looks nicer than the Google one, but it does seem like one would quickly end up with a "pyramid of doom" if every single file operation needs to be in its own callback |
| 07:50 | <jgraham> | othermaciej: In addition I am worried that we have added, or attempted to add, 3 local storage mechanisms in the last 5 years, and our record of doing it well isn't that great |
| 07:50 | <jgraham> | (localStorage, WebSQL, IndexedDB) |
| 07:52 | <jgraham> | (so the platform total, including WebSQL, is 4 of which 3 are already known to be various degrees of broken) |
| 07:54 | <SimonSapin> | jgraham: which is the not-known-broken one? |
| 07:57 | <jgraham> | IndexedDB |
| 07:57 | <Ms2ger> | That one's just hated, right? |
| 07:57 | <jgraham> | By no one uses that yet |
| 07:57 | <jgraham> | So we probably haven't worked out why it is broken yet |
| 07:58 | <jgraham> | Hence I am worried about adding a new storage API before we even work out what the problems that need to be fixed with the previous one are |
| 07:59 | <jgraham> | (I suspect "callback hell" is one of the problems, and I don't think the filesystem API proposals address that) |
| 08:55 | <eighty4> | Any ideas on http://www.netmagazine.com/features/truth-about-structuring-html5-page ? |
| 09:00 | <zcorpan> | TabAtkins: maybe you should ask what the svg wg think about multiple-letter commands before discussing it in whatwg :-) |
| 09:14 | <annevk_> | eighty4: hard to argue with the truth |
| 09:15 | <eighty4> | annevk_: i.e. we shouldn't use the new html5 elements? |
| 09:16 | annevk_ | was mocking the title |
| 09:16 | <hsivonen> | the outline algorithm is ill-clothed as long as there’s no selector for selecting by outline depth |
| 09:16 | <eighty4> | ... |
| 09:16 | eighty4 | is to stupid to get jokes just before lunch |
| 09:17 | <annevk> | eighty4: I stopped caring about semantics a while ago, so these days whenever people ask me I just tell them to use what works best for them |
| 09:17 | <annevk> | eighty4: I personally use <nav> and such as it's nicer than <div id=nav>, if some people prefer the latter, that's cool too |
| 09:17 | <eighty4> | annevk: I've been finding <header> and such in the same way |
| 09:18 | <eighty4> | makes my html cleaner and easier to maintain imo |
| 09:18 | <hsivonen> | Re: semantics: https://twitter.com/glazou/status/250516174473920512 |
| 09:20 | <annevk> | eighty4: exactly, and in a decade from now or so someone will do a new study towards what people are doing and how markup is practiced and the definitions in the specification will be adjusted accordingly |
| 09:20 | <eighty4> | ah well. Back to figuring out how to move things around in this comment form I guess. Seems more important. |
| 09:20 | <annevk> | eighty4: just like the HTML4 element definitions have been adjusted (e.g. for <dl>) |
| 09:21 | <jgraham> | eighty4: I read a little bit of that article and found it was wrong on matters of fact, so I gave up and stopped reading |
| 09:22 | <jgraham> | If the facts taht you are using to support your opinion are fabrications, there's probably very little value in your opinions |
| 09:22 | <annevk> | hsivonen: that's "asshole" per pilgrim classification, no? |
| 09:22 | <eighty4> | jgraham: if anything you should point that out. Seems a shame if people read it and believe it :) |
| 09:22 | <annevk> | if people believe stuff they read online they might be in for some surprises down the road :) |
| 09:23 | <jgraham> | eighty4: If I pointed it out every time some clueless or malicious web developer used incorrect assertions to write controversial articles in the name of publicity I wouldn't have any time to do anything else |
| 09:23 | <eighty4> | annevk: lol |
| 09:24 | <hsivonen> | but see http://epubsecrets.com/ibooks-the-latest-epub-3-0-reader.php |
| 09:24 | <eighty4> | jgraham: meh! |
| 09:24 | <annevk> | eighty4: also, it's important to conserve one's energy http://xkcd.com/386/ |
| 09:24 | <eighty4> | jgraham: (swedish for me not having a response but thinking you should do it anyways) |
| 09:24 | <eighty4> | annevk: I love that one. I live by it :) |
| 09:25 | <annevk> | I like to think I learned from it :p |
| 09:25 | <eighty4> | I never learn |
| 09:27 | <eighty4> | ah well, when I have the time I'll read som of the responses to the post. Should be fun |
| 09:30 | <annevk> | eighty4: you'll learn, might take a long time, mind you; I think I've done it for over half a decade at least with regards to standards discussions |
| 09:30 | <annevk> | and actually, I still do: http://krijnhoetmer.nl/irc-logs/whatwg/20120925#l-101 I just no longer bother sending email :) |
| 09:32 | <eighty4> | annevk: In truth I do get better. I've stopped arguing with trolls :) |
| 09:33 | <eighty4> | annevk: that log is from a couple of hours back :D |
| 10:34 | <jgraham> | hsivonen: Do you really want to encourage the W3C to have big monolithic releases where all known issues have to be fixed? |
| 10:40 | <hsivonen> | jgraham: no. they can drop stuff from snapshots instead of fixing: http://w3cmemes.tumblr.com/post/31865121758/the-joker-shares-his-approach-on-css2-1-issues |
| 10:40 | <hsivonen> | jgraham: I don't want Microsoft to create a new doc mode that implements stuff that others won't be able to implement across modes |
| 10:41 | <hsivonen> | jgraham: and I don't want to deflect n00b requests to implement the bogus REC in Gecko |
| 10:42 | <jgraham> | I don't want the navigation algorithm to be replaced by "now do magic stuff" just for fear that Microsoft might otherwise add in a mode that implements it |
| 10:42 | <jgraham> | In fact I don't think that's practically possible |
| 10:43 | <hsivonen> | jgraham: the W3C REC could say “do magic” and WHATWG and W3C ED’s could try to say something more precise |
| 10:44 | <eighty4> | annevk: ok, I know I shouldn't care but the authors html is kind of horrible :) |
| 10:44 | <jgraham> | In this specific case I don't see how that would work without undefining a bunch of stuff |
| 10:44 | <eighty4> | www.truthabouthtml5.com really isn't nice html |
| 10:44 | <annevk> | noobs caring about the navigation algorithm? not sure that would ever happen |
| 10:44 | <jgraham> | I mean, navigation spreads its tentacles all over the spec |
| 10:46 | <hsivonen> | eighty4: oh was the article trolling for attention in order to sell a book? ok. |
| 10:46 | <eighty4> | hsivonen: I would imagine so, given that the article seems taken from the book. |
| 10:46 | <jgraham> | hsivonen: I would much prefer that the W3C moved to a model where we got releases say every 6 months, and there was an understanding that the spec might not be bug-free |
| 10:47 | <jgraham> | Seems like the closest thing to a living standard that could be fig-leafed as process |
| 12:20 | <zcorpan> | i've moved this to a separate file so other specs can use it: http://dvcs.w3.org/hg/quirks-mode/raw-file/tip/status-warning.js |
| 12:21 | <zcorpan> | (see http://dvcs.w3.org/hg/quirks-mode/raw-file/tip/Overview.src.html for how it looks) |
| 14:03 | <annevk> | who the fuck cares about .mobi anyway? |
| 14:04 | <darobin> | .mobi is still around? |
| 14:04 | <annevk> | it was awkward when I ran into some people from Vodaphone couple of years after I published http://annevankesteren.nl/2004/12/mobi-stld and they recalled what I wrote |
| 14:06 | <darobin> | I reckon they're used to that :) |
| 14:10 | <hsivonen> | what’s the spec for window.screen? |
| 14:13 | <smaug____> | paul_irish: looks like robohornet does something odd with testharness, which causes tests to test something else than what is actually expected. https://github.com/robohornet/robohornet/issues/66 |
| 14:13 | <hsivonen> | I miss zcorpan’s .mobi site that served a single-pixel GIF |
| 14:14 | <zcorpan> | hsivonen: i let the domain expire |
| 14:17 | <annevk> | Ms2ger: was just looking into merging that fix from hasather |
| 14:18 | <Ms2ger> | Too late ;) |
| 14:18 | <annevk> | guess we can now declare hosting specs on github a "great success" |
| 14:18 | <odinho> | and everyone had cake and was happy :-) |
| 14:18 | <Ms2ger> | Did someone change the case of whatwg again? |
| 14:19 | Ms2ger | mumbles about unnecessary merges |
| 14:20 | <annevk> | Ms2ger: my bad |
| 14:20 | <Ms2ger> | Hmm? No, github's bad :) |
| 14:20 | <annevk> | Ms2ger: well I renamed back to /whatwg |
| 14:20 | <Ms2ger> | Oh |
| 14:20 | <Ms2ger> | Keep it that way now? :) |
| 14:21 | <annevk> | but quite a while ago |
| 14:21 | <annevk> | yes |
| 14:22 | <zewt> | heh i read .mobi as the kindle ebook format |
| 14:23 | <annevk> | hsivonen: window.screen is in CSSOM View (at least when I worked on that) |
| 14:29 | <zewt> | google's search result stats must get pretty nastily broken for ED/TR results |
| 14:29 | <zewt> | -ED |
| 14:31 | <zewt> | since invariably the TR gets returned and i can't quickly find the ED in the results, so i click the TR result then click through to the ED--presumably making google thing the TR is what I wanted, making it even more likely to be at the top |
| 14:47 | <annevk> | whoa, Opera and Chrome accept http://017700000001/ |
| 14:48 | <annevk> | http://www.amazon.com/The-Tangled-Web-Securing-Applications/dp/1593273886 is pretty interesting |
| 14:48 | <zewt> | octal, one of those things which are utterly useless yet somehow refuse to die |
| 14:49 | <zewt> | heh https://twitter.com/ID_AA_Carmack/status/243125862403297281 |
| 14:51 | <othermaciej> | jgraham: doesn't the Google one also require a callback for each operation? |
| 14:51 | <othermaciej> | jgraham: (other than when using the sync API in a Worker) |
| 15:10 | <annevk> | zewt: the problem is more that IPv4 is only allowed to be written as DEC.DEC.DEC.DEC |
| 15:32 | <zewt> | annevk: when parsing a URL whose base URL is null, what does eg. "set scheme to base's scheme" mean? SIGSEGV? (i might be missing a default-base-url rule somewhere) |
| 15:32 | <annevk> | zewt: how did you get there? |
| 15:33 | <zewt> | new URL("http://foo.com";); |
| 15:33 | <annevk> | you would not get there |
| 15:33 | <annevk> | you can never get in the "hierarchical" state if base URL is null |
| 15:36 | <annevk> | maybe I'll rename "hierarchical" to "relative" |
| 15:36 | <zewt> | new URL("?a=1"): 1: scheme start, step 1 does nothing, step 2 goes to no scheme; 2: no scheme goes to hierarchical |
| 15:36 | <zewt> | (the case I was actually tracing) |
| 15:37 | <annevk> | ah |
| 15:37 | <annevk> | small bug, thanks |
| 15:37 | <zewt> | (i guessed doing that would actually want to end up invalidated, but was trying to see if that's what actually happens) |
| 15:40 | <annevk> | fixed |
| 15:42 | <dglazkov> | good morning, Whatwg! |
| 15:43 | <zewt> | should the URL ctor throw on invalid URLs, since it does that for base anyway? seems confusing that eg. changing .path and querying .href silently gives the original URL if it was invalid |
| 15:44 | <annevk> | zewt: maybe, but a) that does not happen for <a> and such and b) it might make introducing new schemes that need parser integration trickier |
| 15:44 | <annevk> | zewt: you can check the new isInvalid flag |
| 15:44 | <annevk> | maybe that should be named isValid |
| 15:46 | <zewt> | seems confusing that changes are silently discarded in that state, though |
| 15:48 | <annevk> | you can still set .href |
| 15:48 | <zewt> | but nothing else |
| 15:49 | <annevk> | well doh, if the input is invalid it would be kinda hard to change anything |
| 15:49 | <annevk> | and it's largely an edge case anyway and it that case better extensibility wins |
| 15:49 | <annevk> | in* |
| 15:52 | <jgraham> | othermaciej: Yes, but their proposal sucks even more, so that's not a great argument |
| 15:53 | <othermaciej> | jgraham: I don't know of a reasonable way to avoid callback-per-operation while still avoiding synchronous I/O on the main thread |
| 15:53 | <zewt> | it just seems like a confusingly silent error condition, where the interface is still there, no errors are raised, but it doesn't do anything useful and the reason for why it's no-opping isn't necessarily obvious |
| 15:53 | <othermaciej> | jgraham: that being said, I am not really sure why any local sandboxed storage use cases would need this but couldn't use indexeddb |
| 15:53 | <jgraham> | othermaciej: I think we should perhaps spend some time trying to work out a pattern for that |
| 15:53 | <othermaciej> | jgraham: so I think maybe the right next step is to get very clear about the use cases |
| 15:53 | <jgraham> | Before adding yet more APIs that die under callback hell |
| 15:54 | <jgraham> | But yeah, I agree about IndexedDB and use cases |
| 15:54 | <annevk> | zewt: not too worried with error consoles and whatnot |
| 15:54 | <rwaldron> | annevk was just looking at the mutation methods—great stuff. One question though: Can these be specified to return the node they operate on? |
| 15:54 | <rwaldron> | http://dom.spec.whatwg.org/#mutation-methods |
| 15:54 | <zewt> | othermaciej: fwiw, i expect a portion of it is that everyone implicitly understands and "trusts" filesystem access as a basic storage mechanism for file-like data, where indexeddb is less known and proven in people's minds |
| 15:55 | <annevk> | rwaldron: I haven't done that because that would be inconsistent with every other platform API there is |
| 15:55 | <rwaldron> | I see |
| 15:55 | <rwaldron> | well, that's unfortunate. |
| 15:55 | <Ms2ger> | This ain't jquery |
| 15:56 | <othermaciej> | zewt: yeah, but - Chrome's sandboxed filesystem store is (I believe) in reality backed by a database |
| 15:56 | <othermaciej> | zewt: so the trust level is completely illusory |
| 15:56 | <zewt> | othermaciej: yeah that's pretty bad, defeats the benefits entirely |
| 15:56 | <annevk> | rwaldron: so yes, we can do whatever we want, but taking the rest of the platform into consideration is important |
| 15:57 | <annevk> | rwaldron: it's already inconsequential enough imo |
| 15:58 | <rwaldron> | Ms2ger what do you gain from saying that? Or better, what does the future of the platform gain? |
| 15:58 | <zewt> | (databases don't tend to be terribly good at file-like stuff, eg. storing a 500 MB file and then modifying a few bytes in the middle, appending data without compounding fragmentation, etc) |
| 15:58 | <Ms2ger> | rwaldron, the ability to have functions return something more useful than the this value |
| 15:58 | <rwaldron> | annevk I understand, but since these effectively supplant the previous API, it doesn't seem unreasonable. |
| 15:59 | <rwaldron> | Ms2ger such as? |
| 15:59 | <annevk> | rwaldron: by the platform I mean more than just DOM manipulation :) |
| 15:59 | <annevk> | I mean every API in every standard |
| 16:00 | <rwaldron> | annevk yes, the same ones that are abstracted over, because they are mostly miserable. |
| 16:00 | Ms2ger | yawns |
| 16:00 | <rwaldron> | Ok, well I can see that arguing this is pointless, so thanks for your time everyone. |
| 16:01 | Ms2ger | implements remove() instead |
| 16:01 | <Ms2ger> | I guess I get to write tests now |
| 16:02 | <annevk> | rwaldron: I'd prefer a more complete plan than just changing some APIs here and there into chaining APIs |
| 16:02 | <annevk> | rwaldron: it feels a bit irresponsible to just do it here and there |
| 16:02 | <annevk> | rwaldron: I'm not opposed to the idea though |
| 16:03 | <rwaldron> | Ms2ger seriously? I'm reaching out to spec authors, as a member of TC39 (representing jQuery), to coordinate efforts that will improve the use of APIs that will be used to create the future |
| 16:03 | <rwaldron> | I don't appreciate your dismissive comments |
| 16:03 | <rwaldron> | Considering I said nothing to you to deserve them |
| 16:04 | <Ms2ger> | This is an issue that would be better solved in JS proper |
| 16:04 | <Ms2ger> | If you're in tc39, you're better placed than me to do that |
| 16:04 | <rwaldron> | Ms2ger and what issue is that? |
| 16:04 | <Ms2ger> | You mean there is no issue? |
| 16:05 | <Ms2ger> | Then why do you want to change a few methods in DOM? |
| 16:05 | <rwaldron> | I'm asking you to clarify what issue you're referring to |
| 16:05 | <rwaldron> | "This is an issue that would be better solved in JS proper" |
| 16:05 | <Ms2ger> | Clearly you believe there is an issue with the mutation methods |
| 16:06 | <rwaldron> | I believe there is an issue with the way much of the DOM has been specified |
| 16:06 | <Ms2ger> | I never really understood which issue it is that returning the this value is supposed to solve |
| 16:06 | <rwaldron> | It's not a problem with the language, it's a problem with the authors of the specifications. |
| 16:06 | <Ms2ger> | But it is pointless to try to fix it by changing a few methods here and there |
| 16:07 | <paul_irish> | as pointless as adding a duplicate remove() method purely for improved usability? |
| 16:08 | <rwaldron> | If these methods represent a newly created API, why not specify them in a way that will match the expectations of web developers that are currently using libraries to abstract over the existing APIs |
| 16:08 | <rwaldron> | let me rephrase that... |
| 16:08 | <rwaldron> | "Give them what they want" |
| 16:08 | <Ms2ger> | paul_irish, I'm not sure what parallel you're trying to draw? |
| 16:08 | <zewt> | because adding a return value that has minor benefit just because you're not currently using the return value means you can never, ever in the future use the return value to represent something very useful |
| 16:09 | <rwaldron> | You're implementing methods that "almost" match the API of several DOM libraries |
| 16:09 | <rwaldron> | except that you've left out a significant part and that will just cause more confusion. |
| 16:10 | <Ms2ger> | "Do what jquery does" is not an argument |
| 16:10 | <ls_n> | not just jQuery |
| 16:10 | <danheberden> | Wow, that was a quick mis-characterization of what rwaldron said |
| 16:10 | <annevk> | rwaldron: can't blame Ms2ger and I for the DOM... that was done way back; we just fixed a bunch of holes |
| 16:10 | <annevk> | anyway, gotta go |
| 16:11 | <rwaldron> | Ms2ger that's amusing. |
| 16:11 | <paul_irish> | i'm saying these new methods are introduced for the purpose of improving the usability of the DOM. I can guarantee you that developers would find a useful return value more intuitive |
| 16:11 | <Ms2ger> | You're clearly just trolling |
| 16:11 | <rwaldron> | paul_irish +1 |
| 16:11 | <zewt> | (rwaldron: being rude is not going to convince anyone of much of anything) |
| 16:11 | <rwaldron> | Ms2ger I am absolutely not trolling |
| 16:12 | <rwaldron> | And I don't appreciate the name "name-calling" |
| 16:12 | <danheberden> | zewt, as someone mostly reading this conversation and not participating, I would hardly call rwaldron the rude one here |
| 16:12 | <rwaldron> | so far you've resorted to being unfairly dismissive and now to name calling. |
| 16:13 | <rwaldron> | I spoke up because I want a better DOM API |
| 16:13 | <rwaldron> | That's not trolling. |
| 16:13 | <ls_n> | From my review of the spec, I found it odd that the method names and intent seemed to be following popular library implementations, but without including a return value. |
| 16:13 | <zewt> | the addBefore/addAfter tend not to actually need chaining, since their pattern is e.addAfter(a, b, c); you don't need to say e.addAfter(a).addAfter(b).addAfter(c) |
| 16:13 | <rwaldron> | ls_n agreed, which is why I came to discuss |
| 16:14 | <ls_n> | If the spec had included a return value other than the calling node, I would have called that into question because there is precedence, but I could have been convinced. |
| 16:15 | SamB_MacG5 | thinks it would be handy if the multi-page specs had auto-redirect pages, like epydoc makes: http://epydoc.sourceforge.net/faq.html#redirect |
| 16:15 | <rwaldron> | and all I've gotten in response is "yawn", some snide comments about jQuery and some misguided argument about fixing the issue in JS (ie. the language). |
| 16:15 | <ls_n> | Without a return value, it seems very confusing. Almost purposeful. Why not preserve least surprise, and follow precedence? |
| 16:16 | <Ms2ger> | Is there any reason it is "confusing" except for "it doesn't match jquery"? |
| 16:16 | <rwaldron> | ls_n before annevk left, he told me that having a return value doesn't match the rest of the platform |
| 16:16 | <ls_n> | Ms2ger: fwiw, YUI also includes these methods, and also returns the calling node. |
| 16:17 | <Ms2ger> | Let's take "jquery" as a shorthand for "jquery and other frameworks that look the same" |
| 16:17 | <Ms2ger> | if that makes you happy |
| 16:17 | <SamB_MacG5> | Ms2ger: if you take the name, well ... |
| 16:17 | <ls_n> | rwaldron: interesting. I wonder what the definition of "platform" is in that context. I'm thinking appendChild() has a return value. |
| 16:18 | <Ms2ger> | ls_n, appendChild() returns the argument, not the this value |
| 16:18 | <ls_n> | Ms2ger: I'm aware :) My point is that it returns something. |
| 16:18 | <Ms2ger> | Hah |
| 16:19 | <SamB_MacG5> | that doesn't sound like much of an argument |
| 16:19 | <Ms2ger> | Nobody claimed that returning something useful didn't match the rest of the patform |
| 16:19 | <zewt> | annevk obviously didn't say that DOM functions should never return anything at all, heh |
| 16:19 | <Ms2ger> | platform* |
| 16:19 | <danheberden> | Ms2ger: from a completely "read the statement" - you start with something, you do something to it, why did the thing go away? |
| 16:19 | <danheberden> | sorry, completely "read the statement" argument |
| 16:19 | <zewt> | (parse error, redo from start) |
| 16:19 | <Ms2ger> | So |
| 16:19 | <danheberden> | like - i think that while jQuery executed successfully, there is a natural tendency to expect that |
| 16:19 | <rwaldron> | Ms2ger as does Prototype (however, its use has significanlty diminished) and Dojo (which is widely used in the enterprise) |
| 16:20 | <Ms2ger> | Does anybody want to reply to my actual point instead of complaining about my use of "jquery"? |
| 16:21 | <danheberden> | Ms2ger: but youre combatting points with "because jQuery does it means nothing" |
| 16:21 | jwalden | suspects this scrollback would be marginally interesting to read, fires up logs |
| 16:21 | <SamB_MacG5> | Ms2ger: isn't "gratuitous mismatch with libraries" enough? |
| 16:21 | <ls_n> | appendChild() would be less useful if it didn't return something. If it returned the calling node, it would still be useful. Whether more or less useful than returning the argument is debatable, but not the point. There is utility there. There is less utility without a return value. |
| 16:22 | <Ms2ger> | SamB_MacG5, I was asking for a point besides that |
| 16:22 | <zewt> | SamB_MacG5: no, "we should do it because libraries do it" is not an argument at all |
| 16:22 | <rwaldron> | Ms2ger my response is this: devs use libraries because the DOM APIs are awful. Regardless of the libary, they all share common behaviours and returning the this value is one of them. |
| 16:22 | <SamB_MacG5> | zewt: not a strong argument, I'll grant |
| 16:22 | <Ms2ger> | That's not an answer to my question |
| 16:22 | <danheberden> | And how _else_ would you characterizing people's wants besides their use of these libraries? |
| 16:23 | <Ms2ger> | Let me try again |
| 16:23 | <rwaldron> | These new mutation methods will not ease any DOM API pain points |
| 16:23 | <zewt> | ls_n: as I already said, functions should *not* be given a return value soley for the sake of having a return value; it needs to have enough value to *commit* that return value to that purpose for all time |
| 16:23 | <SamB_MacG5> | but if you haven't got anything *better* to do ... |
| 16:23 | <danheberden> | there is no big online survey of "how do you want the dom to work" |
| 16:23 | <danheberden> | you look at library useage |
| 16:23 | <zewt> | using the return value for something of value 0.1 means you can never use it to support a use case that appears a year from now with value 5.0 |
| 16:23 | <Ms2ger> | Is there any reason that not returning the this value is "confusing" except for "it doesn't match a number of JS libraries"? |
| 16:23 | <zewt> | you're stuck with the 0.1 forever |
| 16:23 | <SamB_MacG5> | zewt: okay, that's an argument |
| 16:24 | <ls_n> | zewt: A fair point, but fear of the future in the face of current usage with developers expectating a return value seems silly. |
| 16:24 | <rwaldron> | zewt but... the current API is the problem |
| 16:25 | <rwaldron> | library adoption over DOM API seems to indicate displeasure with the way it was originally done, in favor of what we are explaining |
| 16:25 | <danheberden> | My addition, Ms2ger, was that JS devs get the idea that "i have something, then i call something on it" and naturally expect that 'something' to be there again |
| 16:25 | <danheberden> | that there is a natural inclination, in addition to library buy-in |
| 16:25 | <zewt> | ls_n: can't say I agree with the premise; I expect functions to do what they're documented as doing |
| 16:26 | <SamB_MacG5> | zewt: probably best not to steal the names the libraries have been using, then ? |
| 16:26 | <danheberden> | and that "it doesn't match a number of JS libraries" might indeed be the only big reason, albeit a very big reason/indicator |
| 16:26 | <SamB_MacG5> | otherwise, the users are liable to read the wrong documentation |
| 16:27 | jwalden | never understood returning-this behavior, versus just naming the same variable a second time, which is inarguably clearer as it requires no knowledge of the return type of the method that's being called |
| 16:27 | <zewt> | rwaldron: that's merely saying "we should arbitrarily mimic jquery because people use jquery" and could be applied to any aspect of the library |
| 16:27 | <SamB_MacG5> | jwalden: well, the one problem with that is that you have to actually name a variable in the first place |
| 16:28 | <zewt> | SamB_MacG5: as long as it doesn't result in weird, contrived or hard to type function names, i don't mind trying to use different names, no |
| 16:28 | <rwaldron> | Ms2ger if the method is "setting" (which includes mutation of subtrees, etc) the this value should be returned. If the method is "getting" (eg. an attribute value by name) then return the value of thing we're requesting. I don't understand what is so hard about this. cc zewt |
| 16:28 | <jwalden> | SamB_MacG5: I don't believe that's a problem, only if you buy into the jquery mindset of chaining method-call upon method-call in the first place |
| 16:28 | <jwalden> | SamB_MacG5: it kind of begs the question |
| 16:28 | <danheberden> | rwaldron: you could also add 'creating' to that list |
| 16:28 | <SamB_MacG5> | jwalden: well, I didn't say it was a *big* problem |
| 16:28 | <Ms2ger> | rwaldron, nothing hard about "how it works", only about "why it's useless" |
| 16:28 | <rwaldron> | danheberden +1 |
| 16:28 | <Ms2ger> | Sorry, useful* |
| 16:28 | <zewt> | (rwaldron: you're repeating yourself and ignoring the responses, so unless you have something new to say I'm not going to repeat responses :) |
| 16:29 | <SamB_MacG5> | but I must admit sometimes I have trouble naming my variables :-) |
| 16:29 | <danheberden> | zewt, i'll bite - there are known problems with how jQuery's API is - rather, some outstanding bugs of people saying they'd like certain api methods to work |
| 16:29 | <danheberden> | and we're backed into a corner because it's existing stuff or we want to match the dom |
| 16:29 | jwalden | sees naming variables as a quite-useful form of documentation, all the more for being an actual part of the code, so less apt to bitrotting |
| 16:29 | <ls_n> | So this argument boils down to a disagreement in the value of returning this? |
| 16:30 | <danheberden> | however, this concept - of return values - people like |
| 16:30 | <danheberden> | people comment on how helpful it is |
| 16:30 | <danheberden> | or how unhelpful it is that the DOM doesn't do that |
| 16:30 | <zewt> | SamB_MacG5: again the chaining pattern tends to be built around eg. "add this one element", but when you're able to pass a list of items to add, a lot of that goes away |
| 16:30 | <danheberden> | so taking a huge number of developers that _choose_ to use jQ's API in to consideration seems worth something, ya? |
| 16:31 | <zewt> | (danheberden: <zewt> rwaldron: that's merely saying "we should arbitrarily mimic jquery because people use jquery" and could be applied to any aspect of the library) |
| 16:32 | <Ms2ger> | danheberden, jquery has its advantages |
| 16:32 | <danheberden> | but no one is saying we should arbitrarily mimic jquery |
| 16:32 | <danheberden> | except you two |
| 16:32 | <Ms2ger> | Papering over browser differences, say |
| 16:32 | <danheberden> | instead of replying to points, you mis-characterize the argument |
| 16:32 | <zewt> | that's exactly what you just said--"lots of people choose to use jquery, and that's an argument for doing this one particular thing in jquery's way" |
| 16:32 | <Ms2ger> | I think that's a bigger reason that people would use it than just the chaining |
| 16:32 | <danheberden> | zewt - THAT PARTICULAR feature |
| 16:32 | <jwalden> | this late in the game, fighting against long-standing DOM precedent, consistency with the rest of the DOM seems the right thing, and let libraries do their thing however they want it as they always do |
| 16:32 | <rwaldron> | In addition to danheberden's argument about taking developer preference into consideration, I'd also like to share some third party statistics: http://trends.builtwith.com/javascript |
| 16:33 | <danheberden> | i'm talking about the return value |
| 16:33 | <zewt> | no, we've replied to many points; i suspect you're not paying attention |
| 16:33 | <danheberden> | zewt - i've agreed with some, i think, so perhaps i should add a +1 in reply if i don't have an argument |
| 16:33 | <rwaldron> | zewt sure, I'll bite... ready? Here goes... |
| 16:34 | <ls_n> | zewt: There are many differences between DOM libraries. If they all, or even mostly, agree on a set of methods to improve the experience of working with the DOM, that's not mimicking jQuery, that's codifying accepted convention. |
| 16:34 | <zewt> | anyway, HTML API design is based around technical arguments, not statistics and +1s and "look how many people use jquery"; i can recall no technical arguments being given for this at all, so i'm going to go and do my day job unless one turns up |
| 16:35 | <rwaldron> | Developers that build real things on the real web prefer library APIs, such as jQuery, YUI, Dojo, etc. as such, the API decisions of those libraries should be taken into consideration when new DOM APIs are created. |
| 16:35 | <danheberden> | zewt, you're aware that these "people" are the ones using these APIs, ya? |
| 16:35 | <zewt> | i use these APIs every day |
| 16:35 | <danheberden> | and the technical arguments don't have to use the APIs daily? |
| 16:35 | <danheberden> | and you wouldn't like them at all easier to use? |
| 16:36 | <zewt> | returning "this" doesn't make them easier to use |
| 16:36 | <Ms2ger> | danheberden, sure, I want them to be easier to use |
| 16:36 | <danheberden> | or because YOU'VE used them and like them means the other thousand people should too |
| 16:36 | <zewt> | not significantly enough to commit the return value to it forever |
| 16:36 | <danheberden> | cuz zewt, personally, i agree with you |
| 16:36 | <Ms2ger> | I've been trying to get people to explain why returning "this" would make them easier to use |
| 16:36 | <Ms2ger> | I haven't heard anything |
| 16:36 | <danheberden> | i am so used to how it works it doesn't bother me |
| 16:36 | <danheberden> | but i see the need for many others |
| 16:36 | <danheberden> | mainly because i work support a lot |
| 16:37 | <danheberden> | so i get a sense of that |
| 16:37 | <danheberden> | i do trainings and deal with a lot of typical developers |
| 16:37 | <danheberden> | Ms2ger: what kind of metrics _would_ be helpful? |
| 16:38 | <danheberden> | like - what way could we get an idea of buy-in from people that would satisfy you? |
| 16:38 | <Ms2ger> | I don't care much about "buy-in" |
| 16:38 | <danheberden> | perhaps i'm not using the right word |
| 16:38 | <danheberden> | i'm meaning if people would find it useful |
| 16:38 | <danheberden> | how to track/measure that |
| 16:38 | <zewt> | it seems clear to me that having a few functions return this, and most (eg. the legacy ones) return nothing or (in the case of appendChild) its argument, both makes the chaining pattern much less useful and very brittle and confusing |
| 16:39 | <Ms2ger> | I'm looking for someone to explain why people would find it useful |
| 16:39 | <danheberden> | like if i asked all of my students in a training, and had my coworkers do the same |
| 16:39 | <rwaldron> | zewt... technical argument: ES1, 3, 5, 5.1 and 6 (draft) have set a precendent for objects whose prototype methods return either a specific value that is relevant to or the result of an operation on the calling object, or a newly created copy of the calling object itself, which allows further calls to be "chained" |
| 16:40 | <Ms2ger> | rwaldron, want to give a few examples? |
| 16:40 | <rwaldron> | the DOM has deviated for a long time and users of DOM APIs have been "fixing" it for a decade. |
| 16:40 | <jwalden> | rwaldron: what precedents can you name for chaining in ECMAScript? I can think of exactly one |
| 16:41 | <jwalden> | rwaldron: (in the language, I mean) |
| 16:41 | <zewt> | the argument i'm looking for is "here's a thing which is made so much easier or less error-prone that it justifies committing the return value to this--and nothing else--even if it's inconsistent with lots of other functions that do related things" |
| 16:41 | <danheberden> | Ms2ger: as for the personal why, i've had people express their displeasure at it NOT returning `this`; i can try to gain more insight as to the motivation behind that |
| 16:41 | <rwaldron> | Ms2ger yes. Array.prototype.push returns a relevant value: the new length. Array.prototype.map returns a newly created array object with the values of the map operation |
| 16:42 | <Ms2ger> | danheberden, I would appreciate that |
| 16:42 | <rwaldron> | need more? |
| 16:42 | <rwaldron> | There is a whole spec full of examples. |
| 16:42 | <Ms2ger> | rwaldron, I think you misunderstood my question |
| 16:42 | <zewt> | rwaldron: what? the new length isn't "this", it's the new length |
| 16:42 | <Ms2ger> | rwaldron, I'm looking for cases where ES returns the this value |
| 16:43 | <zewt> | (and precedent isn't an argument that something should be done, it just means it has been) |
| 16:43 | <jwalden> | rwaldron: [].map is not an example of chaining, it's an example of a function with a return value, no? |
| 16:43 | <rwaldron> | zewt read my previous message before trying to argue something that I _just_ said |
| 16:43 | <jwalden> | rwaldron: the only example I can come up with is [].sort, for a method that chains but doesn't return a new value/object |
| 16:43 | <Ms2ger> | rwaldron, sorry, I misunderstood you |
| 16:43 | <rwaldron> | [12:40 PM] <rwaldron> zewt... technical argument: ES1, 3, 5, 5.1 and 6 (draft) have set a precendent for objects whose prototype methods return either a specific value that is relevant to or the result of an operation on the calling object, or a newly created copy of the calling object itself, which allows further calls to be "chained" |
| 16:44 | <Ms2ger> | rwaldron, I'm just not sure how that is relevant, then |
| 16:44 | <rwaldron> | jwalden push? |
| 16:44 | <rwaldron> | sorry, no |
| 16:44 | <rwaldron> | strike that |
| 16:44 | <Ms2ger> | rwaldron, I think we're all in violent agreement that there is a point to returning a useful value |
| 16:44 | <rwaldron> | (I missed the part where you said "chains but doesn't" |
| 16:44 | <rwaldron> | Ms2ger agreed. |
| 16:45 | <rwaldron> | But I argue that returning void 0/undefined is not doing anyone any favors |
| 16:45 | <Ms2ger> | Phew, we agreed on something ;) |
| 16:45 | <rwaldron> | +1 |
| 16:45 | <danheberden> | Ms2ger: lol |
| 16:46 | <danheberden> | Ms2ger: what dangers do you think are present in returning `this` instead of undefined? |
| 16:46 | <Ms2ger> | I guess I don't really see the value of returning 'this' in a few cases where we would otherwise return undefined |
| 16:46 | <danheberden> | what bad issues or problems would arrise from that? |
| 16:46 | <zewt> | danheberden: i've already explained that repeatedly :) |
| 16:46 | <Ms2ger> | One is that you can't return anything else |
| 16:46 | <zewt> | <zewt> using the return value for something of value 0.1 means you can never use it to support a use case that appears a year from now with value 5.0 |
| 16:47 | <Ms2ger> | Another is that you still need to remember which methods return something useful, and which return this |
| 16:47 | <danheberden> | zewt, so if addEventListener, after all these years, was going to support a different return value |
| 16:47 | <Ms2ger> | I think what would be more useful is a JS feature to call multiple functions on one object |
| 16:47 | <zewt> | if the value of returning "this" is 5.0--if it's a significant, measurable win--then sure; but "we should return *something*, so it may as well be this" is a bad idea |
| 16:48 | <danheberden> | zewt - it's more, like, "this function has no useful return value except for the original element" |
| 16:48 | <zewt> | danheberden: you're confusing foresight with hindsight: when addEventListener was first implemented, there was no way of knowing whether some other return value would have turned up |
| 16:48 | <danheberden> | zewt, i'm saying take advantage of that hindsight |
| 16:49 | <ls_n> | zewt: So the number of years that libraries have been using these methods, returning 'this', and not running into any major use case that would have been so much better than returning 'this' is not evidence? What would a reasonable wait time be? |
| 16:50 | <Ms2ger> | ls_n, who says they haven't found (even not particularly big) such use cases? |
| 16:50 | <danheberden> | zewt, i *do* understand your point |
| 16:50 | <danheberden> | and it's a good one |
| 16:50 | <zewt> | ls_n: it's not about "wait time", it's about adding a feature when there's a clear, measurable win, and that's exactly what nobody is giving--examples of things which are made measurably easier or less error-prone by doing this |
| 16:50 | <Ms2ger> | It's not like they could have implemented those |
| 16:50 | <danheberden> | i don't think this shoudl all be tackled super lightly |
| 16:50 | <rwaldron> | zewt Ms2ger I'm worried that the "avoid future hostility" argument is actually going to end up turning this into a lost opportunity (purely opinion) |
| 16:50 | <danheberden> | but i think there are some cases where one could ascertain whether or not returning this would be a safe future proof change |
| 16:50 | <rwaldron> | :| |
| 16:51 | <Ms2ger> | rwaldron, possibly |
| 16:51 | <danheberden> | and honestly, with this argument, you would NEVER change the return value from undefinded to something |
| 16:51 | <danheberden> | because of the fear you'd need that return value in the future |
| 16:51 | <Ms2ger> | danheberden, why not? Because something *even better* could come along? |
| 16:51 | <danheberden> | i do that too - i buy a really tasty snack and wait for the best time to eat it.. but in the end, it just goes bad |
| 16:51 | <danheberden> | because i waited and waited |
| 16:52 | <zewt> | danheberden: of course you would--when you have a clear benefit for doing so, just like adding any feature. that benefit isn't clear (at least to us) in this case |
| 16:52 | <danheberden> | zewt - so perhaps the question isn't as much of 'should we' or 'shouldn't we' |
| 16:52 | <danheberden> | but how can we gather the information necessary to make this decision |
| 16:52 | jwalden | doesn't think the "we might want to return something in the future" argument has much value here -- either there's an obvious return value, or there's nothing, and thinking something might turn up in the distant future seems unrealistic |
| 16:53 | <ls_n> | Ms2ger: what inconveniences people have come across have been inconveniences. At least, speaking from the YUI side of things. At the end of the day, if these methods are implemented without return value, then the libraries will call them, then return 'this' manually. It will still just be an inconvenience. |
| 16:53 | <danheberden> | jwalden i think it has some merit, for a period of time at least |
| 16:53 | <SamB_MacG5> | I think the "we might want to return something" argument should be judged based on what you could reasonably return |
| 16:53 | <jwalden> | danheberden: plausible, depending on the API I guess |
| 16:53 | <danheberden> | i think libraries like jQuery give an oppurtunity to see if stuff is garbage or not |
| 16:54 | <jwalden> | for most APIs it's kind of a stretch |
| 16:54 | <danheberden> | i mean, look at jQ - `.click and .mouseover` - seriously? |
| 16:54 | <danheberden> | we learned that kind of stuff is awful |
| 16:55 | <zewt> | and again, inconsistently returning "this" is confusing--for example, e.addBefore(e2).appendChild(e3).addBefore(e4) is very confusing, since appendChild returns e3, not e |
| 16:55 | <SamB_MacG5> | I'm guessing most methods have a three or less reasonable, non-vacuous return values |
| 16:55 | <SamB_MacG5> | s/a / |
| 16:56 | <SamB_MacG5> | zewt: yes, agreed |
| 16:56 | <ls_n> | zewt: yes is it |
| 16:56 | <danheberden> | (i have a call to take, my non-response isn't grumpy silence :) |
| 16:56 | <jwalden> | danheberden: fine, then, be that way |
| 16:56 | <jwalden> | ;-) |
| 16:56 | <ls_n> | would e.appendChild(e2).append(e3).boom() be less confusing? |
| 16:56 | <zewt> | anyhow i'm out of time for now--day job and all--so afk |
| 16:57 | <jgraham> | It would be nicer if js made it easier to write a function like chain(elem, appendChild(e1), appendChild(e2), appendChild(e3)) and so on |
| 16:58 | <jgraham> | Rather than forcing each function to return this or not work with chaining |
| 16:58 | <Ms2ger> | ^ that |
| 16:59 | <Hixie> | annevk: extending the legal url syntax lgtm |
| 16:59 | <Hixie> | annevk: do you have a plan for how to specify the authoring conformance criteria? |
| 17:01 | <annevk> | Hixie: not really, wanted to figure out browser stuff first |
| 17:01 | <Hixie> | k |
| 17:01 | <annevk> | Hixie: but I guess in the end I'll just take inspiration from one of your specs |
| 17:01 | <Hixie> | heh |
| 17:01 | <annevk> | Hixie: that's what I usually do anyway, look for some existing pattern |
| 17:03 | <Hixie> | well there's several options on this front even just amongst stuff i've done :-) |
| 17:03 | <Hixie> | in particular, BNF variants and straight prose |
| 17:05 | <annevk> | rwaldron: """and all I've gotten in response is "yawn", some snide comments about jQuery and some misguided argument about fixing the issue in JS (ie. the language). """ dude, I tried to explain where I came from |
| 17:06 | <annevk> | rwaldron: up to and including that I'm fine with changing it, if we have some kind of plan |
| 17:07 | <annevk> | rwaldron: thus far it's like "can we do x?" "well, most of y doesn't do x at the moment and although we could try it, it seems kind of irresponsible without a plan for y" "..." |
| 17:08 | <rwaldron> | annevk I wasn't referring my discussion with you |
| 17:09 | <rwaldron> | annevk while you were away I provided several arguments beyond simply "can we do x?" |
| 17:09 | <annevk> | I think Ms2ger is arguing the same point, but not as constructive and friendly unfortunately |
| 17:10 | <rwaldron> | Ms2ger and I actually both agree that returning something is better then nothing |
| 17:12 | <rwaldron> | I'm stepping out for a few |
| 17:12 | <annevk> | that's not what he agreed to |
| 17:12 | <annevk> | see e.g. "I guess I don't really see the value of returning 'this' in a few cases where we would otherwise return undefined " |
| 17:12 | <annevk> | but yeah, my point was in particular that the platform does not return "this" |
| 17:12 | <annevk> | I don't know such APIs anyway |
| 17:13 | <rwaldron> | annevk [12:45 PM] <Ms2ger> rwaldron, I think we're all in violent agreement that there is a point to returning a useful value |
| 17:13 | <annevk> | right |
| 17:13 | <annevk> | but he's not convinced (like me) "this" is useful |
| 17:13 | <annevk> | furthermore, nowhere in the platform is this returned |
| 17:13 | <rwaldron> | This is really frustrating |
| 17:13 | <annevk> | and fwiw, platform is http://platform.html5.org/ of course |
| 17:14 | <rwaldron> | at no point did i say that ms2ger had agreed to returning this |
| 17:14 | <rwaldron> | I'm not even sure how you came to that based on what I jsut said |
| 17:14 | <annevk> | because you said he thought something is better than nothing |
| 17:15 | <annevk> | which is not what he said |
| 17:15 | <rwaldron> | dude |
| 17:15 | <rwaldron> | wtf |
| 17:15 | <rwaldron> | [12:45 PM] <Ms2ger> rwaldron, I think we're all in violent agreement that there is a point to returning a useful value |
| 17:15 | <rwaldron> | [12:45 PM] <rwaldron> (I missed the part where you said "chains but doesn't" |
| 17:15 | <rwaldron> | [12:45 PM] <rwaldron> Ms2ger agreed. |
| 17:15 | <rwaldron> | [12:46 PM] <rwaldron> But I argue that returning void 0/undefined is not doing anyone any favors |
| 17:15 | <rwaldron> | [12:46 PM] <Ms2ger> Phew, we agreed on something ;) |
| 17:15 | <rwaldron> | [12:46 PM] <rwaldron> +1 |
| 17:16 | <rwaldron> | I hate to leave while we're having so much, but I actually have to step out for an appointment |
| 17:16 | <annevk> | returning a useful value does not mean that returning something is better than nothing |
| 17:16 | <zewt> | ... he was agreeing with the first line (returning something useful is useful), not that returning undefined is bad |
| 17:16 | <annevk> | right |
| 17:17 | <rwaldron> | Cool, well don't sweat it. |
| 17:17 | <annevk> | rwaldron: ttyl then |
| 17:17 | <rwaldron> | I'm actually not interested in participating in this discussion anymore |
| 17:18 | <rwaldron> | Good luck with further development, I wish you nothing but success. |
| 17:19 | <annevk> | rwaldron: that's unfortunate; I hope you'll still contribute to other discussions |
| 17:26 | <annevk> | I had not expected people would actually call Array.prototype.push "chaining" as well |
| 17:26 | <annevk> | I thought "chaining" was reserved for methods that return "this" |
| 17:27 | <Hixie> | annevk: ho does Array push() chain? |
| 17:27 | <Hixie> | heycam|away: you following this Location thread on whatwg? |
| 17:28 | <annevk> | Hixie: because it returns something on which you can do an operation reportedly |
| 17:28 | <ls_n> | it's not chaining |
| 17:28 | <Hixie> | every function that returns anything is chaining then? |
| 17:28 | <Hixie> | o_O |
| 17:28 | <zewt> | that was just one of many confusions in that discussion, heh |
| 17:28 | <ls_n> | well, maybe this is semantics... |
| 17:29 | <annevk> | or maybe I parsed http://krijnhoetmer.nl/irc-logs/whatwg/20120925#l-975 and subsequent lines incorrectly |
| 17:30 | <ls_n> | "chaining" == `return this` vs "returns object" vs ? |
| 17:30 | <Ms2ger> | ls_n, I understood it to mean `return this` |
| 17:30 | <annevk> | ls_n: dunno man, I thought it was about returning the object you invoked the method on |
| 17:30 | <Hixie> | yeah, me too |
| 17:31 | <Hixie> | imho chaining is a layering violation, taking what should be a syntactic issue and dragging it into the api layer |
| 17:31 | <ls_n> | Yeah, I can see it either way, because you're chaining operations through the return value, regardless of whether it's 'this' |
| 17:32 | <Ms2ger> | abarth, so the html test suite currently splits submitted tests by person/organization that submitted them, any preference where those location tests should go? |
| 17:32 | <zewt> | annevk: ms2 asked for "examples" (implied: of things in ES that return the calling object), but was taken literally and received examples of random-not-chaining-at-all return values |
| 17:32 | <Hixie> | bbiab |
| 17:33 | <annevk> | zewt: so are there examples for "this"? |
| 17:33 | <zewt> | annevk: (also, though the ES quote thing wasn't relevant, it also says "a newly created copy of the calling object itself"--which isn't chaining at all when applied to something like a DOM node) |
| 17:33 | <zewt> | annevk: dunno; i don't think it matters (precedent isn't an argument) |
| 17:34 | <zewt> | (or I sure hope it isn't, we have mountains of really bad precedent in the older APIs :) |
| 17:34 | <Ms2ger> | I think jwalden had one |
| 17:35 | <zewt> | (in case the above wasn't clear--that ES line would mean returning this.cloneNode(), not this) |
| 17:35 | <jwalden> | annevk: Array.prototype.sort returns this; that's the only example I can think of |
| 17:35 | jwalden | has no idea why it returns this |
| 17:36 | <annevk> | jwalden: interesting |
| 17:36 | <Ms2ger> | jwalden, arr.sort().sort() // Just making sure |
| 17:36 | <zewt> | well, sorting multiple times is useful |
| 17:36 | jwalden | took advantage of that when constructing XSS exploits against the original Facebook platform, back five years ago, by applying sort to the global object :-) |
| 17:36 | <zewt> | (with different orderings) |
| 17:36 | <annevk> | zewt: I think precedents matter, because the lack of the platform doing it now is one of the arguments I use |
| 17:37 | <ls_n> | jwalden: prior to forEach, I never found it practically useful. |
| 17:37 | <zewt> | annevk: i think that's sort of halfway right |
| 17:37 | <Ms2ger> | zewt, fair :) |
| 17:37 | jwalden | thinks lack-of-platform-doing-it-now is the strongest argument against suddenly doing it now for new methods |
| 17:37 | <zewt> | annevk: it's not exactly precedent, so much as that the chaining paradigm only works well when it's supported consistently |
| 17:37 | <zewt> | eg. we don't want two or three functions that do it (precedent), we'd want to be able to do it everywhere to satisfy that |
| 17:38 | <annevk> | well yeah, my other argument is that I want to see some kind of plan rather than "lets do this here and see what happens" (sicking argues for that) |
| 17:38 | <zewt> | personally i write lots of code without jQuery or any other monolithic library at all and have never gone "man, I wish I could chain these calls", which is my own basic rationale :) |
| 17:39 | <annevk> | and Hixie's point about solving it elsewhere I like too, because then I don't have to worry |
| 17:39 | <jwalden> | heh |
| 17:39 | <ls_n> | annevk: I think a great deal of the feedback is attached to the names. These same methods exist, and behave consistently in libs. If you'd chosen different names, there might have been less reaction. |
| 17:40 | <zewt> | (i'm less enthusiastic about the language-level solution, since that's really hard to do in a sane way--adding new syntax to JS means you can't use it *at all* until it's widely supported, since the whole file will fail to parse) |
| 17:40 | <annevk> | ls_n: nah, this kind of feedback is relatively common also for non-lib methods |
| 17:40 | <annevk> | ls_n: e.g. the mutation observer stuff |
| 17:40 | <zewt> | (unless someone gets creative enough to find a way to avoid that, like the "use strict"; hack, but I doubt that'll happen) |
| 17:41 | <jwalden> | "use strict" was just a bad idea, given script concatenation |
| 17:41 | <jwalden> | c'est la vie |
| 17:41 | <annevk> | javascript folks should've learned from doctype switching, and didn't |
| 17:42 | <zewt> | (i've found it useful, but mostly as a linting thing and to aid my unit tests--until every browser supports it I'm not turning it on in live code) |
| 17:42 | <annevk> | but considering they were pretty far along with an out-of-band versioning strategy, maybe we're lucky :) |
| 17:43 | <annevk> | brendan considers this different strategies for developing the platform a good thing, but I'm not sure I'm quite with him as the technologies do need to work together at the end of the day |
| 17:44 | <ls_n> | There's attachment to the familiarity of appendChild() returning a node, and attachment to the existing behavior of append(str) in libs returning a node (though it is a different one). |
| 17:44 | <jwalden> | well, at this point tc39 is in theory all gung-ho about "no more language modes/versions", so there shouldn't be any more "use strict" mistakes, or even |use strict;| pragmas, or whatever |
| 17:45 | <jwalden> | new syntax will just break stuff, new editions will not break old code |
| 17:45 | <annevk> | jwalden: littlecalculist (iirc) is a great man |
| 17:45 | <jwalden> | :-) |
| 17:46 | <jwalden> | a little too much of the PL-theory propellerhead for me on rare occasion, but yeah |
| 17:46 | <jwalden> | and it takes all kinds anyway |
| 17:47 | jwalden | wouldn't want a committee of people like him :-) |
| 17:47 | <jwalden> | at least, not a whole committee of them |
| 17:47 | <zewt> | i don't really mind a bit of bumpiness for use strict, since some of the things it fixes are *really* annoying JS quirks (unintended globals being the most obvious; .freeze not causing exceptions is lame too, etc) |
| 17:47 | <zewt> | but i'd call that a one-time thing :) |
| 17:48 | <annevk> | anyone from Google here? What are the best email addresses for Alex Russell and Erik Arvidsson? I have their @google.com addresses, but if there's something they actually read and reply to, might be nice |
| 17:48 | <jwalden> | a better rollout strategy for use-strict probably would have helped some; jslint and json2.js picking it up prematurely was a large part of the problem |
| 17:49 | <jwalden> | even still, "backwards compatible" but not is just the worst of both worlds |
| 17:49 | <annevk> | in particular, I see arv is here, I'm looking for a reply to http://lists.w3.org/Archives/Public/www-dom/2012JulSep/0069.html |
| 17:50 | <zewt> | jwalden: python 3's strategy is the worst of all worlds :) overlapping compatibility is much more copable |
| 17:51 | jwalden | is ambivalent about python 3's strategy |
| 17:51 | zewt | isn't |
| 17:51 | <jwalden> | although I am perfectly happy to say it would not at all at all at all work for the web :-) |
| 17:51 | <jwalden> | diff'rent strokes, perhaps |
| 17:51 | <zewt> | python 3.0 released in dec 2008; it's 2012 and I'm still on 2.7. migration failed :) |
| 17:52 | <jwalden> | if they were aiming for a less-than-four-years transition |
| 17:52 | <jwalden> | python's always been a with-all-deliberate-speed sort of group |
| 17:53 | jgraham | expects python 3 transition to work eventually |
| 17:53 | <jwalden> | I think as long as they get there eventually, they're more or less happy |
| 17:53 | <jwalden> | yeah |
| 17:53 | <jwalden> | expecting a turnaround by some particular time, or aiming for one, is setting oneself up for disappointment |
| 17:54 | <jwalden> | and I've seen enough signs from people that they're slowly working on the transition that I don't think it can be said to have failed, right now |
| 17:54 | <zewt> | much saner to make breaking changes slowly, and to keep reasonable compatibility overlap between adjacent versions, instead of making a ton of big breaking changes at once, which just seemed like they got impatient |
| 17:54 | <jwalden> | signs from people, and from projects implemented in python, that is |
| 17:59 | <Ms2ger> | I've seen work on py3 compat in Mozilla's new python code, fwiw |
| 18:25 | <zewt> | annevk: should path step 2 also set fregment to "#", like hierarchical does? |
| 18:27 | <zewt> | (don't know which is correct, just seems odd that they differ) |
| 18:35 | <annevk> | zewt: fixed |
| 18:42 | <Hixie> | "Your task is nontrivial" |
| 18:42 | <Hixie> | story of our lives |
| 18:43 | <zewt> | "queue a nontrivial task" |
| 18:44 | <zewt> | (a big queue) |
| 18:46 | <jgraham> | It does sound like the end of the introduction to a badly translated text adventure, or something |
| 18:48 | <Hixie> | cabanier: is your work on adding blending etc to canvas covering things like adding blur effects? |
| 18:52 | <annevk> | Hixie: not sure if trolling, or just misunderstanding what he's on about |
| 18:52 | <Hixie> | pretty sure he's not trolling |
| 18:53 | <Hixie> | he's right that defining the conformance criteria is non-trivial |
| 18:53 | <Hixie> | but wrong if he thinks that's unusual :-) |
| 18:53 | <Hixie> | i think it's just the regular culture clash -- ietf and w3c often tend to shy away from fixing hard problems |
| 18:54 | <Hixie> | same with the shock that we might even consider doing something that we view as obsoleting an IETF STD |
| 18:54 | <Hixie> | whereas from our point of view, we're like, "look, we said it was broken years ago, we gave you a chance to fix it, now we've timed out and are doing it ourselves" |
| 18:54 | <say2joe> | hixie: Hooray to that. |
| 18:56 | <annevk> | I guess indeed it's the regular culture clash, but using "finding URLs in text" as an example as to why we need to restrict the syntax... |
| 18:56 | <annevk> | but I'm happy you took the time to explain that one |
| 18:57 | <Hixie> | finding urls in text is indeed something that is impossible if we consider any random string valid |
| 18:57 | <Hixie> | but (a) we don't, and (b) people don't want to find only valid URLs so that doesn't matter anyway |
| 18:58 | <Hixie> | it's pretty common for people to will the use case to be different because the real use case is hard to fix :-P |
| 18:58 | <Hixie> | (i do it all the time too :-P) |
| 18:58 | <dsheets> | annevk: your assertion that the composition of parsing, resolving, and canonicalizing is trivial points to the problem. Your task is not trivial so why should your algorithm be? |
| 18:58 | <annevk> | dsheets: hey! |
| 18:58 | <zewt> | when I saw the "why don't you just patch RFC#whatever" post I just grimaced, pitied whoever had to reply to that noise, and moved on :) |
| 18:59 | <Hixie> | we did patch the RFC |
| 18:59 | <Hixie> | didn't work well enough. anne's now doing it properly. :-) |
| 18:59 | <zewt> | exactly :) |
| 18:59 | <annevk> | dsheets: well, 1) I said "quite trivial" and 2) I guess it is indeed non-trivial, but it is rather easy to follow |
| 19:00 | <Hixie> | something can be non-trivial to design, yet be trivial in its result |
| 19:00 | <Hixie> | in fact, the more trivial the solution, typically, the harder one had to work to develop it :-P |
| 19:01 | <Hixie> | (all other things, e.g. how much the solution solves, being equal) |
| 19:01 | <dsheets> | annevk: I find it very difficult to follow. What are the allowable alphabets of conforming productions? What normalization is done? It's all mixed together in a prose state machine. |
| 19:01 | <annevk> | dsheets: and what I like about it in particular is that it is much closer to implementations, so if we want to extend it or implementations want to follow it to fix bugs, things will be a lot easier |
| 19:01 | <annevk> | dsheets: "c" can be any code point basically, including surrogate code points |
| 19:02 | <annevk> | dsheets: that's about it |
| 19:02 | <Hixie> | there's a definition of conforming productions? |
| 19:02 | <annevk> | nope |
| 19:02 | <zewt> | dsheets: do you really find IETF-style specs easier to follow than HTML-style algorithmic specs? because you'd be the first I've heard of |
| 19:02 | <annevk> | need to add that under "Writing" at some point |
| 19:02 | <Hixie> | dsheets: he hasn't defined what's valid yet. |
| 19:03 | <Hixie> | zewt: lots of people think declarative is easier than imperative. They're right, when you don't care about defining timing and error handling. |
| 19:03 | <Ms2ger> | zewt, for authoring, sure |
| 19:03 | <Hixie> | zewt: see e.g. the websocket protocol hybi mailing list |
| 19:03 | <Hixie> | zewt: it's really hard to read complex algorithms and work out their implications. |
| 19:03 | <zewt> | Hixie: personally I find imperative easier even as a user--anne's DOM Events work made the event system infinitely clearer to me, for example |
| 19:03 | <dsheets> | zewt: for testing, yes |
| 19:04 | <zewt> | there's a breaking point, of course, depending on the complexity of the algorithm |
| 19:04 | <Hixie> | zewt: fair enough |
| 19:05 | <annevk> | dsheets: fwiw, I'm not opposed to including some ABNF somewhere |
| 19:05 | <annevk> | dsheets: at the moment I'm focused on figuring out parsing (mostly what code browsers/curl/search engines/etc. need to run) |
| 19:07 | <dsheets> | annevk: mixing parsing and normalization obscures the meaning of a given identifier. Separating the spec into phases and specifying exactly what will pass through unmangled would be very helpful. |
| 19:07 | <Hixie> | what is "normalisation" here? |
| 19:08 | <dsheets> | Hixie: producing identifiers over which serialize compose parse is identity |
| 19:09 | <dsheets> | Hixie: that is, nonconforming -> conforming |
| 19:10 | <dsheets> | Hixie: canonicalization is related, i believe, but concerns things like hexadecimal case changes where both input and output are conforming but one representation is 'canonical' |
| 19:10 | <Hixie> | dsheets: i have no idea what what you just said means |
| 19:11 | <Hixie> | dsheets: how does this differ from "parse"? |
| 19:11 | <dsheets> | Hixie: which bit? if you parse a conforming URI and then serialize it, the result should be the original URI |
| 19:12 | <annevk> | hmm; http://example.org is conforming yet gives http://example.org/; or http://example.org:/ gives http://example.org/ |
| 19:12 | <dsheets> | Hixie: perhaps you say that there are conforming URIs that are not canonical and so the result is the canonicalization of the input… feeding this result back through should result in the same string |
| 19:12 | <Hixie> | dsheets: sounds like what you're saying is "normalisation" is the act of parsing then serialising. |
| 19:13 | <Hixie> | dsheets: so how could you separate it from parsing? |
| 19:13 | <zewt> | yeah. conforming and normalized are different things |
| 19:13 | <dsheets> | Hixie: normalization is whatever you do to produce a valid identifier from an arbitrary input |
| 19:14 | <Hixie> | dsheets: ok, so, parse then serialise. |
| 19:14 | <dsheets> | that is how you can test it, yes, but that is not the normalization algorithm |
| 19:14 | <Hixie> | dsheets: i guess i don't understand what you are asking for. |
| 19:14 | <annevk> | dsheets: it is in the new spec |
| 19:15 | <Hixie> | dsheets: the normalisation algorithm is "parse the string. serialise the bits into a url." |
| 19:15 | <annevk> | dsheets: and for sure parser/serialize is how a typical URL library works |
| 19:15 | <Hixie> | i don't see how else you could do it |
| 19:15 | <dsheets> | I am asking for the explicit separation of nonconforming -> conforming as well as conforming -> canonical |
| 19:16 | <dsheets> | http://www.example.com is conforming but noncanonical. http://www.example.com/ is canonical |
| 19:16 | <zewt> | to back up a little: what's the purpose of this? |
| 19:16 | <annevk> | sure, the former is input, the latter is output |
| 19:16 | <annevk> | that the former is conforming is yet to be written down |
| 19:17 | <Hixie> | dsheets: i don't think it makes sense to define two different parsers. |
| 19:17 | <dsheets> | If there are invalid inputs that produce valid outputs, those invalid inputs must undergo some sort of normalization to put them in the space of valid inputs |
| 19:17 | <Hixie> | dsheets: that would just be asking for them to end up out of sync. |
| 19:18 | <Hixie> | dsheets: it's better not to think of inputs as valid or invalid |
| 19:18 | <Hixie> | dsheets: whether a URL is valid or not is really just a minor detail for authoring conformance/lint tools |
| 19:18 | <dsheets> | Hixie: how can they be out of sync? they compose |
| 19:18 | <Hixie> | dsheets: to help authors avoid likely mistakes |
| 19:19 | <Hixie> | dsheets: i don't see how you could describe a parser that only parses invalid urls and that then passes the result of that to a parser that only accepts valid urls, that would be insane |
| 19:19 | <Hixie> | dsheets: you'd actually need three parsers then, one for invalid urls, one for valid urls, and one for unknown urls to determine if they were valid or not! |
| 19:19 | <annevk> | it would be twice the work and nobody would ever implement it that way |
| 19:19 | <Hixie> | dsheets: just have one parser, it's cleaner |
| 19:20 | <annevk> | this argument is interesting though |
| 19:20 | <annevk> | because it's the exact same argument we got from the W3C TAG about the HTML parser |
| 19:20 | <Hixie> | dsheets: can you imagine what a mess HTML parsing would be if we used that kind of strategy? |
| 19:20 | <annevk> | nobody else ever cared |
| 19:20 | <Hixie> | annevk: really? i guess i blissfully missed that |
| 19:20 | <Hixie> | annevk: or i've blocked it out of my memory :-P |
| 19:20 | <dsheets> | Hixie: not parsers, functions. You can compose all these functions in your parser and most implementations will. |
| 19:21 | <Hixie> | dsheets: function, parser, same thing |
| 19:21 | <annevk> | Hixie: I quite clearly remember DanC and such wanting a parser just for valid stuff |
| 19:21 | <Hixie> | annevk: weird |
| 19:21 | <Hixie> | dsheets: s/parser/algorithm/ in my argument above, it still holds. |
| 19:22 | <dsheets> | Hixie: no. Every parser is a function but not every function is a parser. Parsers operate on strings. |
| 19:22 | <Hixie> | dsheets: that doesn't affect my argument |
| 19:22 | <annevk> | hsivonen: sad news: "Unicode 6.2 will include the accelerated publication of the character U+20BA TURKISH LIRA SIGN" |
| 19:23 | <Hixie> | imho, the right way to do this is to have one function that turns a string into components (parser), one that turns components into strings (serialiser), one that turns an incomplete set of components and a complete set of components into one complete set of components (resolution), and one that takes a string and returns a boolean (conformance definition) |
| 19:24 | <dsheets> | Hixie: Does it? Specifying the composition of these functions for different inputs makes the meaning of the spec much clearer. It is then obvious what inputs are 'safe', what inputs will be mangled, and what inputs will never be mangled. |
| 19:24 | <Hixie> | dsheets: defining what inputs are safe is done by defining "valid URL", which is an entirely separate problem. |
| 19:25 | <Hixie> | dsheets: in the HTML spec, this is http://whatwg.org/html#writing vs http://whatwg.org/html#parsing |
| 19:25 | <dsheets> | Hixie: it would appear that inside of the parser, you generate a valid URL. Why is this obscured? |
| 19:26 | <annevk> | Hixie: parser and resolution are merged in the current spec |
| 19:26 | <annevk> | Hixie: I haven't written a serializer yet; though the API has various members that serialize URLs in various ways |
| 19:26 | <annevk> | Hixie: so I might not bother writing an explicit serializer |
| 19:27 | <annevk> | (never mind, I guess I should for HTTP and such) |
| 19:27 | <Hixie> | dsheets: i don't understand the question. |
| 19:27 | <Hixie> | annevk: i need a "parse" algorithm that returns components, and a "resolve" algorithm that returns an absolute url |
| 19:28 | <annevk> | Hixie: parse always returns an absolute URL |
| 19:28 | <Hixie> | annevk: how do i get the components? |
| 19:28 | <dsheets> | Hixie: Why specify only the composition instead of the factors? |
| 19:28 | <annevk> | Hixie: it returns a URL object that has components |
| 19:28 | <Hixie> | dsheets: i don't understand what that means |
| 19:28 | <annevk> | Hixie: but it's always a complete URL (or invalid) |
| 19:29 | <Hixie> | annevk: if it returns both an absolute URL and components, that's fine by me |
| 19:29 | <annevk> | Hixie: http://url.spec.whatwg.org/#concept-url is what you get back |
| 19:30 | <annevk> | Hixie: you parse an "input" into a concept-url, which has concept-url-scheme etc. |
| 19:30 | <Hixie> | annevk: k |
| 19:30 | <Hixie> | annevk: lgtm |
| 19:30 | <dsheets> | annevk: the base may be unknown or ambiguous. Can I defer relative resolution? |
| 19:31 | <Hixie> | just don't parse it until you need to resovle it |
| 19:32 | <annevk> | dsheets: hold the "input" until you have the base |
| 19:33 | <TabAtkins> | zcorpan: I sent email to WHATWG on *behalf* of the SVGWG, *because* we're adopting multi-letter commands. ^_^ |
| 19:33 | <dsheets> | Hixie: so no means will be provided to manipulate relative references? Relative references can never be serialized? |
| 19:34 | <Hixie> | dsheets: you shouldn't ask me, anne is the editor of this url spec |
| 19:34 | <Hixie> | dsheets: but i'm sure if you give anne use cases, he will be more than happy to address them |
| 19:34 | <Hixie> | dsheets: does anything on the web serialise relative urls? |
| 19:35 | <dsheets> | Hixie: anything that manipulates data structures which use relative references and outputs said data structures... |
| 19:35 | <Hixie> | dsheets: such as? |
| 19:35 | <dsheets> | Hixie: DOM transformers |
| 19:36 | <zewt> | (how is it 2012 and gmail doesn't let you add filters to mark as spam?) |
| 19:36 | <annevk> | dsheets: and they manipulate URLs? |
| 19:37 | <dsheets> | annevk: sure, partial resolution of URLs is common |
| 19:37 | <Hixie> | dsheets: do you have an example i can look at? |
| 19:37 | <Hixie> | zewt: it does |
| 19:37 | <smaug____> | paul_irish: ping |
| 19:38 | <zewt> | Hixie: lets you delete, and "never spam", but not "always spam" |
| 19:38 | <annevk> | dsheets: in any event, if we decide that we do want parsing and resolution separate, that's not really a big deal |
| 19:38 | <zewt> | i guess since the difference between deleted and spam is so opaque with gmail (if it affects filtering, I can't measure it), i may as well not care |
| 19:38 | <Hixie> | zewt: huh |
| 19:38 | <TabAtkins> | zewt: I think the intent is that you just mark it as spam normally, and let your filters catch up. |
| 19:38 | <Hixie> | zewt: i stand corrected. |
| 19:39 | <paul_irish> | smaug____: yessir |
| 19:39 | <zewt> | anyway, sorry for the distraction, didn't notice that you were still talking with ds :) |
| 19:39 | <Hixie> | zewt: i am capable of having multiple conversations at once :-P |
| 19:39 | <TabAtkins> | s/filters/normal spam filter/ |
| 19:39 | <Hixie> | zewt: (whenever i'm chatting here i'm also editing the spec :-P) |
| 19:39 | <dsheets> | Hixie: not off-hand, no. You can't conceive of converting a relative path into an absolute path or a schemed URI into a scheme relative URI? |
| 19:39 | <zewt> | well, i try to limit random irrelevant drop-ins to when there isn't an on-topic discussion going on :) |
| 19:40 | <Hixie> | dsheets: if you have no concrete examples, i have no trouble saying we don't need to address it. |
| 19:40 | <Hixie> | dsheets: i have never found a need to do so, personally |
| 19:40 | <smaug____> | paul_irish: just curious, based on what is some test added to robohornet |
| 19:41 | <dsheets> | Hixie: really? I have done this numerous times in numerous languages. Absolutizing URI references is useful. |
| 19:41 | <Hixie> | dsheets: i'd be happy to look at concrete examples |
| 19:41 | <Hixie> | dsheets: resolving urls is certainly useful, and the algorithm anne is defining does so |
| 19:42 | <smaug____> | (the range API for example looks very odd, since it ends up adding element with same id 50 times to document) |
| 19:42 | <Hixie> | smaug____: sounds realistic :-P |
| 19:42 | <dsheets> | Hixie: you are stonewalling. Please address the technical consideration. |
| 19:42 | <dsheets> | Hixie: resolution and partial resolution are different |
| 19:42 | <zewt> | he's asking for use cases--what you actually want to do (or would want to do) that the proposed API and spec doesn't handle |
| 19:42 | <smaug____> | paul_irish: you probably also saw https://github.com/robohornet/robohornet/issues/66 . It means that some tests are actually testing something else than what they are supposed to test |
| 19:42 | <smaug____> | Hixie: sure :) |
| 19:42 | <Hixie> | dsheets: i'm not the editor, anne is the one who will address issues on this spec. I'm just trying to explain to you how we work. |
| 19:43 | <paul_irish> | smaug____: based on isolated performance issues that have been identified in a few notable js applications and libraries. they've been reduced down to a useful quantity of code |
| 19:43 | <zewt> | that isn't stonewalling, it's the standard approach here |
| 19:43 | <Hixie> | dsheets: and the way we work is we don't address hypotheticals |
| 19:43 | <paul_irish> | smaug____: yeah 66 looks legit. |
| 19:43 | <Hixie> | dsheets: if you have done it as many times as you say, then you need but document them for us |
| 19:43 | <Hixie> | dsheets: e.g. a pointer to a page that does it |
| 19:44 | <dsheets> | Hixie: resolving foo/bar against /baz/ into /baz/foo/bar |
| 19:44 | <Hixie> | dsheets: do you have an example of something that does that? |
| 19:44 | <paul_irish> | smaug____: benchmark.js seems to be the strongest harness for benchmarking, but yeah produces some problems with this test in partic |
| 19:44 | <dsheets> | Hixie: resolving #frag against path into path#frag |
| 19:44 | <smaug____> | paul_irish: I was looking at DOM Range test, because I know that code is probably the least optimized code in Gecko... but then the test is actually spending time everywhere else but in Range code |
| 19:45 | <smaug____> | paul_irish: "some" problems |
| 19:45 | <Hixie> | dsheets: do you have an example of something that does that? |
| 19:45 | <smaug____> | paul_irish: if you run the innerHTML testfile itself, it ends up testing innerHTML |
| 19:45 | <paul_irish> | yeah |
| 19:45 | <Hixie> | dsheets: it's easy to come up with arbitrary needs, but those aren't use cases |
| 19:45 | <smaug____> | if you use the testharness, it tests something else too |
| 19:45 | <zewt> | dsheets: the question isn't what it is (we get that--modifying relative paths as-is without resolving them), it's why you want to do it |
| 19:45 | <Hixie> | dsheets: use cases are concrete examples of actual problems met by real users |
| 19:45 | <paul_irish> | smaug____: really appreciate you, boris, kyle, others looking at these btw |
| 19:46 | <paul_irish> | yes |
| 19:46 | <smaug____> | paul_irish: anyhow, sounds like the usual problems with tests. Testing something else than one is supposed to test :) |
| 19:46 | <annevk> | dsheets: I have looked into this, and as far as http://platform.html5.org is concerned, only parsing input (maybe combined with a base URL) into a URL is what is visibly exposed |
| 19:46 | <annevk> | dsheets: and actually used |
| 19:47 | <dsheets> | Hixie: I am a real user and I have personally constructed systems to do this for real world use cases. It is useful in conjunction with pushState. |
| 19:47 | <annevk> | dsheets: and although I have found some libraries that do the kind of thing you mentioned just now, I have never seen a request for such functionality before |
| 19:47 | <zewt> | how, concretely, is it useful with pushState? |
| 19:48 | <paul_irish> | smaug____: is the range issue that the gEBId soaking up the time? |
| 19:48 | <zewt> | (i've used pushState extensively; I give it relative URLs, and it pushes a resolved absolute URL) |
| 19:48 | <zewt> | not doubting you, just trying to get closer to what you want to do |
| 19:48 | <Hixie> | dsheets: can you provide me with a URL to such a page? |
| 19:48 | <smaug____> | paul_irish: the range test is actually testing parsing time ( r.createContextualFragment(REPLACEMENT_HTML) ) and inserting something to DOM ( r.insertNode ) |
| 19:49 | <smaug____> | very little about range specific stuff |
| 19:50 | <dsheets> | Hixie: http://ashimagroup.net/~sheets/demo/pano/mars/#?az=1.020944687796126&el=-0.11416091059502942 The same app is served for http://ashimagroup.net/~sheets/demo/pano/mars/msl/nav1/ after partial relative resolution to root the common assets to the domain |
| 19:51 | <Hixie> | can you elaborate on his this works? where do i see the partial resolution? |
| 19:51 | <annevk> | Hixie: btw, on http://url.spec.whatwg.org/ and http://xhr.spec.whatwg.org/ dfn.js does not work |
| 19:51 | <paul_irish> | smaug____: got it. making a ticket. |
| 19:51 | <Hixie> | annevk: any idea why not? |
| 19:52 | <annevk> | actually on xhr it just complaints about some cookie function |
| 19:52 | <annevk> | but on url it fails |
| 19:52 | <Hixie> | annevk: probably missing some other script it relies on |
| 19:52 | <smaug____> | paul_irish: Add rows to ticket seems to test reflow, so looks like the issue 66 |
| 19:52 | <annevk> | Hixie: for url it says "Uncaught TypeError: Object function Object() { [native code] } has no method 'push' " |
| 19:52 | <dsheets> | Hixie: currently it is done at build time |
| 19:53 | <Hixie> | annevk: no idea |
| 19:53 | <zewt> | in other news, onerror in ios 6 safari finally gives useful info, huzzah |
| 19:53 | <annevk> | Hixie: Opera says |
| 19:53 | <zewt> | also usable remote debugging, huzzah^2 |
| 19:53 | <annevk> | Error thrown at line 26, column 10 in <anonymous function>() in http://www.whatwg.org/specs/web-apps/current-work/dfn.js: |
| 19:53 | <annevk> | dfnMap[s].push(links[k]); |
| 19:53 | <Hixie> | dsheets: can you elaborate? (this is exactly the kind of thing that is useful here) |
| 19:53 | <smaug____> | paul_irish: oh, AddRows explicitly wants to flush layout. Then it is testing the thing it tries to test :) |
| 19:53 | <paul_irish> | smaug____: whats your github username |
| 19:54 | <smaug____> | hmm, I did have one... |
| 19:54 | <smaug____> | can't recall |
| 19:54 | <smaug____> | I'll follow robohornet issues |
| 19:55 | <dsheets> | Hixie: elaborate on what? The absolute path is unknown in development. The host is unknown at deploy time. The scheme is unknown at run time. |
| 19:55 | <Hixie> | cabanier: your input on the most recent mail to whatwg would be most helpful (re your blending spec) |
| 19:55 | <Hixie> | dsheets: i'm trying to understand what happens in the build process. |
| 19:55 | <annevk> | Hixie: so if I want that fixed I will have to debug? |
| 19:56 | <Hixie> | annevk: yup :-) |
| 19:56 | <paul_irish> | smaug____: https://github.com/robohornet/robohornet/issues/69 |
| 19:56 | <Hixie> | annevk: or send me mail |
| 19:56 | <Hixie> | annevk: no eta |
| 19:56 | <Hixie> | dsheets: e.g. why can't you just use relative URLs? Why do you have something to partially resolve? |
| 19:56 | <annevk> | yeah okay, I'll look into it some day, might learn a thing or two |
| 19:56 | <Hixie> | dsheets: how do you do it today? |
| 19:57 | <smaug____> | paul_irish: thanks |
| 19:58 | <dsheets> | Hixie: the relative path "panos/MER.jpg" is resolved to "/~sheets/demo/pano/mars/panos/MER.jpg" |
| 19:58 | <Hixie> | dsheets: but why? why not just leave it as panos/MER.jpg ? |
| 19:59 | <dsheets> | Hixie: the same source is served for all subpaths and the display is switched in JS to accomodate pushState |
| 19:59 | <Hixie> | why are there multiple subpaths |
| 20:00 | <Hixie> | sorry if it sounds like i'm being stupid here but this really feels like trying to get blood from a stone |
| 20:00 | <dsheets> | Hixie: I'm sorry you are having a hard time understanding. I will try to explain more clearly. |
| 20:02 | <dsheets> | Hixie: your question is "why are there multiple subpaths in your single-page pushState-using web app?"? Is that accurate? Why not? |
| 20:03 | <Hixie> | dsheets: well specifically, why would your one-page app be exposed using multiple URLs when its resources are only exposed at one URL each |
| 20:03 | <Hixie> | dsheets: what user-problem does this solve? |
| 20:04 | <Hixie> | dsheets: seems like a much simpler solution would be to just have one URL, and then you wouldn't have to resolve any resource URLs |
| 20:04 | <Hixie> | dsheets: in terms of spec problems, we don't solve hypotheticals, but we also don't solve unnecessary problems, hence i'm trying to work out why this is a necessary problem rather than just make-work |
| 20:05 | <dsheets> | Hixie: How do I have one URL for multiple resources? Doesn't pushState allow me to design my URI scheme in a way that keeps distinct resources distinct? |
| 20:05 | <dsheets> | Hixie: your dismissive attitude is unnecessary. |
| 20:07 | <Hixie> | dsheets: ok i'm going for lunch, i'll be back in a few. I recommend writing an e-mail the describes your use case, and why it is important, and sending it to the WHATWG list. I recommend doing so in a manner that actually describes the entirety of the problem and doesn't feel as reluctant to share as this conversation has. |
| 20:07 | <Hixie> | bbiab. |
| 20:08 | <annevk> | dsheets: so is your concern that the specification no longer addresses ../foo resolved against /bar/? |
| 20:09 | <annevk> | dsheets: or do you want an API that resolves ../foo against /bar/? |
| 20:09 | <annevk> | dsheets: there's certainly no such API now, so you must use a workaround of some kind |
| 20:10 | <annevk> | dsheets: in any event, concrete examples would go a long way (unfortunately does require some work) |
| 20:13 | <dsheets> | annevk: I want to be able to parse a URI reference in a JSON object, use the browser API to normalize/canonicalize/whatever it, and re-emit a relative URI reference in a JSON object. If parsing entails resolution into an absolute URI, I have to know which bits of the input URI are present, resolve it against a dummy base and then throw away the bits that come from the dummy base. |
| 20:14 | <annevk> | yeah, you can hack around it like that |
| 20:15 | <dsheets> | annevk: yeah, so that's not so cool because now I can't simply use the API, I have to inspect the string itself and bring my own code to understand which components are present. |
| 20:15 | <annevk> | but that wouldn't give you things like input: http://example.org/test/bar/ and /test/foo -> "../foo" |
| 20:16 | <annevk> | I mean there's all kinds of stuff you could write, but it's kinda nice to know the use cases |
| 20:16 | <dsheets> | annevk: which sort of makes the API (which is already doing this internally) unusable |
| 20:16 | <dsheets> | annevk: that is not he algorithm I am talking about. relativization is significantly more complicated and I do not expect it in the API. |
| 20:18 | <annevk> | okay, so this complaint is about the API, not the way the spec is written? |
| 20:18 | <annevk> | because that wasn't really clear to me |
| 20:19 | <dsheets> | annevk: I want the browser to supply a function that takes "/%65/" and outputs "/e/" or "#%65" and outputs "#e", for example |
| 20:20 | <annevk> | the browser does no such thing now... |
| 20:20 | <annevk> | but you can use encodeURI and decodeURI for that |
| 20:20 | <annevk> | (it does no such thing if you put those in places that take actual URLs) |
| 20:21 | <annevk> | anyway, I need to get some sleep |
| 20:21 | <dsheets> | annevk: doesn't the spec specify the API? If the spec says parsing and relative resolution are always composed and parsing can only occur relative to a base URI, then I can't use its normalization. |
| 20:22 | <annevk> | there's no normalization like %65 -> e |
| 20:22 | <annevk> | %65 stays the same |
| 20:23 | <annevk> | ™ will turn into %E2%84%A2 |
| 20:23 | <annevk> | but %E2%84%A2 will never upon parsing turn into ™ |
| 20:24 | <annevk> | but using JavaScript's encodeURI and decodeURI you can go both ways |
| 20:27 | <dsheets> | annevk: you are correct. Take relative path components, then. Or your trademark example… I have the string "#™" and want to encode/decode this… the "#" is not handled how I would expect by encode/decode. |
| 20:29 | <dsheets> | a = document.createElement("a"); a.href = "../foo"; a.href now stringifies to the absolute URI with relative path components resolved |
| 20:30 | <annevk> | yeah |
| 20:30 | <annevk> | you can get a.pathname if you just want the path |
| 20:31 | <annevk> | there's actually only very little code points affected in the fragment part |
| 20:31 | <annevk> | only some whitespace code points are ignored, that's it |
| 20:31 | <dsheets> | annevk: I want the same components that I passed in, but now normalized. |
| 20:32 | <dsheets> | annevk: ">" in fragment? "]" in fragment? |
| 20:32 | <annevk> | dsheets: stays the same |
| 20:33 | <annevk> | dsheets: even U+0000 although maybe we should drop that just like U+000A |
| 20:33 | <annevk> | dunno |
| 20:33 | <dsheets> | annevk: why aren't they percent encoded in the normal form? NUL seems dangerous. |
| 20:33 | <annevk> | because browsers don't do that |
| 20:34 | <annevk> | and it's not really needed anyway, it doesn't go over the wire |
| 20:34 | <annevk> | (even over the wire it's not strictly needed and IE is known for sending raw utf-8 octets in some cases) |
| 20:35 | <dsheets> | annevk: uhh? how do you mean? are the percent-encoded forms equivalent to the literal forms? |
| 20:36 | <annevk> | well they're "considered" equivalent but they're not if you do e.g. string comparison |
| 20:36 | <annevk> | as many people do |
| 20:38 | <dsheets> | annevk: How do I access a comparison function that returns true for "]" and "%5d"? |
| 20:38 | <annevk> | there's no such thing |
| 20:39 | <dsheets> | why not? aren't they equivalent in URI space? |
| 20:39 | <dsheets> | a.href === b.href returns false |
| 20:39 | <annevk> | there's no URI in user agents |
| 20:40 | <dsheets> | "URLUtils" |
| 20:40 | <annevk> | yeah they'd not be equivalent and you'd get different requests to the server |
| 20:40 | <annevk> | one containing ] and one containing %5d |
| 20:41 | <annevk> | even %5d and %5D result in different requests |
| 20:41 | <annevk> | STD 66 allows for all that btw |
| 20:41 | <annevk> | they don't really place any requirements |
| 20:41 | <annevk> | which is why it's quite useless |
| 20:42 | <dsheets> | yes… so you will not perform any canonicalization or normalization? just parse+resolve and that's it? |
| 20:43 | <annevk> | well there's some |
| 20:44 | <annevk> | see e.g. the bits about percent encoded |
| 20:44 | <annevk> | how \ turns into / most of the time, etc. |
| 20:44 | <annevk> | how http://example.org: turns into http://example.org/ etc. |
| 20:44 | <annevk> | or http://example.org:80 becomes http://example.org/ |
| 20:45 | <annevk> | at some point it will define how http://EXAMPLE/ becomes http://example/ (host names and IP addresses need some more research) |
| 20:45 | <annevk> | schemes are lowercased |
| 20:45 | <annevk> | there's a bunch of stuff |
| 20:45 | <annevk> | (when I think about it) |
| 20:45 | <annevk> | anyway, bedtime |
| 20:46 | tantek | compares http://url.spec.whatwg.org/ to the table in http://tantek.com/2011/238/b1/many-ways-slice-url-name-pieces and wonders if he will need to add another row. |
| 20:47 | <annevk> | ah damn it, hey tantek! |
| 20:47 | <annevk> | tantek: I saw that table and it's pretty awesome |
| 20:48 | <annevk> | tantek: if you have any particular opinion on terms to use it's much appreciated |
| 20:48 | <annevk> | tantek: I'm pretty flexible on that front |
| 20:48 | <annevk> | nn |
| 20:54 | <tantek> | annevk nn - I have no / little particular preference on terms - was more just dismayed at how much a supposedly "simple" thing was reinvented/renamed. We can discuss when you get back online tomorrow morning. |
| 21:20 | <rniwa> | annevk: yt? |
| 21:21 | <Hixie> | tantek: man, if that's not a testament to the URL spec being deficient, i dunno what is :-) nice table |
| 21:22 | <tantek> | Hixie, yeah, this is what happen when I try to re-use existing work and end up documenting a mess instead :( |
| 21:22 | <rniwa> | Who here knows WebIDL? |
| 21:23 | <zewt> | death to "search" |
| 21:23 | <tantek> | also, I have maybe 2 more frameworks/standards that use different terms for URL pieces that I have yet to add to the table |
| 21:23 | <TabAtkins> | rniwa: Several of us, at least kinda? |
| 21:23 | <zewt> | also to "fragment" :( |
| 21:24 | <rniwa> | TabAtkins: so... how do I write a callback interface where callbacks are optional? |
| 21:24 | <rniwa> | TabAtkins: for undo manager's DOMTransaction interface, all properties are optional. |
| 21:24 | <rniwa> | TabAtkins: including callback methods |
| 21:24 | <tantek> | zewt - which is your preferred set of terms for the pieces of a URL? |
| 21:24 | <TabAtkins> | You can make any property optional, including ones that take a callback. |
| 21:24 | <rniwa> | TabAtkins: what's the syntax for that? |
| 21:25 | <zewt> | intuitively, "query" and "hash" (those are the only really "contended" ones) |
| 21:25 | <tantek> | btw - when I add the 2 pending splits, that will make 14 different ways people have come up with for expressing the parts of URLs. The URL spec will then be the 15th, thus fulfilling the prophecy foretold in XKCD 927. |
| 21:26 | <tantek> | so are you a "scheme" guy or a "protocol" guy? |
| 21:26 | <TabAtkins> | rniwa: I'm confused - it's the same as any other optional thing. When you define a callback, it just creates a new type that you can use elsewhere. |
| 21:26 | <TabAtkins> | tantek: I'm more of a "boobs" guy. |
| 21:27 | <zewt> | ("host" vs. "hostname", "path" vs "pathname" are trivial differences; i'd have preferred protocol to scheme, but that one's long gone) |
| 21:27 | <zewt> | TabAtkins: try dieting and exercise |
| 21:28 | <zewt> | *crickets* |
| 21:29 | <zewt> | the "1996 HTTP RFC" row makes me :| |
| 21:29 | <TabAtkins> | Why? |
| 21:30 | <zewt> | because it's five rows, heh |
| 21:30 | <TabAtkins> | jQuery 2011 is 6. ^_^ |
| 21:31 | <Hixie> | "scheme" is the http: part of a URL, "protocol" is what set of rules the scheme maps to (HTTP) |
| 21:31 | <zewt> | interesting that (if I'm reading this table correctly) in every case, the "search" name includes the ? and the "query" name does not |
| 21:31 | <zewt> | a pattern I hadn't noticed |
| 21:32 | tantek | sends TabAtkins to the inclusivity dungeon. |
| 21:32 | <TabAtkins> | tantek: Yeah, I know, bad on me. It was too obvious for me to pass up. :( |
| 21:32 | <tantek> | zewt - that is correct. |
| 21:33 | <zewt> | almost the same pattern for hash/fragment, with a couple misses |
| 21:33 | <tantek> | I built the table for exactly that reason, to see what patterns (if any) would be revealed. |
| 21:33 | <zewt> | (wouldn't necessarily say it's a *useful* distinction, but it's an interesting one) |
| 21:34 | <tantek> | yeah |
| 21:34 | <zewt> | (that is, the pattern--whether you include it or don't include it is certainly important from an API standpoint) |
| 21:37 | <zewt> | Hixie: sure, I just don't think the distinction is necessary in this context (but as far as naming goes this one's been decided--scheme it is!) |
| 21:37 | <Hixie> | othermaciej: yt? |
| 21:37 | <Hixie> | zewt: yeah i dunno if the distinction makes sense either. |
| 21:37 | <Hixie> | zewt: people often refer to the thing, and the identifier for the thing, by the same name |
| 21:37 | <othermaciej> | Hixie: yeah, but I have weinig here in my office so not totally paying attention to IRC |
| 21:38 | <Hixie> | othermaciej: k, just had a quick q RE: the bugs you want cloned back; do you want them reresolved also? Most of them are things I never actually resolved, just punted for a few months, and was planning on reopening (i'll be doing that in january for the whatwg ones) |
| 21:38 | <othermaciej> | Hixie: my preference would be to leave them with their prior resolution, even if it was LATER or REMIND |
| 21:39 | <Hixie> | othermaciej: roger |
| 21:42 | <tantek> | Hixie, zewt, re: scheme vs. protocol, the real question is, does "protocol" include the trailing ":" or not? For a good time, see this github thread discussion that very issue in Node.js: https://github.com/joyent/node/pull/1580 |
| 21:42 | <tantek> | *discussing |
| 21:43 | <Hixie> | i'll let anne worry about that :-) |
| 21:52 | <dsheets> | Hixie: zewt gave you your use case for un-resolved refs |
| 21:53 | <Hixie> | dsheets: anne's the one who needs the use cases |
| 21:53 | <Hixie> | i'm just an interested observer |
| 21:53 | <Hixie> | zewt: btw, HFS+ supports directory hardlinks |
| 21:53 | <zewt> | Hixie: weird |
| 21:53 | <Hixie> | Time Machine uses it to good effect |
| 21:54 | <zewt> | anyway simply discarding hardlink loops seems sane (very rare, and rarer within user data since you need to be root to create them) |
| 21:54 | <Hixie> | you can treat each incremental backup as a full backup |
| 21:54 | <Hixie> | they just hardlink the common bits |
| 21:54 | <zewt> | (i'm assuming hard linked directories work like file hard links, eg. you can detect them by comparing inodes, but I haven't played with it) |
| 21:54 | <Hixie> | yeah i dunno either |
| 21:55 | <dsheets> | Hixie: you were interested enough to inquire about use cases previously going so far as to tell me to draft mail |
| 21:55 | <dsheets> | annevk: zewt gave you your use case for un-resolved refs |
| 21:55 | <zewt> | someone also said that OSX somehow prevents hard links from creating loops (no idea if true or how) |
| 21:55 | <zewt> | (i'm pretty sure I didn't, but feel free to be more specific :) |
| 21:56 | <Hixie> | dsheets: well presumably once anne gets to zewt's e-mail, he will make sure it's handled |
| 21:56 | <Hixie> | dsheets: i was interested in helping you get your use case explained so that anne could make sure it was handled |
| 21:56 | <zewt> | (the case you're probably thinking of is where I want to use the parser for queries for entirely unrelated things--portions of the hash--which isn't what you were talking about) |
| 21:57 | <dsheets> | zewt: it was one of the many things I was talking about |
| 21:58 | <dsheets> | zewt: using only the query part of the parser without a dummy base requires the ability to parse without resolving |
| 21:59 | <Hixie> | anne's asleep now so really if you want to affect the url spec your best bet is e-mail |
| 22:02 | <jamesr_> | othermaciej, with sandboxed local storage area systems in general, is there any way to share resources with multiple origins? maybe with CORS or something? use case is having multiple (say) image editing applications on different domains and wanting to edit the same image offline |
| 22:02 | <othermaciej> | jamesr_: hadn't thought about that as a use case |
| 22:03 | <othermaciej> | jamesr_: if the persistent URL for a file is loadable from any origin, then you could share that way, for reading |
| 22:03 | <othermaciej> | jamesr_: that would require the URL format to have an unguessable unique token for each file |
| 22:03 | <othermaciej> | jamesr_: I do not know what would be a reasonable approach to shared write access |
| 22:04 | <othermaciej> | jamesr_: I could imagine creating shareable storage areas (not per-origin) that have an unguessable unique token identifier which can be shared between webapps |
| 22:04 | <othermaciej> | jamesr_: that would be the "capabilities" approach to it |
| 22:04 | <jamesr_> | would that require explicit cooperation between the webapps? |
| 22:04 | <jamesr_> | or would a user have some way to say "give this guy access to that space" in some fashion? i.e. let gimp.org access my local pictures? |
| 22:05 | <othermaciej> | jamesr_: I could imagine shared storage areas as described having a way to grant access |
| 22:05 | <othermaciej> | jamesr_: I have to go to meetings |
| 22:05 | <othermaciej> | jamesr_: happy to follow up on this on public-webapps |
| 22:05 | <TabAtkins> | Clearly a use-case for Web Intents! |
| 22:05 | <jamesr_> | ok. i'm not very caught up on these discussions |
| 22:05 | <TabAtkins> | /kidding |
| 22:05 | <othermaciej> | I do think the non-shared case can be handled with IndexedDB, from what I can tell currently |
| 22:05 | <othermaciej> | just give IndexedDB a way to vend persistent URLs to a keypath |
| 22:06 | <Hixie> | hmm |
| 22:06 | <othermaciej> | and if you want a more filesystem-like API, that can be layered on top |
| 22:06 | <Hixie> | i wonder if i should reorder the sections in the Sections section |
| 22:06 | <Hixie> | so that <section> comes after <aside> |
| 22:06 | <TabAtkins> | I say yes, purely because I liked that sentence. |
| 22:06 | <Hixie> | or maybe have it body, article, section, nav, aside |
| 22:06 | <Hixie> | heh |
| 22:07 | <TabAtkins> | Your second ordering seems nice. |
| 22:07 | <jamesr_> | you should put that in <maincontent>, right? |
| 22:07 | <Hixie> | that's <body> |
| 22:07 | <Hixie> | tantek: k, will do that one |
| 22:07 | <nessy> | you should put nav ahead of article - it's header-type content |
| 22:08 | nessy | should have slept in |
| 22:08 | <Hixie> | <header> is much later :-) |
| 22:08 | <TabAtkins> | nessy: I think the ordering he suggested was roughly in terms of decreasing inclusiveness. |
| 22:08 | <nessy> | fair enough |
| 22:16 | <JonathanNeal> | hello |
| 22:19 | <TabAtkins> | Yo, JN. |
| 22:58 | <JonathanNeal> | I dig this new DOM stuff making its way into Chrome. |
| 22:58 | <JonathanNeal> | Is anyone maintaining a repo for the polyfills? |
| 23:03 | <TabAtkins> | JonathanNeal: Dunno! |
| 23:03 | <TabAtkins> | Though a snarky answer would be "jQuery". |
| 23:03 | <zewt> | email formatting in mail from BRIAN is making my head hurt |
| 23:03 | <zewt> | er, BRYAN |
| 23:04 | <zewt> | (as someone with a more-often-misspelled-than-not name, i guess I should get at least that right) |
| 23:08 | <TabAtkins> | "and since the Invited Expert route didn't work out" is a good euphemism for "because we were asshats". |
| 23:10 | <gavinc> | Hey, where exactly can I learn more about the URL living standard and the use cases being considered? |
| 23:10 | <TabAtkins> | From annevk, when he's awake. |
| 23:10 | <TabAtkins> | Or from the standard itself, maybe? I haven't read it yet. |
| 23:13 | <gavinc> | well, it seems to be claiming to want to replace RFC 3986 and RFC 3987... and doesn't seem to explain how relative urls work with their base very clearly yet |
| 23:13 | <Hixie> | yeah, it's a work in progress |
| 23:13 | <Hixie> | i expect it will eventually completely define everything those rfcs define |
| 23:13 | <Hixie> | (plus everything they're missing) |
| 23:15 | <gavinc> | ... is starting over REALLY necessary? |
| 23:15 | <Hixie> | no |
| 23:15 | <Hixie> | not even slightly |
| 23:15 | <Hixie> | for years we have been asking for the ietf to fix their rfcs |
| 23:16 | <gavinc> | is there a list of the issues some where? |
| 23:16 | <Hixie> | the url specs don't define error handling |
| 23:16 | <Hixie> | that's the big one |
| 23:17 | <Hixie> | and what they do define doesn't match implementations (e.g. implementations handle javascript: URLs differently than http: URLs, but the RFCs don't really define them differently) |
| 23:17 | <gavinc> | and working with IETF...? |
| 23:17 | <gavinc> | 'cause uh... |
| 23:17 | <zewt> | hahahahahahahahaha |
| 23:17 | <zewt> | sorry :) |
| 23:17 | <Hixie> | the IETF was, how you say, not receptive |
| 23:18 | <Hixie> | nor very responsive |
| 23:19 | <gavinc> | perhaps, but throwing out the whole of both RFCs seems a bit... extreme? |
| 23:22 | <zewt> | from the results i've seen so far of anne's work vs. the legacy specs he's replaced, and if he's willing to do the work, i think it's just fine |
| 23:23 | <Hixie> | gavinc: there's not really that much of value in the RFCs when you get right down to it, to be honest |
| 23:23 | <Hixie> | gavinc: so as zewt says, if anne is willing to do the work... |
| 23:23 | <Hixie> | gavinc: it's very similar to the new HTML spec vs HTML4 |
| 23:24 | <gavinc> | Hixie: I've found Normalization and Comparison from 3987 rather reasonable |
| 23:25 | <Hixie> | gavinc: if there are specific use cases that you want to make sure anne takes into account, i recommend e-mailing him (or the list, or filing a bug) |
| 23:25 | <Hixie> | that section in particular seems to use a lot of words to not say that much :-) |
| 23:26 | <zewt> | Hixie: sounds like just about every pre-HTML5 spec ever written :) |
| 23:26 | <Hixie> | gavinc: i expect anne's canonicalisation algorithm will actually end up doing a way cleaner job of that section, actually |
| 23:26 | <Hixie> | gavinc: but we'll see |
| 23:27 | <gavinc> | zewt: being less dismissive of other peoples work would go a long way |
| 23:28 | <gavinc> | gavin: okay, as a work in progress it's reasonable |
| 23:28 | <gavinc> | got a bit lost just from total change of language |
| 23:28 | <zewt> | i'm dismissive of things that i believe should be dismissed |
| 23:28 | <gavinc> | it seems resolving relative urls, is now hierarchical |
| 23:29 | <gavinc> | and yes, I do in fact agree that the hierarchical section is a great deal easier to understand then the RFC |
| 23:29 | <zewt> | fyi <annevk> maybe I'll rename "hierarchical" to "relative" |
| 23:29 | gavinc | snorts |
| 23:29 | <gavinc> | heh |
| 23:29 | <gavinc> | yeah, that would do it |
| 23:30 | <zewt> | it's quite a freenode day |
| 23:32 | <TabAtkins> | zewt: Yeah, they're maintaining some of the servers that a lot of us connect through. |
| 23:35 | <Hixie> | man, coming up with examples is hard |
| 23:35 | <Hixie> | heycam: you following this Location thread on whatwg? |
| 23:35 | <heycam> | Hixie, I had not been, I'll take a look |
| 23:36 | <Hixie> | thanks |
| 23:58 | <Hixie> | any opinions on http://www.whatwg.org/specs/web-apps/current-work/#usage-summary-0 ? |