TreeView left margin override support

[fredvisser]

Pull Request

🤨 Rationale

The "sl-details-panel spacing tweaks" AzDO PR highlights the need to have icons start 16px from the edge, to bring all elements into alignment.

👩‍💻 Implementation

• Update tree-item and anchor-tree-item to change the content-region left-padding from 10px to mediumPadding (8px) to align with standard layout grids.
• Add treeViewPaddingLeftSize token, so that this value can be overridden by client apps that need a larger margin
• Fixed a few .mdx Stories where the description was poorly formatted

🧪 Testing

• Storybook review
• Chromatic diffs

✅ Checklist

• I have updated the project documentation to reflect my changes or determined no changes are needed.

[rajsite]

To summarize the concerns from Friday, the direction I think we should go is that the tree in nimble uses more normal padding values. If we look at a tree view expander aligned above a normal icon button you see the following:

You can see the left-padding on the tree-view is too big (10px). Normally we would expect 8px left spacing-16px icon-8px spacing. So the issue with the nimble tree-view is that padding-left should be 8px and not 10 or 12 px.

The second step is that the systemlink header seems to be using a non-standard icon button with custom sizing. It does not have a square 32px by 32px shape and seems to be a one-off unique button. The tree-view in nimble should not be adjusted to the sizing of that unique button only used in the sl-header.

Instead if we need to override this padding for one unique use-case then it should just be done in the sl-header styles or at most we create a design token that can be configured externally.

[rajsite]

I think having the token for configuration of this property is the right move but I don't know about broadcasting this so openly in the args table.

We could call it out in usage guidance in the mdx for the very specific use case. And we should have a test for the behavior. I'm actually tempted to have it as part of the matrix test to make sure it is interacting well with all the other modes that impact the spacing there (nested menu-items, icons, etc. )

[fredvisser]

How about a compromise where we remove the docs from the args table and rely on the SWIF Chromatic tests to catch any regressions, instead of adding this to the matrix tests?

[rajsite]

I'd like nimble features to have tests in nimble. I wouldn't expect adding a new state to the matrix test to be difficult.
If don't want to bloat the current test matrix can split the dimension out into a separate test pretty easily.
If don't think it's worth testing against the full matrix can make a separate matrix test for the relevant permutations.

[rajsite]

Moving the PR back to draft until we decide on the testing direction