Hi folks.

<masayuki> Hi

Hey folks, welcome to the call.

<garykac> There are 6 bugs remaining.

<garykac> Masayuki: I fixed the 2 remaining key and code bugs.

<garykac> I don't think there's anything surprising there, but let me know if you have any issues or questions.

<garykac> We are planning on releasing the FPWD 'code' and 'key' specs next Thursday (the 12th).

<garykac> The we can update the main spec to refer to them.

Gary and I were just chatting about how we are trying to balance the need to "finish" for the sake of the HTML5 normative references, and the need to "get it right" by addressing some of the questions that Anne and co. had in recent emails.

It seems apparent that we need to work on getting the spec right.

This is going to mean a delay.

We've also been working at a feverish level toward the end-game which just moved out on us a bit. It's not a very sustainable level of investment, so from that point of view things are going to go a bit slower anyway

<masayuki> Thanks, I checked the diff of the fixes.

<masayuki> Looks okay to me.

I will need to sync up with the HTML co-chairs and ask about the impact of a potential delay. I think it will be OK, but I'd like to be sure.

<masayuki> I'll check them again later.

So the bugs are:

* clarify beforeinput firing

* Clarify "default action"

* Align with DOM4

* (unsafe to dispatch might go away)

* Specify event loop and hit testing behavior

* Converge CSS-OM view

I think we have general agreement on the direction of beforeinput

<masayuki> I think that I should file a new bug for virtual keyboard's code value.

<masayuki> But it must be not so difficult issue.

Please do! We love bugs...

<garykac> Masayuki: did you have concerns in particular that you wanted to discuss?

<garykac> We're going to take the next few weeks and try to clean up the text and bring it up to modern standards.

I'm going to take some vacation time around June 19th for two weeks.

<masayuki> garykac: Yeah, I have one.

<masayuki> About KeyboardEvent.code value of printable keys.

<masayuki> If a VKB doesn't emulate native physical key event completely, there are 2 patterns:

<masayuki> One is there is an API to compute scancode from virtual keycode. This is Windows' case. At this time, browsers can use the API and compute .code value from the result.

I filed a bug for us to start investigating tests: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25967

<masayuki> The other is, the is not such API. E.g., Android. At this time, browsers can guess non-printable keys and some printable keys which can guess the key position from virtual keycode name. E.g., it has NUMPAD or something.

<garykac> I don't expect all VKBs to provide useful 'code' values for every key.

<garykac> They should if they want to emulate a physical keyboard, but not all VKBs care about that.

<masayuki> In the latter case, browsers should NOT set .code values for printable keys which must be in standard position because VK -> SC depends on keyboard layout.

<masayuki> https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#code-virtual-keyboards

<garykac> VKBs that emulate a physical keyboard should be emulating a particular layout as well - so they should know what positions to use.

<masayuki> This looks like that D3E spec recommends that browsers should guess the key position even in such case.

<garykac> So I would expect a virtual french keyboard (with standard layout) to use 'KeyA' for the key labeled 'q'.

<garykac> If they completely change the layout for the VKB, then the 'code' doesn't have much use.

<masayuki> I'd like you to document about the latter case in the spec even if the VKB looks like emulating physical keyboard but not generating scancode properly.

<garykac> Are you referring to 6.2.4 "code and virtual keyboards"

<masayuki> I filed a bug with this log https://www.w3.org/Bugs/Public/show_bug.cgi?id=25968

<masayuki> garykac: yes.

<garykac> That section says that the browser MAY set it to the closest match or it MAY leave it undefined.

<masayuki> I think that the document is not clear and makes web developers misunderstand.

Folks, do you mind if I end the telco a bit early?

<garykac> We should probably make it more specific. I'd be happy with stating that it should be left undefined unless you're trying to emulate a physical keyboard.

<garykac> travis: no problem.

Will other folks be around next week?

<garykac> I'll be around. Next week, we're preparing the FCWD or key and code.

<garykac> The week after that is the last one Travis is around before he heads out on vacation.

It will be great to have those docs published.

<masayuki> Yeah, I'm available too.

Super.

<garykac> We should probably meet those 2 weeks and then take a break while Travis is out.

Works for me.

Thanks again everyone!

<masayuki> Thank you, Travis.

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: Travis
Inferring Scribes: Travis

WARNING: No "Topic:" lines found.

Default Present: Travis, +1.425.936.aaaa, garykac
Present: Travis +1.425.936.aaaa garykac 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: 04 Jun 2014
Guessing minutes URL: http://www.w3.org/2014/06/04-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