Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

2011-09-29 Thread Edward O'Connor
If you're talking about bz's second e-mail, then consider cases such as:   pFoo   div Bar /div ...vs:   pFoo   x-div Bar /x-div Can you be a bit more specific and explain the problem you're trying to highlight with this example?

Re: [webcomponents]: First draft of the Shadow DOM Specification

2011-12-20 Thread Edward O'Connor
Hi Dimitri, You wrote: In the joyous spirit of sharing, I present you with a first draft of the Shadow DOM Specification: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html Awesome. Thanks for writing this up! Obviously, I'll have to read this more closely while hiding

[fullscreen] fullscreenEnabled and the fullscreen enabled flag

2012-05-17 Thread Edward O'Connor
Hi, Document.fullscreenEnabled is not defined in normative spec prose. It is mentioned twice in the spec: once in the IDL block at the top of §4 API, and finally in the sentence the fullscreenEnabled attribute must return true if the context object and all ancestor browsing context's documents

Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18

2012-07-11 Thread Edward O'Connor
Art wrote: As such, this is a Call for Consensus to publish a Candidate Recommendation of Web Sockets. Ship it! :) Ted

Re: Editor's draft created of DOM Parsing and Serialization Spec

2012-08-30 Thread Edward O'Connor
Hi Travis, You wrote: Folks, following up on my action item from TPAC 2011 (yeah, I know…), the DOM Parsing and Serialization Editor’s Draft specification has been created! http://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html Cool! How are you splitting the work with Ms2ger? Thanks,

[Shadow DOM] Simplifying level 1 of Shadow DOM

2013-04-25 Thread Edward O'Connor
(Resent from correct email address) Hi, First off, thanks to Dimitri and others for all the great work on Shadow DOM and the other pieces of Web Components. While I'm very enthusiastic about Shadow DOM in the abstract, I think things have gotten really complex, and I'd like to seriously propose

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

2013-12-11 Thread Edward O'Connor
Hi, The name register is very generic and could mean practically anything. We need to adopt a name for document.register() that makes its purpose clear to authors looking to use custom elements or those reading someone else's code that makes use of custom elements. Here are some ideas:

Re: Do we need a rendering spec?

2014-01-28 Thread Edward O'Connor
+CSS WG Hi Dimitri, You wrote, to the WebApps WG: As HTML imports [1] are implemented across browsers, there’s a potential for diversity of opinion in how rendering of documents with imports occurs. What blocks rendering? What doesn’t? To prevent the inevitable pain of converging on a

Re: [File System APIs] If one is good, then two must be better?

2014-01-31 Thread Edward O'Connor
Hi, Art wrote: My understanding is the only implementation of Eric's APIs is Chrome. I do not know the implementation status of Mozilla's spec. If anyone has additional information about the implementation status or plans of either effort, please let us know. With the usual disclaimer that

Re: [webcomponents] Imperative API for Insertion Points

2014-02-17 Thread Edward O'Connor
Hi Alex, You wrote: This doesn't seem like progress. I'd hope an imperative API would, instead, be used to explain how the existing system works and then propose layering that both accommodates the existing system and opens new areas for programmatic use. I think Ryosuke's

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

2014-02-20 Thread Edward O'Connor
+public-webapps, -www-tag in replies to avoid cross-posting Hi, Domenic wrote, to www-tag: [C]an shadow DOM be used to explain existing elements, like video or input type=range, in terms of a lower-level primitive? As of now, it seems like it cannot, for two reasons: 1. Native elements

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

2014-02-20 Thread Edward O'Connor
Hi Jonas, You wrote: I'm not sure if we should return a dictionary or an array. Yeah, it should be an array. The other thing is that it would be great if elements that wanted to participate in submission didn't have to manually call addParticipant. Yes. This could be done by having the

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

2014-02-21 Thread Edward O'Connor
Hi, Ryosuke wrote: What if we added formparticipant boolean content attribute and fired formdata event during form submission to serialize data? This way, we can add more events like validate to support more features of builtin form elements. Hmm, right, validation. In the model I have in

Re: Starting work on Indexed DB v2 spec - feedback wanted

2014-04-29 Thread Edward O'Connor
Hi, Tim wrote: Personally, the main thing I want to see is expose simpler and lower level APIs. For my uses (backend to git server), the leveldb API is plenty powerful[…] Would it make sense to standardize on a simpler set of APIs similar to what levelDB offers and expose that in addition to

Re: Fallout of non-encapsulated shadow trees

2014-07-01 Thread Edward O'Connor
Hi, Maciej said: I agree with the need for encapsulation in Web Components and have been arguing for it for a long time. Currently, despite agreement dating back several years, it doesn’t even offer a mode with better encapsulation. Now that the non-encapsulation version has shipped in

Re: Proposal for a Permissions API

2014-09-04 Thread Edward O'Connor
Hi, Mounir wrote: Permissions API would be a single entry point for a web page to check if using API /foo/ would prompt, succeed or fail. It would be a mistake to add such an API to the platform. A unified API for explicit permissioning is an attractive nuisance which future spec authors will

Re: Minimum viable custom elements

2015-01-15 Thread Edward O'Connor
Hi all, Steve wrote: [I]t also does not address subclassing normal elements. Again, while that seems desirable Given that subclassing normal elements is the easiest and most robust method (for developers) of implementing semantics[1] and interaction support necessary for accessibility I