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 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: Cuora amboinensis, the southeast Asian box turtle Suppose instead that TedHaitchSeven is a subclass of HTMLElement and I've registered it as . In its constructor or createdCallback or whatever, I add appropriate role and aria-level attributes. Now I can write this: Cuora amboinensis, the southeast Asian box turtle This is just as accessible as the 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: Cuora amboinensis, the southeast Asian box turtle 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 . is at least a heading, if not one of the right level. But in such a browser the 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 's implicit heading level: Cuora amboinensis, the southeast Asian box turtle I guess this is OK, but seeing aria-level=7 on and 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. Thanks, Ted
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 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 —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: http://lists.w3.org/Archives/Public/public-web-notification/2012Mar/0029.html Ted
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
>> 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.
Ted
1. http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html
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 > 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 > ( https://github.com/maxogden/level.js ) 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. Ted
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 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. Thoughts? Ted
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 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: 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 so we'd need a different attribute name. participant=foo or something. > We could even make the built-in form controls like and > 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 , 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. Ted
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 or
> , 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
submittable.
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);
theForm.addParticipant(p);
theForm.submit();
This is obviously a super hand-wavy strawman and would need to be
fleshed out. Thoughts?
Ted
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 .add/remove are a better base layer than . In fact, is straightforwardly implementable / explainable on top of MO + .add/remove, but there are several use cases that .add/remove address that are difficult or impossible with (as described in Maciej's recent email on this thread). Ted
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 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. Ted
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 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. Ted P.S. For folk who don't follow public-webapps, the thread is here: http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0101.html
[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: document.defineElement() document.declareElement() document.registerElementDefinition() document.defineCustomElement() document.declareCustomElement() document.registerCustomElementDefinition() I like document.defineCustomElement() the most, but document.defineElement() also works for me if people think document.defineCustomElement() is too long. Ted 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
(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 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 * * ? * 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] Ted 1. The lost HTML design principle: http://www.w3.org/html/wg/wiki/DesignPrinciplesReview#Baby_Steps
Re: Moving File API: Directories and System API to Note track?
Hi, Olli wrote: > I think we should discuss about moving File API: Directories and > System API from Recommendation track to Note. Sounds good to me. Ted
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, Ted
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 have their fullscreen enabled flag set, or false otherwise." 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 whatwg.org/html. Thanks, Ted
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 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 … the web author would be able to select the player's controls by writing #player::controls 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 #player::shadow(controls) or #player::custom(controls) 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! Ted 1. http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#event-retargeting-example
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: >> >> Foo >> Bar >> >> ...vs: >> >> Foo >> Bar > > Can you be a bit more specific and explain the problem you're trying > to highlight with this example? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1162 Ted
