[Editing] Tracking Issues in GitHub

[Ben Peters]

In order to simplify and streamline communication on open issues for Editing 
and Intentions, I suggest we have more conversations on GitHub. To that end, I 
have opened Issues for the list of bugs in the spec, and removed them from the 
spec itself. If there are no objections, please check out our GitHub Issues 
page [1] to open new issues and comment on existing issues.

Ben

[1] https://github.com/w3c/editing-explainer/issues

Re: CfC: publish LCWD of Screen Orientation API; deadline September 18

[Arthur Barstow]

During this CfC, Jonas submitted some comments to this list starting 
with the following:




Jonas - did Mounir's responses adequately address your comments or is 
there something you propose be done before LCWD is published?


There were also comments by Anne on Github (see [1]) and as I understand 
it, those comments were addressed by Mounir. Anne - would you please 
confirm if your comments have been adequately addressed?


-Thanks, ArtB

[1] https://github.com/w3c/screen-orientation/commits/gh-pages

On 9/11/14 5:19 PM, Arthur Barstow wrote:
Mounir and Marcos would like to publish a LCWD of The Screen 
Orientation API and this is a Call for Consensus to do using the 
latest ED (not yet in the LCWD template) as the basis:


  

The spec has three open Issues, all labeled Future + Enhancement and 
the Editors propose these Issues not be addressed for this first 
version of the spec:


  

This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD. Note the Process 
Document used by this group states the following regarding the 
significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

If you have any comments or concerns about this CfC, please send them 
to public-webapps @ w3.org by September 18 at the latest. Positive 
response is preferred and encouraged and silence will be considered as 
agreement with the proposal.


The proposed review period is 4 weeks.

Assuming this CfC passes, if there are any specific groups (e.g. 
script-coord, TAG, WAI, Privacy IG, Security IG, Mobile IG, etc.) or 
external SDOs we should explicitly ask to review the LCWD, please let 
us know.


-Thanks, AB

CfC: publish FPWD of Selection API; deadline Sept 30

[Arthur Barstow]

Ryosuke proposes WebApps publish a First Public Working Draft of 
Selection API and this is a Call for Consensus to do so, using the 
following Editor's Draft as the basis (draft FPWD is [1]):


  

This CfC satisfies the group's requirement to "record the group's 
decision to request advancement".


By publishing this FPWD, the group sends a signal to the community to 
begin reviewing the document. The FPWD reflects where the group is on 
this spec at the time of publication; it does _not_ necessarily mean 
there is consensus on the spec's contents.


If you have any comments or concerns about this CfC, please reply to 
this e-mail by September 30 at the latest. Positive response is 
preferred and encouraged, and silence will be considered as agreement 
with the proposal.


Ryosuke - the current title is "Selection API Specification". Is the 
"Specification" part necessary? If not, perhaps it can be deleted.


-Thanks, AB

[1] 
 

Re: [selection-api] Moving toward First Public Working Draft

[Arthur Barstow]

On 9/22/14 3:55 PM, Ryosuke Niwa wrote:

I think the latest documentation is pretty complete except it’s missing one 
major feature: selection.modify [1].

There was a discussion that took place in WHATWG [2] and there was a 
disagreement on the use case and the purpose of this particular API among UA 
implementors.

I can add that note to the specification for completeness before FPWD is 
published for the patent protection purposes.


OK, please do. Shortly, I'll start the CfC for FPWD.

-Thanks, ArtB


[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=9514
[2] http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Mar/0297.html

Re: [selection-api] Moving toward First Public Working Draft

[Ryosuke Niwa]

On Sep 20, 2014, at 5:52 AM, Arthur Barstow  wrote:

> Hi Ryosuke, Ben, Kenji, All,
> 
> I'm looking for feedback about moving the Selection API [ED] to First Public 
> Working Draft (FPWD) ...
> 
> A `rule of thumb` I generally use when considering if a spec is ready for a 
> FPWD is if the feature set is mostly complete although there is no 
> expectation all features are fleshed out in detail (IOW, looking for breadth 
> mostly complete but not depth). The breadth question is important because a 
> FPWD is also used as an "attorney snapshot" vis-à-vis the [PP]. Regarding the 
> spec's open [Issues], there is no expectation a FPWD be bug/issue free (in 
> fact, it would be rare if that was the case).
> 
> What are your thoughts about publishing a FPWD? Do you consider the latest ED 
> to be feature complete; and if not, what major features are missing?

I think the latest documentation is pretty complete except it’s missing one 
major feature: selection.modify [1].

There was a discussion that took place in WHATWG [2] and there was a 
disagreement on the use case and the purpose of this particular API among UA 
implementors.

I can add that note to the specification for completeness before FPWD is 
published for the patent protection purposes.

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=9514
[2] http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Mar/0297.html

- R. Niwa

Re: User Intentions Explainer (was: List of Intentions)

[Johannes Wilm]

On Mon, Sep 22, 2014 at 3:46 PM, Richard Schwerdtfeger 
wrote:
>
> So, you want to modify contenteditable to "minimum". What will that do to
> existing apps. that are built on it?
>
>
As has been mentioned before, the current (and broken) contenteditable will
stay the way it is, to make sure that nothing breaks for anyone.
contenteditable=minimal or some derivative thereof will come additionally.
With time, when all the frameworks have switched and the usage of
contenteditable is close to zero, I would imagine that browser makers would
likely decide to remove the contenteditable code.

As for Ben's comments -- I think the question he made was to the main
general purpose editors that stand for most of the user created content on
the web. CKeditor is certainly one of them. Others are TinyMCE and possibly
Aloha. And then there are a number of editors created by the browser makers
themselves -- everything from Gmail, Google Docs to Micrsoft's online Word
processor.

Ben was asking whether being able to add items to the right-click context
menu would be something editor creators would like to do. The issue with
this was at least in the past that one can only choose to entirely replace
the context menu, or not at all. If one replaced it, the browser's spell
checker was gone. If one didn't replace it, there was no way to add extra
options. Has this changed at all?

I see for example that CKeditor has chosen to replace the context menu, and
so the spell checker is gone.  Would users of CKeditor not like to have
access to the spell checker? Have you received any feedback on that?

And for those who currently write the specs -- what more information would
you need to go ahead?

-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org

RE: User Intentions Explainer (was: List of Intentions)

[Richard Schwerdtfeger]

Rich Schwerdtfeger

Ben Peters  wrote on 09/19/2014 03:55:46 PM:

> From: Ben Peters 
> To: Piotr Koszuliński , Frederico
> Knabben 
> Cc: Johannes Wilm , "public-editing-
> t...@w3.org" , Julie Parent
> , "public-indie...@w3.org"  u...@w3.org>, public-webapps 
> Date: 09/19/2014 03:56 PM
> Subject: RE: User Intentions Explainer (was: List of Intentions)
>
> I agree that we can divide this work, but so far I think we should
> do "2" first. Being able to remove browser functionality with a
> simple API is going to be far quicker to implement (in browsers) and
> provides immediate benefit. Solving Intentions will be a longer
> process, but is also important to really enable performance and
> "extensible-web" scenarios.
>
> On Tue, Sep 9, 2014 at 4:28 AM, Piotr Koszuliński
>  wrote:
> > I'm not sure if I remember correctly, but I believe that after long
> > discussions we left the question "what should contenteditable=minimal
be?"
> > unanswered. First the intention events lists should be created, so we
can
> > see what needs to be handled. And this is what Ben Peters is working
on.
> >
> >> Still we may also take in consideration that there are limited
resources
> >> available for working on the specs. Therefore the whole work could be
> >> separated into two *independent* topics:
> >>  1. Intention events + execCommand.
> >>  2. contenteditable=“minimal”
> >
> >
So, you want to modify contenteditable to "minimum". What will that do to
existing apps. that are built on it? We have a number of IBM web
applications that use contenteditable as do many other companies. CKSource
(Piotrek is the lead developer) has an open source product called ckeditor
that IBM contributed accessibility support to and so it is now used by many
large enterprises including Oracle.
A migration strategy is needed for existing consumers of contenteditable.

> > That's what I was proposing as well - to have the base (which consists
> > mainly of fixed selection API and intention events) ready as soon as
> > possible, so hopefully browser makers can start implementing it and
then we,
> > editor makers, can start using it. This part will already improve the
> > current situation a lot, but it's itself pretty hard as we can see.
Then, if
> > anyone will be still interested, a specification for default browser's
> > actions can be created. It's a huge task and there are a lot of
> > controversial topics like the famous delete/backspace behaviour when
merging
> > blocks and that's why I would not recommend starting these discussions
right
> > now.
> >
> >
> >
> > On Tue, Sep 9, 2014 at 12:59 PM, Frederico Knabben

> > wrote:
> >>
> >> On Tuesday, 9 September 2014 at 11:13, Frederico Knabben wrote:
> >>
> >> I don’t think that browsers having time/will for it today is a good
> >> argumentation for not doing it. The specs have a critical and noble
scope,
> >> of serving as reference for the future of the web. We’re talking about
the
> >> future after all.
> >>
> >> Still we may also take in consideration that there are limited
resources
> >> available for working on the specs. Therefore the whole work could be
> >> separated into two *independent* topics:
> >>
> >>  1. Intention events + execCommand.
> >>  2. contenteditable=“minimal”
> >>
> >> “1” should be concluded asap, because it is the foundation for the
success
> >> of “2”. It is also compatible with the current
> contenteditable=“true”, so it
> >> should enable sites/frameworks to fix the current status of things.
> >>
I have to agree with Piotrek, 1 is more important to get done first. It is
very important for mobile and we have real problems with device specific
support across devices. We could refine 1 after 2 is attempted.


> >> “2” is the ideal world. Something that would require much more energy
to
> >> get done right. Still in the beginning, there should be an agreement
on
> >> what’s in and what’s out. Following that, several specs can get
started,
> >> each one defining the default behavior we want for each of the
features we
> >> want “minimal” to have. The first ofc, would be “Selection” (and
“Focus”!).
> >

Rich
> >
> >
> >
> > --
> > Piotrek Koszuliński
> > CKEditor JavaScript Lead Developer
> > --
> > CKSource - http://cksource.com
> > --
> > Follow CKEditor on: Twitter | Facebook | Google+ | LinkedIn