Personally I would do it by adding the CSS rule

.hidelabel .field-label {
  display:none;
}

to our templates and add "hidelabel" as a suggestion to the already existing "Render Class" parameter. Similar to what we did for the "Caption Class" in the editor image plugin.

<field
	name="render_class"
	type="text"
	label="COM_FIELDS_FIELD_RENDER_CLASS_LABEL"
	description="COM_FIELDS_FIELD_RENDER_CLASS_DESC"
	class="input-xxlarge"
	size="40"
	>
	<option value="hidelabel">Hide the label</option>
</field>

But it would mean changing the field to a text field as textareas don't seem to support datalists.

This PR of course works as well, but has the cost of an added parameter and a tiny more complex laoyut for something that can be done with simple CSS.

I have tested this item ✅ successfully on 1a48a92

While it's possible to do with css, it seems to me to be cleaner to change the output and not render it at all, but I'll let others chime in on that.

I have tested this item ✅ successfully on 1a48a92

@brianpeat i think its not common to test own PR.

Ah sorry, I'm still learning the rules :)

I'm also open to suggestions on if it's good as is with Hide Label with Yes/No and the default is No, or if we should do it like the article titles are, where it would be Show Label with Show/Hide and default to Show. Does anyone have any opinion on that?

I have tested this item ✅ successfully on 1a48a92

Tested on Siteground. The label disappears when turned off and reappears when on. Everything works well. I don't really understand the merits of Bakuals comments so I will leave that discussion to others.

=============
System Information

php: Linux evm852.sgvps.net 3.12.18-clouder0 #3 SMP Thu Oct 20 14:54:11 EEST 2016 x86_64
dbversion: 5.5.31-30.3-log
dbcollation: utf8_general_ci
dbconnectioncollation: utf8mb4_general_ci
phpversion: 5.5.38
server: Apache/2.2.24 (Unix) mod_hive/5.5 mod_ssl/2.2.24 OpenSSL/1.0.0-fips mod_auth_passthrough/2.1 mod_bwlimited/1.4 mod_fastcgi/2.4.6 mod_fcgid/2.3.6
sapi_name: cgi-fcgi
version: Joomla! 3.7.0-beta1 dev [ Amani ] 18-January-2017 20:28 GMT
platform: Joomla Platform 13.1.0 Stable [ Curiosity ] 24-Apr-2013 00:00 GMT
useragent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

Just to wade in on the CSS debate. Would using CSS mean that all labels are hidden? In this case @brianpeat has made the system flexible enough for labels to be hidden one at a time. However, I would suggest it could be improved by the field having a global option, and then overall fields options having a show/hide field.

Would using CSS mean that all labels are hidden?

No, you would have to add that class to the "Render Class" option of the field where you want to hide the label. It's exactly as flexible as the proposal here, just using CSS instead of a parameter.

it seems to me to be cleaner to change the output and not render it at all

Sometimes it's is better for accessibility to have the label there but hidden. It improves the experience when the site is read with a screenreader. But I'm not an expert here for sure, just watched a presentation from Angie once ?

Well in the case of my example, the field itself is rendering my text as I want it (read-only), so if the label was there in the css, the reader would literally read it twice. So I guess there's an argument for both scenarios :)

@uglyeoin mentioned a global setting. I suppose if we did that it would work something like:

If Custom Fields are enabled in the Integrations tab, then show global option in the Articles tab.
Then my new switch would be changed to a global/show/hide type switch and be renamed Show Label (instead of Hide Label).

Does anyone have any opinions about that?

Having global options in each extension isn't an option for me. It would mean that each extension has to add those options which isn't idea. We have two options imho:

• Put them into the fields plugin like it is today. Downside is that it's not the most intuitiv place to look for
• Have the options in com_fields itself, but that basically means that com_fields becomes a standalone extension and doesn't try to camouflage into other extensions like today.

do you think it would be weird to have a link in the field edit window next to an option that has its setting in the plugin that says "edit global setting" and links to the plugin edit window? That would fix the issue of not finding it.

That's a question for UX, not for me ?

I think the UX team is going to take a good look at this, so I don't want to close it, but I also don't want it to get approved yet. We'll just leave it in limbo for now if that's okay (unless there are rules on that sort of thing).

Given there are over 300 PRs open and many of them already without any activity for a long time, this one can stay open for a few weeks without issues :)

RTC

Marking needs review as Brian made it clear here (and in the UX group in glip) he wants the UX team to review this before it gets merged

I think I need help with the if statement :)

okay, I encourage people to test again, with NEW fields since the params name changed (from hide to show). Should be good to go now. @cpfeifer says it's okay to move forward on this without any global setting.

I have tested this item ✅ successfully on 7be898d

Works fine. I think we should consider any global settings in a different issue. I also feel this method of hiding the label is more consistent with the other features in Joomla than hiding it with CSS. I can see the desire to simplify the coding as much as possible, but I think we should stick with the standard methods here and deal with optimizing the code separately.

Long term, it think it makes sense to have a "fields manager" of some kind to eliminate the need for code updates across three components and to ensure consistency of code, but I'm not sure that large of a change is possible within the timeframe of the 3.7 release. I think it's fine for now, but we will have make changes across multiple components for each adjustment in the current implementation.

I have tested this item ✅ successfully on 7be898d

I have tested this item ✅ successfully on 7be898d

I guess we can add it as it is a useful option.

Do we want to move forward on this now then? It's kind of stalled out even though Cliff has given it the go ahead from the UX team.

Somebody needs to set it back to RTC then.

RTC