I'm not to sure about this. While I appreciate the idea to be able to insert additional fields into that container (something I struggled myself with), it's more a bandaid around this JLayout.
Imho the whole JLayout should be reevaluated because passing the whole view into it isn't good to begin with. Instead the filterform, activefilters and other needed things should be passed explicitely.
Maybe we should deprecate the existing JLayout and use a new one (or the same but other arguments), basically passing only in what is required instead of the whole view. This way it may even be easier to pass in additional fields.

I agree. One of the biggest issues with JLayout's that we cheated and injected the JView object. This was the biggest thing that made swapping legacy mvc to something else near impossible

I guess that discussion about injecting the view into the layout should not be addressed in a different issue. This one fixes the styling case where the box of different contextes swapps on a different line.

It is related, because I'm not a fan of moving the searchtools container outside the searchtools JLayout. The Jlayout should be respsonible for the whole thing.
If we rewrite the JLayout so it is more flexble and you can inject additional fields into it, then it should solve both problems witht he current JLayout.

Just to further explain my intent here as I didn't explain very well in the summary..

Currently the bordered div with grey background is applied to the .js-stools class which is a class in the searchtools JLayout. This PR removes that styling and applies it to a new class (.js-stools-container). The view layout then becomes...

<div class="js-stools-container">
	<?php echo JLayoutHelper::render('joomla.searchtools.default', array('view' => $this)); ?>
</div>

Regardless if JLayouts should be changed (I am not knowledgeable enough on that subject to comment) I believe the PR still correct. The JLayout should only contain the fields and not div styling.

Ah I didn't get that this container didn't exist before. I assumed you moved it out of the JLayout
Still not sure if I like it. It feels wrong to have part of the design of that element outside the element.

Am I correct in assuming JLayout should only contain the fields and not div styling?

The JLayout is meant as a reusable layout component which holds all the HTML elements needed for a given purpose (SearchTools in that case).
It has those advantages (amonsgt others):

• We don't have to write the same HTML code over and over again.
• If we want to adjust something, we can do it in one place.
• If a template wants to adjust the appearance of the Search Tools, they can override that JLayout and it changes the appearance in all components.

Ty @Bakual .. I see now your logic.

I guess the question is if that area of the design is specifically for searchtools or more of a general 'table header' which may contain other non-searchtool fields. The latter appears to be the case for com_fields.

Also do we want the searchtools to be styled with a border/background in every case (eg. modals).

Actually, while looking if we can refactor the JLayout I found that there is a possibility already to include the context into the searchtools JLayout. That seems to be new with J3.7 or so.
See #16546

We still should rewrite that JLayout someday, but this should solve the issue with the context field.

Going to close this for now as @Bakual has offered an alternative solution to the initial reason for this PR with #16546