fix(ui): make the touch pen a corner chip, not a scrim over the art
Always-visible is not the same as always-in-the-way: the overlay is inset:0 at 50% black, so gating it on hover left every touch device with the artwork it is editing permanently darkened. It is only a hint — .cover-art-edit carries the click, so tapping the art always worked — while the × really is the only route to its action and stays. The chip borrows the remove button's size, disc and alpha. Also corrects the claim that no tier can render as a touch device: no committed one does, which is a choice about projects rather than a limit.
This commit is contained in:
@@ -1479,10 +1479,20 @@ and its place in the accessibility tree. Where the control is the
|
||||
overlay and remove, `shortcut-capture`'s reset (#137) — because hiding
|
||||
it takes the action away entirely.
|
||||
|
||||
One thing to know before checking either: **no tier here can render as a
|
||||
touch device.** CDP's `Emulation.setEmulatedMedia` does not reach the
|
||||
component tier's iframe, and the e2e projects are Desktop Chrome and
|
||||
Desktop Safari, neither of which has touch. So
|
||||
**Always-visible is not the same as always-in-the-way.** The cover-art
|
||||
overlay is `inset: 0` at 50% black, which is fine as a hover state and
|
||||
is not fine as the permanent appearance of the artwork being edited —
|
||||
and it is only a *hint*, since `.cover-art-edit` carries the click and
|
||||
tapping the art always worked. Off hover it becomes a corner chip in
|
||||
the remove button's own language. The × beside it stays full-size,
|
||||
because that one really is the only route to its action.
|
||||
|
||||
One thing to know before checking either: **no *committed* tier renders
|
||||
as a touch device.** CDP's `Emulation.setEmulatedMedia` does not reach
|
||||
the component tier's iframe, and the e2e projects are Desktop Chrome
|
||||
and Desktop Safari, neither of which has touch — a Playwright project
|
||||
using a mobile descriptor would report `hover: none`, so this is a
|
||||
choice not to carry one rather than a thing that cannot be done. So
|
||||
`hover-affordance.test.ts` asserts the *parsed stylesheet* — which rule
|
||||
sits inside which media query — and says so; the regression it exists
|
||||
for is someone hoisting a rule out of its query as a tidy-up, which
|
||||
|
||||
@@ -538,10 +538,33 @@ export class TrackDetails extends LitElement {
|
||||
* and nothing about the layout moves.
|
||||
*/
|
||||
@media not all and (hover: hover) {
|
||||
.cover-art-overlay,
|
||||
/* The × is genuinely the only route to removing the art, so
|
||||
on a device that cannot hover it is simply always there.
|
||||
|
||||
The pen is not: .cover-art-edit carries the click that
|
||||
opens the file picker, so tapping the artwork already
|
||||
worked while the overlay was invisible. It is a discovery
|
||||
hint — and paying for discovery by covering the artwork
|
||||
being edited in 50% black, permanently, on every touch
|
||||
device, is heavier than the hint is worth. It becomes a
|
||||
corner chip in the remove button's own visual language
|
||||
instead: same size, same disc, same alpha. */
|
||||
.cover-art-remove {
|
||||
opacity: 1;
|
||||
}
|
||||
|
||||
.cover-art-overlay {
|
||||
opacity: 1;
|
||||
inset: auto 4px 4px auto;
|
||||
width: 24px;
|
||||
height: 24px;
|
||||
border-radius: 50%;
|
||||
background: rgba(0, 0, 0, 0.7);
|
||||
}
|
||||
|
||||
.cover-art-overlay wa-icon {
|
||||
font-size: 14px;
|
||||
}
|
||||
}
|
||||
|
||||
/* Error message */
|
||||
|
||||
Reference in New Issue
Block a user