Re: [Editing] Splitting Selection API Into a Separate Specification

[Ryosuke Niwa]

I've uploaded the first cut the selection API specification unofficial draft at 
https://github.com/rniwa/selection-api

I've modernized and rephrased the text; e.g. the spec refers to browsing 
context instead of defaultView, and defines selection's range being null as 
being "empty".

Finally, I've turned all Aryeh's comments and notes into notes that are 
visible.  We can remove those comments as we solidify the spec. and get 
implementation reports.


As mentioned in the spec (thanks to Aryeh), there are 11 serious open issues in 
the current draft.  The most serious one is that stringification of selection 
is completely undefined due to its dependency on innerText, which in turn is 
also undefined.

Given defining innerText is completely outside the scope of the selection API 
specification, we might need to defer this part to a level 2 specification 
since the only alternative is to wait for someone to write a innerText spec.


While I completely forgot to mention at F2F today, I'm looking for a test 
facilitator.  Aryeh has already written some tests in 
https://dvcs.w3.org/hg/editing/raw-file/tip/selecttest/ so he/she just needs to 
import those into web-platfrom-tests repository on github, and modernize them 
as needed.

- R. Niwa

On Mar 13, 2014, at 4:43 PM, Ryosuke Niwa  wrote:

> Hi,
> 
> It appears that there is a lot of new features such as CSS regions and shadow 
> DOM that have significant implications on selection API, and we really need a 
> spec. for selection API these specifications can refer to.
> 
> Thankfully, Aryeh has done a great work writing the spec. for selection API 
> as a part of HTML Editing APIs specification [1] but no browser vendor has 
> been able to give meaningful feedback or has implemented the spec due to the 
> inherent complexity in HTML editing.  As a result, the specification hasn't 
> made much progress towards reaching Last Call or CR.
> 
> Given the situation, I think it's valuable to extract the parts of the spec 
> that defines selection API into its own specification and move it forward in 
> the standards process so that we can make it more interoperable between 
> browsers, and let CSS regions, shadow DOM, and other specifications refer to 
> the specification.
> 
> Any thoughts and opinions?
> 
> [1] https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html
> 
> - R. Niwa
> 
> 

[April2014Meeting] Draft minutes for April 10

[Arthur Barstow]

The Draft minutes from WebApps' April 10 f2f meeting are at the 
following and copied below:




Corrections, comments, etc., are welcome.

Thanks very much to the various scribes!

-AB

W3C 


 - DRAFT -


 WebApps f2f Meeting (San Jose CA US)


   10 Apr 2014

See also:IRC log 


   Attendees

Present
   Adrian_Bateman, Ali_Alabbas, Arnaud_Braud, Art_Barstow, Ben_Peters,
   Dave_Raggett, Feras_Moussa, Glenn_Adams, Hiroyuki_Aizu,
   Israel_Hilerio, John_Hazen, Laszlo_Gombos, MikeSmith,
   Mounir_Lamouri, Philippe_Le_Hegaret, Phillipe_LeHegaret,
   Robin_Berjon, Ryoskue_Niwa, Takeshi_Yoshino, Yves_Lafon, krisk,
   Anssi_Kostiainen, Zhiqiang_Zhang, Matt_Falkenhagen, Dominic_Cooney,
   Jungkee_Song, Bryan_Sullivan, opoto, Janusz_Majnert, Wonsuk_Lee,
   Xiaoqian, Jinsong, Zhiqiang, Baoping, Tantek, Ted, Brad, Jonas,
   Dimitry, arunranga, Chris_Wilson, Alex_Russell,
   Chaals_Neville(remote), Joshua_Bell, Ted_OConnor
Regrets
   Chaals
Chair
   Art
Scribe
   Art, plh, krisk


   Contents

 * Topics 
1. PubStatus 
2. File and Filesystem APIs
   
3. Service Workers
   
4. PUSH API 
5. Manifest For Web Apps
   
6. indexedDB v2
   
7. screen orientation
   
 * Summary of Action Items
   



 Scribe: Art

 ScribeNick: ArtB

 on the bridge, Bryan Sullivan (AT&T)

http://www.w3.org/2008/webapps/wiki/PubStatus#API_Specifications

 scribe: plh


 PubStatus

Art:Clipboard API
... we have a status report as of April 8
... the editor isn't around

Ryo:some discussions on how to spec the markup
... this will take a couple of years to spec
... seralizing the DOM, including style, is complex
... I'll post more details on the list
... but it will take a long time

Art:if folks are interested in moving this spec forward, please step up 
as always

... DOM3 Events
... we don't have the editors around either
... will be a third LC
... 12 bugs
... some concerns since HTML5 has a normative ref for it
... and would make life easier if DOM3 Events was a REC
... since it's not going to happen anytime soon
... I've been pushing this soec to go back to LC

Marcos:what's the dependency?

Robin:it's about the event types

Art:UIEvents is blocked on D3E
... Pointer Events depends on UIEvents
... Glenn expressed interest in moving forward D3E
... plan is to split out features that would prevent it to move forward

Adrian:plan to split out key names/values

 rniwa: wrong port?

 rniwa: should be 6665

Adrian:and proceed
... primary reason is that changing will happen to those anyway
... also want to review various mobile platforms and their keyboards

Art:DOM P&S
... pre-LC2 comment period
... last set of bugs submitted by Anne
... in the absence of issues in the next couple of days, we'll start LC2
... CfC to stop work on File API specs.
... no one objected

Ryo:any test on DOM P&S

*ACTION:*barstow update testing info in PubStatus for DOM P&S spec 
[recorded inhttp://www.w3.org/2014/04/10-webapps-minutes.html#action01]


 Created ACTION-714 - Update testing info in pubstatus for dom 
p&s spec [on Arthur Barstow - due 2014-04-17].


https://github.com/w3c/web-platform-tests/issues?labels=domparsing&page=1&state=open

https://github.com/w3c/web-platform-tests/pull/493

Art:FullSccreen API
... last update was 2 years ago
... plan was to copy a somewhat stable version into W3C spec
... whenever they think it's donish

Mike:zero bugs is the best you get from the WHATWG
... I don't think it's being worked on actively
... it's on a back burner

Art:any concerns?

 could we not copy other groups' work, causing forked specs?

Glenn:is there a dependency from HTML 5.0

Robin:Fullscreen is non-normative

Art:[reading Hixie's comments from IRC]
... let's move that to an admin topic
... (adding to the whiteboard)
... Gamepad
... they have one bug left
... will enter LC in Q2

Adrian:we're looking into this spec. filed a couple of bugs
... so some discussion left

 (Gamepad will be most probably enabled in FF29)

Art:(going to back to fullscreen)

Tantek:status sounds reasonnable
... Anne is doing most of the work there
... it's waiting for more implementation feedback

Art:implementation status?

Marcos:status is pretty good

*ACTION:*Art to follow with Tantek and Anne on next steps for 
fullscreen [

[Bug 25319] New: [imports]: Want some kind of imperative API

[bugzilla]

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

Bug ID: 25319
   Summary: [imports]: Want some kind of imperative API
   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

It would be nice to have a set of imperative API to

- load import dynamically
- list loaded imports

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

RE: [clipboard events] Pasting scenarios and the shape of clipboardData.getData(‘text/html’) return value

[Ben Peters]

> Also on Mac, there is no  and  and the
> serialized markup copied into the clipboard (called pasteboard on Mac) needs
> to contain the precisely the markup that got copied by the user.

Good point. Perhaps we should make sure any OS specific items like 
 are not visible in developer APIs.

> It has a few implications but one of which is that we need to serialize some
> semantic elements such as "a" and "h1" when a part of content inside such an
> element is selected because we don't want to simply copy the content with
> blue text and underline for "a" for example.  User expects the pasted
> content to be a functional hyperlink if it looks like an anchor.
>
> Even elements such as "b" may need to be treated special because inside a
> contenteditable region where styleWithCSS is false, we don't want copying
> and pasting the content already in the contenteditable to introduce inline
> styles or a new style element.
>
> There are other problems with more exotic features of HTML and CSS.  Another
> problem we recently found is that when the copied content contains position:
> fixed or position: sticky, we need to convert them to position: absolute and
> wrap the whole copied content with a position: relative box in order to
> prevent the pasted content to populate the paste destination.
>
> In general, it is my opinion that copy algorithm should be spec'ed at the
> same time as paste algorithm in the HTML Editing API, and both of them are
> extremely challenging task.

I would say we should start by defining the shape of the html DataTransferItem 
rather than the way browsers should handle specific markup. So to be clearer on 
that, on copy, the DataTransferItem should have this shape:




List of styles that apply to the markup. Classes are named copiedStyle_uniqueID


Copied markup



Then on paste, the DataTransferItem should contain everything on the clipboard, 
possibly minus OS specific things like .

This way developers can generally count on being able to expect a full html 
page being available on paste, with hard styles (inline styles) in the markup, 
and theme styles (from the cascade) being available in the head. 
Implementations that don't have extra styling information in the head or inline 
the styles in the body don't break the model, they just don't allow the same 
level of control on paste.

[Bug 25314] New: screen.orientation.angle should be an unsigned short

[bugzilla]

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

Bug ID: 25314
   Summary: screen.orientation.angle should be an unsigned short
   Product: WebAppsWG
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Screen Orientation
  Assignee: mou...@lamouri.fr
  Reporter: mou...@lamouri.fr
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

The main purpose of that is to use the value for computation. It's a bit of a
shame that it is a string. Let's make it an number so developers don't have to
use parseInt() on it. Also, it will solve some issues Peter Beverloo had
(regarding watches that could have non rectangular screen).

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

[Bug 25313] New: Improve and add examples

[bugzilla]

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

Bug ID: 25313
   Summary: Improve and add examples
   Product: WebAppsWG
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P3
 Component: Screen Orientation
  Assignee: mou...@lamouri.fr
  Reporter: mou...@lamouri.fr
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org, w...@marcosc.com

I would like to add more useful examples but wait for the spec to be quite
stable. Ideally, when it will reach LC.

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

Re: [April2014Meeting] Building an Issue and Bug focused agenda

[Dimitri Glazkov]

>
>
> * Imperative Content distribution API
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18429
>

Also started a gist with some discussion fodder for tomorrow:
https://gist.github.com/dglazkov/ce96f673b0b2ce7b8c55

:DG<

Re: Screen Orientation Status

[Mounir Lamouri]

On Tue, 8 Apr 2014, at 9:08, Bruno Racineux wrote:
> On https://www.w3.org/Bugs/Public/show_bug.cgi?id=25088 :
> 
> You cannot fire on window without also having the window.orientation
> property (with its own issues*). That would break existing code relying
> on
> the webkit api (expecting to read a value on window.orientation).

I understand your concerns. Blink is implementing the legacy Webkit
window.orientation API so we will definitely send feedback here, and the
specification will be modified accordingly if we can't implement this
wrt backward compatibility.

> I am not sure, I was able to get my point across previously, for lack of
> feedback on it, but I strongly believe that mixing 'device' orientation
> and 'screen' orientation is a mistake going forward and important point.
> 
> In the not so distant future, we will likely use screens 'attached'
> to mobile devices. In that, the screen will be entirely independent from
> the mobile table/phone/watch/etc.
> 
> Sample use case:
> Let's imagine an ipad like 'iScreen' plugged to an iPad with dual screen
> capability with two different browser viewport on each screen.  When the
> iPad rotates, it shall only fire for the iPad screen, not the external
> iScreen if the later doesn't rotate, and vice-versa.
> 
> How will you differentiate those two from an implementation standpoint?
> I have no idea how that goes, but I'd like to raise that question.

I don't think the specification should handle multi-screen scenarios
explicitly given that window.screen doesn't and the Web usually doesn't
too. However, we should make sure that we actually match window.screen
so I will change the specification to make sure the screen is the
"output device". That way, we should get consistency between the values
of window.screen and window.screen.orientation.

Note that if you are interested in the scenarios you are mentioning, you
might want to have a look at the webscreens CG.

-- Mounir

[Bug 25311] New: Keep consistency wrt the screen definition with CSS View

[bugzilla]

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

Bug ID: 25311
   Summary: Keep consistency wrt the screen definition with CSS
View
   Product: WebAppsWG
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Screen Orientation
  Assignee: mou...@lamouri.fr
  Reporter: mou...@lamouri.fr
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

We might want to define the screen as the "output device", as the CSS View spec
does. We want to make sure that window.screen values will match
window.screen.orientation.

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

Re: [clipboard events] Pasting scenarios and the shape of clipboardData.getData(‘text/html’) return value

[Ryosuke Niwa]

On Apr 9, 2014, at 1:58 PM, Ryosuke Niwa  wrote:
> On Apr 7, 2014, at 3:37 PM, Ben Peters  wrote:
> 
>> After working with developers inside and outside Microsoft, it seems 
>> there are several types of paste that make sense in various scenarios. 
>> For instance, 
>> 1- if pasting into a rich document, it could be important to maintain 
>> source styling information. 
>> 2- When pasting into a wiki from an external source, it might make more 
>> sense to maintain destination styling instead. 
>> 3- When copying from a wiki and pasting back into that same wiki, it 
>> makes sense to maintain any special formatting on that text (inline 
>> styles) but otherwise to use the theme (style sheets). 
>> 
>> There is one other scenario here, which is to maintain the html shape, but 
>> not any styles.
>> 4- When seeking to maintain lists and tables, but format them with 
>> destination styles, it makes sense to remove style elements and style rules, 
>> but keep other html (  and  for instance ).
> 
> Right, that's an important use case to address.
> 
>> One possibility would be to do something similar to Firefox, but also 
>> include a text/css clipboard item, which contains styles relevant to 
>> what is copied
>> 
> How hard do you think this is to implement?
>> 
 Thanks for the code sample and thoughts! I'll run it by a few more 
 developers to get deeper insight and get back to you.
>> 
>>> Great! Note that the code samples are just to get us started thinking about 
>>> the issues we'll have to tackle if we're going to do this - if some other 
>>> behaviour (say, 
>>> creating new class names and making up a new style sheet with 
>>> generated/computed styles) is easier to implement or seems to make more 
>>> sense by all means 
>>> suggest that other behaviour instead.
>> 
>> In order to support the 4 scenarios I mentioned above, we need to be able to 
>> distinguish inline css from style sheets. Your idea here about creating a 
>> new style sheet seems like a good way to go since it helps solve the 
>> selectors problem where css doesn't work the same once you remove the 
>> context by copying a section out, and it keeps the inline styles separate 
>> from the style sheets. We could include this styles in the head of the 
>> document or in a new text/css item.
>> 
>> On copy, we would take something like Chrome's algorithm to get relevant css 
>> for each element. For top-level elements, this would mean several rules by 
>> default to 'reset' the style, and anything other relevant styles. We would 
>> create a new class for each unique set of computed styles and give it a name 
>> that can be recognized and unique, maybe "copiedStyle_" where 
>>  is a guid or similar. We would also remove any inline style 
>> elements like Chrome/Firefox already do. So on copy you would get something 
>> like this on the clipboard:
>> 
>> Version:0.9
>> StartHTML:000157
>> EndHTML:03
>> StartFragment:01
>> EndFragment:02
>> SourceURL:http://en.wikipedia.org/wiki/Darth_vader
>> 
>> 
>> 
>> .copiedStyle_12345 {
>>  color: black; background-image: none; font-weight: normal; margin: 0px 
>> 0px 0.25em; overflow: hidden; padding: 0px; border-bottom-width: 1px; 
>> border-bottom-style: solid; border-bottom-color: rgb(170, 170, 170); 
>> font-size: 1.8em; line-height: 1.3; font-family: 'Linux Libertine', Georgia, 
>> Times, serif; font-style: normal; font-variant: normal; letter-spacing: 
>> normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: 
>> none; white-space: normal; widows: auto; word-spacing: 0px; 
>> -webkit-text-stroke-width: 0px; background-position: initial initial; 
>> background-repeat: initial initial;
>> }
>> 
>> 
>> 
>> Darth 
>> Vader
>> 
>> 
> 
> Somewhat tricky issue here is that when this content is pasted into some 
> page, that page may also have other CSS rules defined.  Depending on 
> selectors they use, they might have a higher precedence than the single class 
> name we use in the copied content.  We could add !important to each property 
> but that could cause an issue if the pasted content is later edited, say, 
> inside a contenteditable region.

Also on Mac, there is no  and  and the 
serialized markup copied into the clipboard (called pasteboard on Mac) needs to 
contain the precisely the markup that got copied by the user.

It has a few implications but one of which is that we need to serialize some 
semantic elements such as "a" and "h1" when a part of content inside such an 
element is selected because we don't want to simply copy the content with blue 
text and underline for "a" for example.  User expects the pasted content to be 
a functional hyperlink if it looks like an anchor.

Even elements such as "b" may need to be treated special because inside a 
contenteditable region where styleWithCSS is false, we don't want copying and 
pasting the content already in the contente

[Bug 25310] New: Move the HTML specification monkey patching to the HTML specification

[bugzilla]

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

Bug ID: 25310
   Summary: Move the HTML specification monkey patching to the
HTML specification
   Product: WebAppsWG
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P3
 Component: Screen Orientation
  Assignee: mou...@lamouri.fr
  Reporter: mou...@lamouri.fr
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

As soon as the specification is stable enough, we should move the HTML
specification monkey patching to the appropriate specification.

It should probably be done when the spec is in LC.

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

Re: Should events be preferably sent to the Window or the nearest object?

[Mounir Lamouri]

On Thu, 10 Apr 2014, at 0:01, Arthur Barstow wrote:
> Perhaps it would be good then to file a bug for the Screen Orientation 
> spec and/or to add a related note to the ED. WDYT?

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

-- Mounir

Re: [April2014Meeting] New PushAPI ED uploaded

[Arthur Barstow]

Thanks for this information Bryan! Yesterday, Jungkee and Wonsuk said 
they would like to discuss Push API during today's meeting and suggested 
a good time slot would be after the Service Worker slot (which is 
13:30-14:30). Can you join via Zakim at 14:30(+) today? I've tentatively 
updated the agenda accordingly 
.


-AB

On 4/9/14 9:32 PM, ext SULLIVAN, BRYAN L wrote:


Hi all,

I have updated the PushAPI ED for a variety of recent discussions 
including many of the TAG review comments. The new ED is at 
https://dvcs.w3.org/hg/push/raw-file/tip/index.html. This ED will be 
the basis for discussions at the F2F, which I will be dialing into.


Here is a summary of the changes since the last ED:

-  Added optional registerOptions parameter in register 
interface.


-  Added optional body in push message

-  Remove System Messages: changed references to "System 
Messages" to "events" generically. "System Messages" section was 
renamed "Push Events".


-  Globally changed "notification" to "message".

-  Added "7.3 Push Registration Persistence" to clarify 
how registrations preserved between sessions.


-  Added "5.1 Push Server Discovery and API Use" to 
illustrate how webapps may (hypothetically) determine the applicable 
push system, and use Push API data in Push Server API requests.


-  Edited "5. Push Framework" for clarity, to clarify what 
information is passing through push service, and how user-agents are 
authenticated.


-  Updated the example code based upon Alex's service 
worker based example. It needs to be enhanced to include other push 
systems as examples, e.g. include their data in the registerOptions.


-  Added "7.4 Push Registration Uniqueness" to clarify for 
TAG comment that same-origin webpages do not share registrations.


-  Added text to "7.3 Push Registration Persistence" to 
clarify for TAG comment that how user-agents invoke inactive webapp is 
not described here... expected in Service Workers


-  Added text to "3. Terminology" and "4. Security and 
privacy considerations" for TAG comment, to clarify what is meant by 
"express permission"


-  In "7.2 Steps", per TAG comment removed the text "or 
alternatively that the requesting webapp has permission to deactivate 
such push registration", focusing the NoModificationAllowedError 
purely on the validity of the passed pushRegistrationId for this webapp.


-  Added notes for consideration of various TAG comments 
and suggestions.


-  Added text to "7.4 Push Registration Uniqueness" for 
TAG comment, to clarify that webapp association of specific 
registrations to "message streams or sources" is an application-layer 
concern, and that webapp servers can provide means to map 
registrations to specific webapp features/functions as needed.


-  Fixed various missing anchors to code elements

-  Fixed respec issues

-  Fixed normative vs informative reference issues

Thanks,

Bryan Sullivan | Service Standards | AT&T

Re: [admin] WebApps and the Proposed changes to the TR Process

[Charles McCathie Nevile]

On Thu, 10 Apr 2014 00:07:25 +0200, Arthur Barstow   
wrote:


TL;DR: April 21 is the deadline for comments for LC#2 of a revised  
Technical Reports (TR) process  
. If you have  
any comments about LC#2 itself, please send them to the public-w3process  
list .


Below are some of my thoughts about the proposed revisions to the TR  
process and WebApps ...


* I think the only really substantive change is the removal of LCWDs,  
thus a spec now goes from WD directly to CR. However, before advancing  
to CR, the group "must formally address all issues raised about the  
document since the previous publication". Additionally, there is still  
an expectation the spec will have wide review although the group has  
some flexibility to determine how that review is conducted (f.ex. who  
should be asked to review the spec, duration of the review, etc.).   
[ItSeemsToMe, this just means the old LC is now implied rather than  
explicit.]


The idea is that instead of setting an expectation of "do the spec, have a  
Last Call, then see if it works", groups should expect to work on specs  
with testing feedback as they go.


* Given WebApps' work mode and its history of getting specs to REC (see  
 for some data), for all  
practical purposes, if the group was using the proposed process, I don't  
think would have substantively changed the time to REC since the primary  
blocking factors have been lack of tests, lack of implementations and in  
a couple of cases PAGs.


Agreed.

[I mention this because some have stated the proposed process is `more  
agile`.]


I'm not quite sure what anyone means by that - it seems to be bandied  
around as a magical incantation more powerful than "in public" and "on  
github" combined...


My goal (as editor) was to have a process that was more flexible to match  
the few groups that still wanted to work on the "write a spec, deskcheck  
it, implement it" model, while supporting what I think is a far more  
common and usually more effective model of "write implement and test a  
piece, clean it up and start another piece (or two)".


The Process (contrary to what Art suggests below) does retain the idea of  
heartbeat publication, but rather than being based on time (unless nothing  
is happening at all) they are called for when there is a significant  
change that would benefit from broader review. I.e. as a signal for "look  
carefully at what we did here and here please".


* Regardless of the specifics of the TR process, the time to REC [which  
I understand is not necessarily a high priority for all] is still a  
function of: active and competent Editor(s), active reviewers, active  
implementers and commitment to testing and interop.


Well yeah. The real work doesn't change much.

* The current (2005) process permits a group to do as much work as they  
want before LC and thus minimize process and publication overhead. For  
instance, before LC, a group could seek wide review, create a test  
suite, implement the spec and prove interoperability. If a group worked  
as such, after the LC comment period ended  (and assuming no substantive  
comments require going back to WD/LCWD), the spec could skip CR and move  
directly to Proposed Recommendation. [I mention this because it appears  
the Gamepad API could be on this type of trajectory.]


* With the proposed TR process, if a group wants to minimize process and  
publication overhead, after the FPWD is published, there is no mandatory  
requirement that any other TR publication(s) be made before a CR is  
published.


There is a clear *should* requirement - there *should* be a TR publication  
when something significant has changed that would benefit from wide review.


(The process makes the hopeful assumption that the publication process  
itself gets reasonably streamlined).


This would certainly be a different workflow than we have followed in  
the past and I can see some +/- to this approach. If we were to do  
something like this, we would certainly want to make it very clear in  
the FPWD that this was the plan/expectation and strongly note that   
reviewers, implementers, etc. should only use the ED (and ignore the  
FPWD).


The proposed process doesn't particularly support that model (i.e. you are  
avoiding doing what it say you *should* do).


But in any event, a review snapshot and an ED are different. Implementors,  
and people working on the spec in the group, should usually be reading the  
Editor's draft.


But for reviewers who cannot follow the work as it moves through the group  
(time commitment, language difficulty, etc) having documents that are  
clearly identified as "for review" (and ideally, which point out which  
parts are worth reviewing because they have changed, which parts remain  
stable from the last such snapshot, which parts are basi