When attempting to configure a page on https://msft-docs.azurewebsites.net/components/heading/ as soon as a building block is added the heading is lost.
Steps to replicate:
The heading should not go away when building blocks are added.
I am seeing a different issue where heading does not go away but hyperlink does not show up.
@Falkicon's repro is what I get when testing this, and I can provide some context. (Had this written up earlier in the day somewhere)
Breaking it down:
From the standpoint of how these components are currently built to behave - _this is valid behavior_. From the tooling, I see how it may end up frustrating a user. Alternatively, by changing in the tooling to address this experience, we may also confuse users.
If we approach this only in the tool we may end up in an infinite loop of the above or making assumptions about the intention of the user. From a design system standpoint, we've named this specific to text and our guidance really points towards this being used primarily for text. Currently, it operates like an extension of an anchor, which I don't know provides a lot of benefit. Proposal: If we swap this to simply take "text" instead of "children" we could solve this problem and any confusion as to the purpose of hypertext.
@chrisdholt correct, although there is no such thing as a default child, what displays for heading is from the example data. When creating a new child from a component you must go into any building block that is added and add the children yourself since there is no example data for them to draw from.
We can discuss having children defaults along with the addition of child restrictions to schema ids where the permutator would pick a top level child element from the schema id array as the default child.
I don't particularly like the idea of taking text as a prop because then we preclude the ability for someone to pass inline elements like emphasis/strong.
Agree with this:
I don't particularly like the idea of taking text as a prop because then we preclude the ability for someone to pass inline elements like emphasis/strong.
I think it's rare that you'll need to emphasis or embolden only part of a link, but if there is a solution that works without causing the confusion I mentioned above I'm all good with keeping hypertext as children.
@janechu & @chrisdholt , can we bump the pri on this. Feels broken as it is.
The refactor of the navigation and data API has fixed this issue #963