Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

[Bronislav Klučka]

On 7.3.2013 19:08, Scott González wrote: This just seems like a big rant. may seem a bit harsh, but I'm trying to compress my point of view, it's not like we can have hours long discussion about pros and cons. i mean no harm :) Your questions about things like should scripts use closures are just derailing the conversation. I'm honestly not sure it's worth replying to any of your points. But to clarify some points I think are relevant: You are right, because someone is trying to kill important (from my point of view) technology: being able to actually create reusable UI libraries. You may think we have those, we do not... Againg from my experience from other languages... I have approx. 200 controls installed in my Delphy from approx. 12 vendors. I can use them in any combination... seamlessly, without caring how are those written (unless pig wrote them). You cannot do that on Web, don't get me wrong I admire jQuery, it's like the alphabet of JS programming. But regardless of how clever people work on it, it's not self contained, it leaks.... where? in DOM/CSS and it collides. It's not possible to expose potions of a DOM. So, if you want any customization at the DOM level, it's all or nothing. You can't expect to expose a JS API on top of a web component that is small and nice to work with and provide the flexibility of having control over the DOM. You can document that your web component provides some hierarchical structure and uses classes in a specific way. Then users can make modifications, for example, injecting additional markup, without breaking the structure or semantics of the existing web component. I'm not advocating for total anarchy. But that is exactly my point. I do not want to expose the whole DOM and then make programmer read tons of docs. about internals because they leak. I cannot imagine to have app using 50 different controls/component from 4 vendors and having to figure out how to make them not clash If it's safe to modify DOM, I make it public. If it's not, than it is not, then do not touch it. As for the <input type="date"> example: This isn't arbitrary 3rd party scripts coming and crippling your DOM in unexpected ways. This is you as the developer of the site saying the native experience is too limiting and then opting in to a different UI. This is also not global, change the world behavior, this is on a per-element basis. well... if the 3rd party control is not fitting to your scenario, don't use it, or rewrite it (if you have the permission). My JS example may seem like distraction to you, but it's actually the same point here yet again. If you find JS class that is almost there,  you have 3 choices: rewrite it, throw it away and find another or write your own. Yes, you are the developer of the site, so you can choose what you want/can use. It's not mandatory for you to use input[type="date"] containing shadow. Pick another, write your own. If it's wrong technology for you, do not use it. But why killing it altogether for anyone? Because someone else wrote something you cannot modify? B. On Thu, Mar 7, 2013 at 12:55 PM, Bronislav Klučka <bronislav.klu...@bauglir.com> wrote: On 7.3.2013 17:51, Scott González wrote: On Wed, Mar 6, 2013 at 3:00 PM, Boris Zbarsky <bzbar...@mit.edu <mailto:bzbar...@mit.edu>> wrote:     On 3/6/13 1:31 PM, Scott González wrote:         but we feel the pros of exposing internals outweigh the cons.     When you say "exposing internals" here, which one of the following     do you mean:     1)  Exposing internals always.     2)  Exposing internals by default, with a way to opt into not     exposing.     3)  Not exposing internals by default, with a way to opt into     exposing. I was replying in the context of jQuery, in which we expose most internals always. There is no option to have jQuery hide it's internals.     And what do you feel the pros are of whichever one you're talking     about compared to the items after it on the list, just so we're on     the same page? In terms of web components, I'm not sure I (or anyone else on the jQuery team) have too strong of an opinion on the default. However, I can say that I find it extremely annoying that I can't reach into the Shadow DOM for new input types and just kill everything. I want <input type="date"> to render as <input type="text"> because native HTML will likely never be as flexible as custom JS components. Obviously I'd prefer a standard, and web components are supposed to solve this. But in the meantime, we're provided with useful semantics and validation that go unused if you want the flexibility of a JS date picker. As someone building JS components, I see the benefit of having the internals exposed to me so I can do as I please. I also recognize the pain of maintaining code that reaches into internals. As someone who cares about the future of the web, I see the very real danger of this becoming widespread and ending up in the situation Boris wants us to avoid. I do not mean to sound cocky here, but I'd really like to know how many people here are used to languages that can separate internals and externals, because if you are simply not used to it, you simply cannot see the benefits and all goes to "I'm used to play with internals of controls", regardless how wrong it is. I mean it's like discussion of introducing private properties of an class and someone complaining that he/she is used to touch everything he/she desires. I find it hard to explain how wrong that simply is. You do not touch anything else than external API provided by opaque blackbox. As someone building components in several languages not being able to hide certain things is scary to me. I mean why do we wrap JS code in anonymous functions? (function(){ //place code here })(); well.. are you advocating in jQuery not to do that? Because someone wants to play with internals? are you advocating that it does not matter what can anyone change in jQuery internals or what can leak from jQuery internals to outside space? - "well he/she likes to play, let him/her, and if anything brakes down, his/hers fault, and by the way he/she have to be especially careful not to use variable names we are using already , functions as well... but he/she gets used to it" - I mean where is the difference here? Just open jQuery code... bunch of internal variables... why are those not public? Again, how can you advocate for non-private DOM while working in script that is whole private... just exposing the necessary. And thanks for making my point, if my control depends on <input type=date> I do not want some external script to cripple it! I opened jQuery datepicker source code (you seem to like it, I cannot tell you how glad I am for Chrome date picker that I can finally get rid of jQ datepicker [and jQ altogether])... so many private variables... should I repeat myself? Where is the difference? Apparently even jQuery team does not care whether programers wants to play with everything, but cares about that fact, that you can plug jQuery anywhere and it will not break by outside scripts and that outside space will not break by jQuery. And that's what I'm expecting from ShadowDOM = controls you insert and they work, no side effects what so ever. From my JS/HTML control experience? * I want all my tables to look certain way - boom jQury datepicker brokes down, tinyMCE brokes down * I want all my tables to have and option for exporting data - boom jQury datepicker brokes down, tinyMCE brokes down * I switch from content-box to border-box - pretty much every 3rd party control breaks down * I want to autogenerate table of contents (page menu links) from headings in the article, f*ck, some stupid plugin gets involved that's like the last week experience I mean why do I have to spend time learning *internals* of controls in HTML? Why do I have to look to what class names that control is using not to break thinks? etc. And I can go on and on and on... I mean there are people who see the clear borders as benefit for their work. Why not giving them this option (considering HTML/JS controls are like the only major language constructed controls without this option... are .NET, Java, Delphi, C++ Builder etc. so wrong? all of them?). You do not like it? Don't use it. B. -- s pozdravem Bronislav Klučka http://www.bauglir.com bronislav.klu...@bauglir.com * webové aplikace * software na zakázku