remove unused .tsmb-form--slash::after style
#4
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Follows-up ca5519d, which moved this from applying last, in a media query, to hide the keyboard short cut on narrow viewports (likely touchscreen devices); to instead apply before the actual style unconditionally, thus never actually applying as it is immediately overriden by another style right below it. The default for `::after`, is already to not exist / be hidden. Ref #2.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Follows-up ca5519d, which moved this from applying last, in a media query, to hide the keyboard short cut on narrow viewports (likely touchscreen devices); to instead apply before the actual style unconditionally, thus never actually applying as it is immediately overriden by another style right below it.
The default for
::after, is already to not exist / be hidden.Ref #2.
NOTE: This patches conflicts with #3. Given that the limited GitHub PR-model doesn't support patchsets or stacked patches, this means our choices are 1) knowingly submit conflicting patches and rebase which ever is landed last, 2) place one on top of the other and put a disclaimer on the second to not merge it before the first and manually keep the two branches in sync, 3) Put them into one PR and give up CI coverage for the ifrst patch and give up CR separation, 4) work on one thing at a time and keep the other thing to yourself or forget about it, 5) be a maintainer and bypass CR and push directly for one of them.