Re: [clipboard-api] Do paste events and company bubble?
They are indeed cancelable and bubble-able, as shown in Example 1 under the Clipboard event interfaces section.[1] There are also a number of references to canceling the events under the Processing model section.[2] That said, yes, you are absolutely correct that this fact should be explicitly called out somewhere as well. [1] http://dev.w3.org/2006/webapi/clipops/clipops.html#clipboard-event-interfaces [2] http://dev.w3.org/2006/webapi/clipops/clipops.html#processing-model Sincerely, James Greene Sent from my [smart?]phone On Mar 8, 2014 1:20 AM, Boris Zbarsky bzbar...@mit.edu wrote: The clipboard API draft [1] doesn't seem to say whether paste events, or any other events fired by fires a clipboard event bubble. Or whether they're cancelable, for that matter. Presumably it should say something on the matter. -Boris [1] http://dev.w3.org/2006/webapi/clipops/clipops.html#paste-event
[webcomponents] Editable Web Components
Web Applications Working Group, Greetings. I would like to broach some ideas for web components including in response to Web Components in 2014 (http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0338.html). The ideas pertain to web components (http://www.w3.org/TR/components-intro/ , http://www.polymer-project.org/) and HTML5 editing (http://www.w3.org/TR/html5/editing.html). Component technologies have included runtime and designtime modes. Solutions for editable components include designtime, or editable, document object models and shadow document object models, where nested runtime web components could map to nested designtime web components. Other solutions include web intents (http://webintents.org/ , http://webintents.org/edit) and other implementations towards OLE (http://en.wikipedia.org/wiki/Object_Linking_and_Embedding) or OpenDoc (http://en.wikipedia.org/wiki/OpenDoc) functionality. Scenarios for editable web components include wiki technologies (http://en.wikipedia.org/wiki/Wiki , http://en.wikipedia.org/wiki/Category:Wikipedia_templates , http://meta.wikimedia.org/wiki/Help:Advanced_templates). I would like to also introduce the Collaborative Software Community Group (http://www.w3.org/community/groups/proposed/#collaboration) and to welcome others to support the group as well as to participate. The mission of the Collaborative Software Community Group is to provide a forum for experts in collaborative software and groupware for technical discussions, gathering use cases and requirements to align the existing formats, software, platforms, systems and technologies (e.g. wiki technology) with those used by the Open Web Platform. The goal is to ensure that the requirements of collaborative technology and groupware can be answered, when in scope, by the Recommendations published by W3C. This group is chartered to publish documents when doing so can enhance collaborative technology and groupware. The goal is to cooperate with relevant groups and to publish documents to ensure that the requirements of the collaborative software and groupware community are met. Kind regards, Adam Sobieski
[webcomponents] Semantics and Web Components
Web Applications Working Group, Greetings. I would like to also indicate an article at the Argumentation Community Group which broached web components and semantics (http://www.w3.org/community/argumentation/2014/02/23/document-and-package-semantics-and-metadata/). The topics of web components and graph-based data could be, in a collaborative software context, pertinent to Semantic Wiki (http://en.wikipedia.org/wiki/Semantic_wiki , https://www.mediawiki.org/wiki/Google_Summer_of_Code_2014#Semantic_MediaWiki) and to the Collaborative Software Community Group (http://www.w3.org/community/groups/proposed/#collaboration). Kind regards, Adam Sobieski
Re: Extending Mutation Observers to address use cases of
On Feb 12, 2014, at 11:23 AM, Rafael Weinstein rafa...@google.com wrote:
I pushed the Web Components folks about exactly this issue (why aren't these
callbacks just MutationObservers?) early last year. They convinced me (and I
remain convinced) that these signals should be Custom Element callbacks and
not Mutation Observer records
Here's the logic that convinced me: Custom Element are a *strongly coupled
concern*, while Mutation Observers *allow for* multiple decoupled concerns to
peacefully co-exist.
In a certain sense, you can extend the argument that CE callbacks should be
MO records, and you arrive at the conclusion that you don't need Custom
Elements at all -- that everything can be implemented with Mutation
Observers. But the point of Custom Elements is two fold:
1) To allow implementation of Elements by user-space code in roughly the same
model as privileged code.
2) To explain the platform.
Put another way: the *implementation* of an element simply needs to be
privileged in some respects. For custom elements, this means
a) There can only be one. I.e., we don't allow multiple registration of the
same element: Primary behavior is the domain of custom elements, secondary
behavior is the domain of Mutation Observers
b) Callbacks need to fire ASAP. It's important that the implementation of an
element get a chance to respond to events before other concerns so that it
can create a synchronously consistent abstraction
To my mind, Custom Elements callbacks really *should* be fully sync (yes,
including firing createdCallback during parse), but various technical and
security constraints make that impossible.
I’ve thought about this problem, and I don’t see why takeMutationRecords won’t
be adaquate for this use case.
Since custom elements implement their own interfaces, why can’t they call
takeRecords() in the methods that require consistent state?
e.g.
class MyButton {
function someMethod() {
updateStates();
}
...
function updateStates() {
var records = this._subtreeObserver.takeRecords();
...
}
}
This is analogous to how modern Web browser engines resolve styles and update
layout lazily. It’s true that this would require extra line of code in every
method that require consistent state but it has major benefits:
Web developers have a control over when internal states need to be updated
Performance cost is transparent to Web developers
Methods that don’t require updating internal states will be fast
- R. Niwa
