Advanced search fields need IDs

[allanaaa]

In the public interface, advanced search forms cannot be easily customized. Rather than build a whole structure around including or excluding each field with a checkbox, or dragging and dropping, site administrators could use CSS Editor to point to specific fields by ID and hide them.

Unfortunately, many fields do not have IDs:

Numeric Data Types is done well, but core and Mapping need some specificity. There may be other modules that add search fields - I can't think of any offhand.

I think the aria labels and classes should also be applied more consistently? @kimisgold maybe you can advise on the aria labels.

The original question (how best to offer customization on Advanced Search) can be discussed too, but this seems necessary either way.

[kimisgold]

There should now be default IDs provided by the form field row template, as well as manually applied IDs to the identified fields. Could you expand on what kind of consistency you're looking for with the aria labels and classes?

[allanaaa]

Well, I was hoping you'd tell me. Surely if some of them need aria labels, they all do? Is that how aria works?

For classes, maybe "removable" and "multivalue" are the only ones we use. But do you think site admin might want to point at others with CSS styles using things like "singlevalue" or some other category, maybe "dropdown" and "textfield"? Or a class for all the Numeric ones, all the Mapping ones?

[kimisgold]

Ah I see what you mean now. For the fields with multiple inputs, I set the container as role="group" to indicate all the child inputs are associated, and then add aria-labelledby attributes as all group elements require. The field rows with single inputs don't need these: the labels should already use for attributes that associate them with those single inputs.

When there are binary states like "singlevalue" and "multivalue", I think only one class is necessary, as one can provide default styles and then styles targeting the other state. I feel like "dropdown" or "textfield" can already be targeted using select or input[type="text"], etc. I'm open to other ideas though. I think it's also reasonable for modules to provide classes that help target all field rows specific to those modules. I can look at implementing that in our modules.

[zerocrates]

The change to form-row probably needs to more gracefully handle the case where the element doesn't have an ID, as-is we'd have in some places several conflicting "_field" ID rows.

Mostly we use IDs obviously but there are times and places where we don't want to, like when the element can appear multiple times. I don't know that we're actually using form-row with many of those cases but it's probably worth supporting (just by omitting the id where the element doesn't have one, I'd figure).

[kimisgold]

@zerocrates Does be031d5 address your concern?