https://www.w3.org/Bugs/Public/show_bug.cgi?id=21649
Bug ID: 21649
Summary: Duplicate requirement
Classification: Unclassified
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: All
Status: NEW
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21650
Bug ID: 21650
Summary: Require that XHR is available in workers
Classification: Unclassified
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: All
On Mon, Mar 18, 2013 at 5:05 PM, Scott Miles sjmi...@google.com wrote:
I'm already on the record with A, but I have a question about 'lossiness'.
With my web developer hat on, I wonder why I can't say:
div id=foo
shadowroot
shadow stuff
/shadowroot
light stuff
/div
and
So, what you quoted are thoughts I already deprecated mysefl in this
thread. :)
If you read a bit further, see that I realized that shadow-root is
really part of the 'outer html' of the node and not the inner html.
I think that is actually a feature, not a detriment and easily
explainable.
On Apr 10, 2013 1:24 PM, Scott Miles sjmi...@google.com wrote:
So, what you quoted are thoughts I already deprecated mysefl in this
thread. :)
If you read a bit further, see that I realized that shadow-root is
really part of the 'outer html' of the node and not the inner html.
Yeah sorry,
I don't see any reason why my document markup for some div should not be
serializable back to how I wrote it via innerHTML. That seems just plain
bad.
I hope you can take a look at what I'm saying about outerHTML. I believe at
least the concept there solves all cases.
On Wed, Apr 10, 2013 at
Dear Webappsonites,
There's been a ton of thinking on what the custom elements declarative
syntax must look like. Here, I present something has near-ideal
developer ergonomics at the expense of terrible sins in other areas.
Consider it to be beacon, rather than a concrete proposal.
First, let's
On Tue, Apr 9, 2013 at 11:42 AM, Scott Miles sjmi...@google.com wrote:
Duplicate fetching is not observable, but duplicate parsing and duplicate
copies are observable.
Preventing duplicate parsing and duplicate copies allows us to use 'imports'
without a secondary packaging mechanism. For
Interesting. Why do you need [attribute to opt-out of deduping]?
I don't believe it's *needed* exactly, but we imagined somebody wanting to
import HTML, use it destructively, then import it again.
That may be totally crazy. :)
Scott
On Wed, Apr 10, 2013 at 11:50 AM, Dimitri Glazkov
Maybe I'm missing something but we clearly don't want to include
shadowroot in the general innerHTML getter case. If I implement
input[type=range] using custom elements + shadow DOM I don't want innerHTML
to show the internal guts.
On Wed, Apr 10, 2013 at 2:30 PM, Scott Miles sjmi...@google.com
I think we all agree that node.innerHTML should not reveal node's
ShadowDOM, ever.
What I am arguing is that, if we have shadow-root element that you can
use to install shadow DOM into an arbitrary node, like this:
div
shadow-root
Decoration -- content/content -- Decoration
shadow-root
Once again, how would this work for input/video?
Are you suggesting that `createShadowRoot` behaves different than when you
create the shadow root using markup?
On Wed, Apr 10, 2013 at 3:11 PM, Scott Miles sjmi...@google.com wrote:
I think we all agree that node.innerHTML should not reveal
Thank you for distilling all that down into digestible content (yum,
distillates).
A couple of notes:
The 'magic script' problem has been difficult to reconcile with template,
so there is willingness to continue to use element, but ideally without
nesting template. In other words, perhaps
input/video would have intrinsic Shadow DOM, so it would not ever be part
of outerHTML.
I don't have a precise way to differentiate intrinsic Shadow DOM from
non-intrinsic Shadow DOM, but my rule of thumb is this: 'node.outerHTML'
should produce markup that parses back into 'node' (assuming all
No, strictly ergonomic. Less nesting and less characters (less nesting is
more important IMO).
I would also argue that there is less cognitive load on the author then the
more explicit factoring, but I believe this is subjective.
Scott
On Wed, Apr 10, 2013 at 12:36 PM, Rafael Weinstein
I have a counter proposal that takes into a count both the easy-to-declare,
1-to-1 case, as well as the 1-template-to-many-elements case:
https://gist.github.com/csuwldcat/5358039
I can explain the advantages a bit more in an hour or so, I just got pulled
into a meeting...le sigh.
Daniel J.
On Wed, Apr 10, 2013 at 4:15 PM, Daniel Buchner dan...@mozilla.com wrote:
I have a counter proposal that takes into a count both the
easy-to-declare, 1-to-1 case, as well as the 1-template-to-many-elements
case: https://gist.github.com/csuwldcat/5358039
What about CSP that forbids inline
I made an attempt to describe how these things can be non-lossy here:
https://gist.github.com/sjmiles/5358120
On Wed, Apr 10, 2013 at 12:19 PM, Scott Miles sjmi...@google.com wrote:
input/video would have intrinsic Shadow DOM, so it would not ever be part
of outerHTML.
I don't have a
*What about CSP that forbids inline
scripts?https://wiki.mozilla.org/Apps/Security#Default_CSP_policy
*
Is there any reason developers wouldn't just modify the script tag under
either method proposed to use src=link-to-non-inline-script to satisfy
CSP requirements? The proposal I submitted
Averting thread-hijacking...
CSP is something we'll need to discuss with WebAppsSec peeps at the
upcoming F2F.
:DG
-- Forwarded message --
From: Daniel Buchner dan...@mozilla.com
Date: Wed, Apr 10, 2013 at 1:38 PM
Subject: Re: [webcomponents]: Platonic form of custom elements
On Wed, Apr 10, 2013 at 4:38 PM, Daniel Buchner dan...@mozilla.com wrote:
*What about CSP that forbids inline
scripts?https://wiki.mozilla.org/Apps/Security#Default_CSP_policy
*
Is there any reason developers wouldn't just modify the script tag under
either method proposed to use
For the record I'm opposed to what you are proposoing. I don't like that
you lose the symmetry between innerHTML and outerHTML.
On Wed, Apr 10, 2013 at 4:34 PM, Scott Miles sjmi...@google.com wrote:
I made an attempt to describe how these things can be non-lossy here:
Well ok, that's unfortunate, I do wish you gave me more than no, that's
bad. Here are a couple more thoughts.
1. I suspect the loss-of-symmetry occurs because Dimitri has defined an
element that has markup as if it is a child, but it's not actually a child.
This is the 'wormhole' effect.
2. My
On Wed, Apr 10, 2013 at 4:43 PM, Rick Waldron waldron.r...@gmail.comwrote:
A bigger issue with proposal is that the global object appears to be the
element's instance object itself, which isn't going to work
+1
I'm not sure that `this` was supposed to be the [[Global]] object? But
agree with
One thing I'm wondering re template elements and the association of a
specific script with them, is what is it really doing for me? From what I
see, not much. It seems the only thing it does, is allows you to have the
generic, globally-scoped script run at a given time (via a new runwhen___
FWIW, I think it's a design mistake to make element registration a
concern of template.
I'd be more persuaded by the developer ergonomics argument if this was
a cost that was incurred with the usage of custom elements, but it's
not. It's only incurred with the element definition.
Separately, I
On Wed, Apr 10, 2013 at 2:45 PM, Rafael Weinstein rafa...@google.com wrote:
FWIW, I think it's a design mistake to make element registration a
concern of template.
Sorry. I over-stated my conviction here. Let me walk that back: I'm
not yet hearing sufficient justification for making element
On Wed, Apr 10, 2013 at 5:35 PM, Daniel Buchner dan...@mozilla.com wrote:
One thing I'm wondering re template elements and the association of a
specific script with them, is what is it really doing for me? From what I
see, not much. It seems the only thing it does, is allows you to have the
mistake to make element registration a concern of template.
Raf: does that include making a new type 'element' which is a subtype of
'template', which is specifically given this concern?
stamp out light DOM is a new semantic
This is true, it sort of appeared organically and we haven't
how that specific script tag knows what its this value is
I think I'm probably not answering your question, but I believe the notion
was that that script tag is handled specially by element, so it's a
script* which only ever executes in the 'scope' of element.
On Wed, Apr 10, 2013 at 2:54 PM,
On Wed, Apr 10, 2013 at 3:30 PM, Daniel Buchner dan...@mozilla.com wrote:
@John - in my opinion, template bindtotagname=my-yay is the wrong
direction. You should be declaring which *template* an *element* uses, not
which element a template captures. Having templates latch onto element
types
On Wed, Apr 10, 2013 at 8:19 PM, Daniel Buchner dan...@mozilla.com wrote:
Here are a few (compelling?) answers/arguments:
1. Style elements had never done this before, yet it rocks socks:
style scoped
Beat me to it. Another date point is @keyframes/@font-face, which are
(today)
It's incredibly important that we agree that association of a template
with element happens on the element side, something like: element
template=foo-template (or by placing the template inside element, if
that is the API we want). I don't think this part is opinion, but because
doing the reverse
Here are a few (compelling?) answers/arguments:
1. Style elements had never done this before, yet it rocks socks: style
scoped
2. It would be new for script elements, but hardly new for other
elements. There are plenty of elements that have various behaviors or
visual
I thought of another tack. I should have made it clear that I wasn't so
much making a proposal as trying to suggest the nature of 'shadow-dom'
works without lossiness when considered part of outerHTML. The notion
itself doesn't seem to me to be particularly worthy of controversy, so I
suspect the
On Wed, Apr 10, 2013 at 6:38 PM, Rick Waldron waldron.r...@gmail.com wrote:
Everyone's answer to this should be no; changing the expected value of the
top level this, in some magical way, simply won't work.
Can you explain why you feel this way?
:DG
cc Allen Wirfs-Brock, Dave Herman
Allen, Dave
Would you mind reading back through the thread to provide some deeper
insight? Thanks
Rick
On Wednesday, April 10, 2013, Daniel Buchner wrote:
Here are a few (compelling?) answers/arguments:
1. Style elements had never done this before,
Have to lean towards Raf and Daniel on this one. Making a element
registation a concern of template doesn't feel right. In this case, explicit
structure and a few more characters is worth it.
On Wed, Apr 10, 2013 at 9:00 PM, Daniel Buchner dan...@mozilla.com wrote:
It's incredibly important
38 matches
Mail list logo
