[Bug 25484] New: [Explainer]: Example querySelectors need to select IDs
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25484
Bug ID: 25484
Summary: [Explainer]: Example querySelectors need to select IDs
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Component Model
Assignee: dglaz...@chromium.org
Reporter: gsf...@gmail.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 14949
This section should instead select #hh, #sep, and #mm:
this._root.querySelector('hh').textContent = fmt(now.getHours());
this._root.querySelector('sep').style.visibility =
now.getSeconds() % 2 ? 'visible' : 'hidden';
this._root.querySelector('mm').textContent = fmt(now.getMinutes());
--
You are receiving this mail because:
You are on the CC list for the bug.
Re: Separating Transclusion Mechanisms for Inheritance and Data Binding
On Apr 22, 2014, at 10:22 AM, Dimitri Glazkov dglaz...@chromium.org wrote:
On Thu, Apr 17, 2014 at 2:42 AM, Ryosuke Niwa rn...@apple.com wrote:
Review: Template Inheritance in the Current Specification
In the current specification, a super class doesn't define any hooks for
subclasses. Instead, it defines insertion points into which nodes from the
original DOM (light DOM) is inserted, and then subclasses use shadow
element to replace elements that get distributed into superclass's insertion
points.
Consider my-card element used as follows:
my-card
span class=nameRyosuke Niwa/span
span class=emailrn...@apple.com/span
/my-card
Suppose this element's shadow DOM looks like this:
Name: content select=.name/content
Email: content select=.email/content
Then in the composed tree, the first span is distributed into the first
content element and the second span is distributed into the second content
element as follows:
my-card
!-- shadow root begin --
Name: content select=.name
!-- distribution begin --
span class=nameRyosuke Niwa/span
!-- distribution end --
/content
Email: content select=.email
!-- distribution begin --
span class=emailrn...@apple.com/span
!-- distribution end --
/content
!-- shadow root end --
/my-card
If I had my-webkitten-card that always as WebKitten as a name that inherits
from my-card, its shadow DOM may look like this:
shadow
span class=nameWebKitten/span
content/content
span class=emailkit...@webkit.org/span
/shadow
If I had an instance of my-webkitten-card as follows:
my-webkitten-card
span class=nameRyosuke Niwa/span
span class=emailrn...@webkit.org/span
/my-webkitten-card
Then its composed tree will look like this:
my-webkitten-card
!-- my-webkitten-card's shadow root begin --
shadow
!-- my-card's shadow root begin --
Name: content select=.name
!-- distribution begin --
span class=nameWebKitten/span
span class=nameRyosuke Niwa/span
!-- distribution end --
/content
Email: content select=.email
!-- distribution begin --
span class=emailrn...@webkit.org/span
span class=emailkit...@webkit.org/span
!-- distribution end --
/content
!-- my-card's shadow root end --
/shadow
!-- my-webkitten-card's shadow root end --
/my-webkitten-card
Here, my-card's shadow DOM was inserted into where the shadow element existed
in my-webkitten-card's shadow DOM, and the insertion points inside my-card's
shadow DOM got nodes distributed from shadow element's children including
nodes inside content element. If we didn't have the content element inside
my-webkitten-card with name and email classes, then we would only see
WebKitten and kit...@webkit.org distributed into my-card's insertion points
as in:
my-webkitten-card
!-- my-webkitten-card's shadow root begin --
shadow
!-- my-card's shadow root begin --
Name:
content select=.name
!-- distribution begin --
span class=nameWebKitten/span
!-- distribution end --
/content
Email:
content select=.email
!-- distribution begin --
span class=emailkit...@webkit.org/span
!-- distribution end --
/content
!-- my-card's shadow root end --
/shadow
!-- my-webkitten-card's shadow root end --
/my-webkitten-card
Separating Transclusion Mechanisms for Inheritance and Data Binding
The current model mixes data binding and inheritance if we consider
distributing nodes from the light DOM as a form of data binding. Namely,
distributing nodes from my-card's or my-webkitten-card's light DOM is data
binding where the data model is DOM whereas distributing nodes from
my-webkitten-card's shadow element into my-card's insertion points is an
inheritance hook.
Furthermore, the transclusion mechanism for inheritance happens backwards.
Instead of a superclass defining a transclusion points for its subclasses to
use, the subclasses are overriding the meaning of insertion points in the
superclass by injecting nodes. This is how existing JS libraries and
frameworks do template inheritance.
For example, the following two JS template libraries that support inheritance
both allow superclass template to define named blocks that could be
overridden by subclass templates:
http://paularmstrong.github.io/swig/docs/#inheritance
http://jlongster.github.io/nunjucks/templating.html#template-inheritance
An example from Nunjucks:
If we have a template parent.html that looks like this:
{% block header %}
This is the default content
{% endblock %}
section class=left
{% block left %}{% endblock %}
/section
section class=right
{% block right %}
This is more content
{% endblock %}
Re: Separating Transclusion Mechanisms for Inheritance and Data Binding
On Apr 22, 2014, at 10:13 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Thu, Apr 17, 2014 at 2:42 AM, Ryosuke Niwa rn...@apple.com wrote: Review: Template Inheritance in the Current Specification In the current specification, a super class doesn't define any hooks for subclasses. Instead, it defines insertion points into which nodes from the original DOM (light DOM) is inserted, and then subclasses use shadow element to replace elements that get distributed into superclass's insertion points. Consider my-card element used as follows: my-card span class=nameRyosuke Niwa/span span class=emailrn...@apple.com/span /my-card Suppose this element's shadow DOM looks like this: Name: content select=.name/content Email: content select=.email/content Then in the composed tree, the first span is distributed into the first content element and the second span is distributed into the second content element as follows: my-card !-- shadow root begin -- Name: content select=.name !-- distribution begin -- span class=nameRyosuke Niwa/span !-- distribution end -- /content Email: content select=.email !-- distribution begin -- span class=emailrn...@apple.com/span !-- distribution end -- /content !-- shadow root end -- /my-card If I had my-webkitten-card that always as WebKitten as a name that inherits from my-card, its shadow DOM may look like this: shadow span class=nameWebKitten/span content/content span class=emailkit...@webkit.org/span /shadow If I had an instance of my-webkitten-card as follows: my-webkitten-card span class=nameRyosuke Niwa/span span class=emailrn...@webkit.org/span /my-webkitten-card Then its composed tree will look like this: my-webkitten-card !-- my-webkitten-card's shadow root begin -- shadow !-- my-card's shadow root begin -- Name: content select=.name !-- distribution begin -- span class=nameWebKitten/span span class=nameRyosuke Niwa/span !-- distribution end -- /content Email: content select=.email !-- distribution begin -- span class=emailrn...@webkit.org/span span class=emailkit...@webkit.org/span !-- distribution end -- /content !-- my-card's shadow root end -- /shadow !-- my-webkitten-card's shadow root end -- /my-webkitten-card Here, my-card's shadow DOM was inserted into where the shadow element existed in my-webkitten-card's shadow DOM, and the insertion points inside my-card's shadow DOM got nodes distributed from shadow element's children including nodes inside content element. If we didn't have the content element inside my-webkitten-card with name and email classes, then we would only see WebKitten and kit...@webkit.org distributed into my-card's insertion points as in: my-webkitten-card !-- my-webkitten-card's shadow root begin -- shadow !-- my-card's shadow root begin -- Name: content select=.name !-- distribution begin -- span class=nameWebKitten/span !-- distribution end -- /content Email: content select=.email !-- distribution begin -- span class=emailkit...@webkit.org/span !-- distribution end -- /content !-- my-card's shadow root end -- /shadow !-- my-webkitten-card's shadow root end -- /my-webkitten-card Can you help me understand the problems you illustrated with the examples better? What's the desired behavior? Where does the problem arise? This is both for my-webkitten-card and for random-element examples. I would love to have these to start chewing on them. Sorry, maybe my description wasn't clear. This example doesn't demonstrate any issues. I was simply describing what the current specification does. - R. Niwa
Re: Separating Transclusion Mechanisms for Inheritance and Data Binding
On Apr 22, 2014, at 10:46 AM, Dimitri Glazkov dglaz...@chromium.org wrote: BTW, here's a jsbin that implements yield/transclude using existing Shadow DOM plumbing: http://jsbin.com/pacim/1/edit Thanks for an example. That indeed polyfills the API we're proposing in terms of the currently spec'ed API. One important aspect of our proposal is to avoid having to rely on shadowRoot property on HTMLElement, which wouldn't exist in Type III encapsulation. On Apr 22, 2014, at 11:06 AM, Dimitri Glazkov dglaz...@chromium.org wrote: Here's a jsbin that uses the shadow-as-function syntax and does the same thing: http://jsbin.com/peqoz/2/edit This one doesn't quite work as intended in that the insertion points in MyCardElement's shadow DOM could grab nodes from the light DOM. - R. Niwa
