Date form field display label has visual differences to other form fields.

Can you add a couple of screenshots with and without your patch?

Thanks!

Unassigning to allow others to review @kevin.dutra's work.

I reviewed manually some pages and there are other places with the tag h4 and the class label (like /user/[0-9]) but certainly this is the only place where I found the combination h4 + class label + input.

So this is RTBC to me.

Great work!

Thanks for the work @kevin.dutra and @gnuget!

Sorry for knocking this back, I'm going to take a quick look at the CSS codebase first before this is passed onto a committer.

Hi Kevin, thanks for the issue and the patch. Sorry this took so long, this issue needed more thought than first anticipated. (I was thinking of chasing the datetime.module because of the use of a <h4> but I have since studied the core form markup and the HTML standards for forms).

I've noticed that the code does not follow a few of the core CSS coding standards.

Here are the coding standard conflicts for future reference...

We shouldn't fight broken visual styles by bulking up selectors with classes that only match that specific context eg. .field--type-date-time.

This may seem natural, but actually makes CSS less predictable and maintainable. Sooner or later you’re going to need that component style somewhere other than a sidebar! Or, the reverse may happen: a new developer places a component in the sidebar and gets an unexpectedly different appearance.

Referenced from https://www.drupal.org/coding-standards/css/architecture#pitfall-context

And we shouldn't use HTML structure within selectors ie. the <h4> tag itself, to provide styles.

Mirroring a markup structure in our CSS selectors makes the resulting styles easy to break (with markup changes) and hard to reuse (because it’s tied to very specific HTML).

Referenced from https://www.drupal.org/coding-standards/css/architecture#pitfall-structure

So in Bartik form.css there are already styles to style all other labels with the correct font and sizing without being too specific to the type of form element it is. We need to apply the same styling rules using the HTML structure that datetime is using for it's wrapper and label.

Here is the label styling that already exists Bartik form CSS - (which isn't perfect but will be refactored in the future... #2502027: Clean up the "form" component in Bartik)

.form-item label {
  font-size: 0.929em;
}

.node-form label,
.node-form .description {
  font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
}

We can use the same format of selector which is .form-wrapper .label and add it to the styles above to match the other form field element styles on the page. Then any other form item instance that matches what datetime does can benefit from the styles.

It's not the best solution, but it makes it slightly more reusable than the existing patch in this issue. I will also document this change to be refactored further in #2502027: Clean up the "form" component in Bartik.

Thanks Kevin for the further research into the fields markup. And yes the simplest things seem to gain so much complexity!
I will take visually take a look at the fields with a cardinality of >1 with the patch applied and post some screenshots.

OK good shout on the .form-wrapper .field-multiple-table .label selector.

The date label now has the correct sizing...

Before

After

 

 
The patch however needs one more thing. The label also needs to have the correct font set to it. Please can the selector be added to the code block I posted in #11 which has the font declaration in it?

Thanks

Cheers Kevin this is great.

We have added a fix to allow fields such as 'Date' who have a different markup structure and have to use a .label class instead of a <label> to have consistent label styling with the rest of the fields in core.

The CSS can be refactored further in the future once we tackle what we have existing in the form.css file already - #2502027: Clean up the "form" component in Bartik. For now we have looked into all scenarios where this code could provide visual regressions and accounted for them.

See before and after screenshots.

Before
 

 
After
 

Suggested commit message:

git commit -m 'Issue #2653914 by kevin.dutra, emma.maria, gnuget: Date form field display label has visual differences to other form fields'

Retesting against 8.1.x

Moving to 8.2.x because this is a UI change and also minor :)

Great work on this fix! What a silly bug. :) Before/after screenshots are especially helpful.

Committed and pushed to 8.2.x. Thanks!

Oopsie. Credit.

Thanks, removing from UX sprint now.