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 would suggest it is undesirable
 to punt on it.

Apologies in advance, Steve, if I'm missing something obvious. I
probably am.

I've been writing an article about turtles and I've gotten to the point
that six levels of headings aren't enough. I want to use a seventh-level
heading element in this article, but HTML only has h1–6. Currently,
without custom elements, I can do this:

div role=heading aria-level=7Cuora amboinensis, the southeast Asian box 

Suppose instead that TedHaitchSeven is a subclass of HTMLElement and
I've registered it as ted-h7. In its constructor or createdCallback or
whatever, I add appropriate role and aria-level attributes. Now I can
write this:

ted-h7Cuora amboinensis, the southeast Asian box turtle/ted-h7

This is just as accessible as the div was, but is considerably more
straightforward to use. So yay custom elements!

If I wanted to use is= to do this, I guess I could write:

h1 is=ted-h7Cuora amboinensis, the southeast Asian box turtle/h1

How is this easier? How is this more robust?

I think maybe you could say this is more robust (if not easier) because,
in a browser with JavaScript disabled, AT would see an h1. h1 is at
least a heading, if not one of the right level. But in such a browser
the div example above is even better, because AT would see both that
the element is a heading and it would also see the correct level.

OK, so let's work around the wrong-heading-level-when-JS-is-disabled
problem by explicitly overriding h1's implicit heading level:

h1 is=ted-h7 aria-level=7Cuora amboinensis, the southeast Asian box 

I guess this is OK, but seeing aria-level=7 on and h1 rubs me the
wrong way even if it's not technically wrong, and I don't see how this
is easier or more robust than the other options.


Re: Proposal for a Permissions API

2014-09-04 Thread Edward O'Connor

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 be drawn to.

We should be avoiding adding features to the platform that have to
resort to explicit permissioning. Instead of adding features which
require prompting for permission, we should be designing features—like
drag  drop or input type=file—that don't require prompting for
permission at all.

I don't think much has changed since this last came up, in the context
of Notifications:


Re: Fallout of non-encapsulated shadow trees

2014-07-01 Thread Edward O'Connor

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
 Chrome, it may be hard to change other than by renaming everything.

 Web Components as currently designed cannot explain the behavior of
 any built-in elements (except maybe those which can be explained with
 CSS alone).

Domenic replied:

 From what I remember, you were arguing for some kind of soft
 encapsulation, which could be broken by e.g. overwriting
 Object.getOwnPropertyDescriptor [etc…]

Type 2 encapsulation (Encapsulation against deliberate access in
Maciej's original email[1]) isn't a security boundary protecting the
component from the containing page. Type 2 is simply the idea that we
should not provide API for outside code to poke into the component's
shadow DOM without some kind of explicit buy-in (exporting, etc.) by the
component's author. Page authors could hack around it and get at the
internals if they really, really wanted to. But their code to do this
would look bad and they should feel bad for writing it. :)

Exposing the shadow DOM of an element to everyone with API means that
the entire contour of that DOM is now API. That's bad. Half the point of
having a component model is to allow component authors to hide their
implementation details so they can change them without breaking people
using their component.

 But soft encapsulation is just as useless for explaining the platform
 as no encapsulation at all.

I think just as useless overstates your case. Type 2 allows you to
hide implementation details of your component from authors better than
Type 1 does. Yes, it's not isolation for security purposes, so it
doesn't get you the whole way, but like Brendan said, we shouldn't let
the perfect be the enemy of the good.



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

2014-04-29 Thread Edward O'Connor

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
 what indexedDB currently exposes? Or would this make sense as a new
 API apart from IDB?

I think it would be a mistake to grow the existing IndexedDB API to be
more LevelDB-y.

Keep in mind that some IndexedDB implementations are built on top of
LevelDB. We don't want to repeat the mistake of Web SQL Database, where
the Web-exposed API surface depended on the UA using a particular
version of SQLite as its backend.

Also, one of the goals of the IndexedDB API was to provide a substrate
on which database APIs could be built. Like Joshua wrote:

 You may want to try prototyping this on top of Indexed DB as a
 library, and see what others think.

Apparently this already exists:

 The level / node.js community already build a prototype on top of IDB
 ( )

We should certainly ensure that the IndexedDB API is rich enough to let
many such libraries be built on top of it. We should avoid changing it
in ways that favor a particular backend implementation strategy.


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

2014-02-21 Thread Edward O'Connor

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 my head, there are
roughly two kinds of custom form participants: custom form controls
(probably implemented with custom elements  other web components
features) and application state (JS objects with no corresponding DOM
presence but that nevertheless should be submittable).

Suppose in the first case we add a nonconfigurable boolean property to
Element. The engine inspects this property to determine validity, and
it's the responsibility of the component to keep the property up to
date. That way, we don't have to invoke userland JS when performing form
validation or when resolving :valid/:invalid style rules.

In the second case, I think we can just punt completely—form
participants that aren't Elements don't participate in validation, only
submission. Because it's the application's responsibility for
maintaining its own state, there's no sensible visual location in the
document to display a validation error, and no no-application-specific
way for the user to resolve the issue.



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


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 have extra capabilities which are not granted by
 shadow DOM, or by custom elements. For example, they can participate
 in form submission.

Authors need to be able to participate in form submission, but this is
independent of Custom Elements.

Web applications often maintain state in JS objects that have no direct
DOM representation. Such applications may want such state to be

Existing form elements map one field name to many values. People often
build custom controls precisely because those controls hold more
complex values that would be better represented as many names to many
values. Subclassing existing form elements don't get you this.

And inheriting from HTMLInputElement is insane (not because inheriting
is insane, but because HTMLInputElement is insane), so that's not really
how we want author-defined objects to become submittable.

Given the above I don't think we should try to solve the how authors
can participate in form submission problem by enabling the subclassing
of existing form elements. Instead, we should define a protocol
implementable by any JS object, which allows that JS object to expose
names and values to the form validation and submission processes.

Something like this:

  function Point(x, y) {
this.x = x;
this.y = y;
  Point.prototype.formData = function() {
return {
  x: this.x,
  y: this.y

  var theForm = document.querySelector(#my-form);

  var p = new Point(4,2);


This is obviously a super hand-wavy strawman and would need to be
fleshed out. Thoughts?


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.


 This could be done by having the form element attempt check for a
 .formData property on any descendant that was added, and add any
 elements that has such a property as a participant automatically.

That doesn't handle this case:

formp contenteditable/form

I'd like a way to declaratively say that that contenteditable
participates with name foo.

The obvious thing would be to literally add name=foo, but that doesn't
work because of

forma name=foo/a/form

so we'd need a different attribute name. participant=foo or something.

 We could even make the built-in form controls like input and
 select have a .formData() function which returns data in whatever
 format we decide is the right one.

Right. toFormData() or the like, parallel to toJSON().

 The only tricky part is that form.controls is a live array. I don't
 see a way of making form.controls contain custom elements without
 synchronously running getters whenever an element is added as a
 descendant of a form, which is not something we want to do. But live
 arrays are evil anyway so we can probably just ignore integration with
 that and instead add a form.getParticipants() function which returns a
 non-live array of all participants.

Yeah, I think we just say that form.controls is the legacy feature that
only exposes built-in controls. form.getParticipants() works for me.


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 content.add/remove are a better base layer than
content select. In fact, content select is straightforwardly
implementable / explainable on top of MO + content.add/remove, but
there are several use cases that content.add/remove address that are
difficult or impossible with content select (as described in Maciej's
recent email on this thread).


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

2014-01-31 Thread Edward O'Connor

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 we don't comment on future plans or
product releases, we prefer the approach Jonas  Arun have taken in
their API to that of the File API: Directories and System document.


Re: Do we need a rendering spec?

2014-01-28 Thread Edward O'Connor

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 de-facto standard behavior, it would be
 super-nice to have precise documentation of when the rendering engine
 should start (and stop) rendering the document.

 The specific problem we (the imports people) are interested in is “when
 do things first appear on screen?”, and we could definitely hack up some
 vague informative prose in the HTML Imports spec in the short term.

 But long-term, do we (the W3C people) want a rendering spec?

When this has come up in the past, the CSS WG has chosen not to do this.
If you think the platform needs such a spec, I encourage you to engage
with the layout and rendering experts of the CSS WG to make your case.


P.S. For folk who don't follow public-webapps, the thread is here:

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

2013-12-11 Thread Edward O'Connor

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:


I like document.defineCustomElement() the most, but
document.defineElement() also works for me if people think
document.defineCustomElement() is too long.


P.S. Sorry for the bikeshedding. I really believe we can improve the
name of this function to make its purpose clear.

[Shadow DOM] Simplifying level 1 of Shadow DOM

2013-04-25 Thread Edward O'Connor
(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 that we simplify the feature
for 1.0, and defer some complexity to the next level.

I think we can address most of the use cases of shadow DOM while
seriously reducing the complexity of the feature by making one change:
What if we only allowed one insertion point in the shadow DOM? Having
just 1 insertion point would let us push (most? all?) of this complexity
off to level 2:

* distribution, getDistributedNodes(), etc.
* selector fragments  matching criteria
* /select/ combinator
* content select
* shadow ?
* reprojection

Notably, I don't think insertion point(s) get used (much or at all) in
WebKit's internal shadow trees, so I don't think all of the above
complexity is worth it right now. Baby Steps.[1]


1. The lost HTML design principle:

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!

Cool! How are you splitting the work with Ms2ger?


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! :)


[fullscreen] fullscreenEnabled and the fullscreen enabled flag

2012-05-17 Thread Edward O'Connor

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 have their fullscreen enabled flag set, or false

I expected to find a sentence like (but clearer than) the following
somewhere in §3 Model or §4 API: All documents have a fullscreenEnabled
property which, if true, signals that it is possible for elements within
the given document to enter fullscreen mode.

Also, §3 Model claims that HTML defines under what conditions the
fullscreen enabled flag is set, but I found no mention of this flag in


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:

Awesome. Thanks for writing this up! Obviously, I'll have to read this
more closely while hiding upstairs at my in-law's house next week. That
said, I wanted to quickly note something I noticed while skimming this
just now.

In your Event Retargeting Example[1], you have a pseudo= attribute
which allows the author of the shadow DOM to specify the name of a
pseudo-element which will match that element. For example, in

div id=player
div pseudo=controls

the web author would be able to select the player's controls by writing


I'm worried that users may stomp all over the CSS WG's ability to mint
future pseudo-element names. I'd rather use a functional syntax to
distinguish between custom, user-defined pseudo-elements and
engine-supplied, CSS WG-blessed ones. Something like


could do the trick. The latter (or some other, non-shadow-DOM-specific
name) is potentially more exciting because there may be more use cases
for author-supplied pseudo-elements than just the shadow DOM. For
instance, I could imagine an extension to DOM Range which would allow a
user to name a range for selector matching.

Anyway, thanks for the writeup, and have a wonderful break!



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:

   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?