Re: Request for feedback: Streams API
Thanks. ByteStream is already partially implemented in Blink/Chromium. As one of implementors, I'll continue prototyping and share issues here. I haven't got time for, but writing some polyfill might be also good thing to do. Takeshi On Thu, Dec 5, 2013 at 2:38 AM, Kenneth Russell k...@google.com wrote: Looks great! Seems very well thought through. The API seems large enough that it would be worth prototyping it and writing test applications to make sure it addresses key use cases before finalizing the spec. -Ken On Wed, Dec 4, 2013 at 8:27 AM, Feras Moussa feras.mou...@hotmail.com wrote: The editors of the Streams API have reached a milestone where we feel many of the major issues that have been identified thus far are now resolved and incorporated in the editors draft. The editors draft [1] has been heavily updated and reviewed the past few weeks to address all concerns raised, including: 1. Separation into two distinct types -ReadableByteStream and WritableByteStream 2. Explicit support for back pressure management 3. Improvements to help with pipe( ) and flow-control management 4. Updated spec text and diagrams for further clarifications There are still a set of bugs being tracked in bugzilla. We would like others to please review the updated proposal, and provide any feedback they may have (or file bugs). Thanks. -Feras [1] https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm
Re: Comments on version web-apps specs from 2013-10-31
Thanks for feedback. On Thu, Nov 21, 2013 at 4:56 PM, Feras Moussa feras.mou...@hotmail.comwrote: Hi Francois, Thanks for the feedback. From: francois-xavier.kowal...@hp.com To: public-webapps@w3.org Date: Wed, 20 Nov 2013 20:30:47 + Subject: Comments on version web-apps specs from 2013-10-31 Hello I have a few comments on: https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm from 2013-10-31. Apologies wether it is not the latest version: It took me some time to figure-out where was the right forum to send these comments to. Section 2.1.3: 1. Close(): For writeable streams, the close() method does not provide a data-completion hook (all-data-flushed-to-destination), unlike the close method that resolved the Promise returned by read(). The version of the spec you linked doesn't differentiate writeable/readable streams, but is something we are considering adding in a future version. I don't quite understand what you're referring to here. close is independent of future reads - you can call a read after close, and once EOF is reached, the promise is resolved and you get a result with eof=true. writeClose() we have now is still void. In current API, fulfillment of writePromise doesn't necessarily mean acknowledgement (data written has been successfully processed) but implmentor may give such a meaning to it in the following two ways: - fulfill writePromise when the written data is successfully consumed - make writeClose return a Promise, say closePromise. writePromise may be fulfilled before processing but writeClose is fulfilled only when all the data written has been successfully consumed I think it makes sense to change writeClose() type to Promiseundefined so that derived classes may choose to use it to notify the writer of success. 2. Pipe(): the readable Steam (the one that provides the pipe() method) is neutered in case of I/O error, but the state change of the writeable stream is not indicated. What if the write operation failed? Are you asking what the chain of error propagation is when multiple streams are chained? Error handling is not yet well documented but I plan to make write operation failure result in rejection of pipePromise. Section 3.2: 1. Shouldn't a FileWrite also be capable of consuming a Stream? (Like XHR-pipe-to-FileWriter) Yes, I think so - this is a use case we can add. Added to the possible consumer list. 2. Shouldn't an XMLHttpRequest also be capable of consuming a Stream? (eg. chunked PUT/POST)? Section 5.4 covers this - support for posting a Stream. That said, this is a section I think will need to be flushed out more. Added in recent commit. br. —FiX PS: My request to join this group is pending, so please Cc me in any reply/comment you may have until membership is fixed.
Re: inline declarative manifest, was Re: New manifest spec - ready for FPWD?
On 9 December 2013 09:33:47 Yoav Weiss y...@yoav.ws wrote:
IMO, it might be better not to define an explicit way to inline the
manifest, and let authors simply use data URIs to do that, if they see such
a need.
e.g. link rel=manifest href=data:application/manifest+json,{ ... }
If this becomes a common authoring pattern, an explicit mechanism might be
a good fit. Otherwise, there may not be a need.
My suggestion is to define manifest in terms of meta and link elements
whenever possible (e.g. manifest name duplicates meta application-name
defined in HTML and there are other overlapping meta tags and link relations).
This will reduce spec duplication/overlap/conflicts and at the same time
provide basic inline manifest equivalent and gradual migration path for
pages that currently use meta tags (if author decides that their meta tags
take too much space they can migrate the tags to an external manifest).
Here's bug for this: https://github.com/w3c/manifest/issues/97
--
regards, Kornel
Re: New manifest spec - ready for FPWD?
On Wed, Dec 4, 2013, at 10:03, Marcos Caceres wrote: From the research we’ve done, none of the proprietary solutions currently do this. I’ve added this as a feature request [1] so we can see how much interest there is. I think it is exaggerated to say that pages rely on the user seeing the page title. It is very uncommon to be able to read more than a couple of words and depending on your browser/system you might not even see the page title at all (the case for me because I rarely have less than a dozen tabs open). I think the back button and reload buttons might be critical to be able to run some apps while the page title is simply a nice to have. -- Mounir
Fwd: Re: Please review the updated Streams API
Rob Manson sent out a request to the WEBRTC WG's mailing list for review of the implications of the Stream API to WEBRTC. Arthur Barstow asked for comments to be sent to public-webapps@w3.org, so I'm forwarding my response here. Original Message Subject:Re: Please review the updated Streams API Resent-Date:Sun, 08 Dec 2013 16:10:27 + Resent-From:public-web...@w3.org Date: Sun, 08 Dec 2013 17:09:54 +0100 From: Harald Alvestrand har...@alvestrand.no To: Rob Manson rob...@mob-labs.com, public-web...@w3.org Thank you for posting the link. As written, this specification shows how to send an uninterpreted, unsegmented stream of bytes over an API interface. Since none of our interfaces (except possibly the output of the Recorder interface) is specified in terms of uninterpreted, unsegmented streams of bytes, I don't think this is particularly useful to the APIs specified by this working group. Thank you very much for explicitly naming the types you're specifying 'ByteStream' so that it is trivial to see that this is the abstraction that this specification is relevant to. On 12/05/2013 11:06 AM, Rob Manson wrote: Hi, if you didn't see my earlier post to public-media-capture, there's an updated W3C Streams API draft available for review and I've been asked to also notify this WG to get your feedback on it's implications for MediaStream, MediaStreamTrack, RTCPeerConnection and RTCDataChannels. https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm I'd encourage you all to review it and provide any feedback or thoughts you might have. As I mentioned in my post to public-media-capture, Feras and Takeshi have been doing a great job integrating and filtering all the feedback they've received and I've personally been pushing for as much focus on making it as effective and useful for post-processing as possible. I'm sure many of you here have a different perspective they would find very valuable. Below is the email Feras sent to describe where this work is up to. roBman On 12/4/13 11:27 AM, ext Feras Moussa wrote: The editors of the Streams API have reached a milestone where we feel many of the major issues that have been identified thus far are now resolved and incorporated in the editors draft. The editors draft [1] has been heavily updated and reviewed the past few weeks to address all concerns raised, including: 1. Separation into two distinct types -ReadableByteStream and WritableByteStream 2. Explicit support for back pressure management 3. Improvements to help with pipe( ) and flow-control management 4. Updated spec text and diagrams for further clarifications There are still a set of bugs being tracked in bugzilla. We would like others to please review the updated proposal, and provide any feedback they may have (or file bugs). Thanks. -Feras [1] https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm
Re: inline declarative manifest, was Re: New manifest spec - ready for FPWD?
On Mon, Dec 9, 2013, at 20:33, Yoav Weiss wrote:
IMO, it might be better not to define an explicit way to inline the
manifest, and let authors simply use data URIs to do that, if they see
such
a need.
e.g. link rel=manifest href=data:application/manifest+json,{ ... }
If this becomes a common authoring pattern, an explicit mechanism might
be
a good fit. Otherwise, there may not be a need.
Sounds like a good plan to me.
-- Mounir
Re: [webcomponents] Auto-creating shadow DOM for custom elements
Domenic Denicola a few messages back gave a highly cogent explanation of
the exact line of thinking arrived at last time we went through all this
material.
I'm not wont to try to summarize it here, since he said it already better
there. Perhaps the short version is: nobody knows what the 'standard use
case' is yet.
In previous adjudications, the straw that broke that camel's back was with
respect to handling auto-generation with inheritance. Shadow-roots may need
to be generated for each entry in the inheritance chain. Having the system
perform this task takes it out of the control of the user's code, which
otherwise has ability to modulate calls to super-class methods and manage
this process.
class XFoo {
constructor_or_createdCallback: function() {
// my shadowRoot was auto-generated
this.doUsefulStuffLikeDatabinding(this.shadowRoot);
}
}
class XBar extends XFoo {
constructor_or_createdCallback: function() {
super(); // uh-oh, super call operates on wrong shadowRoot
}
}
Scott
On Mon, Dec 9, 2013 at 7:20 AM, Brian Kardell bkard...@gmail.com wrote:
+public-nextweb _ i encourage folks there to check out
public-webapps@w3.org as this conversation is deep and multi-forked and I
am late to the party.
On Dec 7, 2013 4:44 PM, Brendan Eich bren...@secure.meer.net wrote:
What does polymer do? Cows are already treading paths.
I still smell a chance to do better out of the gate (gave, thanks
autospellcheck! lol). Call me picky. Knee-jerking about scenario solving (I
think I taught Yehuda that one) doesn't help. Particular response, please.
/be
I think the most important part is to first ensure that we -can- explain
the magic with core apis even if they are initially saltier than we'd all
like. When reasonable opportunities present themselves to improve
developer ergonomics, we should take them - it doesn't preclude other
opportunities for better flowers to bloom.
The issues in this specific case in my mind surround the observation that
it feels like it is attempting to bind several layers together which are in
various states of done and conceptually what we have is more like a
squirrel path than a cow path on this piece. Without bindings or some kind
of pattern for solving those use cases, template is a less thing - and i
think we are far from that.Templates aren't necessary for a useful
document.register(). Shadow DOM isn't either but it's more obvious where
the connections are and it seems considerably more stable. There also
isn't necessarily a 1:1 relationship of component to template, so we have
to be careful there lest we add confusion. Is this really a ShadowHost?
I am not actually sure that the initial message in this thread really
needs to have anything particular to the template element though, it looks
like the optional third argument could be any Node - and that does actually
seem to describe a useful and common pattern which we could easily explain
in existing terms and it might be fruitful to think about that.
Re: [webcomponents] Auto-creating shadow DOM for custom elements
I'm late to the party...so pardon if this is a dumb idea but
Could the solution to this problem be as simple as adding an
applyTemplate callback to the lifecycle and prohibiting access to the
shadowRoot prior to that point in time?
On Mon, Dec 9, 2013 at 2:13 PM, Scott Miles sjmi...@google.com wrote:
Domenic Denicola a few messages back gave a highly cogent explanation of
the exact line of thinking arrived at last time we went through all this
material.
I'm not wont to try to summarize it here, since he said it already better
there. Perhaps the short version is: nobody knows what the 'standard use
case' is yet.
In previous adjudications, the straw that broke that camel's back was with
respect to handling auto-generation with inheritance. Shadow-roots may need
to be generated for each entry in the inheritance chain. Having the system
perform this task takes it out of the control of the user's code, which
otherwise has ability to modulate calls to super-class methods and manage
this process.
class XFoo {
constructor_or_createdCallback: function() {
// my shadowRoot was auto-generated
this.doUsefulStuffLikeDatabinding(this.shadowRoot);
}
}
class XBar extends XFoo {
constructor_or_createdCallback: function() {
super(); // uh-oh, super call operates on wrong shadowRoot
}
}
Scott
On Mon, Dec 9, 2013 at 7:20 AM, Brian Kardell bkard...@gmail.com wrote:
+public-nextweb _ i encourage folks there to check out
public-webapps@w3.org as this conversation is deep and multi-forked and
I am late to the party.
On Dec 7, 2013 4:44 PM, Brendan Eich bren...@secure.meer.net wrote:
What does polymer do? Cows are already treading paths.
I still smell a chance to do better out of the gate (gave, thanks
autospellcheck! lol). Call me picky. Knee-jerking about scenario solving (I
think I taught Yehuda that one) doesn't help. Particular response, please.
/be
I think the most important part is to first ensure that we -can- explain
the magic with core apis even if they are initially saltier than we'd all
like. When reasonable opportunities present themselves to improve
developer ergonomics, we should take them - it doesn't preclude other
opportunities for better flowers to bloom.
The issues in this specific case in my mind surround the observation that
it feels like it is attempting to bind several layers together which are in
various states of done and conceptually what we have is more like a
squirrel path than a cow path on this piece. Without bindings or some kind
of pattern for solving those use cases, template is a less thing - and i
think we are far from that.Templates aren't necessary for a useful
document.register(). Shadow DOM isn't either but it's more obvious where
the connections are and it seems considerably more stable. There also
isn't necessarily a 1:1 relationship of component to template, so we have
to be careful there lest we add confusion. Is this really a ShadowHost?
I am not actually sure that the initial message in this thread really
needs to have anything particular to the template element though, it looks
like the optional third argument could be any Node - and that does actually
seem to describe a useful and common pattern which we could easily explain
in existing terms and it might be fruitful to think about that.
--
Rob Eisenberg,
President - Blue Spire
www.durandaljs.com
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Dec 8, 2013, at 4:42 PM, Dominic Cooney domin...@google.com wrote: On Sun, Dec 8, 2013 at 7:25 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 7, 2013, at 4:38 PM, Dominic Cooney domin...@google.com wrote: On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 5, 2013, at 10:09 PM, Hajime Morrita morr...@google.com wrote: On inheritance around HTMLElement family, there seems to be a confusion between interface side inheritance and implementation side inheritance. Right. Differentiating the two is very important. For Custom Elements, the inheritance is not only about interface, but also about implementation. The implementation is more complex and flux in detail, thus worth being shared between different elements. Actually, the implementation of built-in HTML elements, which are usually done in C++, uses inheritance heavily, at least Blink and (I believe) WebKit. The reason we can use inheritance heavily is because we have control over both parent and child classes, and there are careful distinctions between public, protected, and private member functions and member variables in those classes. Unfortunately, custom elements can't easily inherit from these builtin HTML elements because builtin elements do not provide protected functions, and they don't expose necessary hooks to override internal member functions to modify behaviors. Built-in HTML elements have lots of hooks to modify their behaviour (for example, HTMLVideoElement's autoplay attribute.) The analogy is extending a Java class which has private and public final members, but no protected or public non-final ones. If someone were to make proposals about adding more hooks to the web platform to enable more subtyping use cases (for example, a protocol for participating in form submission) I would look forward to working with them on those proposals. The problem here is that until such hooks are well defined, inheriting from builtin elements doesn't make any sense. So let's not support that until such proposal is made and implemented. You assert that inheriting from built-in elements does not make any sense. You seem to base this on the claim that hooks (the example being form submission protocol hooks) are not well defined. Whether hooks are well defined or not doesn't sufficiently support your assertion, because: 1. Not all subtyping relies on hooks. For example, subtyping a built-in element can add additional API to it. This may make sense. For example, a social network endorse button has a number of additional properties. Yet it is (or could be) a button. If the only use case was to add new JavaScript property, then we wouldn't need custom elements at all. Authors could already do this by simply adding properties on builtin elements. As for the social endorse button, I've never seen a popular SNS share buttons implemented using HTML button elements; most of them add their own DOM to add icons, etc... 2. The premise that hooks are not defined is also incorrect. Many hooks are already defined. Here is one example: the INPUT element has input and change events and a value property. These are sufficient to observe, filter and change the value of the INPUT element. This can't possibly be an explanation for whether hooks are well defined or not doesn't sufficiently support your assertion. HTML input elements have a lot more internal states than just the value. To list a few: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#concept-input-value-dirty-flag http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#concept-input-checked-dirty-flag In mentioning hooks, was merely observing that we could define more hooks to enable even more use cases. In addition, consider how inheriting views work in AppKit, UIKit, .net and MFC. When a view T inherits from another view S, T doesn't simply put S into a subregion of T; S intrudes into T's view and modifies what's been displayed or places extra content after or before T draws itself. I can not discern a specific point you are making here. You are drawing an analogy to various UI frameworks but you have not completed the analogy. I think if you completed the analogy it would end up being a claim about Shadow DOM. You may have confused extending an element and having Shadow DOM. As Rafael Weinstein points out here: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0883.html, whether an element has Shadow DOM is orthogonal to whether it is a Custom Element or not. I also disagree with your implied argument about Shadow DOM. Then we simply continue to disagree about this point. I have a hard time understanding how this bizarre mixture of inheritance and composition is considered as the minimal subset of features while adding one optional argument to document.register to
[Bug 24042] New: [imports]: Parser should not wait on external resources inside imports
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24042 Bug ID: 24042 Summary: [imports]: Parser should not wait on external resources inside imports Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: espr...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 20683 The HTML parser should continue tree building inside an import even if blocked on an external resource. As a result document.write() should also throw when the currentScript is inside an import since the location of the write is arbitrary. The result of this is that given: link rel=import href=1.html script src=slow.js/script link rel=import href=2.html link rel=import href=3.html x-foo/x-foo script console.log(1); /script While slow.js is being downloaded the entire import tree (1.html, 2.html and 3.html) can be processed and constructed into DOM trees. When it finishes loading the scripts that were queued while tree building these nested imports and the top level import with the console.log should be executed in order. This is conceptually similar to defer@ or async@ on script. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24043] New: [Custom]: Need to check writable too.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24043 Bug ID: 24043 Summary: [Custom]: Need to check writable too. Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: a...@chromium.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14968 PROTOTYPE has a non-configurable property named constructor, throw a NotSupportedError and stop. If it is non-configurable but writable it is fine for us to change the value of the property. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Tue, Dec 10, 2013 at 6:38 AM, Ryosuke Niwa rn...@apple.com wrote: On Dec 8, 2013, at 4:42 PM, Dominic Cooney domin...@google.com wrote: On Sun, Dec 8, 2013 at 7:25 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 7, 2013, at 4:38 PM, Dominic Cooney domin...@google.com wrote: On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 5, 2013, at 10:09 PM, Hajime Morrita morr...@google.com wrote: On inheritance around HTMLElement family, there seems to be a confusion between interface side inheritance and implementation side inheritance. Right. Differentiating the two is very important. For Custom Elements, the inheritance is not only about interface, but also about implementation. The implementation is more complex and flux in detail, thus worth being shared between different elements. Actually, the implementation of built-in HTML elements, which are usually done in C++, uses inheritance heavily, at least Blink and (I believe) WebKit. The reason we can use inheritance heavily is because we have control over both parent and child classes, and there are careful distinctions between public, protected, and private member functions and member variables in those classes. Unfortunately, custom elements can't easily inherit from these builtin HTML elements because builtin elements do not provide protected functions, and they don't expose necessary hooks to override internal member functions to modify behaviors. Built-in HTML elements have lots of hooks to modify their behaviour (for example, HTMLVideoElement's autoplay attribute.) The analogy is extending a Java class which has private and public final members, but no protected or public non-final ones. If someone were to make proposals about adding more hooks to the web platform to enable more subtyping use cases (for example, a protocol for participating in form submission) I would look forward to working with them on those proposals. http://goto.google.com/dc-email-sla The problem here is that until such hooks are well defined, inheriting from builtin elements doesn't make any sense. So let's not support that until such proposal is made and implemented. You assert that inheriting from built-in elements does not make any sense. You seem to base this on the claim that hooks (the example being form submission protocol hooks) are not well defined. Whether hooks are well defined or not doesn't sufficiently support your assertion, because: 1. Not all subtyping relies on hooks. For example, subtyping a built-in element can add additional API to it. This may make sense. For example, a social network endorse button has a number of additional properties. Yet it is (or could be) a button. If the only use case was to add new JavaScript property, then we wouldn't need custom elements at all. Authors could already do this by simply adding properties on builtin elements. If you do this on the Interface Prototype Object of a built-in element, the API will appear on all elements of that type. So that is not a feasible solution for many use cases. If you try to do this on a per-instance basis, that means you have to track instances. As I pointed out here: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0893.html that is very difficult for the author to do correctly. Custom Elements puts the responsibility for this in the UA which has full knowledge of when elements are being created. As for the social endorse button, I've never seen a popular SNS share buttons implemented using HTML button elements; most of them add their own DOM to add icons, etc... This is why it is important to be able to subtype built-in elements. Some authors prefer buttons to be buttons because of the better default handling by accessibility technology. Tangentially, this is also why it is important to be able to add Shadow DOM to built-in elements. It should be possible to elaborate the UI of a button but still get the benefits of encapsulated styles, encapsulation from accidental access through casual DOM walking or simple CSS selectors, etc. 2. The premise that hooks are not defined is also incorrect. Many hooks are already defined. Here is one example: the INPUT element has input and change events and a value property. These are sufficient to observe, filter and change the value of the INPUT element. This can't possibly be an explanation for whether hooks are well defined or not doesn't sufficiently support your assertion. HTML input elements have a lot more internal states than just the value. To list a few: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#concept-input-value-dirty-flag http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#concept-input-checked-dirty-flag I did not claim that all possible hooks are defined. I claimed that some hooks are defined. These enable some use cases. I was observing that
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
Ryosuke Niwa wrote: As for the social endorse button, I've never seen a popular SNS share buttons implemented using HTML button elements; most of them add their own DOM to add icons, etc... Right you are. And there's a deeper reason why like (endorse, LOL) buttons use iframes: the ability to set 3rd party cookies. /be
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Mon, Dec 9, 2013 at 5:50 PM, Brendan Eich bren...@secure.meer.netwrote: Ryosuke Niwa wrote: As for the social endorse button, I've never seen a popular SNS share buttons implemented using HTML button elements; most of them add their own DOM to add icons, etc... Right you are. And there's a deeper reason why like (endorse, LOL) buttons use iframes: the ability to set 3rd party cookies. They don't actually need to be able to set cookies, but they do need to be able to _read_ them. For example some widgets show your username and your face next to the button so it'd say: Like this as +Elliott Sprehn, or Leave a comment as Elliott. - E
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Dec 9, 2013, at 5:12 PM, Dominic Cooney domin...@google.com wrote: On Tue, Dec 10, 2013 at 6:38 AM, Ryosuke Niwa rn...@apple.com wrote: On Dec 8, 2013, at 4:42 PM, Dominic Cooney domin...@google.com wrote: On Sun, Dec 8, 2013 at 7:25 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 7, 2013, at 4:38 PM, Dominic Cooney domin...@google.com wrote: On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 5, 2013, at 10:09 PM, Hajime Morrita morr...@google.com wrote: On inheritance around HTMLElement family, there seems to be a confusion between interface side inheritance and implementation side inheritance. Right. Differentiating the two is very important. For Custom Elements, the inheritance is not only about interface, but also about implementation. The implementation is more complex and flux in detail, thus worth being shared between different elements. Actually, the implementation of built-in HTML elements, which are usually done in C++, uses inheritance heavily, at least Blink and (I believe) WebKit. The reason we can use inheritance heavily is because we have control over both parent and child classes, and there are careful distinctions between public, protected, and private member functions and member variables in those classes. Unfortunately, custom elements can't easily inherit from these builtin HTML elements because builtin elements do not provide protected functions, and they don't expose necessary hooks to override internal member functions to modify behaviors. Built-in HTML elements have lots of hooks to modify their behaviour (for example, HTMLVideoElement's autoplay attribute.) The analogy is extending a Java class which has private and public final members, but no protected or public non-final ones. If someone were to make proposals about adding more hooks to the web platform to enable more subtyping use cases (for example, a protocol for participating in form submission) I would look forward to working with them on those proposals. The problem here is that until such hooks are well defined, inheriting from builtin elements doesn't make any sense. So let's not support that until such proposal is made and implemented. You assert that inheriting from built-in elements does not make any sense. You seem to base this on the claim that hooks (the example being form submission protocol hooks) are not well defined. Whether hooks are well defined or not doesn't sufficiently support your assertion, because: 1. Not all subtyping relies on hooks. For example, subtyping a built-in element can add additional API to it. This may make sense. For example, a social network endorse button has a number of additional properties. Yet it is (or could be) a button. If the only use case was to add new JavaScript property, then we wouldn't need custom elements at all. Authors could already do this by simply adding properties on builtin elements. If you do this on the Interface Prototype Object of a built-in element, the API will appear on all elements of that type. So that is not a feasible solution for many use cases. If you try to do this on a per-instance basis, that means you have to track instances. As I pointed out here: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0893.html that is very difficult for the author to do correctly. Custom Elements puts the responsibility for this in the UA which has full knowledge of when elements are being created. But one of Google representatives stated that the current goal of web components, which we may not necessarily agree with, is to provide the minimum set of features for JS frameworks to build on top of it. If that were the goal, why are we bothering to add this API at all? In fact, why do we even bother to add any new API at all for web components if our primary target was framework authors. Ember.js, Angular JS, etc... all work great already because they add an abstraction layer on top of DOM. As currently argued by many representatives of Google, we'll be adding a bunch of APIs for frameworks to define declarative syntax, etc... each of which may or may not be interoperable with one another thereby making it impossible for us to later introduce one unified API. If that were true, then web components specifications don't satisfy the previously claimed goal of letting multiple frameworks and libraries to co-exist at all. Recall that [t]he WebApps Working Group is chartered to develop specifications for webapps, including standard APIs for client-side development, and a packaging format for installable webapps. This work will include both documenting existing APIs such as XMLHttpRequest and developing new APIs in order to enable richer web applications. We have a serious problem with the goal itself if the primary goal of web components features were to satisfy needs and use cases of JS
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Dec 9, 2013, at 8:45 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Dec 10, 2013 at 3:33 PM, Ryosuke Niwa rn...@apple.com wrote: In fact, why do we even bother to add any new API at all for web components if our primary target was framework authors. Ember.js, Angular JS, etc... all work great already because they add an abstraction layer on top of DOM. As currently argued by many representatives of Google, we'll be adding a bunch of APIs for frameworks to define declarative syntax, etc... each of which may or may not be interoperable with one another thereby making it impossible for us to later introduce one unified API. If that were true, then web components specifications don't satisfy the previously claimed goal of letting multiple frameworks and libraries to co-exist at all. Responding to an I don't think we need to add that much sugar right now opinion with a Well then why bother adding any sugar at all?!? is never helpful. This is not an all-or-nothing thing, it's a search for the right level of sugaring to bake into the browser. And I'm claiming that the right level of sugaring should be decided based on needs of authors, not just of framework authors. - R. Niwa
Re: [webcomponents] Auto-creating shadow DOM for custom elements
On Dec 9, 2013, at 11:13 AM, Scott Miles sjmi...@google.com wrote:
I'm not wont to try to summarize it here, since he said it already better
there. Perhaps the short version is: nobody knows what the 'standard use
case' is yet.
How is that possible given we've already spent 2+ years on the whole web
components effort?
In previous adjudications, the straw that broke that camel's back was with
respect to handling auto-generation with inheritance. Shadow-roots may need
to be generated for each entry in the inheritance chain.
The problem with that approach is that it mixes inheritance with composition.
Having the system perform this task takes it out of the control of the user's
code, which otherwise has ability to modulate calls to super-class methods
and manage this process.
class XFoo {
constructor_or_createdCallback: function() {
// my shadowRoot was auto-generated
this.doUsefulStuffLikeDatabinding(this.shadowRoot);
}
}
class XBar extends XFoo {
constructor_or_createdCallback: function() {
super(); // uh-oh, super call operates on wrong shadowRoot
}
}
This example doesn't work because the kind of encapsulation provided by shadow
insertion point is not suitable for inheritance amongst UI components nor is
available in other prominent GUI frameworks for the purpose of inheritance.
When subclassing a UI component, one has to either know what the superclass
draws on the screen (so that you can modify them as needed or draw more stuff
above or beneath it) or completely replace what's displayed. Putting the
superclass' content on some bounding box is a composition. Let us not mix the
two.
There are primarily two major use cases of inheritance in building UI views:
Adding some non-GUI API for convenience - You don't need to touch the view at
all. Let the superclass draw/paint its view, and call its public API to modify
the internal states as needed.
Provide a new UI but use the underlying data model - You don't need to use
superclass' view. Just draw/paint your own stuff.
Modifying what its superclass paints/draws to tweak the UI - You need to know
exactly what superclass does. Either superclass needs to provide a hook to do
this or you need to know how superclass does its work so that you can intercept
by overriding methods and callbacks as needed.
None of that involves putting superclass' view into some subregion in the
subclass. (We also argue that the first two use cases are better addressed by
compositions on the Web for reasons I've stated elsewhere.)
- R. Niwa
[webcomponents] Standard Use Case (Was Auto-creating shadow DOM for custom elements)
On Dec 9, 2013, at 9:34 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 9, 2013, at 11:13 AM, Scott Miles sjmi...@google.com wrote: I'm not wont to try to summarize it here, since he said it already better there. Perhaps the short version is: nobody knows what the 'standard use case' is yet. How is that possible given we've already spent 2+ years on the whole web components effort? I don't want to start a word game here but if it's really true that we don't know what web components' the primary/standard use case is, then we have a much bigger issue here. We need to design features and APIs to address specific use cases. We don't design an API in the hope that that it'll magically address some use cases. - R. Niwa
Re: [webcomponents] Standard Use Case (Was Auto-creating shadow DOM for custom elements)
On Dec 9, 2013, at 11:03 PM, Matthew McNulty mmcnu...@google.com wrote: On Tue, Dec 10, 2013 at 4:04 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 9, 2013, at 9:34 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 9, 2013, at 11:13 AM, Scott Miles sjmi...@google.com wrote: I'm not wont to try to summarize it here, since he said it already better there. Perhaps the short version is: nobody knows what the 'standard use case' is yet. How is that possible given we've already spent 2+ years on the whole web components effort? I don't want to start a word game here Really? Because that is exactly what you are doing. This is the equivalent of no offense, but... It's disingenuous to put it mildly. I'm sorry if I offended you but I never intend to play a word game since it's not a productive use of my time. I do admit that I never word things nicely. I'm not a pleasant person to talk with. I'm sorry. but if it's really true that we don't know what web components' the primary/standard use case is, then we have a much bigger issue here. And here's where you start the word game, by adding words and subtly changing the definition from what was obviously intended, and then fighting against your new straw man. That was definitely not my intention. You know exactly what was meant by what Scott said. No, I don't. How developers and the wider ecosystem of the web will precisely use the primitives provided by the platform and the patterns that then emerge are unknown at best at this early stage. Could you elaborate more on what you mean by this? We know what use cases we are trying to solve, and so do you. Could you give me pointers to the exact list of use case you have? By providing the lowest-level primitives possible, we're opening the door to use cases we haven't even considered. This is A Good Thing. No. That's not a use case. - R. Niwa
