See also: IRC log
<garykac> I'm taking notes at https://docs.google.com/document/d/1XxIEF0So-kMF5mcJ03Yj0zsYMFRHEgXw1fV1K5FOwuQ/edit#
<garykac> Everyone should have write access to the doc
- What should the order of the events be and in what spec should this be placed?
GK: We have these in UI Events. Where should they go? Don't mind.
JW: Don't want it in UI Events?
GK: Don't think it makes sense - should be in a "downstream" version - but don't feel strongly.
OV: What if the ordering impacts the UI Events
GK: Should be stated in drag and drop how they impact.
OV: e.g. dropevent fires before beforeinput. So does paste. So which of those two fires first. Does it matter?
GK: If we don't get interop will it cause a problem?
OV: Yes.
MS: Is there an event orchestration spec?
GK: Might make sense to have one
for adding new things to.
... would be a list, basically
OV: Makes more sense for me to put these into UI Events
GK: Don't mind, but it makes UI Events never end.
OV: People propose a diff to the spec, when it gets implemented we merge it into the spec.
CMN: Need to write something down that tracks the overall order.
GK: Would rather that be event order alone…
RESOLUTION: GaryKac will maintain a spec for event order…
GK: How many drag and drop events?
OV: They should happen at the same time as copy/paste
JW: @@ missed
OV/Enrica: the dragging uses the copy/paste transport but doesn't interact.
JW: in dragging you can add to or change the data that moves, in editing you just want the html being dragged, mostly.
Enrica: you might want to manipulate - represent image differently…
OV: Ordering meets all these. Order that makes sense to me.. UI Events has keydown, beforeinput… drag events to me seem to fit in the same stage as keydown.
GK: Keypress is like beforeInput - cancelable
MS: Does canceling dragstart stop
the subsequent parts of the drag?
... this is particularly key with key events
JW: If you cancel beforeinput for drag I would expect the whole process to stop.
GK: Drag events don't update DOM,
so should not generate input so not beforeInput
... if I am modfing the DOM I don't need to fire an event.
OV: There are cases where drop and dragend modify content.
GK: When they implicitly do
that…
... dragend not cancelable, drop is.
DT: Expect beforeInput to be
after drop.
... are drop/dragend mutually exclusive?
GK: Is drop before DOM update?
DT: before
... if you clone, do you get a drop, a dragend as well?
MS: What's dragend for?
Enrica: Occurs no matter what - whether you successfully drop, or just decide to stop dragging.
DT: dragend is targeted at the source, drop at the target.
JW: If we only have a drop?
GK: nothing else implicitly updates the DOM
MS: What about dragover updating the DOM?
GK: Don't know of any implicit actions that would make that happen, it's only your own code.
JW: How do we specify where a drag comes from and goes to if we only have a drop?
GK: Beforeinpur, with this drop,
should have the currentSelection and needs the target
loction.
... does it have data telling you what will be changed?
JW: It tells you what will be injected, and you can take over doing that.
GK: Trying to think of analogy with cut/paste.
beforeInput you get one for the cut, and another for the paste.
MS: Drop triggers the paste...
OV: drag events don't modify anything, the drop is the only thing that modifies. drag* isn't modifying the DOM.
DT: On dragend you *might* get an operation, if it is a move…
JW: So when you drop you get a dragend and a drop. That gives you where it comes from and where it goes to.
GK: Which implies two
beforeinputs, for the two pieces.
... what is the selection range for drop - source or
target?
Enrica: Target
GK: So you get beforeinput, drop, beforeinput input.
OV: This is decided for us in implementation we just need to figure out what it is…
MS: Can the selection change during a drag?
GK: That's scary.
... it's why beforeinput uses static range.
MS: Select a word, click, drag, and somehow it changes in the interim. You expect a static range on drop of the selection when you began dragging.
GK: If it has been modified between then you get a mess.
DT: It has a live range behind it, so you get an adjusted static range when you ask.
OV: Seems like we need to do some more digging. I can't get dragging to fire in contentEditable in Chrome
JW: images can drag by default. everything else needs draggable attribute
OV: Drop happens before the input.
GK: We only get one input
OV: Only one drop.
GK: But there is a remove from one part, and input in the other.
JW: If not dragend, we need a beforeinput that gives us where it comes from
GK: Would like to have one pair of before+input, but it can't carry two ranges.
<ojan> hQKIIrVAoRIr9joAPs1otSittvJ9xBB1u9bTt6vkzoC/Kt/s9pteEUeGKdylhCJCkIuKvNDx1+wGVwduzGHzmeJ+gvD4xocAZeAA=
<ojan> http://jsbin.com/cezivejuyi/edit?html,js,console,output
<chaals1> MS: If you do 2 input events you may have to share logic between the two, which isn't desirable
<chaals1> CMN: But they are separated
<chaals1> MS: Knowing what they are might be useful
<ojan> above jsbin is broken here's the fixed oen http://jsbin.com/latatovotu/1/edit?html,js,console,output
<chaals1> GK: If you really care you can listen to drop…
<chaals1> … someone who listens to beforeinput but not drag would be OK.
<chaals1> MS: If you drag, then drop into the container if X is true of container and Y is true of being dragged
<chaals1> GK: If you care about that you're listening to DND events and you have all the info.
<chaals1> MS: You have to store the dragstart info and correlate
<chaals1> GK: Yes, you do now.
<chaals1> JW: When you get dragend you add data to datatransfer and then only handle the drop when you get that extra information.
<chaals1> MS: We're not trying to improve drag and drop, just figure out how it works already.
<chaals1> MS: beforeInput only ever has one range, so if you need two you need two events.
<chaals1> GK: And that's what the spec says...
<chaals1> OV: And not what browsers do.
<chaals1> … testcase shows order of events, logs innerHTML
<chaals1> in FF/safari/chrome te same thing happens which isn't according to spec, for dragging an image
<chaals1> GK: So you get drop, DOMupdate, input
<chaals1> … spec says if you drag text, it does a cut during text.
<chaals1> JW: if you make an element draggable does it make text inside it draggable?
<chaals1> OV: We need some more testing here.
<chaals1> … looks like the ordering is interoperable and spec is wrong.
<chaals1> CZ: If there is a different element we will have input for both.
<chaals1> MS: beforeinput on source or target?
<chaals1> OV: Seems like we could have drop event, beforeinput, input, dragend
<chaals1> … dragstart should go long before.
<chaals1> JW: So should dragend generate another beforeinput?
<chaals1> OV: We need tests to find out
RESOLUTION: check what really happens, and update HTML specs to match.
<garykac> Doc with notes: https://docs.google.com/document/d/1XxIEF0So-kMF5mcJ03Yj0zsYMFRHEgXw1fV1K5FOwuQ/edit#
<ojan> test case again: http://jsbin.com/latatovotu/1/edit?html,js,console,output
GK: We don't want to repeat the readyStateChange problem with beforeInput having lots of switch stuff to figure out what it does
GL: I feel the same way. We fire beforeCopy etc
GK: They were removed
... because they were not that clear
JW: beforeCopy etc fired when you tried to get the context menu up, and you need to know whether to enable or disable copy etc.
GK: so if you have native UX for
e.g. bold, these events were related to whether a control
supported the function and wanted it enabled.
... backing up to give some history
... Keypress was deprecated to be replaced by
beforeinput.
... as the only thing you listen to for DOM updates. So you
didn't care whether the changes came from keyboard, handwriting
input, speech reco, etc.
... as opposed to atomic events for every possible thing
... the choice helped for accessibility, because you won't miss
a specific action like key
OV: We already have input.
... makes less sense for beforeinput and input to have
mismatch
GK: Design is we have input, and
beforeinput as catchall for any update to the DOM, instead of
specific events trapping the user's action (not intent).
... a hybrid in the middle seems a bad idea.
... But don;t think this is a generic thing like readyState.
Although people may say it is.
OV: hear Anne's point, and adding the inputtype has some risk of doing what Anne was worried about - having written an editor, I *want* to do what Anne doesn't want me to do - for me it is a feature not a bug.
DT: For adding event listeners you can have options - would we specify a filter? Before you add a listener, you filter the things and e.g. only listen for paste, instead of dealing with switch statements.
GK: What if you want to listen for 12 out of 20?
DT: this is where you want to e.g. listen for "enter", not all keys
MS: If you listen with a filter, does the event still fire more generally?
DT: Yes.
... we have a lot of performance hit because we're listening
for the enter key and running a lot of JS to figure it
out.
... note this is an idea, not a plan.
OV: Are you concerned about beforeinput in general, or specifically on clipboard
GL: Specifically on
clipboard.
... beforeInput seems to want to do everything, beforeInput
should be user-initiated, but cut/copy/paste might or might not
be
GK: We could restrict beforeInput to only user-initiated DOM updates. Would be tricky spec…
OV: Same issue applies to input
right?
... but it seems *really* strange for beforeinput and input not
to match.
GK: We try to make beforeinput cancelable
[except IME]
GL: I thought you can listen to the beforeCopy event
OV: That's a different beast. If
you preventDefault, it prevents the copy item appearing in the
right-click menu.
... happens when you pop up a right-click menu.
... and it's terrible.
GK: And it's gone from the spec
JW: Was only implemented in one browser, no?
[testing...]
<garykac> Issue where they were removed from the clipboard api spec: https://github.com/w3c/clipboard-apis/issues/25
<johanneswilm> Here is Hallvord asking to kill beforecopy https://readable-email.org/list/public-webapps/topic/clipboard-kill-onbefore-events
GL: If people generally want to have beforeInput instead of beforeCopy, we can go with that.
JW: It is paste that is similar to beforeInput - beforePaste is a different thing relevant to the menus and so on.
GK: Yes, paste is analagous to
beforeInput - before DOM is updated, and cancelable.
... does paste always trigger input?
OV: modulo bugs, yes.
GK: Don't think we can get rid of
paste, since it's been around, but we would like to replace it
with beforeInput.
... if we could get rid of paste and cut, what happens to
copy?
... leaving the three around is consistent in that regard.
GL: So if we go with this do we discourage web developers from listening to paste?
GK: i.e. we're deprecating
them.
... we cannot do that for copy. So think we should keep paste
and cut.
JW: Tried to get the two specs
together last year. CLipboard said the browser must paste -
cannot stop it. I.e. not cancelable.
... but we were trying to do it the other way around. So
clipboard tried to make exception for contentEditable=true, not
cE=[other values]
GK: So order would have to be beforeInput, cut/paste, input. Copy doesn't have before/input
JW: What if you cancel beforeCut?
Does it not copy at all?
... I cannot cancel a copy to the cipboard - does canceling a
cut send something to the clipboard?
GK: If you cancel beforeInput inputtype=cut then it should cancel the cutting operation?
JW: Trying to find correspondence between copy and cut…
GK: canceling beforeInput could
just stop the impact on the DOM, and canceling cut stops the
whole lt. But I want those two things to be consistent.
... if you consider clipboard buffer as part of the DOM, then
you can claim some consistency.
[So, what's more surprising: incosistency between beforeinput.inputtype-cut and cut, or cut and copy?]
MS: Cancel is generally understood as a "binary operation", but in this case there are 4 possible outcomes of it, so figuring out which of those is the "obvious and useful" one is hard.
JW: When cut happens you make
your own copy not on clipboard, but you also want to see that
in the clipboard. Then we don't know where the paste goes -
what if it goes off to a different app?
... so in your own app you use your private clipboard, but you
put the other stuff into the clipboard so it can be used
outside the app.
GL: Think user would be surprised if the stuff they cut isn't removed but still gets into the clipboard.
JW: If the user cuts something you want that into their clipboard, but you are going to handle it if it is all use within your app.
CMN: what Grisha says. Everywhere else, a failed cut doesn't affect clipboard, so we shouldn't introduce anomalous behaviour. Canceled cut should not copy to the clipboard, either in beforeInput or in cut.
JW: Want to make sure we can do this, because there is user-initiated requirements.
MS: So why do we have beforeinput *and* cut?
GK: Because we cannot get away
with removing cut/copy/paste from the web :(
... and so someone can handle beforeinput and always manage to
get the events they need.
RESOLUTION: cut and beforeinput with inputtype=cut are cancelable, canceling stops anything going to the clipboard, paste the same, there is no beforeInput for copy, and this is for anything that is not contenteditable=false
OV: input fires in editable regions, but key events fire wherever things can be focused.
GL: If we fire input, we fire beforeinput…
OV: Yeah. at some point we might
want to relax that, but will require author opt-in
... who implements undo API?
GL: We do in Edge.
OV: Thought we did, but apparently not
EC: nor webkit
OV: Like cut copy paste: input
already fires, our hands are tied.
... should the browser try to work out what changes were made?
Think the answer is no.
GL: People who want undo will track their own, rather than go for literally everything.
OV: Wait, misunderstood. If JS modifies the DOM should it go into the history?
GL: What's the use case?
JW: Your editor handles a bunch of stuff, but you pass undo/redo to the browser to handle.
GL: So if you have a browser stack and your own, you want to make sure they don't get interleaved wrong.
JW: Is it possible to let the browser handle undo/redo?
GK: sounds analogous to cut/copy/paste
OV: We wrote a spec to do this,
but don't see anyone implementing it.
... browsers are not interoperable here anyway last I
looked.
JW: So if I am going to start handling undo I need to handle the lot, right now.
OV: Yes. It would be great to have a standard for that, but won't be now, and is orthogonal to beforeInput.
JW: So beforeinput doesn't have targetrange for undo/redo
GK: Yes, because the info is coming from somewhere else. If you call it, I don't think it is helpful info.
MS: So what does beforeinput have?
GK: fires before the change, has type, don't think there is any other info.
MS: We just want something we can cancel, and handle it ourself.
RESOLUTION: currently, you can rely on the browser totally, you can do your own thing and take care of it all, but trying to have a mix of the two is likely to have bad outcomes.
GK: is undo/redo cancelable?
OV: Should be.
GL: Don't think we fire undo event.
GK: So if nobody implemented it,
let's not add the event.
... you can find when undo happened because of undo/redo
already, you always get an input.
GL: if we preventDefault an undo, what happens to the undo stack?
CMN: Think it makes sense that if you preventDefault on an undo action the stack should be popped.
[most people: no, that makes no sense]
EC: You should delete the stack
GK: that saves memory. But in the future it means we cannot make an undo manager.
RESOLUTION: We don't want undo/redo events
outside beforeInput
... preventDefault on an undo means "don't apply this, no
change to the DOM, no change to the undo stack"
<rniwa> chaals: /me hi's chaals!
JW: This is about moving stuff from input events to UI.
GK: We need input events never cancelable, or sometiimes, e.g. in IME, it might not work.
JW: for simplicity we said it is
never cancelable.
... problem is we write editors for latin that don't work with
composition. We want to make that easier.
GK: We have to make an exception for composition, and we should pick the easiest way to make it happen
OV: On the down side, that means in Android nothing is ever cancelable. Other than that, it would be great.
GK: The reality is "it is possibly not cancelable".
OV: If the isComposing flag is true, then Input is possibly not cancelable
GK: And that is in UIEvents
[We would like to make the two specs say the same thing…]
OV: Android may not make it
cancelable at all.
... use case is where you write your own editor you want to
control everything.
JW: e.g. collaborative
OV: pragmatic thing is to say If composing is true it's not cancelable - for now…
CZ: The very last thing can be
cancelable.
... you are finished, the browser is inserting text.
... e.g. I have editor, don't want user to edit text. Using IME
makes it uncancelable, but when the user tries to insert text I
cancel that
JW: So I let you use the IME, handle the composition, and then when you hand it to me I can decide what to do.
<Grisha> resehttps://cdn.rawgit.com/w3c/uievents/gh-pages/tools/key-event-viewer.html
-> https://cdn.rawgit.com/w3c/uievents/gh-pages/tools/key-event-viewer.html keyboard event viewer
OV: if you type into an IME, and the preventDefault, should the stuff I typed remain?
GK: No, it's temporary stuff for the IME.
DT: So I presume the line would stay there…
OV: Staying in IME composition?
DT: The line indicating you're in IME would be there
「pぁいんg」アロウンdウィthイメ
OV: if you preventDefault while in composition, at the end of it when you can, you remove all the artefacts of what was being done in composition…
GL: We update DOM before
composition
... now we fire compositionUpdate, and the DOM is not updated
yet.
GK: We agreed where we would put beforeInput
GL: We were different, agreed we would change to match everyone else
OV: And we had a bug, as
well.
... didn't have a final compositionUpdate before
compositionEnd.
... compositionStart / End don't do updates, only
compositionUpdate which have beforeInput, and at the end there
is compUpdate, befInput, input, compEnd.
... so the last beforeInput in that stream, if prevented, will
undo the whole composition back to the compositionStart
JW: If you can cancel it, then by definition you're at the end.
GL: When is isComposing flag set?
OV: In each of these cases.
GK: How do I know if we are catching the last thing?
JW: Spec says you have to delete everything and add it again. And Chrome does.
CZ: Doesn't have to be the latest text, could be the english text.
GK: But for japanese that's irrelevant if you're in kana already.
OV: Consistency across here is good.
GK: So in japanese we delete then reinsert as a way to know that we're at the end of the composition.
[testing]
GK: We could optimise away the replacement in some IMEs
OV: The majority of people writing editors don't understand any IMEs. So you're better not having inconsistency, or they break stuff
GK: So we have to have a redundant event, for Japanese.
MS: Why no different type?
GK: We never had a type, in the past. We could say "type=finalComposition" - which sounds nicer
JW: That sounds saner.
OV: This might be good enough to
spec it like this and be happy with it.
... so if isComposing is true, and type !=
finalCompositionStateThingPlaceShedForCycles, then it isn't
cancelable. Then we get something that will work for
developers.
[break coming fast]
[question about why to have inComposition, and how to stop developers from breaking things by accident]
GK: Is beforeInput cancelable or
not? Yes, except when isComposing is true… except that the last
beforeInput sent, just before the endComposition, and that will
have a special type.
... and if canceled DOM goes back to how it was before
startComposition...
OV: Does that work for Android? You can start composition on existing text.
RESOLUTION: beforeInput is cancelable except when isComposing is true… except that the last beforeInput sent, just before the endComposition, and that will have a special type. Note this is subject to matching Android reality…
[so there is spec update to be done, and testing on Android]
GK: proposal is consistent with what RNiwa said…
rniwa: ^^
EC: We were in favour of static ranges. Otherwise we are all fine.
JW: What's the plan for where it lives
GK: Range is a separate spec. static range is probably going to be another thing on its own.
OV: there isn't a spec yet,
right?
... maybe we should have one before we ship.
ASIDE: what happens if you undo/redo within composition… [needs testing]
GK: So we take static ranges through the process, I'll edit it.
OV: data property should give same content as datatransfer.getdata text/plain
JW: OK, no problem.
OV: Do all beforeInputs have transferData?
JW: not now but we can make that so.
OV: or we can make them have only one.
GL: undo doesn't have anything
JW: Now only clipboard and DND
have this - the only one with data is insertText. I can expand
it…
... bold, italic, etc has a targetRange but no data or
transferData
OV: insertNonText ?
JW: Was replaceContent, and people agreed to change it
OV: nonText is weird. Something
like insertComplicatedStuff, or HTML, or whatever. This is
bikeshedding, but I don't like the current colour.
... do we really need it at all yet?
JW: a spellcheck that replaces stuff running across element boundaries, not from a user typing.
CMN: Maybe a live translation system.
MS: I see value between a user input event and something done by another system like spellcheck.
GK: So to return to the data / transferData issue - do we have both? Is there transferData everywhere that is nice for consistency?
OV: What about bold… there are nonsensical place to have it.
DT: transferData seems heavyweight for things that don't need it.
OV: DnD and CCP (cut copy paste) need it. Also insertRichStuff would.
JW: Seems odd that there are data sometimes and transferData others.
OV: We could put both onto DnD, CCP, and insertRichStuff and insertText, with data as a shortcut.
GL: The redundancy bugs me a bit
OV: me too.
GL: how often will it be used?
OV: Depends on the command…
... if they are doing transferData on insertText, that's stupid
expensive.
... propose: insertText has data, DnD and CCP get
transferData.
DT: We have a table in the spec to show which ones are valid?
JW: Yep.
GK: so insertText has transferData = null.
OV: We need to be sure its transferData or dataTransfer...
[scribe agrees]
[It is dataTransfer]
JW: There is a different name for it in clipboard API
GL: So for CCP and DnD, data will be null.
<dtapuska> For the notes if the spec could have a table that looks similar to this: https://w3c.github.io/pointerevents/#pointer-event-types
RESOLUTION: CCP and DnD have dataTransfer an data=null, insertText is vice versa.
GK: There is no good technical answer here :(
DT: This applies to virtual keyboard, whether there is a bold option, etc.
GL: developers want to turn on or off things that they don't do, or give context to the UA asking for numeric keyboard, or I'm editing plaintext and there is no need for bold etc.
OV: You can use inputmode with the input event, but otherwise no…
EC: iOS does this driven by input type.
DT: Same class of problem.
JW: Especially problematic that menus pop up we cannot remove, but try to do things the user cannot use.
GK: New feature is released - what does current code do - are they opted in or do they update their code to get the feature?
OV: Don't think we should support arbitrary commands. Does it make a difference to support bold+italic but not underline, vs have rich formatting or not?
MS: People want to lock down some options, and don't want a context menu to bypass that and offer other stuff.
GL: What if we have a binary - you can disable formatting buttons.
OV: High priority is which virtual keyboard - that's what people want.
EC: Would be the same for the entire element - you won't switch keyboard as you move around the block.
JW: You also get the menu showing up that you didn't want. It covers stuff and users can't get to things they want.
MS: You can't just disable the context menu to stop bold appearing because you want e.g. copy
EC: Ideally you have a set of
commands and let the application choose which ones are
available.
... This isn't the same as the keyboard problem.
CMN: Can we use inputmode?
OV: Not sure it matches well - although nobody ships inputmode any more so maybe we can er-use it. Or call it keyboardType - someone needs to make a list of the types that we want.
DT: You might want e.g. autocapitalise. On Android you roll these into flags for the keyboard.
CMN: the problem is this is a big list that is very context-specific so you get whatever a few developers understood and missed out on various others.
DT: iOS has ascii, phonepad, email, twitter, phone number, etc...
OV: Let's take the intersection of iOS+Android, and then add things if people convince us
CMN: We can replace inputmode as specced - and unimplemented - with this. It's a simple list of labels and keys that should be there.
OV: Sure, unless that upsets people and we can change the name.
JW: From editors I heard that
people wanted to get rid of the menu, but Ryosuke proposed a
way to get rid of the commands.
... on a more fine-grained basis. Is it possible to have a
command to disableAll, and enable(individual) menu
components?
GK: So by default you opt in to new features, although you can opt out of everything and choose everything you want.
OV: Apple are the only ones who
do this now, so they should make a proposal and everyone else
will say "sure"...
... think we should wait for Apple's proposal
... having opt-out all and then opt back in, is super
painful.
GK: There isn't an obviously
right answer.
... Does that block anything or is it orthogonal and not
holding anything. I think and hope so.
JW: editing software developers want this, but no it doesn't interfere with standards work - only reality.
RESOLUTION: We're waiting for Apple's proposal
to discuss at TPAC regarding opt in/out of
commands.
... We will spec up the list of inputmode (or whatever we call
it) for selecting keyboards.
-> https://w3c.github.io/html/sec-forms.html#input-modalities-the-inputmode-attribute in W3C HTML
GK: OMGNo!
JW: Made a proposal about reasonable execCommand things - but not all of them are there. If things are missing, please speak up.
GK: seems like a small number should come over.
GL: Think it is close to 37 things.
GK: Think most don't have corresponding beforeinputtypes.
<garykac> https://github.com/w3c/editing/issues/110
OV: All we need command types for
are things built in to the user agents that the user can
trigger
... Think a bunch of the ones included might not be
implemented. The point is not to come up with a whole new set
of names - use the same names.
GK: And spec should not require implementing them all to conform.
OV: LGTM.
JW: You hold down a key, and then
you get a menu for accented characters. If we cancel on
keydown, that breaks.
... if we preventDefault on getting the 'e' we don't get the
menu.
DT: if you do the preventDefault on beforeInput instead of on keyDown, the problem goes away...
RESOLUTION: Use preventDefault on beforeInput instead, and magically the world will be better. For now.
DT: Lets you adjust the text of
the enter key on virtual keyboard.
... iOS has some predefined ones, with this you can set
values.
... want to make this work on Android.
... specified on the input field - will have to specify
something similar for HTML, so it effects cE
GK: We got a lot of input from Android because we could find documentation. Think the key values we have work everywhere but couldn't find them for iOS, so if you can help us find them…
EC: I'll dig it out.
RESOLUTION: make it so (sort out mozActionHint)
OV: static range needs a spec first.
JW: contentEditable modes isn't
sleeping but maybe should be moved forward.
... input events too.
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/need/can add to or change/ Succeeded: s/G:/GK:/ Succeeded: s/Hee/Here/ Succeeded: s/precv/prev/ Succeeded: s/GK/OV/ Succeeded: s/dataTransfer/transferData/ Succeeded: s/dataTransfer/transferData/ Succeeded: s/79/110/ No ScribeNick specified. Guessing ScribeNick: chaals Inferring Scribes: chaals Present: GaryKac Johannes Morgan Grisha Enrica Dave Chong Ojan Léonie Chaals esprehn WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 29 Jul 2016 Guessing minutes URL: http://www.w3.org/2016/07/29-editing-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]