Re: Minimum viable custom elements

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

Re: Proposal for a Permissions API

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: Fallout of non-encapsulated shadow trees

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: Starting work on Indexed DB v2 spec - feedback wanted

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: Form submission participation (was Re: Goals for Shadow DOM review)

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

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

+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)

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: [webcomponents] Imperative API for Insertion Points

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

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

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: Do we need a rendering spec?

+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

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

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:

[Shadow DOM] Simplifying level 1 of Shadow DOM

(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

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

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,

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

Art wrote: As such, this is a Call for Consensus to publish a Candidate Recommendation of Web Sockets. Ship it! :) Ted

[fullscreen] fullscreenEnabled and the fullscreen enabled flag

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: [webcomponents]: First draft of the Shadow DOM Specification

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

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

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?