See also: IRC log
<Florian> Meeting: Editing TF face to face
<Florian> rssagent, log
<rniwa> https://github.com/w3c/editing/issues/77#
<Florian> Scribe: Florian
<tantek> hello
Enrica: Should we keep talking about multirange selections?
Florian: let's do that when we have mozilla on the phone later today
Johannes: Ehsan will call at 2pm. We will talk about selection normalization then as well.
<chaals1> scribe: chaals
<Florian> Agenda: https://www.w3.org/wiki/Fall_2015_Editing_Taskforce_F2F_meeting
<Florian> https://github.com/w3c/editing/issues/72
<chaals1> JW: looking at issues 72 and 73, wonder if we should change the name of events, or keep it but make it clear that this is only for cE, or deal with input/textarea events (later?)
<chaals1> … stuff do deal with selection should be in the selection API.
<chaals1> … but they need the intention of what the user wanted to do…
<chaals1> RN: Fine to spec in selection.
… caret is a type of selection…
JW: What about name - does it apply to input fields as well?
RN: interesting question - what happens in a multi-range selection. Do we fire beforeinput events with multiple ranges, or multiple single events one per range?
JW: don't mind
FR: Think it is better to have a single event with all the data to eenable doing smart things
SW: so targetRanges?
Johan: then we need an array for the ranges.
… you can delete at multiple locations
RN: There isn't a way to insert different characters in different locations
FR: You can put the same data in multiple places at once...
SW: But it is the same data and three targetRanges
JW: So we need targetranges?
[yes]
JW: Input on what to do with input?
FR: This is pretty different, making it apply is odd. The name is confusing.
EC: Call it the editing event?
JW: beforeEditing?
EC: yeah, beforeEdit …
JW: Only applies to contenteditable, right?
PK: We have input on ce=true
JW: Input events have change and input. ce has input and what we call this...
SW: Problem?
FR: beforeinput doesn't work on input elements
[what the input event does]
<Florian> https://developer.mozilla.org/en-US/docs/Web/Events/input
FR: There is already a beforeinput event
JW: This spec has different fields for the event
… so can we override the other event, or should we call ours something else - beforeEdit?
… don't mind which.
FR: Ours is supposed to be the same as the general one, no?
<johanneswilm> http://w3c.github.io/editing/input-events.html
JW: Thought so, but seems not.
EC: In webkit we fire input events for input/textarea events...
… so they seem to be disjoint.
… Why don't we go completely disjoint?
JW: Think it is a good idea to have a different name.
PK: We should check other browsers too...
[should we use the input event? no, having multiple events of the same name leads to confusion]
PK: There is apparently input n ce in firefox but seems broken
<PiotrekKoszulinski> http://jsfiddle.net/hxh4ybsf/
[does pgup pgdn move the caret? Sometimes, but not others]
SW: We could spec it, but it would never fire in Safari
RN: it needs to fire in selection...
… so if we spec it that means we would need to support it
EC: Moving caret by a page isn't deterministic…
CMN: Not unusual for a user to do that though
SW: Wonder if we should be linking up everything that platforms can do.
… we *could* implement this - but think we're ratholing something that isn't that important.
RN: We wouldn't trigger this from user actions
SW: But if authors want to make something, good luck to them.
RESOLUTION: remove
caret, and put it in beforeselectionchange in selection
API
... We call the relevant events edit and beforeedit (instead of
overloading input)
EC: If we do this let's have home, start/end of doc, etc etc
RN: Home is line boundary, ctrl-home is document boundary
EC: So we are left with the things that are not selection… insert/replace char/text/content, un/do
RN: Why do we need different things for replacing text or content?
JW: Don't suppose we do. Lets get rid of replaceText and make it content.
RN: Might want to add another boolean for spellchecking
CMN: Does it matter?
EC: If you want to do visualisation ...
RN: IME will also do replacecontent
FR: The boundary between typing and spellchecking is fluid
EC: So this comes from the browser saying it wants to autocorrect something?
[is there a fingerprinting issue with noting something is autocorrected?]
[probably - you can see the dictionary, and how often people are making mistakes. But what's the real problem?]
SW: Don't think there is a real problem here
FR: What's the value in doing this?
PK: e.g. so you don't move the selection there
JW: That's why replacecontent should not move the caret.
SW: This would also happen on dictation, where words that were put there are updated later.
[When you replace content, the offset for the cursor is probably different…]
JW: Whatever the common behaviour is when content is replaced, keep doing that…
<johanneswilm> https://github.com/w3c/editing/issues/25
JW: MS Office team want to know the source for the edit event… #25
lya: if you have a floatingUI that comes up when you select something, you need to know how the selection happens
FR: so you get different behaviour depending on whether you used keyboard or mouse?
Grisha: Are they asking for this to be specified
JW: yes…
[do they need to know what they are actually asking here - what a given keyboard event will actually fire…]
SW: issue is that we don't support progressive enhancement and we need a viable way for that to happen…
FR: A browser may have an event type, but not actually fire it ever…
CMN: feature detection breaks…
SW: This is hard because our events fire after the old event, so you don't know if it will trigger the new event…
EC: Why not do something similar with execcommand - would that be crazy?
SW: Not for knowing the source of the event, but that is a different problem.
… hard part is knowing the set of sources
EC: We could have an enum that we can extend.
SW: remains an open issue.
CMN: there are a lot of gotchas, too
JW: That's not so hard, right?
FR: listing things isn't a great idea
Grisha: So we need a table of accelerators to fire a function… who maintains that?
JW: Your browser.
FR: That's the problem with the list - you don't know what to do with a source you didn't know about in advance
CMN: see also Brian Kardell's input-modality proposal in WICG
RN: Can we have a relatedEvent?
SW: Sometimes. But not if find causes a selection.
CMN: We don't really want authors listening to device-specific events, because they make a mess of it…
FR: Authors should not have to care about dev-specific events, but they should be able to care…
SW: Don't think supporting this is high priority
CMN: Maybe not, and it will probably be misused more than well used, but authors really really want it all the time :(
RN: If you have a timer to check whether an intention is for a particular keydown, we cannot guarantee the association.
SW: Having a pointer to the event that caused something, or null, might be enough.
RN: That would more or less address the use case.
FR: There is a risk that people will make assumptions about why they get null…
SW: Don't think it is a huge issue
RN: What if a combination of events were the cause of a single DI event?
SW: last one? Still don't think this is an important problem to solve.
RN: You want to prollyfill, so if there is a ctrl-C you set a timer to see if it fired a copy… and if it didn't, you fire one.
JW: you want to know what things are working...
SW: So #19 and #25 are the same thing?
CMN: similar…
FR: So the relatedEvent thing is probably not that bad...
TC: Maybe you really should record a use case of supporting polyfills
RESOLUTION: have a relatedEvent to point to the UI event that caused a DI event to be fired.
<rniwa> Filed https://github.com/w3c/editing/issues/78
Grisha: is there a reason to have the 3 different delete events?
JW: If people click delete button or backspace, you have different things happen.
… if you build track changes you get the intent to delete forward, move the caret
EC: can we have one delete event and use attributes? Ditto for insertCharacter/Line
RN: There is a difference between line break and paragraph break.
… don't think we want to collapse lines and characters - and would like to have a way of inserting a paragraph. Agree that we should have forward/backward as an attribute on the delete event.
[A use case for delete backwards - tracking changes means that the delete thing doesn't remove the content, but marks it and moves the caret backwards]
EC: When do we fire deleteContent?
RN: A default of keypress
FR: The default will be forward or backward
… we don't need deleteContent if it is only for an edge case
EC: So if someone presses an "h", what do I fire?
[insertcharacter, or replacecharacter]
CMN: with a delete event that has forward/backward, if it has neither then it is basically replace with nothing
FR: The problem is if you are listening for delete, when sometimes what is fired is a replace with empty, then you get complexity.
RESOLUTION: one delete event with data for forward/backward
FR: Typing/replacing at caret/selection uses insert, doing it elsewhere uses replace
RESOLUTION: We want to be able to insert newline or new paragraph
[lunch]
Ryosuke: If we allow JS to set selection, can we always render a selection caret?
… we currently do normalisation of selection endpoints, but going forward we want to change that.
EA: Gecko tries to be permissive, ask where the selection goes and try to get a caret there.
… there are edge case bugs, but we restructured this a few years ago which helped in a bunch of situations for getting carets where we couldn't.
… So things are better, but it isn't perfect yet. It is impossible to predict every possible place to put the caret.
RN: Would you be OK with not doing normalisation?
<ehsan> the audio feed stopped
<rniwa> Is Gecko okay with not normalizing selection when JavaScript modifies it
<ehsan> rniwa: ^
<ehsan> yes, in the abstract sense :)
RN: Current proposal is not to normalise selection when JS modifies it.
… do we need to specify a guarantee of wher the caret can be?
… e.g. we cannot render a caret in an element with display none.
… also in a japanese IME in composition there is often no caret.
… Can these be specified?
EA: Harder cases are where selection goes into part ofthe DOM that is obscured by another element.
<johanneswilm> examples of where the caret doesn't go or doesn't render: https://bug873883.bmoattachments.org/attachment.cgi?id=751510
… Or where user places caret next to an image. Should we render it on the border of the image?
… How does it combine with background colour of image…
… There are some other tricky cases. The button element - should it go inside it or not?
… there is a text node underneath it, so it makes sense to be able to edit that, or it is a form control and it makes no sense to allow editing it…
… there is value in specifying how the browser deals with these situations. We can normalise things, or list the possible cases…
JW: e.g. can't get between two canvas elements immediately adjacent in Firefox, can go between SVGs, but cannot in Chrome, etc...
… do we want a guarantee of where things will go?
EA: 2 cases to consider - caret when you are using keyboard to navigate, and when JS moves it. There are many places where you cannot get a caret with user navigation keys, but can do it wiith script.
… There are 2 classes of problems, some putting the caret there and some painting it.
RN: yes, we have those 2 kinds of issues.
EA: 3rd question - whether we should do caret navigation through the DOM or the rendered page.
… Gecko does screen-based navigation - sometimes weird but often better.
JW: We left how the caret moves unspecified for now. Important thing is that you can get the caret "everywhere it should" and be rendered there
… we want to avoid cases where the caret is now where it looks like it is. We realise there are places you cannot get to, but if we can move the caret there with JS that shoud be enough.
RN: Browser bugs *will* exist…
EC: Idea is that with JS you can place selection anywhere, and there will be no attempt to move it to be visible. So if it is put into an invisible element you just won't see it, but that will be a legitimate thing to do?
JW: In certain places we want a guarantee that the caret will be rendered.
RN: Don't think we need a restriction - I think it is premature to spec a list of places where carets must be rendered.
… we need implementation experience of not normalising first, and need to fix caret-painting bugs.
EA: Now position of caret is not observable by script. Are we going to add that?
RN: Think we are still using collapsed selection. We discussed this yesterday
… at boundary of bidi levels we could have two caret positions, so there would be two rectangles.
… We need to sort out carets in vertical mode, too.
EA: Collapsed selection is probably OK. Not sure it is useful for authors, but it is what we do now.
FR: Logical position of caret is offset, plus bidi level, plus if you are at a line break. This gives enough to find out where you are, or to specify where a caret should be.
RN: Discussed adding a new selection object. Current selection API seems to be misused. Argument that one reason is the interface makes it hard to understand that you have to get the counts and collect them, so Ojan selected we have an iterator of ranges that may help get better quality support.
… in multi-range world, the fact we have anchor, etc, looks like a single range and not so smart for a set of them.
… So if we have a multiple range selection in a new API, we can carry caret information better.
FR: Other issue motivating a new selection API was a desire for non-Live nodes…
EA: Performance implications for keeping ranges alive… supporting multi-range selections, do other vendors want to do it?
RN: Apple is - for example so you can select content visually when different boxes are laid out and aren't in DOM order.
FR: And selecting rectangles on a touch device…
… selecting across a user-select: none thing…
EA: We can enable users to select multiple things at a time - another example is selecting table cells.
… how many of these cases do we want to expose? (not all of them are necessary to support)
… Multi-range selection is very very difficult to implement properly - there are lots of points in code that need to deal with it.
… So it is great for the user, but very hard for the engine.
FR: If we let JS author create selections however tehy want, they can create e.g. overlapping ranges. We considered throwing exceptions to stop that, and backed off to say we would allow overlapping selections, only normalise if you tried to exec command, otherwise leave it up to the scripter to decide how to handle their weird results
EA: Seen pages put selections in places that make no sense. Hard to say what the right behaviour should be. Whatever we choose, we want to be consistent across browsers.
FR: Do you mean problem rendering selection, or how the selection braks exec comman in e.g. overlapping ranges
EA: We e.g. display visual selection behaviour selecting a run from RTL to LTR, but select logically, which is of course a bug
FR: If an editor wants to e.g. allow visual selection across bidi boundaries, they need multiple ranges and don't want the selection to move from under them?
PK: We like gecko's behaviour because we know where it will put text. For multi-range, allowing table selection is interesting even though it can be faked if it isn't supported.
EC: How does gecko handle copy? Do you take a single fragment or keep a set of fragments on clipboard?
EA: we iterate over each one, don't remember how we handle the gap…
… *think* we put some break between the ranges
FR: Seems like you put double line break between fragments.
EC: What happens if you copied 3 disjoint things and try to paste into 2 ranges.
FR: You replace the first range with the whole clipboard, and just delete the second range.
EA: This is an example of where correct behaviour is non-obvious. E.g. select items from an ordered list and an unordered list nested, and delete things so you promote list items from the sub-list to the parent list.
… ther are a lot of these tricky cases where we just do *something* because there is no sane behaviour.
FR: Tables are an example of where there is an obvious behaviour that is hard - e.g. copy column and paste to another column should not paste the column into the first replaced cell, but …
EC: WOuld be easy to leave it up to implementation what to do.
FR: The browser should do the simple and predictable thing, and leave it up to JS editor developers to customise behaviour in smarter ways.
EA: I am sure there are cases where it is hard to come up with "the simple predictable behaviour".
RN: Think the current plan for ce=typing is for each app to implement bolding, underline etc themselves, so they decide on what "sensible behaviour" is.
… if we want to let app decide what to do with multi-range copy/paste, we need to have the information available about where each piece came from.
… cut/paste multi ranges in the same place should look like a noop… which takes lots of information about what is in the clipboard
FR: We have beforeedit that says what is going to happen, but in order to do the smart thing, you need to have the structure available
… don't need to stitch together in the clipboard, do we?
RN: Stitching may not happen in clipboard. It doesn't assume there are multiple pieces in the clipboard - there is no way to support that
SW: Yes you can, at least on Mac, annotate types and multiple pieces.
EA: Even if clipboard understands format, you are bound by common denomiator of different clipboards. As far as I recall there is no clipboard that allows for multiple pieces somewhere, so gecko needs to stitch the pieces together.
EC: There is also the issue of exposing this to the clipboard API.
FR: If you don't have multi-piece clipboards, you may be able to intercept the copy event and annotate with extra information, but then those annotations will do weird things e.g. on paste inot a different application.
EA: You can copy different formats at the same time. If the goal is to have copy-paste within the browser, you can invent your own format.
… Paste into another application would show there is text/html (stitched) or magic-firefox-clipboard-format… would that be good enough, or cause problems because you can't paste from FF to IE?
FR: Or copy HTML table and paste into Excel
RN: We could spec the annotation we add in a browser to provide structure information…
… if that were supported across browsers it seems other apps could recognise it too.
EC: Not sure we should specify the clipboard format for native platform… we should specify what goes there to use with clipboard API
… anyone can specify as many formats as they want to post to clipboard. Think we should aim for copy/paste consistency within an app, not so sure we need to have fidelity copying from one browser to another.
FR: If we manage to get this working for a given browser, then maybe we can go to a standard clipboard format
RN: Browser vendors can't change the format, it is an OS-based format they use.
FR: But we can standardise an additional format that we could put in which is interoperable.
SW: We don't need to debate this now if it is a "later on" feature.
FR: We thought we had a non-overlapping set of things for when to delete and when to replace…
… but what if you do alt-backspace - delete something that isn't selected, but with direction.
… if delete doesn't have a range other than selection you cannot use it for e.g. previous line…
EC: Thought these were low-level events where you got the info backwards/forward. Now you are asking for more commands, like word or line.
JW: If the caret moves, why not select the word and then delete it?
FR: Yes, we could do that.
Perhaps save previous selection, delete the word, restore
...
... If browser has a native deleteWord, it is a thing that it
would do.
… depends on how that is implemented, maybe it already does the right thing.
JW: So the caret moves, so I think we are fine.
PK: What if I cancel the deletion but not the selection of the word before that.
JW: Tough luck…
FR: You don't know that you get select in order to delete.
CMN: If you have relatedEvent then perhaps you do...
RN: WHy not targetRange?
FR: There isn't one on delete, only on replace.
… otherwise there is overlap between delete and replace.
RN: Don't think that is an issue.
… we can spec them around this.
FR: Yes, but that is harder to make happen.
RN: All commands should always work on target range.
EC: So what happens in ce=typing when user types "hello". I select "lo", press delete. What events come out?
RN: targetrange are those characters, will delete backward.
EC: and user presses "delete word"? Webkit changes selection to select word, deletes.
RN: Same. select the content, delete backward with targetrange as what was selected.
[chaals leaves]
<MikeSmith> is the meeting still going on?
<MikeSmith> is somebody else taking notes elsewhere? (etherpad or something)
<tantek> MikeSmith - meeting is over
<MikeSmith> tantek: ah ok
<MikeSmith> thanks
<tantek> notes were all in IRC - no separate etherpad AFAIK
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/71 and 72/72 and 73/ Succeeded: s/beforeinput/input/ Succeeded: s/Ilya/Grisha/G Found Scribe: Florian Inferring ScribeNick: Florian Found Scribe: chaals Inferring ScribeNick: chaals Scribes: Florian, chaals ScribeNicks: Florian, chaals Present: Ryosuke SamW Enrica SimonS Grisha Piotr Florian Johannes Johan tantek chaals Ehsan(videconf) Chaals Tantek Agenda: https://www.w3.org/wiki/Fall_2015_Editing_Taskforce_F2F_meeting Found Date: 24 Aug 2015 Guessing minutes URL: http://www.w3.org/2015/08/24-webapps-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]