Required fields are force-fed stars?

[nternetinspired]

Why stars?

Showing a star next to a required field is s stylistic treatment (possibly also meaningless in many cultures) with zero functional benefit. A browser will consider it as meaningful as a :poop: symbol, it has no place in markup.

Nonetheless, if a form input is defined as required (I'm looking at com_users currently) in the forms/.xml it is output with a meaningless \ appended to the label.

<label id="password-lbl" for="password" class=" required">Password<span class="star">&nbsp;*</span></label>

Why not stars?

This is enforcing a style trump over the wishes of template authors, site owners and end users and it is nuts. It can't be overridden, AFAIK. I would have to hack core to remove this star symbol.

What if I don't want a star on every required form field? What if I want to use another icon? What if I want a clown-face or an :8ball: ??

Badges? We don't need no steenkin' badges

A wholly stylistic treatment like this should only ever be applied in the presentation layer, i.e. the template. The current behaviour isn't correct in any sense, semantically or stylistically. If I knew how to correct this I would submit a PR in an instant, unfortunately I don't. I'm restricted, as a front-ender, to;

• Hiding .star in css, an ugly hack.
• Hacking core to remove the required attribute, an even uglier hack.
• Creating rage-fuelled Github issues.

I can't think of any justifiable reason for this behaviour but if anyone can I'd love to hear it. I promise to remain calm!

In summary:

<label class="required"> = good. <span class="star">&nbsp;*</span> = bad.

[dgrammatiko]

I think is not a problem any more because there is a layout: /layouts/joomla/form/renderlabel.php It’s already there so in the next update you (we) can put whatever in the template override

[DavidGould]

@dgt41 I disagree, with respect. To say "the core code is wrong, but that's OK because everyone can override it" means the whole world has to do the override.

It would be better for the correct semantics to be delivered by the core, as suggested.

This comment was created with the J!Tracker Application at http://issues.joomla.org/.

[phproberto]

It's maybe better to say: the core is wrong but we cannot break BC with existing templates and sites so we cannot fix this now.

Overriding in the template is the best solution (and the only thing frontenders can do at thia moment). If anybody has a better BC solution is welcome.

Summary: Copy the layout to: templates/yourtemplate/html/layouts/joomla/form/renderlabel.php and edit it to fit your requirements On 28 Aug 2014 01:36, "David Gould" notifications@github.com wrote:

@dgt41 https://github.com/dgt41 I disagree, with respect. To say "the core code is wrong, but that's OK because everyone can override it" means the whole world has to do the override.

It would be better for the correct semantics to be delivered by the core, as suggested.

This comment was created with the J!Tracker Application https://github.com/joomla/jissues at http://issues.joomla.org/http://issues.joomla.org/ http://issues.joomla.org/.

— Reply to this email directly or view it on GitHub https://github.com/joomla/joomla-cms/issues/4139#issuecomment-53655751.

[DavidGould]

@phproberto - yes, fair point. I expect it would be a mountain of work for a molehill of benefit to get sensible semantics without breaking everything in sight. One day, maybe :-)

[nternetinspired]

Summary: Copy the layout to: templates/yourtemplate/html/layouts/joomla/form/renderlabel.php and edit it to fit your requirements

Thanks for this clarification @phproberto it is very helpful, I will do that.

Personally, I don't think that altering this behaviour would be a BC break, but maybe I'm missing something? Section 6.1.7. of the Joomla Development Strategy states that rendered markup is not subject to the backwards compatibility promise.

http://developer.joomla.org/news/586-joomla-development-strategy.html

[dgrammatiko]

@DavidGould I think you got me wrong, I am not saying let the core be bad and just override it. My comment was that for any label we can NOW use override, nothing more. @phproberto explained it very well, but for what it may worth, let me clarify that I DON’T like the star as well.

[roland-d]

I am just thinking that stars are so 80-ies :) Would be nice to get a better design there out of the box.

[dgrammatiko]

We can include icomoon font from jui/fonts and a css for .star pointing to one of the glyphs from E0223 - E0225 (all caution signs, circular or triangle)...

[nternetinspired]

Would be nice to get a better design there out of the box.

It would be nice to to let (template) designers do the designing. The * has zero functional value, it is entirely stylistic, and so it has (IMO) no place in a core output, that's why I have a problem with it.

Yes, I can override it, but I shouldn't have to override something that shouldn't be there. Moreover the average user, Joe Public, probably cannot override it.

[nternetinspired]

We can include icomoo font from jui/fonts and a css for .star pointing to one of the glyphs from E0223 - E0225 (all caution signs, circular or triangle)...

No! That would be even worse.

If you, or the template designer wants to map .required to an icon, do that. The last thing core output needs is any more icons.

[roland-d]

Yes, I can override it, but I shouldn't have to override something that shouldn't be there.

There are customers who want an indication of required fields, if nothing is there, being Joe Public, they wouldn't know how to add it. Either way someone has to do an override, either to show or not show something.

[nternetinspired]

There are customers who want an indication of required fields…

Is there? Really? I've never seen any user make such a request.

…if nothing is there, being Joe Public, they wouldn't know how to add it.

Joe and Jane Public buy templates. Template designers know how to design stuff, including placing icons if they so wish.

[dgrammatiko]

I think, if I got it right, what @nternetinspired is saying: “don’t impose anything in the core” And I guess that’s the best option. Leave a .required class and that’s it, am I right Seth?

[nternetinspired]

Right @dgt41 because that provides a sensible, semantic, hook for any styling that is required (in addition to a required attribute in the input itself, which provides the functional aspect).

Styling belongs in the template.

[dgrammatiko]

:+1:

[mbabker]

I'd have no issue if someone proposed a PR removing the <span> rendering the star in favor of the required attribute, but I'd say that the core templates should be required to render something similar (through CSS declarations) in its place.

[nternetinspired]

The required attribute on the input already exists as does a .required class on the label, so a pure css solution to replicate the existing appearance requires only:

label.required {
display: inline-block;
position: relative;
}

label.required:after {
content: "*";
display: block;
position: absolute;
right: -.75em;
top: 0;
}

Positioning (the right: value) may need some minor tweaking, but I imagine that would place it pretty much spot on. If such a change would be accepted generally I will happily put it in place.

[mbabker]

Send it, I can't think of a (logical) reason it wouldn't be.

[Bakual]

I agree. Do a PR and maybe include that CSS snippet to restore the function. This way if someone is missing the stars, he can add it easily after looking at (or being pointed to) the PR.

[infograf768]

Whatever the solution proposed, please also think of RTL. Thanks.

[infograf768]

RTL (isis back-end)

label.required {
display: inline-block;
position: relative;
}

label.required:after {
content: "*";
display: block;
position: absolute;
left: -.75em;
top: 0;
}

careful with hathor, these values would not work.

Is it possible to check for an existing css in renderlabel as a conditional to

<?php if ($req) : ?><span class="star">&#160;*</span><?php endif; ?>

[Bakual]

Good point with RTL. However I wouldn't do a check for an existing CSS (it is likely not possible anyway).

Honestly: If the star isn't there anymore in a template, it will still work without issues. It will not break anything. And it's easy to add again using a CSS rule if it's important for someone. If we start adding complicate code, then I would be against the change :smile:

[phproberto]

Am I the only one seeing that we are going to change everybody's forms?

User Y has a site with template X. Template X does not include any style for the required fields because it relays on core. User Y upgrades his Joomla and the stars dissappear.

Am I missing something? In fact we could do it in the reverse mode: leave it in the default layout and remove it in protostar override.

For me changing libraries layouts are a BC. Worse if we are talking about form fields. Remember that layouts is something "new" and most templaters still don't know they can override things (like Seth). On 28 Aug 2014 19:33, "Michael Babker" notifications@github.com wrote:

Send it, I can't think of a (logical) reason it wouldn't be.

— Reply to this email directly or view it on GitHub https://github.com/joomla/joomla-cms/issues/4139#issuecomment-53761940.

[Bakual]

It's not really a BC break because nothing really breaks. Also as stated our BC promise so far doesn't include the generated output.

It's true that the stars will not be show anymore for each template which doesn't have an override. Imho, it's not really a big thing as everything will still work and the design of the template will not break. The point is also that it's way simpler to add the star (using CSS rules) than to remove them (needs a JLayout override).

[brianteeman]

I agree with @phproberto on this one. If this change occurs then every site will need to add css to work as it did before. While I would agree that in some cases a visual change can be classed as not BC break in this case removing something that designates a required field would be. Speaking personally I completed an online form yesterday 5 times as the site had no indication that some fields were required. Very frustrating and thats exactly what we will be doing to everyones sites if we make this change.

[nternetinspired]

And it's easy to add again using a CSS rule if it's important for someone.

It's not really a BC break because nothing really breaks. Also as stated our BC promise so far doesn't include the generated output.

:100:

Am I missing something? In fact we could do it in the reverse mode: leave it in the default layout and remove it in protostar override.

Core is not the place to implement styling.

[nternetinspired]

If this change occurs then every site will need to add css to work as it did before.

Every site will continue to work just as it did before and will have benefited from the removal of bad markup.

Speaking personally I completed an online form yesterday 5 times as the site had no indication that some fields were required.

If a field has a required attribute, as these will, then your browser would have told you which fields were required and what you should be putting in them. It will also prevent you trying to submit the form when required fields are not complete.

[brianteeman]

it is not a great experience to submit a form and then get a message that you missed a required form.

And I don't know what browser you are using but Chrome doesnt tell me which fields are required

[nternetinspired]

it is not a great experience to submit a form and then get a message that you missed a required form.

You can't submit a form that has required fields that are invalid, the browser won't allow it.

I'm using Chrome:

[Bakual]

@brianteeman Chrome does show you after you activated the field and left it empty. Without actually sending the form.

[brianteeman]

and how is the user to know that a red border means its required. Users are stupid

On 29 August 2014 09:45, Thomas Hunziker notifications@github.com wrote:

@brianteeman https://github.com/brianteeman Chrome does show you after you activated the field and left it empty. Without actually sending the form. [image: requried] https://cloud.githubusercontent.com/assets/1018684/4088116/cd356dea-2f58-11e4-870e-fdac8150ce34.png

— Reply to this email directly or view it on GitHub https://github.com/joomla/joomla-cms/issues/4139#issuecomment-53851486.

Brian Teeman Co-founder Joomla! and OpenSourceMatters Inc. http://brian.teeman.net/

[nternetinspired]

There's also the alert of course:

[nternetinspired]

and how is the user to know that a red border means its required. Users are stupid

And how is the user to know that a star means it's required? Users are stupid.

There's a legend on this form, but not on any other.

[brianteeman]

Because it says so right at the top of the form!!

[brianteeman]

As for the alert didnt I already say it was a bad user experience to wait until after the user submits a form to tell them that they missed something out.

[nternetinspired]

Because it says so right at the top of the form!!

Does it?

[nternetinspired]

As for the alert didnt I already say it was a bad user experience to wait until after the user submits a form to tell them that they missed something out.

Which is why this is a far better option:

[brianteeman]

It does on the register form (and I would suggest that its a bug that it doesnt on the edit form)

[Hils]

@brianteeman said

users are stupid

I don't think we are but we have been trained in a Pavlov-like manner that a star means we have to fill in that field else we will not be able to send the form. Even the BBC employs that device. https://ssl.bbc.co.uk/faqs/forms/?eid=&id=I2GGS2N5VAA7VI32E45V4TA2OA&mid=&uid=347299105

This is an end-user comment on the default, not a how to code it/change it comment.

Hils

[brianteeman]

As always Hils you write far more eloquently than me

[nternetinspired]

It does on the register form (and I would suggest that its a bug that it doesnt on the edit form)

…or the login form, the username reminder form, the password reset form, or contact forms. It is in fact unique to the registration form.

[Hils]

@brianteeman learning from a master perhaps

[nternetinspired]

I don't think we are but we have been trained in a Pavlov-like manner that a star means we have to fill in that field else we will not be able to send the form. Even the BBC employs that device. https://ssl.bbc.co.uk/faqs/forms/?eid=&id=I2GGS2N5VAA7VI32E45V4TA2OA&mid=&uid=347299105

I agree with you here Hils, but in this example it is somewhat of a necessity as the form is poorly coded and there is no required attribute on the select. So, while the star says (to some) that is required, the html says it isn't.

That isn't the case with Joomla's forms where the elements themselves do contain the correct required attributes which correctly allow browsers to provide additional feedback to users, as does Bootstrap's form validation css which also provides user feedback.

As noted in my original comments I'm guessing (really, no more than a guess) that in other languages / cultures a * might not say “I'm a required field!”.

As also noted in previous comments we can easily, if people think it is necessary, add a * to form labels in the correct manner using css content. Inserting stylistic treatments, inline, with html is not the correct way to do things. It's no different to doing:

<label style="font-weight:bold,color:black,text-transform:uppercase">Me very important label!</label>

Styles belong in templates.

[phproberto]

It's not really a BC break because nothing really breaks. Also as stated our BC promise so far doesn't include the generated output.

Nothing really breaks? Ok then I think we can change the renderfield classes/structure too. I'm sure there is a better way to semantically render fields. We will mess all the people forms but who cares? It's a visual thing.

Forms layouts should be part of our BC promise because remember that they were hardcoded! The renderlabel layout was introduced 10th July 2014. Do you think we have a lot of templates out there with an override? This affects ALL the forms including 3rd part extensions like shopping carts where this information is really important.

The right thing is to start doing it right where we can (templates) and wait until a major break to fix all the core markup. Templaters will have their base layouts pack anyway so it's not a big problem for them. It is for users.

Roberto Segura Twitter: @phproberto http://twitter.com/phproberto - Skype: phproberto

• Phone: (+34) 636 420 530 http://phproberto.com

2014-08-29 10:24 GMT+02:00 Thomas Hunziker notifications@github.com:

It's not really a BC break because nothing really breaks. Also as stated our BC promise so far doesn't include the generated output.

It's true that the stars will not be show anymore for each template which doesn't have an override. Imho, it's not really a big thing as everything will still work and the design of the template will not break. The point is also that it's way simpler to add the star (using CSS rules) than to remove them (needs a JLayout override).

— Reply to this email directly or view it on GitHub https://github.com/joomla/joomla-cms/issues/4139#issuecomment-53849723.

[infograf768]

Stars on the net for required fields are not dependant on culture: it is the Net culture. I also believe that by forcing these new css and taking off the span star we are losing B/C. Thus why I asked if we could add a conditional.

[brianteeman]

You will also need to decide how to handle the display of the current language string COM_USERS_REGISTER_REQUIRED

On 29 August 2014 10:23, infograf768 notifications@github.com wrote:

Stars on the net for required fields are not dependant on culture: it is the Net culture. I also believe that by forcing these new css and taking off the span star we are losing B/C. Thus why I asked if we could add a conditional.

— Reply to this email directly or view it on GitHub https://github.com/joomla/joomla-cms/issues/4139#issuecomment-53854692.

Brian Teeman Co-founder Joomla! and OpenSourceMatters Inc. http://brian.teeman.net/

[nternetinspired]

Stars on the net for required fields are not dependant on culture: it is the Net culture.

Yes, @infograf768 you're right. It does appear to be a universally accepted treatment:

http://ux.stackexchange.com/questions/19491/is-the-asterisk-the-common-symbol-to-mark-fields-as-required-in-all-languages?rq=1

However, while the current usage did appear in the W3C HTML4 spec examples of form markup: http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H90 such usage has been removed from all form markup examples in the html5 spec which instead use only the required attribute (as we already do): http://www.w3.org/html/wg/drafts/html/master/forms.html#introduction-2 as it provides real functionality and user feedback, unlike a *.

[hdwebpros]

There's no way something like this could be done until the next major release, but this is a decent read about not showing any required fields. http://loglr.com/i/36272

Either way, we have to make it clear though. And I'm for yanking the actual star out and replacing it with css

[nicksavov]

Personally, I don't think that altering this behaviour would be a BC break, but maybe I'm missing >something? Section 6.1.7. of the Joomla Development Strategy states that rendered markup is not >subject to the backwards compatibility promise.

http://developer.joomla.org/news/586-joomla-development-strategy.html

It isn't part of the BC promise because so far there isn't a good, objective way to define what constitutes a break and what doesn't.

Just because it isn't part of the backward compatibility promise doesn't mean that anything goes. Please note the bolded part (emphasis mine) of Section 6.1.7:

For the time being, rendered markup is not subject to our backwards compatibility promise. We will try not to change markup in such a way that a site might render differently, but we can't promise not to break anything at the present time. We will work on defining ways in which we might make a backwards compatibility promise for markup in the future, but we do not currently have a satisfactory consensus on a workable standard.

In this particular case, the proposed change would intentionally be changing the markup in such a way that the site would render differently (in most cases, negatively), therefore it goes against the development strategy.

I'm in favor of the change, but not until the next major release. layouts/joomla/form/renderlabel.php can be used for overriding until then.

@nternetinspired I'm really glad you brought this up. It helps us all to think proactively about semantic markup issues moving forward.

[nicksavov]

Could someone send in a PR to mark instances of <span class="star">&nbsp;*</span> as deprecated for 4.0?