And for HTML Improts:
# Since Last TPAC:
* Minor bug fixes
* Styleshet cascading order clarification
# Next 6 months:
* Script execution order clarification
* ES6 modules integration
On Fri, Oct 24, 2014 at 1:08 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
Here's an update on Custom
Thanks for the feedback!
i addressed some. I aim to address all of them but some are hard to fix
instantly.
On Tue, Aug 19, 2014 at 6:51 AM, Gabor Krizsanits gkrizsan...@mozilla.com
wrote:
I've heard complains about the readability of the current import draft,
and I think the best way to
AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Jul 22, 2014 at 12:36 AM, Hajime Morrita morr...@google.com
wrote:
It behaved like that before. I changed it to current one so that it works
with credential-protected in-house or staged apps.
You'll need to elaborate a bit, I'm not sure I
It behaved like that before. I changed it to current one so that it works
with credential-protected in-house or staged apps.
That's right. Thanks for the catch!
Fixed:
https://github.com/w3c/webcomponents/commit/90da4809a207916486bc7af83a568f3762e780a0
On Tue, Jul 15, 2014 at 10:00 AM, Boris Zbarsky bzbar...@mit.edu wrote:
In http://w3c.github.io/webcomponents/spec/imports/#fetching-import the
spec says:
Fetch
A clarification to make sure people in same page:
On Mon, Jun 2, 2014 at 5:54 AM, James M Snell jasn...@gmail.com wrote:
So long as they're handled with the same policy and restrictions as the
script tag, it shouldn't be any worse.
HTML Imports are a bit more strict. They see CORS header and
Hi,
Since last HTML Imports WD is published, I heard some feedback. Most of
them are about the loading order and its sync/async nature. Thanks for
sharing your thought!
At the same time, I found there are some confusion about how it works. As
it's hard for me to capture the underlying thinking
On Fri, Feb 28, 2014 at 3:40 PM, Arthur Barstow art.bars...@nokia.comwrote:
Hajime proposes WebApps publish a new WD of HTML Imports on March 6, based
on [ED].
If you have any comments about this proposal, please reply to this thread
by March 3 at the latest.
-Thanks, AB
[ED]
Here is my understanding:
Firefox has already shipped style scoped without Shadow DOM and I guess
there is no dependency from scoped style to shadow DOM as the former is
done before the later is started.
WebKit situation was similar. style scoped was done before Shadow DOM,
and style scoping for
This seems related to discussion around selection [1].
My claim there was that the selection shouldn't cross shadow boundary, at
least from the boundary crossing shouldn't be visible script.
If this invariant is kept, we can model copy-pasting in DOM land, without
thinking about Shadow DOM nor
On Thu, Feb 6, 2014 at 2:54 PM, Erik Arvidsson a...@google.com wrote:
All good points. One issue that we should track...
On Thu, Feb 6, 2014 at 5:20 PM, Hajime Morrita morr...@google.com wrote:
This seems related to discussion around selection [1].
My claim there was that the selection
to prevent that kind of thing. But owning different
content type will be stronger protection.
On Tue, Feb 4, 2014 at 12:22 AM, Frederik Braun fbr...@mozilla.com wrote:
On 03.02.2014 21:58, Hajime Morrita wrote:
Parser-made script means the script tags and its contents that are
written in HTML
On Mon, Feb 3, 2014 at 2:23 AM, Frederik Braun fbr...@mozilla.com wrote:
On 31.01.2014 06:43, Hajime Morrita wrote:
Generally I prefer master-CSP model than the own CSP model due to its
simplicity but I agree that unsafe-script kills the conciseness of
Imports.
To make inline scripts
Generally I prefer master-CSP model than the own CSP model due to its
simplicity but I agree that unsafe-script kills the conciseness of Imports.
To make inline scripts work with imports, we might want another CSP
directive like safe-script, which allows parser-made script but doesn't
allow
I don't want to make it removable from the cache/manager. Once it is
loaded, it should be there until the page ends. Allowing
removal/cancellation has big implication that will introduce many
complicated race conditions and edge cases. For example, what happens if
link is removed before/while its
On Fri, Jan 10, 2014 at 5:30 PM, Frederik Braun fbr...@mozilla.com wrote:
On 10.01.2014 03:52, Hajime Morrita wrote:
Hi Frederik,
Thanks for bringing it up!
As you pointed out, CSP of imported documents essentially extends the
set of allowed domains. I thought I was useful
Hi Frederik,
Thanks for bringing it up!
As you pointed out, CSP of imported documents essentially extends the
set of allowed domains. I thought I was useful for component authors to
specify their own domains, like one of their own CDN.
I'm not sure how it is threatening because components won't
On inheritance around HTMLElement family, there seems to be a confusion
between interface side inheritance and implementation side inheritance.
In WebIDL, interfaces of HTML elements have inherited only from HTMLElement
interface. This is fine just because it cares only about interface (API
:34 PM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 5, 2013, at 10:09 PM, Hajime Morrita morr...@google.com wrote:
On inheritance around HTMLElement family, there seems to be a confusion
between interface side inheritance and implementation side inheritance.
Right. Differentiating the two
I'd frame the problem in a slightly different way.
Seems like almost everyone agrees that we need better way to
modularize JavaScript, and ES6 modules are one of the most promising
way to go. And we also agree (I think) that we need a way to connect
ES6 modules and the browser.
What we don't
Oh I see. Thanks for the clarification.
On Thu, Oct 24, 2013 at 5:54 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Oct 24, 2013 at 1:38 AM, Hajime Morrita morr...@google.com
wrote:
OK, I will refer the fetch section in HTML spec then.
I think you misunderstood, http
Hi Joe,
Thanks for trying HTML Imports and looking into the spec!
It's a spec bug. The intention of the spec is to allow CORS-aware cross
origin resources. It seems that something wrong happened during editing. I
filed a bug [1] for revising it.
I've been trying to define the import loading
OK, I will refer the fetch section in HTML spec then.
On Wed, Oct 23, 2013 at 9:29 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 23, 2013 at 1:16 PM, Hajime Morrita morr...@google.com
wrote:
I've been trying to define the import loading behavior on top of the
basic
fetch
On Thu, Oct 17, 2013 at 5:01 PM, Ryosuke Niwa rn...@apple.com wrote:
On Oct 16, 2013, at 9:47 PM, Hajime Morrita morr...@google.com wrote:
D. H[ello Shado]w World - selection spans outside to inside.
Suppose we allowed this selection. Then how does one go about pasting this
content
On Fri, Oct 18, 2013 at 3:56 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Oct 17, 2013 at 1:55 AM, Hajime Morrita morr...@google.com
wrote:
On Thu, Oct 17, 2013 at 5:01 PM, Ryosuke Niwa rn...@apple.com wrote:
On Oct 16, 2013, at 9:47 PM, Hajime Morrita morr...@google.com wrote
wrote:
On Fri, Oct 11, 2013 at 10:23 PM, Ryosuke Niwa rn...@apple.com
wrote:
On Oct 7, 2013, at 1:38 PM, Jonas Sicking jo...@sicking.cc
wrote:
On Oct 7, 2013 6:56 AM, Hajime Morrita morr...@google.com
wrote:
Hi,
I'm sorry that I didn't notice that you were talking about UA
, 2013, at 1:38 PM, Jonas Sicking jo...@sicking.cc wrote:
On Oct 7, 2013 6:56 AM, Hajime Morrita morr...@google.com wrote:
Hi,
I'm sorry that I didn't notice that you were talking about UA shadow
DOM.
It's an implementation detail and the standard won't care about that.
That being
Hi,
I'm sorry that I didn't notice that you were talking about UA shadow DOM.
It's an implementation detail and the standard won't care about that.
That being said, it might be a good exercise to think about feasibility to
implement img-like custom element which supports alternate text.
1.
Just after started prototyping HTML Imports on Blink, this idea comes to my
mind: Why not have import for HTML Imports?
The good old link has its own semantics which allows users to change the
attributes dynamically. For example, you can change @href to load other
stylesheets. @type can be
Thanks for your feedback, folks.
I presumed that link rel=import is one-shot just because it is how
element works and I felt both are analogous, but apparently this is not a
common perception.
It seems like making link rel=import dynamically-updatable isn't that
controversial. I'll try that way.
On Sat, Mar 23, 2013 at 3:25 AM, Dimitri Glazkov dglaz...@chromium.orgwrote:
On Fri, Mar 22, 2013 at 9:35 AM, Scott Miles sjmi...@google.com wrote:
In our work, we adopt a composition rule that a node knows about it's own
children and can have expectations of them, but can make no
From an implementors perspective:
Putting such callbacks on the prototype object means that it can be
changed, or even can be added after the element registration. This is
different from a function parameter, which we can consider as a snapshot.
One consequence is that it will become harder to
On Thu, Mar 7, 2013 at 9:13 AM, Erik Arvidsson a...@chromium.org wrote:
Inline
On Wed, Mar 6, 2013 at 7:03 PM, Hajime Morrita morr...@google.com wrote:
One consequence is that it will become harder to cache (including
negative cache) these values. We need to traverse the prototype chain
On Wed, Sep 28, 2011 at 3:39 PM, Roland Steiner
rolandstei...@chromium.orgwrote:
Expanding on the general web component discussion, one area that hasn't
been touched on AFAIK is how components fit within the content model of HTML
elements.
Take for example a list (
34 matches
Mail list logo
