refactor(breadcrumb): replace 'strong' with 'breadcrumb' tags

[escii]

solves issue FusionAuth/fusionauth-issues#2572

[tonyblank]

LGTM - so many breadcrumbs, I feel like a duck!

[Aaron-Ritter]

thanks for the review @tonyblank while merging the latest updates i found a mistake in a few changes we did where it should have been replaced with <UIelement></UIelement> instead.

[Aaron-Ritter]

@alex-fusionauth I've merged the latest changes and updated some newly introduced <strong> tags and we are ready to merge. As discussed, while reviewing for any other changes the single step navigation instructions. I've update all these accordingly as well with the <Breadcrumb> tag.

The few ones unclear right now are the ones where it refers to navigate to a section rather a full page/tab.

[Aaron-Ritter]

@alex-fusionauth defined the sections as a <InlineUIElement>

[andrewpai]

Here is a file of lines that in most cases need <Breadcrumb> instead of some other styling. A few need <InlineUIElement>.
breadcrumbs-needed.txt

[Aaron-Ritter]

Here is a file of lines that in most cases need <Breadcrumb> instead of some other styling. A few need <InlineUIElement>. breadcrumbs-needed.txt

@andrewpai Working on this at the moment, and wanted to clarify, we will not only change the site content but all blog posts too with the same concept. And according to that i will update the blog section in DocsDevREADME.md with that guideline too.

[andrewpai]

Here is a file of lines that in most cases need <Breadcrumb> instead of some other styling. A few need <InlineUIElement>. breadcrumbs-needed.txt

@andrewpai Working on this at the moment, and wanted to clarify, we will not only change the site content but all blog posts too with the same concept. And according to that i will update the blog section in DocsDevREADME.md with that guideline too.

Correct, we should make our docs consistent across /docs, /blog, and /articles.

[Aaron-Ritter]

@andrewpai can we consider a read-only field still a InlineField or is InlineUIElement preferred? The most common case is the ID field which can be at different stages either of it.

And further specifying fields would be good too: can we define all types of form fields e.g. text, drop-down selection, checkbox considered InlineField, defining it as where ever info is being entered?

If it comes to the field input, it isn't standardized at the moment we have <strong>, *, **, `, ", and in few places just text at the moment. Could this be a new definition e.g. InlineFieldInput?

[andrewpai]

@andrewpai can we consider a read-only field still a InlineField or is InlineUIElement preferred? The most common case is the ID field which can be at different stages either of it.

And further specifying fields would be good too: can we define all types of form fields e.g. text, drop-down selection, checkbox considered InlineField, defining it as where ever info is being entered?

If it comes to the field input, it isn't standardized at the moment we have \<strong\>, *, **, , "`, and in few places just text at the moment. Could this be a new definition e.g. InlineFieldInput?

Sorry, I completely missed this. InlineField was created so we could reference a field in an API request or response along with its various annotations, inline to some text vs. called out on its own line. I'm not sure if the read-only field fits that description, but if so then I think InlineField is appropriate. If it isn't a field used in an API then maybe InlineUIElement is better.

[Aaron-Ritter]

Thanks @andrewpai,

We will go ahead and define a read-only form field as InlineField as it is still a form field.

fusionauth-site/DocsDevREADME.md

Line 42 in d73546e

- If you are referencing a field in a form or JSON API doc, use the [InlineField](astro/src/components/InlineField.astro) component: `<InlineField>Issuer</InlineField>`.

If it comes to the field input, we go ahead and use the <strong> tag everywhere unless you want to create a custom tag.