; On Fri, Mar 8, 2013 at 12:22 PM, Steve Orvell wrote:
> > I also find the name confusing. It's common to use the term 'component'
> when
> > describing the functionality of a custom element.
> >
> > What about "HTML Modules"?
>
> Then we probably need to rename link rel="module" for consistency?
>
> :DG<
>
>
> Also, it sounds like this specification should be titled "Fetching
> components" or some such as that's about all it defines.
I also find the name confusing. It's common to use the term 'component'
when describing the functionality of a custom element.
What about "HTML Modules"?
On Fri, Ma
The word "component" will be used as a synonym for a custom element. Since
this spec is designed to load various html resources that may include
custom element definitions, attaching the word component to this spec is
just confusing.
We're loading html so rel="html" is most straightforward. The na
f some sort of "import" or
> "include", especially seeing that
> other web developers are aligned with this lingo.
>
> My 0$.02
>
>
>
> On Wed, Mar 27, 2013 at 11:29 AM, Steve Orvell wrote:
>
>> The word "component" will be used as a s
For context here's another thread about ::part where we start to look a
little into the rabbit hole:
http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0012.html
One wants the expressiveness of css applied to ::part but things get
complicated very fast and the 'shadow cat' starts to lo
Here's a minimal and hopefully simple proposal that we can flesh out if
this seems like an interesting api direction:
https://gist.github.com/sorvell/e201c25ec39480be66aa
We keep the currently spec'd distribution algorithm/timing but remove
`select` in favor of an explicit selection callback. The
he flow of events. So a similar question: when is it safe to call
child.dispatchEvent such that if parent distributes elements to its
shadowRoot, elements in the shadowRoot will see the event?
On Mon, Apr 27, 2015 at 1:45 PM, Ryosuke Niwa wrote:
>
> On Apr 27, 2015, at 11:47 AM, Steve O
so since it is just another element from
his perspective.
How can I, the author of , craft my element such that I don't
violate Bob's expectations? Does your proposal support this?
On Mon, Apr 27, 2015 at 3:42 PM, Ryosuke Niwa wrote:
>
> > On Apr 27, 2015, at 3:15 PM, Steve Orvell
.offsetHeight;
On Mon, Apr 27, 2015 at 4:55 PM, Ryosuke Niwa wrote:
>
> > On Apr 27, 2015, at 4:41 PM, Steve Orvell wrote:
> >
> >> Again, the timing was deferred in [1] and [2] so it really depends on
> when each component decides to distribute.
> >
>
onable requirement that the
shadowRoot author can be aware of this change since the author is causing
it to happen.
On Mon, Apr 27, 2015 at 7:01 PM, Ryosuke Niwa wrote:
>
> > On Apr 27, 2015, at 5:43 PM, Steve Orvell wrote:
> >>
> >> That might be an acceptable mode of op
With respect to Dimitri's *unpacking* notion, we think it can work.
In most cases today the redistribution tree is not large; however, if there
were a lot of final destination points in that tree, unpacking would be
cumbersome because you need to define a slot at every level for every final
destin
11 matches
Mail list logo
