search

w3c / webappswg

Web Applications Working Group
https://www.w3.org/groups/wg/webapps
64 stars 21 forks source link

Move input-events to CR #28

Closed johanneswilm closed 3 years ago

johanneswilm commented 4 years ago

As per Editing TF call of 2020-01-10, we believe the requirements are fulfilled to move level 1 of the spec on to CR. We would like to be informed about next steps by @LJWatson @marcoscaceres

marcoscaceres commented 4 years ago

Ok, cool. Just coming back to this. I need to check the the state and can provide a check list.

marcoscaceres commented 4 years ago

Ok, here is the list:

We can treat this as members of the WG feeling confident that the spec is in good shape - particularly the folks that need to implement it :)

I don't imagine there are any...

Working group requirement will be around some kind of test suite (even if manual). We basically need a full test suite to check interop and to check that conformance requirements are ok.

We can specify a minimum here... but we can say, like, around TPAC?

Have the a11y folks, PING folks, and i18n folks checked this spec?

marcoscaceres commented 4 years ago

Transferred the issue to the WebApps WG Admin repo, so we don't make too much noise over in input-events.

johanneswilm commented 4 years ago

Working group requirement will be around some kind of test suite (even if manual). We basically need a full test suite to check interop and to check that conformance requirements are ok.

I wrote a number of tests [1]. I believe WPT should now be able to handle these with slight modifications (I can look at that). There are also a number of other tests already [2]. But I wonder how we measure that the number of tests we have are sufficient?

Have the a11y folks, PING folks, and i18n folks checked this spec?

Yes, accessibility [3], PING [4] and internationalization [5] have all reviewed this.

[1] https://github.com/johanneswilm/input-events-testing [2] https://github.com/web-platform-tests/wpt/tree/master/input-events [3] https://lists.w3.org/Archives/Public/public-editing-tf/2017Feb/0057.html [4] https://www.w3.org/2017/04/20-privacy-minutes.html [5] https://github.com/w3c/input-events/issues?q=label%3Ai18n-needs-resolution

marcoscaceres commented 4 years ago

But I wonder how we measure that the number of tests we have are sufficient?

That would be great. What we can do in ReSpec is link tests to spec text: https://github.com/w3c/respec/wiki/data-tests

That would give us a good sense of specifically where any tests are missing. However, we need to do the analysis systematically to see if there are gaps.

Can we rally some folks in the task force to help us do that?

If you want to see how Payment Request does this, search for "data-tests" in the index.html: https://github.com/w3c/payment-request

This is how they show up:

Screenshot 2020-03-02 16 39 12

So, makes it easy to see how each assertion in the spec is being tested.

Yes, accessibility [3], PING [4] and internationalization [5] have all reviewed this.

Fantastic! Thanks for gathering the links. That's a huge help.

Nothing in level 1 should be at risk. Everything that was at risk in the past was moved to level 2.

Excellent.

marcoscaceres commented 4 years ago

Discussed on call chair call today. Marcos can work with @johanneswilm to get tests sorted.

johanneswilm commented 4 years ago

Interesting about "data-tests" @marcoscaceres .

One difficulty in the case of input events that I see is that we have this long last of input types, which are actions that were supported by at least one browser at the time we compiled the list. However, that should not mean that every browser has to support each action to be compliant. For example there is an input type called insertFromYank which is described as "replace the current selection with content stored in a kill buffer". Not every platform will have a "kill buffer" at all, so this is only relevant if the user agent supports kill buffers and provides a keyboard shortcut (or menu) that the user can use to replace the current selection with the contents of the kill buffer. So a test should not fail when run in browsers on OSes without kill buffers. If we do add a test it should only fail if there is such a kill buffer and the browser support such an action, yet the browser does not trigger the corresponding beforeinput and input events when it should. If a browser supports kill buffers, we haven't standardized how the user could trigger the action - for example by means of a keyboard shortcut or some menu entry.

What can we do about that?

For all those input types that I feel fairly confident are supported by all the browsers on all OSes, there should be tests now.

marcoscaceres commented 4 years ago

It's still ok to link optional tests, but it's up to you to decide. Think of it in the following way, which can help you decide: if there are potential UA interoperability issues, and those issues are causing pain for developers, then add a web platform test. That will force browsers to have to deal with those issues, because they will show up as failures once the tests are ingested into the browser code base (i.e., they will be looked at, and our managers will come and ask us about why they are failing). Otherwise, mostly ok to ignore and not add a test.

johanneswilm commented 4 years ago

Ok, understood. I think then we have everything that really is interoperable covered.

I was thinking that maybe we could also have some tests for bold and italic (and possibly some other formatting), which will work in all browsers except Firefox. The test would select some text and then press CTRL+I or CTRL+B. This should either cause no event at all (on Firefox) OR it should cause a beforeinput/input event for bold/italic. It will fail if it causes any other beforeinput or input events.

Would such a test be acceptable? Unfortunately the keyboard shortcuts CTRL+I/B also cause other things to happen in Firefox (menus opening, etc.). I hope that's not an issue.

marcoscaceres commented 3 years ago

Now part of the editing WG.