- Optimized/Customized/Catregorize -> Optimised/Customised/Categorise
- Github -> GitHub (80% were spelt with capital H, this is the way GitHub spells itself)
- GitPod -> Gitpod (most were without the capital P, Gitpod's site does not use capital P)
- Remove duplicate words (to to, the the)
- De-coupled -> decoupled
- implementors -> implementers (all other references used 'site implementers' so just aligning with the common case)
- Fix a/an usage in one case
- Fix one comment usage of ok, replace with OK
Fixes #10427.
In d51ec00ce1, the target was changed from
'[data-field] > .handsontable' to '.handsontable', as the .handsontable
element is no longer a direct descendant of the [data-field] element.
However, this means that we're marking ALL elements with .handsontable
as resize targets, which is not ideal as pretty much all elements
generated by Handsontable have that class.
The original logic would presumably only select the outermost element
with the .handsontable class, which is equal to the element with the
foo-handsontable-container ID (we store this in the containerId
variable).
Frankly, removing this selector outright would also fix the issue. That
said, let's keep this selector in anyway, to match the logic in older
releases.
Regression in 933a730928 introduced in 4.2.
This causes the discrepancy seen between 4.1 vs 4.2 (and later). In 4.2,
this check was broken, which means the event handler never gets added.
The combination of the event handler and the incorrect selector (fixed
in the next commit) would resize all Handsontable elements, resulting in
the bug where the table cannot be interacted with.
The commit b9f8a6b6c0 fixed another cause
of the issue, which was calling `resizeWidth(getWidth())`. The
getWidth() function should only be used to set the Handsontable's
settings, while resizeWidth should be called with '100%' as done within
the event handler.
However, seeing that the event listener is not even attached in 4.2
onwards, dispatching the resize event might not be necessary and
Handsontable might already handle this correctly. That said, let's
avoid making other changes that could potentially cause issues.
With this commit, the bug should reappear in 4.2 and later releases,
making it consistent with 4.1. The bug will be fixed in the next commit.
Previously, we rely on the fact that the SubMenuItem itself is a dismissible. So, we decide how to show/hide the number badge based on the value for the SubMenuItem's dismissible ID on the server. However, this means that if the user has dismissed the SubMenuItem and we add new dismissible child items within it (e.g. update the ID for the 'What's new in Wagtail version' child item), the number badge will not show up. This commit changes the logic to show/hide the number badge based on whether there are any undismissed items within the SubMenuItem and whether the it has been opened or not.
* Extract userbar BaseItem.get_context_data()
* Extract Axe config into smaller attributes and methods for easier overrides
* Add TypeScript interface for WagtailAxeConfiguration
* Improve typings for userbar.ts
* Separate Axe `runOnly` and `rules` options
* Pass request object to all axe configuration methods
* Remove Axe runOnly option if it's falsy
* Add docs for customising the accessibility checker
* Use lists for Axe include and exclude selectors
* Parse JSON script when testing accessibility checker config
* Add tests for customising accessibility checker configuration
Co-authored-by: Thibaud Colas <thibaudcolas@gmail.com>
