Page MenuHomePhabricator

Isolate styles in demo pane
Closed, ResolvedPublic5 Estimated Story Points

Description

Summary

The VitePress demo site has its own styles, and we don't want those to bleed into the component demos. For example, VitePress adds somewhat specific styles to links, which could cause an issue if an <a> element is used for something in a Codex component.

These demo site styles come from two places:

  • VitePress itself
  • Our custom.css file, which includes overrides to the default VitePress theme

VitePress provides a way (raw) to exclude styles from specific files in elements:

  • Add a postcss plugin from VitePress
  • Configure it to exclude the style files you don't want
  • Use the vp-raw class on elements where you want to exclude those styles

We can apply the vp-raw class on the demo pane element in the Wrapper component.

Exceptions

We actually do want a couple of styles/resets in the demo pane:

  • Some component demos need basic link styles, e.g. a Message with a link in the text or Tabs content
  • We generally don't want the large margins placed on <p> elements in most browsers

We'll need to add these styles back to the demo pane. For link styles, this should be opt in via the existing allowLinkStyles prop of the Wrapper component.

Future work

A future use case might be a theme/skin switcher where a user can toggle between things like Vector or MinervaNeue styles, or a different theme, when viewing the demos. We should keep this use case in mind when implementing this baseline.


Acceptance criteria

  • VitePress and our custom.css styles no longer apply in the demo pane
  • Special styles, like link styles and paragraph margins, should still apply in the demo pane

Event Timeline

STH moved this task from Inbox to Backlog on the Design-System-Team board.
ldelench_wmf subscribed.

Removing from sprint as it's low priority & doesn't have an assignee - feel free to adjust!

egardner raised the priority of this task from Low to Medium.Nov 17 2022, 12:20 AM
egardner subscribed.

Now we are packaging up the Vitepress demos and using them in MediaWiki. This means that the style pollution from Vitepress is (in some cases at least) also impacting the MW demos, which are intended to be more production-like.

I'm going to move this back into the sprint board and raise the priority since the impact of this issue has expanded.

whyframe's VitePress integration looks like a promising approach: https://whyframe.dev/docs/integrations/vitepress

A simpler solution could be to use the vp-raw class in VitePress (docs), but support for code isolation is "opt-in", which essentially means "do it yourself". The example in the VitePress docs prefixes all CSS selectors in vp-doc.css (we'd want to add vp-base.css too, that's where most of the problematic rules are) with :not(:where(.vp-doc *)). This wouldn't work in older browsers that don't support :where (support table), but I don't know if VitePress works well in those older browsers anyway.

One approach we might want to consider here is to actually build the demo wrapper component as a Custom Element (aka web component). One "feature" of Web Components is that they have a separate "shadow DOM" and no styles would be inherited from the surrounding context. Vue.js supports building components as Custom Elements (just use Vue.defineCustomElement instead of Vue.defineComponent – most of the allowed options are the same). Vite also supports building Vue SFCs as custom elements (just use a *.ce.vue file extension in addition to Vue's defineCustomElement method).

I don't know if this approach would do everything we want, but it should be easy to test since our current toolset already provides these abilities.

Do we need a dedicated spike task to explore this approach?

Change 987199 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] docs: Isolate styles in the demo pane

https://gerrit.wikimedia.org/r/987199

AnneT changed the task status from Open to In Progress.Jan 2 2024, 10:02 PM
AnneT updated the task description. (Show Details)

@egardner Thanks for the info - I wanted to see if VitePress's built-in way to deal with this would work first, which I believe it does. But we should keep your suggestion in mind if we find that just excluding the undesirable style files from the demo pane isn't sufficient.

VitePress's vp-raw functionality fixes this for us, but it does so by adding :not(:where(.vp-raw, .vp-raw *)) to the end of each selector in the files that are being excluded by the vp-raw class. :where() has limited browser support in our Grade C tier.

I tested the patch in a couple of browsers that don't understand :where(), and the styles are just ignored. The site is still readable, and the components are still styled properly (although they have default fonts):

Screenshot 2024-01-03 at 4.10.58 PM.png (1×2 px, 1 MB)

Screenshot 2024-01-03 at 4.12.16 PM.png (1×1 px, 227 KB)

Screenshot 2024-01-03 at 4.11.45 PM.png (1×1 px, 579 KB)

The biggest issue I encountered is that code blocks don't have enough contrast:

Screenshot 2024-01-03 at 4.12.50 PM.png (1×1 px, 429 KB)

Screenshot 2024-01-03 at 4.11.31 PM.png (654×1 px, 390 KB)

In the patch, I fixed this by adding a new CSS file that just adds enough styles to make code blocks readable, and is not excluded when vp-raw is applied. With these styles, code blocks look like this in old browsers:

Screenshot 2024-01-03 at 4.43.14 PM.png (592×1 px, 66 KB)

Screenshot 2024-01-03 at 4.43.19 PM.png (2×1 px, 312 KB)

Change 987199 merged by jenkins-bot:

[design/codex@main] docs: Isolate styles in the demo pane

https://gerrit.wikimedia.org/r/987199

Change 989250 had a related patch set uploaded (by LWatson; author: LWatson):

[mediawiki/core@master] Update Codex from v1.2.0 to v1.2.1

https://gerrit.wikimedia.org/r/989250

Change 989250 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v1.2.0 to v1.2.1

https://gerrit.wikimedia.org/r/989250

AnneT updated the task description. (Show Details)