| 00:01 | <rillian> | setSet(getSet(jet.set)) |
| 00:26 | <zewt> | gar, photoshop is another one of those things where each update fixes some stuff you really need fixed, while simultaneously breaking a bunch of things in horrible ways, making every upgrade a nightmare |
| 00:28 | <zewt> | cs6 removed the zoom panel, so now I can't find any way to quickly zoom to 50%, which i have to do constantly due to retina stuff |
| 00:47 | <GPHemsley> | zewt: It seems that's how you do things nowadays. |
| 00:48 | <zewt> | indeed |
| 00:48 | <zewt> | gotta introduce new bugs so you can sell n+1 |
| 00:48 | <GPHemsley> | that theory doesn't really work for free software/websites ;) |
| 00:49 | <zewt> | doesn't make it seem any less so for commercial ones :P |
| 00:49 | <GPHemsley> | I think it's more that people forget that you don't need to fix things that ain't broke |
| 00:49 | <zewt> | seriously, i can't figure out how to zoom to 50% in cs6 |
| 00:49 | <GPHemsley> | well, that I can't help you with :P |
| 00:50 | <zewt> | did they really go "nobody needs to do that!" |
| 00:50 | <GPHemsley> | is there a menu option that'll point you to a keyboard shortcut or something? |
| 00:50 | <GPHemsley> | </obvious suggestions> |
| 00:50 | <zewt> | can't even find it in the menu, heh |
| 00:50 | <GPHemsley> | aha! |
| 00:50 | <zewt> | (i'm not really expecting to find a solution in here :) |
| 00:50 | <GPHemsley> | no more zoom! |
| 00:51 | GPHemsley | shrugs |
| 00:51 | <zewt> | (though I suspect there are more than a few people in here whose jobs involve translating PSDs to websites, so perhaps there are at least people here who share my pain) |
| 00:52 | <GPHemsley> | maybe give GIMP a shot? there's a native Mac version now |
| 00:52 | <zewt> | "now you have two problems" |
| 00:52 | <GPHemsley> | heh |
| 00:52 | <GPHemsley> | I have to admit, I'm not a photo editing expert |
| 00:53 | <jsbell> | They ditched the X11 requirement so focus now mostly behaves, but it's still barely a Mac app. :P |
| 00:53 | <zewt> | every time i've tried gimp, it feels very ... 90s |
| 00:53 | <GPHemsley> | it's now early '00s ;) |
| 00:53 | <zewt> | granted it's been several years (even if I learn to use it, the artists giving me assets won't) |
| 00:54 | <GPHemsley> | actually, maybe even late '00s |
| 00:54 | <GPHemsley> | (I forget what year it is sometimes) |
| 00:54 | <zewt> | is it still a mess of separate windows, or do they finally have a usable docking ui? |
| 00:55 | <GPHemsley> | there's even a single-window version! |
| 00:55 | <GPHemsley> | and by "version" I mean, a simple menu click |
| 00:55 | <GPHemsley> | it still has a few kinks, but it's leaps ahead of where it used to be |
| 00:56 | <GPHemsley> | (as in, I can actually stand to use it now) |
| 00:56 | <GPHemsley> | but again, not a photo editing expert |
| 00:59 | <zewt> | i don't do much photo editing, i use ps for ui work |
| 01:02 | <GPHemsley> | s/photo editor/graphic designer/ |
| 01:02 | <GPHemsley> | oh, uh |
| 01:02 | <GPHemsley> | s/photo editing/graphic design/ |
| 01:10 | <zewt> | wonder if webkit optimizes the case of opacity: 0; pointer-events: none; position: absolute; or if it's useful to listen for transitionend and set display: none explicitly |
| 01:10 | <esprehn> | zewt: optimizes how? |
| 01:11 | <zewt> | if i have a lot of them in the same place, eg. blocks of text that i'm fading across, whether it's beneficial to explicitly remove it from rendering or if it figures that out on its own |
| 01:12 | <zewt> | would be easier if there was a :not-animating selector, so i don't have to jump event hoops |
| 01:12 | <zewt> | guess i can just stick a few thousand of them on top of one another and test it |
| 01:14 | <jamesr> | opacity: 0 is magic, but it's not as magic as display:none |
| 01:14 | <jamesr> | (in WebKit) |
| 01:14 | <esprehn> | opacity: 0 is skipped for painting, p-e: none is skipped for hit testing |
| 01:14 | <esprehn> | for some definition of skipped. If you have thousands of these things we still check every one for pointer-events to see if we could have hit it since each one has a layer and we walk the while layer tree |
| 01:14 | <esprehn> | position: absolute doesn't matter |
| 01:15 | <jamesr> | display:none takes them out of the box tree completely |
| 01:15 | <esprehn> | (in this case, since you already have a layer from opacity) |
| 01:15 | <jamesr> | at the cost of having to regenerate them when display goes back to non-none |
| 01:16 | <esprehn> | whole layer tree* |
| 01:23 | <esprehn> | zewt: if you need better perf you should display: none them. we still need to do layout on the opacity: 0 things |
| 01:23 | <esprehn> | I guess we could do it lazily, but no one has taken the time to implement that kind of optimization |
| 01:24 | <zewt> | does that tend to have a nontrivial cost, even when the box isn't changing and has no effect on other content? |
| 01:24 | <esprehn> | not usually |
| 01:24 | <zewt> | i'll probably just need to benchmark it and see if it'll matter (this isn't a huge page, but it does have to run smoothly on mobile) |
| 01:28 | <jamesr> | data >> guesses |
| 01:28 | <zewt> | yep |
| 01:29 | <zewt> | does help to have a picture of what's actually going on, too, of course |
| 02:04 | <miketaylr> | back |
| 02:11 | <miketaylr> | >_< |
| 02:12 | <miketaylr> | (no thanks to my clients spammy auto-back in every channel message....) |
| 02:15 | <zewt> | photoshop also taking a horrifyling google-esque ui turn, with a big list that now has no separating lines to anchor it, making it headachy |
| 07:02 | <annevk> | Hixie: thanks for responding so quickly! |
| 07:04 | <annevk> | Hixie: I take that back, I see you cursed me last night :p |
| 07:30 | <annevk> | Hixie: I |
| 07:30 | <annevk> | Hixie: assuming this is about DOMTokenList, I picked set rather than ordered list, because the items are guaranteed to be unique with the new definitions |
| 08:13 | <MikeSmith> | well well well seems it's official http://my.opera.com/ODIN/blog/300-million-users-and-move-to-webkit |
| 08:19 | <heycam> | well there you go |
| 08:38 | <jamesr_> | heycam: did you see that thread about RAF's WebIDL use? |
| 08:38 | <heycam> | jamesr_, oh yes, sorry I'll get to that |
| 08:38 | <jamesr_> | need to s/something/partial interface/ |
| 08:38 | <jamesr_> | great! thanks |
| 08:47 | <heycam> | jamesr, fixed |
| 08:47 | <MikeSmith> | [[Wium Lie says that it is jumping aboard at the right time, as “the industry moves to make it the de facto Web rendering engine”.]] |
| 08:47 | <jamesr_> | heycam: cool! thanks |
| 08:47 | <MikeSmith> | call an exorcist, that doesn't sound like the Haakon I know |
| 08:48 | <heycam> | how does that quote gel with the "We hope to work with you to further strengthen the open web that we |
| 08:48 | <heycam> | all believe in" quote from the webkit-dev mail |
| 08:48 | <MikeSmith> | heycam: I'm pretty sure Haakon didn't write that message either |
| 08:49 | <MikeSmith> | seriously |
| 08:51 | <jgraham> | MikeSmith: Where is that quote from? |
| 08:51 | <MikeSmith> | hey jgraham |
| 08:51 | <MikeSmith> | from http://thenextweb.com/insider/2013/02/13/opera-300-million-users-webkit/ |
| 08:55 | <MikeSmith> | so I've yet to hear anything about what the plans are for the Presto code. What happens? It just .. disappears? |
| 08:55 | <MikeSmith> | I mean outside of maintenance on it for patche updates to existing products (for security fixes or whatever) |
| 08:56 | <MikeSmith> | it seems like it could be open-sourced, eventually at least |
| 08:56 | <MikeSmith> | and should be |
| 08:58 | <jgraham> | MikeSmith: I believe that Presto won't be open sourced |
| 08:58 | <MikeSmith> | ok |
| 08:58 | <MikeSmith> | that's too bad |
| 08:59 | <sangwhan> | No, condemned folks (read: me) are destined to work on it until nobody else wants it. It won't be open sourced. |
| 08:59 | <sangwhan> | ...as in, Presto. |
| 08:59 | <jgraham> | The reasoning is that doing a big code dump with no documentation or people tasked to work on it isn't helpful to anyone |
| 09:00 | <MikeSmith> | I suppose so |
| 09:01 | <MikeSmith> | god Haavard is nauseating |
| 09:02 | <MikeSmith> | I wish I had some screen to avoid ever seeing his tweets |
| 09:02 | <sangwhan> | MikeSmith: Unfollow him? |
| 09:02 | <MikeSmith> | I don't follow him |
| 09:02 | <doublec> | how are you seeing his tweets? |
| 09:03 | <MikeSmith> | I follow other people whose tweets he replies to, in conversations |
| 09:04 | <doublec> | oh right. need better twitter clients to manage conversions and 'kill files'. |
| 09:04 | <MikeSmith> | I really get the sense that dude would do any kind of 180 switch that might be required by his masters, in order to remain cheerleader #1 |
| 09:05 | <doublec> | I wonder if there are any |
| 09:06 | <sangwhan> | Greasemonkey to the rescue |
| 09:06 | <MikeSmith> | doublec: none that I know of |
| 09:07 | <MikeSmith> | hmm I guess if you block somebody on twitter you never see their tweets |
| 09:12 | <MikeSmith> | anyway I guess he's just doing his job, like the rest of us |
| 09:17 | <roc> | I dunno, he could probably find a job that isn't nauseating. Most of us have that luxury |
| 09:17 | <roc> | whether we choose to exercise it or not |
| 09:26 | <roc> | "Our first patch to WebKit (so for all WK browsers) is to bring CSS multi-col to Presto levels http://bit.ly/14RHGux"; ... and the patch is like half a line. OK that is dumb. |
| 09:35 | <doublec> | It'll suck if their first ever patch ends up with a huge comment discussion and an r- |
| 09:35 | <doublec> | at least a small one is safer in that regard |
| 09:36 | <roc> | I guess so |
| 09:38 | <gsnedders> | And it's probably easier to post something small, eh. |
| 09:42 | <roc> | the tweet drastically oversold it, is all. |
| 09:42 | <darobin> | is the Presto code going anywhere? |
| 09:43 | <roc> | yes, into the void |
| 09:44 | <doublec> | sad. Where's wikileaks for abandoned code when you need it. |
| 09:45 | <Philip`> | Github would probably work well enough for that |
| 09:45 | <darobin> | it would be a crying shame for it to just vanish :( |
| 09:48 | <odinho> | :-) |
| 10:02 | <MikeSmith> | ...and just when I think Haarvard couldn't say anything more obnoxious |
| 10:02 | <MikeSmith> | what a knob |
| 10:03 | <MikeSmith> | and this one somebody I follow retweeted |
| 10:03 | <darobin> | MikeSmith: where? |
| 10:04 | <MikeSmith> | https://twitter.com/opvard/status/301624575882575872 |
| 10:04 | <MikeSmith> | he "predicts" .. Now he's a sage |
| 10:05 | <MikeSmith> | he should write a book, "The Wise Musings of Haavard" |
| 10:08 | <roc> | tweet this back at him: http://robert.ocallahan.org/2013/02/and-then-there-were-three.html |
| 10:10 | <darobin> | what roc said |
| 10:12 | <MikeSmith> | thanks roc |
| 10:12 | <MikeSmith> | https://twitter.com/sideshowbarker/status/301635273291341825 |
| 10:13 | <roc> | thanks |
| 10:20 | <annevk> | MikeSmith: kind of an odd message to come from howcome indeed |
| 10:21 | <annevk> | I never really liked Jon, but in hindsight it's pretty clear that replacing him with a sales guy was the wrong move |
| 10:22 | <roc> | it may well turn out to be the best thing for Opera-the-company |
| 10:24 | <MikeSmith> | roc: maybe so, for what's left of it |
| 10:24 | <MikeSmith> | and I mean that un-bitterly |
| 10:24 | asmodai | grins |
| 10:25 | <MikeSmith> | it's just going to be a different company |
| 10:25 | <MikeSmith> | already has become a different one really |
| 10:26 | <MikeSmith> | what really made everything go to hell was when Thomas Ford left :) |
| 10:26 | <MikeSmith> | that was the sign |
| 10:26 | <asmodai> | So is there agreement that one rendering engine will be beneficial in the long run? ;) |
| 10:26 | <asmodai> | (assuming MS and/or Mozilla would ever switch) |
| 10:27 | <roc> | did you read my post? |
| 10:27 | <asmodai> | roc: No sorry, is it higher up in the chatlog? |
| 10:28 | <roc> | http://robert.ocallahan.org/2013/02/and-then-there-were-three.html |
| 10:28 | <MikeSmith> | annevk: I never really disliked Jon but .. he was a real person and he had his heart in the right place. But I guess that's not what a company wants in a CEO. It wants Steve Jobs. |
| 10:28 | <asmodai> | roc: Fair points. |
| 10:30 | <MikeSmith> | along with roc's post, https://plus.google.com/116237864387312784020/posts/iRRPVaaPQvo from jaffathecake |
| 10:31 | <Stevef_> | roc: thanks for the post makes issues clear for those such as myself who have no idea |
| 10:35 | <asmodai> | MikeSmith: domo |
| 10:36 | <asmodai> | Maybe Opera can show Chrome how to do proper anti-aliased fonts with Webkit :P |
| 10:52 | <MikeSmith> | On the plus side, I guess Opera devs are all gonna get new machines to build on. |
| 10:53 | <MikeSmith> | Because they're going to need them. With more RAM and big(ger) SSDs. |
| 10:53 | <annevk> | MikeSmith: trololol |
| 10:53 | <MikeSmith> | sorry for party rocking |
| 10:56 | <annevk> | This makes Firefox OS harder, makes Windows Phone harder, and worst case will further enshrine WebKit bugs as part of the web platform, complicating projects for new browser engines such as Servo |
| 10:57 | <odinho> | MikeSmith: We did get it. :-) |
| 10:57 | <odinho> | Reeeaaally powerful |
| 10:57 | odinho | happy |
| 10:57 | <MikeSmith> | annevk: yeah |
| 10:59 | <MikeSmith> | odinho: and you can look forward to a year from now you'll probably get a new one that's twice as powerful. Because you'll need it. |
| 10:59 | <MikeSmith> | du --si on my Chromium+WebKit build directory = 26GB. The WebKit part is only 8GB of that, and 1.4GB of other third-party stuff. |
| 10:59 | <MikeSmith> | implied scare quotes around the word /only/ |
| 11:00 | <odinho> | It's no secret that the code bases are very different. :-) |
| 11:00 | <annevk> | Servo is probably the coolest thing right now when it comes to browsers and web platform architecture. |
| 11:00 | <annevk> | At least from the browser projects that are public. |
| 11:01 | <annevk> | odinho: what happens to the Presto code? |
| 11:02 | <MikeSmith> | meanwhile in the tab next door, all of Nightly in my built mozilla-central directory is 4.9GB |
| 11:06 | <MikeSmith> | so does this mean Opera is (eventually) going to be added a new port in the WebKit trunk? |
| 11:12 | <sangwhan> | annevk: Some people will continue to work on it, but it won't be open sourced from what I heard so far |
| 11:12 | <annevk> | sangwhan: ta |
| 11:14 | sangwhan | is not particularly excited about several hour long compile runs |
| 11:16 | <asmodai> | http://www.xkcd.com/303/ <-- appropriate |
| 11:21 | <sangwhan> | https://dl.dropbox.com/u/7479257/Photo%20Feb%2013%2C%2020%2020%2018.jpg <-- way ahead of you |
| 11:22 | <jgraham> | In the days of CVS, someone had printed that out and s/compiling/waiting for locks in DOM/ or somesuch |
| 11:23 | <sangwhan> | and/or tagging/branching |
| 11:24 | <annevk> | slightlyoff: http://dev.w3.org/csswg/css3-fonts/#font-load-events |
| 11:24 | <annevk> | slightlyoff: we need to get Future out there |
| 11:24 | <annevk> | slightlyoff: how is that going to work with TC39? |
| 11:24 | <annevk> | slightlyoff: I can add it to DOM any day, but I'd like to not change it around to much |
| 11:31 | <rniwa> | roc: sadly, webkit is new ie6 :/ |
| 11:31 | <roc> | that's not fair |
| 11:32 | <rniwa> | roc: i know :( |
| 11:32 | <rniwa> | roc: just as we thought we got rid of ie6... |
| 11:32 | <roc> | at least it's open source, and good |
| 11:32 | <rniwa> | roc: yeah, at least you can read the code. |
| 11:32 | <roc> | and contribute. You've got a good community. |
| 11:33 | <rniwa> | roc: right. |
| 11:33 | <rniwa> | roc: but now that webkit is really popular on mobile |
| 11:33 | <roc> | don't be sad. You've got job security :-) |
| 11:33 | <rniwa> | roc: job security is good and i'm excited that webkit is getting more momentum. |
| 11:34 | <rniwa> | roc: but with great market share, comes great responsibility |
| 11:35 | <roc> | indeed |
| 11:36 | <rniwa> | roc: but really, the web has gotten to the point where writing a browser from scratch is not an option. |
| 11:36 | <darobin> | ie6 was good when it came out, too |
| 11:36 | <roc> | it's certainly very difficult, and that is a major problem |
| 11:36 | <rniwa> | roc: yeah. |
| 11:37 | <darobin> | well, this ups the incentive to do it |
| 11:37 | <roc> | darobin: it was good compared to the competition, but it wasn't as close to the standards of its day as we are to ours |
| 11:37 | <rniwa> | roc: even just parsing html properly involves significant undertaking. |
| 11:37 | <darobin> | roc: sure, but to be fair to them the standards of back then were pretty damn hard to implement in that they were largely underspecified |
| 11:38 | <darobin> | I wonder what's the first component you write if you create a new browser |
| 11:38 | <roc> | that didn't help, but they weren't even close to the parts that were specified. |
| 11:38 | <darobin> | I'm not trying to defend ie6 |
| 11:39 | <roc> | JS engine, DOM bindings and a basic DOM I think. Check out Servo :-) |
| 11:39 | <darobin> | just saying that it wouldn't be remembered in infamy if it hadn't stayed around for a decade |
| 11:39 | <darobin> | oh, I was assuming one would have the JS engine |
| 11:39 | <rniwa> | darobin: js engine & parser & DOM |
| 11:39 | <darobin> | yeah, Servo does look cool indeed |
| 11:40 | <darobin> | those parts are (relatively) easy |
| 11:40 | <rniwa> | not too sure if i like the idea of using an entirely new programming language for it though… |
| 11:40 | <darobin> | if I were to write a browser, I'd do it in JS ;-) |
| 11:43 | <wilhelm> | Watching this slow decline to irrelevance has been heartbreaking. There have been so many stupid decisions done by Opera management over the years. This switch is merely the inevitable nail in the coffin. |
| 11:43 | <wilhelm> | You reap what you sow. )c: |
| 11:43 | <wilhelm> | I'm glad I jumped ship when I did. /c: |
| 11:45 | <rniwa> | wilhelm: it's sad because Opera does have top-notch good engineers. |
| 11:46 | <rniwa> | wilhelm: but then running any company, let alone a company that sells browser, is really hard. |
| 11:46 | <wilhelm> | rniwa: Yes. Although the last two rounds of layoffs have more than decimated the team. |
| 11:47 | <wilhelm> | And morale is at rock bottom. |
| 11:48 | <wilhelm> | (I'm just observing this from the outside now.) |
| 11:48 | <MikeSmith> | rniwa: especially when most all of the company's (or organization's...) revenue comes from the browser |
| 11:50 | <MikeSmith> | wilhelm: you make it sound too grim man |
| 11:51 | <wilhelm> | MikeSmith: It is pretty grim. On the positive side - now is a good time to hire great engineers. (c; |
| 11:52 | wilhelm | has done so already. |
| 11:59 | <darobin> | business seems brisk wilhelm :) |
| 12:00 | <wilhelm> | I can't complain. (c: |
| 12:00 | <darobin> | I know several companies who've been looking for good browser engineers for a while, I know they're happy about this |
| 12:04 | <annevk> | So I guess I messed up the setup of GitHub.app this time around. Why are https://github.com/whatwg/url/commit/b4598abb5c83d4f394344ead62fa5200d1158f45 and such not attributed to me? |
| 12:04 | <darobin> | annevk: it says "Anne van Kesteren authored a minute ago" |
| 12:05 | <annevk> | darobin: contrast with https://github.com/whatwg/url/commit/724f4989fef387efeefe7ed0e8d7490b60ea3abf |
| 12:05 | <darobin> | is there another Anne van Kesteren |
| 12:05 | <jgraham> | It looks like you maybe didn't set your emaila ddress |
| 12:05 | <darobin> | ah, interesting |
| 12:06 | <jgraham> | (dunno how you do that in github.app ofc but on the command line it is something like git config global.email) |
| 12:06 | <jgraham> | (that is from memory though and so wrong) |
| 12:06 | <Raymondo> | wilhelm: what should opera have done differently as a company? |
| 12:06 | <darobin> | make money |
| 12:07 | <Raymondo> | darobin: like everyone else? |
| 12:07 | <darobin> | they have a goldmine with Mini that they haven't mined |
| 12:07 | <darobin> | they also had a chance to build up the Opera Platform about 8 years ago |
| 12:08 | <darobin> | they could've been in the OS game, and made huge inroads |
| 12:08 | <annevk> | jgraham: .gitconfig has the right email |
| 12:08 | <darobin> | but they dropped the ball completely and on purpose |
| 12:08 | <darobin> | annevk: was the previous commit from the app as well? |
| 12:08 | <annevk> | darobin: yeah |
| 12:08 | <annevk> | darobin: different laptop though |
| 12:08 | <annevk> | and not restored from backup or anything |
| 12:09 | <darobin> | ah, so maybe different setup |
| 12:09 | <annevk> | I suspect so, just wondering what it is, as GitHub.app does require you to login and all so they bloody well know! |
| 12:10 | <jgraham> | But are the email addresses on the commits right? |
| 12:11 | <jgraham> | I don't really see what it could use other than the author information on the commit |
| 12:11 | <wilhelm> | Raymondo: A lot. A brief summary would be: 1) Focus. 2) Focus. 3) Avoid all the friction that kills productivity. |
| 12:11 | <darobin> | this seems like a bug to me |
| 12:11 | <darobin> | maybe you switch to hg |
| 12:12 | <darobin> | ah — no Ms2ger. Sad. |
| 12:13 | <Raymondo> | wilhelm: interesting that you and darobin seem to be saying opposite things. 'make an os, develop your non-browser proxy service' vs. 'focus (on the desktop browser?)' |
| 12:13 | <darobin> | Raymondo: wilhelm said focus, he didn't say on what |
| 12:13 | <wilhelm> | Raymondo: They are not neccessarily opposites. |
| 12:14 | <darobin> | I agree with him — pick a project, focus on it |
| 12:14 | <darobin> | don't ship stuff like a web server in your browser |
| 12:16 | <wilhelm> | Raymondo: Opera tried to be all things for all people for too long. While we (heh, I still say "we") wasted time on getting the browser engine to compile on the most braindead compilers out there, the competition shipped. |
| 12:16 | <annevk> | jgraham: how do I get the raw commits? |
| 12:16 | <MikeSmith> | well, Opera takes chances, including some nutty ones. That's a big part of what has made it the great thing it is. I hope it keeps taking some crazy chances. |
| 12:17 | <annevk> | I guess I'll try once more |
| 12:17 | <Raymondo> | agreed. opera's leaps weren't always successful but were always interesting and often influencial |
| 12:18 | <Raymondo> | must not talk in past tense |
| 12:18 | <MikeSmith> | Opera was the first browser project to ship a real full browser preinstalled on a mobile phone (here in Japan). At a time when others thought that was just plain not practical to do. |
| 12:19 | <MikeSmith> | And Opera shipped a browser on the original Nintendo DS. Which had the computing power of a sewing machine. 66MHz CPU! |
| 12:20 | <roc> | haha |
| 12:20 | <roc> | blog commenter claims "Opera isn't a big company like Mozilla" |
| 12:20 | <rniwa> | roc: lol. |
| 12:21 | <roc> | (Opera has more employees than Mozilla, FWIW) |
| 12:21 | <wilhelm> | MikeSmith: Yep. I remember shipping a full browser on Qtopia in 2004. It was amazing that thing even worked. |
| 12:21 | <rniwa> | roc: for starters, mozilla isn't a company. |
| 12:21 | <wilhelm> | But it did. |
| 12:21 | <MikeSmith> | roc: you need to count productive employees at Opera. Then the count is closer, I think :) |
| 12:22 | <roc> | don't be so sure :-) |
| 12:22 | <MikeSmith> | touche |
| 12:22 | <rniwa> | so… if you're in the business of making a web browser, where do you compete? |
| 12:22 | <rniwa> | it seems like all web browsers are going to implement every single API ever invented on the web |
| 12:22 | <MikeSmith> | rniwa: user experience |
| 12:22 | <rniwa> | with a flavor of various bugs |
| 12:22 | <MikeSmith> | simple |
| 12:24 | <MikeSmith> | btw I guess Opera did most of the really crazy stuff in the days when Jon was running the show, and I guess for better or worse those days have already been long gone for quite a while now. |
| 12:25 | <wilhelm> | Yes. |
| 12:28 | <smaug____> | rniwa: hopefully not every single API. |
| 12:28 | <smaug____> | need to fight against bad APIs |
| 12:29 | <rniwa> | smaug____: I wanna delete them all. |
| 12:29 | <smaug____> | rniwa: yes, you could start with Filesystem API ;) |
| 12:29 | smaug____ | is trying to kill MutationEvents |
| 12:29 | <rniwa> | smaug____: fwiw, we've deleted web intents |
| 12:29 | <rniwa> | smaug____: and safari has never shipped file system API |
| 12:30 | <rniwa> | smaug____: chrome might be the only browser that ships filesystem api |
| 12:30 | <roc> | that didn't stop Mega from using it :-( |
| 12:31 | <rniwa> | smaug____, roc: http://caniuse.com/filesystem |
| 12:32 | <rniwa> | you might as well as consider it as a proprietary api... |
| 12:33 | <roc> | like I said... |
| 12:33 | <rniwa> | roc, smaug____: didn't Microsoft & Mozilla publicly stated that they won't implement the file system API as is? |
| 12:33 | <smaug____> | random note, don't try to open emscripten created huge .js file in a syntax highlighting editor |
| 12:33 | <smaug____> | rniwa: and Apple and Opera, pretty much |
| 12:34 | <rniwa> | smaug____: yeah. |
| 12:34 | <smaug____> | the old Opera |
| 12:34 | <roc> | oh yeah |
| 12:34 | <roc> | Opera supports Filesystem API now! |
| 12:34 | <rniwa> | smaug____: i don't think opera has to ship file system api even if they used webkit/chromium |
| 12:34 | <roc> | why wouldn't they, though? There's no incentive to diverge |
| 12:35 | <roc> | rniwa: all these things are true, yet Mega used the API anyway and dissed other browsers :-) |
| 12:35 | <roc> | well, until we sent a man around to their office to sort them out |
| 12:35 | <rniwa> | roc: it doesn't really matter though |
| 12:36 | <rniwa> | roc: there will always be some websites that use proprietary apis |
| 12:36 | <rniwa> | it's their choice |
| 12:36 | <doublec> | heh, I wonder if we'll see Opera's entry changed on Mega |
| 12:37 | <roc> | rniwa: it does matter when sites like Mega think other browsers should be implementing those APIs |
| 12:37 | <roc> | note: doublec was that man |
| 12:38 | <rniwa> | roc: is Mega that popular? |
| 12:38 | <roc> | yes |
| 12:38 | <rniwa> | roc: huh, i didn't know that. |
| 12:38 | <roc> | well, it had a spurt of popularity at least |
| 12:38 | <roc> | it's new |
| 12:43 | <doublec> | it's still in the top 200 or so of web sites iirc |
| 12:43 | <doublec> | so it sucks when they say "Use Chrome, other browsers are all outdated" |
| 12:44 | <MikeSmith> | I like the image of doublec being the man you send around to offices to sort people out. It makes hime sounds pretty intimidating. |
| 12:44 | <doublec> | rniwa: technically I'm not sure you'd call their use of the filesystem api proprietary. it was a w3 draft spec, implemented by chrome and there's even an o'reilly book about it. |
| 12:44 | <MikeSmith> | doublec the Enforcer |
| 12:45 | <doublec> | haha |
| 12:45 | <rniwa> | doublec: it seems like Mega lets you select file or drag & drop it? |
| 12:45 | <doublec> | rniwa: yes. You can select directories and it will upload that. |
| 12:45 | <smaug____> | doublec: doesn't matter. It is still google only API |
| 12:46 | <smaug____> | draft spec somewhere in w3 doesn't mean much |
| 12:46 | <doublec> | I don't think it's much different from people that were using Mozilla's audio api to be honest |
| 12:46 | <rniwa> | smaug____: yup. |
| 12:46 | <rniwa> | it's somewhat dubious to claim that API is open & standard just because you've sent it to w3c. |
| 12:46 | <doublec> | they just lost the bet that others would implement the spec |
| 12:47 | <smaug____> | problem is to know whether a draft spec is something everyone agrees (like DOM and such) or just effectively a proposal |
| 12:47 | <doublec> | right |
| 12:47 | <rniwa> | right. |
| 12:47 | <doublec> | that said, the Mega people were very open and friendly and are doing a indexeddb version to replace the filesystem api usage where they can for non-chrome browsres. |
| 12:47 | <rniwa> | also… it could be a proposal if you can modify them to address other vendors' concenrs |
| 12:47 | <rniwa> | |
| 12:48 | <rniwa> | concerns* |
| 12:48 | <doublec> | of course, indexeddb is a working draft too I guess :) |
| 12:49 | <smaug____> | yes, but implemented by everyone |
| 12:51 | <rniwa> | smaug____: and that's a big difference. |
| 12:57 | <MikeSmith> | interesting... David Hasather tweet "The switch to WebKit unfortunately means that Opera Dragonfly is no more." now deleted |
| 12:57 | <MikeSmith> | interesting because he being one who would know |
| 12:57 | <hasather> | MikeSmith: ;) |
| 12:58 | <MikeSmith> | hey man :) |
| 12:58 | <MikeSmith> | so I imagine you got asked (told) to delete that |
| 12:58 | <hasather> | yep |
| 12:58 | <smaug____> | too late ;) |
| 12:58 | <MikeSmith> | yeah I figured |
| 12:59 | <MikeSmith> | sigh |
| 12:59 | <hasather> | :D |
| 13:00 | <MikeSmith> | hasather: they gotta figure it would sorta be obvious, about the future for Dragonfly |
| 13:00 | <MikeSmith> | anyway you did some great work on that |
| 13:00 | <MikeSmith> | glad that part is OSS at least :) |
| 13:00 | <hasather> | MikeSmith: it's pretty tightly coupled to Presto, so yea. And thanks! |
| 13:07 | <MikeSmith> | heh, leave it to Chris: "I will miss the Douglas Crockford of browsers" http://christianheilmann.com/2013/02/13/i-will-miss-the-douglas-crockford-of-browsers/ |
| 13:12 | <jgraham> | annevk: git log on the commandline |
| 13:13 | <MikeSmith> | "Opera was my linting tool" |
| 13:13 | <jgraham> | Your username/email in the earlier commits was annevk <annevk⊙an> and its now Anne van Kesteren <annevk⊙5l> |
| 13:13 | <annevk> | jgraham: brilliant |
| 13:14 | <annevk> | jgraham: so I guess the key setup went less than okay |
| 13:14 | <jgraham> | annevk: Well it should just be the local git config |
| 13:15 | <jgraham> | $ git config --global user.name |
| 13:15 | <jgraham> | and |
| 13:15 | <jgraham> | $ git config --global user.email |
| 13:16 | <annevk> | jgraham: that gives the right results |
| 13:21 | <jgraham> | Cool |
| 13:23 | <annevk> | well no, because the commits go wrong :) |
| 13:23 | <darobin> | annevk: to look at raw commits, you can try git show deadbeef... |
| 13:23 | <annevk> | but I'll try again |
| 13:23 | <darobin> | (I think there's a --pretty=raw option to get it more raw) |
| 13:24 | <darobin> | note that the committer and author can be different, so that might be the source of your weird issue — GH.app has you log in as committer, but you may have a different author |
| 13:25 | <Philip`> | Given that one of the goals of HTML5 was to encourage competition by documenting the platform well enough to let new people build a new browser engine from scratch without it being prohibitively expensive, and now Opera has decided it's prohibitively expensive even though they've already got a mostly-working engine, is that goal anything other than a pointless fantasy? |
| 13:29 | <darobin> | Philip`: I don't know, let's build a browser from scratch and see if it works :) |
| 13:34 | <slightlyoff> | annevk: oy, yeah, that font load thing is pretty terrible |
| 13:40 | <darobin> | fantasai: can you forward your ruby comments to public-i18n-cjk please? |
| 13:44 | <MikeSmith> | Let's do darobin idea about writing a browser engine completely in JavaScript. And then let's use that to build an OS... |
| 13:45 | <darobin> | MikeSmith: that's what I have in mind :) |
| 13:45 | <darobin> | I just need to find someone crazy enough to pay me for it |
| 13:45 | <darobin> | the Inception Engine |
| 13:46 | <MikeSmith> | Jon von Tetzschner has money, and he's crazy too |
| 13:46 | <MikeSmith> | so, perfect combination |
| 13:46 | <darobin> | sounds like a plan |
| 13:46 | <darobin> | I already did ruby: https://github.com/darobin/inception/blob/master/lib/elements/ruby.js |
| 13:46 | <darobin> | so the rest is just a SMOP |
| 13:47 | <darobin> | or we could call it Amaya.JS |
| 13:48 | <darobin> | the EU is always worrying about there being enough competition in the browser space, maybe they could grant us a few millions |
| 13:48 | <MikeSmith> | oh man naming any new Web thing Amaya and having it stick, that'd be fun |
| 13:50 | <MikeSmith> | anyway, I think you're nuts enough to even be working on Servo. And writing stuff in Rust. And even _liking_ to write stuff in Rust. |
| 13:50 | <jgraham> | Javascript is nice, but a browser written in Javascript seems unlikely to be fast enough for anyone to actually use |
| 13:50 | <MikeSmith> | too bad there is only one of you |
| 13:50 | <darobin> | jgraham: that's the kind of pronouncement that people read ten years later when the project is successful and make fun of you for :) |
| 13:52 | <jgraham> | darobin: I'm not feeling very threatend by that :) |
| 13:52 | <MikeSmith> | jgraham: plus it would be be a browser doing garbage collection. which makes about as much sense as writing an OS in a language that has GC instead of requiring old-school memory housekeeping |
| 13:54 | <MikeSmith> | anyway, psd++ for pithiest tweet of the day: https://twitter.com/psd/status/301626612724690944 "Browser wars part 3: The Quickening" |
| 13:56 | <MikeSmith> | slightlyoff: I dig your new ride, man. |
| 13:56 | <slightlyoff> | MikeSmith: hah |
| 14:08 | <MikeSmith> | hey so is Peter Beverloo not going to do his Last Week in WebKit writeups any more? |
| 14:12 | <beverloo> | Lack of time, MikeSmith |
| 14:12 | <beverloo> | I'm hoping to publish something today |
| 14:13 | <MikeSmith> | hey it's beverloo |
| 14:13 | <MikeSmith> | good to hear you're still at it |
| 14:14 | <MikeSmith> | you left an information vacuum there for a while |
| 14:15 | <beverloo> | I'd almost consider saying sorry for being busy :) |
| 14:38 | <annevk> | slightlyoff: from what I hear they consider that API pretty a much done deal |
| 14:38 | <slightlyoff> | annevk: will discuss with Tab |
| 14:38 | <annevk> | slightlyoff: what's still blocking Future atm? |
| 14:39 | <slightlyoff> | annevk: I need to do the polyfill and respond to one of the internal questions about it by one of our TC39 folks |
| 14:39 | <annevk> | k |
| 14:41 | <MikeSmith> | beverloo: wasn't trying to make you feel guilty :) Whatever you been busy on I expect it's probably awesome |
| 15:16 | <annevk> | Philip`: it has helped Safari and is helping Servo |
| 15:16 | <annevk> | Philip`: and helped Opera through numerous rewrites, but yeah, it's not entirely clear |
| 15:24 | <annevk> | GitHub now uses /annevk again, maybe because I changed the login to be my email address... |
| 15:25 | <sangwhan> | I'm going to throw out a pretty silly question here - are political r-(s) common? |
| 15:28 | <Ms2ger> | darobin, yeah, HG fixes everything :) |
| 15:29 | <jgraham> | Can lead to mercurial poisoning though |
| 15:30 | <annevk> | beverloo: do another one of those tweets for WHATWG |
| 15:30 | <annevk> | beverloo: even howcome gets it wrong! |
| 15:31 | <annevk> | sangwhan: hmm? |
| 15:32 | <sangwhan> | annevk: just wondering if crap code is the only way to get a r- |
| 15:32 | <annevk> | sangwhan: well not in line with project goals is another |
| 15:32 | <annevk> | sangwhan: and those are vague of course |
| 15:33 | <annevk> | e.g. Mozilla let some XForms stuff happen for a while, but now most of that is gone |
| 15:33 | <annevk> | don't really know the entire story around that though, just know that it happened |
| 15:33 | <sangwhan> | annevk: Project goals sounds like it has a lot of potential to get political |
| 15:33 | <annevk> | uhuh |
| 15:33 | <Ms2ger> | We used to take pretty much everything, AIUI |
| 15:34 | <Ms2ger> | Remember, we used to support python |
| 15:34 | <annevk> | I didn't :p |
| 15:34 | <jgraham> | I knew that! |
| 15:35 | <sangwhan> | Dunno, I just got this impression by comparing rejects on bugs.webkit.org and bugzilla.mozilla.org |
| 15:35 | <jgraham> | Mark Hammond did it, right? |
| 15:35 | <Ms2ger> | I dunno |
| 15:35 | <Ms2ger> | This was landed in CVS without authorship information, IIRC |
| 15:35 | Ms2ger | had some fun removing that code |
| 15:35 | <sangwhan> | Could be that I'm looking at it subjectively because so far I'm not uber happy |
| 15:36 | <Ms2ger> | Anyway, I guess I should mention Mozilla is hiring :) |
| 15:36 | <Ms2ger> | Hi sangwhan! |
| 15:36 | sangwhan | waves back to Ms2ger |
| 15:36 | <sangwhan> | Especially, the absolute code size of Webkit is overwhelming |
| 15:38 | <Ms2ger> | A lot bigger than Gecko ;) |
| 15:40 | <sangwhan> | No more having the entire source history on my laptop at least :) |
| 15:51 | <annevk> | jgraham: I knew it, but I didn't support it (was my lame joke) |
| 15:52 | <beverloo> | annevk, related: https://twitter.com/littlecalculist/status/301717526465896448 |
| 15:53 | <annevk> | beverloo: oh he is joking |
| 15:53 | <annevk> | beverloo: took me long enough :) |
| 15:53 | <beverloo> | :) |
| 16:51 | <annevk> | "I never understood the implicit assumption that 'open-source' makes monopolies good for you." |
| 16:51 | <annevk> | https://twitter.com/sgalineau/status/301733367324504065 |
| 16:55 | Ms2ger | was surprised to see email about a Bacon API |
| 16:56 | <jgraham> | ?! |
| 16:57 | <Ms2ger> | Turned out to read "Beacon", unfortunately |
| 16:59 | <marcosc> | oh :( |
| 17:00 | <marcosc> | bacon.crispy(); …. mmmm bacon…. |
| 17:01 | <jgraham> | I see it as a good use case for the async API |
| 17:01 | <jgraham> | I mean DOMFuture |
| 17:01 | <jgraham> | Because making good bacon is seriously async |
| 17:02 | <jgraham> | Like, you probably want to start with the part where you get the pig |
| 17:02 | <Hixie> | sigh, a sad day for the web today |
| 17:02 | <jgraham> | and a pig is really a promise that will one day return bacon |
| 17:02 | <Hixie> | annevk: "set" is by definition unordered, imho |
| 17:03 | <marcosc> | jgraham: :) |
| 17:03 | <MikeSmith> | jgraham: solid gold, man :) |
| 17:11 | <jgraham> | annevk: I tend to agree with Hixie fwiw. I think ordered set would be clearer |
| 17:11 | <slightlyoff> | I, for one, am enjoying watching people trip over their poorly-thought-through piles of preferences |
| 17:12 | <slightlyoff> | it's like nobody has ever asked anyone on the web to stack-rank what they want, most to least |
| 17:13 | <annevk> | still waiting for my pet hippo |
| 17:14 | <jgraham> | slightlyoff: huh? |
| 17:14 | <slightlyoff> | jgraham: nevermind. |
| 17:15 | GPHemsley | wonders what the sad-inducer-of-the-day is |
| 17:16 | <Ms2ger> | GPHemsley, Opera |
| 17:16 | <GPHemsley> | ? |
| 17:16 | <Ms2ger> | http://my.opera.com/ODIN/blog/300-million-users-and-move-to-webkit |
| 17:19 | <GPHemsley> | "a browser is much more than just a renderer and a JS engine" barely |
| 17:19 | <miketaylr> | it has a few buttons too |
| 17:19 | <Ms2ger> | Not particularly nice ones, in their case |
| 17:20 | <GPHemsley> | even the buttons are all starting to look the same at this point |
| 17:20 | darobin | read that as the Bacon API too |
| 17:20 | <GPHemsley> | aren't they essentially obsoleting themselves? |
| 17:20 | <GPHemsley> | now there will be zero reason to use Opera |
| 17:20 | <GPHemsley> | just like there is zero reason to use Safari |
| 17:21 | <GPHemsley> | (except by accident) |
| 17:21 | <annevk> | https://o.twimg.com/1/proxy.jpg?t=FQQVBBheaHR0cDovLzI1Lm1lZGlhLnR1bWJsci5jb20vYzMxNDkzY2NjZmJjYzAwNzc3YWYxYTRkYjRjZmYyOTEvdHVtYmxyX21pNjRxcHMxRkgxcnF2eTEybzFfNDAwLmpwZxQCFgASAA&s=CX4Z-zv4t9SbB8nIo-4fXADqLJwsdyun9Xju4GWAP-s |
| 17:21 | <annevk> | beautiful |
| 17:22 | GPHemsley | seems to recall some chatter a few years ago about Firefox doing the same |
| 17:23 | <Ms2ger> | There's always chatter |
| 17:23 | <Ms2ger> | We just have competent CEOs |
| 17:23 | <GPHemsley> | ah |
| 17:23 | <GPHemsley> | so it's back to Firefox vs. the World again, huh? |
| 17:23 | <GPHemsley> | with IE just... there |
| 17:25 | <Ms2ger> | Sounds right |
| 17:25 | <GPHemsley> | or maybe it will be Firefox + IE vs Google |
| 17:25 | <annevk> | Hixie: so we're agreed it's different from a list? |
| 17:25 | <GPHemsley> | that could be fun |
| 17:26 | <annevk> | Hixie: oh the spec calls it an ordered set even |
| 17:26 | <annevk> | Hixie: I guess I could rename the algorithms to also say ordered set |
| 17:26 | <annevk> | Hixie: you're talking about the "set parser" and "set serializer" right? |
| 17:27 | <GPHemsley> | Ms2ger: Oh, interesting. A commenter on that post invoked the rumor as if it were present-day. |
| 17:28 | <annevk> | Yeah, Opera's Asa Dotzler tweeted about it too |
| 17:28 | <GPHemsley> | https://bugzilla.mozilla.org/show_bug.cgi?id=840928 |
| 17:31 | <GPHemsley> | (but then again, Ms2ger already knew about that) |
| 17:33 | <sangwhan> | Can't wait to see what Asa Dotzler is going to write regarding this |
| 17:33 | sangwhan | gets the popcorn bag |
| 17:34 | <Hixie> | annevk: i would not name the variables after their type. You don't call a loop index variable "integer", you call it "index". You don't call a string that contains the user's name "string", you call it "username" |
| 17:34 | <annevk> | oh variables |
| 17:34 | <annevk> | but that's something else |
| 17:34 | <annevk> | where's that? |
| 17:35 | <annevk> | aaah HTMLCollection |
| 17:36 | <Hixie> | yeah, collection |
| 17:36 | <annevk> | Hixie: suggestion? |
| 17:36 | <Hixie> | not "Let set be an empty list" :-) |
| 17:36 | <annevk> | oh you |
| 17:36 | <Hixie> | how about "let elements be an empty list" |
| 17:36 | <Hixie> | or "let result be" |
| 17:37 | <annevk> | that's good, elements would be confusing with element in the next paragraph |
| 17:37 | <annevk> | ty! |
| 17:40 | <tantek> | Hixie, do you have a grammar for HixieScript? (all the pseudocode written in "let … " etc. in the spec(s)) ? |
| 17:40 | <Hixie> | tantek: yeah. http://ian.hixie.ch/bible/english |
| 17:41 | <tantek> | "let" is not found on that page :P |
| 17:42 | <annevk> | when you introduce a variable use let, when you reuse it use set |
| 17:42 | <annevk> | Let x be y. Set x to z. |
| 17:43 | <Hixie> | tantek: it defers to regular english :-) |
| 17:43 | <annevk> | Hixie: not for filename! |
| 17:43 | <Hixie> | yeah i generally try to use "let" when i'm introducing and "set" when i'm changing things |
| 17:43 | <tantek> | HixieScript seems far more constrained than "regular english" and certainly has a particular style/feel to it. |
| 17:43 | <Hixie> | annevk: the actual reason i used "file name" was that there were numerous places where i had things like "name of the file" and so forth |
| 17:43 | <Hixie> | annevk: and "filename of the file" read really weird |
| 17:44 | <Hixie> | tantek: the feel is just because i'm always copy/pasting |
| 17:44 | <annevk> | Hixie: reading through the diff I thought that might have been it |
| 17:44 | <tantek> | and also documenting conventions like: "not name the variables after their type" |
| 17:44 | <Hixie> | "not name the variables after their type" is just good programming practice |
| 17:45 | <tantek> | [citation] |
| 17:45 | <Hixie> | - Hixie, 2013 |
| 17:45 | <annevk> | tantek: feel free to add to http://wiki.whatwg.org/wiki/Howto_spec |
| 17:46 | <annevk> | I try to write my specs somewhat consistently so once you grasp one you get the others, but things change over time... |
| 17:47 | marcosc | wonders [picture of velociraptor] … what's more important: interop or ease of use of APIs? |
| 17:48 | <Ms2ger> | marcosc, WebKit |
| 17:48 | <tantek> | Hixie, I can't put that in a <cite> according to your spec text on <cite> :P |
| 17:49 | <Hixie> | tantek: yup :-) |
| 17:49 | <marcosc> | Ms2ger: correct! :) |
| 17:49 | <annevk> | marcosc: I think the contrast is between ease of use and exposing low enough primitives for the really hard cases |
| 17:51 | <tantek> | thanks annevk - http://wiki.whatwg.org/wiki/Howto_spec#Defining_an_attribute and latter in the page covers a lot of HixieScript - I might create a separate page for it with known constructs as a summary. |
| 17:51 | <marcosc> | sure, but if you were to take a platform wholesale warts and all (e.g., say WebOS) and "standardize it" (i.e., provide specs, tests, and two conforming imps), would that be enough? |
| 17:52 | <Hixie> | tantek: honestly i wouldn't focus too much on the exact constructs we use, it's more the concept of "write prose like you would write code" and "cover every eventuality" that matters |
| 17:52 | <Hixie> | like, my style vs the ecma style, who cares, both are fine |
| 17:52 | <Hixie> | ecma's might even be better |
| 17:53 | <Hixie> | i just don't have the discipline for it |
| 17:53 | <marcosc> | Do developers really case about good API design? Like people still code for iOS in objective-c… and that stuff looks pretty ugly… and java is also extremely successful |
| 17:53 | <marcosc> | but it's also hella ugly |
| 17:53 | <marcosc> | So I'm left wondering, like a velociraptor, should we give a crap about API design? And if so, to what extent? |
| 17:53 | <Ms2ger> | marcosc, two independent implementations? That's what the web is, surely |
| 17:54 | <marcosc> | Ms2ger: well, three now :) |
| 17:54 | <Ms2ger> | On another note, anybody here feel like writing a new browser? |
| 17:55 | marcosc | crickets |
| 17:55 | <Ms2ger> | I promise we won't have any pesky users |
| 17:55 | <Hixie> | marcosc: we need to care about good api design on the web because we've sacrificed so many other things that the other platforms rely on to get where they got |
| 17:55 | marcosc | puts his hand a little way up… then quickly puts it down again before anyone sees |
| 17:55 | <Ms2ger> | Too late |
| 17:55 | <tantek> | Ms2ger, been there, done that. |
| 17:56 | <Ms2ger> | tantek, excellent, I was hoping to recruit you :) |
| 17:56 | <tantek> | Ms2ger, just get MSFT to open source Tasman and we can have some fun. ;) |
| 17:56 | <Ms2ger> | Heh |
| 17:57 | <Ms2ger> | I think I'd prefer Presto at this point, if we're open-sourcing :) |
| 17:57 | <tantek> | Tasman is smaller ;) |
| 17:57 | <Ms2ger> | Exactly :) |
| 17:58 | <tantek> | But yes, Opera should open source Presto regardless. |
| 17:58 | <marcosc> | Hixie: I feel like caring… but I'm looking at the SysApps API stuff and I feel like crying. I don't know if I want to get into a shit fight about those APIs or if it would be better to just let those things be standardized (it's basically the B2G APIs, which feel very rushed). |
| 17:58 | <Ms2ger> | Hah |
| 17:58 | <Hixie> | marcosc: are any other browsers going to implement them? if yes, then you should care. |
| 17:58 | <sangwhan> | tantek: If you put it that way, Dillo is small (but may need a lot of work to bring up to the game) too :) |
| 17:58 | <annevk> | Hixie: is your todo list public these days? |
| 17:58 | <Hixie> | annevk: bugs, e-mail |
| 17:59 | <annevk> | Hixie: also, do update http://wiki.whatwg.org/wiki/Specs_todo ? |
| 17:59 | <Hixie> | annevk: to say what? |
| 17:59 | <annevk> | Hixie: I'm wondering if there's anything more important than Fetch and spec maintenance to be worked on |
| 17:59 | <Hixie> | ah |
| 18:00 | <annevk> | I plan to work on DOMFuture, and spec on(), and fix your DOM event thingie eventually (once I figure out the shadow DOM story), but that's all relatively minor |
| 18:00 | <marcosc> | It would be good to find a home quickly for DOMFuture |
| 18:01 | <annevk> | there's a home: DOM |
| 18:01 | <annevk> | just need to settle on the details |
| 18:01 | <marcosc> | ok, if there is anything I can do |
| 18:01 | <marcosc> | review or whatever, let me know |
| 18:02 | <smaug____> | annevk: fix event thingie? I'd say add something on top of the current stuff |
| 18:02 | <annevk> | review Alex's GitHub page? |
| 18:02 | <marcosc> | I guess that will do for now |
| 18:02 | <annevk> | smaug____: right, that's on(), unless you mean something else? |
| 18:03 | <annevk> | marcosc: my plan is to just write out that design |
| 18:05 | smaug____ | would still like to see how Presto handles cycles between native and JS code |
| 18:05 | <marcosc> | be cool if Opera released their code … for historical reasons or whatever |
| 18:06 | <marcosc> | or just because it would be cool :) |
| 18:07 | <smaug____> | and to possibly learn new ways to implement certain things |
| 18:07 | <marcosc> | yep |
| 18:08 | <TabAtkins> | annevk: What's this about rewriting the URL parser? Are you asking me to or something? |
| 18:09 | <annevk> | TabAtkins: since you said it was so easy for CSS and fantasai called state-machines assembly, I figured I could ask you to take a look at the URL Standard to see if it was possible |
| 18:10 | <annevk> | TabAtkins: given that there's not much tokens I suspect not really, but who knows, maybe we can do better :) |
| 18:11 | <MikeSmith> | annevk: meaning state-machine algorithms in specs? |
| 18:12 | <annevk> | MikeSmith: uhuh |
| 18:15 | <MikeSmith> | well ... that's an interesting way of looking at things I guess |
| 18:16 | <MikeSmith> | though I reckon the she must just mean they're like imperative code |
| 18:17 | <gsnedders> | smaug____: Native code as in the rest of the browser, UI, etc., or as in DOM objects? |
| 18:17 | <jgraham> | gsnedders: DOM objects |
| 18:17 | <gsnedders> | Assume you mean the former. |
| 18:17 | <annevk> | I think my Twitter feed might be an echo chamber. It has a lot of people talking about bad stuff they read elsewhere, but none of that is in my feed. |
| 18:18 | <gsnedders> | jgraham: Was that obvious if I read more context? :) |
| 18:18 | <jgraham> | gsnedders: Well, if by "more context" you mean like "the conversation for like one year ago" |
| 18:18 | <smaug____> | gsnedders: DOM object <-> JS |
| 18:19 | <jgraham> | s/ like// |
| 18:19 | <jgraham> | s/for/from/ |
| 18:19 | <smaug____> | gsnedders: the thing which webkit doesn't really handle at all ;) |
| 18:20 | <gsnedders> | smaug____: Provided we don't end up with a stupid web API because of one impl… :) |
| 18:20 | <jgraham> | smaug____: It's a pity that none of [sof|jl|bratell] are around since they probably actually understand this stuff |
| 18:21 | <gsnedders> | The basic answer is "we don't, really". The long answer is it happens to nicely fall out of how other things work. :) |
| 18:22 | <jgraham> | (I suppose some others do as well, but they also aren't on irc, so that still doesn't help) |
| 18:22 | <gsnedders> | (I have a reasonable idea of how this all works, at least.) |
| 18:23 | <gsnedders> | Anyhow, supper time for me. |
| 18:28 | <MikeSmith> | jgraham: what you mean by jl not being around? you mean just at the moment, today? |
| 18:28 | <gsnedders> | MikeSmith: In #whatwg, I was presuming? |
| 18:29 | <MikeSmith> | ah ok |
| 18:34 | <jgraham> | MikeSmith: Right, we didn't take them out and shoot them or anything |
| 18:34 | <jgraham> | But they aren't really avaliable on any channel where smaug____ can cross-question them :) |
| 18:37 | <MikeSmith> | I see |
| 18:37 | <MikeSmith> | everybody should just be on this channel |
| 18:38 | <smaug____> | :) |
| 18:42 | <jacobolus> | g'morning |
| 18:42 | <gsnedders> | smaug____: The very short detailed answer is marking everything reachable from JS scopes, and let host objects have their own mark-phase callbacks (which can mark more). This means that such cycles aren't a problem, because they're just instantly out-of-scope. However, it makes things like XHR objects hard because they can call a callback which is unreachable from any JS scope. |
| 18:43 | <gsnedders> | And the hacks for XHR and the like are ugly. |
| 18:43 | <smaug____> | gsnedders: ok, so it is about tracing everything? |
| 18:44 | <smaug____> | somewhat similar to Trident, I guess |
| 18:44 | <smaug____> | I mean, effectively use GC for everything |
| 18:44 | <gsnedders> | smaug____: Yeah, indeed |
| 18:45 | <smaug____> | gsnedders: and for cycles within C++ code something manual is used |
| 18:45 | <gsnedders> | smaug____: Relatedly, we still use a very naïve mark/sweep GC. |
| 18:46 | <gsnedders> | smaug____: Yeah. I don't know too much about how except "it's ugly" :) |
| 18:47 | <sangwhan> | gsnedders: It's not _that_ ugly, it "could use improvements". There are uglier bits in Opera. |
| 18:47 | <Ms2ger> | sangwhan, I'd love to see them :) |
| 18:47 | <gsnedders> | sangwhan: I'm just quoting bratell here :) |
| 18:48 | <gsnedders> | sangwhan: And I avoid this stuff enough, yet alone touching the really bad parts. |
| 18:49 | <sangwhan> | gsnedders: Consider yourself lucky :-) |
| 18:49 | <sangwhan> | Ms2ger: Yeah, let's see what Opera management wants to do with Presto in a couple years. |
| 18:49 | <Ms2ger> | Bury it deeper |
| 18:50 | <sangwhan> | Part of me hopes that someone disgruntled employee leaks it, but that probably won't be me |
| 18:51 | <sangwhan> | Would be a shame to see it buried away. Even if every web developer hated Presto, I still have way more love than hate for that code. |
| 18:51 | <Ms2ger> | Probably, excellent |
| 18:53 | <TabAtkins> | annevk: I can take a look, I suppose. |
| 18:54 | Philip` | wonders how the code compares in quality to the original open-sourced Netscape code |
| 18:54 | <jgraham> | My impression is that Presto is like the opposite of Gecko (in some sense) |
| 18:55 | <jgraham> | Most things are implemented in a very minimalist way |
| 18:55 | <jgraham> | (I am totally not a good person to judge of course) |
| 18:56 | <TabAtkins> | annevk: You're already using a state machine for parsing, so I assume you mean you're looking if it can be simplified by running a tokenization step first? |
| 18:57 | <Ms2ger> | jgraham, minimalist? |
| 18:57 | <TabAtkins> | It's possible, though I'd need to understand more of the structure of URLs first. If there are higher-level constructs that you can infer locally, such as "alphanumeric sequence" and "/" and "." or whatever, that would help. |
| 19:44 | <JonathanNeal> | This could have been titled "quirks mode" http://imgs.xkcd.com/comics/workflow.png |
| 19:55 | <annevk> | TabAtkins: yeah, don't think so really |
| 19:55 | <annevk> | TabAtkins: it's highly contextual |
| 19:55 | <annevk> | TabAtkins: maybe if you switch on things like : / \ @ etc. you might be able to get somewhere I suppose |
| 19:56 | <annevk> | TabAtkins: though I guess the other thing is that for URLs a state machine makes a lot of sense so you can implement them as a single-pass |
| 19:56 | <annevk> | TabAtkins: which is good for perf |
| 19:59 | <Hixie> | annevk: updated relative url bug |
| 20:03 | <annevk> | Hixie: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20926#c4 wouldn't navigate (it would just update the URL), but I guess you're right that we should initialize url if input is given hmm |
| 20:03 | <Hixie> | er right, my bad |
| 20:03 | <Hixie> | but yeah, the point is the same |
| 20:04 | <Hixie> | i would have thought the same was true of new URL('...') btw |
| 20:04 | <Hixie> | you could drop .href entirely and the API would still work fine |
| 20:04 | <Hixie> | in principle |
| 20:04 | <Hixie> | (not as specced) |
| 20:07 | <annevk> | Hixie: I guess my thought was that when creating an <a> you'd parse the URL and such |
| 20:07 | <annevk> | Hixie: as is e.g. done for <img> |
| 20:08 | <annevk> | Hixie: and then set the result pieces on the object |
| 20:08 | <Hixie> | well for <img> we have to do something to parse the url because we need to hit the network |
| 20:08 | <Hixie> | for <a> we don't need to do anything unless the API is used |
| 20:08 | <Hixie> | i'd rather not have to copy and paste the same logic for <a> and <area> and everywhere else that does this |
| 20:08 | <Hixie> | would be better for just URLUtils to have all the logic and just to have the minimum number of hooks |
| 20:09 | <Hixie> | which is basically just an algorithm to get the current value, and algorithm to get the current base url, and an algorithm to set the value |
| 20:09 | <Hixie> | note that you can't preparse <a href=""> anyway, since if the base url changes, the output changes too |
| 20:09 | <Hixie> | you have to reparse it each time |
| 20:10 | <annevk> | yeah you're right, new URL doesn't have that particular problem |
| 20:10 | <annevk> | which is prolly why stuff is somewhat broken |
| 20:10 | <annevk> | I'll fix tomorrow |
| 20:18 | <annevk> | The people across the street are making my free WiFi slow :( |
| 20:19 | <Hixie> | so, nobody magically came up with an algorithm for me in https://www.w3.org/Bugs/Public/show_bug.cgi?id=20524 while i was slacking, huh |
| 20:19 | <Hixie> | bummer |
| 20:26 | <TabAtkins> | annevk42: Tokenization steps are usually done inline with the parser anyway (you implement it as a generator that pops out the next token when you ask for it, as the parser runs), so the perf isn't significant. |
| 20:26 | <TabAtkins> | But yeah, I'm thinking URLs are too contextual to benefit from a tokenization pass. |
| 20:33 | marcosc | tries to embroil annevk42 and slightlyoff in a discussion about DOMFuture vs DOMRequest …. wish there was a way to get Ms2ger into the mix :) http://lists.w3.org/Archives/Public/public-sysapps/2013Feb/0048.html |
| 20:34 | <Ms2ger> | Hah, sysapps |
| 20:34 | <zewt> | what a hell is sysapps |
| 20:34 | <marcosc> | zewt: widgets 2.0 :) |
| 20:34 | <marcosc> | http://www.w3.org/2012/sysapps/ |
| 20:35 | <Ms2ger> | B2G |
| 20:35 | <marcosc> | WIDGETS! |
| 20:35 | <marcosc> | :) |
| 20:36 | <zewt> | discussions about that sort of thing should be on webapps or whatwg, doing it on some obscure list guarantees less input |
| 20:36 | <marcosc> | zewt: the discussion is happening there because all the APIs are using the DOMRequest pattern from B2G |
| 20:37 | <marcosc> | And given that SysApps is really a standardization B2G, then it doesn't make sense to have it anywhere else |
| 20:37 | <zewt> | if it's an api with general application, at least (which iirc those may) |
| 20:37 | <zewt> | ... what the heck is b2g? smells buzzwordy |
| 20:37 | <marcosc> | right now, it ain't … but hopefully it will be. |
| 20:37 | <marcosc> | zewt: quit trollin |
| 20:37 | <marcosc> | :) |
| 20:38 | <zewt> | i can't help smelling whag I'm smelling :P |
| 20:38 | <Ms2ger> | Firefox OS |
| 20:38 | <zewt> | also touchscreen typoing |
| 20:39 | <zewt> | two words that never belong aside one another |
| 20:39 | <marcosc> | heh |
| 20:39 | <zewt> | technically three, i suppose |
| 20:45 | <volkmar> | marcosc: I think neither sicking or I want to make sysapps a B2G WG |
| 20:46 | <volkmar> | (argh, I should really change that nickname...) |
| 20:48 | <marcosc> | volkmar: Ms2ger and I were just messing around :) |
| 20:49 | <volkmar> | marcosc: that's all Ms2ger does ;) |
| 20:52 | <volkmar> | marcosc: btw, how does DOMRequest would require things to be wrapped up in functions while DOMFuture wouldn't? |
| 20:53 | <marcosc> | Depends on .then()… if .then() understands that that is means after whatever "you are doing or did" finishes, then it should work. |
| 20:54 | <marcosc> | like: |
| 20:55 | <marcosc> | var promise = something.then(function(){}); setTimeout(function(){doSomething(); promise.then(doSomethingElse)}) |
| 20:56 | <volkmar> | how is that behaviour related to DOMRequest interface? |
| 20:57 | <volkmar> | I mean, that behaviour working or not working |
| 20:57 | <anon> | hi |
| 20:57 | <marcosc> | well, in IDBRequest, you need to do everything in one go: |
| 20:59 | <marcosc> | (function()(var request = indexedDB.open("todos", version); |
| 20:59 | <marcosc> | request.onsuccess = function(e) {…}()} |
| 20:59 | <volkmar> | in IDB, you can do: |
| 20:59 | <volkmar> | var r = idb.open(); |
| 20:59 | <volkmar> | r.onsuccess = function() {}; |
| 20:59 | <volkmar> | but that's just an event handler |
| 20:59 | <volkmar> | that should also exist with DOMFuture |
| 20:59 | <volkmar> | just named accept instead of success |
| 21:00 | <marcosc> | the problem is that you are opening before setting the listener |
| 21:00 | <volkmar> | (according to what slightlyoff told me, .onaccept should work in DOMFuture) |
| 21:00 | <marcosc> | that's counter intuitive. You've started an operation before you set listeners for it |
| 21:01 | <volkmar> | marcosc: that behaviour is because of DOM events |
| 21:01 | <volkmar> | and DOMFuture keeps DOM events |
| 21:01 | <marcosc> | It's not related to DOM events. Consider XHR. |
| 21:01 | <volkmar> | based on that, DOMFuture is simply DOMRequest with renamed attributes and events |
| 21:02 | <marcosc> | XHR is the counter example. You need to explicitly call .send() for anything to happen |
| 21:02 | <volkmar> | (and .then(), .done() and other additions) |
| 21:02 | <volkmar> | marcosc: sure |
| 21:02 | <volkmar> | but DOMFuture works the same way though |
| 21:02 | <marcosc> | so, IndexedDB should not have been requests, they should have been tasks |
| 21:02 | <volkmar> | or I misunderstood you |
| 21:02 | <volkmar> | with DOMFuture you have to do: |
| 21:03 | <marcosc> | volkmar: maybe they do, and then we are going to have the same problem :) |
| 21:03 | <marcosc> | That's why we need lots of people looking at them |
| 21:03 | <volkmar> | doSomethingAsync().done(function() { \o/; }, function() { :(; }); |
| 21:04 | <marcosc> | Sometimes that makes sense… sometimes not. It has to be looked at on a case by case basis |
| 21:04 | <volkmar> | marcosc: the promise idea is that when an action happen, it returns an object telling you that the result of the action will be found there |
| 21:04 | <volkmar> | by design, you can't set listeners before getting that objects |
| 21:04 | <volkmar> | or I'm missing something |
| 21:05 | <marcosc> | no, you are probably right. Butt, like I said, it might not be the right pattern for what we are trying to do. It depends on the use case. |
| 21:05 | <marcosc> | The use case for each API, that is |
| 21:05 | <volkmar> | marcosc: what developers are asking is a promise-like object |
| 21:05 | <marcosc> | We should not just say "DOMFuture ALL THE THINGS!" :) |
| 21:06 | <Ms2ger> | We should not? |
| 21:06 | <volkmar> | I feel like ppl say that already ;) |
| 21:06 | <TabAtkins> | (Those people are right.) |
| 21:06 | <marcosc> | volkmar: no, we should totally resist that |
| 21:06 | <volkmar> | having a promise design is great |
| 21:07 | <volkmar> | promise designed object |
| 21:07 | <volkmar> | anyway... I'm starving |
| 21:07 | <marcosc> | volkmar: we should look at each API and evaluate the best way to do something. If it fits a promise, then yay… if not, then, we use something else. |
| 21:07 | <marcosc> | volkmar: lets chat on the list. But thanks for chatting about this. |
| 21:08 | <volkmar> | marcosc: sure |
| 21:08 | <volkmar> | I will write some emails tomorrow I guess |
| 21:08 | <volkmar> | ttyl |
| 21:18 | <annevk42> | marcosc: yes we should DOMFuture all the things |
| 21:18 | <annevk42> | marcosc: that's the whole point |
| 21:19 | <TabAtkins> | Futures are roughly a superset of events anyway, no? |
| 21:20 | <annevk> | no |
| 21:20 | <annevk> | events are still needed |
| 21:20 | <annevk> | Futures are useful for all yes/no operations |
| 21:21 | <annevk> | async yes/no operations |
| 21:21 | <annevk> | such as geolocation / XHR / <canvas>.getBlob() / ... |
| 21:22 | <nimbu> | MikeSmith: !!!! |
| 21:22 | <nimbu> | do not despair!! |
| 21:22 | <nimbu> | the web is not dead! |
| 21:22 | <nimbu> | there is something to cheer for! |
| 21:27 | <TabAtkins> | nimbu: I dunno what you're talking about, I'm just designing iOS apps now. |
| 21:28 | <nimbu> | :))))))))))))))) |
| 21:28 | <odinho> | At least I'm dead X) |
| 21:28 | <nimbu> | TabAtkins: that would be hilarious. |
| 21:28 | nimbu | slaps odinho |
| 21:29 | odinho | at work 09-22, that's... 13 hours. No wonder I feel bad. |
| 21:29 | <odinho> | So I'll go home now. |
| 21:29 | <nimbu> | :|| |
| 21:29 | <odinho> | nimbu: Thanks, now I'm dead AND got slapped :-O |
| 21:29 | <nimbu> | TabAtkins: you should do a 'what i will be working on for the new year post' which basically lists 10 app ideas for April fool's joke |
| 21:30 | <nimbu> | odinho: yeah the slap was not useful. |
| 21:30 | <odinho> | A little bit maybe :] |
| 21:36 | <MikeSmith> | nimbu: :-) |
| 21:37 | <MikeSmith> | but I'm switching to i0S apps along with TabAtkins |
| 22:45 | <nimbu> | ahahahah MikeSmith |
| 22:45 | <nimbu> | NOOOOOOOOOO |
| 22:46 | <nimbu> | i cannot imagine that future. |
| 23:11 | <Hixie> | ok how does multicol work |
| 23:11 | Hixie | gets out the spec |
| 23:11 | <Hixie> | and does anyone implement this yet? (prefixes don't count) |
| 23:12 | <Hixie> | what i really want is column-width: shrink-wrap |
| 23:12 | <gsnedders> | Well, I believe Presto has the most complete impl… |
| 23:12 | <TabAtkins> | Hixie: That'll be column-width:fit-content when everyone supports that value. |
| 23:13 | <gsnedders> | Hixie: Unprefixed in Presto and Trident, I believe. |
| 23:13 | <Hixie> | TabAtkins: would that actually work? what's the intrinsic size of an element with a variable number of columns? |
| 23:13 | <TabAtkins> | Hixie: We'd have to magic it up when used there. |
| 23:13 | <Hixie> | gsnedders: d'oh |
| 23:13 | <Hixie> | TabAtkins: k, lgtm. make it so. |
| 23:13 | <Hixie> | ok |
| 23:14 | <Hixie> | i have http://software.hixie.ch/utilities/js/sorter/index.html |
| 23:14 | <TabAtkins> | We already do some significant magic with multicol intrinsic sizing. |
| 23:14 | <Hixie> | now to come up with an algorithm |
| 23:14 | <Hixie> | also if anyone sees anything else that i should make sure we support in table sorting autosort, let me know |
| 23:14 | <Hixie> | (see the "input" part of that) |
| 23:15 | <Hixie> | (i think the input is in the order i want) |
| 23:15 | <Hixie> | (so check that too) |
| 23:16 | <TabAtkins> | Hixie: How are the short space-separated things sorting after? space is u+20, well before all the letters and numbers. |
| 23:16 | <Hixie> | in the input? |
| 23:16 | <TabAtkins> | Yes. |
| 23:16 | <Hixie> | the sort order in the input is not perfect |
| 23:16 | <Hixie> | it's locally sorted |
| 23:16 | <TabAtkins> | Oh, okay. |
| 23:16 | <Hixie> | which ones should i fix? |
| 23:16 | <Hixie> | i'd like it to be what we all agree we want |
| 23:17 | <Hixie> | but i don't really know what that is at a global level |
| 23:17 | <TabAtkins> | Wait, I'm confused. So you want the *input* to already be sorted? |
| 23:18 | <Hixie> | i want to know what output i want, and i am at this point putting the input in that order, so that i can then trivially check if my function is working |
| 23:18 | <Hixie> | (i'll run it at least twice, with different permutations of the input) |
| 23:18 | <Hixie> | (including at least the input, and the input reversed) |
| 23:18 | <Hixie> | (to make sure they agree) |
| 23:19 | <Hixie> | that make sense? |
| 23:21 | <TabAtkins> | Yeah. |
| 23:22 | <Hixie> | ok reload, i think the input order is right now |
| 23:25 | <Hixie> | moving IPs around... |
| 23:26 | <Hixie> | ok |
| 23:27 | <Hixie> | so that would give an order of: 1; 1.1.1; 1.1.1.1; 1.1 |
| 23:27 | <Hixie> | (sort by first number, then next number, etc) |
| 23:27 | <TabAtkins> | Huh? That's a weird order. |
| 23:27 | <Hixie> | (so here 1 and 1.0 sort first, then 1.1.1 and 1.1.1.1 sort next because they're sorting on the first number "1", and then 1.1 goes last because it's bigger than 1.0) |
| 23:28 | <Hixie> | yeah, it being weird is why i'm raising it here |
| 23:28 | <Hixie> | not sure how else to do it though |
| 23:28 | <Hixie> | unless we say that if you have a number followed by another, it sorts after infinity |
| 23:28 | <TabAtkins> | Don't split "numbers" on periods? |
| 23:28 | TabAtkins | wasn't aware that we were doing natural sorting of lists of things in the first place. He may have missed the relevant discussion. |
| 23:28 | <Hixie> | so then you'd have 1, 1.1, 2, 1.1.1, 1.1.1.1 |
| 23:28 | <Hixie> | this is for <table><th sorted> |
| 23:29 | <Hixie> | see https://www.w3.org/Bugs/Public/show_bug.cgi?id=20524 |
| 23:29 | <Hixie> | the problem is we need to support IP addresses, version numbers, and regular reals |
| 23:29 | <Hixie> | but we have to define how they sort relative to each other |
| 23:29 | <Hixie> | (they're each easy to do alone) |
| 23:30 | <Hixie> | do we prefer 1, 1.1.1, 1.1.1.1, 1.1, 2; or 1, 1.1, 2, 1.1.1, 1.1.1.1 ? |
| 23:30 | <TabAtkins> | Ah, I wasn't aware of this bug. Okay, that justifies a lot of this. |
| 23:30 | <Hixie> | it's basically the hard bit of the <table sortable> feature that i did a few weeks ago, i had bailed on this one hard part :-) |
| 23:31 | <TabAtkins> | The concept of natural sorting has been done before. Sorting 1.1 and 1.1.1 at the same time, though, is tricky. |
| 23:31 | <Hixie> | hoped someone else would solve it for me, but as usual, my lazyness fails to bear fruit :-P |
| 23:31 | <TabAtkins> | Hmmm |
| 23:31 | <Hixie> | yeah a lot of this is based on stuart's work with sortable.js |
| 23:31 | <Hixie> | unfortunately he bailed on some of these harder questions :-P |
| 23:32 | <Hixie> | i think i prefer 1, 1.1, 2, 1.1.1, 1.1.1.1 |
| 23:32 | <TabAtkins> | Actually, I think it's impossible to always accurately sort both version numbers and reals. |
| 23:32 | <TabAtkins> | Because in version numbers, 1.1 and 1.01 are the same thing. |
| 23:33 | <Hixie> | certainly |
| 23:33 | <TabAtkins> | Okay. |
| 23:33 | <Hixie> | if people are actually mixing these, they're being silly |
| 23:33 | <TabAtkins> | And worse, 1.1 and 1.10 are different versions. |
| 23:33 | <Hixie> | though the v1.01 vs 1.10 thing is hard |
| 23:33 | <TabAtkins> | Yeah, 1.1 vs 1.01 vs. 1.10 = :/ |
| 23:34 | <Hixie> | but it's obvious that 1.0 < 1.01 < 1.1 = 1.10, so, sorry version people |
| 23:34 | <TabAtkins> | It's not even a question of mixing them. It's just that the *way* you sort them are different. |
| 23:34 | <Hixie> | yeah |
| 23:34 | <Hixie> | anyway we solve that by having <data value="1 10">1.10</data> |
| 23:35 | <Hixie> | so that's a separate problem |
| 23:35 | <TabAtkins> | It looks, though, like if you use a separate other than ., or if you include at least three values, that they'll sort correctly as a list of numbers. |
| 23:35 | <Hixie> | yeah |
| 23:35 | <Hixie> | but should "1 1" sort before or after "2"? |
| 23:35 | <TabAtkins> | Okay, well, I'd sort list of numbers after single numbers. |
| 23:36 | <Hixie> | that means you get 1; 2; 1 1; 1 2; 2 1; 2 2 |
| 23:36 | <TabAtkins> | Yes. |
| 23:36 | <Hixie> | seems consistent with what i prefer above for IPs |
| 23:36 | <Hixie> | ok |
| 23:36 | <TabAtkins> | It causes some confusion if you're using . to separate two numbers in a list, but other than that it's very natural. |
| 23:37 | <TabAtkins> | Are you handling this just by splitting the strings into digit/non-digit groups, and sorting them lexicographically? |
| 23:37 | <Hixie> | is "2 2 2" less than or greater than "1 1 1 1"? |
| 23:37 | <Hixie> | i'm not handling this at all so far |
| 23:37 | <Hixie> | so far i just want to know what result i want |
| 23:37 | <TabAtkins> | Lack of something sorts before existence. So less. |
| 23:38 | <TabAtkins> | Oh, but hm. |
| 23:38 | <Hixie> | so 1 2 3; 1 2 4; 1 2 5; 1 2 3 4; 1 2 3 4 5; ? |
| 23:38 | <TabAtkins> | Sorry, greater than. Wasn't thinking. |
| 23:38 | <Hixie> | k |
| 23:38 | <TabAtkins> | The first 2 loses. |
| 23:39 | <TabAtkins> | Sorting is always eager with comparisons. |
| 23:41 | <Hixie> | so we're sorting "one number" before "more than one number", but "2 numbers" and "3 numbers" get sorted based on their numbers |
| 23:41 | <Hixie> | i.e. 1; 9; 1 1; 1 1 1; 1 2 |
| 23:41 | <TabAtkins> | ...yes? |
| 23:41 | <TabAtkins> | Hm. |
| 23:41 | <Hixie> | i think that's right, but it's weird |
| 23:41 | <TabAtkins> | Why are my preferences inconsistent? |
| 23:41 | <Hixie> | hehe |
| 23:41 | <Hixie> | i do think that's the right answer |
| 23:42 | <Hixie> | it's just a bit weird when you mix all these things together |
| 23:42 | <TabAtkins> | I think I can justify it by saying that "one number" and "a list of numbers" are different categories, and we sort categories whole. |
| 23:42 | <Hixie> | and lists can't have just one number :-P |
| 23:42 | <Hixie> | yeah |
| 23:42 | <TabAtkins> | Without an explicit indicator, no, lists cant' have one value. ^_^ |
| 23:43 | <Hixie> | of course this means 0 1; 0 1.1.1; 0 1.1 |
| 23:43 | <TabAtkins> | Why? |
| 23:43 | <Hixie> | because 1.1.1 turns into the same as [0, 1, 1, 1], but 0 1.1 turns into [0, 1.1] |
| 23:43 | <TabAtkins> | I would think that each item in the list is sorted recursively, so |
| 23:43 | <TabAtkins> | Oh... |
| 23:44 | <Hixie> | could do a recursive sort saying it's a list within a list, though |
| 23:44 | <Hixie> | that would be... special to specify :-) |
| 23:44 | <TabAtkins> | Hm, I was thinking of different separators living at different levels, but I don't think I can justify my concept of "separator" without human thought. |
| 23:45 | <TabAtkins> | We could just create a list of separators - " ", "-", ".", ",". |
| 23:45 | <Hixie> | unless you want to be a very busy man, i don't think i can specify that the UA texts you a question each time it wants to compare numbers |
| 23:45 | <TabAtkins> | First one encountered makes it a list, and splits the value. You then type each value recursively. |
| 23:45 | <TabAtkins> | Then sort. |
| 23:46 | <TabAtkins> | I don't think people use different separators in the same list. |
| 23:46 | <Hixie> | so 0 1.1.1 becomes [0, [1, 1, 1]] and 0 1.1 becomes [0, 1.1] ? |
| 23:47 | <Hixie> | i think that is aesthetically pleasing but in reality the resulting complexity wouldn't be justified by the real world applications |
| 23:49 | <TabAtkins> | I'm just thinking of lists of the same type. It seems weird that "1.1 2.0 1.2" sorts correctly (as a list of real numbers), but "1.1.1 2.0.1 1.2.0" doesn't (because it turns into a list of 9 integers). |
| 23:50 | <Hixie> | hm, interesting point |
| 23:50 | <Hixie> | this would only break when sorting lists of variable length lists, right |
| 23:51 | <TabAtkins> | On the other hand, the way I described it would break anyway unless we established a hierarchy among separators. (Which might be justifiable, if we just put . above the others, due to ip addresses and versions.) |
| 23:51 | <TabAtkins> | Hm, maybe. |
| 23:51 | <TabAtkins> | (Well, - should probably be above space and comma too, though perhaps below .) |
| 23:51 | <TabAtkins> | SORTING IS HARD |
| 23:51 | <TabAtkins> | LET'S GO SHOPPING |
| 23:52 | <Hixie> | i admitedly lack imagination sometimes, but i can't think of any cases of lists of variable length lists in sortable tables |
| 23:52 | <Hixie> | so i'm happy to bail on that one :-P |
| 23:54 | <TabAtkins> | True that. |
| 23:54 | <TabAtkins> | Yeah, I guess that as long as the sub-lists are of the same type and length, you can treat it like a big list for sorting. |
| 23:55 | <Hixie> | how should "-2-4-7" sort? |
| 23:56 | <Hixie> | as ["-", 2, 4, 7], or as [-2, 4, 7] ? |
| 23:56 | <TabAtkins> | On the argument that "-2a-4" shoudl sort as [-2, a, -4], I say as [-2, -4, -7]. |
