Contact emails
Bruce...@microsoft.com, Amit...@microsoft.com, Grisha....@microsoft.com
Explainer
Native Caret Browsing Explainer
Design Doc
Native Caret Browsing Design Document
A TAG review is not requested, because the feature is not intended to be introduced as web standards. It is not expected that web developers will need to make changes to their content as a result of this work
Summary
We are proposing the implementation of native caret browsing in Chromium. In caret browsing a moveable cursor is placed on a web page, allowing a user to select and navigate text with just a keyboard. Caret browsing mode will be toggled by an activation key (F7), with a confirmation dialog displayed. The native implementation of this feature will obviate the need to install a browser extension.
Motivation
Caret browsing enables users to navigate web content using the keyboard keys and common shortcuts for character, word and line level navigation. Caret browsing allows a full range of text navigation and selection functionality within web content without relying on additional pointing devices like mice, trackpads and touchpads, so is an important accessibility feature.
Today Chromium users can download a Caret Browsing extension from the Chrome Web Store. There are several problems with this approach:
Risk
Interoperability and Compatibility
Mozilla Firefox, Microsoft Edge and Internet Explorer already natively support caret browsing. Native caret browsing doesn't aim to replace extensions; they would continue to work as they do today having the first opportunity to handle the default activation shortcut.
Ergonomics
Performance should not be significantly impacted. Native caret browsing will rely on the same implementation for rendering a caret and moving it around as already used within editable content in Chromium.
Activation
The feature is not exposed to the web API layer. The feature will initially be behind a runtime flag and disabled by default.
Debuggability
No special DevTools support is required to debug this feature.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes, with the caveat that function keys such as F7 may not be available and so alternative shortcuts might be needed.
Link to entry on the feature dashboard
TBD--but not a web-facing change in Blink.
Requesting approval to ship?
No. The feature will initially be implemented behind a runtime flag.
Thanks.
--Bruce
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MWHPR2101MB0874DFEE466AAD72ADCA8E75865F0%40MWHPR2101MB0874.namprd21.prod.outlook.com.
A few days ago talking to Alice Boxhall we were thinking about the
possibilities to improve TAB navigation on grid layout so it doesn't
follow DOM order always, instead it could follow the "visual" order
defined by grid layout (first one row, then the next one, etc.).
Probably Alice can provide more information about these ideas.
Have you think about this issue related to caret navigation?
Would be possible to make it closer to "visual" order than DOM order?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFz-FYyzVt8KE2m34Gi_CFjep14Fy_ECL3R0B8_pXPHpbuOwPA%40mail.gmail.com.
I'm glad to see this!Several years ago I tried implementing native caret browsing. One of the things I did was modifythe web tests (then layout tests) so that at the end of every test it'd try to start with the cursorat the top of the document and arrow all the way to the bottom. The test would pass if thecursor reached the bottom. I hit thousands of cases where the cursor got stuck, indicating a bugin the text editing code. That led me to implement the extension instead.I definitely think native caret browsing would be the best, though.Another issue was that I couldn't figure out how to make it possible for users to get in andout of iframes. I didn't see you address that issue in your proposal. I don't believe otherbrowsers necessarily handle this, but I think it'd be good to at least be explicit as to what'sin and out of scope.Along those lines, which form controls ought to be possible to work with and which ones areout of scope?
On Tue, Mar 26, 2019 at 2:27 PM 'Bruce Long' via blink-dev <blin...@chromium.org> wrote:
Contact emails
Bruc...@microsoft.com, Amit...@microsoft.com, Grisha...@microsoft.com
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFz-FYyX6Lj5Tx61gkTycDCNR%3D-maEturCDQ5hBSMG6PgH%3D58Q%40mail.gmail.com.
* I also found it to be a really good stress case of the editing code, caret code and selection code. I imagine you will have to fix a lot of bugs in that area.
Hi,I think there are several differences between caret navigation and spatial navigation.
- Need for the modifier key:
Caret navigation uses the modifier key (F7) to activate the feature, but spatial navigation doesn't.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6be56edf-c630-4510-b867-59246609864e%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zzmmn8t9rbppqq%40cicero2.linkoping.osa.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/39a68d66-58be-42d2-8376-babae9e0886c%40chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6be56edf-c630-4510-b867-59246609864e%40chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/84977192-5f0f-4501-9507-82defff57cd0%40chromium.org.
Contact emails
Bruc...@microsoft.com, Amit...@microsoft.com, Grisha...@microsoft.com
Thank you for all the insightful commentary on this i2i. The Native Caret Browsing Design Document has been updated in response to feedback on this thread. Summarizing the principle concerns:
Aaron, thanks for raising this issue. The design has been updated so that the caret browsing mode preference is not persisted between browser sessions. Caret browsing mode is always turned off when the browser relaunches, and the user needs to explicitly toggle it on if desired. The session caret browsing state is respected by all open tabs, and is applied on creation of a new tab.
Thanks to the several reviewers asking for clarification on the caret movement model. The design doc now specifies that caret movement for native caret browsing using the arrow keys follows the same model as caret movement in editable regions or the selection focus in editable or read-only regions of the document. After discussion with my colleagues, we feel that deriving a new independent model for moving the caret would lead to a disjoint experience when, for example, the user extends the caret into a selection by holding shift while pressing an arrow key, and thus is a non-goal for the introduction of this feature.
This movement model constrains caret movement within the same regions that establish natural boundaries for selection, i.e. the caret can move from position X to position Y if a selection can start at X and end at Y. This precludes moving into or out of controls, across regions with different content-editabilities, or across iframes.
Movement between selection boundaries established by controls and other elements that are intrinsically focusable is generally possible with tab navigation unless the author has explicitly declared these elements to not be tab stops. Moving focus also moves the caret into the focusable element, so in this way, tab navigation complements caret navigation.
There is currently no way to navigate between iframes using the keyboard alone. The goal of caret browsing, however, is to facilitate precision selection and not facilitate navigation to every possible insertion point in the document using only the keyboard. The typical scenario is for a user to click to place the caret and then further position the caret and subsequently extend it into a selection using the keyboard.
Given this understanding I’m inclined to say this isn’t a problem we need to solve in v1, and if other usage patterns emerge, we can pursue a new affordance for navigating across selection boundaries.
The primary overlap with spatial navigation and caret browsing is just that both features consume the arrow keys to control movement of the caret and focus. They aren’t solving the same problem so I don’t see any overlap otherwise. Caret browsing would typically be used to place the caret, extend it into a selection, and copy content to the clipboard. Spatial navigation moves focus between focusable elements; it is to caret browsing as tab navigation is to caret browsing. It should be complementary, but because (for the moment) they consume the same input (arrow keys) you really need to use just one or the other and not both at the same time.
The situation is similar to how caret browsing interacts with scrolling: caret browsing handles the arrow key and as a result the caret moves instead of the page scrolling (unless the caret would navigate out of the viewport in which case it is scrolled back into view).
I think caret browsing should also take priority over spatial navigation. You can toggle caret browsing on and off with F7 so it’s easy to get back into a mode that moves between focusable elements with the arrow keys instead of moving the caret.
It seems like there’s plenty of room for us to define exactly what triggers each of these features. Per Dominic’s suggestion we can talk with Chrome UX about that. FWIW it’s also not clear that on devices where Spatial Navigation shines (like navigating with a TV remote) that you would ever want to enable caret browsing – so maybe the flags controlling the features will never be enabled by default on the same device.