See also: IRC log
<scribe> scribe: chaals
issue 38: dictionary or interface
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
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> 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.
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 [recorded in http://www.w3.org/2017/03/14-editing-minutes.html#action01]
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? 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… [recorded in http://www.w3.org/2017/03/14-editing-minutes.html#action02]
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 http://www.w3.org/2017/03/14-editing-minutes.html#action03]
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/to tell/for the app to tell/ Succeeded: s/dics/disc/ Succeeded: s/showing this/showing the use of the selection API to construct the targetRange/ Succeeded: s/contextEditable/contentEditable/g Succeeded: s/Grisha +1/Grisha: +1/ Succeeded: s/issue and bug/issue on spellchecking and bug/ Present: chaals johannes chongz Grisha Found Scribe: chaals Inferring ScribeNick: chaals Got date from IRC log name: 14 Mar 2017 Guessing minutes URL: http://www.w3.org/2017/03/14-editing-minutes.html People with action items: chaals johannes jw WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]