Re: Custom elements "Constructor-Dmitry" baseline proposal

> On Aug 17, 2015, at 3:19 PM, Domenic Denicola wrote: > > In > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_webcomponents_blob_gh-2Dpages_proposals_Constructor-2DDmitry.md&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=Cq0heWYmrUNShLjLIzuzGQ&m=U2qIHSkYawudMNTponjVOJxTr1-blzlm_skvYT

Re: Apple's updated feedback on Custom Elements and Shadow DOM

> On Jul 20, 2015, at 10:29 PM, Domenic Denicola 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. Specif

Apple's updated feedback on Custom Elements and Shadow DOM

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 ex

Re: [components] Isolated Imports and Foreign Custom Elements

(Replying to slightly old thread.) > > Another thing that might be nice is that if these elements are that > much isolated, perhaps we can consider allowing them to be renamed > them as well, similar to what module systems allow you to do. An earlier version of my proposal had support for arbit

Re: Making ARIA and native HTML play better together

> On May 7, 2015, at 12:59 AM, Domenic Denicola wrote: > > From: Anne van Kesteren > >> On Thu, May 7, 2015 at 9:02 AM, Steve Faulkner >> wrote: >>> Currently ARIA does not do this stuff AFAIK. >> >> Correct. ARIA only exposes strings to AT. We could maybe make it do more, >> once we under

Re: [components] Isolated Imports and Foreign Custom Elements

On May 1, 2015, at 4:35 PM, Domenic Denicola 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 clarity: thi

Re: [components] Isolated Imports and Foreign Custom Elements

> On May 1, 2015, at 9:47 AM, Anne van Kesteren wrote: > > On Thu, Apr 23, 2015 at 8:58 PM, Maciej Stachowiak 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: >

Re: [components] Isolated Imports and Foreign Custom Elements

quot;); > // now new MyElementName(); returns an instance of "element-name" element > ``` > > You can imagine this might be useful for any custom element (either those > exported as shown above, or those defined using registerElement -- the > non-isolated custom eleme

Re: Exposing structured clone as an API?

> On Apr 23, 2015, at 3:27 PM, Martin Thomson wrote: > > On 23 April 2015 at 15:02, Ted Mielczarek wrote: >> Has anyone ever proposed exposing the structured clone algorithm directly as >> an API? > > If you didn't just do so, I will :) > >> 1. https://twitter.com/TedMielczarek/status/591315

[components] Isolated Imports and Foreign Custom Elements

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

Re: [components] Apple's consolidated feedback on Web Components

> On Apr 22, 2015, at 11:10 PM, Maciej Stachowiak 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

[components] Apple's consolidated feedback on Web Components

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

Re: Shadow tree style isolation primitive

> > ... 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.

Re: Fallout of non-encapsulated shadow trees

> On Jul 1, 2014, at 3:26 PM, Domenic Denicola > wrote: > > From: Maciej Stachowiak > >> Web Components as currently designed cannot explain the behavior of any >> built-in elements (except maybe those which can be explained with CSS alone). > > Unfortun

Re: Fallout of non-encapsulated shadow trees

> On May 15, 2014, at 6:17 AM, Anne van Kesteren 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 primitives. > >

Re: [April2014Meeting] Building an Issue and Bug focused agenda

too! > > :DG< > > > On Mon, Apr 7, 2014 at 10:55 PM, Maciej Stachowiak 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 > person

Re: [April2014Meeting] Building an Issue and Bug focused agenda

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 in, and I think I might only be able to spare the time for one of the two days, so I’d appreciate knowing which day

Re: Indexed DB: Opening connections, versions, and priority

On Feb 26, 2014, at 10:35 AM, Joshua Bell 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 the note: "

Re: Form submission participation (was Re: Goals for Shadow DOM review)

On Feb 21, 2014, at 2:28 PM, Ian Hickson 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

Re: Form submission participation (was Re: Goals for Shadow DOM review)

On Feb 21, 2014, at 11:04 AM, Ian Hickson wrote: > On Thu, 20 Feb 2014, Jonas Sicking wrote: >> On Thu, Feb 20, 2014 at 2:51 PM, Edward O'Connor wrote: >>> >>> Yeah, I think we just say that [form.elements] is the legacy feature >>> that only exposes built-in controls. form.getParticipants()

WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)

On Feb 16, 2014, at 2:16 AM, Marcos Caceres wrote: > > > On Sunday, February 16, 2014, Alex Russell wrote: > On Sat, Feb 15, 2014 at 5:56 AM, Marcos Caceres wrote: > tl;dr: I strongly agree (and data below shows) that installable web apps > without offline capabilities are essentially usele

Re: [webcomponents] Imperative API for Insertion Points

On Feb 15, 2014, at 4:57 PM, Ryosuke Niwa 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 auth

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

On Feb 14, 2014, at 7:16 PM, Boris Zbarsky 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 having the

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

On Feb 14, 2014, at 9:00 AM, Erik Arvidsson wrote: > > > > On Thu, Feb 13, 2014 at 9:00 PM, Maciej Stachowiak wrote: > > On Feb 13, 2014, at 4:01 PM, Alex Russell wrote: >> A closure is an iron-clad isolation mechanism for object ownership with >> regard

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

On Feb 13, 2014, at 4:01 PM, Alex Russell wrote: > On Thu, Feb 13, 2014 at 1:25 PM, Maciej Stachowiak wrote: > > On Feb 12, 2014, at 4:04 PM, Alex Russell wrote: > >> >> >> In discussion with Elliot and Erik, there appears to be an additional >> compl

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

On Feb 12, 2014, at 4:04 PM, Alex Russell wrote: > > > In discussion with Elliot and Erik, there appears to be an additional > complication: any of the DOM manipulation methods that aren't locked down > (marked non-configurable and filtered, ala caja) create avenues to get > elements from t

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

On Feb 11, 2014, at 4:04 PM, Dimitri Glazkov wrote: > On Tue, Feb 11, 2014 at 3:50 PM, Maciej Stachowiak wrote: > > On Feb 11, 2014, at 3:29 PM, Dimitri Glazkov wrote: > >> >> Dimitri, Maciej, Ryosuke - is there a mutually agreeable solution here? >> >

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

On Feb 11, 2014, at 3:29 PM, Dimitri Glazkov 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 the email Ryosuke c

Re: "Officially" deprecating main-thread synchronous XHR?

On Feb 7, 2014, at 9:18 AM, Jonas Sicking wrote: > On Feb 7, 2014 8:57 AM, "Domenic Denicola" > wrote: > > > > From: Olli Pettay > > > > > And at least we'd improve responsiveness of those websites which stop > > > using sync XHR because of the warning. > > > > I think this is a great point

Re: "Officially" deprecating main-thread synchronous XHR?

On Feb 7, 2014, at 9:32 AM, Scott González 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 you can use an img ele

Re: Background sync & push messaging: declarative vs imperative

On Jan 2, 2014, at 9:33 AM, John Mellor wrote: > On Thu, Dec 19, 2013 at 9:32 PM, Maciej Stachowiak wrote: > > On Dec 19, 2013, at 9:02 AM, John Mellor wrote: > >> [cross-posted to public-webapps and public-sysapps] >> >> A couple of us from Chrome have t

Re: Passsword managers and autocomplete='off'

On Dec 17, 2013, at 11:21 AM, Joel Weinberger 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 to the W3 > Web

Re: [webcomponents] Auto-creating shadow DOM for custom elements

On Dec 7, 2013, at 3:31 PM, Dominic Cooney 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 (after much reading

Re: [webcomponents] Auto-creating shadow DOM for custom elements

On Dec 7, 2013, at 1:29 PM, Domenic Denicola 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 this kind of bo

Re: [webcomponents] Auto-creating shadow DOM for custom elements

On Dec 9, 2013, at 11:13 AM, Scott Miles 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 already better > t

Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)

On Dec 10, 2013, at 12:24 PM, Elliott Sprehn wrote: > > On Tue, Dec 10, 2013 at 8:00 AM, Anne van Kesteren wrote: > On Tue, Dec 10, 2013 at 3:54 PM, Boris Zbarsky wrote: > > On 12/10/13 10:34 AM, Anne van Kesteren wrote: > >> E.g. the 's close() method won't work as defined > >> right now on

Custom form elements (was Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax))

On Dec 7, 2013, at 4:38 PM, Dominic Cooney 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 protected or > publi

Re: Passsword managers and autocomplete='off'

On Dec 12, 2013, at 11:20 AM, Joel Weinberger 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 the security

Re: [custom elements] Improving the name of document.register()

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 sa

Re: [custom elements] Improving the name of document.register()

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 wrote: > >> On Thu, Dec 12, 2013 at 5:17 AM, pira...@gmail.com wrote: >> I have seen registerProtocolHandl

Re: Beacon API

On Feb 15, 2013, at 9:21 PM, Maciej Stachowiak wrote: > > On Feb 15, 2013, at 3:51 AM, Ian Fette (イアンフェッティ) wrote: > >> Anne, >> >> Both Chrome and Safari support the ping attribute. I am not sure about IE, I >> believe Firefox has it disabled by default

Re: Beacon API

On Feb 15, 2013, at 3:51 AM, Ian Fette (イアンフェッティ) 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 to use ping w

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

On Dec 18, 2012, at 6:44 AM, Anne van Kesteren wrote: > On Tue, Oct 23, 2012 at 12:50 AM, Maciej Stachowiak 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 >&g

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Nov 29, 2012, at 12:24 PM, Elliott Sprehn wrote: > > On Wed, Nov 28, 2012 at 2:51 PM, Maciej Stachowiak wrote: > > Does this support the previously discussed mechanism of allowing either > public or private components? I'm not able to tell from the referenced >

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

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 wrote: > As of http://dvcs.w3.org/hg/webcomponents/rev/0714c60f265d, there's now an

Re: [webcomponents]: Changing API from constructable ShadowRoot to factory-like

;>>>> >>>>> B1) Using constructable ShadowRoot: >>>>> >>>>> var element = document.querySelector('div#foo'); >>>>> alert(element.shadowRoot); // null >>>>> var root = new ShadowRoot(element); >

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Nov 8, 2012, at 2:15 AM, Elliott Sprehn wrote: > > On Thu, Nov 1, 2012 at 6:43 AM, Maciej Stachowiak wrote: > > On Nov 1, 2012, at 12:41 PM, Tab Atkins Jr. wrote: > > ... > > > > For example, being able to re-render the page manually via DOM > >

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Nov 6, 2012, at 3:29 PM, Dimitri Glazkov wrote: > On Thu, Nov 1, 2012 at 8:39 AM, Tab Atkins Jr. wrote: >> >> 6) The "isolated" setting essentially means that there's a new >> document and scripting context for this shadow subtree (specifics >> TBD). Watch https://www.w3.org/Bug

Re: [webcomponents]: Changing API from constructable ShadowRoot to factory-like

Could you please provide equivalent code examples using both versions? Cheers, Maciej On Nov 7, 2012, at 10:36 AM, Dimitri Glazkov wrote: > Folks, > > Throughout the year-long (whoa!) history of the Shadow DOM spec, > various people commented on how odd the constructable ShadowRoot > pattern

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Nov 1, 2012, at 12:41 PM, Tab Atkins Jr. wrote: > On Thu, Nov 1, 2012 at 9:37 AM, Maciej Stachowiak wrote: >> On Nov 1, 2012, at 12:02 AM, Dimitri Glazkov wrote: >>> Hi folks! >>> >>> While you are all having good TPAC fun, I thought I would

Re: [webcomponents] More backward-compatible templates

On Nov 1, 2012, at 1:57 PM, Adam Barth 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 open script

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Nov 1, 2012, at 12:02 AM, Dimitri Glazkov 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 fact that > Sh

[webcomponents] More backward-compatible templates

In the WebApps meeting, we discussed possible approaches to 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 necessarily mutual

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

On Oct 22, 2012, at 3:04 PM, Chris Pearce 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 keyboard acce

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

On Oct 15, 2012, at 5:01 PM, Chris Pearce 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

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

ur app, that make it > pointless to try to use the API on that vendors browser? Anyone? > > On Mon, Oct 15, 2012 at 12:32 PM, Maciej Stachowiak wrote: > > On Oct 14, 2012, at 3:54 PM, Chris Pearce wrote: > > > On 14/10/12 00:49, Maciej Stachowiak wrote: &g

Re: full screen api

On Oct 14, 2012, at 3:52 PM, Chris Pearce 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. For most of

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

On Oct 14, 2012, at 3:54 PM, Chris Pearce 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 >> explicitl

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

On Oct 13, 2012, at 4:58 AM, Florian Bösch wrote: > On Sat, Oct 13, 2012 at 1:49 PM, Maciej Stachowiak wrote: > I think the most effective defense against phishing via fullscreen is to > prevent keyboard access. The original design for requestFullscreen had an > optional

Defenses against phishing via the fullscreen api (was Re: full screen api)

On Oct 13, 2012, at 1:49 AM, Anne van Kesteren wrote: > On Fri, Oct 12, 2012 at 8:25 PM, Florian Bösch 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 >> fullscreen is desired, shoul

Re: Moving File API: Directories and System API to Note track?

atforms, 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 Stachowiak wrote: > - I'm not keen on exposing portions of the user's filesystem. In pa

Sandboxed Filesystem use cases? (was Re: Moving File API: Directories and System API to Note track?)

On Sep 25, 2012, at 10:20 AM, James Graham 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 > one, one h

Re: Moving File API: Directories and System API to Note track?

On Sep 22, 2012, at 9:35 PM, Maciej Stachowiak wrote: > > On Sep 22, 2012, at 8:18 PM, Brendan Eich wrote: > >> >>> And two of the interfaces are generic and reusable in other contexts. >> >> Nice, and DOMRequest predates yours -- should it be done se

Re: Moving File API: Directories and System API to Note track?

On Sep 22, 2012, at 8:18 PM, Brendan Eich 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 FileSystem-like > ones? >

Re: Moving File API: Directories and System API to Note track?

On Sep 21, 2012, at 10:10 PM, Jonas Sicking 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 FileSystem drafts,

Re: Moving File API: Directories and System API to Note track?

t 5:37 PM, Maciej Stachowiak 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

Re: Moving File API: Directories and System API to Note track?

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 valu

Re: Moving File API: Directories and System API to Note track?

> -Darin > > On Thu, Sep 20, 2012 at 4:48 PM, Maciej Stachowiak wrote: > > +1 > > I don't see an indication of any major browser but Chrome planning to > implement this and expose it to the Web. > > - Maciej > > On Sep 18, 2012, at 4:04 AM, Olli Pe

Re: Moving File API: Directories and System API to Note track?

+1 I don't see an indication of any major browser but Chrome planning to implement this and expose it to the Web. - Maciej On Sep 18, 2012, at 4:04 AM, Olli Pettay wrote: > Hi all, > > > I think we should discuss about moving File API: Directories and System API > from Recommendation trac

Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

On Aug 27, 2012, at 2:07 PM, Tab Atkins Jr. wrote: > > > >> I have mixed feelings about this proposal overall, but I think it's a little >> weird to use CSS property syntax instead of markup-like attribute syntax to >> set attributes. I think this makes the syntax confusingly similar to CSS

Re: [UndoManager] Disallowing live UndoManager on detached nodes

On Aug 22, 2012, at 11:08 PM, Olli Pettay wrote: > On 08/22/2012 10:44 PM, Maciej Stachowiak wrote: >> >> On Aug 22, 2012, at 6:53 PM, Ojan Vafai > <mailto:o...@chromium.org>> wrote: >> >>> On Wed, Aug 22, 2012 at 6:49 PM, Ryosuke Niwa >> <

Re: [UndoManager] Disallowing live UndoManager on detached nodes

On Aug 22, 2012, at 6:53 PM, Ojan Vafai wrote: > On Wed, Aug 22, 2012 at 6:49 PM, Ryosuke Niwa wrote: > On Wed, Aug 22, 2012 at 5:55 PM, Glenn Maynard wrote: > On Wed, Aug 22, 2012 at 7:36 PM, Maciej Stachowiak wrote: > Ryosuke also raised the possibility of multiple text f

Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

On Aug 21, 2012, at 1:59 PM, Tab Atkins Jr. wrote: > On Tue, Aug 21, 2012 at 1:37 PM, Brian Kardell wrote: >> On Tue, Aug 21, 2012 at 4:32 PM, Tab Atkins Jr. wrote: >>> Correct. If we applied CAS on attribute changes, we'd have... problems. >> >> Because you could do something like: >> >> .

Re: [UndoManager] Disallowing live UndoManager on detached nodes

Hi folks, I wanted to mention that, in addition to the extra implementation complexity, I am not sure that multiple independent UndoManagers per page is even a good feature. The use cases document gives a use case of a text editor with an embedded vector graphics editor. But for all the nativ

URL spec parameter-related methods use "parameter" in a way inconsistent with the URI RFC

The current draft URL spec has a number of Parameter-related methods (getParameterNames, getParameterValues, hasParameter, getParameter, setParameter, addParameter, removeParameter, clearParameters)[1]. Apparently these methods refer to key-value pairs in the query part of the URL as "paramete

Re: Shrinking existing libraries as a goal

On May 17, 2012, at 10:58 PM, Jonas Sicking wrote: > On Thu, May 17, 2012 at 3:21 PM, Yehuda Katz wrote: >> I am working on it. I was just getting some feedback on the general idea >> before I sunk a bunch of time in it. > > For what it's worth, I definitely support this idea too on a general

Re: [websockets] Moving Web Sockets back to LCWD; is 15210 a showstopper?

I think it would be reasonable to defer the feature requested in 15210 to a future version of Web Sockets API. It would also be reasonable to include it if anyone feels strongly. Was a reason cited for why 15210 should be considered critical? I could not find one in the minutes. Cheers, Maciej

Re: CORS/UMP to become joint WebApps and WebAppSec joint deliverable

On Aug 2, 2011, at 4:10 AM, Anne van Kesteren wrote: > On Tue, 02 Aug 2011 12:53:49 +0200, Thomas Roessler wrote: >> Well, groups can decide to stop working on a deliverable without having to >> recharter; further, we've had separate groups work on joint deliverables in >> the past. In practi

Re: Element.create(): a proposal for more convenient element creation

On Aug 1, 2011, at 8:43 PM, Tab Atkins Jr. wrote: > On Mon, Aug 1, 2011 at 7:05 PM, Charles Pritchard wrote: >> Can we have it 'inherit' a parent namespace, and have chaining properties? >> >> Element.create('div').create('svg').create('g').create('rect', {title: 'An >> svg rectangle in an HTM

Re: Element.create(): a proposal for more convenient element creation

On Aug 1, 2011, at 8:36 PM, João Eiras wrote: > On , Ian Hickson wrote: > >> On Mon, 1 Aug 2011, Ryosuke Niwa wrote: >>> On Mon, Aug 1, 2011 at 6:33 PM, Maciej Stachowiak wrote: >>> > >>> > In an IRC discussion with Ian Hickson and Tab Atkins

Element.create(): a proposal for more convenient element creation

In an IRC discussion with Ian Hickson and Tab Atkins, we can up with the following idea for convenient element creation: Element.create(tagName, attributeMap, children…) Creates an element with the specified tag, attributes, and children. tagName - tag name as a string; by default it doe

Re: From-Origin FPWD

On Aug 1, 2011, at 10:29 AM, Hill, Brad wrote: > The ability to do all of these things server-side, with referrer checking, > has been universally available for fifteen years. (RFC 1945) > > In every one of the use cases below, From-Origin is a worse solution than > referrer checking. What

Re: From-Origin FPWD

On Jul 31, 2011, at 5:52 PM, Bjoern Hoehrmann wrote: > * Anne van Kesteren wrote: >> http://www.w3.org/TR/from-origin/ > > The proposed `From-Origin` header conveys a subset of the information > that is already available through the Referer header. From-Origin is a response header and Referer

Re: CORS/UMP to become joint WebApps and WebAppSec joint deliverable

On Jul 15, 2011, at 7:51 AM, Thomas Roessler wrote: > On Jul 15, 2011, at 16:47 , Anne van Kesteren wrote: > >> On Fri, 15 Jul 2011 14:43:13 +0200, Arthur Barstow >> wrote: >>> As indicated a year ago [1] and again at the end of last month [2], the >>> proposal to create a new Web Application

Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)

On Jun 30, 2011, at 2:07 PM, Dimitri Glazkov wrote: > On Thu, Jun 30, 2011 at 1:32 PM, Maciej Stachowiak wrote: >> >> On Jun 30, 2011, at 1:03 PM, Dimitri Glazkov wrote: >> > > In the case of extending elements with native shadow DOM, you have to > use comp

Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)

On Jun 30, 2011, at 1:03 PM, Dimitri Glazkov wrote: > Maciej, as promised on #whatwg, here's a more thorough review of your > proposal. I am in agreement in the first parts of your email, so I am > going to skip those. > >> == Are there other limitations created by the lack of encapsulation? ==

Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)

On Jun 30, 2011, at 10:57 AM, Dimitri Glazkov wrote: > Hi Maciej! > > First off, I really appreciate your willingness to get into the mix of > things. It's a hard problem and I welcome any help we can get to solve > it. > > I also very much liked your outline of encapsulation and I would like >

Re: Component Model: Landing Experimental Shadow DOM API in WebKit

On Jun 29, 2011, at 9:08 AM, Dimitri Glazkov wrote: > Hi Folks! > > With use cases (http://wiki.whatwg.org/wiki/Component_Model_Use_Cases) So I looked at this list of use cases. It seems to me almost none of these are met by the proposal at

Re: Publishing From-Origin Proposal as FPWD

On Jun 30, 2011, at 7:22 AM, Anne van Kesteren wrote: > Hi hi, > > Is there anyone who has objections against publishing > http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html as a FPWD. The > idea is mainly to gather more feedback to see if there is any interest in > taking this forw

Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)

I am not a fan of this API because I don't think it provides sufficient encapsulation. The words "encapsulation" and "isolation" have been used in different ways in this discussion, so I will start with an outline of different possible senses of "encapsulation" that could apply here. == Diffe

Re: Model-driven Views

On Apr 28, 2011, at 5:46 AM, Alex Russell wrote: > On Thu, Apr 28, 2011 at 12:09 PM, Maciej Stachowiak wrote: >> >> On Apr 28, 2011, at 2:33 AM, Jonas Sicking wrote: >> >>> >>> I agree with much of this. However it's hard to judge without a bit &g

Re: Model-driven Views

On Apr 28, 2011, at 2:33 AM, Jonas Sicking wrote: > On Thu, Apr 28, 2011 at 2:02 AM, Maciej Stachowiak wrote: >> >> On Apr 27, 2011, at 6:46 PM, Rafael Weinstein wrote: >> >>>> >>>> >>>>> >>>>> What do you think

Re: Model-driven Views

On Apr 27, 2011, at 6:46 PM, Rafael Weinstein wrote: >> >> >>> >>> What do you think? >>> >> >> - Is this something you'd like to be implemented in the browsers, > > Yes. > >> and if yes, why? What would be the reasons to not just use script >> libraries (like your prototype). > > FAQ i

Re: Cross-Origin Resource Embedding Restrictions

For what it's worth, I think this is a useful draft and a useful technology. Hotlinking prevention is of considerable interest to Web developers, and doing it via server-side Referer checks is inconvenient and error-prone. I hope we can fit it into Web Apps WG, or if not, find another goo home

Re: publish a new Working Draft of DOM Core; comment deadline March 2

On Feb 26, 2011, at 7:15 AM, Doug Schepers wrote: > > I will remove my objection to publish DOM Core if: 1) conflicts (rather than > extensions) are removed from the draft, or reconciled with changes in DOM3 > Events; and 2) for those changes that have broad consensus, we can integrate > them

Re: publish a new Working Draft of DOM Core; comment deadline March 2

On Feb 24, 2011, at 5:21 PM, Doug Schepers wrote: > Hi, Anne- > > I object to publishing a Working Draft of the DOM Core spec that includes DOM > Events. > > Introducing conflicting specifications that cover the same materials > dramatically harms interoperability, and the idea of "competing

Re: CfC: publish a new Working Draft of DOM Core; comment deadline March 2

I support this publication. - Maciej On Feb 23, 2011, at 8:20 AM, Arthur Barstow wrote: > Anne and Ms2ger (representing Mozilla Foundation) have continued to work on > the DOM Core spec and they propose publishing a new Working Draft of the spec: > > http://dvcs.w3.org/hg/domcore/raw-file/

Re: XBL2: First Thoughts and Use Cases

On Dec 15, 2010, at 11:14 AM, Boris Zbarsky wrote: > > >>> At least in Gecko's case, we still use XBL1 in this way, and those design >>> goals would apply to XBL2 from our point of view. It sounds like you have >>> entirely different design goals, right? >> >> Sounds like it. > > OK, so give

Re: Structured clone in WebStorage

On Dec 2, 2010, at 10:41 AM, Jeremy Orlow wrote: > On Thu, Dec 2, 2010 at 6:29 PM, Jonas Sicking wrote: > On Thu, Dec 2, 2010 at 5:45 AM, Arthur Barstow wrote: > > On Nov/29/2010 9:59 AM, ext Adrian Bateman wrote: > >> > >> On Wednesday, November 24, 2010 3:01 AM, Jeremy Orlow wrote: > >>> > >>

Re: Structured clone in WebStorage

On Dec 2, 2010, at 5:45 AM, Arthur Barstow wrote: > On Nov/29/2010 9:59 AM, ext Adrian Bateman wrote: >> On Wednesday, November 24, 2010 3:01 AM, Jeremy Orlow wrote: >>> For over a year now, the WebStorage spec has stipulated that >>> Local/SessionStorage store and retrieve objects per the struct

  1   2   3   4   5   >