[DOM3Events/UIEvents] Minutes from 27 Jan 2015 teleconference

Minutes logged at: http://www.w3.org/2015/01/28-webapps-minutes.html

Previous minutes: https://www.w3.org/2008/webapps/wiki/Bi-weekly_meetings


<masayuki> Travis: Hi

<masayuki> garykac: Hi,

<garykac> masayuki: Hello

<garykac> Travis is having trouble with IRC. He's working on a fix right now.

<masayuki> Oh, I see.

We have a few things to follow up on from last meeting.

Spec name change is one

3 bugs from Masayuki blocking Gecko progress

Removal of beforeinput and friends from the spec

<garykac> And renaming and moving the spec.

<garykac> Oops! I see that was already mentioned

Spec name change

garykac: Not done yet.
... will do next.
... hesitated since there are redirects to old one, etc.
... renaming and moving to new URL?
... can't remember the details.
... Are we going to move it to D4E?
... [and other questions]

So, latest TR published is here: http://www.w3.org/TR/DOM-Level-3-Events/


So, the shortname is "DOM-Level-3-Events"

Editor's draft is here:  https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html


So, under HG's "dom3events" folder.

<garykac> Basically, we need to agree on the exact order that we do things in.

One thing we should do is re-publish the current spec with a re-direct to it's new home

So, unordered list first :)

* Modifiy Editor's draft to change name

* Copy editor's draft new location

<garykac> * Decide where the editor's draft should live: the current D3E, current UIE, or a new place

* Change current published doc's "editor's draft" link to point to new location.

* Publish new draft in TR with new name and valid links

* Update bug database component name?

<garykac> I'm going to dig up the email where this was last discussed to remind myself what it says...

<garykac> Philip suggested publishing an updated version (new name) and having *both* shortnames point to it.

OK, well, first step is probably "modify editor's draft" so that we can do that :-)

As for location, where do we put the editor's draft?

<garykac> We need to make sure that both ED links point to the correct editor's draft

<garykac> I think it makes sense to keep using the dom3events location

I don't mind the mercurial path staying D3E (vesus a new location or D4E)

<garykac> OK. so that means that we rename dom3events in-place

So, scrap the "Copy editor's draft to new location"

garykac: New shortname?
... nope, it'll be UIEvents

Do you want to change the name of the file in mercurial?

<garykac> I don't think it's necessary, but we can do that later if we need to.

garykac: I would avoid doing that now--we can always do it later.

beforeinput removal

<garykac> Next topic

<garykac> I removed beforeinput and input from the spec.

<garykac> But we still have a few links that need to be updated

<garykac> But I don't have a real spec to link them to.

<garykac> This makes me sad

<garykac> I'm waiting until we have a real link before fixing them - I'm assuming that we can get the links soon.

<garykac> Ben's unofficial spec is at: http://w3c.github.io/editing-explainer/input-events.html


http://w3c.github.io/selection-api/


<masayuki> Where the input spec go to? .isComposing is important and useful. So, it should be defined by somebody.

Oh, I don't think my link was right...

<masayuki> Oh, I see, bad timing...

<garykac> The link I sent is an "unofficial draft", so I'd like to see a more semi-official draft before fixing up all the links.

<garykac> masayuki: isComposing is part of the input spec

<garykac> They took their initial draft from the work we did

<masayuki> garykac: Yeah, thanks, I confirmed.

3 bugs for masayuki

(a new children's story)

j/k

bug 24739, 26019 and 26218

<masayuki> I updated bug 26218 now.

scribe: [familiarizing ourselves with the bugs again]

<masayuki> Our Linux's module owner, karlt, doesn't like adding "Super" and "Hyper" to the modifier key, but I like them.

<garykac> So, for 24739

<garykac> Which keys are missing to support the Sun keyboard?

<garykac> Props is there...

<masayuki> garykac: its label is "Props".

<masayuki> USB keycode indicates "Menu".

<garykac> vs. ContextMenu

<garykac> So, do we need Menu and ContextMenu (with Props mapping to Menu)?

<masayuki> But it's different from "ContextMenu" and Sun's keyboard also has "ContextMenu" key. Therefore, we should provide different name for "Props".

<masayuki> It will provide a way to distinguish the keys.

<garykac> Sun has ContextMenu and Props. But if Props -> Menu, isn't that sufficient.

<masayuki> I guess "Props" is a good name? "Menu" sounds like not good.

<garykac> This assumes that we add Menu (in a way that clearly distinguishes it from ContextMenu)

<garykac> masayuki: Yeah. "Menu" sounds to generic and will be probably be mis-used.

<garykac> ContextMenu and Props are what we currently have in the spec.

<masayuki> garykac: Yeah, it must be mis-used.

<masayuki> Oh, you added "Props" already?

<masayuki>  https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3Events-code.html#code-Props


<garykac> So, it sounds like the current spec has the definitions is needs? Is there anything else that has to happen for this bug?

<masayuki> garykac: just close it ;-)

<garykac> masayuki: yes, 'props' is in the legacy section and has a bunch of other Sun keys

<garykac> Yay!

On to bug 26019

<garykac> OK, 26019... (reading bug)

<masayuki> I also filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=27902 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=27903


<masayuki> Olli, our DOM event module owner, doesn't like the dictionary name and attribute names.

<garykac> I hadn't seen those names before. Perhaps UIEventModifierInit

Ah, I recall the issue with 26019.

In DOM4, the way to process an event initializer is laid out: https://dom.spec.whatwg.org/#constructing-events


Step 4 basically maps names onto properties.

However, for these modifier key states, there's no corresponding attribute name on the event object.

So, I needed to define how to do this in the UIEvents/D3E spec.

(It's just some simple prose that describes the mapping.)

I can take 26019. It's a relatively small change.

Related to the bug 27903, garykac and I don't have a strong reason not to change the names.

<garykac> travis: and 27092 and 27903 seem related to 26019 (naming suggestions)_

(double negatives!)

Now, 26218.

<masayuki> Using "Super" and "Hyper" and adding "SystemAccel" is my best idea. But comment 5 and comment 6 disagree with the approach.

<masayuki> He said "similar to 'OS'". But "similar" must cause incompatibility between browsers at mapping them...

garykac and I are musing about how Mac is unique... :)

We already have "Accel" which covers the Ctrl (windows), Meta (mac), and Super (linux)

garykac will now scribe what he thinks.

<masayuki> Travis_: no, Accel on Linux should be Control

<garykac> I was originally thinking that the 'OS' key would catch the Windows key and the Mac Command key, but that it not the case. (Mac Command -> Meta)

<garykac> Given that, it would be very nice to have a single key that captures Win and Command. SystemAccel fits that purpose.

<masayuki> My suggestion is, SystemAccel should be OS on Windows and Super/Hyper on Linux. Not existing on Mac.

<masayuki> Because Command is used for shortcut key. It should be Accel.

<garykac> For the Mac, I think that the Command key should be in both Accel and SystemAccel.

<garykac> It we want people to adopt SystemAccel as the platform neutral way of getting system accel keys, then it needs to work on all platforms.

<garykac> So, I will add the SystemAccel definition to the spec based on the discussion we had back in July.

<masayuki> I'm not use Mac usually. Does Command key is also used for system's shortcut key?

<garykac> And I think we're out of time

<garykac> masayuki: yes. e.g., Cmd-Tab to switch apps

So, we should meet again in two weeks?

<garykac> The Command key is the main shortcut key for app and system shortcuts

<garykac> two weeks sounds good.

<masayuki> garykac: Cmd-Tab example is conflict with Alt-Tab on Windows, though. But if it's so, I don't disagree with mapping Command key as SystemAccel.

<masayuki> I'm okay two weeks.

Fantastic. Thanks everyone!

Is this a wrap?

<masayuki> Thank you!

<garykac> masayuki: