Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 7.3.2013 17:51, Scott González wrote:
> On Wed, Mar 6, 2013 at 3:00 PM, Boris Zbarsky <bzbarsky@mit.edu 
> <mailto:bzbarsky@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.

Received on Thursday, 7 March 2013 17:55:43 UTC