- From: Takayoshi Kochi <notifications@github.com>
- Date: Thu, 02 Jun 2016 23:11:42 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc:
- Message-ID: <w3c/webcomponents/issues/496/223498940@github.com>
@rniwa I generally agree that you can define the algorithm in iterative steps to find the next or previous element. Once I tried, but during the PR review @hayatoito preferred the way as it is, for the reasons stated above, and we did that way. It is still pretty tough to upstream the current focus navigation to the html spec, I'd like to work on express the algorithm in better way. With that said, dumping the current Blink implementation into spec text should not what you want, and it is already quite complex to handle various cases, probably has bugs on corner cases. The testability is also a problem, as we don't have a good way to test how tab navigation works in e.g. web platform tests infrastructure (of course, Blink and WebKit has both eventSender, though). As a first step toward it, I'd like to make some non-normative notes like what chaals commented https://github.com/w3c/webcomponents/issues/496#issuecomment-223056995 and write down some examples (or manual tests). Does it make sense? --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webcomponents/issues/496#issuecomment-223498940
Received on Friday, 3 June 2016 06:12:30 UTC