| 00:17 | <TabAtkins> | Can someone point me at a spec using ReSpec? Wanna verify something before I copy it. |
| 01:05 | <MikeSmith> | TabAtkins: https://dvcs.w3.org/hg/webdriver/raw-file/default/webdriver-spec.html is one |
| 01:05 | <TabAtkins> | Cool, thanks. |
| 01:11 | <MikeSmith> | TabAtkins: that's using an outdated version. Dunno if it matters for what you need, but I think https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/media-source-respec.html is using something newer |
| 08:44 | <zcorpan> | Ms2ger: r? https://critic.hoppipolla.co.uk/r/3063 https://critic.hoppipolla.co.uk/r/3076 https://critic.hoppipolla.co.uk/r/3077 |
| 08:45 | <Ms2ger> | zcorpan, did I see that event.ports pr before, or was that another one? |
| 08:46 | <zcorpan> | Ms2ger: dunno? haven't seen any other pr touching that file |
| 09:08 | <annevk> | http://www.dreamhoststatus.com/2014/11/04/upgrading-187-shared-web-hosting-servers-to-ubuntu-12-04-precise-november-8th-8pm-2am-pst/ Hopefully WHATWG is on one of those |
| 09:35 | <zcorpan> | Ms2ger: thank you |
| 09:35 | <Ms2ger> | Np |
| 09:35 | <Ms2ger> | And thank you :) |
| 13:49 | <annevk> | While trying to create a new mapping table I run into this rather obscure bug https://bugzilla.mozilla.org/show_bug.cgi?id=1094804 |
| 13:56 | <frivoal> | *.whatwg.org is in my firefox's force TLS list. Not sure how it got there, but if this is something that is pushed remotely, this is a problem as lists.whathwg.org is not served over https |
| 13:56 | <Ms2ger> | Indeed |
| 13:56 | <Ms2ger> | The archives are available at lists.w3.org |
| 13:59 | <frivoal> | Yep, found them. But I was signing up for the mailing list, and trying to confirm by visiting the link (rather than replying to the mail), and that can only be done on lists.whatwg.org (afaik) |
| 14:00 | <Ms2ger> | I've heard that you can email somewhere |
| 14:00 | <Ms2ger> | It sucks, but it's apparently impossible to make dreamhost serve that over https |
| 14:01 | <frivoal> | found how I got the header (maybe that's obvious, but it wasn't to me). go to http://whatwg.org, get a 301 to https://whatwg.org which has the following http header |
| 14:01 | <frivoal> | Strict-Transport-Security:max-age=31556900; includesubdomains; preload |
| 14:02 | <frivoal> | if we can't actually serve all domains on https, maybe this header shouldn't be served |
| 14:02 | <Ms2ger> | Already been considered and rejected, sorry :) |
| 14:02 | <frivoal> | :) |
| 14:03 | <frivoal> | oh well, I am signed up now, so I'm fine, but this is pretty noob hostile |
| 14:04 | <Ms2ger> | I don't disagree |
| 14:06 | <frivoal> | Even if dreamhost can't serve mailman over https, it would be good to get them to serve something there. |
| 14:06 | <annevk> | frivoal: it's either that header or https://hstspreload.appspot.com/ |
| 14:08 | <frivoal> | probably not https://hstspreload.appspot.com/, since accessing the site on my wife's firefox (which hadn't visited http://whatwg.org) worked fine. |
| 14:09 | <annevk> | But yeah, we need to solve this somehow :-( |
| 14:10 | <frivoal> | alternatively, is it possible to customise the message that is sent to ask people to confirm their registration? Just removing the link from there would have saved me the confusion, as there are instructions on how to confirm by email. |
| 14:10 | <annevk> | Yeah I think that might be possible. Hixie would have to configure it |
| 14:11 | <frivoal> | the welcome email also has a list lists.whatwg.org, but it is an uninteresting one, so that might not matter |
| 14:11 | <frivoal> | s/list/link/ |
| 14:12 | <frivoal> | I'll mail Hixie |
| 14:18 | <annevk> | ta |
| 14:20 | <frivoal> | "ta"? |
| 14:21 | <annevk> | http://www.urbandictionary.com/define.php?term=ta |
| 14:22 | <frivoal> | TIL |
| 14:22 | <frivoal> | mail sent |
| 14:45 | <pikaren> | why doesnt whatwg merge with w3c |
| 15:06 | <boogyman> | pikaren: politics |
| 15:11 | <Domenic> | pikaren: because then we couldn't work according to https://wiki.whatwg.org/wiki/FAQ#The_WHATWG_Process |
| 15:24 | <annevk> | If you just want to get a set of bytes in JavaScript, is there no simpler way than creating an ArrayBuffer, creating a view upon that, and then setting the bytes? |
| 15:26 | <Domenic> | what does "get a set of bytes" mean? is [123, 111, 159] a set of bytes>? |
| 15:30 | <Domenic> | annevk: maybe what you're looking for is Uint8Array.from([123, 111, 159]).buffer ? |
| 15:30 | <annevk> | Domenic: yeah, I wonder if that's implemented |
| 15:30 | <Domenic> | doesn't seem to be |
| 15:30 | <Domenic> | Uint8Array.of(123, 111, 159).buffer |
| 15:39 | <annevk> | Domenic: neither |
| 15:39 | <annevk> | TypeError: undefined is not a function in Chrome and TypeError: Uint8Array.of is not a function in Firefox |
| 15:39 | <Domenic> | Polyfillable, I guess |
| 15:40 | <annevk> | Sure, but for playing with TextDecoder this is annoying |
| 15:40 | <Domenic> | Yeah, text decoder is not the most user-friendly API sadly |
| 15:45 | <annevk> | It's quite easy, no? |
| 15:45 | <annevk> | It's the bytes bit that's fucked |
| 15:46 | <annevk> | That is to say, if we can make it more friendly I would like to make that happen |
| 15:47 | <Domenic> | I guess you're right |
| 15:47 | <Domenic> | Some statics might be nice though |
| 15:48 | <Domenic> | TextDecoder.decode(bytes/*, "utf-8"*/) |
| 15:48 | <Domenic> | I wonder if you could support any iterable |
| 15:48 | <annevk> | Ah yeah, for the non-streaming case that'd be nice |
| 15:49 | <annevk> | For the real streaming case we prolly want streams |
| 15:49 | <Domenic> | yeah |
| 15:49 | <Domenic> | I should prototype that out |
| 15:50 | <annevk> | We should probably upgrade the API when streams have landed |
| 15:50 | <Domenic> | Agreed |
| 15:50 | <annevk> | Add streams plus convenience as v2 |
| 15:50 | <Domenic> | I should prolyfill them based on the streams polyfill |
| 15:50 | <JonathanNeal> | Yea! |
| 15:51 | <Domenic> | should be really easy actually |
| 15:52 | <annevk> | https://wiki.whatwg.org/index.php?title=Web_Encodings&oldid=3949 5+ years now, but getting close |
| 15:52 | <annevk> | (though only getting close in Firefox and Chrome) |
| 15:53 | <Domenic> | Wow not even under consideration for IE |
| 15:53 | <JonathanNeal> | Event Streams or some other kind? |
| 15:54 | <Domenic> | JonathanNeal: http://streams.spec.whatwg.org/ |
| 15:54 | <Domenic> | (https, rather ... I copied and pasted too fast I guess) |
| 15:56 | <Domenic> | go upvote https://wpdev.uservoice.com/forums/257854-internet-explorer-platform/suggestions/6558040-support-the-encoding-api |
| 15:58 | <Domenic> | https://twitter.com/domenic/status/530388605920116736 |
| 15:59 | <Domenic> | annevk: which parts of the API are web-specific? EncodingError DOMException; anything else? |
| 16:01 | <Domenic> | At the next TC39 the Microsoft guy wants to talk about Streams as part of the JS standard library. My position is that JS engines should just start implementing more specs than ECMA-262 and ECMA-402. I plan to point to Streams, Encoding, maybe even URL and Fetch. |
| 16:01 | <annevk> | Domenic: URL and Fetch are generic (up to a point) |
| 16:01 | <annevk> | Domenic: and yeah, EncodingError :/ |
| 16:02 | <Domenic> | I imagine that could be changed especially if it was the price of getting IE on board. |
| 16:03 | <Domenic> | (No idea if that's actually how it'll go down, but it's a possible future.) |
| 16:03 | <annevk> | I'm open to changing it. I don't know if jsbell and whoever implemented it in Gecko want the churn |
| 16:03 | <Domenic> | right yeah, would want to be worth the trouble |
| 16:04 | <annevk> | Search and replace operations through the code base are somewhat costly |
| 16:04 | <annevk> | But yes, if it helps Node.js and Microsoft that would be good |
| 16:05 | <annevk> | Domenic: you should probably again point out that if TC39 wants to treat DOM as a library, they should provide the tools for writing said library (IDL) |
| 16:06 | <annevk> | Domenic: if TC39 helped out with IDL there'd probably be less differences in design approaches |
| 16:07 | <annevk> | Domenic: if JavaScript's own library was written in IDL... well |
| 16:07 | <Domenic> | it's just a big task with unclear gain compared to just paying attention on public-script-coord... |
| 16:08 | <annevk> | I have the feeling that there's quite a few things in IDL TC39 disapproves |
| 16:08 | <annevk> | But have not been marked as such and continue to be getting usage |
| 16:44 | <gsnedders> | I don't think you can deal with some of the weird legacy stuff in the JS standard library easily |
| 16:44 | <gsnedders> | Though I think proxies make arrays now implementable in pure JS? |
| 17:33 | <caitp> | a person named NotBobTheBuilder wants links to not be navigable (ie `href` attribute removed) if they contain the attribute `disabled` |
| 17:33 | <caitp> | "web browsers follow the spec and IMO the spec gets this wrong" |
| 17:33 | <Hixie> | there's a bug about that |
| 17:33 | <caitp> | basically "disabled shouldn't just be a form control thing, it should behave more like aria-disabled" |
| 17:34 | <caitp> | can I link them to it? |
| 17:34 | <Hixie> | browser vendors didn't seem against it, but also weren't particularly enthusiastic |
| 17:36 | <Hixie> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=26622 is where it was discussed, looks like it's not a dedicated bug |
| 17:41 | <caitp> | it would be pretty cool, fwiw, if all of the various `aria` attributes had some behaviour merged into the regular html stuff |
| 17:43 | <annevk> | disabled used to be a global attribute in IE |
| 17:44 | <annevk> | There's bound to be some emails or bugs written by me about that, circa 2005-? |
| 17:45 | <caitp> | if it came between breaking a lot of websites, but making other sites, and all future sites basically accessible by default, or not breaking websites, but not getting accessibility by default, what would you go for |
| 17:48 | <boogyman> | imo "status quo" is already broken, so as a web-author, I would prefer accessibility by default. |
| 18:01 | <annevk> | Domenic: most implementers at Gecko keep pointing out web components seems mostly abandoned spec-wise and is broken in implementations once you look at the details |
| 18:01 | <annevk> | Domenic: is Google still putting actual effort into fixing it? |
| 18:02 | <proberts_> | $('html *').each(function(){$(this).css('animation','spaceboots '+(1+Math.random(1))+'s infinite')}) |
| 18:02 | <caitp> | they probably gave some talks about it at blinkon, so they probably haven't given up on it |
| 18:02 | <caitp> | implementation-wise at least |
| 18:04 | <caitp> | according to the state of blink slides, shadow dom and html imports shipped, so I guess that's an indication that they haven't given up on custom elements entirely |
| 18:05 | <smaug____> | sure, shippen, but behaving against the current specs |
| 18:05 | <smaug____> | shipped |
| 18:06 | <tantek> | shipped, behaving against current specs, unprefixed / unpreffed and in production, not just beta/alpha/dev builds? |
| 18:07 | <caitp> | element.createShadowRoot seems to be available in m38, I don't think I have any experimental stuff flipped on for my stable browser |
| 18:07 | <caitp> | i'm sure the css behaviour is probably broken |
| 18:08 | <caitp> | all i'm saying is, if it's shipped, they probably haven't given up on it just yet |
| 18:08 | <tantek> | caitp - presumably they have samples for the DOM and CSS stuff that demonstrates it working? |
| 18:09 | <tantek> | caitp - Chrome ships and kills things. E.g. Google's "Web Intents". |
| 18:09 | <caitp> | yes, I keep up with it |
| 18:13 | <annevk> | They haven't really been actively improving things though |
| 18:15 | <caitp> | sure, it's not clear anyone really knows how to make it better, but I think there's a lot of pressure not to kill it off now as so many groups want it |
| 18:18 | <hober> | "not clear anyone really knows how to make it better" doesn't match up with all of the issues raised by other vendors then ignored or WONTFIXed... |
| 18:19 | <caitp> | maybe they really thought those weren't very good ideas! |
| 18:20 | <caitp> | or something, I dunno, I am talking for other people right now and I can't read their minds |
| 18:21 | <hober> | heh. i'm just saying it's hard to keep spec momentum on a thing you're manifestly unwilling to change based on the feedback you've actually gotten. why would other folks continue giving you feedback? |
| 18:22 | <tantek> | hober, also odd to reject feedback, and then ship something that differs from the spec, without updating the spec |
| 18:22 | <annevk> | hober: actually, we've given a ton of feedback that has simply gone unaddressed |
| 18:22 | <annevk> | hober: is Apple planning on putting resources on it or hoping it dies? |
| 18:23 | <annevk> | Web components feels a bit like abandonware, ship prematurely, then don't bother polishing |
| 18:23 | <annevk> | Allocate resources to focus on some other thing |
| 18:24 | <tantek> | annevk - are there no google sites/apps that depend on or take advantage of Chrome's web components implementation? e.g. gmail? |
| 18:24 | <hober> | annevk: i think you already know the answer to questions of the form "is apple planning..." |
| 18:24 | <caitp> | they don't depend on them |
| 18:25 | <annevk> | hober: I wonder if I should try to convince Mozilla leadership (if there even is such a thing) that we pull out too |
| 18:25 | <caitp> | why not just fork the spec? |
| 18:25 | <caitp> | make a bigger, better one |
| 18:25 | <tantek> | hober: "Ask me is Apple planning one more time, I dare you, I double dare you …." |
| 18:25 | <caitp> | with pancakes |
| 18:25 | <caitp> | and css |
| 18:26 | <smaug____> | someone else could become the editor, sure |
| 18:26 | <smaug____> | but I'd probably make rather major changes |
| 18:26 | <smaug____> | and it is really work initiated by Google |
| 18:26 | <smaug____> | I'd expect Google to have enough resources to finalize and maintain it |
| 18:27 | <smaug____> | annevk: that is actually a good guestion |
| 18:28 | <smaug____> | we should at least think about whether it is really worth spending resources for this half-baked thing |
| 18:29 | <annevk> | smaug____: especially since what it seems most of us wanted aligns rather well with what Apple wants |
| 18:29 | <smaug____> | yeah |
| 18:31 | <smaug____> | should ask Gaia folks how they use shadow dom, and whether it is actually useful |
| 18:32 | <caitp> | my experience with googlers is that they have a bit of a hard time focusing on one thing, other duties always seem to creep in, which could be related to inattention to bugs |
| 18:32 | <caitp> | there are exceptions, but it seems common |
| 18:33 | <smaug____> | "hard time focusing on one thing" sounds so familiar ;) /me kicks himself for not doing what he was supposed to do |
| 18:35 | <jamesr_> | smaug____, annevk: i'm not following web components personally but i can forward your concerns to those who are (i don't think they can pop into IRC right this second) |
| 18:36 | <jamesr_> | it's definitely being used |
| 18:36 | <annevk> | jamesr_: we have reached out to some of the editors and in particular dglazkov afaik |
| 18:39 | <annevk> | jamesr_: https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14972&hide_resolved=1 is the basic problem |
| 18:39 | <smaug____> | if someone from Apple or Mozilla would become the active editor of the web components stuff, the specs might change quite a bit. I wonder if Google would be then willing to make the changes |
| 18:39 | <annevk> | jamesr_: (minus "make examples" bugs) |
| 18:40 | <annevk> | jamesr_: and Google not actually implementing the spec |
| 18:40 | <annevk> | jamesr_: as I understand it |
| 18:40 | <caitp> | if 2 out of 4 popular browsers come up with an incompatible implementation of components, google would probably have to change them |
| 18:41 | <Ms2ger> | smaug____, well, is Google willing to implement the spec now? :) |
| 18:42 | <smaug____> | heh |
| 18:42 | <gsnedders> | Ms2ger: does it help with moible perf? |
| 18:42 | <smaug____> | Ms2ger: it is implementing some imaginary variant of it |
| 18:42 | <smaug____> | gsnedders: web components? |
| 18:42 | <smaug____> | I can't think of anything which would improve performance |
| 18:43 | <Ms2ger> | gsnedders, we need a "tropes in web standards" catalogue :) |
| 18:43 | <caitp> | it improves peoples ability to read html |
| 18:43 | <smaug____> | but I can think of cases where it slows down performance a bit |
| 18:43 | <gsnedders> | smaug____: I think you're missing the joke :) |
| 18:44 | <smaug____> | I think not. I just happened to answer as if I did :) |
| 18:44 | <annevk> | Pretty sure it's about ethics in ... |
| 18:44 | <caitp> | womp |
| 18:45 | <gsnedders> | smaug____: actually, should it not be possible to do some sort of memoization for web components? make repeated patterns quicker? or something |
| 18:45 | gsnedders | doesn't really know about layout |
| 18:47 | <smaug____> | I don't see how web components(well, shadow dom) could make anything faster comparing to some other random DOM subtrees |
| 18:48 | <caitp> | sometimes you buy a fast computer with GPUs dedicated to crunching big numbers, to improve performance |
| 18:48 | <caitp> | and sometimes you buy a standing desk because sitting on your ass all day is terrible for your back |
| 18:48 | <caitp> | developer ergonomics |
| 18:48 | Ms2ger | whacks annevk |
| 18:48 | <gsnedders> | smaug____: the fact you have a single subtree that you can use as a cache key more easily, I'd guess |
| 18:49 | <caitp> | the standing desk won't crunch numbers faster, but you'll feel less miserable while you do it |
| 18:49 | <gsnedders> | Ms2ger: BUT INTEGRITY! |
| 18:50 | <annevk> | I hate iso-2022-jp |
| 18:50 | <terinjokes> | but don't use ikea desk with extendable legs, because then you'll just be annoyed that your desk sways (and you eventually lower it back down anyways) |
| 18:50 | <annevk> | Also, browsers are terrible |
| 18:50 | <annevk> | Film at 11 |
| 18:51 | <jarek> | are there any benchmarks that would take web components performance into account? |
| 18:57 | <tantek> | annevk: also, sockpuppets and the online media editors who seem unable to recognize them when they arrive in droves. |
| 19:00 | <gsnedders> | jarek: probably not |
| 19:02 | <caitp> | it would be easy to make one |
| 19:02 | <caitp> | just wrap that cool 3d rubiks cube css demo in a custom element, and voila |
| 19:04 | <jarek> | it would be interesting to see how rewriting jQuery spaghetti code into proper set of web components impacts performance |
| 19:20 | <caitp> | not having to wait for DOMContentReady before performing all your wacky DOM manipulation would probably be a win for at least one performance metric |
| 19:20 | <caitp> | ready? loaded? |
| 19:22 | <jarek> | DOMContentLoaded |
| 19:23 | <jarek> | that's an awful DOM event name btw |
| 19:24 | <jarek> | are there any plans to rename it to "domcontentload" for the sake of consistency? |
| 19:24 | <caitp> | well it's not WM_COMMAND at least |
| 19:24 | <jarek> | s/rename/symlink |
| 19:48 | <esprehn> | annevk: lots of work is still going into our web components implementation, is there some bugs you're aware of that aren't being addressed? |
| 19:55 | <tantek> | esprehn - seems to be a consensus here that the biggest bug is that Chrome's implementation is divergent from the spec, and the spec isn't being updated accordingly. |
| 19:56 | <esprehn> | I'll talk to the person working on the spec |
| 19:56 | <esprehn> | We should have been better about how the monkey patching was done |
| 19:56 | <jarek> | for me the biggest headache with Web Components is how relative URLs are handled |
| 20:00 | <esprehn> | hmm? |
| 20:01 | <esprehn> | jarek: can you give an example? |
| 20:03 | <smaug____> | esprehn: from an implementors point of view the current situation is hard. Implementing what the specs say leads to very different behavior what blink has. And one never knows if blink implements what the spec is supposed to say, or if blink behavior is just a bug. |
| 20:07 | <jarek> | esprehn: http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0013.html |
| 20:20 | <rubys> | TabAtkins: I just updated bikeshed. It no longer accepts ED. Unfortunately, it doesn't accept 'current' or 'dated' either. |
| 20:20 | <rubys> | File "/home/rubys/git/bikeshed/bikeshed/ReferenceManager.py", line 273, in getRef |
| 20:20 | <rubys> | refs = [ref for ref in refs if ref['status'] == "ED" or (ref['status'] == "TR" and self.specs[ref['spec']].get('ED') is None)] |
| 20:20 | <rubys> | KeyError: u'encoding-1' |
| 20:31 | <rubys> | Heading out. Left this as a comment: https://github.com/rubys/url/compare/anolis2bikeshed?expand=1#commitcomment-8468411 |
| 20:55 | <esprehn> | smaug____: please file bugs, run our tests, and contribute your own |
| 20:55 | <esprehn> | hayato_: ^ |
| 20:56 | <smaug____> | esprehn: bugs filed |
| 20:56 | <smaug____> | some at least |
| 20:56 | <esprehn> | jarek: yes, loading images with css from inside a component is difficult when loaded in |
| 20:56 | <esprehn> | err, packaged in rather |
| 21:37 | <annevk> | esprehn: there's a whole lot of open bugs against the spec |
| 21:38 | <annevk> | esprehn: some issues I filed with regards to members exposed on ShadowRoot still hasn't been addressed, same with an issue with regards to blocking events based on their type name |
| 21:39 | <annevk> | esprehn: more recent bugs also go without feedback, seems like there's not active maintenance, especially with some stuff prolly lingering now for a year or so |
| 21:41 | <Hixie> | maybe the spec needs a new editor |
| 21:42 | <annevk> | There's also the fact that neither Apple nor Mozilla are particularly thrilled with the current design |
| 21:43 | <annevk> | Hixie: heh, how many editors have you seen deliver solid work recently? |
| 21:43 | <esprehn> | annevk: can you link me to which bugs you think need addressing? |
| 21:43 | <esprehn> | I don't see recent bugs from you |
| 21:43 | <annevk> | Hixie: that's the kind of line I'd expect in one of these 60 people in a room group meetings :p |
| 21:43 | <annevk> | esprehn: my bugs are ancient, recent bugs were by bz and others |
| 21:44 | <Hixie> | annevk: the lack of good editors in general is indeed quite sad |
| 21:45 | <annevk> | esprehn: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16904 was filed in May 2012 |
| 21:46 | <annevk> | esprehn: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23620 from October 2013 |
| 21:47 | <esprehn> | I don't believe we can remove the getElementById method, but we should probably remove the others |
| 21:48 | <annevk> | esprehn: a bug of mine was duped against https://www.w3.org/Bugs/Public/show_bug.cgi?id=20247 which is from December 2012 and pretty fundamental with respect to event dispatching |
| 21:48 | <annevk> | esprehn: getElementById is fine, that's on DocumentFragment these days |
| 21:48 | <rniwa> | annevk: I stopped giving feedback because our feedback was basically ignored |
| 21:48 | <annevk> | rniwa: same |
| 21:48 | <annevk> | rniwa: that's why my bugs are so old |
| 21:50 | <rniwa> | annevk: I think maciej’s encapsulation model has been “accepted” informally on the mailing list numerous times in the last four or five years yet I don’t see any indication of it appearing anywhere in the spec. |
| 21:52 | <rniwa> | annevk: it would be nice if specs WebApps WG actually reflected the consensus of the WG instead of one participant in the WG... |
| 21:52 | <rniwa> | specs WebApps WG produce* |
| 21:54 | <annevk> | https://github.com/webcomponents/webcomponents.github.io/tree/site/src/documents/specs |
| 21:54 | <annevk> | Is that really where the specifications are hosted these days? |
| 21:54 | <annevk> | Anyway, seems like they're not really updated |
| 21:56 | <annevk> | Oh no, it's https://github.com/w3c/webcomponents/ |
| 21:57 | <annevk> | https://github.com/w3c/webcomponents/commits/gh-pages |
| 21:57 | <annevk> | So yeah, couple of fixes every so often |
| 22:02 | <rniwa> | annevk: I think the real issue is that any feedback editors don’t like is not incorporated into the spec. even if multiple non-Google browser vendors liked it :( |
| 22:03 | <esprehn> | annevk: thanks for the pointers, I'll share them with hayato_ and see where he is in addressing the bug backlog |
| 22:03 | <rniwa> | annevk: surely, they can create a spec that’s consistent with Blink’s behavior but if they’re not accepting any feedback, they might as well as not do it in WebApps WG… |
| 22:04 | <annevk> | rniwa: "don't attribute to malice..." |
| 22:04 | <annevk> | rniwa: (not that it means we have to be okay with it) |
| 22:05 | <rniwa> | annevk: I’m not saying that they have a bad intention but it’s an observable fact that they haven’t taken any significant feedback from other browser vendors recently. |
| 22:05 | <annevk> | rniwa: the editors are new, editing core platform features is hard and requires months of hard work |
| 22:05 | <annevk> | rniwa: it seems likely they were not prepared for the task and are also assigned to other things |
| 22:06 | <rniwa> | annevk: perhaps. |
| 22:06 | <annevk> | rniwa: I don't know how to best address it since the amount of good editors we have is rather limited |
| 22:06 | <esprehn> | rniwa: we've be very interested in hearing your feedback as you implement the spec |
| 22:07 | <annevk> | rniwa: and they all have plenty to do already |
| 22:07 | <rniwa> | esprehn: I don’t think we’re interested in implementing anything unless there is an indication that the spec will change in accordiance with our feedback. |
| 22:07 | <esprehn> | rniwa: that sounds like a hostage situation :) |
| 22:07 | <rniwa> | there’s no point in having to support something incompatible |
| 22:08 | <jarek> | rniwa: wasn't Shadow DOM work already started in WebKit branch? |
| 22:08 | <rniwa> | jarek: no |
| 22:08 | <annevk> | esprehn: I think it is true to some extent that feedback on the WebApps list has been ignored |
| 22:09 | <jarek> | rniwa: ohh... I recall someone mentioning it on the mailing list |
| 22:09 | <rniwa> | jarek: I did mention it |
| 22:09 | <esprehn> | annevk: a large amount of feedback has been incorporated |
| 22:09 | <rniwa> | jarek: but I didn’t really start implementing anything since our feedback has largely been ignored. |
| 22:09 | <annevk> | esprehn: some level of engagement, but then failing to make a compelling case and leaving arguments unaddressed |
| 22:10 | <annevk> | esprehn: that's not really my impression |
| 22:10 | <annevk> | esprehn: I feel that most of the substantive stuff I complained about has been ignored |
| 22:12 | <esprehn> | annevk: I apologize we didn't get your feedback addressed |
| 22:12 | <hober> | esprehn: that *does* sound like a hostage situation, though probably not in the way you intended... |
| 22:13 | <esprehn> | hober: perhaps a stand off is better |
| 22:14 | <esprehn> | annevk: please feel free to bring up your concerns again, I'll point the people in your direction |
| 22:15 | <Ms2ger> | That no longer sounds like a hostage situation |
| 22:15 | <Ms2ger> | That sounds like the HTMLWG |
| 22:18 | <jarek> | is it still possible that Web Components will end up with native support only in one (well two if you count Opera) browsers? |
| 22:18 | <jarek> | this is what happened with Pointer Events recently |
| 22:20 | <jarek> | Chrome has too big market share and other vendors can't afford to not support apps/sites optimised for it |
| 22:20 | <cbiesinger_> | hm? do browsers implement pointer events, beyond ie? |
| 22:21 | <jarek> | cbiesinger_: Mozilla did start work on it |
| 22:21 | <cbiesinger_> | jarek: why? :-) |
| 22:22 | <jarek> | cbiesinger_: the spec is almost finished |
| 22:22 | <esprehn> | what's apple's position on the spec? |
| 22:22 | <cbiesinger_> | jarek: it's more that I don't get the impression that blink/webkit are interested |
| 22:23 | <cbiesinger_> | but I could be wrong! |
| 22:23 | <Ms2ger> | Ohai |
| 22:24 | <jarek> | cbiesinger_: they are not interested and they expressed it clearly on mailing list and on Chrome bug tracker |
| 22:24 | <cbiesinger_> | jarek: ok, so mozilla thinks this is useful nonetheless? |
| 22:25 | <jarek> | cbiesinger_: Google is planning to extend touch events spec: https://docs.google.com/a/chromium.org/document/d/1x-yE4CmTZlZQXea4_FPjgly5TOvF28UBNs9gZ5aGUhg |
| 22:25 | <cbiesinger_> | jarek: yeah |
| 22:25 | <caitp> | https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/pointer-events/blink-dev/K1qk6qZWgIc/4PxUvSibPTsJ this doesn't sound like an outright rejection of pointer events (or did i miss something?) |
| 22:26 | <jarek> | cbiesinger_: no idea what Mozilla thinks about it |
| 22:26 | <roc> | esprehn: this isn't the first time we've reached out to Google people try to get more traction on Web Components standards issues. |
| 22:26 | <smaug____> | cbiesinger_: Gecko has implementation |
| 22:26 | <smaug____> | cbiesinger_: not enabled by default |
| 22:27 | <smaug____> | the initial backend is for Metro |
| 22:27 | <esprehn> | roc: thanks for the feedback |
| 22:27 | <roc> | esprehn: I raised basically the same issues with Hixie a few weeks ago |
| 22:27 | <smaug____> | cbiesinger_: and yes, pointer events would be way nicer than touch+mouse+touch extensions which google is now driving |
| 22:28 | <roc> | esprehn: and that wasn't the first time either |
| 22:28 | <esprehn> | roc: I'll make sure dglazkov is aware |
| 22:28 | <smaug____> | cbiesinger_: pointer events were supposed to go to blink, but for some reason blink folks decided to go with a model no one else then follow (extensions to touch events) |
| 22:29 | <jarek> | esprehn: Apple invented pointer events, so they will probably opt for extending that spec rather then introducing a completely new input model |
| 22:29 | <jarek> | s/pointer events/touch events |
| 22:29 | <esprehn> | I'm aware of the history |
| 22:29 | <smaug____> | web devs prefer pointer events model |
| 22:30 | <smaug____> | IIRC several script library impls will have pointer events |
| 22:30 | <jarek> | yeah, but as always browser developers know better :P |
| 22:30 | <smaug____> | and just polyfill implementations which don't support them |
| 22:30 | <othermaciej> | I think the reasons Google stated for why pointer events are problematic for perf are correct |
| 22:30 | <caitp> | doesn't polymer use a pretty competent pointer events polyfill? |
| 22:30 | <caitp> | or jquery or something |
| 22:30 | <smaug____> | polymer == google, so pointer events were dropped, IIRC |
| 22:31 | <caitp> | I know who is backing polymer :p |
| 22:31 | <caitp> | but I remember hearing them pushing it at a conference a while ago |
| 22:31 | <jarek> | caitp: that component was deprecated few months ago |
| 22:31 | <caitp> | ah |
| 22:33 | <smaug____> | we should go back and start all over with XBL2 :) |
| 22:35 | <esprehn> | caitp: they stopped using it |
| 22:35 | <caitp> | wow apparently you can hide that annoying menu in google groups, TIL. anyways, I see intent to implement + ship threads with 3 lgtms for parts of pointer events, and no "lets not do this" in the other thread, so I must be missing where this rejection happened in blink |
| 22:37 | <caitp> | https://code.google.com/p/chromium/issues/detail?id=162757#c64 oh I see. |
| 22:37 | <caitp> | that's pretty painful considering the implementation status from other vendors lol |
| 22:38 | <cbiesinger_> | smaug____: ^ |
| 22:39 | <smaug____> | cbiesinger_: ? |
| 22:39 | <smaug____> | I did answer to rick about the reasoning |
| 22:39 | <cbiesinger_> | smaug____: re "for some reason blink folks decided to go with a model no one else then follow" |
| 22:39 | <cbiesinger_> | that is the some reason |
| 22:40 | <cbiesinger_> | anyway, just surprised that firefox implements something that only them and ie support |
| 22:40 | <smaug____> | "especially without support from Safari" is a bit silly. blink implements all sorts of stuff not in Webkit |
| 22:40 | <smaug____> | like web components |
| 22:41 | <rniwa> | isn’t the whole reason Mozilla has implemented pointer events was because Blink was gonna do it? |
| 22:41 | <smaug____> | 2) is not quite true |
| 22:42 | <caitp> | mozilla has implemented quite a lot of things that nobody else has |
| 22:42 | <smaug____> | rniwa: let's say so that if blink folks hadn't said for 2 years that they are going to implement pointer events, gecko probably wouldn't have implementation |
| 22:42 | <caitp> | and by "quite a lot" i mean the handful of examples in my head |
| 22:43 | <smaug____> | caitp: how is that relevant here |
| 22:43 | <caitp> | it was just in response to what rniwa had said |
| 22:43 | <caitp> | I don't think they would wait for blink to do it |
| 22:43 | <caitp> | s/they/you guys |
| 22:43 | <smaug____> | and 3) is something which could be solved too |
| 22:44 | <smaug____> | caitp: well, blink folks explicitly said they will implement pointer events |
| 22:44 | <cbiesinger_> | safari is interested in web components, unlike pointer events |
| 22:46 | <smaug____> | I haven't seen too many positive signals |
| 22:46 | <smaug____> | mostly concerns about broken encapsulation and information hiding |
| 22:46 | <cbiesinger_> | I guess https://lists.webkit.org/pipermail/webkit-dev/2014-February/026251.html is kind of old |
| 22:46 | <smaug____> | which are almost non-existent in web components |
| 22:46 | <caitp> | so why did gecko implement microdata? was that dave's idea or something? |
| 22:47 | <caitp> | according to wikipedia, presto is the only other |
| 22:48 | <roc> | wasn't that dzbarsky's intern project or something? |
| 22:48 | smaug____ | wonders if rniwa got anywhere with the shadow dom implementation, given the state of the spec |
| 22:50 | <rniwa> | smaug____: I said web components but not shadow DOM LOL |
| 22:50 | <cbiesinger_> | rniwa: maciej said shadow dom :) https://lists.webkit.org/pipermail/webkit-dev/2014-February/026258.html |
| 22:51 | <smaug____> | caitp: well, microdata is in the spec |
| 22:51 | <rniwa> | cbiesinger_: well, in that case, I can safely say that I haven’t implemented any |
| 22:52 | <rniwa> | cbiesinger_: like I mentioned ealirer, there’s no point for me to start implementing stuff when our feedback is completely ignored. |
| 22:52 | <rniwa> | cbiesinger_: then we’re left with an option of either implementing what spec says, which doesn’t match Blink’s implementation, or match Blink’s implementation, or implement something we think is the right API and propose those spec changes |
| 22:52 | <rniwa> | and none of those options are attractive to us. |
| 22:53 | <caitp> | lots of things are in the spec :p |
| 22:53 | <caitp> | or in one spec or the other |
| 22:55 | <rniwa> | smaug____: I find it amusing that you guys have been mis-quoted repeatedly that Mozilla is implementing web components LOL |
| 22:56 | <smaug____> | I'd say we're experimenting whether it makes sense to implement it all |
| 22:56 | <jarek> | rniwa: is this really the only reason? Web Components are critical for Web Platform to take over the app store ecosystems |
| 22:56 | <caitp> | in january I saw that a lot of mozilla's web components metabug had landed |
| 22:57 | <caitp> | did you revert all that gunk? :p |
| 22:57 | <jarek> | rniwa: and this obviously against Apple's interests |
| 22:57 | <hober> | jarek: i think it would be fair to say that the web needs a component model, sure |
| 22:57 | <smaug____> | caitp: nope |
| 22:57 | <smaug____> | caitp: and we have put lots of resources to this |
| 22:57 | <rniwa> | jarek: have you read all the specs. for web components? |
| 22:57 | <caitp> | indeed |
| 22:57 | <smaug____> | but perhaps we should have put the resources elsewhere? (just a personal comment ) |
| 22:58 | <hober> | jarek: but that capital-W, capital-C Web Components might not be a very good take on defining that component model |
| 22:58 | <caitp> | is it that web components are not a useful primitive for web developers |
| 22:58 | <caitp> | or is it that the feedback is ignored |
| 22:58 | <caitp> | the former is probably fixable |
| 22:58 | <caitp> | er |
| 22:58 | <caitp> | not former, latter |
| 22:58 | <jarek> | rniwa: nope, only the fragments that I was interested in |
| 22:59 | <rniwa> | jarek, caitp: in my experience, a lot of web developers are excied when they hear the word “web components” because there’s a lot of hype about it |
| 22:59 | <caitp> | whether the former is fixable, I don't know --- I know that we want to be able to use web components in angular, and ember wants them too, and probably the next 30 stupid javascript frameworks will want them to be around |
| 23:00 | <jarek> | caitp: as a frontend web developer I can say that Web Components allowed me to greatly simplify the architecture of my app |
| 23:00 | <rniwa> | but they tell me it’s not exactly what they want when I explain to them the feature set we currently have. |
| 23:00 | <smaug____> | jarek: was "Web Components are critical for Web Platform to take over the app store ecosystems" a copy-paste from somewhere ? |
| 23:00 | <caitp> | honestly I don't think it's even that --- it's like this |
| 23:00 | <rniwa> | jarek: by “Web components”, which features are you talking about? |
| 23:00 | <caitp> | if you open up gmail and inspect the DOM |
| 23:00 | <caitp> | the source code is terrifying |
| 23:00 | <jarek> | smaug____: no, what makes you think so? I know it's a popular opinion |
| 23:01 | <smaug____> | it is? |
| 23:01 | <smaug____> | I don't understand the reasoning |
| 23:01 | <caitp> | if you get people to nicely wrap and encapsulate things, so much better :> |
| 23:01 | <jarek> | smaug____: it was not like I were saying "OMG Apple is trying to take over the world" |
| 23:02 | <jarek> | smaug____: Apple makes money by selling iPhone, and people buy iPhone because of iPhone apps (and hardware) |
| 23:02 | <smaug____> | I might understand some of it if Web Components provided some sort of encapsulation and information hiding so that people could use components from various sources reliably |
| 23:02 | <jarek> | smaug____: fewer iPhone-specific apps means fewer reasons for customers to buy them |
| 23:02 | <rniwa> | jarek: you do remember that the original iPhone only had web apps and developers kept asking for native API, right? |
| 23:02 | <smaug____> | how are Web Components critical to anything? |
| 23:03 | <rniwa> | jarek: but “fewer iPhone-specific apps” isn’t anything to do with web components :( |
| 23:03 | <rniwa> | jarek: you can literally write web apps that are not iPhone specific today. |
| 23:03 | <jarek> | rniwa: that was a minimum viable product |
| 23:03 | <rniwa> | I agree providing some component API in the Web is useful |
| 23:04 | <smaug____> | useful is different than cricital |
| 23:04 | <rniwa> | jarek: but I don’t think the Web components as currently spec’ed is the best way to do it |
| 23:04 | <smaug____> | critical |
| 23:04 | rniwa | nods |
| 23:04 | <jarek> | rniwa: and I find it hard to believe that this is motivated purely by technical reasons :P |
| 23:05 | <caitp> | it's like i said earlier |
| 23:05 | <caitp> | it's developer ergonomics |
| 23:05 | <rniwa> | caitp: right. |
| 23:05 | <othermaciej> | Apple wants web apps to work great and be easy to write on all our platforms. |
| 23:05 | <caitp> | at least, in theory it is |
| 23:05 | <rniwa> | caitp: but I don’t think shadow DOM provides the best developer ergonomics |
| 23:05 | <othermaciej> | Especially so the WebKit team, and we are the ones who decide the details of our web standards strategy. |
| 23:06 | <rniwa> | caitp: it adds a shit ton of complexity to how DOM works and yet doesn’t provide “true” encapsulation. |
| 23:06 | <othermaciej> | caitp: All my developer ergonomics related feedback on Web Components was 100% ignored |
| 23:06 | <caitp> | yeah |
| 23:06 | <othermaciej> | caitp: with reason of, basically, “too late, we’re shipping" |
| 23:06 | <caitp> | i'm not excusing that, i think a better job could have been done there |
| 23:06 | <rniwa> | what it provides is a weak encapsulation you can pierce through with special CSS syntax. |
| 23:06 | smaug____ | believes XBL2 -like approach would have led to easier-to-write components than the current Web Components setup |
| 23:07 | <othermaciej> | caitp: after multiple years of “oh, we’ll get to that later, there’s plenty of time" |
| 23:07 | <caitp> | yeah |
| 23:07 | <rniwa> | smaug____: XBL2 is definitely simpler than web components as it stands today. |
| 23:07 | <othermaciej> | you don’t need a conspiracy theory to explain why that might make us not feel so great about it |
| 23:07 | <othermaciej> | I like that Web Components decomposes the XBL-style model into independent parts |
| 23:07 | <caitp> | but the good news is, if only one vendor uses it, even a massively popular vendor, it's probably not going to take over the web |
| 23:07 | <rniwa> | smaug____: it’s amazing we started from “XBL2 is too damn complicated. let’s create something simpler” and ended up with “well, we need something more complicated than XBL2!" |
| 23:07 | <othermaciej> | I think the biggest flaws are missing parts, bad defaults, and not doing enough to make it work well together |
| 23:08 | <caitp> | so tehre's probably still time to unwreck it |
| 23:08 | <rniwa> | caitp: yeah, after some massive renames LOL |
| 23:08 | <othermaciej> | there’s this weird attitude that clean integration points mean a failure of decomposition |
| 23:09 | <othermaciej> | and to some extent, that direct usability is not important because Web cCmponents should ever be used via a JavaScript framework on top of it |
| 23:10 | <caitp> | we'll find a way, we want to keep getting paid :p |
| 23:11 | <caitp> | nah I am kidding --- the idea is that you add useful application tools on top of the useful component tools |
| 23:11 | <caitp> | which is desirable, I think |
| 23:14 | <roc> | personally I think we're stuck with the Google approach, so my best hope is get the spec and Blink aligned. |
| 23:15 | <jarek> | I find raw Web Components API to be easy enough to be used without frameworks |
| 23:15 | <hober> | roc: i don't think we're stuck with it. |
| 23:16 | <roc> | hober: you think an alternative approach can be specced and implemented and win in the market against Chrome's? |
| 23:16 | <caitp> | in the apple/mozilla/microsoft market? probably |
| 23:16 | <smaug____> | we could change at least those odd defaults web components has |
| 23:16 | <roc> | and furthermore, all that energy and disruption would actually be worth it? |
| 23:16 | <smaug____> | to have proper information hiding and encapsulation |
| 23:17 | <jarek> | smaug____: what do you mean specifically? |
| 23:17 | <jarek> | smaug____: is this something facing the API users? |
| 23:17 | <roc> | having to opt into encapsulation isn't great but it's not a deal-breaker. |
| 23:18 | <smaug____> | jarek: anyone can poke into anyone's shadow dom |
| 23:18 | <smaug____> | and make changes, and that way break components |
| 23:18 | <smaug____> | and if that CSS thing is added, that may happen almost accidentally |
| 23:18 | <caitp> | you mean the shadow piercing selectors? |
| 23:18 | <jarek> | roc: only if he does it intentionally, you can't mess up another component accidentally |
| 23:18 | <caitp> | or a different css thing |
| 23:19 | <jarek> | s/roc/smaug___ |
| 23:19 | <smaug____> | roc: it might be worth so that we, API designers, learn from this mess |
| 23:19 | <jarek> | smaug____: what CSS thing? CSS is fully encapsulated by default (i.e. if you use <style> tag inside shadow DOM) |
| 23:20 | <smaug____> | caitp: is that what it is called |
| 23:20 | <smaug____> | the selector for accessing shadow dom |
| 23:20 | <caitp> | that's what I call it, it seems like a good name |
| 23:21 | <jarek> | smaug____: it could be handy in some rare cases |
| 23:21 | <smaug____> | there is also Event.path (though in the current spec it is not clear what it actually returns ) |
| 23:21 | <jarek> | smaug____: like when you want to force default font |
| 23:23 | <smaug____> | while programming , say C++, want to poke into the implementations of some class? public: isn't the default |
| 23:23 | <caitp> | web developers don't speak C++, they speak javascript and CSS |
| 23:23 | <caitp> | and in those cases, there's no such thing as non-public |
| 23:23 | <caitp> | they'll be fine |
| 23:24 | <smaug____> | well what is then the point with web components? |
| 23:24 | <caitp> | so, I kinda agree on the CSS thing |
| 23:24 | <roc> | smaug____: I really think that having to write a tiny amount of boilerplate to get encapsulation is much less important than just about every other issue here |
| 23:25 | <smaug____> | to get encapsulation? there is no real encapsulation |
| 23:26 | <smaug____> | roc: but sure, I agree the main issue is to get implementation to follow the spec, which means we need to have a spec which can be followed |
| 23:26 | <smaug____> | s/implementation to follow/implementations to follow/ |
| 23:26 | <roc> | sure, we're talking about some future extension which actually provides encapsulation. |
| 23:27 | <jarek> | smaug____: I disagree that 100% encapsulation is always good, there are situations were breaking rules makes perfect sense |
| 23:27 | <smaug____> | jarek: sure, and you opt-in to have weaker encapsulation |
| 23:28 | smaug____ | is not sure shadow dom model bends easily to have better encapsulation |
| 23:28 | <smaug____> | maybe it does. Haven't seen any proposals what the API would look like. |
| 23:30 | <roc> | *that* is an important question. |
| 23:31 | <caitp> | are you familiar with parkinson's law of triviality? |
| 23:33 | <astearns> | caitp: I think we should find a better name for that |
| 23:34 | <caitp> | lets argue about the naming aesthetics then |
| 23:35 | <rniwa> | smaug____: I don’t think we necessarily need 100% encapsulation |
| 23:36 | <rniwa> | smaug____: but not enabing shadow piercing and not exposing shadow root goes a long way towards making components more version-change relilient |
| 23:36 | <rniwa> | smaug____: as thigns stand, it’s so easily for developers to shoot themselves in foot by accessing shadow DOM and pierce through shadow boundaries. |
| 23:36 | <caitp> | that's true, but it would also be really hard for people who want to build frameworks on top of them |
| 23:36 | <smaug____> | I could agree with that. (implementations, if they want to use shadow dom for form elements and such, will need to have 100% encapsulation) |
| 23:36 | <caitp> | we need a shadow root :( |
| 23:36 | <rniwa> | the worst part is that component’s author doesn’t have a control over it :( |
| 23:37 | <rniwa> | so if you build some component, and let other developers use it |
| 23:37 | <rniwa> | then you have no idea if anyone has been piercing through shadow boundries or not. |
| 23:38 | <rniwa> | so from component’s author’s perspective, the current design of web components doesn’t solve one of the biggest problem with Web today |
| 23:38 | <roc> | seems like it would be easy enough to have an opt-in encapsulation attribute that blocks the shadow-piercing combinator and access to the shadow root |
| 23:38 | <rniwa> | as I understand it, non-Apple/Google/Mozilla browser vendor has a serious concern about this as well. |
| 23:39 | <rniwa> | roc: right, that’s what othermaciej suggested ages ago, and we’ve been waiting for it be added to the spec. |
| 23:39 | <rniwa> | roc: and we’ve been arguing that it should be the default. |
| 23:39 | <roc> | I recall a pretty long discussion about this in www-style |
| 23:40 | <caitp> | well i mean what are you going to do, give each shadow tree its own JS sandbox, its own style sandbox, and its own event tree? |
| 23:40 | <rniwa> | roc: instead, none of that gets spec’ed and chrome shipped with the default we publicly objected to |
| 23:40 | <roc> | I recall everyone agreeing that encapsulation control was important |
| 23:40 | <caitp> | that would be expensive |
| 23:40 | <rniwa> | roc: right. |
| 23:40 | <roc> | there was disagreement over the default |
| 23:40 | <rniwa> | caitp: WebKit does that already to implement input, textarea, etc… |
| 23:40 | <roc> | I happen to agree with you about what the default should be, but I don't think the default is important. |
| 23:40 | <rniwa> | caitp: although we don’t have a separate VM since the code is written in C++ |
| 23:40 | <caitp> | yes |
| 23:40 | <rniwa> | caitp: but we can certainly make the creation of VM much cheaper |
| 23:41 | <rniwa> | roc: default may not be the show stopper but if there’s not even an option to turn on real encapsulation |
| 23:41 | <caitp> | even if you do, if you ever want to have communication between those sandboxes, it gets nasty |
| 23:41 | <rniwa> | roc: I don’t see a point in implementing shadow DOM |
| 23:41 | <roc> | there's nothing to stop Apple and Mozilla supporting an encapsulation attribute even if Google doesn't care |
| 23:41 | <rniwa> | caitp: indeed. |
| 23:42 | <rniwa> | caitp: that’s precisely why we’d like to sort out details in that world |
| 23:42 | <rniwa> | caitp: and make sure shadow DOM, custom elements, etc… designs are coherent against such an encapsulation model |
| 23:42 | <rniwa> | caitp: it’s hard to add an encapsulation model on top of a non-encapuslated model. |
| 23:42 | <roc> | that's not necessarily true |
| 23:42 | <roc> | it happens all the time |
| 23:43 | <rniwa> | roc: examples? |
| 23:43 | <caitp> | it's hard to ship an encapsulation module which works but is super slow |
| 23:43 | <caitp> | s/module/model |
| 23:43 | <roc> | C++ extends C |
| 23:43 | <smaug____> | roc: getting XBL1 stuff properly encapsulated in Gecko has taken years |
| 23:43 | <rniwa> | roc: oh sure |
| 23:43 | <smaug____> | well, a decade |
| 23:43 | <rniwa> | roc: but we’ve had a lot of internal discussions about how we can use shadow DOM & custom elements to do real encapsulation |
| 23:44 | <smaug____> | (not that we use XBL1 much for web exposed stuff) |
| 23:44 | <rniwa> | roc: and that required a lot of fundamental design changes |
| 23:44 | <roc> | rniwa: by all means share those results |
| 23:44 | <rniwa> | roc: we already have! |
| 23:44 | <roc> | ok |
| 23:44 | <roc> | I don't really folllow Web Apps so it was probably there |
| 23:45 | <rniwa> | roc: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0418.html |
| 23:45 | <rniwa> | roc: there’s a long discussion following that email |
| 23:46 | <rniwa> | roc, smaug____: all of that feedback was basically ignored/rejected after a long debate in the favor of us spec’ing the non-encapsulated model first, which loudly objected to |
| 23:46 | <rniwa> | we* loudly |
| 23:46 | <rniwa> | I’m more than happy to work with Mozilla and any other vendor to work out details on how to do real encapsulation with shadow DOM |
| 23:47 | <rniwa> | In fact, I’d love if you guys are interested in having such a conversation |
| 23:48 | <rniwa> | but I’ve gotten to a point where I don’t see much value in giving furhter feedback on WebApps given the second we say anything, they basically tell me to go implement and come back. |
| 23:54 | <roc> | rniwa: it looks like you tried to address maciej's "type 3" inverse encapsulation? |
| 23:56 | <roc> | I think that's much less important than type 2 encapsulation. |
| 23:56 | <rniwa> | roc: yeah, sort of. |
| 23:57 | <roc> | and much harder |
| 23:57 | <rniwa> | roc: I’m not certain. type 2 encapsulation is useful for some things |
| 23:59 | <roc> | I think in practice, component-users depending on the details of component implementations is a much bigger problem than components depending on the details of their users. |
| 23:59 | <roc> | especially in terms of DOM structure |
| 23:59 | <rniwa> | roc: well, type 2 doesn’t solve that problem |