- From: Bronislav Klučka <Bronislav.Klucka@bauglir.com>
- Date: Thu, 07 Mar 2013 19:37:50 +0100
- To: public-webapps <public-webapps@w3.org>
- Message-ID: <5138DE7E.90707@bauglir.com>
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.Klucka@bauglir.com <mailto: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>
> <mailto: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.
>
>
--
s pozdravem
Bronislav Klučka
http://www.bauglir.com <http://www.bauglir.com>
http://www.bauglir.com
Bronislav.Klucka@bauglir.com <mailto:Bronislav.Klucka@bauglir.com>
* webové aplikace
* software na zakázku
Received on Thursday, 7 March 2013 18:38:18 UTC