Add test of cursor on element underneath a <select> menu

[cvrebert]

Refs:

• https://connect.microsoft.com/IE/feedback/details/963961/when-hovering-over-a-select-menu-item-the-cursor-for-the-element-underneath-the-menu-is-displayed
• not-allowed cursor of a disabled field appears in a <select> menu in IE11 twbs/bootstrap#14528

[syncbot]

Automatic validation checks of commit eca00da passed.

[syncbot]

Automatic validation checks of commit feaec41 passed.

[cvrebert]

CC: @frivoal, since you're an Editor of css-ui-3

[cvrebert]

CC: @tantek for review, as other Editor of CSS3 UI

[frivoal]

@cvrebert Sorry for the sluggish answer, I was on vacation.

1. Why are use using testharness.js, since you're not making any programmatic assertions?

2. No need to ask for the test to be skipped if cursor is not supported. This goes into the test suite for css-ui, so cursor is supposed to be supported, and failing the test if it is not is appropriate.

3. The test passes if cursor is not supported at all. You should display a recognizable cursor shape or the FAIL case, rather than rely on just the default.

4. I completely agree with the intent of the test, but I am not sure I can find justification for it in specifications, on 2 grounds:
   4.1: The spec defines being over the element in terms of the "border edge". I can't find a clearcut answer to whether that's supposed to include the thing that pops down when you click on the select element.
   4.2: More glaringly, the spec does not seem to define what happens when elements overlap.

Can you find justifications somewhere for these two points? If not, I still agree with the test, but then we probably need to add extra clarifications in the specification (this level or the next) first to back it up.

[syncbot]

Automatic validation checks of commit 164ea24 discovered the following problem:

In css-ui-3/select-cursor-001-manual.html:

• Not linked to a tracked specification anchor.

[syncbot]

Automatic validation checks of commit 6d5a56d passed.

[cvrebert]

1. Why are use using testharness.js, since you're not making any programmatic assertions?

Sorry, http://testthewebforward.org/docs/test-templates.html#manual-test confused me. Removed the <script>s.

2. No need to ask for the test to be skipped if cursor is not supported.

Removed.

[cvrebert]

@frivoal

3. The test passes if cursor is not supported at all. You should display a recognizable cursor shape or the FAIL case, rather than rely on just the default.

Given that the spec says:

User agents may ignore the cursor property over [...] native UI widgets e.g. those that may be used inside some user agent specific implementations of form elements.

Then setting e.g. select { cursor: XXX; } (like you're suggesting) cannot be relied upon.
Also, my sanity-check testcase is merely checking that insanity (using the cursor of an underlapping non-ancestor element) doesn't occur. I think it'd be reasonable to leave stronger "verify that cursor is actually supported" checks to other testcases.

4.2: More glaringly, the spec does not seem to define what happens when elements overlap.

I agree, that appears to be a significant oversight in the spec. Perhaps it could delegate and define the semantics in terms of :hover (or define them both in terms of some 3rd shared definition)? I'm unable to come up with a situation where foo { cursor: XXX; } and foo:hover { cursor: XXX; } wouldn't be equivalent.

If not, I still agree with the test, but then we probably need to add extra clarifications in the specification (this level or the next) first to back it up.

Cool. Do you need me file a spec bug or anything?

[syncbot]

Automatic validation checks of commit b2a1ffe passed.

[cvrebert]

Went ahead and posted to the mailing list. As of yet, there haven't been any comments on the post.

[cvrebert]

@frivoal Friendly ping. Hope your move went okay.

[frivoal]

@cvrebert Filing a bug on the spec is a good idea, and the best way to do that is what you did: sending a mail to www-style. Your mail is in my queue of things to get to, but due to my ongoing move, I'm processing this queue rather slowly. Sorry for the delay, and thanks again for the test and the bug report.

[cvrebert]

@frivoal Given that you've now updated the spec to use hit testing and thus resolve (4), and I responded to (3) in #800 (comment) , is there anything else blocking you from merging this?

[frivoal]

@cvrebert Nope, nothing is blocking. The delay was only caused by me trying to get connectivity in my new home. Since that's solved, this is merged. Thanks.

[cvrebert]

Thank you.