[Bug 13909] Selections have three possible directions, not two
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13909 Ryosuke Niwa rn...@webkit.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Ryosuke Niwa rn...@webkit.org --- 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.
Re: [selection] [editing] Selection API Bugzilla is available
On Mon, Apr 21, 2014 at 9:19 PM, Ben Peters ben.pet...@microsoft.com 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!
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
[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: Separating Transclusion Mechanisms for Inheritance and Data Binding
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. :DG
Re: Separating Transclusion Mechanisms for Inheritance and Data Binding
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
%}/section
And we render this template:
{% extends parent.html %}
{% block left %}This is the left side!{% endblock %}
{% block right
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
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 dglaz...@chromium.orgwrote: 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
*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 dglaz...@chromium.orgwrote: BTW, here's a jsbin that implements yield/transclude using existing Shadow DOM plumbing: http://jsbin.com/pacim/1/edit :DG
[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.
