# tabbing Published articles for tabbing. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## HTML inert property and React fallback DevFeed: [HTML inert property and React fallback]() Original publisher: [Read original article]() Author: Stanko Published: 2023-12-21T00:00:00Z Content type: tutorial Language: en Sources: [Stanko Tadić]() Topics: [HTML](), [React](), [Web Development]() Tags: [aria](), [browser](), [code](), [component](), [focus](), [html](), [mutation](), [react](), [tabbing]() ### AI overview This tutorial explains how the HTML inert property disables user interaction, keyboard tabbing, and screen-reader access for an element. It also presents a React fallback that uses tabindex changes and a mutation observer to support older browsers. ### Source excerpt HTML inert is a relatively new property, but it is supported in all major browsers since April this year. When you set inert on an element, the browser will ignore all user events on it, including tabbing into elements. It will also hide it from screen readers. I like to think of it as a "reversed focus trap". But we can use it to create focus traps for modals by setting inert on the main content. This div has inert property set and if your browser supports it, you won't be able to interact with the button and link below. You can't click meNor me! React fallback component # Before I learned about inert, I built a relatively simple component to achieve the same result. Now I prefer to use the native solution, but on most projects, we still have to support older browsers. My approach is to handle it in the wrapper component, which finds all focusable elements and sets tabindex="-1". After mounting, the mutation observer starts listening and re-sets the tabindex when content is changed. The wrapper itself has aria-hidden="true", which hides it from screen readers. You can try it out on CodePen and see the source code below: const focusableElementsSelector = [ "a[href]", "input", "select", "textarea", "button", "audio[controls]", "video[controls]", "details > summary:first-of-type", "details", "[contenteditable]:not([contenteditable=\"false\"])", "[tabindex]:not([tabindex=\"-1\"])" ].join(", "); const addTabIndex = ($wrapper) => { $wrapper.querySelectorAll(focusableElementsSelector).forEach(($element) => { $element.setAttribute("tabindex", -1); }); }; const removeTabIndex = ($wrapper) => { $wrapper.querySelectorAll(focusableElementsSelector).forEach(($element) => { $element.removeAttribute("tabindex"); }); }; const Inert = ({ enabled, children, ...props }) => { const wrapperRef = useRef(null); const observerRef = useRef( new MutationObserver(() => addTabIndex(wrapper.current)) ); useEffect(() => { if (enabled) { if (wrapperRef.current) { // Add tabindex addTabIndex(wrap ## Tab Navigation DevFeed: [Tab Navigation]() Original publisher: [Read original article]() Author: Nenad Rakocevic (noreply@blogger.com) Published: 2023-11-22T22:00:00Z Content type: tutorial Language: en Sources: [Red]() Topics: [tabbing]() Tags: [automatic](), [gui](), [keyboard](), [navigation](), [override](), [tabbing]() ### AI overview Red uses a high-level layer for tab navigation while native GUI backends retain spatial navigation behavior. TAB moves among focusable widgets and wraps to the first; Shift-TAB moves backward and wraps from first to last. Removing a face's focusable flag makes navigation skip it. In area faces, TAB normally navigates instead of inserting a tab character; Ctrl-TAB inserts one, while disabling focusability lets TAB insert it directly. The excerpt also introduces next and prev options for manually choosing navigation targets, but cuts off before showing the example's full behavior. ### Source excerpt We finally got tab navigation implemented! You might think it should have been an easy feature to add, but achieving a consistent and controllable behavior across our different native GUI backends is not that straightforward. So we opted for a mixed implementation with a general high-level navigation layer in Red and left spatial navigation handling to each backend, in order to preserve the native behavior as much as possible. Automatic navigation By default, pressing TAB key will allow you to navigate to all the GUI widgets in a window, capable of acquiring the focus. Once the last widget is reached, the next TAB press will circle back to the first focusable widget. Conversely, back-navigation can be achieved using Shift-TAB key combination, circling from first face to last one. Here is a simple example: view [ text "Name" field focus return text "Surname" field return below check "Single" check "Employed" button "Send" ] Note: check-boxes selection/unselection is done using the Space key (default on Windows). It is possible to make a face "TAB-transparent", so that TAB navigation will skip it in both directions. This is achieved by removing the focusable flag from a navigable face. For example, in the following code, clicking on the "Click me!" button will toggle the button's focusable flag on and off (using set-flag/toggle): view [ text "Name" field focus return text "Surname" field return below check "Single" check "Employed" button "Send" button "Click me!" 100 [ face/text: pick ["TAB ignore" "TAB stop"] to-logic face/flags set-flag/toggle face 'focusable ] ] In case of area face, the default behavior for TAB navigation means that tab characters cannot be input in the area. In such cases, the alternative Ctrl-TAB key combination can be used to input tab characters. In case the focusable flag is removed from an area face, then TAB key will directly produce tab characters. Here is an example: view [ text "Name" field focus return text "Surname" field return below ## Day 71: the masonry keyword DevFeed: [Day 71: the masonry keyword]() Original publisher: [Read original article]() Author: Manuel Matuzović Published: 2023-01-02T00:00:00Z Content type: tutorial Language: en Sources: [Manuel Matuzović]() Topics: [CSS](), [layout](), [Web Development](), [Web Accessibility (a11y)](), [Firefox](), [browser]() Tags: [accessibility](), [browser-support](), [css](), [css-grid](), [firefox](), [keyboard](), [layout](), [tabbing](), [test]() ### AI overview A concise guide to using the CSS masonry keyword to create masonry grid layouts. It explains how to apply the keyword to either grid axis, warns about accessibility issues caused by packing order, and notes that browser support is currently limited to Firefox behind a flag. ### Source excerpt The masonry keyword allows you to create masonry grid layouts. If you want to create a masonry layout, all you have to do is turn one of the grid axes into a masonry axis using the masonry keyword.
  1. Day 70: the defined pseudo-class
  2. Day 69: width in container queries
  3. Day 68: cascade layers and browser support
    4. ...
ol { display: grid; gap: 1rem; grid-template-columns: repeat(auto-fill, minmax(16.5rem, 1fr)); grid-template-rows: masonry; } This simple layout turns into... ...this "so much better" layout. You can also turn the other axis into the masonry axis. ol { display: grid; gap: 1rem; grid-template-columns: masonry; grid-template-rows: repeat(auto-fill, 6rem); } Accessibility By default, the packing algorithm puts items into the column with the most space. This may cause a disconnect between DOM and tabbing order, which can be an issue for keyboard and screen reader users. Test your masonry grids sufficiently. Browser support Why am I showing screenshots instead of rendering the result directly? Well, because Firefox is the only browser that supports the keyword at the moment and the feature is still behind a flag. You can enable it by visiting about:config and setting layout.css.grid-template-masonry-value.enabled to true. Can you use it today? Yeah, why not?! Most users will still get a grid, it's just not a masonry layout. My blog doesn't support comments yet, but you can reply via blog@matuzo.at.