Bug 263968 – Remove SwitchThumbElement and SwitchTrackElement

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Anne van Kesteren]

Antti tells me internal element subclasses are an anti-pattern. And given how we have been slowly shifting the approach we might not need them after all.

[Radar WebKit Bug Importer]

<rdar://problem/118056124>

[Tim Nguyen (:ntim)]

They aren't necessary if you're not using any of the resolveCustomStyle stuff.

See: https://searchfox.org/wubkat/rev/114aa2c8594807cbc34dd5dff48a9e2addfd1e00/Source/WebCore/html/ColorInputType.cpp#148,155 on how you can create a <div> with a PseudoId associated to it.

[Anne van Kesteren]

Note that I'm not entirely sure it's possible to remove these. We probably need resolveCustomStyle() to set

    grid-area: 1/1;

conditionally.

[Tim Nguyen (:ntim)]

(In reply to Anne van Kesteren from comment #3)
> Note that I'm not entirely sure it's possible to remove these. We probably
> need resolveCustomStyle() to set
> 
>     grid-area: 1/1;
> 
> conditionally.

The problem here is that WebKit is using display: inline-grid for a form control in the first place. Changing the display value should not break the form control layout. (Fwiw, WebKit has a similar issue with date inputs and display: inline-flex)

[Anne van Kesteren]

Could you elaborate on that? It's not clear to me how that works for appearance:auto. I can see someone being able to change the outer display value, but the inner display value has to be grid, no? Perhaps for appearance:auto that part has to be !important.

[Tim Nguyen (:ntim)]

(In reply to Anne van Kesteren from comment #5)
> Could you elaborate on that? It's not clear to me how that works for
> appearance:auto. I can see someone being able to change the outer display
> value, but the inner display value has to be grid, no? Perhaps for
> appearance:auto that part has to be !important.

This seems to be set on the web exposed element:

https://searchfox.org/wubkat/rev/3943142d2ef1777fc8977e6158eb10e053c3f8ca/Source/WebCore/css/htmlSwitchControl.css#27-30

We shouldn't be able to break the layout of the switch by setting a different display type on the input itself.

[Anne van Kesteren]

Given the approach taken in bug 267334 I've become more convinced we can remove these elements. For a future appearance:base we could use StyleAppearance::BaseThumb or some such and some corresponding adjustBaseThumbStyle() method. Or reconcile it with SwitchThumb and branch on the host. Various options.

[Anne van Kesteren]

Pull request: https://github.com/WebKit/WebKit/pull/23013

[EWS]

Committed 273262@main (75760f40e328): <https://commits.webkit.org/273262@main>

Reviewed commits have been landed. Closing PR #23013 and removing active labels.

[EWS]

Committed 272448.356@safari-7618-branch (2e9a891e4ccc): <https://commits.webkit.org/272448.356@safari-7618-branch>

Reviewed commits have been landed. Closing PR #1038 and removing active labels.