06 Jan 2016

See also: IRC log


Travis, garykac, xiaoqian, masayuki




Zakim respond please.

<garykac> a+ webplatformtests not merging pull request

agenda 1

This Thursday/Friday we are meeting at Microsoft.

scribe: to discuss editing-related things.

<xiaoqian> scribe: Travis

scribe: (and have a Bikeshed hackathon too)

<garykac> Is Johannes Wilm going to be attending that meeting (local or remote)?

<garykac> He

<garykac> He's the editor of the editing spec (now called input events): https://w3c.github.io/editing/input-events.html

The purpose of the meeting is to close on issues related to the input/beforeinput event (as I understand it), and to discuss static (dead) ranges

garykac: Only want to see everyone happy and the event in a state that we can implement.

<garykac> Masayuki: did you have any concerns about these events?

<garykac> We can send you a summary at the end of Thursday so that you can give feedback for Friday.

Also (for UI Events) if there are any discussions of order-of-events, we probably need to capture that.

<masayuki> garykac: let me check the email...

webplatformtests not merging pull request

<masayuki> garykac: er, you meant that you can send the email next Thursday... (I misunderstood)

<garykac> masayuki: Sorry. I meant I can send out a summary Thursday night (PST) which you'll get Friday morning (Japan time).


Looks like that was merged!

<garykac> Yay! It got merged.

Cheat sheet: http://www.w3.org/2001/12/zakim-irc-bot.html

<masayuki> garykac: I worry about beforeinput's detail. If it's fired not only with 'direct' user input, we need to discuss the security of nested call stacks. (e.g., editing content with JS shouldn't cause nested beforeinput events)

<masayuki> garykac: because beforinput is a cancelable event, so, browsers need to fire it synchronously.

<garykac> masayuki: Yes. beforeinut needs to be cancelable, and it can't be nested. I'll keep that in mind during the discussions.

<masayuki> garykac: thanks

masayuki: in regards to nesting, I've previously proposed that it work like focus events, where a particular editable element "flags" that it will be firing the event, but only after checking to make sure the flag is not already set--prevents infinite recursion.

discuss upcoming editing/beforeevents mtg

Thanks Xiaoqian for the help!

<masayuki> Travis: do you mean that if browser meets a case to fire beforeinput during firing another event, browsers can fire new beforeinput event asynchronously? (i.e., in such case, the event is not cancelable) If so, sounds reasonable.

masayuki: no. everything is still synchronous. It's only that if recursion happens, the event is not fired so the stack can unwind.

automatic publication

masayuki: the recursion can happen for different elements, just not the same element.

<masayuki> Travis: Okay, I see.

<masayuki> Travis: It's simpler than my previous comment.

<garykac> auto publication: from now on, working drafts will be published automatically.

<xiaoqian> https://labs.w3.org/pubrules/?url=https%3A%2F%2Flabs.w3.org%2Fspec-generator%2F%3Ftype%3Drespec%26url%3Dhttp%253A%252F%252Fw3c.github.io%252Fuievents%252Findex.html%253FspecStatus%253DWD%253BshortName%253Duievents&profile=WD-Echidna&validation=simple-validation&noRecTrack=false&informativeOnly=false&echidnaReady=true&patentPolicy=pp2004&processDocument=2015

masayuki: It matches what HTML says about synchronous focus/blur events: http://www.w3.org/TR/html5/editing.html#element-level-focus-apis

<masayuki> Travis: Although, I don't see the definition of focus/blur events in the URL, but it's interesting. The definition must be different from current Firefox's behavior. I'll check other browsers' behavior.

automating the manual tests

<garykac> Apparently, this will require some additional work on the WebDriver team

<garykac> Next time we'll start going over the uievent spec bugs - I believe there are about 50 total remaining because we had a bunch of new ones added over the past month.

<garykac> Travis can't make it next week.

<garykac> But the following week (the 19th) should be good.

<garykac> Thank you everyone.

<masayuki> Thanks!

<garykac> Next meeting: 19 Jan 2016

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/01/06 02:01:27 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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)

Found Scribe: Travis
Inferring ScribeNick: Travis

WARNING: Replacing previous Present list. (Old list: Travis, garykac, xiaoqian)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ masayuki

Present: Travis garykac xiaoqian masayuki

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Got date from IRC log name: 06 Jan 2016
Guessing minutes URL: http://www.w3.org/2016/01/06-webapps-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]