Re: Moving W3C Streams to Note and adding disclaimer [was: [charter] What is the plan for Streams API?]

[Michael[tm] Smith]

After looking back at how we’ve handled cases like this one in the past,
and after noting that we appear to already have some agreement that at
least a disclaimer of some kind would be appropriate here—and that it
would be uncontroversial to add one—I’ve gone ahead and done so.

That seems preferable to, say, just waiting to anything at all until more
of the relevant parties to the discussion who are on vacation now are back.

That said, moving the WD to Note of course would require a WG decision. So,
short of that, I think having the disclaimer on the drafts is as much as
can be done at this point.

  —Mike

-- 
Michael[tm] Smith https://people.w3.org/mike


signature.asc
Description: Digital signature

Moving W3C Streams to Note and adding disclaimer [was: [charter] What is the plan for Streams API?]

[Michael[tm] Smith]

Arthur Barstow , 2015-08-10 08:07 -0400:
> Archived-At: 
> 
> On 8/7/15 8:32 AM, Anne van Kesteren wrote:
> >On Fri, Aug 7, 2015 at 1:56 PM, Arthur Barstow  wrote:
> >>Given this status, and in the absence of other feedback, I think the Streams
> >>API should remain in WebApps' charter (at least for now). Then later, the
> >>work may proceed (if there is still agreement an additional API would be
> >>useful); otherwise, if there is agreement to stop the work, the work can be
> >>stopped (and a WG Note published).
> >What would this additional API do?
> 
> Given Takeshi's status it seems premature to speculate.

Given that Takeshi said:

> I don't have bandwidth to maintain W3C version of the spec even briefly
> currently...

...it seems we can’t actually claim to even have an active editor for the
spec. And the https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm
source hasn’t had any changes in more than 10 months, which was also when
the https://www.w3.org/TR/streams-api/ WD was last updated.

> The current [TR] is now mostly void of content although it might be good to
> gut it even more as well as to add a clear note that indicates that work has
> stopped and might not resume.

On their own, the two facts that we lack of an active editor and that the
ED hasn’t had any changes in more than 10 months would normally be more
than sufficient grounds for moving the WD to Note right now, and to either
completely gut the ED or just make its URL redirect to the upstream spec.

But if we lack the collective will to go ahead and move that WD to Note
now, and to do the right thing with the ED, then we should at least as soon
as possible clearly mark both the WD and ED with big bold warnings saying
“Do not use this for anything, do not link to it as if it were representative
of current implementation plans.” or whatever.

Because in the mean time we have some widely-read pages such as the one at
https://dev.modern.ie/platform/status/streamsapi/ that are referencing the
https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm document, and
that thus are giving misleading information to people (including implementors
who I’ve personally seen confused by it in discussions) about which spec it
is that UAs are actually implementing (or planning on implementing). And
experience tells us that’s never a good thing to have happening.

  —Mike

Arthur Barstow , 2015-08-07 07:56 -0400:
> Archived-At: 
> 
> On 8/5/15 10:53 AM, Takeshi Yoshino wrote:
> >+domenic
> >
> >We've recently finished the ReadableStream part of the spec and
> >experimenting integration with the Fetch API. Most of the spec is still
> >unstable. I don't have bandwidth to maintain W3C version of the spec even
> >briefly currently...
> 
> Hi Takeshi, All,
> 
> Given this status, and in the absence of other feedback, I think the Streams
> API should remain in WebApps' charter (at least for now). Then later, the
> work may proceed (if there is still agreement an additional API would be
> useful); otherwise, if there is agreement to stop the work, the work can be
> stopped (and a WG Note published).
> 
> -Thanks, AB

Takeshi Yoshino , 2015-08-05 23:53 +0900:
> Archived-At: 
> 
> 
> +domenic
> 
> We've recently finished the ReadableStream part of the spec and
> experimenting integration with the Fetch API. Most of the spec is still
> unstable. I don't have bandwidth to maintain W3C version of the spec even
> briefly currently...
> 
> Takeshi

Arthur Barstow , 2015-08-04 10:13 -0400:
> Archived-At: 
> 
> On 7/30/15 8:46 AM, Arthur Barstow wrote:
> >
> 
> The WebApps + HTML WG draft charter says the following about WebApps'
> Streams API:
> 
> [[
> Streams API 
>An API for representing a stream of data in web applications.
> ]]
> 
> I believe the previously agreed "plan of record" for this spec was to create
> an API on top of . Is that still something
> this group wants to do, and if so, who can commit to actually doing the
> work, in particular: editing, implementation, and test suite?
> 
> If we no longer have committed resources for doing the above tasks then this
> spec should be removed from the draft charter.

-- 
Michael[tm] Smith https://people.w3.org/mike


signature.asc
Description: Digital signature

RE: Copying multi-range selection

[Phillips, Addison]

> > This appears to make visual selection appealing--although it doesn't, for 
> > the
> reasons mentioned elsewhere, lead to sensible text operations unless the
> selected run happens to be all in a single direction.
> 
> and if the text runs all in a single direction, there's no difference between
> logical and visual selection anyway, right?.
> 

Exactly so.

Re: Copying multi-range selection

[Richard Ishida]

On 15/08/2015 22:24, Phillips, Addison wrote:

This appears to make visual selection appealing--although it doesn't, for the 
reasons mentioned elsewhere, lead to sensible text operations unless the 
selected run happens to be all in a single direction.


and if the text runs all in a single direction, there's no difference 
between logical and visual selection anyway, right?.



ri

Re: Custom elements "Constructor-Dmitry" baseline proposal

[Anne van Kesteren]

Thank you for writing this up. Would be interesting to hear what
Maciej and Ryosuke think.

On Tue, Aug 18, 2015 at 12:19 AM, Domenic Denicola  wrote:
> - Use symbols instead of strings for custom element callbacks.

So the way this is done is that they are publicly available on the
prototype. Does that mean behavior can change during the lifetime?
What does that mean for builtin elements that do not have these
callbacks on their prototype?

Also, we probably need to rename registerElement() due to the
different semantics.

Also, you want to sort the attributes in some way before calling
attributeChanged from upgrades, or we must finally agree on that
attributes are sorted in some deterministic way:

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

I also thought the idea was to pass attached/detached their changed
ancestor and perhaps rename them inserted/removed (and no longer scope
them to document change).


-- 
https://annevankesteren.nl/