When using Ranges to try to navigate content, I'm finding that it would be
useful to be able to decompose a Range in sub-Ranges that correspond to the
rects returned from getClientRects(). In particular, this would make it
easier to find line-breaks.
Thoughts?
Cheers,
Justin
On Thu, Mar 26, 2015 at 10:53 AM, Travis Leithead <
travis.leith...@microsoft.com> wrote:
> Hi folks,
>
>
>
> Today’s ShadowDOM model is designed around only adding shadow roots to
> element in the ‘light side’. I assume this is intentional, but was hoping
> someone could describe why this design
On Thu, Mar 26, 2015 at 11:36 AM, Travis Leithead <
travis.leith...@microsoft.com> wrote:
> > From: Justin Fagnani [mailto:justinfagn...@google.com]
> >> Elements expose this “shadow node list” via APIs that are very similar
> to
> >> existing node list ma
I do want the ability to redirect distributed nodes into a holes in the
base template, so that part is welcome to me. However, my first reaction to
the slot idea is that forcing users to add the content-slot attribute on
children significantly impairs the DOM API surface area of custom elements.
F
On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa wrote:
>
> > On Apr 21, 2015, at 10:23 PM, Justin Fagnani
> wrote:
> >
> > I do want the ability to redirect distributed nodes into a holes in the
> base template, so that part is welcome to me. However, my first reaction
).
Could slots have multiple names to support something like this?
On Wed, Apr 22, 2015 at 10:16 AM, Justin Fagnani
wrote:
>
>
> On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa wrote:
>
>>
>> > On Apr 21, 2015, at 10:23 PM, Justin Fagnani
>> wrote:
>> >
On Wed, Apr 22, 2015 at 2:37 PM, Ryosuke Niwa wrote:
>
> On Apr 22, 2015, at 10:16 AM, Justin Fagnani
> wrote:
>
>
>
> On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa wrote:
>
>>
>> > On Apr 21, 2015, at 10:23 PM, Justin Fagnani
>> wrote:
>> &
On Wed, Apr 22, 2015 at 4:40 PM, Jan Miksovsky
wrote:
> Hi Tab,
>
> Thanks for your feedback!
>
> A primary motivation for proposing names instead of CSS selectors to
> control distribution is to enable subclassing. We think it’s important for
> a subclass to be able to override a base class inse
On Sun, Apr 26, 2015 at 11:05 PM, Anne van Kesteren
wrote:
> On Sat, Apr 25, 2015 at 10:49 PM, Ryosuke Niwa wrote:
> > One major drawback of this API is computing insertionList is expensive
> > because we'd have to either (where n is the number of nodes in the shadow
> > DOM):
> >
> > Maintain a
On Mon, Apr 27, 2015 at 1:01 AM, Anne van Kesteren wrote:
> On Mon, Apr 27, 2015 at 9:25 AM, Justin Fagnani
> wrote:
> > I really don't think the platform needs to do anything to support
> > subclassing since it can be done so easily at the library level now that
>
On Tue, Apr 28, 2015 at 4:32 PM, Ryosuke Niwa wrote:
> On Apr 27, 2015, at 4:23 PM, Tab Atkins Jr. wrote:
>
> On Mon, Apr 27, 2015 at 4:06 PM, Tab Atkins Jr.
> wrote:
>
> On Mon, Apr 27, 2015 at 3:42 PM, Ryosuke Niwa wrote:
>
> On Apr 27, 2015, at 3:15 PM, Steve Orvell wrote:
> IMO, the appea
Here's one case of redistribution:
https://github.com/Polymer/core-scaffold/blob/master/core-scaffold.html#L122
Any time you see inside a custom element it's potentially
redistribution. Here there's on that is (line 122), and one that could be
(line 116), and one that definitely isn't (line 106).
On Wed, May 6, 2015 at 8:25 AM, Anne van Kesteren wrote:
> On Wed, May 6, 2015 at 4:34 PM, Dimitri Glazkov
> wrote:
> > This is https://www.w3.org/Bugs/Public/show_bug.cgi?id=24866.
> >
> > The way I remember it, the argument went like this: the most common use
> case
> > for this callback is to
If I'm understanding your proposal correctly, wouldn't this limit any
document to have a single subclass per native element?
How would you express:
Me
You
-Justin
On Fri, May 8, 2015 at 12:56 PM, Travis Leithead <
travis.leith...@microsoft.com> wrote:
> The 'is' attribute is only a declarative
ight have both iron-button and
paper-button. There would be no chance for that with native element
extensions without is="".
>
>
> *From:* Justin Fagnani [mailto:justinfagn...@google.com]
> *Sent:* Friday, May 8, 2015 1:06 PM
> *To:* Travis Leithead
> *Cc:* Ryosuke N
Like we pointed out in the previous thread, adding enough special cases to
slots leads to select.
At this point we're much more interested in agreeing on something rather
than nothing.
On Mon, May 18, 2015 at 3:58 PM, Domenic Denicola wrote:
> I was thinking opposed. I don’t see any reason to i
On Mon, May 18, 2015 at 4:58 PM, Philip Walton
wrote:
> Pardon my question if this has been discussed elsewhere, but it's not
> clear from my reading of the "slots" proposal whether they would be allowed
> to target elements that are not direct children of the component.
>
> I believe the with th
fer select, but this is a compromise to enable progress.
>
> From: Elliott Sprehn
> Sent: Monday, May 18, 21:03
> Subject: Re: [webcomponents] How about let's go with slots?
> To: Justin Fagnani
> Cc: Philip Walton, Domenic Denicola, Daniel Freedman, Dimitri Glazkov,
&g
And I'm still concerned that removing is= would severely harm the cases
where you need access to special parsing behavior like and
On Jun 9, 2015 8:45 AM, "Dimitri Glazkov" wrote:
>
> On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren
wrote:
>>
>>
>> > - v1 sets the stage for people to develop habits and expectations
about how
>> > custom elements work. New features tend to be slowly adopted, by both
>> > browser vendors and
We also have an extension of form which collects values from both native
and custom inputs.
On Thu, Jun 11, 2015 at 1:41 PM, Joshua Peek wrote:
> GitHub has been using tag extensions in a few places for progressive
> enhancement. Form and button elements have been the most useful things
> to ext
You can also override addEventListener/removeEventListener on your element.
My concern with that, and possibly an event listener change callback, is
that it only works reliably for non-bubbling events.
On Thu, Nov 5, 2015 at 4:16 PM, Travis Leithead <
travis.leith...@microsoft.com> wrote:
> Inter
On Fri, Nov 6, 2015 at 12:44 PM, Olli Pettay wrote:
> On 11/06/2015 09:28 PM, Justin Fagnani wrote:
>
>> You can also override addEventListener/removeEventListener on your
>> element. My concern with that, and possibly an event listener change
>> callback, is
>> t
On Fri, Apr 22, 2016 at 8:24 PM, Anne van Kesteren wrote:
> On Sat, Apr 23, 2016 at 3:08 AM, /#!/JoePea wrote:
> > I really believe that we should be allowed to name our elements with any
> > name we wish, and that they should override native elements (that is
> future
> > proof), and that overr
24 matches
Mail list logo
