SV_MEETING_TITLE -- 04 Jun 2013

Hi gary!

<garykac> Hallo!

<kochi_> hi

<garykac> We'll be dialing in in a sec.

<scribe> scribe: travil

<scribe> scribe: Travis

<scribe> scribeNick: Travis

agenda

http://www.w3.org/2008/webapps/wiki/DOM3Events

New repository for editor's drafts (CVS->Hg)

<garykac> So.. starting from the top...

<garykac> We are using the new repository

<garykac> It's a bit flaky at times

<garykac> It often fails to authenticate

<garykac> But the it starts working again a few hours later

<garykac> I'

<garykac> I've converted the spec to use respec everywhere

<garykac> Which means that it's autonumbered now

Link to new ReSpec edition: https://dvcs.w3.org/hg/dom3events/raw-file/6cc9e60bf4b1/html/DOM3-Events.html

<garykac> and we use respec formatting for the IDL

<garykac> this organizes the content a little bit more nicely

<garykac> especially with the IDL stuff

<garykac> previously the IDL definitions were spread in multiple sections, now we only have to define it in one place

<garykac> I also added a key table generator. the content of the table is now generated via javascript

Looks great--I don't notice any significant changes... :0)

garykac: need to make the spec look like an editor's draft, instead of a working draft.

<garykac> All the changes have been merged into the top-of-tree to make a new baseline

Summary/overview of recent updates (formatting/typos)

garykac: Fixed a couple of typos...

<garykac> And a couple of grammar issues and capitalization

Overview of proposed changes (adding section on 'input' and 'beforeinput')

<garykac> There are a bunch of places in the spec that refer to 'input' events replace 'keypress'

<garykac> But 'input' is not properly defined in any spec

<garykac> On the ML, someone said that they expected it to be in this spec.

<garykac> Which was a great surprise to those of us working on this spec

<garykac> however, it makes some sense to include it here if we're going to going to rely on it to replace 'keypress'

<real_wez> I'm not convinced that input/beforeinput is the right way to solve this

<real_wez> They are geared toward notifying of changes to the contents of input elements, IIUC

<real_wez> Fundamentally they are not tied to text input

<garykac> I think we need to make sure the spec includes a suitable replacement for 'keypress'

<real_wez> I think we're agreed we want a replacement for keypress

<real_wez> The old textInput spec seems a better fit for that than input

<kochi_> FYI I'm seeing old textInput spec at http://www.w3.org/TR/2011/WD-DOM-Level-3-Events-20110531/#events-textevents

<real_wez> What do input and beforeinput contain if the element isn't a text input element, for example?

<real_wez> Gary points out that input and beforeinput may only have been intended to apply to text editing fields, originally

<real_wez> One point arguing against textInput has been that e.g. speech recognition should be distinguishable from keyboard text input

I think that beforeinput was indended to be for editing, yes.

The input event is basically a change notification for input/textarea elements.

The only context it conveys is the 'target' , where to check for the updated text.

<real_wez> If input/beforeinput are text-element-specific then I'd be more comfortable with using beforeinput to convey newly-entered characters

The textInput carried all the data from the KeyboardEvent.

<real_wez> However, there's the question of how non-text-input elements would receive character data if entered, e.g. <div>

The element has to be focusable... right?

<real_wez> If you create a <div> and add event listeners for "keydown" etc then can yoiu also get "beforeinput" so as to see the character input?

<garykac> It sounded like input/beforeinput were intended for editing, so I'm not sure if a <div> would receive them

input/beforeinput make sense when actual text gets added--but not for generic elements...

<real_wez> Gary suggests starting a thread on the broader mailing list around the rationale for preferring input/beforeinput vs textInput

<garykac> ...and bring up these issues

Is there any reason why we wouldn't consider back 'keypress'?

<real_wez> Historically it was under-specified

garykac: We could specify it...

<real_wez> Plus, we may receive multiple characters for a single keypress, which the existing keypress w/ char field doesn't really fit

<real_wez> i.e. if we use it to convey entered text, it doesn't then match an individual keypress, so it's mis-named

<real_wez> Plus, if we have e.g. textInput then that can in principle be generated by other input than keyboard, e.g. speech recognizers

<real_wez> Without confusing folks by the name

<garykac> There's a lot of exising documentation on the web that describes how to use 'keypress' and it covers the old/broken version. So there might be confusion if we redefine it.

<real_wez> True

So, textInput means that input is being sent--not necessarily that input is being recieved.

<real_wez> But then how prevalent are the "broken" implementations - are the various browsers at least consistent?

<real_wez> travis: More that text input has been generated, somehow, not necessarily via keyboard input

<real_wez> e.g. you might get text input by an on-screen keyboard, or from speech recognition, OCR, etc

<real_wez> Gary says that keypress implementations are not consistent wrt ordering of events, etc - we'd have to break existing impls to define something consistent

<real_wez> That seems bad to me!

<kochi_> allowing non-edit element to get textInput event fits the model that IME API assumes

<real_wez> You mean that non-<input> elements can receive entered text?

<garykac> If we define 'keypress' now, we'll end up breaking at least one current implementation and there are certainly webapps that depend on current browser behavior

<kochi_> real_wez: yes

<real_wez> Gary also mentions that looking for the "input" event in docs is a pain because the name is so generic!

<real_wez> (I think that's also true for the name "UI Events")

<real_wez> ;)

Got to search with "named input" :-)

<real_wez> Can we change the spec to "DOM4 UI Events" or "D4E UI Events" or something more helpful?

So, do we have an opinion on adding 'input'/'beforeinput' vs.bringing textinput back?

real_wez: I think it would be great to have both input/beforeinput in the spec as well as textinput...

<real_wez> My preference would be to add specification of beforeinput and input to D3E, independent of the input vs textInput question

<real_wez> Yay

<real_wez> I am double-scribed

garykac: I'm worried about the delay that will cause to the spec.

<garykac> I would rather punt to D4UIEvents unless we need to include it in DOM3 in order to cover a replacement on 'keypress'

Reviving 'textinput' event?

<real_wez> Questions is about the use-cases for the "locale" field

<real_wez> *question

<real_wez> Locale was invented for use w/ textInput so that the source of textInput is clear

<kochi_> the original intention of local was to add context for textinput event

<real_wez> Locale field was then propagated to keydown, keyup, composition*, etc

<real_wez> The intent with 'locale" was to support language-specific spell-check, word suggestions, etc, if I understand correctly?

<garykac> Locale is a BDP-47 string

<garykac> Do the IME events specify a subset of these strings? or can any BCP-47 string be present and useful?

<garykac> It seems like a lot of the BCP-47 strings are too general

<garykac> kochi sez: locale is useful as a hint

kochi_: I see this as a hint to applications, it's not specific like en-us, but is still useful.
... For example: spellchecking would see that it's not russian, but english...

<real_wez> Have any browsers implemented 'locale' yet?

IE9 has implemented.

kochi_: Masayuki implemented in Firefox

<kochi_> FF has implementation for Win/Mac

<kochi_> smart quotes (") is a use case for keypress locale

<real_wez> kochi_: So would having 'locale' on textInput not work for that use-case? Would that be too late to see the locale?

<kochi_> real_wez: should be same for keypress and textInput

<real_wez> kochi_: Are we allowing re-writing of events, e.g. textInput w/ '"' becomes textInput with '>>" in French?>

<real_wez> kochi_: keypress is deprecated; do you mean keydown?

<kochi_> usually modern custom editors listen events in hidden field and can insert different character for rendering text

<kochi_> so users won't see raw (") character typed

<real_wez> kochi_: Could custom editors listen for textInput, detect the locale, and adjust the characters entered, then?

<kochi_> real_wez: i think so.

<Travis_> I think there's a bit more detail that should be considered...

<real_wez> kochi_: So we don't need 'locale' on keydown/keyup?

<kochi_> real_wez: might be, if textInput is implemented.

<real_wez> kochi_: :D

<garykac> Question to answer: is the current spec (BCP-47) good enough? It sounds like it is for IME events, but it might not be for keydown/keyup events.

<Travis_> I wonder if it's sufficient to have it only in the CompositionEvents + IME API.

<kochi_> Travis_: if system doesn't have IME at all, no composition events but some apps may want to know whether the locale is French or English, for example

<Travis_> We have to agree (and get the working group to agree) that BCP-47 is good enough. Might be worth a shot.

<real_wez> Gary suggests that for the current use-cases, BCP-47 is overkill - not necessarily a reason to change it, but worth bearing in mind

<Travis_> So, when we go into Last Call for CR, we can mark locale "at risk" meaning we can rip it out without going back to working draft if necessary.

<real_wez> Based on the current use-cases revolving around language-matching

<garykac> The current spec says that locale is defined as BCP-47, so we should be good there.

Use cases for locale attribute

Discuss spacebar

<real_wez> Gary raises Masayuki's point about the Spacebar key value; he agrees that 'Spacebar' is a bad name, and more suitable for D4E's 'code' value for that key

<garykac> There are a lot of X11 keysyms that seem to have been imported from an old font (not keyboard).

<garykac> Wez recalls that these were related to an old (obsolete) DEC keyboard related to publishing

<garykac> I don't think we should worry about NBSP, halfwidth space, et al. unless we can find a modern keyboard layout that generated these keys.

<Travis_> What is the specific action for D3E?

<garykac> Also, the SPACE and the Keypad_SPACE should both generate the same 'key' value (just like the '2' and the Keypad-'2' generate the same value - just with a different location)

<garykac> For D3E, we need to update the definition for 'key' when the spacebar is pressed

<Travis_> When implementing the key values for various control characters, the question of what to report was raised, as it's somewhat ambiguous

<real_wez> Fundamentally the keysyms Masayuki raised are of two kinds: Space and KP_Space have the same semantic meaning, but are on different physical keys - they can generate the same 'key' and then be distinguished by location. The remaining "space" KeySyms have different meanings to the normal space character, so aren't appropriate for including in 'key'

<Travis_> So, it might be worth giving some of those control codes names (if they don't already in the spec).

<garykac> Yes, names for the control codes makes sense (even though I'm not sure how to type them)

<Travis_> Next meeting in 2 weeks (June 18)

<Travis_> Same time.

<real_wez> ASCII has the "printable" characters starting from character 0x20 (32) (Space) - the preceding characters are "control" characters. I think it would make sense to use that distinction here, and so have ASCII Printable characters always use the character for the 'key' value, and generate the corresponding character input

<real_wez> And have non-"ASCII-printable" characters use named 'key' values, e.g. 'Tab', 'Delete', etc

- DRAFT -

SV_MEETING_TITLE

04 Jun 2013

Attendees

Contents