Re: Request for feedback: Streams API

2013-12-09 Thread Takeshi Yoshino
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

2013-12-09 Thread Takeshi Yoshino
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?

2013-12-09 Thread Kornel Lesiński

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?

2013-12-09 Thread Mounir Lamouri
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

2013-12-09 Thread Harald Alvestrand
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?

2013-12-09 Thread Mounir Lamouri
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

2013-12-09 Thread Scott Miles
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

2013-12-09 Thread Rob Eisenberg
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)

2013-12-09 Thread Ryosuke Niwa
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

2013-12-09 Thread bugzilla
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.

2013-12-09 Thread bugzilla
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)

2013-12-09 Thread Dominic Cooney
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)

2013-12-09 Thread Brendan Eich

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)

2013-12-09 Thread Elliott Sprehn
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)

2013-12-09 Thread Ryosuke Niwa
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)

2013-12-09 Thread Tab Atkins Jr.
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.

~TJ



Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)

2013-12-09 Thread Ryosuke Niwa
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

2013-12-09 Thread Ryosuke Niwa
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)

2013-12-09 Thread Ryosuke Niwa
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)

2013-12-09 Thread Ryosuke Niwa
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