[Bug 22836] Missing First Principle in overall Design

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

--- Comment #2 from Shark <xfcjscn@gmail.com> ---
(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()?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 30 July 2013 15:05:45 UTC