You can tackle bits of this problem by assigning different subdomains
either per-permission set or per-client.
AFAIU, the settings should be stored independently.
With more and more permissions coming to the web, the numbers of
combinations might grow exponentially though.
On 27.04.2015 12:50,
On Mon, Apr 27, 2015 at 9:03 AM, Rune Lillesveen r...@opera.com wrote:
On Mon, Apr 27, 2015 at 6:22 AM, Anne van Kesteren ann...@annevk.nl wrote:
Would they match against elements in the host's tree or the shadow
tree? I don't see anything in the specification about this.
They would match
On Sat, Apr 25, 2015 at 12:41 AM, Brendan Eich bren...@secure.meer.net wrote:
Step where you need to, to avoid falling over :-P.
Fair. I filed
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28566
on adding a structured clone API.
The problems with generalized/extensible clone are clear
On Mon, Apr 27, 2015 at 12:50 PM, Andy Earnshaw andyearns...@gmail.com wrote:
I realise that this is outside the scope of the specification and that the
spec only goes as far as making a recommendation to use the origin of the
document or worker when making security decisions, but this seemed
I work for an adserving company, where many third-party creatives are
served from the same CDN domain. One of the things we're starting to see
now is more use of APIs that require permissions, such as Geolocation and,
since the recent Chrome 42 release, Push Notifications.
These APIs are great,
Not sure this is a public-webapps issue but I'm pretty sure however that the
reason is the return values of getElement*By*(...) are cached by the
browser which means that you end up not doing the work at all at some point in
the loop, while you probably do it every single time for
On Apr 26, 2015, at 6:11 PM, Hayato Ito hay...@chromium.org wrote:
I think Polymer folks will answer the use case of re-distribution.
So let me just show a good analogy so that every one can understand
intuitively what re-distribution *means*.
Let me use a pseudo language and define
On Sat, Apr 25, 2015 at 9:32 AM, Anne van Kesteren ann...@annevk.nl wrote:
I don't understand why :host is a pseudo-class rather than a
pseudo-element. My mental model of a pseudo-class is that it allows
you to match an element based on a boolean internal slot of that
element. :host is not
On Apr 27, 2015, at 1:45 PM, Ryosuke Niwa rn...@apple.com wrote:
On Apr 27, 2015, at 11:47 AM, Steve Orvell sorv...@google.com
mailto:sorv...@google.com wrote:
Here's a minimal and hopefully simple proposal that we can flesh out if this
seems like an interesting api direction:
On Apr 26, 2015, at 11:05 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Sat, Apr 25, 2015 at 10:49 PM, Ryosuke Niwa rn...@apple.com 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
On Apr 27, 2015, at 11:47 AM, Steve Orvell sorv...@google.com wrote:
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
On Tue, Apr 28, 2015 at 6:18 AM Ryosuke Niwa rn...@apple.com wrote:
On Apr 26, 2015, at 6:11 PM, Hayato Ito hay...@chromium.org wrote:
I think Polymer folks will answer the use case of re-distribution.
So let me just show a good analogy so that every one can understand
intuitively
On Mon, Apr 27, 2015 at 6:22 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Apr 27, 2015 at 5:56 AM, L. David Baron dba...@dbaron.org wrote:
For :host it's less interesting, but I thought a major use of
:host() and :host-context() is to be able to write selectors that
have combinators
On Mon, Apr 27, 2015 at 9:25 AM, Justin Fagnani
justinfagn...@google.com 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
multiple generations of shadow roots are gone. As long as a subclass and
Intuitively, querySelector('.class') only needs to find the first matching
node, whereas getElementsByClassName('.class')[0] needs to find all matching
nodes and then return the first. The former should be a lot quicker than the
latter. Why that's not the case?
See
On Mon, Apr 27, 2015 at 1:01 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Apr 27, 2015 at 9:25 AM, Justin Fagnani
justinfagn...@google.com 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
On Sat, Apr 25, 2015 at 10:49 PM, Ryosuke Niwa rn...@apple.com 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 an ordered list of insertion points, which results in O(n)
On Sun, Apr 26, 2015 at 11:05 PM, Anne van Kesteren ann...@annevk.nl
wrote:
On Sat, Apr 25, 2015 at 10:49 PM, Ryosuke Niwa rn...@apple.com 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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28564
Bug ID: 28564
Summary: [Shadow]: Event model
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
On Mon, Apr 27, 2015 at 10:23 AM, Justin Fagnani
justinfagn...@google.com wrote:
A separate hidden tree per class sounds very much like multiple generations
of shadow trees, and we just killed that...
We killed it for v1, not indefinitely. As I already said, based on
my post-meeting
On Mon, Apr 27, 2015 at 3:41 PM, Matthew Robb matthewwr...@gmail.com wrote:
I know this isn't the biggest deal but I think naming the function
distribute is highly suggestive, why not just expose this as
`childListChangedCallback` ?
Because that doesn't match the actual semantics. The callback
This is an announcement of the intent to publish a new WD of Push API on
April 30 using the following document as the basis:
https://w3c.github.io/push-api/publish/TR.html
(The sequence diagram is not found when the above document is loaded but
the diagram will be available in the WD
I know this isn't the biggest deal but I think naming the function
distribute is highly suggestive, why not just expose this as
`childListChangedCallback` ?
- Matthew Robb
On Mon, Apr 27, 2015 at 4:34 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Apr 27, 2015 at 10:23 AM, Justin
I think there are a lot of user operations where distribution must be
updated before returning the meaningful result synchronously.
Unless distribution result is correctly updated, users would take the dirty
result.
For example:
- element.offsetWidth: Style resolution requires distribution. We
On Mon, Apr 27, 2015 at 4:06 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Apr 27, 2015 at 3:42 PM, Ryosuke Niwa rn...@apple.com wrote:
On Apr 27, 2015, at 3:15 PM, Steve Orvell sorv...@google.com wrote:
IMO, the appeal of this proposal is that it's a small change to the current
spec
IMO, the appeal of this proposal is that it's a small change to the current
spec and avoids changing user expectations about the state of the dom and
can explain the two declarative proposals for distribution.
It seems like with this API, we’d have to make O(n^k) calls where n is the
number of
Could you clarify what you are trying to achieve? If we don't support,
everything would be weird.
I guess you are proposing the alternative of the current pool population
algorithm and pool distribution algorithm.
I appreciate you could explain what are expected result using algorithms.
On
Again, the timing was deferred in [1] and [2] so it really depends on when
each component decides to distribute.
I want to be able to create an element x-foo that acts like other dom
elements. This element uses Shadow DOM and distribution to encapsulate its
details.
Let's imagine a 3rd party
On Apr 27, 2015, at 2:38 PM, Hayato Ito hay...@chromium.org wrote:
On Tue, Apr 28, 2015 at 6:18 AM Ryosuke Niwa rn...@apple.com
mailto:rn...@apple.com wrote:
On Apr 26, 2015, at 6:11 PM, Hayato Ito hay...@chromium.org
mailto:hay...@chromium.org wrote:
I think Polymer folks will
On Apr 27, 2015, at 3:15 PM, Steve Orvell sorv...@google.com wrote:
IMO, the appeal of this proposal is that it's a small change to the current
spec and avoids changing user expectations about the state of the dom and can
explain the two declarative proposals for distribution.
It seems
On Apr 27, 2015, at 4:41 PM, Steve Orvell sorv...@google.com wrote:
Again, the timing was deferred in [1] and [2] so it really depends on when
each component decides to distribute.
I want to be able to create an element x-foo that acts like other dom
elements. This element uses Shadow
On Apr 27, 2015, at 3:31 PM, Hayato Ito hay...@chromium.org wrote:
I think there are a lot of user operations where distribution must be updated
before returning the meaningful result synchronously.
Unless distribution result is correctly updated, users would take the dirty
result.
On Mon, Apr 27, 2015 at 3:42 PM, Ryosuke Niwa rn...@apple.com wrote:
On Apr 27, 2015, at 3:15 PM, Steve Orvell sorv...@google.com wrote:
IMO, the appeal of this proposal is that it's a small change to the current
spec and avoids changing user expectations about the state of the dom and
can
On Apr 24, 2015 3:16 PM, Joshua Bell jsb...@google.com wrote:
It seems like the OP's intent is just to deep-copy an object. Something
like the OP's tweet... or this, which we use in some tests:
function structuredClone(o) {
return new Promise(function(resolve) {
var mc = new
I'm aware that our consensus is to defer this until v2. Don't worry. :)
The feature of shadow as function supports *subclassing*. That's
exactly the motivation I've introduced it once in the spec (and implemented
it in blink).
I think Jan Miksovsky, co-author of Apple's proposal, knows well that.
On Apr 27, 2015, at 5:43 PM, Steve Orvell sorv...@google.com wrote:
That might be an acceptable mode of operations. If you wanted to
synchronously update your insertion points, rely on custom element's
lifecycle callbacks and you can only support direct children for
distribution.
On Thu, Apr 23, 2015 at 6:31 PM, Kyle Huey m...@kylehuey.com wrote:
On Thu, Apr 23, 2015 at 6:06 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/23/15 6:34 PM, Elliott Sprehn wrote:
Have you benchmarked this? I think you're better off just writing your
own clone library.
That requires
Perhaps we need to make childrenChanged optionally get called when
attributes of child nodes are changed just like the way you can configure
mutation observers to optionally monitor attribute changes.
Wow, let me summarize if I can. Let's say we have (a) a custom elements
synchronous
Note: Our current consensus is to defer this until v2.
On Apr 27, 2015, at 9:09 PM, Hayato Ito hay...@chromium.org wrote:
For the record, I, as a spec editor, still think Shadow Root hosts yet
another Shadow Root is the best idea among all ideas I've ever seen, with a
shadow as function,
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28522
Koji Ishii kojii...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28552
Bug 28552 depends on bug 28522, which changed state.
Bug 28522 Summary: [Shadow] Cascading for trees of no-inner/outer and
no-younger/older relationship
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28522
What|Removed
On Thu, Apr 23, 2015 at 12:28 PM, Ali Alabbas a...@microsoft.com wrote:
Hello WebApps Group,
Hi Ali,
Yay! This is great to see a formal proposal for! Definitely something
that mozilla is very interested in working on.
If there is sufficient interest, I would like to work on this within the
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23726
Takeshi Yoshino tyosh...@google.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On Mon, Apr 27, 2015 at 1:57 AM, Glen Huang curvedm...@gmail.com wrote:
Intuitively, querySelector('.class') only needs to find the first matching
node, whereas getElementsByClassName('.class')[0] needs to find all matching
nodes and then return the first. The former should be a lot quicker
On Apr 27, 2015, at 7:32 PM, Steve Orvell sorv...@google.com wrote:
Perhaps we need to make childrenChanged optionally get called when
attributes of child nodes are changed just like the way you can configure
mutation observers to optionally monitor attribute changes.
Wow, let me
Thank you for the sample code. It's very helpful.
When you say var node = list[0]; walks the DOM until the first item is found,
do you mean it only happens under the condition that some previous code has
changed the DOM structure? If not, the returned list object will be marked as
up-to-day,
On Apr 27, 2015, at 12:25 AM, Justin Fagnani justinfagn...@google.com wrote:
On Sun, Apr 26, 2015 at 11:05 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Sat, Apr 25, 2015 at 10:49 PM, Ryosuke Niwa rn...@apple.com wrote:
If we wanted to allow non-direct child descendent (e.g. grand child
For the record, I, as a spec editor, still think Shadow Root hosts yet
another Shadow Root is the best idea among all ideas I've ever seen, with
a shadow as function, because it can explain everything in a unified
way using a single tree of trees, without bringing yet another complexity
such as
On Apr 27, 2015, at 7:04 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Apr 27, 2015 at 1:57 AM, Glen Huang curvedm...@gmail.com wrote:
Intuitively, querySelector('.class') only needs to find the first matching
node, whereas getElementsByClassName('.class')[0] needs to find all matching
I wonder why querySelector can't get the same optimization: If the passed
selector is a simple selector like .class, do exactly as
getElementsByClassName('class')[0] does?
On Apr 28, 2015, at 10:51 AM, Ryosuke Niwa rn...@apple.com wrote:
On Apr 27, 2015, at 7:04 PM, Jonas Sicking
On 4/27/15 11:27 PM, Glen Huang wrote:
When you say var node = list[0]; walks the DOM until the first item is found,
do you mean it only happens under the condition that some previous code has changed the
DOM structure?
Or that no one has ever asked the list for its [0] element before, yes.
Live node lists make all dom mutation slower, so while it might look faster
in your benchmark it's actually slower elsewhere (ex. appendChild).
Do you have a real application where you see querySelector as the
bottleneck?
On Apr 27, 2015 5:32 PM, Glen Huang curvedm...@gmail.com wrote:
I wonder
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28577
Bug ID: 28577
Summary: [XMLHttpRequest] Throwing NetworkError on open() call
for some kind of simple errors
Product: WebAppsWG
Version: unspecified
Hardware: PC
On Thu, Apr 23, 2015 at 5:45 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Apr 23, 2015 at 12:28 PM, Ali Alabbas a...@microsoft.com wrote:
If there is sufficient interest, I would like to work on this within the
scope of the WebApps working group.
It seems somewhat better to just
Looks good to me. While we are continuing work on data payload encryption
and alignment with the IETF Web Push Protocol, it makes sense to refresh
the WD snapshot.
Regards,
Michael
On Mon, Apr 27, 2015 at 2:39 PM, Arthur Barstow art.bars...@gmail.com
wrote:
This is an announcement of the
On 04/27/2015 02:11 AM, Hayato Ito wrote:
I think Polymer folks will answer the use case of re-distribution.
I wasn't questioning the need for re-distribution. I was questioning the need
to distribute grandchildren etc -
and even more, I was wondering what kind of algorithm would be sane in
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.
On Fri, Apr 24, 2015 at 2:28 AM, Ali Alabbas a...@microsoft.com wrote:
If there is sufficient interest, I would like to work on this within the
scope of the WebApps working group.
And I'll help with the FileSystem API bit, ensuring that full spec.[3]
has bits about the Directory Upload
58 matches
Mail list logo
