[webcomponents] Missing First Principle in overall Design (bugzilla: 22836) (#231)

Title: Missing First Principle in overall Design (bugzilla: 22836)

Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22836

----
comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22836#c0
*Shark* wrote on 2013-07-30 06:51:19 +0000.

Every tech concept/architecture should derived from single First Principle, so that the concept/architecture is compact, consistent and easy to understand in future evolution. 
Per my understanding, component model(web components) tries to model the UI to get UI better structured and reused. And we need a First Principle to guide this. 
I think the most suitable First Principle here can be Object Oriented. 
E.g. Custom Elements try to make html elements object oriented (support element encapsulation and extend)
Shadow DOM try to make dom tree object oriented(support dom tree encapsulation and extend)
So base on above statement, I think we should have a better name for Shadow DOM, since this name can not reflect its core value & feature. 
Also the same for the method to start shadow dom (ele.createShadowRoot).

----

comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22836#c1
*Dominic Cooney* wrote on 2013-07-30 11:56:14 +0000.

(In reply to comment #0)
> Every tech concept/architecture should derived from single First Principle,
> so that the concept/architecture is compact, consistent and easy to
> understand in future evolution.

This is an interesting idea. I'm not sure that I agree it has to be just one, but let me think about it.
 
> Per my understanding, component model(web components) tries to model the UI
> to get UI better structured and reused. And we need a First Principle to
> guide this.

The experience from early adopters is that Web Components is useful UI and for much more. UI is something relatively concrete that many web developers have experience with so it is a good place to start explaining Web Components. Maybe we should make another try at explaining the more general idea.

> I think the most suitable First Principle here can be Object Oriented. 
> E.g. Custom Elements try to make html elements object oriented (support
> element encapsulation and extend)

I think object orientation is a bad metaphor; the composition of Custom Elements is pretty different to objects. Although the ideas about encapsulation and reuse are pretty close to the mark.

> Shadow DOM try to make dom tree object oriented(support dom tree
> encapsulation and extend)
> So base on above statement, I think we should have a better name for Shadow
> DOM, since this name can not reflect its core value & feature. 

Do you have a suggestion for what this name would be?

> Also the same for the method to start shadow dom (ele.createShadowRoot).

----

comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22836#c2
*Shark* wrote on 2013-07-30 15:05:40 +0000.

(In reply to comment #1)
Hi Dominic, 

First of all thanks for your reply. 
Since I am not from English language country, please pardon my poor English. 

> (In reply to comment #0)
> > Every tech concept/architecture should derived from single First Principle,
> > so that the concept/architecture is compact, consistent and easy to
> > understand in future evolution.
> 
> This is an interesting idea. I'm not sure that I agree it has to be just
> one, but let me think about it.

To supplement this point: Due to the furture uncertainty, the evolution is uncontrolable. It's not possible to guarantee that there is no clash between concepts derived from different FP.


> > Per my understanding, component model(web components) tries to model the UI
> > to get UI better structured and reused. And we need a First Principle to
> > guide this.
> 
> The experience from early adopters is that Web Components is useful UI and
> for much more. UI is something relatively concrete that many web developers
> have experience with so it is a good place to start explaining Web
> Components. Maybe we should make another try at explaining the more general
> idea.
> 

Agree, at least newbies like me prefer to know the undergroud idea for the innovation.  

> > I think the most suitable First Principle here can be Object Oriented. 
> > E.g. Custom Elements try to make html elements object oriented (support
> > element encapsulation and extend)
> 
> I think object orientation is a bad metaphor; the composition of Custom
> Elements is pretty different to objects. Although the ideas about
> encapsulation and reuse are pretty close to the mark.
> 

Object is a conceptual glossary, also object orientation, it should not bind to some specific tech. During design process, if with the idea in mind, you can say it's object oriented. To extend this, we can use object oriented in design/architecture in industries other than software. 
Practice proved that Object oriented is a good design approach comforming to nature. I insist that it should suitable here. 


> > Shadow DOM try to make dom tree object oriented(support dom tree
> > encapsulation and extend)
> > So base on above statement, I think we should have a better name for Shadow
> > DOM, since this name can not reflect its core value & feature. 
> 
> Do you have a suggestion for what this name would be?
> 

We can say younger Shadow DOM extend older Shadow DOM/original DOM, and this younger Shadow DOM can customiz/reuse the parent DOM's structure(hide/expose parent DOM's contents), now this is doable via \<content\> & \<shadow\>. And of course itself can be extend. 
Here I only can explain my understanding here, I can not find a English word to precisely express it. Sorry again for my poor English. 


> > Also the same for the method to start shadow dom (ele.createShadowRoot).

The current api to start the shadow dom can be replace by something like: extend()?

----

comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22836#c3
*Dominic Cooney* wrote on 2014-01-20 02:48:34 +0000.

How is "define widgets with a level of visual richness and interactivity not possible with CSS alone, and ease of composition and reuse not possible with script libraries today" as an overarching principle?

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/231