| 01:31 | <rcombs> | is there a channel about, or relevant to, HTTP/2? |
| 01:36 | <rcombs> | because I'd love to see it include support for range requests for resources of indeterminate size |
| 07:02 | <zcorpan> | annevk: what was the solution to "FATAL ERROR: Functions/methods must end with () in their linking text, got 'dom-MediaList-item'." ? |
| 07:32 | <error08del> | hello |
| 07:32 | <zcorpan> | hello error08del |
| 07:33 | <error08del> | it's quiet here |
| 07:37 | <annevk> | zcorpan: I'm not sure |
| 07:37 | <annevk> | zcorpan: add ()? |
| 07:56 | <zcorpan> | that seems to silence the error at least |
| 07:56 | <zcorpan> | next up FATAL ERROR: No 'idl-name' refs found for 'EmptyString'. |
| 08:03 | <annevk> | zcorpan: I don't really know how bikeshed works though |
| 08:04 | <annevk> | zcorpan: rubys converted the URL Standard to use it, but I haven't really done much updating of that |
| 08:04 | <zcorpan> | ok |
| 08:06 | <darobin> | also I think rubys always uses bleeding edge Bikeshed |
| 08:06 | <annevk> | http://www.cc.gatech.edu/~sakhshab/evoarch-extended.pdf was somewhat interesting, though I didn't really follow the math |
| 08:07 | <zcorpan> | darobin: right now i use https://api.csswg.org/bikeshed/ since i failed to update my local copy |
| 08:07 | <darobin> | zcorpan: ah, yeah, no idea how fresh that one is; I wouldn't be surprised if it were quite far behind |
| 08:08 | <zcorpan> | the docs says it should be kept up-to-date |
| 08:08 | <darobin> | zcorpan: not sure what you mean by "failed to update" though, you can just git clone it and run it from the repo |
| 08:08 | <darobin> | oh, if the docs say it then it must be true! |
| 08:09 | <zcorpan> | i wanted to be able to use `bikeshed` from the command line |
| 08:09 | <darobin> | ln is you friend :) |
| 08:10 | <darobin> | or whatever the python equivalent of "npm link" is, if that exists |
| 08:15 | <zcorpan> | hmm, seems like httparchive data is actually 129236 pages, not ~300,000 pages |
| 09:08 | <annevk> | darobin: Microsoft |
| 09:08 | <darobin> | annevk: you mean like Silverlight |
| 09:08 | <annevk> | darobin: I mean like IE6 |
| 09:08 | <darobin> | if so got that listed, ta |
| 09:09 | <darobin> | I wouldn't call that betting against the Web |
| 09:09 | <darobin> | more like going it alone on the Web :) |
| 09:09 | <annevk> | Not updating it |
| 09:09 | <darobin> | oh that |
| 09:09 | <darobin> | well, would you call it a bet though? more like falling asleep |
| 09:09 | <annevk> | Yes, the bet was on Longhorn / XAML / whatever it was called |
| 09:10 | <darobin> | yeah, I guess that counts, ta |
| 09:10 | <annevk> | I think it's the largest gamble against it so far |
| 09:11 | <darobin> | Mike found this great cwilso_ quote "Two things I never bet against - the web as a platform, and Moore's Law." |
| 09:11 | <darobin> | annevk: well, the people who invested massively in mobile Flash made a big investment too |
| 09:12 | <darobin> | Microsoft may have been the biggest from a single company, but there was a lot of investment from multiple players in mobile Flash |
| 09:12 | <annevk> | Adobe doing Adobe Air |
| 09:13 | <annevk> | sorry, AIR |
| 09:15 | <darobin> | oh yeah! |
| 09:15 | <darobin> | thanks, I'd *completely* forgotten |
| 09:15 | <darobin> | man, AIR |
| 09:15 | <darobin> | that was something |
| 09:16 | <jgraham> | Something almost entirely irrelevant? |
| 09:16 | <darobin> | exactly |
| 09:22 | <annevk> | JavaFX? |
| 09:23 | <annevk> | There's some successful betting too though |
| 09:23 | <annevk> | E.g. the App Store |
| 09:29 | <darobin> | annevk: yeah, we listed Java in general already |
| 09:29 | <darobin> | annevk: this is precisely to be part of an argument against app stores and why you should bet on them :) |
| 09:31 | <annevk> | the web still has some lag compared to native though |
| 09:31 | <annevk> | App Store solved payments, making things work offline, and getting the right performance |
| 09:31 | <annevk> | we still don't really have any of those |
| 09:31 | <darobin> | yes, and it will perhaps always have a lag on the latest cool thing |
| 09:31 | <darobin> | I know |
| 09:44 | <jgraham> | I sometimes wonder if what app stores actually solved was a mindset issue |
| 09:44 | <jgraham> | When people design "a mobile app |
| 09:45 | <jgraham> | " they create something with very simple UI designed to work like other apps on the device |
| 09:45 | <Ms2ger> | Ha: https://mailarchive.ietf.org/arch/msg/ietf-announce/rlIsY8yvvKhbkbkuk2mcQ-ylSNw |
| 09:45 | <jgraham> | When they design a website, even a mobile-targeted one, they somehow fail to do this |
| 09:45 | <jgraham> | Which is suspect means that we aren't giving them the right tools |
| 09:47 | <MikeSmith> | jgraham: interesting point |
| 09:50 | <MikeSmith> | Ms2ger: wow |
| 09:50 | <darobin> | jgraham: are you thinking of something like <link rel="stylesheet native"> that could just pump in a bunch of extra styles to make something look like it's from the system? |
| 09:51 | <darobin> | holy crap |
| 09:52 | <darobin> | well, it only took it 46 years to become a standard |
| 09:52 | <Domenic> | RequestAutocomplete still seems like a good payments solution to me. |
| 09:57 | <annevk> | It's a small step towards one |
| 09:57 | <darobin> | Domenic: it's a good first step for sure, but has anyone implemented it beyond Blink? |
| 09:58 | <darobin> | last I checked it was pretty much not there, but it's been a while |
| 09:58 | <darobin> | looking on the Web doesn't give me much more hope |
| 09:59 | <jgraham> | darobin: Not really :) In theory CSS has a solution for native-"look", albeit one that's broken, but I'm talking more about actual functionality |
| 10:00 | <darobin> | jgraham: yeah, I didn't mean the system colours, just a way of conveying that you want a native look; but I guess you want more |
| 10:03 | <jgraham> | I'm not even sure how much it's a technical problem and how much it's a social problem. I suspect a bit of both. I presume the technical problem is that native platforms provide good tools for building native apps without too much effort, whereas the web is providing good tools for building 90s era forms. Hence you need a much more skilled developer to make a good web-based app than native app. |
| 10:03 | <jgraham> | When the main selling point of the web is "you don't have to build everything twice", that's a problem |
| 10:04 | <darobin> | yes, you have a point |
| 10:04 | <darobin> | just look at the success of Bootstrap |
| 10:05 | <jgraham> | Some social problems are a) if you go out and ask for a mobile app, you inevitably end up getting it done by people who know how to build mobile apps and b) having "an app" is still considered more sophisticated than merely having "a website" so companies want them for PR reasons rather than anything else |
| 10:05 | <darobin> | jgraham: but you'd mentioned "looking like the rest of the platform" — that's a different problem from the fact that HTML forms suck |
| 10:06 | <darobin> | (to put it in a nutshell) |
| 10:06 | <jgraham> | darobin: I guess "and feeling" |
| 10:06 | <jgraham> | i.e. it's not just about having the right CSS, it's about having the right interaction models and "flow" |
| 10:06 | <annevk> | So why is nobody putting effort into HTML forms? |
| 10:07 | <darobin> | yeah, we were wondering the other day about this idea for next generation apps |
| 10:07 | <darobin> | that basically are sold on the app store, but do nothing beyond opening the actual browser |
| 10:07 | <othermaciej> | doing what typical mobile apps do is not mainly a matter of forms, I think |
| 10:07 | <darobin> | yeah, you need a fair bit more than that |
| 10:07 | <darobin> | forms are just one of the components |
| 10:08 | <darobin> | even just scrolling in HTML in nonsensical if you compare it to most platform's scrollable views |
| 10:08 | <darobin> | *platforms' |
| 10:08 | <othermaciej> | we are trying to design more stuff over time to let apps do more mobile-platform-like interactions |
| 10:09 | <darobin> | othermaciej: thinking of a specific example? |
| 10:10 | <othermaciej> | Dean’s animation trigger thing, which synergizes nicely with CSS snap points (which we did not design, but which we like) |
| 10:10 | <othermaciej> | pretty much everyone trying to do page swipes on the web with pure JS and existing events is doing a terrible job |
| 10:11 | <darobin> | annevk: re forms specifically, I think we're seeing a combination of the fact that a lot of people think the newer types often suck and of web components/extensible web promising that people would just build their own things |
| 10:11 | <jgraham> | annevk: It has become very unfashionable to add higher-level primitives to browsers. I guess the perception is that eventually the lower level primitives will allow authors to solve these problems themselves. But of course it will still lead to a situation where authors keep reinventing the wheel and all websites have slightly different feels |
| 10:11 | <darobin> | yeah, and doing a terrible job for a reason: it's stupidly hard :) |
| 10:11 | <othermaciej> | very few apps on my phone are at all well described as a form |
| 10:12 | <darobin> | othermaciej: I think forms surfaced here because they tend to be particularly painful on mobile; not as a model of everything to be done in an app |
| 10:12 | <othermaciej> | the closest I can think of is Settings, and none of the control or layout styles it uses are represented in html forms |
| 10:12 | <darobin> | Evernote is, like, a big form :) |
| 10:12 | <othermaciej> | they tend to be painful on mobile because good mobile app design isn’t form-like, so you shouldn’t use forms |
| 10:13 | <jgraham> | othermaciej: No, but one can imagine adding higher-level features directly in browsers in the same way that forms are directly implemented |
| 10:13 | <othermaciej> | I don’t use evernote so I would’t know,but I believe you |
| 10:13 | <darobin> | yeah |
| 10:13 | <othermaciej> | right, the problem is the higher-level features start getting pretty platform-specific |
| 10:14 | <darobin> | the set of high-level features that aren't impossible to expose well to styling is small, but I believe it exists |
| 10:14 | <othermaciej> | the problem isn’t platform-specific look, it’s platform-specific behavior |
| 10:14 | <jgraham> | Yeah, but there are two choices really. 1) you add the higher level features to the browser, which then doesn't match the available featureset on many platforms 2) you allow authors to design the high level features, which still don't work like the specific features on any platforms |
| 10:15 | <othermaciej> | one tricky thing about, for example, doing the animation for paged swipe is that Android and iOS use different animation curves in the place where they do it natively |
| 10:15 | <darobin> | why do I get the impression I've had this conversation continuously since the late 90s? |
| 10:15 | <darobin> | oh, yeah, I know why :) |
| 10:16 | <othermaciej> | so either you build a feature that encapsulates all that, or you give people primitives and they match one platform if they are really good, and match zero platforms if they are not (which is most of the time) |
| 10:16 | <othermaciej> | this is part of why I don’t fully buy into the “expose the primitives” theory of web platform design |
| 10:16 | <darobin> | othermaciej: I suspect that if the swipe speed curve were left up to implementations, it might actually be okay |
| 10:16 | <annevk> | jgraham: we have failed in decoupling forms though to make it easier to adjust them or create them from scratch |
| 10:16 | <othermaciej> | it’s nearly impossible to abstract platform differences if all you provide is low-level primitives |
| 10:17 | <darobin> | for reference, see Flash |
| 10:17 | <annevk> | jgraham: no standards group spending critical thinking time on them does not really help either |
| 10:17 | <othermaciej> | and what people build ends up not matching the platform, so it feels second-class, so people keep wanting to build native apps |
| 10:17 | <jgraham> | annevk: Yes. The built-in stuff fails at being adjustable. |
| 10:17 | <darobin> | Flash actually exposed quite a lot of primitives that made it possible to make it look wrong on every platform |
| 10:18 | <othermaciej> | Flash helped you fail to match the platform, and also fail to match what any other webpage looked or acted like |
| 10:18 | <othermaciej> | somehow it even helped you make your Flash app look and act differently from all other Flash apps |
| 10:19 | <othermaciej> | so that was taking it to a whole new level |
| 10:19 | <darobin> | actually there are people here and there thinking about these problems, even hashing out early solutions — not sure where they'll take the stuff but I reckon it'll hit an organisation near you soon enough |
| 10:19 | <darobin> | othermaciej: well, Java awt made it possible to make your applet look exactly like every other applet and I'm not sure that was necessarily great |
| 10:19 | <jgraham> | There is a rich history of toolkits that managed to look wrong on every environment. Usually their shortcomings were hidden by the fact that Windows applications all looked different from each other anyway |
| 10:20 | <annevk> | darobin: I feel like I need an accountability board for your predictions |
| 10:20 | <darobin> | have I *ever* been wrong? |
| 10:20 | <annevk> | see, if I had that board I would know |
| 10:20 | <darobin> | lol |
| 10:20 | <othermaciej> | I do find myself curious how different the Android and iOS apps are for popular services where they have both and actually tried to make both of them good |
| 10:21 | <darobin> | annevk: well, you never know, we might know one another for a few more decades so you could get one such board started now; could come in handy |
| 10:21 | <darobin> | othermaciej: to the best of my knowledge they just write them twice |
| 10:21 | <darobin> | at least, that's what Facebook did |
| 10:21 | <jgraham> | Anyway, I don't really know how to fix this stuff unless Firefox OS (or some other platform using web apis to construct the UI) actually wins. And there are some quite big players working to prevent that happening. |
| 10:22 | <darobin> | I'm pretty sure it's what Evernote did too since they adopted Material Design super early on |
| 10:22 | <othermaciej> | darobin: I mean different in appearance, design and observable behavior, not how different they are in code |
| 10:22 | <othermaciej> | (though there are some apps that try to share a cross-platform core engine with ObjC or Java GUI on top as appropriate) |
| 10:23 | <darobin> | othermaciej: that's probably less of the case for FB, but I'd be shocked if Evernote iOS looked like the Android version. |
| 10:23 | <othermaciej> | a lot of iOS apps look like they could almost be a webpage, but if you go to their website, even when it’s a mobile-specific site, it’s not even trying to be similar to the app |
| 10:24 | <othermaciej> | like Yelp’s mobile site compared to their app looks surprisingly ugly, and I can’t think of any good reason it needs such a crutfy layout |
| 10:25 | <darobin> | I suspect that poor application of responsive design might have something to do with that |
| 10:25 | <darobin> | yeah, Evernote iOS https://encrypted.google.com/search?tbm=isch&q=evernote%20ios&tbs=imgo:1 seems to be quite different from Evernote Android https://encrypted.google.com/search?tbm=isch&q=evernote%20android&tbs=imgo:1#safe=off&tbs=imgo:1&tbm=isch&q=evernote+material+design |
| 10:25 | <othermaciej> | except I guess maybe trying hard to be platform-agnostic |
| 12:13 | <zcorpan> | http://www.w3.org/mid/CAN9ydbXtc5oToTTMBZ-f9PigXAoo04KTgn1LfUMTLL6938f5_A⊙mgc reminds me of when rubys started chairing htmlwg |
| 12:16 | <Ms2ger> | Imma let you finish, but please let me declare consensus? |
| 12:47 | <hemanth> | what's wrong with class Person { sayHi = () => "Hello!"; } ? |
| 12:49 | <hemanth> | class Person { sayHi(){ "Hello!"; } }; works fine, i understand that lexical binding would be by default in class, but arrow function are still useful, no? |
| 12:50 | <hemanth> | annevk, around :) ^^ |
| 12:51 | <hemanth> | `new` conflicts with that? |
| 13:07 | <annevk> | hemanth: dunno, ask Domenic |
| 13:08 | <hemanth> | Domenic, help :) |
| 13:09 | <hemanth> | AFAIK, new on a arrow function will throw an error "is not a constructor" and it doesn't have a prototype, so I guess it can't be used with class... |
| 13:11 | <annevk> | hemanth: did you try using 6to5 or some such? |
| 13:13 | <hemanth> | Unexpected token |
| 13:13 | <hemanth> | yup, I tired. |
| 13:17 | <hemanth> | annevk, related issue https://github.com/facebook/react/issues/2972 ;) |
| 13:32 | <hemanth> | and in 6to5 https://github.com/6to5/6to5/issues/616 |
| 13:40 | <caitp-> | i'm not sure you can really polyfill that behaviour |
| 13:46 | <hemanth> | caitp-, looks like, even traceur https://github.com/google/traceur-compiler/issues/1664 |
| 13:46 | <hemanth> | caitp-, can you spot the not? https://github.com/facebook/react/issues/2972 |
| 13:47 | <caitp-> | spot the not? |
| 13:48 | <hemanth> | AFAIK, new on a arrow function will throw an error "is not a constructor" and it doesn't have a prototype, so I guess it can't be used with class... |
| 13:49 | <caitp-> | the error you have is an early error, and if it's anything like ES2015 classes, it's probably because of the `property = value` stuff going on |
| 13:49 | <caitp-> | not too familiar with jsx |
| 13:51 | <hemanth> | hmm, ok. (`property = value` looks like it..) |
| 17:00 | <Domenic> | hemanth: you can't use = inside class declarations. |
| 18:02 | <TabAtkins> | darobin: The API version of Bikeshed is always up-to-date, via github commit hooks. |
| 19:31 | <Domenic> | as someone put it (dherman I think?), "living spec tool for your living standards" |
| 19:32 | <Ms2ger> | TabAtkins, were you going to move DOM? |
| 19:33 | <TabAtkins> | Ms2ger: Move? |
| 19:33 | <Ms2ger> | To CS |
| 19:33 | <Ms2ger> | BS |
| 19:33 | <TabAtkins> | Oh, yeah. I'm partially through it. |
| 19:33 | <TabAtkins> | Will take a bit. |
| 19:33 | <TabAtkins> | Why? |
| 19:33 | <Ms2ger> | Just wondering |
| 19:52 | <smaug____> | Ms2ger: CS? |
| 19:54 | <Ms2ger> | Bikeshed |
| 19:55 | <Ms2ger> | With fat fingers |
| 20:02 | <TabAtkins> | Not drawing that. |