My personal objections (ones that I think are shared by at least some other
Safari folks):
- It's way too complicated. (As one crude metric, I count 22 interfaces; and
yes, I know many of those are callback interfaces or sync versions of
interfaces; it still seems overengineered).
- I see
, Sep 21, 2012 at 5:37 PM, Maciej Stachowiak m...@apple.com wrote:
My personal objections (ones that I think are shared by at least some other
Safari folks):
- It's way too complicated. (As one crude metric, I count 22 interfaces; and
yes, I know many of those are callback interfaces or sync
On Sep 21, 2012, at 10:10 PM, Jonas Sicking jo...@sicking.cc wrote:
For what it's worth, I put together a draft for what an API would look
like that has basically the same feature set as the current FileSystem
API, but based on DeviceStorage. It's a much smaller API that the
current
On Sep 22, 2012, at 8:18 PM, Brendan Eich bren...@mozilla.com wrote:
And two of the interfaces are generic and reusable in other contexts.
Nice, and DOMRequest predates yours -- should it be done separately since (I
believe) it is being used by other proposals unrelated to
On Sep 22, 2012, at 9:35 PM, Maciej Stachowiak m...@apple.com wrote:
On Sep 22, 2012, at 8:18 PM, Brendan Eich bren...@mozilla.com wrote:
And two of the interfaces are generic and reusable in other contexts.
Nice, and DOMRequest predates yours -- should it be done separately since (I
On Sep 25, 2012, at 10:20 AM, James Graham jgra...@opera.com wrote:
In addition, this would be the fourth storage API that we have tried to
introduce to the platform in 5 years (localStorage, WebSQL, IndexedDB being
the other three), and the fifth in total. Of the four APIs excluding this
unsolvable. The
two tricky ones I've seen are maximum filename/path length limitations, and
valid characters varying between platforms, which have been discussed a lot
and would need to be revisited--it's been too long and I forget where that
left off.)
On Fri, Sep 21, 2012 at 7:37 PM, Maciej
On Oct 13, 2012, at 1:49 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Oct 12, 2012 at 8:25 PM, Florian Bösch pya...@gmail.com wrote:
There was a limited discussion on that a few days ago with the limited
consensus (?) being that requiring user-consent up front before switching to
On Oct 13, 2012, at 4:58 AM, Florian Bösch pya...@gmail.com wrote:
On Sat, Oct 13, 2012 at 1:49 PM, Maciej Stachowiak m...@apple.com wrote:
I think the most effective defense against phishing via fullscreen is to
prevent keyboard access. The original design for requestFullscreen had
On Oct 14, 2012, at 3:54 PM, Chris Pearce cpea...@mozilla.com wrote:
On 14/10/12 00:49, Maciej Stachowiak wrote:
Despite both of these defenses having drawbacks, I think it is wise for
implementations to implement at least one of them. I think the spec should
explicitly permit
On Oct 14, 2012, at 3:52 PM, Chris Pearce cpea...@mozilla.com wrote:
On 13/10/12 07:20, Carr, Wayne wrote:
There’s a recent post on a phishing attack using the full screen api
[1][2}[3].
It's worth noting that this attack has been possible in Flash for years, and
the sky hasn't fallen.
the API on that vendors browser? Anyone?
On Mon, Oct 15, 2012 at 12:32 PM, Maciej Stachowiak m...@apple.com wrote:
On Oct 14, 2012, at 3:54 PM, Chris Pearce cpea...@mozilla.com wrote:
On 14/10/12 00:49, Maciej Stachowiak wrote:
Despite both of these defenses having drawbacks, I think
On Oct 15, 2012, at 5:01 PM, Chris Pearce cpea...@mozilla.com wrote:
On 16/10/12 11:39, Maciej Stachowiak wrote:
That's why I liked having a separate API to request fullscreen with full
alphanumeric keyboard access. This allows apps to determine if fullscreen
with keyboard is available
On Oct 22, 2012, at 3:04 PM, Chris Pearce cpea...@mozilla.com wrote:
This looks remarkably like Mozilla's original proposal:
https://wiki.mozilla.org/Gecko:FullScreenAPI
We chose not to implement this as it offers little protection against
phishing or spoofing attacks that don't rely on
In the WebApps meeting, we discussed possible approaches to template that may
ease the transition between polyfilled implementations and native support,
avoid HTML/XHTML parsing inconsistency, and in general adding less weirdness to
the Web platform.
Here are some possibilities, not
On Nov 1, 2012, at 12:02 AM, Dimitri Glazkov dglaz...@google.com wrote:
Hi folks!
While you are all having good TPAC fun, I thought I would bring this
bug to your attention:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19562
There's been several comments from developers about the
On Nov 1, 2012, at 1:57 PM, Adam Barth w...@adambarth.com wrote:
(5) The nested template fragment parser operates like the template fragment
parser, but with the following additional difference:
(a) When a close tag named +script is encountered which does not match
any currently
On Nov 1, 2012, at 12:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Thu, Nov 1, 2012 at 9:37 AM, Maciej Stachowiak m...@apple.com wrote:
On Nov 1, 2012, at 12:02 AM, Dimitri Glazkov dglaz...@google.com wrote:
Hi folks!
While you are all having good TPAC fun, I thought I would bring
Could you please provide equivalent code examples using both versions?
Cheers,
Maciej
On Nov 7, 2012, at 10:36 AM, Dimitri Glazkov dglaz...@google.com wrote:
Folks,
Throughout the year-long (whoa!) history of the Shadow DOM spec,
various people commented on how odd the constructable
On Nov 6, 2012, at 3:29 PM, Dimitri Glazkov dglaz...@google.com wrote:
On Thu, Nov 1, 2012 at 8:39 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
6) The isolated setting essentially means that there's a new
document and scripting context for this shadow subtree (specifics
TBD). Watch
On Nov 8, 2012, at 2:15 AM, Elliott Sprehn espr...@gmail.com wrote:
On Thu, Nov 1, 2012 at 6:43 AM, Maciej Stachowiak m...@apple.com wrote:
On Nov 1, 2012, at 12:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
...
For example, being able to re-render the page manually via DOM
=== element.shadowRoot); // false
alert(root2 === element.shadowRoot); // true
:DG
On Thu, Nov 8, 2012 at 9:42 AM, Maciej Stachowiak m...@apple.com
wrote:
Could you please provide equivalent code examples using both
versions?
Cheers,
Maciej
On Nov 7, 2012, at 10:36 AM, Dimitri Glazkov dglaz
Does this support the previously discussed mechanism of allowing either public
or private components? I'm not able to tell from the referenced sections.
- Maciej
On Nov 28, 2012, at 1:17 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
As of
On Nov 29, 2012, at 12:24 PM, Elliott Sprehn espr...@gmail.com wrote:
On Wed, Nov 28, 2012 at 2:51 PM, Maciej Stachowiak m...@apple.com wrote:
Does this support the previously discussed mechanism of allowing either
public or private components? I'm not able to tell from the referenced
On Dec 18, 2012, at 6:44 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Oct 23, 2012 at 12:50 AM, Maciej Stachowiak m...@apple.com wrote:
Based on all this, I continue to think that requesting keyboard access
should involve separate API, so that it can be feature-detected and given
On Feb 15, 2013, at 3:51 AM, Ian Fette (イアンフェッティ) ife...@google.com wrote:
Anne,
Both Chrome and Safari support the ping attribute. I am not sure about IE, I
believe Firefox has it disabled by default. FWIW I wouldn't consider this a
huge failure, if anything I'd expect over time people
On Feb 15, 2013, at 9:21 PM, Maciej Stachowiak m...@apple.com wrote:
On Feb 15, 2013, at 3:51 AM, Ian Fette (イアンフェッティ) ife...@google.com wrote:
Anne,
Both Chrome and Safari support the ping attribute. I am not sure about IE, I
believe Firefox has it disabled by default. FWIW I
I like defineElement a lot too. I think it gets to the heart of this method's
potential - the ability to define your own elements.
- Maciej
On Dec 11, 2013, at 6:46 PM, Dominic Cooney domin...@google.com wrote:
On Thu, Dec 12, 2013 at 5:17 AM, pira...@gmail.com pira...@gmail.com wrote:
I
Thanks, Google folks, for considering a name to document.register. Though a
small change, I think it will be a nice improvement to code clarity.
Since we're bikeshedding, let me add a few more notes in favor of defineElement
for consideration:
1) In programming languages, you would normally
On Dec 12, 2013, at 11:20 AM, Joel Weinberger j...@chromium.org wrote:
Hi all. For a while now, we have wanted on Chrome to ignore
autocomplete='off' for password fields for the password manager. We believe
that the current respect for autocomplete='off' for passwords is, in fact,
harming
On Dec 7, 2013, at 4:38 PM, Dominic Cooney domin...@google.com wrote:
Built-in HTML elements have lots of hooks to modify their behaviour (for
example, HTMLVideoElement's autoplay attribute.) The analogy is extending a
Java class which has private and public final members, but no
On Dec 10, 2013, at 12:24 PM, Elliott Sprehn espr...@chromium.org wrote:
On Tue, Dec 10, 2013 at 8:00 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Dec 10, 2013 at 3:54 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/10/13 10:34 AM, Anne van Kesteren wrote:
E.g. the dialog's
On Dec 9, 2013, at 11:13 AM, Scott Miles sjmi...@google.com wrote:
Domenic Denicola a few messages back gave a highly cogent explanation of the
exact line of thinking arrived at last time we went through all this
material.
I'm not wont to try to summarize it here, since he said it
On Dec 7, 2013, at 1:29 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
From: Brendan Eich [mailto:bren...@secure.meer.net]
Requiring this kind of boilerplate out of the gave is not:
this.createShadowRoot().appendChild(document.importNode(template.contents));
Wanting to avoid
On Dec 7, 2013, at 3:31 PM, Dominic Cooney domin...@google.com wrote:
It's not reasonable to require developers to write the above super tricky
line of code. It involves at least four different concepts and is easy to get
subtly wrong.
For example, when I wrote my first component
On Dec 17, 2013, at 11:21 AM, Joel Weinberger j...@chromium.org wrote:
Thanks for the feedback, everyone. A few people at this point have suggested
emailing the wha...@whatwg.org list since this is really an HTML feature;
I'll do that in a few. In response to Ian's question, I'm referring
On Jan 2, 2014, at 9:33 AM, John Mellor joh...@google.com wrote:
On Thu, Dec 19, 2013 at 9:32 PM, Maciej Stachowiak m...@apple.com wrote:
On Dec 19, 2013, at 9:02 AM, John Mellor joh...@google.com wrote:
[cross-posted to public-webapps and public-sysapps]
A couple of us from Chrome
On Feb 7, 2014, at 9:32 AM, Scott González scott.gonza...@gmail.com wrote:
What about developers who are sending requests as the page is unloading? My
understanding is that sync requests are required. Is this not the case?
Besides the proposed Beacon API, if you don't need to do a POST then
On Feb 7, 2014, at 9:18 AM, Jonas Sicking jo...@sicking.cc wrote:
On Feb 7, 2014 8:57 AM, Domenic Denicola dome...@domenicdenicola.com
wrote:
From: Olli Pettay olli.pet...@helsinki.fi
And at least we'd improve responsiveness of those websites which stop
using sync XHR because of
On Feb 11, 2014, at 3:29 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
Dimitri, Maciej, Ryosuke - is there a mutually agreeable solution here?
I am exactly sure what problem this thread hopes to raise and whether there
is a need for anything other than what is already planned.
In
On Feb 11, 2014, at 4:04 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
On Tue, Feb 11, 2014 at 3:50 PM, Maciej Stachowiak m...@apple.com wrote:
On Feb 11, 2014, at 3:29 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
Dimitri, Maciej, Ryosuke - is there a mutually agreeable solution
On Feb 13, 2014, at 4:01 PM, Alex Russell slightly...@google.com wrote:
On Thu, Feb 13, 2014 at 1:25 PM, Maciej Stachowiak m...@apple.com wrote:
On Feb 12, 2014, at 4:04 PM, Alex Russell slightly...@google.com wrote:
In discussion with Elliot and Erik, there appears
On Feb 14, 2014, at 7:16 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/14/14 10:07 PM, Ryosuke Niwa wrote:
We most vigorously object to making the CSS style resolver depend on JS
DOM object properties.
Ryosuke, I think you misunderstood the proposal. I'm pretty sure we all
object to
On Feb 15, 2014, at 4:57 PM, Ryosuke Niwa rn...@apple.com wrote:Hi all,I’d like to propose one solution for[Shadow]: Specify imperative API for node distributionhttps://www.w3.org/Bugs/Public/show_bug.cgi?id=18429because select content attribute doesn’t satisfy the needs of framework/library
On Feb 16, 2014, at 2:16 AM, Marcos Caceres mar...@marcosc.com wrote:
On Sunday, February 16, 2014, Alex Russell slightly...@google.com wrote:
On Sat, Feb 15, 2014 at 5:56 AM, Marcos Caceres w...@marcosc.com wrote:
tl;dr: I strongly agree (and data below shows) that installable web apps
On Feb 21, 2014, at 11:04 AM, Ian Hickson i...@hixie.ch wrote:
On Thu, 20 Feb 2014, Jonas Sicking wrote:
On Thu, Feb 20, 2014 at 2:51 PM, Edward O'Connor eocon...@apple.com wrote:
Yeah, I think we just say that [form.elements] is the legacy feature
that only exposes built-in controls.
On Feb 21, 2014, at 2:28 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 21 Feb 2014, Maciej Stachowiak wrote:
I'd guess most sophisticated webapps do not use attribute-based event
handlers (as opposed to addEventListener), so they would not get this
convenient scoping benefit.
That's
On Feb 26, 2014, at 10:35 AM, Joshua Bell jsb...@google.com wrote:
While looking at a Chrome bug [1], I reviewed the Indexed DB draft, section
3.3.1 [2] Opening a database:
These steps are not run for any other connections with the same origin and
name but with a higher version
And
sounds better for me too!
:DG
On Mon, Apr 7, 2014 at 10:55 PM, Maciej Stachowiak m...@apple.com wrote:
Hi folks,
I’d really appreciate it if we could decide whether Web Components related
topics will be discussed Thursday or Friday. It is the topic I am most
personally interested
On May 15, 2014, at 6:17 AM, Anne van Kesteren ann...@annevk.nl wrote:
I'm still trying to grasp the philosophy behind shadow trees.
Sometimes it's explained as exposing the primitives but the more I
learn (rather slowly, this time at BlinkOn) the more it looks like a
bunch of new
On Jul 1, 2014, at 3:26 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
From: Maciej Stachowiak m...@apple.com
Web Components as currently designed cannot explain the behavior of any
built-in elements (except maybe those which can be explained with CSS alone).
Unfortunately
... Hanging but?! Oh lordy. Oooh, let me turn this into a contemplative
sidebar opportunity.
Shadow DOM and Web Components seem to have what I call the Unicorn
Syndrome. There's a set of specs that works, proven by at least one browser
implementation and the use in the wild. It's got
On Apr 23, 2015, at 3:27 PM, Martin Thomson martin.thom...@gmail.com wrote:
On 23 April 2015 at 15:02, Ted Mielczarek t...@mozilla.com wrote:
Has anyone ever proposed exposing the structured clone algorithm directly as
an API?
If you didn't just do so, I will :)
1.
Hi everyone,
I wrote up a proposal (with input and advice from Ryosuke Niwa) on a possible
way to extend Web Components to support fully isolated components:
https://github.com/w3c/webcomponents/wiki/Isolated-Imports-Proposal
https://github.com/w3c/webcomponents/wiki/Isolated-Imports-Proposal
On Apr 22, 2015, at 11:10 PM, Maciej Stachowiak m...@apple.com wrote:
Hi everyone,
In preparation for Fridays’ face-to-face, a number of us at Apple (including
me, Ryosuke Niwa, Sam Weinig, and Ted O’Connor
I forgot to mention that Gavin Barraclough also contributed to this discussion
Hi everyone,
In preparation for Fridays’ face-to-face, a number of us at Apple (including
me, Ryosuke Niwa, Sam Weinig, and Ted O’Connor) got together to collect our
thoughts and feedback about the current state of Web Components.
Before going into the changes we propose, we want to reiterate
On May 1, 2015, at 4:35 PM, Domenic Denicola d...@domenic.me wrote:
alert(weirdArray.__proto__ == localArray.__proto__)
This alerts false in IE, Firefox, and Chrome.
That is what I'd expect it to do. (It does the same in Safari).
I guess I didn't explain why I put this line in, so for
On May 1, 2015, at 9:47 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Apr 23, 2015 at 8:58 PM, Maciej Stachowiak m...@apple.com wrote:
I wrote up a proposal (with input and advice from Ryosuke Niwa) on a
possible way to extend Web Components to support fully isolated components
]
https://github.com/w3c/webcomponents/wiki/Cross-Origin-Custom-Elements:-Concept-and-Proposal
-Original Message-
From: Anne van Kesteren [mailto:ann...@annevk.nl]
Sent: Friday, May 1, 2015 9:48 AM
To: Maciej Stachowiak
Cc: WebApps WG
Subject: Re: [components] Isolated Imports
On May 7, 2015, at 12:59 AM, Domenic Denicola d...@domenic.me wrote:
From: Anne van Kesteren ann...@annevk.nl
On Thu, May 7, 2015 at 9:02 AM, Steve Faulkner faulkner.st...@gmail.com
wrote:
Currently ARIA does not do this stuff AFAIK.
Correct. ARIA only exposes strings to AT. We could
On Aug 17, 2015, at 3:19 PM, Domenic Denicola d...@domenic.me wrote:
In
A while back we sent a consolidated pile of feedback on the Web Components
family of specs. In preparation for tomorrow's F2F, here is an update on our
positions. We've also changed the bugzilla links to point to relevant github
issues instead.
We're only covering Custom Elements (the main
On Jul 20, 2015, at 10:29 PM, Domenic Denicola d...@domenic.me wrote:
Thanks very much for your feedback Maciej! I know we'll be talking a lot more
tomorrow, but one point in particular confused me:
From: Maciej Stachowiak [mailto:m...@apple.com]
4. Specifically, we don't really like
301 - 363 of 363 matches
Mail list logo
