Add support for the inline variation of form elements

Let me check how this can be done...

It seems that in core, the form elements with inline label are controlled by adding the container-inline class. But the actual approach is not standardized and sometimes it causes invalid markup.

Result of my research of container-inline usage:

Explanation of Effect type column:

• Direct

means that the HTML class is added directly to the form element's #attributes array (here I mean the form_element theme wrapper)

• Indirect

means that the form element's content (label, input, prefix/suffix and description as well) is rendered inline because some of it's parent wrapper has the HTML class container-inline

1. To handle the direct cases the fastest solution is to check that the form_element has the container-inline class and if it has, we can replace it with a form-item--inline class (that would be the inline variation's modifier class).
   
   

2. Indirect cases — I feel that some of them could be replaced by a combined usage of form--inline module (see #2417111: Replace container-inline with form--inline to display forms horizontally.) and our new form-item--inline modifier.

   The form--inline CSS module makes a set of form items (form__elements) inlined, and this is the right approach IMHO since its not so general like the container-inline module is.

   In the described case, the best solution would be to add some API for inline form items right in core, and reduce the usage of container-inline as much as possible...

We need the inline form item design extended with a description, a prefix/suffix and an error message.

Postponing until we get the design done.

Updated text inputs prefix

Fixed failed tests

Before additional patch-making, the IS should be updated so the scope is clear (and clearly not prefix/suffix related)

Updated the image and the focus on the Issue Summary. Ready to resume the work.

Here's a test module that provides a form at inline-form-element-test with inline text, radio, checkbox and textarea fields.

Forgot to include a select element in the previous patch. Use this one instead.

This is a start but definitely needs more work- anybody is welcome to pick up from here.

1. One of the approaches in #7 probably needs to be implemented. This patch unloads all core css that targets .container-inline and replaces it with custom claro styles for .container-inline and its decendants. If others think that claro-custom styles for .container-inline are acceptable
2. Per #8: The InlineElementForm in the test module needs to be expanded to cover errors and probably prefix/suffix ( if prefix/suffix is suitable for inline form elements, we'd need designs for that)
3. The bar with a select that is seen when previewing a node is not pleased with this change (but not sure how good it looks in claro overall)

Screenshots attached of container-inline usage with the new styles.

Note that there is more markup than the old use of container-inline, but it also doesn't have the excessive side effects of the ruthless wildcard usage in core's container-inline styles

This is a mountain of screenshots that will be given more context in a followup comment. Uploading them here to make the comment-making a little easier.

A screenshot is attached that includes inline form errors. Those are not currently covered in the design, so if they don't look right here then some design input will be needed to determine how they should be displayed.

This patch has some refactoring and additional styling to account for all the use cases in #6 (other than views, which is being handled in #3066006: Convert Views UI to new design system). There's a bit of edge-casing going on, but may still be preferable to the edge-case-riddled approach of setting .container-inline * {display: inline}

Had to account for ConfirmClassyCopiesTest

Note that the styling of inline image resolution fields such as the ones found at admin/structure/types/manage/article/fields/node.article.field_image won't look ideal until #3082672: Form prefix/suffix redesign in Claro. There is SO much to review that there's no reason to changed the status to postponed waiting on that issue. Several iterations will likely take place before that's the final item before completion.

*1 of 4 : patch and basic screenshots*

There's a large amount of information needed to properly review/implement/discuss this patch so this will be provided in four comments to make things easier to mentally organize (and type)

This patch builds on #28 addressing several things I spotted in review. The results can be seen in the screenshots.

The next comments will cover the use cases identified in #6, contrib modules that may be impacted by this change, and a suggested approach for error messages.

*2 of 4: use cases in #6*

Several of the items in #6 don't need to be in scope. Several are in themes, and the views items are being addressed in #3066006: Convert Views UI to new design system.

Action

https://www.drupal.org/files/issues/2020-07-17/Action-inline.png

Content Moderation

https://www.drupal.org/files/issues/2020-07-17/ContentModeration-inline.png

Editor (maximum dimensions)

https://www.drupal.org/files/issues/2020-07-17/EditorImageMaxDimensions-...

Editor (dialog radios)

https://www.drupal.org/files/issues/2020-07-17/ImageDialogAlign-inline.png

Field UI

https://www.drupal.org/files/issues/2020-07-17/FieldStorageConfigEditFor...

Image (shows both items listed)

https://www.drupal.org/files/issues/2020-07-17/ImageItem-minmaxResolutio...

Locale (the filter button is in container-inline ,but has no effect. This is the same in HEAD)

https://www.drupal.org/files/issues/2020-07-17/Translate-FilterButton-no...

Path

https://www.drupal.org/files/issues/2020-07-17/PathFilterForm-inline.png

Search (SearchPageForm)

https://www.drupal.org/files/issues/2020-07-17/Search-keywords-inline.png

Search (SearchPageListBuilder)

https://www.drupal.org/files/issues/2020-07-17/SearchPageListBuilder-inl...

Workspaces

https://www.drupal.org/files/issues/2020-07-17/WorkspaceSwitcher-default...

Comment

https://www.drupal.org/files/issues/2020-07-17/Comment-inline.png

Dblog (the filter button is in container-inline ,but has no effect. This is the same in HEAD)

https://www.drupal.org/files/issues/2020-07-17/Dblog-FilterButton-nothin...

3 of 4: Contributed modules that may be impacted
I used http://grep.xnddx.ru/ to find uses of container-inline and form--inline. If a module uses those classes in a way that is clearly covered by this patch, I did not include it in the list. I separated the remaining modules into two buckets.

The modules in the first list should probably be notified that their use of container-inline or form--inline may have unexpected impact in Claro. Those classes (particularly container-inline) were too powerful in their reach which led to frequent unwanted side effects. The inconvenience presented here will reduce larger ones in the future.

Modules that either have D9 support or have enough evidence of usage/recent activity to suggest a D9 version is likely to be available

(I'm aware the site metrics for a module are not particularly accurate, this is just used to see which modules comparatively appear to have higher usage)

uses container-inline

• https://www.drupal.org/project/collageformatter
• https://www.drupal.org/project/owlcarousel2
• https://www.drupal.org/project/entity_delete
• https://www.drupal.org/project/imagepin
• https://www.drupal.org/project/lingotek (could not evaluate as it requires a lingotek account, but this is a very widely used module)
• https://www.drupal.org/project/skinr
• https://www.drupal.org/project/twig_field
• https://www.drupal.org/project/unlimited_number
• https://www.drupal.org/project/elastic_email (242 users)
• https://www.drupal.org/project/commerce_inventory (also uses form--inline possibly unused, no D9, last updated 2018)

uses form--inline

• https://www.drupal.org/project/commerce_product_bundles
• https://www.drupal.org/project/entity_reference_quantity (just a dev version but 201 sites report using)
• https://www.drupal.org/project/give
• https://www.drupal.org/project/better_exposed_filters
• https://www.drupal.org/project/content_planner (no d9 but recent activity and 167 sites)
• https://www.drupal.org/project/entityqueue
• https://www.drupal.org/project/monitoring
• https://www.drupal.org/project/paragraphs_collection
• https://www.drupal.org/project/simple_entity_translations
• https://www.drupal.org/project/simple_survey (no d9, but very recent, 27 sites)
• https://www.drupal.org/project/views_link_attributes (no d9, but very recent, 36 sites)
• https://www.drupal.org/project/watchdog_delete_filter (no d9, but very recent, 27 sites)

No Drupal 9 support +minimal usage and no recent activity

container-inline

• https://www.drupal.org/project/affiliates_connect
• https://www.drupal.org/project/alexanders
• https://www.drupal.org/project/backup_permissions
• https://www.drupal.org/project/bs_inventory
• https://www.drupal.org/project/care
• https://www.drupal.org/project/commerce_admin_checkout
• https://www.drupal.org/project/commerce_amws
• https://www.drupal.org/project/competition
• https://www.drupal.org/project/druminate
• https://www.drupal.org/project/dsc
• https://www.drupal.org/project/dvf
• https://www.drupal.org/project/design (container-inline only used in tests)
• https://www.drupal.org/project/date_recur_interactive (272 sites use but minimal support and module acknowledges bugs and recommends an alternative)
• https://www.drupal.org/project/datex (no longer maintained, merged into calendar_systems module)
• https://www.drupal.org/project/entity_gallery
• https://www.drupal.org/project/entity_jump_menu
• https://www.drupal.org/project/entity_library
• https://www.drupal.org/project/jvector
• https://www.drupal.org/project/log_monitor
• https://www.drupal.org/project/loopit
• https://www.drupal.org/project/openlms
• https://www.drupal.org/project/prepared_data
• https://www.drupal.org/project/qr_decode
• https://www.drupal.org/project/quadruple_field
• https://www.drupal.org/project/scheduled_maintenance
• https://www.drupal.org/project/twinesocial
• https://www.drupal.org/project/uaparser
• https://www.drupal.org/project/unix_time_conversion
• https://www.drupal.org/project/widget_engine

form--inline

• https://www.drupal.org/project/availability_timing
• https://www.drupal.org/project/dea
• https://www.drupal.org/project/ot
• https://www.drupal.org/project/seeds_layouts
• https://www.drupal.org/project/aframe

4 of 4: how to best proceed
Some concerns:

Inline form errors could stand to look a little better

I noticed errors weren't in the design so I shared some screnshots in Slack. @ckrina thought that they were largely fine, but the error message should be aligned with the corresponding input and not its label. I like this suggestion as well, but it would require some major refactoring. I think this would work best in a followup issue because
1) The alignment is no different in Seven, so this patch does not cause a regression even though it could be argued the alignment difference is more noticeable in Claro.
2) No new problems are introduced with the current scope, and this current scope is already quite complex due to the variety of ways .container-inline can be used.

The solution seems to include many bandages

The .container-inline class was a bit too powerful and had many unwanted side effects. Look at that +2 specificity determining the display of all child divs and labels

.container-inline div,
.container-inline label {
  display: inline-block;
}

It was applied in a variety of ways that makes it incredibly difficult to remove/change the class in preprocess functions, particularly if contrib is taken into account. The approach in patch #30 does a bit of edge-casing when a broader solution like #3059593: Provide API for inline containers is more ideal. I think the approach in this patch is a step towards the feasibility of #3059593 landing. The changes here expose the use cases that would need addressing, and the CSS here can be repurposed.

Discussed this with @lauriii, and these changes should address the majority of the concerns in the previous four comments.

The contrib concerns in #32 are addressed as the expected .container-inline and .form--inline is now unchanged. There are already issues to address my primary concerns about those old issue, and it was pointed out that those concerns aren't quite as bad as I thought. This patch does add an alternative to the somewhat far-reaching .container-inline styling. A form can also add the class .form--inline-elements, which will inline-style every item in the form without the many side effects of the far-reaching .container-inline style on an entire form. An example of this in use was added to the form in the test module.

The concern about the bandage-ish approach in #33 is also resolved for the reasons stated above.

Screenshots

Test Form

This is labeled, but the first half are items individually wrapped in .container-inline the second half is a group of items wrapped in a container with the .form--inline-elements class.
https://www.drupal.org/files/issues/2020-07-28/inline-form-RTL-narrow.png
https://www.drupal.org/files/issues/2020-07-28/inline-form-RTL-wide.png
https://www.drupal.org/files/issues/2020-07-28/inline-form-narrow.png
https://www.drupal.org/files/issues/2020-07-28/inline-form-wide.png

IE11

https://www.drupal.org/files/issues/2020-07-28/form--inline-elements-add...
https://www.drupal.org/files/issues/2020-07-28/container-inline-plus-for...
https://www.drupal.org/files/issues/2020-07-28/container-inline-IE11-mob...
https://www.drupal.org/files/issues/2020-07-28/form--inline-elements-IE1...
https://www.drupal.org/files/issues/2020-07-28/container-inline-IE11-wid...

Other uses

Action

https://www.drupal.org/files/issues/2020-07-28/Actions.png

Comment

https://www.drupal.org/files/issues/2020-07-28/Comment_.png

Content Moderation

https://www.drupal.org/files/issues/2020-07-28/content-moderation.png

Dblog

https://www.drupal.org/files/issues/2020-07-28/Dblog-same_as_HEAD.png

Editor

https://www.drupal.org/files/issues/2020-07-28/EditorImageDialog.png
https://www.drupal.org/files/issues/2020-07-28/maximum-dimensions-editor...

Field UI

https://www.drupal.org/files/issues/2020-07-28/AddField.png

Image

https://www.drupal.org/files/issues/2020-07-28/ImageItem.png

Locale

https://www.drupal.org/files/issues/2020-07-28/Locale_same_as_HEAD.png

Node

https://www.drupal.org/files/issues/2020-07-28/NodePreview_same_as_HEAD.png

Path

https://www.drupal.org/files/issues/2020-07-28/PathFilterForm.png

Search

https://www.drupal.org/files/issues/2020-07-28/SearchPageForm.png
https://www.drupal.org/files/issues/2020-07-28/SearchPageListBuilder.png

Search Block + Workspaces Block

https://www.drupal.org/files/issues/2020-07-28/SearchBlock_WorkspacesBlo...

Rerolled

Addressing #37:

1. I've reorganized in a way that made sense to me, so hopefully it's not just me. :)

2. Got it, and then moved it.

3. Got these, and also moved them.

Ah, good idea. Test removed, and patch rerolled.

Test failure was an unrelated test infamous for intermittently failing

#43.1 Good call, moved these styles to field UI and opened an issue suggesting the same be done to all the instances outside of Claro #3169719: Move .form-inline .form-item-separator rules from inline-form css to field UI css
#43.2 That styling is already present in #3082672: Form prefix/suffix redesign in Claro, but it's not clear which will be added first so it'll go here as well and reroll as needed.
#43.3 Follow-up for aligning the description and error messages with the form element: #3169723: [PP-1] description and (inline)errors in inline forms should align with their element
#43.4

.form--inline-elements looks like it would be applying the BEM modifier pattern, but I don't think we have form block element?

Shoot, that makes the class a little less self-explanatory, but it's true it should not follow the modifier pattern. Changed that here and will need to do that in #3083256: Create smaller variations for form elements as well.
#43.5

Is this utility class something that should be supported outside of Claro?

I'm sure that could be helpful throughout core. I created an issue for it: #3169734: [PP-1] Implement something similar to Claro's form-elements-inline class in all of core

It may help to have a summary of the BEM issues being discussed in #43 and #44:
This issue and #3083256: Create smaller variations for form elements deal with creating form element variants. Currently, form elements receive variant styles by adding a class directly to the form element render array. The currently patches in this issue and #3083256: Create smaller variations for form elements offer a different way to provide variant styling to form elements: add a single wrapper class to the form, which will style every element within.

In the case of this issue, this would make is possible to present every element within a form as inline by adding the single .form-elements-inline class to the form. Similarly , issue #3083256 proposes adding a wrapper class so all elements within a form can be styled as their small/extrasmall variants.
At the moment I feel like the benefits of this approach outweigh the drawbacks of deviating from BEM. Were this approved for core, I'd still want to specifically document why the exception was made and why it should not be seen as an overall loosening of a standard that has proven beneficial.

Here are some of the specific reasons I support the approach, perhaps there are specific holes in the logic.
Prevents unwieldy form alters
Without the wrapper classes, providing variant styles to every element in a form means explicitly adding a class (and in the case of inline form elements, some element types require to to be added a #prefix/#suffix or #theme_wrapper). This results in some very busy form_alters to accomplish what a single wrapper class could, and I'm skeptical of it being possible to address this through any sort of helper function that recursively traverses the array to add these classes, due to the application of these classes differing depending on element type and other contexts that are less predictable.

Contrib modules aren't expected to do Claro-specific class additions.
Many contrib modules add elements to existing forms. Without the variant-facilitating wrapper class, contrib modules will need to add Claro-specific classes to every added form element. 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.

There is a greater need for form element variants in Claro, which increases the need for an easy way to apply them

Claro's form elements are very large, which benefits the user in many ways. There are contexts, however, where this large size is detrimental, such as when they appear in a dialog or views filters. There's already agreement that in contexts such as these, it's useful to use smaller variants within the entire form. Making this possible via the addition of a single class seems far preferable than the form_alter headaches mentioned above.

This provides an easy way to have context-dependent form element variants
For example, a form can easily use default styling in a page, and smaller variants inside a dialog.

Some elements are not easily alterable
In cases like views, where there are form elements that are not inside an actual form array, it's not always straightforward (or possible?) to add classes to specific elements. While it's true that theoretically all of these should be alterable and issues could be filed for each need, it's a plate of vegetables that are at risk of spoiling before they are fully eaten. A variant-facilitaing wrapper class makes this a non-concern.

Additional thoughts
Seeing a form element as part of a form vs being a discrete block is likely the way many of us conceptualize things already. While BEM effectively prevents unpredictable behavior, in the case of form elements, I don't feel like it would be particularly jarring for a form element to assume the variant state of its constituent elements vs retaining it's block-level styles. I think that core's BEM policy could define an exception specific to forms and their elements.

I also think that these wrapper classes should only exist if there are block-level versions of them as well. It should always be possible to style a variant on a per-element basis.

+1 to the thorough and convincing explanation in #45.

Tested #44 on 9.1
This can be moved to RTBC

Follow-ups are here: #3170928: Add form variants to the Form API and #3170933: Use Form API to implement form variants

This takes care of the remaining item in #48

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

+++ b/core/themes/claro/css/components/container-inline.css
@@ -8,6 +8,18 @@
+ * Note that most rules with with .container-inline selectors are accompanied by

tiny nit: repeated "with" in comments with this opening line

I don't see anything else, so I think this is ready to RTBC otherwise.

This addresses #52 and changed the wrapper class .form-elements-inline to .claro-form-elements-inline so the prefix makes it clear this is provided by Claro and not all of core.

Previous patch was missing a few compiled files

The changes look right to me. Marking RTBC.

#56.1

Wondering how the design system expects this to be rendered; some of the examples use colon and some are not using it. If we remove this, I don't think we use colon anywhere.

Right, I made a judgement call here that ought to have been documented in the issue. The Figma designs state
HAS LABEL-COLON: textfield and radios
NO LABEL-COLON: textarea, select, machine name, checkboxes

I decided to remove the colon entirely (knowing it may lead to discussion) for the following reasons:

• With the Claro designs, there would be an inconsistency on forms with multiple inline elements. A textfield with a colon next to a select without would seem odd enless the label wording of one was clearly more colon-accommodating than the other - and were that the case it would be best if the colon was part of the label. This led me to believe the colons in the comps were envisioned as part of the label name and not appended to it via CSS.
• The theme formerly known as Classy has colons on every type of field other than radio and checkbox. Although I prefer removing colons entirely (more on this later), the deciding factor appears to be fieldset and non-fieldset input types. With the Claro designs, the distinction is less clear. This elevated my suspicion that the colons in the comps were envisioned as part of the label name and not appended to it via CSS.
• The Figma examples for checkbox highlight another issue with appending colons. The form label there is "Which ones apply to you?". Form labels phrased as a question are not uncommon, and adding a colon after the question mark wouldn't look right to me.

#56.2

Instead of duplicating this in multiple files, let's add @see referencing container-inline.pcss.css.

Yep that's better
#56.3 Added the @see

#56.4 These definitely aren't needed. Were likely a part of an earlier iteration and missed as they only target .container-inline and tests may have only been done with the wrapper class.

#56.5 Found a solution that works pretty good.

#56.6 Looks like that was happening with .container-inline but not .claro-form-elements-inline. Setting display: flex on .form-item, as it already does with .claro-form-elements-inline, takes care of it.

Re #56.4, it looks to me like these are needed, as the elements with the container-inline class look misaligned without. Maybe a comment with these would help?

The rest looks good to me, and the colon explanation works for me, unless it warrants further discussion.

Looks like there was a style specific to the wrapper class that can also be used by container-inline and it fixes the issue repported in #58. This patch also adds a wrapper class equivalent to a container-inline style that was missing it.

The issue in #58 looks resolved, thanks! And good catch on adding the wrapper class.

The below looks like it could use the same treatment (unless there is a reason not to?):

+++ b/core/themes/claro/css/components/form.pcss.css
@@ -31,6 +39,14 @@ tr .form-item,
+.container-inline .form-item:not(:last-child) {
+  margin-right: var(--space-m); /* LTR */
+}
+[dir="rtl"] .container-inline .form-item:not(:last-child) {
+  margin-right: 0;
+  margin-left: var(--space-m);
+}

+++ b/core/themes/claro/css/components/form.pcss.css
@@ -140,6 +192,13 @@ tr .form-item,
+.container-inline .form-actions .button,
+.container-inline .form-actions,
+.container-inline.form-actions {
+  margin-top: 0;
+  margin-bottom: 0;
+}

Pending the above, I think it's ready to go back to RTBC.

#60 isn't needed as those styles are specific to a use of .container-inline that isn't covered by the wrapper class. This is for displaying the elements of a form next to each other instead of stacked, such as the usage in admin/config/system/actions

This did lead to me discovering that this use of container-inline was broken by the fix for #56.6, which replaced the inline-block styling for .form-item with flex. This has been refactored to more specific targeting, so the margins should now be consistent regardless of the approach used, and container-inline can still be used to display elements next to each other.

This looks like it works! The spacing now appears consistent between .container-inline and the wrapper class.

I have no other issues to report, so marking as RTBC.

I can see how the different examples led to confusion about the colon: we considered it more a content decision rather than a forced element on any specific type of field.
We don't have any reason to force the colon on a visual design perspective, so I'd +1 @bnjmnm decision about deleting them completely.

Great catch, this should address #64

This seems to take care of it based on reviewing the usages in #6. Here are screenshots of the usages impacted by these changes.

I manually checked the affected forms, and all look good. I see nothing else in the code to comment on, so moving back to RTBC.

This needed a reroll.

Re #69 The datetime element should look the same with .claro-form-elements-inline and .container-inline, and for me it is looking the same. For that particular element, it would even look like that without either of those classes, as datetime-form.html.twig adds an entirely different class that results in the date and time being next to each other

<div{{ attributes.addClass('form-items-inline') }}>
  {{ content }}
</div>

Plus
.form-items-inline > .form-item

If I get steps on how to reproduce the stacking in #69 I'll address whatever is causing it.

I think this could use a reroll (or better, open a Merge Request) and update it. Some clues here: @lauri mentioned a test seems to be failing.

I'm working on a re-roll (via a merge request).

Re-rolled #67 as a MR. Here is the plain diff that can be used as a patch, if needed: https://git.drupalcode.org/project/drupal/-/merge_requests/559.diff

Tugboat live preview:
https://mr559-58yfpbqxizvkv518ouxtbz7fzteksjbh.tugboat.qa/

Looking into this test failure:

_________________________________________________

TEST FAILURE:  1 assertions failed, 286 passed (2m 6s)

 ✖ claroAutocompleteTest
 – Test Claro autocomplete (9.398s)
   Expected element <.js-form-item-autocomplete-3 [data-drupal-selector="autocomplete-message"]> to not be visible - expected "not visible" but got: "visible" (5128ms)
       at Object.Test Claro autocomplete (/var/www/html/core/tests/Drupal/Nightwatch/Tests/claroAutocompleteTest.js:45:20)
       at processTicksAndRejections (internal/process/task_queues.js:97:5)

error Command failed with exit code 5.

Adding tag for DrupalCon Europe2021. Thanks

This needs a reroll.

Rebase is done

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Rerolled the MR for Drupal 10.1.5 and attached interdiff.

Fixed failures in #92.

RE: #93

Thank you for work!

One point:
Really not sure. Why all css custom properties listed in few files?
Maybe add dependency to file which contains them?

We have css/base/variables.css already available in global-styling. There is no need to import it in any particular file. I have removed the import. Attached interdiff and patch for same.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Could we have this patch https://www.drupal.org/files/issues/2023-10-25/3029675-93.patch for Drupal core 10.2.1 version please? Thanks in Advance.

Rerolled #93 against core 11.x

This one is for 10.2.5