| 00:00 | <Hixie> | zewt: yeah. i'm trying to make the default handle the most cases in isolation (e.g. ip addresses alone, floating point numbers alone) |
| 00:01 | <Hixie> | zewt: the hard ones are when two identical sets of strings should sort differently, and that i have no way to solve, obviously |
| 00:01 | <GPHemsley> | it seems to me you might want to have an adaptive algorithm that decides between 1.0 < 1.1 = 1.10 < 1.11 < 1.9 and 1.0 < 1.1 < 1.9 < 1.10 < 1.11 |
| 00:01 | <Hixie> | that's an interesting idea |
| 00:01 | <Hixie> | kind of score the suitability of various algorithms along all the values, and pick the one that scores highest? |
| 00:01 | <GPHemsley> | basically |
| 00:01 | <Hixie> | not sure how i'd tell the difference between those two that you listed if those were the values |
| 00:02 | <GPHemsley> | because 95% of the time, you're be sorting things all of the same type |
| 00:02 | <Hixie> | but hex you could detect |
| 00:02 | <GPHemsley> | well, if those were the only values, do float sort |
| 00:02 | <GPHemsley> | but if there's a 1.0.1 in there, do version sort |
| 00:02 | <Hixie> | this is an interesting idea |
| 00:03 | <GPHemsley> | "<gsnedders> Well, I believe Presto has the most complete impl…" |
| 00:04 | <Hixie> | i think on reflection that changing algorithm is probably too surprising, but it's definitely an interesting idea i hadn't considered |
| 00:04 | Hixie | ponders it further while getting a snack |
| 00:05 | <GPHemsley> | and version sort handles IP addresses, too |
| 00:05 | <GPHemsley> | it's basically the difference between treating the string as a single float or multiple ints separated by a . |
| 00:06 | <GPHemsley> | a possible outcome with this method (if you take it this far) is allowing further algorithm extensions for new types |
| 00:06 | <GPHemsley> | in the future |
| 00:07 | <zewt> | heuristic sorts? sounds really confusing |
| 00:08 | <GPHemsley> | also, you want to make sure that when someone sees the output of a sort, they're not like "why did it sort like this?" |
| 00:08 | <zewt> | better to pick a default and give the author a way to pick a different collation method than be magic and have something that changes out from under you seemingly randomly |
| 00:08 | <GPHemsley> | i.e. no one should have to track Hixie down to find out the justification |
| 00:09 | <GPHemsley> | zewt: Well, it's only the most basic heuristic, I think |
| 00:10 | <GPHemsley> | to be clear, 1.2e3 should never be [1, "2e3"] |
| 00:10 | <zewt> | i mean, i don't think any kind of adaptive sort that picks between "1.10" being [1,10] and [1.1] depending on other values in the list would ever be not weird |
| 00:11 | <GPHemsley> | zewt: In >95% of the cases, you wouldn't even know the difference |
| 00:11 | <zewt> | especially since changing the value in row 10 might cause the sort to "re-adapt", and suddenly the order of rows 1 and 2 switch places |
| 00:12 | <zewt> | being confusing 5% of the time is a lot |
| 00:12 | <GPHemsley> | basically, it'd be [1.1] unless "1.0.1" is encountered |
| 00:12 | <GPHemsley> | if it does change, it'd likely change in a more intuitive direction |
| 00:13 | <GPHemsley> | meaning, if you have a list of version numbers, you wouldn't want them sorted such that 1.1 < 1.11 < 1.9 |
| 00:13 | <zewt> | so if i have rows "1.0", "1.10", "1.2", they'd sort that way, then if i add another row "1.3.4", suddenly rows 1 and 2 switch positions |
| 00:13 | <GPHemsley> | that to me is a good thing |
| 00:13 | <zewt> | if you want 1.10 to sort as [1,10], then you probably *always* want it to do that for that column, not only if there happens to be a 1.3.4 item somewhere else |
| 00:14 | <zewt> | otherwise it'd be wrong when you don't happen to have that 1.3.4 row |
| 00:14 | <GPHemsley> | but the problem is determining between 1.1 = 1.10 and 1.1 < 1.10 |
| 00:15 | <GPHemsley> | in some cases, it'll be the former; in others, the latter |
| 00:15 | <zewt> | right, and you simply can't decide if there doesn't happen to be a 3rd row saying "1.2.3"--when that row isn't there, you'll guess wrong |
| 00:15 | <GPHemsley> | exactly |
| 00:15 | <zewt> | which is why i'm saying adaptive is bad :) |
| 00:15 | <GPHemsley> | but you have to a have default |
| 00:15 | <GPHemsley> | which essentially means you have to "decide" without any information |
| 00:16 | <zewt> | right, i mean the sorting shouldn't be adaptive and it should just pick one |
| 00:16 | <GPHemsley> | then when you get (more) information, you can re-decide |
| 00:16 | <zewt> | if that isn't what you want for a particular case, you use explicit sort keys to get what you want |
| 00:16 | <GPHemsley> | perhaps |
| 00:17 | <GPHemsley> | but how? |
| 00:17 | <zewt> | eg. if you have a release table with a version column, containing versions 1.0, 1.2 and 1.10, and you want them sorted in that order, then you'd provide alternate sort keys (forget the attribute name) containing eg. "1 1", "1 2" and "1 10" |
| 00:17 | <GPHemsley> | oh |
| 00:17 | <GPHemsley> | IDK about that |
| 00:17 | <zewt> | if you provide the alt sort key, it sorts based on that rather than the text of the field |
| 00:17 | <GPHemsley> | that's a lot of extra work |
| 00:18 | <zewt> | not really |
| 00:18 | <GPHemsley> | and that extra work isn't always possible |
| 00:18 | <zewt> | and you're going to need it no matter what you do |
| 00:18 | <GPHemsley> | who is the "you" in this case? |
| 00:18 | <GPHemsley> | the author shouldn't have to specify two values for each cell |
| 00:18 | <zewt> | the browser vendor and the api |
| 00:19 | <zewt> | the author is going to have to, any time he wants a sort order we didn't think of already |
| 00:19 | <zewt> | trying to minimize where it's needed is fine, of course |
| 00:19 | <Hixie> | i'm with zewt on the larger point of the confusion caused by dynamically picking the sort algorithm here being too great, i think. it's an interesting idea though. |
| 00:20 | <GPHemsley> | what I'm saying is, we should give the author the ability to specify which algorithm to use with e.g. an attribute |
| 00:20 | <GPHemsley> | rather than forcing them to specify two values for each cell |
| 00:20 | <GPHemsley> | if you want to avoid that dynamic sorting change |
| 00:20 | <Hixie> | yeah, a feature to pick a specific algorithm is a fine idea |
| 00:20 | <Hixie> | (not one i'd do in v1, but in general) |
| 00:20 | <GPHemsley> | (though I wonder how often you're adding rows and sorting at the same time) |
| 00:21 | <zewt> | i don't mind there being different sort modes (you're going to have to fall back on sort keys at some point, though) |
| 00:22 | <GPHemsley> | Hixie: Any time you do anything but lexical sort, you're gonna wind up with situations where the sorting is wrong, and perhaps in an unexpected way. |
| 00:22 | <GPHemsley> | Hixie: Which suggests to me that you might not want to put it off until v2 |
| 00:22 | <Hixie> | nah, it's definitely not "any time" |
| 00:22 | <GPHemsley> | Hixie: At least not for the issue of how to handle numbers |
| 00:23 | <Hixie> | the only common cases that will fail that i can think of cases where you have version numbers in different styles, or only two-part version numbers. |
| 00:23 | <Hixie> | well, that and hex in certain unlucky cases |
| 00:23 | <zewt> | unexpected isn't catastrophic, unpredictable or hard to understand are much worse |
| 00:23 | <Hixie> | both of which are pretty rare in the cosmic scale of things |
| 00:25 | <GPHemsley> | I am concerned about a situation were the integers in a hex value cause hex values to be sorted non-alphabetically |
| 00:25 | <Hixie> | yeah i wish there was a good way to handle hex |
| 00:26 | <Hixie> | non-base-ten numbers just aren't going to work with what i have so far |
| 00:26 | <GPHemsley> | and I do think it'd be weird to have 1 < 1.10 < 1.9 < 1.10.1 |
| 00:26 | <zewt> | personally i'd prefer to not support 1e10 in favor of hex sorting intuitively, personally i just don't see any value in it |
| 00:26 | <GPHemsley> | I'm inclined to agree |
| 00:26 | <zewt> | it's an easy thing to work around (specify a sort key of the value in decimal) |
| 00:27 | <GPHemsley> | yeah, I think that's an acceptable/appropriate usecase for having 2 values |
| 00:27 | <GPHemsley> | because it's not just a hack that is essentially having the information twice |
| 00:27 | <GPHemsley> | instead, the e notation is a shortcut of the decimal version |
| 00:28 | <zewt> | well, i meant you can specify the hex value in decimal |
| 00:28 | <GPHemsley> | oh |
| 00:28 | <GPHemsley> | that'd be kind of silly for, e.g. a hash |
| 00:28 | <zewt> | if you have 10e500000 (an extreme example) you can't reasonably specify a sort key in decimal |
| 00:29 | <GPHemsley> | true |
| 00:29 | <zewt> | (though iirc in a previous discussion there was a clever workaround for that, don't remember what it was off hand) |
| 00:29 | <GPHemsley> | but I think a hash is more likely than that |
| 00:30 | <GPHemsley> | and a hash isn't commonly considered an integer |
| 00:30 | <GPHemsley> | by which I mean, it'd be unintuitive to represent it as a decimal |
| 00:30 | <zewt> | a hash is just a number, the point of formatting as an integer is simply so it won't be sorted as a float |
| 00:31 | <GPHemsley> | I don't think everyone will see it that way |
| 00:31 | <GPHemsley> | (perception is reality) |
| 00:31 | <zewt> | people can be wrong, i'm not too concerned :) |
| 00:33 | <GPHemsley> | I think the number of people confused by a sort order changing when adding new rows to the table is smaller than the number of people who don't see a hash as an integer |
| 00:33 | <zewt> | i think it's orders of magnitude smaller |
| 00:34 | <zewt> | it's not only confusing, it's wrong |
| 00:34 | <GPHemsley> | "wrong" or not, perception is reality |
| 00:34 | <zewt> | it would actively choose the wrong sort order, then "fix" itself when you add more rows--that's just wrong |
| 00:34 | <zewt> | ... what? |
| 00:34 | <GPHemsley> | oh |
| 00:34 | <GPHemsley> | maybe we're not talking about the same thing? |
| 00:35 | <GPHemsley> | which "it" are you referring to? |
| 00:35 | <zewt> | adaptive sorting would give the wrong sort until you happen to give it a new row that makes it switch |
| 00:36 | <GPHemsley> | it is my understanding that it'd be wrong all the time without the adaptive sorting |
| 00:36 | <zewt> | if i have 1.1 1.2 1.10 2.1.5, and it sorts in that order (because the 2.1.5 kicks it into "version number mode"), if i then remove 2.1.5 it would drop back into "floating-point mode", which isn't (in this example) the sort order i want |
| 00:36 | <zewt> | wrong all the time is much better than being right only if you happen to have "2.1.5" in the list somewhere, then you'll have people going <td hidden>1.1.1.1</td><!-- trick the weird sort --> or something like that |
| 00:37 | <GPHemsley> | I'm not sure I follow you |
| 00:37 | <GPHemsley> | why would they do that? what would be their intention? |
| 00:38 | <zewt> | because if the list happens to not contain 2.1.5, and they still want 1.1 1.2 1.10 ordering, they'd have to somehow get the sort back into that ordering |
| 00:38 | <GPHemsley> | oh, I see |
| 00:39 | <zewt> | if the logic is "sort like a version number if at least one row contains three or more integers separated by periods" |
| 00:39 | <GPHemsley> | right |
| 00:39 | <GPHemsley> | I thought you meant going the other way |
| 00:39 | <GPHemsley> | that's why I was confused |
| 00:39 | <zewt> | it'd be fine to have a sort order attribute somewhere to toggle it explicitly |
| 00:39 | <GPHemsley> | that was my argument |
| 00:41 | <zewt> | (personally i'd be more interested in a natural sort, but that's also something you can mostly do with sort keys, so not too concerned) |
| 00:42 | <zewt> | though it might be that a natural sort and a version sort would turn out to be the same thing (or could, with some effort) |
| 00:42 | <GPHemsley> | I do think it's weird to have "1.0" < "4.4e2e2" < "0.9e1" < "1000" < "10000.0" < "1.1.1" < "1.1.1.1" |
| 00:43 | <zewt> | i think a little weirdness isn't the end of the world, if it does well at a lot of realistic cases, though |
| 00:43 | <Hixie> | clearly '1a' < '1b', and clearly ' 1'<'1'. But should ' 1b' be < or > than '1a'? |
| 00:44 | <Hixie> | i'm thinking > |
| 00:45 | <zewt> | in principle you could say that a number is only parsed as a float if it isn't followed by a period followed by non-whitespace (or something like that), so "Cost: $1.1." is a float but "1.1.A" is not; but not sure in the general case |
| 00:46 | <GPHemsley> | Hixie: '1' < ' 1' < ' 1b' < '1a' < '1b' ? |
| 00:46 | <GPHemsley> | oh no |
| 00:46 | <Hixie> | ' 1'<'1' |
| 00:46 | <GPHemsley> | Hixie: ' 1' < ' 1b' < '1' < '1a' < '1b' ? |
| 00:47 | <Hixie> | you don't think leading spaces should be second class citizens? |
| 00:47 | <GPHemsley> | whatever they are, I think they should be treated equally in all cases, no? |
| 00:48 | <Hixie> | i'm thinking with one number you sort first by the prefix if it's not whitespace, then by the number, then by the suffix, then by the whitespace |
| 00:50 | <GPHemsley> | so you're saying ' 1' < '1' < '1a' < ' 1b' < '1b' ? |
| 00:50 | <Hixie> | yeah |
| 00:50 | <GPHemsley> | hmm, yeah, I guess that works |
| 00:51 | <Hixie> | how about ' 1.00' vs '1.0'? does the space win, or does the sorter string representing the number win? |
| 00:51 | <Hixie> | normally 1.0<1.00 and normally ' 1'<'1' |
| 00:52 | <GPHemsley> | '1.0' < ' 1.00' |
| 00:52 | <GPHemsley> | the space only works as a tie-breaker |
| 00:52 | <Hixie> | so no-WS-prefix, then number, then suffix, then number-as-string, then WS-prefix. |
| 00:52 | <GPHemsley> | 'use case' < 'usecase' |
| 00:52 | <GPHemsley> | (maybe?) |
| 00:53 | <Hixie> | where one of non-WS-prefix and WS-prefix is going to be the empty string |
| 00:54 | <GPHemsley> | so, '3rd' </> '3rd'? |
| 00:54 | <GPHemsley> | ugh |
| 00:54 | <GPHemsley> | so, '3.0rd' </> '3rd'? |
| 00:54 | <Hixie> | > |
| 00:55 | <Hixie> | because 3.0==3, 'rd'=='rd', but '3.0'>'3'. |
| 00:55 | <GPHemsley> | when does number-as-string come into play? |
| 00:55 | <Hixie> | after you've exhausted all other options |
| 00:55 | <GPHemsley> | example? |
| 00:55 | <Hixie> | except meaningless prefix whitespace |
| 00:55 | <Hixie> | the case you gave is a perfect example |
| 00:55 | <GPHemsley> | oh, great |
| 00:55 | <GPHemsley> | so part of my brain understands |
| 00:55 | <Hixie> | hah |
| 00:56 | <Hixie> | i feel like i have made a poor career choice somewhere, for me to have ended up having to make the decisions i'm making today |
| 00:56 | <GPHemsley> | heh |
| 00:56 | <Hixie> | ah well, monday hixie can figure it out |
| 00:56 | <Hixie> | bbl |
| 00:57 | <GPHemsley> | so, '3nd' < '3rd' < '3.0rd' < ' 3nd' < ' 3rd' < ' 3.0rd' |
| 00:57 | <GPHemsley> | or |
| 00:58 | <GPHemsley> | ' 3nd' < '3nd' < ' 3rd' < '3rd' < ' 3.0rd' < '3.0rd' |
| 00:59 | GPHemsley | has no idea |
| 00:59 | <GPHemsley> | my brain hurts |
| 01:17 | <tantek> | GPHemsley, rather than worry about the syntax (for circa dates) let's keep collecting real world examples. syntax-shedding can always come later. that being said, feel free to post such syntax brainstorms in the comments for the proposal so we can at least collect them. |
| 04:44 | <karlcow> | http://www.quickmeme.com/meme/3t0ltf/ |
| 05:15 | <MikeSmith> | haha |
| 05:15 | <MikeSmith> | nice |
| 06:12 | <MikeSmith> | is b2g multi-process? |
| 08:58 | <Ms2ger> | MikeSmith, yes, b2g has multiple processes |
| 08:59 | <MikeSmith> | Ms2ger: for content? |
| 08:59 | <Ms2ger> | At least one parent/one child; I'm not clear on the details |
| 08:59 | <MikeSmith> | ok |
| 09:00 | <MikeSmith> | wondering why that couldn't be reused to provide per-tab processes for Firefox |
| 09:00 | <Ms2ger> | Ah |
| 09:00 | <Ms2ger> | Extensions |
| 09:00 | <MikeSmith> | oh |
| 09:01 | <Ms2ger> | That's one issue, at least |
| 09:01 | <sangwhan> | Is it a process per "application" on B2G? |
| 09:01 | <Ms2ger> | See above :) |
| 09:02 | <sangwhan> | I decipher that as one for the OS UI and one for the applications |
| 09:03 | <othermaciej> | MikeSmith: it's harder to convert an existing browser to multi-process than to do it for a new one |
| 09:03 | sangwhan | has been down the road of HTML powered mobile apps before, we used to call them widgets |
| 09:03 | <othermaciej> | (IMO anyway; I only have direct experience with the latter) |
| 09:03 | <othermaciej> | (er, the former I mean) |
| 09:04 | <MikeSmith> | in other news I'm trying to build Servo but the mozjs part of the build is failing with an "indirect goto might cross protected scopes" that appears to be the exactly the same bug as https://bugzilla.mozilla.org/show_bug.cgi?id=664252 which was resolved=fixed in 2011... :( |
| 09:04 | <MikeSmith> | othermaciej: yeah I can imagine |
| 09:04 | <MikeSmith> | you guys did it for WebKit2 and Safari though, right? |
| 09:05 | <sangwhan> | Making a existing browser sensibly multi-process isn't easy. There are ultra dirty ways to do it though... |
| 09:05 | <MikeSmith> | I guess for Safari you don't have the Extensions problem to deal with |
| 09:05 | <othermaciej> | Safari has extensions |
| 09:06 | <MikeSmith> | oh |
| 09:06 | <othermaciej> | some of our extensions APIs were not designed well for multiprocess |
| 09:06 | <othermaciej> | but there is more of a defined API than for Firefox extensions |
| 09:07 | <MikeSmith> | I guess the other thing is that Firefox extensions seem to be allowed to do just about anything |
| 09:08 | <MikeSmith> | I mean they can get pretty deep down |
| 09:08 | <Ms2ger> | Rather too deep :/ |
| 09:09 | <MikeSmith> | "decisions that seem incredibly clear in the near term… don’t always seem so clear several years later" |
| 09:09 | <MikeSmith> | https://blog.mozilla.org/gen/2013/02/15/john-lillys-thoughts-on-opera-moving-to-webkit/ |
| 09:09 | <MikeSmith> | seems apt |
| 09:12 | <othermaciej> | is this the best reference for mime sniffing? |
| 09:13 | <MikeSmith> | hmm maybe the Servo build is meant to be run with gcc instead of clang? |
| 09:13 | <othermaciej> | yes, Safari's extensions, like Chrome's are more shallow |
| 09:13 | <MikeSmith> | shallow seems prudent |
| 09:28 | <sangwhan> | MikeSmith: You naive person, you default to clang? |
| 09:29 | <Ms2ger> | Spidermonkey should build just fine with clang... |
| 09:32 | <MikeSmith> | filed a Servo bug |
| 09:36 | <sangwhan> | not up to date with www-style, is css3 generated content a dumped spec? |
| 09:38 | sangwhan | found some testcases that depend on the content property to visually display a pass |
| 09:38 | <Ms2ger> | element { content: "foo" }? |
| 09:38 | <Ms2ger> | Nobody supports that |
| 09:40 | <sangwhan> | ...with a exception of Presto. |
| 09:40 | <Ms2ger> | As I said :) |
| 09:42 | <sangwhan> | I don't quite see any negative effects of supporting it though |
| 09:43 | <sangwhan> | ...although being able to do insane stuff like what's defined in css3 generated content doesn't sound fun to implement |
| 09:43 | <Ms2ger> | The usual, lack of engineering recourses and compat issues |
| 11:55 | <Ms2ger> | > document.createElement("image").localName |
| 11:55 | <Ms2ger> | "img" |
| 11:55 | <Ms2ger> | Yay, Chrome. |
| 14:42 | <gsnedders> | No, no, I will not bitch at people talking about asm.js cluelessly. |
| 14:42 | <gsnedders> | PEOPLE, STOP BEING WRONG ON THE INTERNET! |
| 16:28 | <MikeSmith> | slightlyoff: wtf are you talking about with the wpa2 tweet who even knows what wpa2 is |
| 16:33 | <slightlyoff> | MikeSmith: uhhh....some people, I guess? |
| 16:39 | <MikeSmith> | well I understood it but I don't think I count |
| 16:40 | <MikeSmith> | anyway, 140 chars |
| 18:56 | Ms2ger | loves that the CSSWG preprocessor uses ul instead of ol for its tocs |
| 19:00 | <boogyman> | TOCs do not imply a specific order |
| 19:14 | <zewt> | they don't? heh |