Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

This just seems like a big rant. 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:

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.

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.



On Thu, Mar 7, 2013 at 12:55 PM, Bronislav Klučka <
Bronislav.Klucka@bauglir.com> wrote:

>
> 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.
>
>