If you're talking about bz's second e-mail, then consider cases such as:
div Bar /div
x-div Bar /x-div
Can you be a bit more specific and explain the problem you're trying
to highlight with this example?
In the joyous spirit of sharing, I present you with a first draft of
the Shadow DOM Specification:
Awesome. Thanks for writing this up! Obviously, I'll have to read this
more closely while hiding
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
As such, this is a Call for Consensus to publish a Candidate
Recommendation of Web Sockets.
Ship it! :)
Folks, following up on my action item from TPAC 2011 (yeah, I know…),
the DOM Parsing and Serialization Editor’s Draft specification has
Cool! How are you splitting the work with Ms2ger?
(Resent from correct email address)
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
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:
You wrote, to the WebApps WG:
As HTML imports  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
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
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
+public-webapps, -www-tag in replies to avoid cross-posting
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
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.
This could be done by having the
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
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
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
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
[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 and interaction
support necessary for accessibility I
Mail list logo