Minutes 14 March Re: Meeting tomorrow

Minutes are online at https://www.w3.org/2017/03/14-editing-minutes.html and below as plain text version. Next meeting 11 April, 1pm Boston time. That's 10am US pacific, 1700Z, 6pm UK Summer time, 7pm Central Europe, etc: https://time.yandex.com

cheers

                               Editing TF

14 Mar 2017

   See also: [2]IRC log

      [2] http://www.w3.org/2017/03/14-editing-irc

Attendees

   Present
          chaals, johannes, chongz, Grisha

   Regrets
   Chair
          Johannes

   Scribe
          chaals

Contents

     * [3]Topics
         1. [4]dictionary or interface for static range
         2. [5]contentEditable=plaintext-only?
         3. [6]mark ranges with spellcheckedness?
         4. [7]getTargetRanges info outside beforeInput
         5. [8]Next meeting?
     * [9]Summary of Action Items
     * [10]Summary of Resolutions
     __________________________________________________________

   <scribe> scribe: chaals

dictionary or interface for static range

   [11]issue 38: dictionary or interface

     [11] https://github.com/w3c/input-events/issues/38

   JW: We discover that webkit is about to ship with an interface,
   and nobody seems opposed to it, so we can go back to that
   instead of using a dictionary, if nobody disagrees.
   ... Chong will this Static Range interface spec appear?

   CZ: Gary will make it.

   JW: So in Input Events we go back to what we had
   pre-dictionary.

   Grisha: OK

   RESOLUTION: We use interface for static range

contentEditable=plaintext-only?

   [12]issue 62

     [12] https://github.com/w3c/editing/issues/162

   JW: Webkit are *using* cE=plaintextonly, and Chrome has been
   shipping it. But if people are fine with adding this, it seems
   to make sense

   Grisha: Agree. Edge ships it too. Let's add it. There are some
   interop issues Ojan brought up, we can address those as we go.

   JW: So, we agree to add it.

   RESOLUTION: We add plaintext-only as a cE type

   JW: So, are people OK with the idea that there are no
   beforeInput formatting events…

   <johanneswilm> [13]https://github.com/w3c/editing/issues/162

     [13] https://github.com/w3c/editing/issues/162

   Grisha: Missed that comment. What values do we fire the events
   for

   JW: We'll fire them for the text itself, but not for e.g.
   "bold".
   ... ctrl-B won't make an event, but "w" "3" "c" will make
   events for the text…

   Grisha: Need to think about use cases here, let's open an
   issue.

   JW: OK
   ... What about pasting into plaintext only?
   ... Both wanted to ignore formatting if you paste into
   plaintext-only

   Grisha: That makes sense.

   JW: It's a draft, not a finished stone, but let's put that in,
   and raise issues to check whether we really agree.
   ... Ojan's point - what happens if you hit enter.

   Grisha: Yep

   RESOLUTION: If you paste into plaintext-only you get text but
   no formatting

   JW: Think this is already how Chrome works.

mark ranges with spellcheckedness?

   JW: If you do something yourself, the browser no longer knows
   if the text has been spellchecked or not.
   ... Webkit cannot give direct access to spellchecker in JS for
   security reasons

   Grisha: Similar in EdgeHTML. Spellchecker should be directly
   user-invoked. Don't see a justification to expose the
   functionality to JS devs

   JW: Alternative to getting direct spellcheck access is for the
   app to tell the browser whether a range has been spellchecked
   or not.
   ... this was a suggestion from Ryosuke, and it would be
   helpful. Question is where would such an interface live, are
   there more security issues with it, …

   Grisha: What's the use case?

   CMN: Where the application is handling input chunks, and the
   browser gets a pile of text, but doesn't know whether the input
   was spellchecked or the application wants the browser to
   spellcheck it.

   JW: Or where you merge two paragraphs in the application.
   ... Some editors try to hand as much as possible to the
   browsers. But where there is a collaborative editor, the word
   is being inserted by the JS, and the browser no longer knows
   which bits have been spellchecked.
   ... If we can't get a direct spellcheck API, it would be good
   to say "this should be spellchecked" or "this has been
   spellchecked"

   CZ: Can you prevent spellchecking in insertRange?

   JW: What is the mechanism, where you *want* something
   spellchecked?
   ... e.g. I write the sentence, my friend on his machine adds
   the word "not", but I still want my text to be spellchecked.
   ... (still in collaborative editor scenario)
   ... Think we are open to all kind of solutions, this is based
   on Ryosuke's proposal, but it is a use case that we want to be
   able to meet.

   [Hmm. Scratching of beards…]

   Grisha: Let's open an issue - I haven't thought enough about it
   yet.

   <scribe> ACTION: Johannes to open an issue on spellchecking and bug Grisha to
   shop it around internally

getTargetRanges info outside beforeInput

   JW: A few people have been talking about this. Where do words
   and sentences end? It's complicated and not going to get
   resolved soon, but it would be good if JS could try to act like
   the browser it is *currently* running in.
   ... so that if we trigger beforeInput we can know what is the
   targetRange for a word forward, or a word backward, so what we
   fire matches what the browser would do.
   ... where does this discussion go and how realistic is it to
   expose this information…

   CMN: The amount of work to get a formal model is possibly more
   work than bringing behaviour into alignment…

   JW: Yeah, but it seems there are external reasons why there
   won't be an effort to align. If we could have a sense of
   measurement - what does "one word forward" cover from *here*?
   ... Right now we implement our own understanding, and that can
   produce conflicts.

   Grisha: Talking about word or sentence end, do you mean line
   breaks or is there more?

   JW: In european languages we can generally find word and
   sentence divisions. But for some other languages that doesn't
   work well - to know where a japanese word ends you need
   something more like a language dictionary.

   <chongz> Just to clarify: Are we talking about this issue?
   [15]https://github.com/w3c/selection-api/issues/37

     [15] https://github.com/w3c/selection-api/issues/37

   JW: so if I want to move the cursor forward one word by script,
   or create a beforeInput that selects the word, I have to
   specify the targetRange. If my guess is different to the
   browser's guess, then they won't know what is going to happen
   when they try to e.g. select a word.
   ... It isn't just about changing selection

   CZ: Yeah, but using this you can get the piece of information
   you want.
   ... so this API solves the issue of finding what the word,
   sentence, etc is…

   JW: Sounds similar
   ... if this is the information needed to construct the
   targetRange, then that would do it.
   ... Yep, this looks like we can use it. So we point to this in
   selection API ...

   Grisha: WOuld be a good idea to construct an example to make
   sure it fits the requirements.

   JW: OK, this looks like something we should at least refer to
   in a note in the Input Events spec.

   <scribe> ACTION: JW write an example showing the use of the
   selection API to construct the targetRange and pointing to it…


Next meeting?

   JW: Let's plan for next month, and if we don't need it we'll
   cancel a week earlier.

   Grisha: +1

   CMN: Suggest we go with a plan for second Tuesday of the month,
   time as is.

   Grisha: time works for me.

   CMN: Let's pin it to second Tuesday of the month, 1300 Boston
   time.
   ... (because that's how W3C's systems default)

   RESOLUTION: Next meeting planned April 11, 10am Pacific, 1pm
   Boston, 1700Z 6pm London, 7pm Central Europe Summer Time.

   <scribe> ACTION: chaals to book the meeting bridge [recorded in
   [17]http://www.w3.org/2017/03/14-editing-minutes.html#action03]

     [17] http://www.w3.org/2017/03/14-editing-minutes.html#action03

Summary of Action Items

   [NEW] ACTION: chaals to book the meeting bridge

   [NEW] ACTION: Johannes to open an issue on spellchecking and bug Grisha to shop
   it around internally

   [NEW] ACTION: JW write an example showing the use of the
   selection API to construct the targetRange and pointing to it…


Summary of Resolutions

    1. [21]We use interface for static range
    2. [22]We add plaintext-only as a cE type
    3. [23]If you paste into plaintext-only you get text but no
       formatting
    4. [24]Next meeting planned April 11, 10am Pacific, 1pm
       Boston, 1700Z 6pm London, 7pm Central Europe Summer Time.


-- 
Charles McCathie Nevile - standards - Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Tuesday, 14 March 2017 18:04:55 UTC