Create smaller variations for form elements

Updated form--select.css and form--text.css with smaller versions of the text field and the select box.
I used the --small and --xsmall flags on form-element class.
It worked for me but needs review/testing, and I think for these two new sizes we need a small and xsmall submit button variations.

@ckrina, thank you for your feedback. I'm working on it!

I updated the small and extra small text and select fields.

The smaller variants should also be used for the actions on the /content page, did you also test that @ckrina?

Fixing nits.

@ckrina good thanks :)

@fhaeberle thanks! :)
@ckrina, please test the patch, and if it's good, it's done.

@pzajacz and fhaeberle: When I tried patch #14, it fixed the extra small fields as seen on the Textarea formatting select screenshot but the content and people filter forms still look like they're using the medium input fields as seen in their screenshots. Please let me know if there's any other testing that I can do to help out.

-Kat

I added an if in the claro_form_views_exposed_form_alter preprocess. I don't know that, this is the good solution or not, but it's working now.
So, the implemetation of 'small-size' is testable now on these pages:
/admin/content
/admin/people

The patch should be re-rolled (we are already in core :)).

Just a reroll [ it is small enough that I just transferred all the changes between projects ]

This patch is bigger

what is new is that files like

form--text.pcss.css

have a corresponding file in with a name ..

form--text.css

I am not sure what is going wrong here ... So help would be appreciated

I will also ask on slack

When I run

yarn run build:css

it works only on files in

themes/claro/css/src/components/

specifically variables.pss.css does not generate variables.css

when I try and follow up with

yarn run build:css --file themes/claro/css/src/base/variables.pcss.css

is does not function as expected ... hmm

please ignore this as

changes to variables.pcss.css ARE reflected in changes to 'form--text.css'

+++ b/core/themes/claro/claro.theme
@@ -616,6 +616,10 @@ function claro_form_views_exposed_form_alter(&$form, FormStateInterface $form_st
+
+      if ($form['#action'] === '/admin/people' || $form['#action'] === '/admin/content') {
+        $form[$child_key]['#attributes']['class'][] = 'form-element--small';
+      }

Why should this be limited to these two specific pages? Shouldn't all exposed views use this?

This builds off the previous patch in #23, but since it was created when Claro's file structure was different, an interdiff wouldn't be particularly useful.

This applies the changes to all views filters and refactors how several values are calculated so there's a consistent method of determining padding, etc for the default and variants.

There's a small change in views-exposed-form.pcss.css that could be argued as out of scope, but is necessary for the submit button to align in views filters. I think this is an acceptable change as views filters are a very good place to do the first implementation of --small variants, and those changes stop this from happening:

There is also a temporary change to in a form_alter() to node forms to make this easier to review. This adds textinput and select inputs of each size to every node form. That should get removed once there's been sufficient manual review.

Should we also ensure that autocomplete elements work nicely in the small variation?

Agree with #29.
I also think the selectors should be expanded on a bit so it is possible to make all inputs in a form small/extrasmall by adding one class to the form.

With the current solution, it's only possible to do this on a per-input basis. Also allowing this on a per-form basis will make it easier for contrib developers and prevent the need for many unweildy form_alter() uses.

This patch should address 29 and 30. I think I still need to address form buttons though. I matched the autocomplete dropdown to the font-size and padding of the parent field.

Relevant screenshots attached.

Whoops, I let a composer thing slip through. New patch. :)

1. Lets also add styles for .button inside .form--extrasmall and .form--small

2. +++ b/core/themes/claro/claro.theme
   @@ -726,4 +726,14 @@
   + * Implements hook_preprocess_HOOK for form.
   + */
   +function claro_preprocess_form(&$variables) {
   +  // Use small form elements.
   +  if ($variables['element']['#form_id'] == 'views_exposed_form') {
   +    $variables['attributes']['class'][] = 'form--small';
   +  }
   +}
   

   May be simpler to just put the class addition in the existing claro_form_views_exposed_form_alter()

3. +++ b/core/themes/claro/css/components/form--select.css
   @@ -74,24 +74,24 @@
   -.no-touchevents .form-element--type-select.form-element--small {
   +.no-touchevents .form--small .form-element--type-select.form-element {
   

   There's still a benefit in including the rules that end with classes such as .form-element--small. This allows the targeting of specific elements OR the entire form. This is useful if there's a need for different sizes in the same form or there are inputs without a parent form (this exists in the wild :) )

4. +++ b/core/themes/claro/css/components/form--select.css
   @@ -74,24 +74,24 @@
   +.no-touchevents .form--extrasmall .form-element--type-select.form-element,
   

   The additional .form-element seems like more specificity than needed, but I haven't tested this manually.

5. +++ b/core/themes/claro/css/components/jquery.ui/theme.pcss.css
   @@ -396,9 +396,10 @@
    .ui-autocomplete .ui-menu-item-wrapper {
      display: block;
   -  padding: 0.75rem 0.9375rem;
   +  padding: var(--input-padding-vertical--small) var(--input-padding-horizontal--small);
      color: inherit;
      background: inherit;
   +  font-size: var(--input-font-size--small);
    }
   

   It looks like this is changing the default styling to work in a --small form. This should instead get small/extrasmall variants like the other inputs did.

Thanks @bnjmnm!

I think I've addressed 1-4, and 5 was me misinterpreting #29, so I reverted and adjusted the icon in the autocomplete field instead (see screenshot).

I also applied similar small and extrasmall form rules to action links per @bnjmnm's suggestion.

New patch with some RTLs I missed.

1. +++ b/core/themes/claro/claro.theme
   @@ -1272,7 +1386,9 @@ function claro_form_media_library_add_form_alter(array &$form, FormStateInterfac
   +  if (isset($form['container']['upload'])) {
   +    $form['container']['upload']['#media_library_upload'] = TRUE;
   +  }
   

   Looks like some cross-patch contamination

2. +++ b/core/themes/claro/css/components/autocomplete-loading.module.css
   @@ -84,6 +84,16 @@
   +.js .form--small .form-autocomplete,
   +.js .form-autocomplete.form-element--small {
   +  background-image: url("data:image/svg+xml,%3Csvg width='36' height='18' viewBox='0 0 20 20' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath d='m8,0.999781c-4.5394538,-0.1723607 -8.18800628,4.7870352 -6.6873554,9.068641 1.1767997,4.383903 6.9938335,6.416563 10.6372244,3.700244 0.325764,-0.391006 0.56541,0.275384 0.84585,0.440896 1.246479,1.246479 2.492958,2.492959 3.739437,3.739438 0.471354,-0.471354 0.942709,-0.942709 1.414063,-1.414063 -1.44987,-1.44987 -2.89974,-2.899739 -4.34961,-4.349609C16.410345,8.7174615 14.748115,2.9379071 10.536504,1.4755074 9.7302231,1.1615612 8.8650587,0.99941873 8,0.999781Z m0,2c3.242467,-0.1231148 5.848576,3.4193109 4.776682,6.477601 -0.841211,3.131959 -4.9939918,4.58038 -7.5998944,2.649077C2.4322236,10.397214 2.2765833,6.0022025 4.8919502,4.0831465 5.7667487,3.38528 6.8811016,2.996997 8,2.999781Z' fill='%23868686' /%3E%3C/svg%3E");
   +}
   +
   +.js .form--extrasmall .form-autocomplete,
   +.js .form-autocomplete.form-element--extrasmall {
   +  background-image: url("data:image/svg+xml,%3Csvg width='30' height='15' viewBox='0 0 20 20' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath d='m8,0.999781c-4.5394538,-0.1723607 -8.18800628,4.7870352 -6.6873554,9.068641 1.1767997,4.383903 6.9938335,6.416563 10.6372244,3.700244 0.325764,-0.391006 0.56541,0.275384 0.84585,0.440896 1.246479,1.246479 2.492958,2.492959 3.739437,3.739438 0.471354,-0.471354 0.942709,-0.942709 1.414063,-1.414063 -1.44987,-1.44987 -2.89974,-2.899739 -4.34961,-4.349609C16.410345,8.7174615 14.748115,2.9379071 10.536504,1.4755074 9.7302231,1.1615612 8.8650587,0.99941873 8,0.999781Z m0,2c3.242467,-0.1231148 5.848576,3.4193109 4.776682,6.477601 -0.841211,3.131959 -4.9939918,4.58038 -7.5998944,2.649077C2.4322236,10.397214 2.2765833,6.0022025 4.8919502,4.0831465 5.7667487,3.38528 6.8811016,2.996997 8,2.999781Z' fill='%23868686' /%3E%3C/svg%3E");
   +}
   

   It was decided Claro would stop inlining SVGs in CSS in #3083657: Devise strategy to address several SVG loading+usage issues. Any new SVG background-image styles should reference a file.

   For reference, this is being applied to all existing inline SVG usages in this issue: #3085245: Un-inline SVGs in pcss.css files, add build tool to inline them when compiled

Addresses my feedback in #36, and expanded some needed autocomplete RTL rules.

+++ b/core/themes/claro/css/components/autocomplete-loading.module.pcss.css
@@ -26,25 +26,54 @@
+  padding-right: var(--autocomplete-icon-padding--small); /* LTR */

These padding-right properties make the autocomplete fields wider and not aligned with text fields in their vicinity.

Maybe adding something in each case like the following would compensate? (I think this does it in this instance):

  max-width: calc(100% - var(--autocomplete-background-width--small) - var(--space-xs) - var(--input-border-size));

Current:

With max-width:

Good suggestion in #38
The main patch for this removes the node form override since this is possibly close to completion, but it's still provided in a second manual-review-facilitating patch with the do-not-test wording so the testbot doesn't bother with it.

This is looking really good! Though, at smaller breakpoints, the background width adjustment doesn't work, so there will need to be a variation for those. Or, the above changes should only apply to larger breakpoints?

This addresses #40
In earlier patches, the magnifying glass adjustment also included a fix for a prexisting issue in both Claro and Seven, where an input's content area continues underneath the magnifying glass icon.

What I didn't realize until attempting to address #40 is that this solution does not work consistently at all widths, even after accounting for smaller breakpoints like the scenario discovered in #40

So, the overflow/icon bug will not be addressed here, but I created a followup issue to address it: #3163127: Autocomplete input text can visibly overflow under magnifier icon

This patch also:

• brings back the form_alter() on node forms to make this easier to review
• Adds small/extrasmall selectors for .touchevents. Previously these were only present on .no-touchevents. When using Chrome's device simlulator, the form input sizes would not change. For .touchevents, small and extrasmall both receive the styling for small, as extrasmall would be too small of a target area for touchscreen users

@katherined pointed out that small/extrasmall autocomplete inputs do not consistiently match the width of other inputs of the same size, when at screen widths under 600px. Discovered this was due to the autocomplete wrapper class being set to display: inline-block;, which can be removed at narrower widths since the input is supposed to occupy the full width of the form anyway.

I've looked through this in Firefox, Chrome and IE 11, and it looks great in all. I went over the patch, including manually testing a few things I wasn't clear about, and I don't see anything else to comment on.

I've removed the test fields from the patch again, but this patch is otherwise identical to #42. I'm including an interdiff for clarity.

Per the conversation in #3085245-24: Un-inline SVGs in pcss.css files, add build tool to inline them when compiled, I think we should move the icons to the theme file.

Good catch with #45 - I've kicked back a few tickets for the very same thing and missed it on my own, so thanks for noticing that 🙂.

I think it's ready!

1. +++ b/core/themes/claro/css/components/form--select.pcss.css
   @@ -5,28 +5,53 @@
   +  --select--background-image-height-width-ratio: 0.642; /* SVG background image has width:14px height:9px. 9 / 14 = .642 */
   +  --select--background-image-width: var(--space-m);
   +  --select--background-image-height: calc(var(--select--background-image-width) * var(--select--background-image-height-width-ratio));
   +  --select--background-image-width--small: var(--space-s);
   +  --select--background-image-height--small: calc(var(--select--background-image-width--small) * var(--select--background-image-height-width-ratio));
   +  --select--background-image-width--extrasmall: var(--space-s);
   +  --select--background-image-height--extrasmall: calc(var(--select--background-image-width--small) * var(--select--background-image-height-width-ratio));
   

   Based on the variable naming pattern documented here https://www.drupal.org/docs/8/modules/claro/claro-css-coding-standards#s..., shouldn't these start with --select-background-image?

2. +++ b/core/themes/claro/css/components/form--select.pcss.css
   @@ -5,28 +5,53 @@
   +.no-touchevents .form--small .form-element--type-select,
   +.no-touchevents .form-element--type-select.form-element--small {
   ...
   +.no-touchevents .form--extrasmall .form-element--type-select,
    .no-touchevents .form-element--type-select.form-element--extrasmall,
    .no-touchevents .form-element--type-select[name$="][_weight]"] {
   

   Should't these styles be applied regardless of the touchevents to be consistent with the generic form styles?

3. +++ b/core/themes/claro/css/components/form--text.pcss.css
   @@ -19,12 +19,26 @@
   +.touchevents .form-element[name$="][_weight]"] {
   

   What is this for? I noticed it has been used before but I couldn't figure out quickly where to test this.

#48.1
Yes, the naming convention needed to be changed.

#48.2
This was building from an existing pattern, but I wasn't aware of what the reasoning was until reviewing #3021094: File field style update. The goal of this was to meet AAA guidelines by having a minimum height of 44px, described in Success Criterion 2.5.5: Target Size. This will need to get accessibliity review, but this patch allows touch devices to get --small styling, but --extrasmall will be styled as --small. The input/select/button height is 32px, which based on informal inquiry seems to be acceptable for applications not aiming for AAA, provided the inputs are sufficently distanced from each other. In addition, for form items with labels above them, the click area turns out to be 44px high at --small. Not allowing some form of smaller form elements on touch devices results in cognitively challening forms due to the limited context available within the viewport, so I'm inclined to adopt an approach that is not-quite-AAA but not so small to be error prone.

#48.3

The .touchevents .form-element[name$="][_weight]"] selector was for targeting the "weights" select field in multivalue file fields. Every element in this widget was targeted individually to make is smaller. This is no longer needed now that this patch provides a .form--extrasmall parent class, which I added to the widget and removed the individual styles.

I also added a .form--extrasmall to the block admin form, which was previously targeting individual items and neglected to include the weights dropdown.
Before:

After:

Tagging

Reroll since the postcss svg inline build tool has been added.

This won't pass WCAG 2.1.5 (AAA criteria) unless the label can be counted to the target size. The criteria is not explicit on that and I asked @andrewmacpherson on Slack and he wasn't sure either, but he said that it probably should be taken into account when measuring the target size.

However, there is a WCAG 2.2 draft which adds a new criteria 2.1.8 which is an AA requirement. It has slightly relaxed rules compared to 2.1.5 so that space between elements can be taken into account when assessing the target size. I think the current design and implementation passes that criteria.

From my point of view, at least with the current usages of the extra small variation, it seems we have a large enough target size even though we aren't necessarily compliant to a strict interpretation of the WCAG 2.1.5.

#52 Addresses my accessibility concerns, particularly since this included a discussion with an accessibility maintainer. The new criteria 2.1.8 in draft 2.2 puts me at ease regarding future AA compliance. I had also been under the assumption that labels would be included as part of this height. It hadn't occurred to me until now that factoring labels into target height is not formally defined/refuted, but glad to see that the more-credible @andrewmacpherson had a similar suspicion that it would be.

+++ b/core/themes/claro/css/components/button.pcss.css
@@ -67,21 +67,30 @@
+/**
+ * On touch devices, extrasmall receives small styling in order to provide
+ * adequate target height.
+ */
+.button--small,
+.form--small .button,
+.touchevents .button--extrasmall,
+.touchevents .form--extrasmall .button {
   margin: var(--space-s) var(--space-xs) var(--space-s) 0; /* LTR */
   padding: calc(var(--space-xs) - 1px) calc(var(--space-m) - 1px); /* 1 */
   font-size: var(--font-size-xs);
 }

1. It looks like this pattern should be applied to dropdown buttons too?

+++ b/core/themes/claro/src/ClaroPreRender.php
@@ -17,7 +17,6 @@ class ClaroPreRender implements TrustedCallbackInterface {
-      $element['remove_button']['#attributes']['class'][] = 'button--extrasmall';

2. I'm not 100% sure why this is changed, but I can see why it would be a good idea to leave this up to the various forms instead of making these buttons extrasmall everywhere. But then maybe the single file upload needs a template override?

Would be great to be able to apply to big tables

Example in #3167829-3: Remove columns with %

#54.1 Yep, even if it wasn't in the issue summary, dropbuttons need to be included as they'll be sharing forms and table rows with small/extrasmall variants. Not matching them makes the UI feel broken. On touch devices, the toggle button has an increased width of 44px on small/extrasmall so it's a sufficient target size. Screenshots of every possible variation I can think of attached. To test the variants manually, I provided a dropbutton-markup-for-testing.txt which can be pasted into any page that loads the dropbutton library. This has all size variants, both the specific classes and the form--small, form--extrasmall wrapper classes. Obviously the JS won't work for this pasted-in markup, but it displays everything that was restyled in the patch.

#54.2
The change was made because the weight dropdown (only present in multiple item widgets) was already set to extrasmall, so the wrapper was changed so the adjacent form elements match. When multiple items are present it also seems beneficial to save space overall so the list of items doesn't overwhelm the surrounding context.

I opted to not do this for single item widgets because there is no weight dropdown that needs to be matched with, and there's less need to conserve space when only a single item is present.

I just found a few small things testing in Chrome, Firefox and IE 11.

1.

+++ b/core/themes/claro/css/components/dropbutton.pcss.css
@@ -246,20 +286,32 @@
+.form--extrasmall .dropbutton__item:first-of-type > input,
+.dropbutton--extrasmall .dropbutton__item:first-of-type > input {
+  margin-top: 0;
+  margin-bottom: 0;
+}
+

Looks like the dropdown/adjacent menu items also need this margin. Something like .form--extrasmall .dropbutton__item:first-of-type ~ .dropbutton__item > input

In IE 11, the default and small variants also have a similar, additional issue.

2.

+++ b/core/themes/claro/css/components/dropbutton.pcss.css
@@ -370,7 +422,13 @@
-.no-touchevents .dropbutton--small .dropbutton__item:first-of-type ~ .dropbutton__item > .button {
+.no-touchevents .dropbutton--small .dropbutton__item:first-of-type ~ .dropbutton__item > .button,
+.touchevents .dropbutton--extrasmall .dropbutton__item:first-of-type ~ .dropbutton__item > a,
+.touchevents .dropbutton--extrasmall .dropbutton__item:first-of-type ~ .dropbutton__item > .button,
+.no-touchevents .form--small .dropbutton__item:first-of-type ~ .dropbutton__item > a,
+.no-touchevents .form--small .dropbutton__item:first-of-type ~ .dropbutton__item > .button,
+.touchevents .form--extrasmall .dropbutton__item:first-of-type ~ .dropbutton__item > a,
+.touchevents .form--extrasmall .dropbutton__item:first-of-type ~ .dropbutton__item > .button {
   padding-top: var(--dropbutton-small-spacing-size);
   padding-bottom: var(--dropbutton-small-spacing-size);
   font-size: var(--dropbutton-small-font-size);
@@ -378,7 +436,9 @@

Missing .touchevents small variants. The dropdown menu items will still get the default styles on touch devices.

3. The extrasmall variant jumps a bit/widens when the menu item is wider than the button:

#58.1 fixed
#58.2 Addressed a bit differently. That made me realize that the list items did not have sufficient height for touch device accessibility, so .touchevents dropbutton items now get the same style regardless of variant. The button itself can afford to be a bit smaller as surrounding space can (probably, no official spec exists yet) can be factored into the target region. The list items are adjacent, though, so they should be at least 44px high.
#58.3 This is one of the quirks dropbutton is most famous for, and among the reasons it's getting replaced with splitbutton 🙂 It happens more often on smaller variants since less word is needed to exceed the padding + toggle. #1890266: dropbutton text fails to retain .dropbutton-widget width

This is a small thing:

+++ b/core/themes/claro/css/components/dropbutton.pcss.css
@@ -306,8 +306,10 @@
+.dropbutton__item:first-of-type > input.button,
+.dropbutton__item:first-of-type > input.button,

duplicate line

And I'm still seeing seeing something like this in IE, on all sizes (and I'm not even sure it's a deal-breaker):

Otherwise, it looks good! I love the approach for #58.2.

This patch removes the duplicated line

The IE11 issue happens in HEAD as well, so out of scope in this patch. I filed an issue for it.
#3169141: IE11: background is visible in space between secondary dropbutton items

Thank you! You've fully addressed everything I have seen, so marking as RTBC.

1. +++ b/core/themes/claro/claro.theme
   @@ -679,11 +679,21 @@ function claro_form_views_exposed_form_alter(&$form, FormStateInterface $form_st
   +function claro_form_block_admin_display_form_alter(&$form, FormStateInterface $form_state) {
   +  $form['#attributes']['class'][] = 'form--extrasmall';
   +}
   

   We should expand this to other tables. I would be fine if that was done in a follow-up.

2. +++ b/core/themes/claro/css/components/dropbutton.pcss.css
   @@ -168,20 +199,29 @@
   +  width: 2.75rem;
   

   The 2.75rem width makes the toggle look misshapen. I think we should implement this according to the designs here. We could try to make the dropbutton/splitbutton AAA compliant in a follow-up.

3. +++ b/core/themes/claro/css/components/views-exposed-form.pcss.css
   @@ -58,3 +64,12 @@
   +/**
   + * If touch events are active, the button will be taller than other inputs in
   + * the form. Setting the width to 100% ensures it is on its own line so the
   + * button's height difference does not appear incongruous.
   + */
   +.touchevents .views-exposed-form__item--actions {
   +  width: 100%;
   +}
   

   Is this still needed now that buttons are rendered using small variant on touch devices? I'm not saying that it wouldn't make sense to have this rule but that the reasoning might not make sense anymore.

#64.1 Created followup #3169690: [PP-1] Add form--extrasmall class to forms with operations dropbutton
#64.2 Wide toggle removed, followup created: #3169699: [PP-2] Investigate touch-friendly target size for dropbutton/splitbutton toggle
#64.3 Good call, that is no longer needed and it is now removed.

It was pointed out in #3029675: Add support for the inline variation of form elements that a wrapper class used for styling all form elements was applying a modifier a nonexistent base class. That concern also applies to the .form--small and .form--extrasmall wrapper classes applied here, so those have been changed to classnames without a modifier.

Now after these changes I'm wondering how strictly we should follow the BEM guidelines. It feels like the form level size and inline variations would go against the principles of BEM.

Block styles are never dependent on other elements on a page, so you will never experience problems from cascading.

http://getbem.com/introduction/

It's certainly a nice to have feature, but it does add some complexity to the CSS. I'm certainly not sure which way is better so I'd love to hear what others think.

The patch in #66 looks good to me, and I'd say it's ready to RTBC again, pending any additional thoughts on the BEM approach.

If we're not strictly following the spirit of BEM, then I don't have a strong preference either way, but I do have a slight preference for the most recent change now that I see it. form-elements-small seems a little more precise, and it's consistent with the latest patch in #3029675: Add support for the inline variation of form elements, so I'd probably leave it as-is.

See #3029675: Add support for the inline variation of form elements for an explanation regarding why I see the benefit of slightly deviating from BEM by providing wrapper classes for that would style all elements inside a form.

The very thorough explanation in #3029675: Add support for the inline variation of form elements is enough to convince me, and in particular, the current approach prevents the need for excessive form alters on things like the media library specifically, or any other form displayed in a dialog.

I also especially appreciate addressing the benefit to contrib maintainers:

With the wrapper class, the added elements integrate with the rest of the form automatically. Contrib maintainers don't need to devote dev time to adding Claro classes, and there's less risk of poor sentiment towards Claro because contrib modules don't look right in it.

Tested #66 and looks good on 9.1
This can be moved to RTBC

Per @lauriii in #3029675-48: Add support for the inline variation of form elements, we should proceed here with this issue, but also follow up here: #3170928: Add form variants to the Form API and #3170933: Use Form API to implement form variants

We thought that the next steps could be:

Go ahead here and #3083256: Create smaller variations for form elements but add some documentation to Claro to state where and why we deviate.
File a follow to address the issue in Form API.
FIle another follow-up to use Form API changes in Claro if necessary.

This takes care of the final suggestion from [#13822587-13822587]

add some documentation to Claro to state where and why we deviate.

Fixed typos from previous patch.

Everything I've seen has been fully addressed. Marking as RTBC. :)

The patch adds few usages of the small variations of form elements and it feels like some of the pages become inconsistent because different forms / sections of forms use different size variation. For example, multiple file upload is now using the small form elements which could be placed in node form where rest of the form elements are using the normal variation. Also, the views filters are using the small variation, but bulk operations are using the normal variation. Should we at least provide more guidance on how different variations should be used?

I’m also wondering if we should prefix these utility classes with claro- for now to make it explicit that they are specific to Claro.

The issue summary has been updated so it documents all things that are changed. The multiple file element widget is no longer being changed in this patch, nor are the styles that target [name$="][_weight]"] selector as those must be present to keep the extrasmall styles on the multiple file widget if the wrapper class isn't used.

This expands the small form element styling to the views bulk operations form as suggested in #76

This also adds the claro- prefix to the wrapper classes.

Discussed this with @ckrina and @katherined at length yesterday. The concern with 3 variations is that it requires very strong rules around where each of the variations should be used because when the variations are used incorrectly, it can make elements look unproportionate. For example, the button looks extremely large compared to the select:

Another example of this can be seen with #74 applied. In this example you can see all different size variations on a single page:

I was curious to know how other design systems define how their size variations should be used. I looked at Carbon, Material UI and Bootstrap and I didn't find any examples of size variations from them.

This made me wonder why do we need three variations of form elements if the competing design systems only define one. I didn't come to conclusion on that, but I started wondering if some of it was due to the normal variation of the form elements being too large for most use cases outside of the entity edit form, and if the solution should be to make changes to the default variation so that it could be used variety of use cases.

Perhaps someone who was present for the discussion in #78 can clarify what next steps should be (or at the very least, what next steps have been ruled out)?

The two types of approaches that come to mind fall into two broad categories:

• Rescoping this issue and updating the issue summary with the new requirements
• Largely retaining the scope of this issue and addressing the concerns in #78 in a followup.

Was one approach or the other determined to be the preferred one? If there was no clear preference, I suppose that will need to be figured out to unlock the multiple stable blockers currently depending on either this or an equivalent solution.

I'm partial to the second approach since Claro is not currently Stable nor does it have a BC promise and the postponed issues wouldn't need to wait on potentially lengthy design discussions. This opinion may also be influenced by the amount of time I put into the issue so far, so my objectivity is debatable.

As far as I know, @ckrina is working on new design spec that would reduce the size variations to two. We are planning to discuss this again tomorrow on the Claro weekly meeting. I'm hoping that after the meeting we have clarity on how we should proceed on this issue.

Here's a version with two variants instead of three, as discussed. From a brief manual review, it seems like extrasmall may not be needed. It's possible something like Views could require it, but Views already needs a decent amount of custom styling. A nice advantage of this approach is every variant is tall enough for touchscreen, provided there is whitespace above/below.

I still get the feeling that the default form input sizes could still be a little smaller, but that possibility has more to do with my personal preferences.

This looks pretty good! I just found a few things.

1.

+++ b/core/themes/claro/css/components/autocomplete-loading.module.pcss.css
@@ -26,18 +26,47 @@
+  background-position: calc(100% - var(--space-xs) - (var(--input-border-size) * 2)) 50%; /* LTR */

Missing RTL

+++ b/core/themes/claro/css/components/autocomplete-loading.module.pcss.css
@@ -67,19 +66,6 @@
-.js[dir="rtl"] .claro-form-elements-small .form-autocomplete,
-.js[dir="rtl"] .form-autocomplete.form-element--small {
-  background-position: calc(var(--space-xs) - (var(--input-border-size) * 2)) 50%;
-}

This should be restored.

2. Remove "extrasmall" in a few places:

+++ b/core/themes/claro/css/components/dropbutton.pcss.css
@@ -167,19 +166,22 @@
+ * `Small and extrasmall variants.` that appears earlier in this file.

+++ b/core/themes/claro/css/components/dropbutton.pcss.css
@@ -204,10 +206,15 @@
+   * `Small and extrasmall variants.` that appears earlier in this file.

+++ b/core/themes/claro/css/components/dropbutton.pcss.css
@@ -245,19 +252,26 @@
+ * `Small and extrasmall variants.` that appears earlier in this file.

+++ b/core/themes/claro/css/components/dropbutton.pcss.css
@@ -368,23 +382,27 @@
+ * `Small and extrasmall variants.` that appears earlier in this file.

3.

+++ b/core/themes/claro/css/components/form--select.pcss.css
@@ -29,7 +27,7 @@
  * On touch devices, extrasmall receives small styling in order to provide
  * adequate target height.

This can be removed

The changes here are based on #83. I made these changes in hopes of advancing the issue, but it should be noted that the requirements of the issue haven't "officially" changed and this should be viewed more as a proof of concept to help confirm the new approach is a good one.

This should get an issue summary update with the new agreed-upon specs before any additional reviews happen, so those reviews can be checked against the current requirements.

Adding NorthAmerica2021 and Easy Out of the Box tags for visibility.

DrupalCon NA is April 12-16 with a focus on EOOTB on Wednesday, April 14.
Thanks

#84 Patch Failed

#93 Please review the patch

Attached patch. Added interdiff for same.

Tagging for Design4Drupal 2021. Contributions are Friday, July 22
https://design4drupal.org/

Correcting tag Design4Drupal2021

Adding tag for DrupalCon Europe 2021. Thanks

Adding tag for DrupalCon Europe 2021. Thanks

Tagging for Global Contribution Weekend since this only needs minor CSS work to get this over the finish line.

I assumed the changes had to be rebased onto 9.4.x because that is the current active development branch. I did that, force pushed and thus added 1000 commits... That broke the MR and I can't change the MR destination branch (from 9.3.x to 9.4.x) so I rebased the changes on 9.3.x, force pushed and the MR is mergeable again. Sorry for the issue noice -_- .

When polishing the Paragraphs UI from Claro, we realized that the Core extrasmall button component has inconsistent height padding that makes these buttons inacceptably tiny (both top and bottom vertical padding 3px instead of 5px or 6px.).

The proposal here fixes this problem. I would love to see extra small buttons cleanly implemented by Core.

I think this is a WCAG 2.5.1 issue as per https://knowbility.org/blog/2018/WCAG21-251PointerGestures/

WCAG 2.1.5 and not 2.1.8

https://www.w3.org/WAI/WCAG21/quickref/?currentsidebar=%23col_overview
https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/

Gonna work on it.

Extra-small creates usability/accessibility issues for me. I created #3412439: Give users option to override Claro --font-size-xs and --font-size-xxs with --font-size-s, which I believe would also apply to the current issue.