<Travis> Zakim this is DOM3

Hallo Travis

<masayuki> Hello, Travis, Garykac

<scribe> Agenda: TPAC arrangements

<scribe> Agenda: Prep for a new spec release before TPAC

<Travis> The deadline for CfC to publish a spec before TPAC is October 28th

For TPAC, I'm arriving in HK on Sunday. And then I'll be traveling to Tokyo on Wednesday night.

I'll be in Tokyo until Sunday. If Thu or Fri work for Masayuki, then we should try to get together at that time.

<Travis> For TPAC, I'm arriving in ShenZhen on Sunday, and staying through Saturday morning.

For webapps, the interesting stuff is on Mon/Tue

<Travis> WebApps meets Mon/Tues, HTML is Thurs/Friday

<Travis> Let's open the spec, then start reviewing it from the bottom-up.

<Travis> Gary is pushing an update to the spec now--stay tuned

<Travis> Update complete, please reload the spec if you haven't already. (Issue 5 should be expose ticks in wheel event)

<Travis> Starting with issue 22 at the bottom...

starting with issue 22 ("basic mobile phone keys") at the bottom

Do we want to have a section with mobile phone keys?

Or do we want to have that in a separate addendum document?

I wouldn't want the spec to be delayed waiting for these keys, but they certainly would be nice to have

We should try to make a stab at including them, but if takes too much time we should punt.

<Travis> We don't want to block on this.

<Travis> Next issue 21: multimedia keyboard.

<masayuki> On Windows, browser can dispatch keydown events for multimedia keyboard's keys at least. On Linux, they are defined by GDK. But I'm not sure if they are actually used.

Would it be better to have LaunchApp1 ... LaunchApp12 or LaunchMail, LaunchBrowser, LaunchXxx ?

There's some overlap (unfortunately) between things like LaunchApp2 and LaunchCalculator

With the GDK definitions, people can remap keys to use the values.

<Travis> LaunchApp1..12 seems easier for a windows implementation, not sure how Linux would handle this.

App1 .. App12 is the easiest, but then I'm not sure about the best way to handle the GDK definitions.

<Travis> Issue 20 and 21 are the same issue, right?

<masayuki> Travis: see the bug's comment 0. They are different.

<Travis> garykac: We could define them generically (numbers), and then suggest how GDK would map their specific app commands.

We could define App1..App12 and then have suggested apps for each number (App2 = Calculator, ...)

<Travis> ... this works for 1 and 2 which are psuedo-defined anyway.

Actually, there are probably more than 12...

I'm going to write that up to see how it looks and then solicit comments.

<Travis> Sounds good.

<Travis> Next issue 19..

<masayuki> The reason was, there was .char, I think.

For issue 19, why do we use "DeadAcute" instead of the Unicode codepoint?

<masayuki> I think that it's okay to use Unicode comibing characters instead of DeadXxx.

So DeadAcute would become \x0301.

This is not as pretty in the code as the "DeadAcute", but there are a lot more combining characters than the short set that we have.

I like the friendly names, but the unicode code points is more general.

<Travis> No resolution here yet.

Let's think about it a bit more and revisit this next time.

<Travis> Next issue 18.

For the Eisu key, I think we should call it "Eisu" since that's the most common name for it.

<Travis> I have no context on this, perhaps masayuki can weigh in?

I don't think there's any value coming up with another name for it.

<Travis> Resolve to name the key Eisu then?

Also see issue 16 - Zenkaku and Hankaku are probably better names for these keys than fullwidth/halfwidth since that's how they are defined in most (all?) OSs.

<masayuki> On JIS keyboard for PC, there is also Eisu key, but it may work different from Mac's Eisu key. Should we use same name for them?

<masayuki> garykac: I agree with Zenkaku/Hankaku are better name.

<Travis> HTML5's input mode: http://www.w3.org/html/wg/drafts/html/master/forms.html#input-modalities:-the-inputmode-attribute

<Travis> has keywords, "full-width-latin", but no half-width anything at the moment.

Travis is checking to see if there's another W3C spec that uses the names fullwidth/halfwidth. If so, it makes sense to be consistent with that other spec. If not, I think zenkaku/hankaku work better.

<Travis> I don't think that the HTML5 spec presents a compelling argument for keeping fullwidth/halfwidth

<masayuki> It depends on Zenkaku/Hankaku key switches if they actually change the inputmode to fullwidth/halfwidth characters.

<masayuki> I meant it depends on the environment.

<masayuki> OS or IME framework or IME.

<Travis> I think HTML5's input mode is a helper for IME.

<Travis> As far as the names go, I don't have a strong opinion.

Another argument for zenkaku and hankaku is that ZenkakuHankaku sounds better than FullWidthHalfWidth ^_^

<Travis> and Issue 15, if there's a key for it, I'd like to include it.

I'm not sure if there's a real key equivalent for IMEToggle? Does the OS grab it before the browser has a chance to see it?

Anyway, if we find these keys, I'll add them. But I'm going to look for evidence first (this issue is a placeholder reminder for me)

<masayuki> I think that KanaMode and KanjiMode indicates the result of the keypress, however, in most environment, we cannot know what happes with the key because it may depend on IME settings.

OK. I'll hold off on them and we can add them later if needed.

<Travis> If we do add these keys, but can't implement them, then they can be labelled "at risk" for the CR for DOM 3 Events, and we can remove them later if they are un-implementable.

<masayuki> On all platforms, we can catch every native key event before IME handles it. However, on Windows, current implementations handles it after IME handles it.

For issue 14, I've seen both PowerOff and PowerDown. Is there a distinction or are they the same thing?

<Travis> They seem like the same thing.

I'll merge these keys unless we find evidence that they should be separated

<masayuki> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=21118#c3

For issue 13, Sleep, Hibernate and Suspend, we should add text describing the difference between them.

Ideally, these keys would cause a separate Sleep or Hibernate event that would be handled.

<Travis> Sleep is generally the "lightest" sleep (wake and be ready at a moment's notice.

I'm not sure if it makes a lot of sense to have them here, but they are actually defined keys

<Travis> Suspend, may actually mean that the system is not shutting down, but that the app is being suspended--could be confusing.

<Travis> Might just want to add them with a note saying they are included for completeness and that their behavior might overlap

Travis says that we could add a note "included for completeness". Which is a good idea.

for issue12, the text should read MediaPause (not MediaPlay)

Oh nevermind.

I think the Pause key is a leftover from older days and shouldn't be used for media apps.

Should we meet next week?

<masayuki> Yes, Play and Pause are legacy keys for old non-PC systems.

<Travis> Yes, I'd like to meet next week.

Good. That's what I thought.

<Travis> (The 22nd).

We want to try to CfC by the 28th.

<masayuki> Okay.

<Travis> We should plan on making last-minute polish on the spec, and try to issue the CfC for publication in that coming week.

Should we leave any of the "issue"s in the spec for the CfC, or do we need to remove all of them?

I wonder if it makes sense to leave markers for areas that we want people to review or comment on.

I think we want to remove them all...

But I want to call people's attention to the areas of the spec that have had major changes.

We'll probably have to do that in the announcement email

<masayuki> Will we meet in Tokyo on Oct 31th or Nov 1th?

<Travis> We should add a "general changes" section (F.3) to direct folks to what's new

TPAC is Nov 11-15

<masayuki> After next draft is published, I'll modify Gecko's implementation. Then, I'll feedback new issues if there are.

<Travis> That sounds great.

I'll be in Tokyo Thu 14 Nov - Fri 15 Nov (actually until Sun 17 Nov)

<Travis> Recap on action items...

masayuki: Sounds great!

<masayuki> garykac: Okay, I'll book the days.

<Travis> garykac: should be able to propose solutions to issues 11-22 (key name changes)

One AI I have on hold from last week is moving locale into UI Events. Do we still want to hold off, or should we do that now?

masayuki: which day works better for you, Thu or Fri? Pick one and let us know. I don't know if Kochi has a preference.

<Travis> Travis will follow-up with Kochi on the potential removal of locale from the spec.

<masayuki> garykac: Either is okay, but Thu is better for me.

Let's plan on Thu then.

<Travis> garykac: To produce a first draft of the CfC document with all issues noted for review, rather than being open.

See you all next Tue

<Travis> See everyone next week!

<masayuki> See you!

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

No ScribeNick specified.  Guessing ScribeNick: garykac
Inferring Scribes: garykac

WARNING: No "Topic:" lines found.

Default Present: [Microsoft], +1.650.390.aaaa, garykac
Present: [Microsoft] +1.650.390.aaaa garykac Travis masayuki

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: 16 Oct 2013
Guessing minutes URL: http://www.w3.org/2013/10/16-webapps-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report