Open m-akinc opened 2 months ago
@chrisdholt No rush, but it's been a couple weeks since I posted this, so I thought I'd give you a ping.
@janechu is there anything I can do to help get this in?
@janechu is there anything I can do to help get this in?
LGTM, sorry for the delay!
@chrisdholt while we've got some momentum, would be nice to get a review on this. 😊
@janechu are you comfortable merging this in? @chrisdholt do you want to review?
Pull Request
📖 Description
This PR addresses a couple design-token-related bugs:
T
(with CSS variable--T
)T
to "10" for both<my-child>
and<my-parent>
<my-child>
's value is the same as the inherited value, the value is not reflected to CSS on<my-child>
T
to "20" for<my-other-parent>
<my-child>
under<my-other-parent>
(detach, then append)<my-child>
, the value of the CSS variable--T
should be "10" for it, but it is not. It is "20", which is incorrect.<my-child>
differs from<my-other-parent>
, it should reflect the value to CSS. It doesn't. ❌<my-element></my-element>
T
(with CSS variable--T
)T
to "10" for<my-element>
T
from<my-element>
<my-element>
should not have any value for--T
, but it is still defined as "10".Also:
.only
from a combobox test that was apparently submitted on accidentconsole.error
). Now that we are properly triggering token re-evaluations when detaching elements from the DOM, a derived token may throw an error during evaluation, because it depended on an inherited token value. It seems better to print an error than to let this derail execution.🎫 Issues
N/A
👩💻 Reviewer Notes
Stackblitz demo of bug numbered 1 in description. Stackblitz demo of bug numbered 2 in description.
📑 Test Plan
Added additional test cases.
✅ Checklist
General
$ yarn change