| 00:23 | <MikeSmith> | "we have an over-arching concern that there is things going on in CSS that likely have an impact on Accessibility, and PF (Protocols and Formats WG) have concerns that we aren't monitoring or seeing work at a focused level" |
| 00:23 | <MikeSmith> | nice specific actionable feedback there |
| 00:24 | <MikeSmith> | http://lists.w3.org/Archives/Public/www-archive/2014Jul/0031.html |
| 00:24 | <MikeSmith> | "Our desire would be to have a "partner" - somebody who couldhelp bridge the two working groups by being members of both" |
| 00:25 | <tantek> | s/CSS/*.* WG/ |
| 00:25 | <MikeSmith> | translation: we don't really have the technical understanding about CSS to know what things you guys are working on in CSS that we should be trying to harrass you about |
| 00:25 | <tantek> | s/CSS/the web platform/ |
| 00:27 | <MikeSmith> | ... so, what we'd like to do is, have somebody join our group so that we can make that person explain to us what specific spec we can try to slow work down on by forever expressing slightly more focus but still basically vague "concerns" |
| 00:27 | <MikeSmith> | tantek: yeah, unfortunately |
| 00:28 | <MikeSmith> | but the gall of this request, it's admirable |
| 00:28 | <tantek> | oh this was specifically addressed to glazou! hold on let me get the popcorn... |
| 00:28 | <MikeSmith> | hahah |
| 00:28 | <MikeSmith> | yeah man |
| 00:28 | <tantek> | this ought to be worth some memeage |
| 00:28 | <MikeSmith> | they picked the wrong guy to float that idea to |
| 00:29 | <tantek> | seriously |
| 00:29 | <MikeSmith> | tantek: yeah let's hope so, we could use the memeds |
| 00:29 | <MikeSmith> | *memes |
| 00:29 | <tantek> | take two memeds and call the WG in the morning |
| 00:30 | <MikeSmith> | haha |
| 00:31 | <tantek> | BTW I've been wondering about this whole "Extensible Web" thing. Is "Extensible Web" the XML of the 2010s? |
| 00:31 | <tantek> | and is the Extensible Web Summit the XTech of the 2010s? |
| 00:32 | <MikeSmith> | Glazou, Hey partner! We think maybe there are "things going on in CSS that likely have an impact on Accessibility". Likely. Some things. We extend to you the opportunity to join our telcons and talk about concerns. |
| 00:32 | <MikeSmith> | tantek: yeah that would be an apt comparison I guess |
| 00:33 | <MikeSmith> | "Extensible Web" is the kind of thing we should have been doing back then instead XML |
| 00:33 | <MikeSmith> | we weren't ready yet for it back then |
| 00:34 | <tantek> | still not convinced we anyone are ready for extensible anything |
| 00:34 | <MikeSmith> | fun to try |
| 00:34 | <tantek> | but it's entertaining watching people try for sure |
| 00:34 | <MikeSmith> | it's really about putting power back in the hands of web developers |
| 00:34 | <MikeSmith> | like your indieweb work |
| 00:34 | <tantek> | so far indieweb hasn't need much extension except additions to rel and class |
| 00:35 | <MikeSmith> | well, "Extensible Web" isn't about extensibility |
| 00:35 | <tantek> | but maybe cross-site comment forms would be neat |
| 00:35 | <tantek> | and I could see web components being useful for that |
| 00:35 | <MikeSmith> | it's misleadingly named, "Extensible Web" |
| 00:35 | <tantek> | yeah, bummer of a name |
| 00:35 | <MikeSmith> | yeah, I wasn't asked for my vote on the name when it came up |
| 00:35 | <tantek> | was the re-use of "Extensible" from XML an accident, deliberate, ironic? |
| 00:36 | <MikeSmith> | we're kind of stuck with it now |
| 00:36 | <MikeSmith> | no idea |
| 00:36 | <tantek> | kind of like we were stuck with XML? |
| 00:36 | <MikeSmith> | I don't know who came up with it originally |
| 00:36 | <MikeSmith> | I guess it was first used in that idiot "manifesto" thing |
| 00:36 | <tantek> | yay happy 10 year anniversary of the great web schism where XML was presumed |
| 00:36 | <tantek> | "manifesto"s have such a great history of working out so well |
| 00:36 | <MikeSmith> | yeah we've come a long way since |
| 00:36 | <MikeSmith> | heh |
| 00:37 | <MikeSmith> | yeah, exactly |
| 00:38 | <MikeSmith> | anyway to me the ultimate win we'd get is that Web developers would not have to show up hat-in-hand to browser projects begging for some particular feature to be implementd |
| 00:39 | <MikeSmith> | instead they'd have the primitives exposed from which they could build the features themselves, & more quickly get them out to others web devs to use |
| 00:41 | <MikeSmith> | things do have a bit of the feel of the xtech era of 2005-2006 |
| 00:42 | <MikeSmith> | optimism about the possibility of some really great new game-changing things coming |
| 00:42 | <MikeSmith> | ..along |
| 00:44 | <tantek> | I guess it still feels like there so much opportunity to create & build game-changing things *without* all this extensible web manifesto stuff that I'm not sure I buy the implied premise (of necessity) |
| 00:45 | <tantek> | but hey - that's why I'm still in the wait and see and learn mode re: extensible web *.* |
| 00:45 | <tantek> | and instead, work on the "create & build now" with today's building blocks part in #indiewebcamp |
| 00:46 | <MikeSmith> | yeah you got plenty to do there already |
| 01:25 | <TabAtkins> | tantek: Basically, EWM is about reducing the distance down the tech stack you have to go when you want to change some aspect of how a web feature works. |
| 01:25 | <TabAtkins> | Too often, if you want some small change, we shrug and you have to reinvent a ton of stuff from scratch. |
| 01:26 | <TabAtkins> | Better if we can expose the layers and let you just move down to the first layer that gives you the control you need; then you still get to rely on whatever's underneath. |
| 01:26 | <TabAtkins> | (And often can rely on what's sideways, if things interoperate well between the primitives. That's an ideal that doesn't always happen.) |
| 01:27 | <TabAtkins> | This also drastically reduces the lead time between "I want some new feature" and "I have the new feature", because people can more often build new features themselves. |
| 01:27 | <TabAtkins> | Which also means we don't have to invent everything, or try to predict the best way to do something - we can come along afterwards and learn from what was build on top and is already popular. |
| 02:01 | <JonathanNeal> | Angular.js does this thing where it parses out the arguments in a function to handle dependency injection, I think it’s referred to as reflection. Is there anything like this in native JS or anything proposed to do this? |
| 02:05 | <caitp> | I would guess no, because something people really love to do with JS is mangle symbol names with minifiers |
| 02:10 | <JonathanNeal> | caitp: good point. |
| 02:17 | <zewt> | (that's no reason to not support reflection; minification is a clueless authoring bug) |
| 02:18 | <zewt> | (also "minification" is a euphemism for "obfuscation") |
| 02:18 | <caitp> | I don't disagree, I just haven't seen it come up on es-discuss |
| 02:19 | <caitp> | in the future, maybe people won't care about file sizes because they can depend on their scripts being cached |
| 02:19 | <caitp> | and maybe gzip will be good enough |
| 02:19 | <zewt> | minification has nothing whatsoever to do with file size |
| 02:19 | <zewt> | (if that's what you want, you just use deflate) |
| 02:20 | <caitp> | people rarely just use deflate, minification can get you fewer symbols and deflate better than plaintext would |
| 02:20 | <caitp> | but, I'm a neutral observer, I don't care a whole lot what people use :) |
| 02:21 | <zewt> | no, "minification" is just an excuse to obfuscate code, deflate is plenty |
| 02:21 | <caitp> | I don't know man, I think if people were trying to obfuscate their code, they wouldn't use CDNs with source maps in the same directory |
| 02:21 | <zewt> | (or total incompetence from people who don't know about compression, which isn't better) |
| 02:22 | <caitp> | nobody really does that for the purpose of obfuscation unless they're trying to win [[certain contests]] |
| 02:23 | <caitp> | where "nobody" is the informal "probably very few people" |
| 02:29 | <tantek> | TabAtkins - that's the best summary explanation of EWM I've seen yet. |
| 02:29 | <tantek> | thanks |
| 02:57 | <zewt> | adobe sure is special: their applications don't ask you to configure how much memory to use, they have you configure how much memory to "leave available to other applications" |
| 02:58 | <zewt> | "16 gigs detected, leaving: 5 gigs for other applications" no. |
| 05:38 | <roc> | I'm just a little afraid that EWM is becoming a bit dogmatic, to the point where if something can't be done in an EWM-friendly way people argue it shouldn't be done at all. Or EWM-friendliness trumps all other considerations. |
| 05:44 | <SamB> | EWM? |
| 05:46 | <MikeSmith> | SamB: extensible web |
| 05:46 | <MikeSmith> | manifesto |
| 05:46 | <MikeSmith> | I guess |
| 05:48 | <MikeSmith> | roc: yeah the "but this feature can't be explained" comments are tiresome |
| 05:48 | <MikeSmith> | roc: and I'm afraid it already has become dogma |
| 05:52 | <MikeSmith> | when you start something new by launching it with a "manifesto" I guess you're ensured to get to the dogma stage pretty quickly |
| 05:55 | <TabAtkins> | Welp, "unexplainable" pretty much means "better hope your use-case is exactly one of the ones we solved", so yeah, it's kinda important. |
| 05:56 | <MikeSmith> | nobody said it's not important |
| 05:56 | <MikeSmith> | but as roc said, the point is whether it trumps all other considerations |
| 05:58 | <TabAtkins> | There's a distinction between "trumps everything" and "always gets brought up", though it might not always seem that way from the other side. |
| 06:01 | <SamB> | I would think "unexplainable" meant "what the hell did you do here, go make something that we can follow!" |
| 06:05 | <MikeSmith> | I was referring to "explain" in the specific term-of-art sense in which it appears in recent feature/API discussions |
| 06:05 | <MikeSmith> | not in the general sense |
| 06:05 | <SamB> | explain should NOT be a term of art |
| 06:05 | <MikeSmith> | well extensible web should not a term of art |
| 06:06 | <MikeSmith> | and ServiceWorker should not be the name for an API |
| 06:06 | <SamB> | it is inexplicable |
| 06:06 | <SamB> | perhaps, but that's less bad than "explain" as a term of art ... |
| 07:08 | <TabAtkins> | SamB: It means "this chunk of functionality invokes too much magic". |
| 07:09 | <TabAtkins> | Stuff is "explainable" if you can create it out of other, smaller features. |
| 07:09 | <TabAtkins> | And everything becomes a term of art in some context. |
| 07:10 | <TabAtkins> | Anyway, it comes from "explain how this works". If the answer is "C++ magic", rather than "here's the JS it desugars to", you gotta evaluate whether the magic is too big or an okay size. |
| 07:10 | <SamB> | TabAtkins: well, I guess "explainable" is a better word for that than "redundant" |
| 07:11 | <SamB> | why is it irrelevant whether the JS is an okay size or not ;-) |
| 07:11 | <TabAtkins> | Sugar isn't redundant, it's usable. |
| 07:11 | <SamB> | TabAtkins: I know that ;-) |
| 07:11 | <SamB> | hence "is a better word ..." |
| 07:12 | <TabAtkins> | Perfectly fine to have something desugar to some fairly complicated code; that's why you provide the sugar in the first place. It just means that it's possible for people to move down the abstraction levels without having to go *too* far down and reinvent a whole bunch of unrelated stuff. |
| 07:12 | <SamB> | well, at some point you might want to reconsider desugaring it at all |
| 07:13 | <TabAtkins> | Yeah, you eventually hit a point that's low enough level that it's not worth further explaining, or at least not worth further explaining *right now*. |
| 07:13 | <TabAtkins> | Like, fetch() is trying to remain a fairly small nucleus of functionality. |
| 07:13 | <SamB> | or, well, maybe my thinking is colored too much by what desugar means in e.g. GHC |
| 07:13 | <TabAtkins> | Which is not, itself, explainable. |
| 07:13 | <TabAtkins> | And let further features build on it in a desugarable way. |
| 07:14 | <SamB> | where the code actually does get converted to the desugared form in the compiler |
| 07:14 | <TabAtkins> | Yeah, it's often not necessary (or even prudent) to *actually* implement it in the desugared form. |
| 07:14 | <TabAtkins> | You can get better efficiency/whatever by doing it in CSS instead. |
| 07:14 | <TabAtkins> | It should just be possible to do so. |
| 07:15 | <SamB> | yes, most of the desugaring that GHC's desugarer does is fairly trivial |
| 07:15 | <odinho> | high level sugared apis could be implemented directly, as long as they look/behave exactly as if not. |
| 07:15 | <TabAtkins> | s/CSS/C++/ |
| 07:15 | <TabAtkins> | odinho: Yeah. |
| 07:15 | <bufferino> | is there a channel to discuss software development practices? |
| 07:16 | <SamB> | and if you're talking about semantic sugar rather than syntactic sugar, well, I don't actually know what that is ;-) |
| 07:19 | <odinho> | when i just started at opera i remember discussing much a higher-level convenient api in browsers. starting with an extension, maybe even pre-bundled and get some highlevel nice apis defined. i like the |
| 07:20 | <odinho> | direction the js api discussions has taken lately. seem in that direction though not the same |
| 07:21 | <TabAtkins> | bufferino: I'm sure there is, but I don't know where it would be. ^_^ |
| 12:15 | <gsnedders> | All the introductions to current flexbox model seem... lacking. They either have way too little detail or just describe stuff as black magic when trying to explain how flex items flow. |
| 18:29 | <Hixie> | the problem with "explainable" being defined as "doesn't involve too much C++" is that "too much" is invariably defined as "as much as my feature, but less than your feature" |
| 18:30 | <Hixie> | imho "explainable" is a bad design philosophy. It's definitely good to design things in a way that they can be repurposed logically, and so on. But it's not objective enough as a design philosophy. |
| 18:30 | <Hixie> | that's why i prefer the "list the use cases, then evaluate the proposals based on those use cases" model |
| 18:43 | <hober> | Yeah, but "sensibly, incrementally add to the platform based on concrete use cases" isn't the stuff MANIFESTOS are made of |