Problem/Motivation


The search field is rounded both as another opportunity to introduce friendliness into the UI, but also follows a tendency for search fields to be rounded in some browsers and operating systems.

Grouping the single text field and the submit button together simplifies the component and implies a one-to-one relationship between the two. There is also an opportunity to create a bootstap-style input group component.

The dropdown menu is intentionally designed as a distinct component (see the section Dropdowns and Popovers) for modularity of the design and code reusability. Visually and in terms of implementation, merging or joining the search field with the drop down is both awkward and not strictly necessary for usability.

Steps to reproduce

N/A

Proposed resolution

See description

Remaining tasks

Review

User interface changes

Before:

before

After:

after

Introduced terminology

N/A

API changes

Some mark up changes

Data model changes

N/A

Release notes snippet

N/A

Issue fork drupal-2160545

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

lewisnyman’s picture

Issue summary: View changes
lewisnyman’s picture

lewisnyman’s picture

Here are a few examples of pages that use single input search/filter forms:



lewisnyman’s picture

dawehner’s picture

Interesting to have a common approach for all those forms.

Can you please remove the last example? This is just wrong, given that this is no search functionality.

lewisnyman’s picture

Sure thing.

lewisnyman’s picture

Issue tags: +DrupalCampLDN
lewisnyman’s picture

Title: Create search component » Create search/filter component
lewisnyman’s picture

Here's a proposal patch implemented on the module page. You have to apply it alongside #1986418: Update textfield & textarea style

The submit button doesn't do anything yet and we'll have to override it with JS.

tompagabor’s picture

StatusFileSize
new13.96 KB
new3.65 KB

Add a newy patch, because overflow: hidden, and overflow: auto cut box-shadow, on the left side.
Used position relative/absolute, instead of floating.

search form with visible box-shadow

lewisnyman’s picture

Status: Active » Needs review
emma.maria’s picture

StatusFileSize
new3.71 KB

Patch re-rolled :)

lewisnyman’s picture

This is looking good, is it a good idea to have a set width like that? What if people need it to be shorter or wider than 200px?

nikolay shapovalov’s picture

Assigned: Unassigned » nikolay shapovalov
nikolay shapovalov’s picture

Issue tags: +drupalcampfi
nikolay shapovalov’s picture

Status: Needs review » Needs work
StatusFileSize
new19.69 KB
new17.95 KB

I have tested the patch #13 on windows 7.
There are several bugs:

  • left corner isn't rounded
  • submit button is on the next line

IE 11:
IE 11
Google Chrome:
Google Chrome

nikolay shapovalov’s picture

StatusFileSize
new41.25 KB

About pacth #13
There is semicolon required at the end after position:absolute.

+++ b/core/themes/seven/css/components/input-group.css
@@ -0,0 +1,25 @@
+.input-group .form-submit {
+  position: absolute

Also there is an issue with submit button width on mobile device.
Google Chrome:
Google Chrome

nikolay shapovalov’s picture

Assigned: nikolay shapovalov » Unassigned
sqndr’s picture

Assigned: Unassigned » sqndr

Picking up this issue. I ended up with some css that looked like this:

.input-group {
  position: relative;
}
.input-group .form-item {
  width: 100%;
}
.input-group input.form-search {
     width: 75%;
     padding: .3em .4em .355em .5em;
     border-right: 0; /* LTR */
     border-top-right-radius: 0; /* LTR */
     border-bottom-right-radius: 0; /* LTR */
 }
.form-wrapper.input-group .form-submit {
    width: 25%;
    position: absolute;
    margin: 0;
    top: 0;
    right: 0;
    border-top-left-radius: 0; /* LTR */
    border-bottom-left-radius: 0; /* LTR */
}

@media screen and (max-width: 600px) {
  .input-group input.form-search {
    padding: .3em .4em .3em .5em;
  }
}

Looked good in chrome ... but then I opened Firefox, and there were some layout issues again. Seems like this still needs some work. Maybe we can look into Bootstrap and see how the form group is styled there?

Chrome:
http://cl.ly/image/12083J023x3k
http://cl.ly/image/431k410n0h0S
http://cl.ly/image/183b082e0216

sqndr’s picture

Assigned: sqndr » Unassigned
Bojhan’s picture

Issue tags: +frontend
lewisnyman’s picture

Issue tags: -markup, -DrupalCampLDN, -drupalcampfi

I think we can take a new approach with this and specify the component similar to Bootstrap:

.input-group
.input-group .form-item
.input-group__add-on

Then we don't have to assume a specific element is the special case.

emma.maria’s picture

Version: 8.0.x-dev » 8.2.x-dev

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

markconroy’s picture

Component: Seven theme » theme system

Let's move this to the theme system queue. Looks like it's relevant to Drupal rather than just Seven theme.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

nayana_mvr made their first commit to this issue’s fork.

nayana_mvr’s picture

Status: Needs work » Needs review
StatusFileSize
new246.66 KB
new245.02 KB
new4.44 KB
new1.99 KB

I have re-rolled the MR to D11 but there are UI issues as shown in below screenshot.

re-roll

The class names .input-group and .input-group__text are not getting added in the expected elements when compared to the HTML structure shown in http://getbootstrap.com/components/#input-groups. Also, as per my understanding, input-group can only be used if the theme uses Bootstrap style (Please correct me if I'm wrong). In D11 Claro theme doesn't use Bootstrap but there are many contrib themes such as Radix, Bootstrap, etc which can be used to achieve this.

I tried a different approach for the UI part where I could make the input field and search button inline to each other. Screenshot attached below.

patch-40

Attaching both re-rolled patch and patch with new approach here.

This issue seems to be an old one. Currently in D11, there exists one filter functionality in module extend page so do we still need to work this issue? If not please close this ticket. Moving to Needs Review for feedback.

nayana_mvr’s picture

Attaching few issue links which I referred while looking into this ticket. Please feel free to remove if it's not relevant.

smustgrave’s picture

Status: Needs review » Needs work
Issue tags: +Needs issue summary update

Patches should be in MR

Also issue summary should use complete template.

nayana_mvr’s picture

Issue summary: View changes
StatusFileSize
new269.32 KB

Created MR with the new approach and updated IS with complete template but as I mentioned in my previous comment, need input from core team about whether we are still planning to implement this feature or not. Please review.

nayana_mvr’s picture

Issue summary: View changes
nayana_mvr’s picture

Status: Needs work » Needs review
sagarmohite0031’s picture

StatusFileSize
new123.47 KB

Hello,
I have try to reproduced the issue on Drupal 11 but its looks fine for me.
The MR is applied successfully.

Please check attachment-

smustgrave’s picture

Status: Needs review » Needs work

I don't think the MR is accomplishing what is described. All it seems to be doing is changing the label and adding a submit button where not needed. Why do we need a submit button for something that is autosubmitting? Also issue summary contains suggestions as typing which does not appear to be working.

markconroy’s picture

Issue summary: View changes
Status: Needs work » Closed (outdated)
StatusFileSize
new120.23 KB

The free text filter on the "Extend" page is not a search component.

Please do not work on that as part of this issue.

This issue is to standardise how search will look where search is actually used when it's a single input+button in Drupal 7.

I'm not even sure there are examples of this in Drupal 10/11 core at this stage.

The only thing I can find is this:

filter aliases

With all that being the case, I am going to close this issue. If someone disagrees, please open a new issue with very clear instructions on what you want to achieve.