[Bug 25423] New: [Shadow]: event.path should return every nodes in the event path, instead of erasing nodes on descendant trees.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25423 Bug ID: 25423 Summary: [Shadow]: event.path should return every nodes in the event path, instead of erasing nodes on descendant trees. Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: hay...@chromium.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14978 It might be useful that we just expose every nodes in the event path in event.path API, instead of filtering out nodes on descendant trees. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Separating Transclusion Mechanisms for Inheritance and Data Binding
*claps for sharing JSBin* Would love to see more of this on public-webapps when possible :) On Tue, Apr 22, 2014 at 10:46 AM, Dimitri Glazkov wrote: > BTW, here's a jsbin that implements yield/transclude using existing Shadow > DOM plumbing: > > http://jsbin.com/pacim/1/edit > > :DG< >
Re: Separating Transclusion Mechanisms for Inheritance and Data Binding
Here's a jsbin that uses the shadow-as-function syntax and does the same thing: http://jsbin.com/peqoz/2/edit :DG< On Tue, Apr 22, 2014 at 10:46 AM, Dimitri Glazkov wrote: > BTW, here's a jsbin that implements yield/transclude using existing Shadow > DOM plumbing: > > http://jsbin.com/pacim/1/edit > > :DG< >
Re: Separating Transclusion Mechanisms for Inheritance and Data Binding
BTW, here's a jsbin that implements yield/transclude using existing Shadow DOM plumbing: http://jsbin.com/pacim/1/edit :DG<
Re: Separating Transclusion Mechanisms for Inheritance and Data Binding
On Thu, Apr 17, 2014 at 2:42 AM, Ryosuke Niwa 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:
>
> Ryosuke Niwa
> rn...@apple.com
>
>
> Suppose this element's shadow DOM looks like this:
> Name:
> Email:
>
> 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:
>
>
> Name:
>
> Ryosuke Niwa
>
>
> Email:
>
> rn...@apple.com
>
>
>
>
>
> 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:
>
> WebKitten
>
> kit...@webkit.org
>
>
> If I had an instance of my-webkitten-card as follows:
>
> Ryosuke Niwa
> rn...@webkit.org
>
>
> Then its composed tree will look like this:
>
>
>
>
> Name:
>
> WebKitten
> Ryosuke Niwa
>
>
> Email:
>
> rn...@webkit.org
> kit...@webkit.org
>
>
>
>
>
>
>
> 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:
>
>
>
>
>
> Name:
>
>
> WebKitten
>
>
> Email:
>
>
> kit...@webkit.org
>
>
>
>
>
>
>
> *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 %}
> {% block left %}{% endblock %}
> {% block right %} This is more content {% endblock
> %}
>
> And we render this template:
>
> {% extends "parent.html" %}
> {% block left %}This is the left side!{% endblock %}
> {% block right %}This is the right side!{% endblock %}
>
> The output would be:
>
> This is the default content
> This is the left side!
> This is the right side!
>
>
> *Alternative Approach to Inhertiance*
>
> Consider random-element which picks a random child node to show whenever a
> user clicks on the element. This element may show the name of probability
> distribution it uses to pick a child in its shadow DOM. The name of the
> probability distribution is in the definitions of subclasses of
> random-element, and not in the light DOM of this custom element. If we
> wanted to use the current inheritance model (multiple generations of shadow
> DOM & shadow element), we have to either replace the entire shadow DOM in
> the subclass to show the name of the probability distribution that
> subclasses use or add an attribute, etc… to identify the element that
> contains the name of probability distribution inside subclasses' shadow
> element. The latter would be weird because there is nothing preventing from
> the user of random-element to put an element that matches the same selector
> as a child of random-element in the "light DOM".
>
> Here, we propose an alternative approach. We introduce a new "yield"
> element to be used in the superclass define a
Re: Separating Transclusion Mechanisms for Inheritance and Data Binding
On Thu, Apr 17, 2014 at 2:42 AM, Ryosuke Niwa 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:
>
> Ryosuke Niwa
> rn...@apple.com
>
>
> Suppose this element's shadow DOM looks like this:
> Name:
> Email:
>
> 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:
>
>
> Name:
>
> Ryosuke Niwa
>
>
> Email:
>
> rn...@apple.com
>
>
>
>
>
> 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:
>
> WebKitten
>
> kit...@webkit.org
>
>
> If I had an instance of my-webkitten-card as follows:
>
> Ryosuke Niwa
> rn...@webkit.org
>
>
> Then its composed tree will look like this:
>
>
>
>
> Name:
>
> WebKitten
> Ryosuke Niwa
>
>
> Email:
>
> rn...@webkit.org
> kit...@webkit.org
>
>
>
>
>
>
>
> 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:
>
>
>
>
>
> Name:
>
>
> WebKitten
>
>
> Email:
>
>
> kit...@webkit.org
>
>
>
>
>
>
>
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.
:DG<
[admin] public-webapps-testsuite is now Closed
As discussed a few weeks ago, public-webapps-testsuite is now closed and all previous subscribers have been unsubscribed. For all testing related discussions specific to WebApps, please use the public-webapps list and infrastructure type discussions, please use the public-test-infra list. -Thanks, AB
Re: [charter] Addressable Ranges?
Hi, Art– There are different approaches that could be taken, but one concrete implementation in JavaScript is from the Hypothes.is Annotator [1]. https://hypothes.is/blog/fuzzy-anchoring/ Regards– –Doug On 4/22/14 9:04 AM, Arthur Barstow wrote: Hi Doug, Do you have some prior art/work for this functionality (that could help people get a bit deeper understanding of the proposal)? All - if you have any feedback - both positive/+1 or negative - please do speak up by April 25 at the latest. -Thanks, AB On 4/18/14 3:45 PM, Doug Schepers wrote: Hi, folks– I'd like to ask for feedback on the notion of adding "addressable ranges" to the WebApps WG charter. There are a set of use cases for being able to link to a specific passage of text in a document, which has a number of what I consider hard problems: * the passage might cross element boundaries * someone linking into the document usually doesn't have write access to the document such that they can insert permanent markers into the text * documents might change: the passage may have moved, been slightly altered, or even been completely removed * many other considerations (including single-page vs. multi-page versions of the same document, near-duplicates of the document at different URLs, etc.) I bring this to the WebApps WG for a couple reasons: * there are related deliverables and discussions already underway, including the new Selections API work from Niwa, the Clipboard API work, and the discussions around a Find API * if this is ever going to happen, this is the right community of developers and browser vendors to discuss the different challenges and possibilities This work might take a while before we consider it ready for serious consideration for implementation and deployment in browsers, but I'd like to start the conversation now so we can keep this in mind while developing related features, and build toward some tangible outcome in the not-too-distant future. Because finding a solution to this would be a major goal of the proposed Web Annotations WG, it would be nice if this could be a joint deliverable of both groups. While we propose to have the conversation on public-webapps (for the widest and most critical review), the Web Annotations WG will provide an Editor and a Test Lead, and we would prefer to have a co-Editor from WebApps. Regards- -Doug
Re: [charter] Addressable Ranges?
Hi Doug, Do you have some prior art/work for this functionality (that could help people get a bit deeper understanding of the proposal)? All - if you have any feedback - both positive/+1 or negative - please do speak up by April 25 at the latest. -Thanks, AB On 4/18/14 3:45 PM, Doug Schepers wrote: Hi, folks– I'd like to ask for feedback on the notion of adding "addressable ranges" to the WebApps WG charter. There are a set of use cases for being able to link to a specific passage of text in a document, which has a number of what I consider hard problems: * the passage might cross element boundaries * someone linking into the document usually doesn't have write access to the document such that they can insert permanent markers into the text * documents might change: the passage may have moved, been slightly altered, or even been completely removed * many other considerations (including single-page vs. multi-page versions of the same document, near-duplicates of the document at different URLs, etc.) I bring this to the WebApps WG for a couple reasons: * there are related deliverables and discussions already underway, including the new Selections API work from Niwa, the Clipboard API work, and the discussions around a Find API * if this is ever going to happen, this is the right community of developers and browser vendors to discuss the different challenges and possibilities This work might take a while before we consider it ready for serious consideration for implementation and deployment in browsers, but I'd like to start the conversation now so we can keep this in mind while developing related features, and build toward some tangible outcome in the not-too-distant future. Because finding a solution to this would be a major goal of the proposed Web Annotations WG, it would be nice if this could be a joint deliverable of both groups. While we propose to have the conversation on public-webapps (for the widest and most critical review), the Web Annotations WG will provide an Editor and a Test Lead, and we would prefer to have a co-Editor from WebApps. Regards- -Doug
Re: [selection] [editing] Selection API Bugzilla is available
On Mon, Apr 21, 2014 at 9:19 PM, Ben Peters wrote: > The Selection API Bugzilla component [1] is now available for bugs in the > Selection API spec [2]. I propose that we move selection-related bugs from > the HTML Editing APIs spec [3] to this new component. Are there any > objections? If not, we will be moving some bugs over (in case you're tracking > them). Please go ahead. Thanks!
[Bug 13909] Selections have three possible directions, not two
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13909 Ryosuke Niwa changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Ryosuke Niwa --- I've fixed this when I ported the specification: http://rniwa.github.io/selection-api.html#dfn-direction "Each selection has a direction, forwards, backwards, or directionless. If the user creates a selection by indicating first one boundary point of the range and then the other (such as by clicking on one point and dragging to another), and the first indicated boundary point is after ([DOM4]) the second, then the corresponding selection must initially be backwards. If the first indicated boundary point is before ([DOM4]) the second, then the corresponding selection must initially be forwards. Otherwise, it must be directionless." -- You are receiving this mail because: You are on the CC list for the bug.
