I'd like to revisit this after spending a lot of time with the new Field and Label components and other input components like Checkbox and Radio. Some thoughts:

@CCiufo-WMF revisiting this, I did originally set the acceptance criteria to just cover making this possible, not actually providing full support within Codex itself. So resolving T284273 will resolve this task too, although we may want to consider if we do want to provide documented, full support for the checkbox hack in Codex in the future.

@bmartinezcalvo I ended up not creating a separate demo, because having 2 CSS Tabs on a single page requires some extra work to track the current tab for both demos. This muddies the markup for both demos, which I believe will make them harder to understand for users. Most users will only ever have a single set of CSS tabs on a page, so they will not need to know how to handle multiple instances.

@bwang suggested a way for us to do minimal updates in Codex to allow them to achieve the right styles in Vector:

Good question @CCiufo-WMF and thanks for laying out the options @egardner - I would recommend we update the markup of the Vue component to use <details> (in a future patch) and use that for the CSS-only version as well. I can't get behind the idea of not using the appropriate, semantic HTML element just to support IE11

@Sswiergosz I'm assigning this to you since you built the component, but do let us know if you don't have time to do follow-up work. Thanks again for your contribution to Codex!

In T325105#8861519, @bmartinezcalvo wrote:

Message

• The messages with dismiss button and auto-dismiss are missing.

The dismiss and auto-dismiss functionality is not really possible without JavaScript, so those features were not implemented.

@AnneT should we include a message in the CSS-only version demo explaining this?

@bmartinezcalvo I've added the size prop to the configurable demo, thanks for the reminder!

@lwatson FYI, this is the component-library-wide vertical alignment issue I was talking about

@Jdlrobson @bwang we've just merged the following:

Moving this to design review so we can decide what to do about fixedHeight

@bwang we hadn't implemented any responsiveness in the flush layout mixin until just now since we were blocked on how to implement T333392: Button: add "large" size. I just pushed a series of patches that will:

@bmartinezcalvo thanks for all the feedback! I've responded to it all and pushed a patch that fixes some of the issues you raised. I just have a question about the Select disabled colors.

Update: the engineers have decided against largeOnMobile. Since Minerva only uses large buttons for all viewport widths for now, we will simply add the large size.

@bmartinezcalvo thanks for your thoughts on this! I like the idea of introducing a new size for the 44px version, and agree with the terminology "medium" for the existing size and "large" for the 44px size. Not restricting it to icon-only buttons makes sense to me and makes implementation a bit easier.

@Sgs the idea of style props is really interesting, thank for sharing those examples. I agree that a boolean prop is not ideal here and that we should think about a pattern that we could use for cases like this throughout the library.

@CCiufo-WMF Sorry, I must have assigned myself by accident - this would be for the Web team to do, but we will want to discuss the results of the experiment to determine if we want to continue to offer the legacy Wikimedia UI theme in Codex (the one with the 14px base font size).

Speaking specifically about IE11 here:

It looks like the only remaining issue (once my latest patch is merged and released) is T336548.

@bmartinezcalvo @Volker_E @egardner we're in agreement with the Web team that we should handle this in the Button component and enable dev users to set a larger size in certain contexts, and that it's acceptable to set the larger size only on mobile viewports. We now need to decide what's appropriate in the context of the design system. The remaining questions are:

In T322436#8843511, @Jdlrobson wrote:

However, it looks like the flushing is 1px off from what we currently use - Looks like you subtract the border here rather than add it: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/918598/3/resources/lib/codex-design-tokens/theme-wikimedia-ui.less#163 - I'm not sure which is correct since it's late in my day but wanted to note this down.

To add more context: Codex buttons use px for padding, so using px for the flush layout mixin is necessary since button padding will not change with font size. So the mixin will work with Codex buttons but not the Vector buttons with relative padding values.

In T333584#8837094, @Sgs wrote:

This makes me wonder about a11y requirements. Should we backup the dots with some specific aria attributes or a title? Also, if click navigation is supported, should we support keyboard arrow navigation?

@Jdlrobson we've been referring to these kinds of buttons with icons as icon-only buttons (i.e. no visible text).

@Sgs @VYanez-WMF please feel free to edit the description to add more details!

@Sgs Thanks for raising these points! I think we can narrow down the potential features of this component to a minimum viable product that will work for the onboarding dialog and be extendable in the future if we need to add more features to support more use cases.

@bmartinezcalvo Text versions of the typography examples are now up for review! https://917391--wikimedia-codex.netlify.app/style-guide/typography.html#use-of-styles

@bmartinezcalvo done in the latest patchset; it'll show up on the test site shortly!

This has been completed and documented on mw.org

Since there's no configurable demo set up for TextArea yet, I think we can skip design review for now. Once the TextArea demos are built and we're getting ready to take TextArea out of WIP, we can make sure it goes through design review. Nice work, @lwatson!

@bmartinezcalvo / @CCiufo-WMF do we want to do design review of CSS-only components? I think it would be worthwhile to have a designer review the CSS-only components that we have implemented just to check that we have indeed reached an acceptable level of parity with the Vue component. FWIW, not all components are 100% the same due to different underlying markup (e.g. the CSS-only Select menu is native to the browser, and keyboard navigation works differently for CSS-only tabs).

Thanks for the feedback @bmartinezcalvo! Everything should now be fixed except for this one:

Looping in @Jdlrobson and @bwang so they can weigh in on the design discussion here.

@Jdlrobson @bwang The patch to add this mixin has been merged, but please let us know if you have any feedback. See the code here and a working example here (below the button tables).

Am I understanding correctly that part of the problem is that we could potentially add more CSS classes to the parser-generated markup, but this would not cover templates that mimic the parser output? If that's the case, I wonder if some version of "CSS-only components" could help here. This could look like creating semantic CSS class names via BEM and documenting the intended markup structure and classes, which template authors could copy. We're documenting CSS-only Codex components on the Codex docs site (example); something similar could be done on-wiki for this.

@bwang Good point - we make use of several native button pseudo-selectors (enabled/disabled, active/focus/hover...) which would not work with label, and I'm assuming we'd need to explicitly set display: inline-block to cover other elements. We would either need to use an explicit class-based approach in Button or write special styles to cover other elements.

@bwang we now support 3 icon sizes in both the Vue and CSS-only icons, with associated size tokens that are also available. Will that be sufficient for your needs?

@bmartinezcalvo awesome, thanks for reviewing!

Design principles section is up: https://914017--wikimedia-codex.netlify.app/style-guide/design-principles-overview.html

@bmartinezcalvo That all makes sense to me! I've opened a patch as a proof of concept of this change,here's the preview site. Some details to review on mobile:

@bmartinezcalvo thanks for the info! You can see the updates here. One note: when menu items are hovered, they have black text, but I decided to keep the blue text on hover in the menu since that's how regular menu items (not in the dropdown menu) act.