[manifest] name and icons, was Re: [manifest] V1 ready for wider review

[Marcos Caceres]

On Thursday, February 13, 2014 at 1:21 AM, Jonas Sicking wrote:

> 
> I still think that leaving out name and icons from a manifest about
> bookmarks is a big mistake. I just made my case here
> 
> http://lists.w3.org/Archives/Public/www-tag/2014Feb/0039.html
I'll reply separately.  
> Basically I think we need to make the manifest more self sufficient. I
> think that we're getting Ruby's postulate the wrong way around by
> making the file that describes the bookmark not contain all the data
> about the bookmark. Instead the two most important pieces about the
> bookmark, name and icons, will live in a completely separate HTML
> file, often with no way to find yourself from the manifest to that
> separate HTML file.
> 

I still think that icons and name are outside the scope of V1 - but I've added 
them to V2. The whole manifest and icon updating mechanism you describe in your 
email to the TAG adds a bunch of complexity (yes, we need to deal with it 
eventually as it's an extremely valid use case - but we can defer it to HTML at 
this moment and for a few months... even if UAs don't do updating of icons and 
name from HTML). I still hold that we should get the most critical and least 
controversial functionality (display mode, default-orientation, and start-url) 
standardized before we do the other stuff. It also gives a chance for UA's to 
catch up and implement HTML's "application-name" and  properly.  

UAs are going to need to support those HTML features to work with apps that 
don't make use of manifests. And apps the use manifests will work just fine 
till we add proper support for name and icons into the manifest - all web apps 
will need to include "application-name" and "link rel=icon" (as well as a bunch 
of proprietary stuff!) to target todays and yesterdays UAs regardless. So, 
IMHO, there is not much to be won by putting name and icons into V1 for 
implementers or for developers at this moment.

I would go as far as to say that it's initially harmful to have name and icon 
in V1 because it discourages UAs from fixing their support for application-name 
and . Having the fallback behavior explicitly tested in V1 of 
the manifest may help improve support for those features of HTML. 

So, I'm not saying let's never do name and icon - I'm saying let just do the 
easy stuff we have some agreement on first. 

Re: [manifest] V1 ready for wider review

[Jonas Sicking]

On Wed, Feb 12, 2014 at 12:06 PM, Marcos Caceres  wrote:
> The editors of the [manifest] spec have now closed all substantive issues for 
>  "v1".
>
> The spec defines the following:
>
> * A link relationship for manifests (so they can be used with  rel="manifest">).
>
> * A standard file name for a manifest resource 
> ("/.well-known/manifest.json"). Works the same as "/favicon.ico" for when 
>  is missing.
>
> * The ability to point to a "start-url".
>
> * Basic screen orientation hinting for when launching a web app.
>
> * Launch the app in different display modes: fullscreen, minimal-ui, open in 
> browser, etc.
>
> * A way of for scripts to check if the application was launched from a 
> bookmark (i.e., similar to Safari's navigator.standalone).
>
> * requestBookmark(), which is a way for a top-level document to request it be 
> bookmarked by the user. To not piss-off users, requires explicit user action 
> to actually work. Expect install my app everywhere on the 
> Web now :)
>
> If you are wondering where some missing feature is, it's probably slated for 
> [v2]. The reason v1 is so small is that it's all we could get agreement on 
> amongst implementers (it's a small set, but it's a good set to kick things 
> off and get us moving... and it's a small spec, so easy to quickly read over).
>
> We would appreciate your feedback on this set of features - please file 
> [bugs] on GitHub. We know it doesn't fully realize *the dream* of installable 
> web apps - but it gets us a few steps closer.
>
> If we don't get any significant objections, we will request to transition to 
> LC in a week or so.

I still think that leaving out name and icons from a manifest about
bookmarks is a big mistake. I just made my case here

http://lists.w3.org/Archives/Public/www-tag/2014Feb/0039.html

Basically I think we need to make the manifest more self sufficient. I
think that we're getting Ruby's postulate the wrong way around by
making the file that describes the bookmark not contain all the data
about the bookmark. Instead the two most important pieces about the
bookmark, name and icons, will live in a completely separate HTML
file, often with no way to find yourself from the manifest to that
separate HTML file.

/ Jonas

[Bug 24349] [imports]: Import documents should always be in no-quirks mode

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24349

Morrita Hajime  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||morr...@google.com
 Resolution|--- |FIXED

--- Comment #2 from Morrita Hajime  ---
https://github.com/w3c/webcomponents/commit/f7945a427e467285902951336f5b963682e01875

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Alex Russell]

On Tue, Feb 11, 2014 at 5:16 PM, Maciej Stachowiak  wrote:

>
> On Feb 11, 2014, at 4:04 PM, Dimitri Glazkov 
> wrote:
>
> On Tue, Feb 11, 2014 at 3:50 PM, Maciej Stachowiak  wrote:
>
>>
>> On Feb 11, 2014, at 3:29 PM, Dimitri Glazkov 
>> wrote:
>>
>>
>>
>>> Dimitri, Maciej, Ryosuke - is there a mutually agreeable solution here?
>>>
>>
>> I am exactly sure what problem this thread hopes to raise and whether
>> there is a need for anything other than what is already planned.
>>
>>
>> In the email Ryosuke cited, Tab said something that sounded like a claim
>> that the WG had decided to do public mode only:
>>
>> 
>> Quoting Tab:
>>
>> The decision to do the JS side of Shadow DOM this way was made over a
>> year ago.  Here's the relevant thread for the decision:
>> <
>> http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/thread.html#msg312
>> >
>> (it's rather long) and a bug tracking it
>> .
>>
>>
>> I can't speak for Ryosuke but when I saw this claim, I was honestly
>> unsure whether there had been a formal WG decision on the matter that I'd
>> missed. I appreciate your clarification that you do not see it that way.
>>
>>
>> Quoting Dmitri again:
>>
>> The plan is, per thread I mentioned above, is to add a flag to
>> createShadowRoot that hides it from DOM traversal APIs and relevant CSS
>> selectors: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144.
>>
>>
>> That would be great. Can you please prioritize resolving this bug[1]? It
>> has been waiting for a year, and at the time the private/public change was
>> made, it sounded like this would be part of the package.
>>
>
> Can you help me understand why you feel this needs to be prioritized? I
> mean, I don't mind, but it would be great if I had an idea on what's the
> driving force behind the urgency?
>
>
> (1) It blocks the two dependent issues I mentioned.
> (2) As a commenter on a W3C spec and member of the relevant WG, I think I
> am entitled to a reasonably prompt level of response from a spec editor.
> This bug has been open since November 2012. I think I have waited long
> enough, and it is fair to ask for some priority now. If it continues to go
> on, then an outside observer might get the impression that failing to
> address this bug is deliberate stalling. Personally, I prefer to assume
> good faith, and I think you have just been super busy. But it would show
> good faith in return to address the bug soon.
>
> Note: as far as I know there is no technical issue or required feedback
> blocking bug 20144. However, if there is any technical input you need, or
> if you would find it helpful to have a spec diff provided to use as you see
> fit, I would be happy to provide such. Please let me know!
>
>
> It seems like there are a few controversies that are gated on having the
>> other mode defined:
>> - Which of the two modes should be the default (if any)?
>>
>
> This is re-opening the old year-old discussion, settled in
> http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/thread.html#msg800,
> right?
>
>
> I'm not sure what you mean by "settled". You had a private meeting and the
> people there agreed on what the default should be. That is fine. Even using
> that to make a provisional editing decision seems fine. However, I do not
> believe that makes it "settled" for purposes of the WG as a whole. In
> particular, I have chosen not to further debate which mode should be the
> default until both modes exist, something that I've been waiting on for a
> while. I don't think that means I lose my right to comment and to have my
> feedback addressed.
>
> In fact, my understanding of the process is this: the WG is required to
> address any and all feedback that comes in at any point in the process. And
> an issue is not even settled to the point of requiring explicit reopening
> unless there is a formal WG decision (as opposed to just an editor's
> decision based on their own read of input from the WG.)
>
>
>
>
>> - Should shadow DOM styling primitives be designed so that they can work
>> for private/closed components too?
>>
>
> Sure. The beauty of a hidden/closed mode is that it's a special case of
> the open mode, so we can simply say that if a shadow root is "closed", the
> selectors don't match anything in that tree. I left the comment to that
> effect on the bug.
>
>
> Right, but that leaves you with no styling mechanism that offers more
> fine-grained control, suitable for use with closed mode. Advocates of the
> current styling approach have said we need not consider closed mode at all,
> because the Web Apps WG has decided on open mode. If what we actually
> decided is to have both (and that is my understanding of the consensus),
> then I'd like the specs to reflect that, so the discussion in www-style can
> be based on facts.
>
> As a more basic point, mention of closed mode to exclude it from /shadow
> m

[Bug 24639] New: [Shadow]: Each section on the spec needs examples

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24639

Bug ID: 24639
   Summary: [Shadow]: Each section on the spec needs examples
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: dglaz...@chromium.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 14978

For example:

* multiple shadow roots per host translate to the inheritance model in DOM.
* what happens when you change the value of the select attribute (show that
it's dynamic)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 24638] New: [Shadow]: elementFromPoint should return the host when you hit a Text node

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24638

Bug ID: 24638
   Summary: [Shadow]: elementFromPoint should return the host when
you hit a Text node
   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: 14978

Seeing as we don't want to throw an exception when you put a Text node as a
child of a ShadowRoot, we should at the very least return the host element so
that hit testing in a ShadowRoot that has direct text children does something
sensible.

We probably need to make it return the host if you hit a border/background
color too?

(this also makes sense since you can querySelector(":host"), so the host really
is in the same scope as the ShadowRoot.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: Extending Mutation Observers to address use cases of

[Ryosuke Niwa]

On Feb 12, 2014, at 2:33 PM, Jonas Sicking  wrote:

> On Wed, Feb 12, 2014 at 2:08 PM, Ryosuke Niwa  wrote:
>> On Feb 12, 2014, at 11:23 AM, Rafael Weinstein  wrote:
>>> 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
>> 
>> I'm not convinced that only custom elements require a synchronously 
>> consistent abstraction.
> 
> I want to be *very* careful about exposing synchronous callbacks.
> While I'm sure a lot of authors will ask for it, it's a tremendous foot gun.

Right.  This is why I’d like to know exactly why end-of-microtask synchronicity 
isn’t sufficient for custom elements.

> The first type of footgun that it is is that authors can footgun
> themselves when using these callbacks. For example by accidentally
> calling into external code while they are in an inconsistent state.
> Another thing to remember here is that you can only really have one
> consumer that truly receives synchronous callbacks. The moment you
> have two observers it means that the second observer doesn't have time
> to react before the first observer runs. This can be a problem both
> for the first observer, since it sees a world where the mutation has
> happened, but where the second observer hasn't had time to react to
> it, and for the second observer, since the world can have changed
> under it before it has had a chance to react to a mutation.

That is a good point.  There is a clear disadvantage in the case of multiple 
observers observing the same node.

> The second type of footgun is that by adding synchronous callbacks, we
> are limiting our own ability to extend and optimize the platform since
> we have to worry about JS callbacks running at inopportune times. So
> by adding synchronous callbacks, we're footgunning ourselves.

But why is it okay to add semi-synchronous callbacks to custom elements then?

>>> I think there's an argument to be made that Mutation Observers *should* be 
>>> extended to allow for observation of trees which include DOM reachable 
>>> through shadowRoots. The motivation for this would be to allow existing 
>>> de-coupled concerns to operate faithfully in the presence of custom 
>>> elements implemented with shadowDOM. The obvious concern here is that 
>>> de-coupled code may interfere with the implementation of elements, but 
>>> that's no more true with custom elements than it is today, and shadowRoot 
>>> is imperatively public, it's consistent to allow MutationObservers to 
>>> continue to fully observe a document.
>> 
>> I think this would be a nice opt-in feature; component authors should be 
>> able to choose whether or not to expose its internal DOM in embedding 
>> documents.
> 
> For now Mutation Observation never crosses shadow DOM boundaries. When
> we add that ability I think it needs to be explicitly opted into, and
> even when explicitly opted into, it should not cross the boundary into
> private shadow DOM trees.
> 
> In short, I think this is an orthogonal discussion, and should follow
> the decision of the open/close debate. This is just one more aspect of
> how shadow DOM nodes can be exposed and should follow the policies
> that are used elsewhere.

I agree. This should be discussed separately.

- R. Niwa

Re: Extending Mutation Observers to address use cases of

[Jonas Sicking]

On Wed, Feb 12, 2014 at 2:08 PM, Ryosuke Niwa  wrote:
> On Feb 12, 2014, at 11:23 AM, Rafael Weinstein  wrote:
>> 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
>
> I'm not convinced that only custom elements require a synchronously 
> consistent abstraction.

I want to be *very* careful about exposing synchronous callbacks.
While I'm sure a lot of authors will ask for it, it's a tremendous
footgun.

The first type of footgun that it is is that authors can footgun
themselves when using these callbacks. For example by accidentally
calling into external code while they are in an inconsistent state.
Another thing to remember here is that you can only really have one
consumer that truly receives synchronous callbacks. The moment you
have two observers it means that the second observer doesn't have time
to react before the first observer runs. This can be a problem both
for the first observer, since it sees a world where the mutation has
happened, but where the second observer hasn't had time to react to
it, and for the second observer, since the world can have changed
under it before it has had a chance to react to a mutation.

The second type of footgun is that by adding synchronous callbacks, we
are limiting our own ability to extend and optimize the platform since
we have to worry about JS callbacks running at inopportune times. So
by adding synchronous callbacks, we're footgunning ourselves.

>> 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.
>>
>> In short, Custom Elements and Mutation Observers are servicing very 
>> different needs. Custom Elements are privileged, but limited and singular (I 
>> can only react to changes in myself and I'm the only responding party), 
>> while Mutation Observers are unprivileged, pervasive and multiple (I get to 
>> respond to anything in the document, and there are likely other parties 
>> doing work in the same place I am).
>
> The problem I have with this approach is that we'll then end up with not two 
> but three parallel API for observing DOM mutations that each has its own 
> delivering/dispatching mechanism and timing: mutation events, mutation 
> observers, and custom elements.  API fragmentation like that can't be good 
> for the platform.

Hopefully mutation events can go away. In gecko we have since August
2012 warned authors whenever they are used that they are going to be
removed. We've gotten very little feedback (none that I know of) that
this is a problem.

>> I think there's an argument to be made that Mutation Observers *should* be 
>> extended to allow for observation of trees which include DOM reachable 
>> through shadowRoots. The motivation for this would be to allow existing 
>> de-coupled concerns to operate faithfully in the presence of custom elements 
>> implemented with shadowDOM. The obvious concern here is that de-coupled code 
>> may interfere with the implementation of elements, but that's no more true 
>> with custom elements than it is today, and shadowRoot is imperatively 
>> public, it's consistent to allow MutationObservers to continue to fully 
>> observe a document.
>
> I think this would be a nice opt-in feature; component authors should be able 
> to choose whether or not to expose its internal DOM in embedding documents.

For now Mutation Observation never crosses shadow DOM boundaries. When
we add that ability I think it needs to be explicitly opted into, and
even when explicitly opted into, it should not cross the boundary into
private shadow DOM trees.

In short, I think this is an orthogonal discussion, and should follow
the decision of the open/close debate. This is just one more aspect of
how shadow DOM nodes can be exposed and should follow the policies
that are used elsewhere.

/ Jonas

Re: Extending Mutation Observers to address use cases of

[Ryosuke Niwa]

On Feb 12, 2014, at 11:23 AM, Rafael Weinstein  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

I’m not arguing that custom elements should use mutation observers or that we 
should replace custom elements with mutation observers.

> 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

I’m not convinced that only custom elements require 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.
> 
> In short, Custom Elements and Mutation Observers are servicing very different 
> needs. Custom Elements are privileged, but limited and singular (I can only 
> react to changes in myself and I'm the only responding party), while Mutation 
> Observers are unprivileged, pervasive and multiple (I get to respond to 
> anything in the document, and there are likely other parties doing work in 
> the same place I am).

The problem I have with this approach is that we’ll then end up with not two 
but three parallel API for observing DOM mutations that each has its own 
delivering/dispatching mechanism and timing: mutation events, mutation 
observers, and custom elements.  API fragmentation like that can’t be good for 
the platform.

> I think there's an argument to be made that Mutation Observers *should* be 
> extended to allow for observation of trees which include DOM reachable 
> through shadowRoots. The motivation for this would be to allow existing 
> de-coupled concerns to operate faithfully in the presence of custom elements 
> implemented with shadowDOM. The obvious concern here is that de-coupled code 
> may interfere with the implementation of elements, but that's no more true 
> with custom elements than it is today, and shadowRoot is imperatively public, 
> it's consistent to allow MutationObservers to continue to fully observe a 
> document.

I think this would be a nice opt-in feature; component authors should be able 
to choose whether or not to expose its internal DOM in embedding documents.

- R. Niwa

[manifest] V1 ready for wider review

[Marcos Caceres]

The editors of the [manifest] spec have now closed all substantive issues for  
"v1". 

The spec defines the following:

* A link relationship for manifests (so they can be used with ).

* A standard file name for a manifest resource ("/.well-known/manifest.json"). 
Works the same as "/favicon.ico" for when  is missing.

* The ability to point to a "start-url". 

* Basic screen orientation hinting for when launching a web app.

* Launch the app in different display modes: fullscreen, minimal-ui, open in 
browser, etc.

* A way of for scripts to check if the application was launched from a bookmark 
(i.e., similar to Safari's navigator.standalone).

* requestBookmark(), which is a way for a top-level document to request it be 
bookmarked by the user. To not piss-off users, requires explicit user action to 
actually work. Expect install my app everywhere on the Web now 
:)   

If you are wondering where some missing feature is, it's probably slated for 
[v2]. The reason v1 is so small is that it's all we could get agreement on 
amongst implementers (it's a small set, but it's a good set to kick things off 
and get us moving... and it's a small spec, so easy to quickly read over).  

We would appreciate your feedback on this set of features - please file [bugs] 
on GitHub. We know it doesn't fully realize *the dream* of installable web apps 
- but it gets us a few steps closer. 

If we don't get any significant objections, we will request to transition to LC 
in a week or so. 
 
[manifest] http://w3c.github.io/manifest/
[v2] see goals for v2, https://github.com/w3c/manifest#goals-for-v2-and-beyond
[bugs] https://github.com/w3c/manifest/issues

-- 
Marcos Caceres

Re: Extending Mutation Observers to address use cases of

[Rafael Weinstein]

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.

In short, Custom Elements and Mutation Observers are servicing very
different needs. Custom Elements are privileged, but limited and singular
(I can only react to changes in myself and I'm the only responding party),
while Mutation Observers are unprivileged, pervasive and multiple (I get to
respond to anything in the document, and there are likely other parties
doing work in the same place I am).

Therefore, it is neither a good idea to make Custom Elements more async,
nor a good idea to make Mutation Observers more sync.

---

One final note. UNRELATED to custom elements' implementation.

I think there's an argument to be made that Mutation Observers *should* be
extended to allow for observation of trees which include DOM reachable
through shadowRoots. The motivation for this would be to allow existing
de-coupled concerns to operate faithfully in the presence of custom
elements implemented with shadowDOM. The obvious concern here is that
de-coupled code may interfere with the implementation of elements, but
that's no more true with custom elements than it is today, and shadowRoot
is imperatively public, it's consistent to allow MutationObservers to
continue to fully observe a document.

However, I don't think there's any rush to do this. Just something to think
about for a post-shadowDOM world.


On Wed, Feb 12, 2014 at 4:49 AM, Olli Pettay wrote:

> On 02/12/2014 04:27 AM, Ryosuke Niwa wrote:
>
>>
>>  On Feb 11, 2014, at 6:06 PM, Bjoern Hoehrmann  wrote:
>>>
>>> * Olli Pettay wrote:
>>>
 We could add some scheduling thing to mutation observers. By default
 we'd use microtask, since that tends to be good for various performance
 reasons, but normal tasks or nanotasks could be possible too.

>>>
>> Right, we need some sort of a switch.  I'm not certain if we want to add
>> it as a per-observation option or a global switch when we create an
>> observer. My guy feeling is that we want the latter.  It would be weird
>> for some mutation records to be delivered earlier than others to the same
>> observer.
>>
>>
> Yeah, I was thinking per observer.
> Something like
>
> var m = new MutationObserver(callback, { interval: "task"} );
> m.observe(document, { childList: true, subtree: true});
>
>
> Some devtools devs have asked for adding 'interval: "nanotask"' thing
> I was thinking to add such thing only for addons and such in Gecko,
> because it brings
> back some of the performance problems Mutation Events have.
> But if web components stuff would be less special with such option,
> perhaps it should be enabled for all.
>
>
>
>
> -Olli
>
>
>
>  I'd like to know exact semantics requirements before start jumping into
>> details though.
>>
>>  This sounds like adding a switch that would dynamically invalidate
>>> assumptions mutation observers might make, which sounds like a bad idea.
>>> Could
>>> you elaborate?
>>>
>>
>> I don't really follow what the problem is. Could you elaborate on what
>> you see as a problem?
>>
>> - R. Niwa
>>
>>
>
>

[Bug 24632] New: [meta][imports]: The spec should have fewer monkey patches

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24632

Bug ID: 24632
   Summary: [meta][imports]: The spec should have fewer monkey
patches
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: morr...@google.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 20683

Spawned from Bug 24623:

> In general we should avoid monkey patching. 1) A specification may not be 
> aware  
> of the patches being applied and invalidate them. 2) Readers of a 
> specification 
> may not be aware of the patches being applied and write code that turns out 
> to  
> be wrong due to patches. 3) If patches start getting applied from multiple
> sources the mental model quickly becomes too hard and mistakes start creeping 
>in all over.

We have some for now. This is a master bug to track these to be removed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [progress-events] Progress Events is a W3C Recommendation

[Charles McCathie Nevile]

On Wed, 12 Feb 2014 16:49:07 +0400, Jungkee Song   
wrote:



Thanks Art. The work is attributed to Anne, Chaals and Ms2ger. Thanks!


Actually, I did editing, like Jungkee, and the work is attributed to quite  
a lot of people, many of whom worked on it before the WebApps group  
existed.


Anyway congratulations to everyone.

cheers

Chaals


On Feb 12, 2014 9:28 PM, "Arthur Barstow"  wrote:


Congratulations to Anne, Jungkee and Chaals on the publication of a
Progress Events Recommendation .

(I updated this spec's PubStatus data to state that no additional work  
is

planned and that the feature is now part of XHR.)







--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
  cha...@yandex-team.ru Find more at http://yandex.com

Re: [manifest] orientation member

[Marcos Caceres]

On Monday, January 27, 2014 at 9:47 PM, Jonas Sicking wrote:

> On Mon, Jan 13, 2014 at 1:44 AM, Marcos Caceres  (mailto:w...@marcosc.com)> wrote:
> 
> Ok, makes sense.
> 
> So my counter questions are:
> 
> 1. Could we get away without using generic media queries and instead
> only allow switching on screen size height and/or width?


Probably - need to check if there is anything else on which this decision would 
be made. This is something we will need to look into.  
 
> 2. Could we get away with just using static orientations in v1? I.e.
> punt using different orientations for mobile/tablet until v2 of the
> manifest?
> 

Personally, I think so. That's currently what is in the spec [1]. 


[1] http://w3c.github.io/manifest/#default_orientation-member

Re: "Officially" deprecating main-thread synchronous XHR?

[Mounir Lamouri]

On Sat, 8 Feb 2014, at 12:19, James Greene wrote:
> There are certain situations where sync XHRs are, in fact, required...
> unless we make other accommodations. For example, in the Clipboard API,
> developers are allowed to inject into the clipboard as a semi-trusted
> event
> during the event handling phase of certain user-initiated events (e.g.
> `click`).[1]  This has not yet been implemented in any browsers yet.
> 
> However, if browser vendors choose to treat this scenario as it is
> treated
> for Flash clipboard injection, then the semi-trusted state ends after the
> default action for that event would occur.[2]
> 
> For Flash clipboard injection, this means that any required "on-demand"
> XHRs must be resolved synchronously. For the DOM Clipboard API, it would
> be
> nice to either still be able to use sync XHRs or else we would need to
> specially authorize async XHRs that are started during the semi-trusted
> state to have their completion handlers also still resolve/execute in a
> semi-trusted state.

Couldn't the semi-trusted state be kept for any promise created while
the semi-trusted is set? In other words, promises could keep the
semi-trusted state along the chaining. Though, as Olli said, this is
something the Clipboard API specification should fix.

-- Mounir

Re: [progress-events] Progress Events is a W3C Recommendation

[Jungkee Song]

Thanks Art. The work is attributed to Anne, Chaals and Ms2ger. Thanks!
On Feb 12, 2014 9:28 PM, "Arthur Barstow"  wrote:

> Congratulations to Anne, Jungkee and Chaals on the publication of a
> Progress Events Recommendation  REC-progress-events-20140211/ >.
>
> (I updated this spec's PubStatus data to state that no additional work is
> planned and that the feature is now part of XHR.)
>
>
>
>

Re: Extending Mutation Observers to address use cases of

[Olli Pettay]

On 02/12/2014 04:27 AM, Ryosuke Niwa wrote:



On Feb 11, 2014, at 6:06 PM, Bjoern Hoehrmann  wrote:

* Olli Pettay wrote:

We could add some scheduling thing to mutation observers. By default we'd use 
microtask, since that tends to be good for various performance
reasons, but normal tasks or nanotasks could be possible too.


Right, we need some sort of a switch.  I'm not certain if we want to add it as 
a per-observation option or a global switch when we create an
observer. My guy feeling is that we want the latter.  It would be weird for 
some mutation records to be delivered earlier than others to the same
observer.



Yeah, I was thinking per observer.
Something like

var m = new MutationObserver(callback, { interval: "task"} );
m.observe(document, { childList: true, subtree: true});


Some devtools devs have asked for adding 'interval: "nanotask"' thing
I was thinking to add such thing only for addons and such in Gecko, because it 
brings
back some of the performance problems Mutation Events have.
But if web components stuff would be less special with such option, perhaps it 
should be enabled for all.




-Olli



I'd like to know exact semantics requirements before start jumping into details 
though.


This sounds like adding a switch that would dynamically invalidate assumptions 
mutation observers might make, which sounds like a bad idea. Could
you elaborate?


I don't really follow what the problem is. Could you elaborate on what you see 
as a problem?

- R. Niwa

[progress-events] Progress Events is a W3C Recommendation

[Arthur Barstow]

Congratulations to Anne, Jungkee and Chaals on the publication of a 
Progress Events Recommendation 
.


(I updated this spec's PubStatus data to state that no additional work 
is planned and that the feature is now part of XHR.)

RE: [clipboard events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data

[Ben Peters]

Hi Hallvord!

The IE11 API you mentioned is msConvertURL [1] (also on the IE blog [2]), and 
it was designed as a simple way for sites to choose DataURI or Blob for 
otherwise inaccessible images. We default to DataURI to be interoperable with 
Firefox’s current design of always doing DataURI for local images on the 
clipboard. With a little bit of code, blobs can be used instead. Our 
clipboardData.files implementation contains only images at the moment because 
we have only partial support of the current version of the Clipboard API spec. 
This means that with a quick ‘for’ loop over those images, javascript can 
choose to create blobs, manage the blob’s memory, and upload the blobs to a 
server. As you mention, it is not possible to tell which file/image corresponds 
to which  because it’s really designed as a simple approach for cases 
where a site wants to always use blob or dataURI for images that they couldn’t 
otherwise access.

We are considering doing the CID approach as well in the future. It is nice to 
have the additional control of seeing which  src you are changing, and it 
will likely work better for copy, not just paste like convertURL. We believe 
that convertURL does not block using the CIDs you have in the current spec. To 
better understand your approach and allow us to help move it forward, can you 
give us sample javascript that a site would use to set the DataTransferItems 
for HTML and the related images during copy? Second, can you provide the 
javascript for how a site would put them into the pasted markup during paste?

Regarding a couple other questions you ask:
* As far as I’ve seen, WebKit/Blink do not yet support images with local-system 
sources. They do support binary images on the clipboard using 
ClipboardData.items like in the example I found online [3].
* Some sites prefer DataURI to Blob because it’s all inline and doesn’t require 
sending separate objects or managing memory, so I don’t think DataURI is 
something we should discount.

Looking forward to seeing your sample code!
Ben Peters

[1] http://msdn.microsoft.com/en-us/library/ie/dn254951(v=vs.85).aspx 
[2] 
http://blogs.msdn.com/b/ie/archive/2013/10/24/enhanced-rich-editing-experiences-in-ie11.aspx
[3] http://strd6.com/2011/09/html5-javascript-pasting-image-data-in-chrome/

-Original Message-
From: Hallvord R. M. Steen [mailto:hst...@mozilla.com] 
Sent: Thursday, January 23, 2014 5:30 PM
To: public-webapps
Subject: [clipboard events] seeking implementor feedback on using CID: URI 
scheme for pasting embedded binary data

> Hi,
> pasting HTML that contains embeds (images, video) into a rich text editor is 
> a use case we should cover. It's currently handled in different ways - 

> * IE11 supports pasting images as either data: URLs or blobs [1] (and has a 
> non-standard method to fill in a gap in the blob approach). I don't 
> understand from this blog post how/if it supports referencing the binary 
> parts from the HTML. If for example you paste a snippet from a Word page that 
> contains two images, the DataTransferItemList is presumably populated with 
> two image files, which can be processed/uploaded using the blob method - but 
> how is the script processing the data supposed to know what IMG tag in the 
> pasted HTML each image file belongs to?

> * Pasting stuff as data: URLs seems like a hack, wasting memory and requiring 
> quite some extra processing if there is a lot of data.

> * Firefox apparently happily passes on file:/// URLs with local paths and all 
> [2], this is of course a bug.

> * Right now I'm not sure what WebKit/Blink - based implementations do. Test 
> results welcome!

> As the editor of the Clipboard Events spec, I'm proposing a somewhat 
> different take on this: "cid:"-URIs for embeds. See 
> http://dev.w3.org/2006/webapi/clipops/clipops.html (search for "cid:").

> The idea is that rather than embedding potentially very huge data: URLs or 
> reference local files in the embedded markup, we add a reference to the 
> DataTransferItemList, and use the index of this reference to construct a cid: 
> URI in the markup that clipboardEvent.getData('text/html') will see. The 
> script processing this data can then pull out the cid: URIs, do drag-and-drop 
> style file uploads for referenced clipboard parts, and update the data to 
> refer to the locations on the server eventually (maybe first using an 
> intermediate placeholder image or something like that.)

> AFAIK, outside of the used in HTML intended for E-mail, this would be the 
> first usage of CID: URIs in web platform specs. I'm looking for feedback 
> regarding whether this is implementable and a good solution. I haven't had 
> much (if any) feedback from implementors on this issue yet, so thank you all 
> in advance for your ideas and input.
-Hallvord

> [1] 
> http://blogs.msdn.com/b/ie/archive/2013/10/24/enhanced-rich-editing-experiences-in-ie11.aspx
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=665341

Re: [clipboard events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data

[Hallvord R. M. Steen]

> Hi Hallvord!

Hi Ben! Thanks for responding to my request for feedback - especially since the 
IE team has done some interesting work in this area and is arguably ahead of 
the rest! :-)

> The IE11 API you mentioned is msConvertURL [1] (also on the IE blog [2]), and 
> it was designed as a
> simple way for sites to choose DataURI or Blob for otherwise inaccessible 
> images. 

> As you mention, it is not possible to tell which file/image corresponds to 
> which  because it’s
> really designed as a simple approach for cases where a site wants to always 
> use blob or dataURI for
> images that they couldn’t otherwise access.

That's more or less what I thought, based on the blog post, so thanks for 
describing it in detail.

> We are considering doing the CID approach as well in the future. It is nice 
> to have the additional
> control of seeing which  src you are changing, and it will likely work 
> better for copy, not just
> paste like convertURL.

Actually, I haven't truly considered the copy case here yet. I've sort of 
assumed that given that you can put multiple bits of data on a clipboard, the 
various clipboard implementations should already have a way one piece of data 
can reference one specific other piece of data - I haven't really found the 
technical details here. 

Of course it would be nice to support a script that wants to generate random 
HTML with embedded files to place on the clipboard (although I think most of 
those use cases can already be met by using URLs and assuming that any software 
reading HTML from the clipboard can understand URLs..). However, one can 
imagine a use case for example with a CANVAS app where the script wants to copy 
the state of the CANVAS as an image inside HTML it places on the clipboard - 
having the script create src="cid:n" type markup, append files, and make the UA 
translate that to the platform's native clipboard implementation's way of 
referencing one part on the clipboard from another part..

> We believe that convertURL does not block using the CIDs you have in the 
> current spec.

I suppose not, but perhaps the more relevant question is: should we standardise 
convertURL? Would it still have a use case if we take the cid: route? (And I 
guess a related question is: given that we've done data: URLs for a while, how 
much content will we break if, say, Firefox moves from data: to cid:? Do we 
need to make cid: opt-in somehow, like you're doing with convertURL?)

> To better understand your approach and allow us to help move it forward, can 
> you give us sample
> javascript that a site would use to set the DataTransferItems for HTML and 
> the related images during copy?

As I said, I have not really considered this use case - so the spec doesn't 
actually cover this. If we want to make this work, I suppose the JS would look 
somewhat like this?

document.addEventListener('copy', function(e){
// So, you want to copy the current status of your game? No problem.
// Let's say this game generates a number of PNG graphics from CANVAS 
tags
// and keeps them in memory in ArrayBuffers or something

var html = 'player\'s medals: ';
e.clipboardData.items.add(html, 'text/html');
e.clipboardData.items.add(new File(medals[0], 'medal.png', 
{type:'image/png'}));
e.clipboardData.items.add(new File(medals[1], 'medal.png', 
{type:'image/png'}));
e.preventDefault();

}, false);

> Second, can you provide the javascript for how a site would put them into the 
> pasted markup during paste?

The way I thought this would work, would be that the site starts XHR uploads 
from the paste processing, and shows some intermediate 'loading' animation or 
something before it gets the final URLs back from the server. A bit like this 
(although some things could be more elegant, like the insertion of the data 
which needs to take cursors and selections into account):

http://jsfiddle.net/2Qqrp/

Thinking about it, it may be considered somewhat wasteful (or exceedingly slow 
- if for example the embedded data is a video) to do it this way - but it 
quickly gets complex and/or confusing if we have a some "show this local file 
until it's uploaded, then reference the online file instead" magic..?

-Hallvord