feat(website): add size="s" to all content EuiText wrappers

[weronikaolejniczak]

Summary

Change the EuiTour docs examples to use EuiText as a content wrapper and set size="s".

Why are we making this change?

We want the content in EuiTour to use this composition:

<EuiText>
  <p>
    {content}
  </p>
</EuiText>

as outlined by our docs:

EuiText is a generic catchall wrapper that will apply our standard typography styling and spacing to naked HTML.

That composition yields undesirable font-size, specifically 16px. The hierarchy between the title and the content seems off:

Therefore, we want all our docs examples to use size="s":

<EuiText size="s">
  <p>
    {content}
  </p>
</EuiText>

Impact to users

🟢 None. It's a website change.

QA

Specific checklist

• Verify that all examples on the EuiTour docs page render correctly (the content is 14px)

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 4b32c4d
• Documentation website
• Storybook

cc @weronikaolejniczak

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 4b32c4d

cc @weronikaolejniczak

[tkajtoch]

[not a direct feedback to this PR] I don't know how I feel about the fact that a prop to an EUI component needs wrapping with EuiText in order to render text content correctly. I strongly believe a design system component library should provide necessary defaults so that such wrappers are never needed.

EuiText is a generic catchall wrapper that will apply our standard typography styling and spacing to naked HTML.

I understand this sentence as "if you write naked / custom HTML you'll need to wrap text with EuiText for styling". Passing a simple paragraph to EuiTour is a bit of a stretch...

LMK what you think!

[acstll]

sharing my 2¢, this sounds like the never-ending struggle between consistency vs flexibility, providing sensible defaults is not always straightforward.

Passing a simple paragraph to EuiTour is a bit of a stretch...

I agree with this.

I would be in favor of having this PR merged and creating a new issue to update the API so passing EuiText is not needed.

[weronikaolejniczak]

@tkajtoch @acstll we had this conversation with @ek-so and @ryankeairns on the issue. I recommend reading it through :) Thank you for your input, I'd appreciate a review.

[acstll]

Thanks @weronikaolejniczak for bringing up the discussion conversation, I hadn't read it before you shared it 🫣. I think the discussion is not exactly the same: here it's mostly about the API in EuiTour and more exactly the need for the EuiText wrapper in order to have consistent font sizes. Would you agree?

Keeping in mind there's a need to revisit font sizes in general later, did you consider adding euiFontSize(_, 's') to the .euiTour__content node? That way we don't need EuiText, and even passing just text to the content prop will always yield 14px as expected.

<EuiTourStep
-  content={
-    <EuiText size="s">
-      <p>The tour step content.</p>
-    </EuiText>
-  }
+  content="The tour step content."

[weronikaolejniczak]

@acstll totally agree with your proposal, and I appreciate you taking the time to dive into this! 💚 I actually raised a similar point in an earlier comment (#9037 (comment)):

One doubt I have. We make <p> render as expected (instead of 14px it would be 16px). That doesn't fix the initial issue of the tour content being larger than the header. How do we want to fix that? Increase the header size or force a specific font-size in the content?

Since that part of the thread didn't get picked up at the time, I took a more immediate, lower-impact route - updating the docs for consistency and usability based on what is the current component state. I also noted a broader fix (like the one you're outlining now) would need its own issue and discussion:

“I will also create a separate task to make the <p> match the <EuiText><p> default. This has a much broader impact.”

That said, I think your idea of adding euiFontSize(_, 's') to the .euiTour__content is a solid way forward and would love to explore it further in a follow-up. If you prefer to tackle that now instead of landing this quick fix, I’m happy to close the PR and help test the change across Kibana.

Let me know what you'd prefer - I’m happy either way, just want to keep us moving forward 👍

[acstll]

Since the change I suggest would also mean updating the docs (in this case to remove any EuiText usages), I thought it could be part of this same PR.

But I'm fine with either option. And as discussed elsewhere, I'm in favor of landing this quick fix now and working on any follow-up updates later on. I will do a quick check and approve.

[acstll]

🟢 Everything looking as expected (thanks also for the other few fixes in there!)

[weronikaolejniczak]

Thanks for the review 🎉 I removed the link to the issue, will unassign myself and put into the backlog. If you have the time in your support duty week, feel free to take it!