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

@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/.

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
#4139 (comment).

@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 :-)

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

@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.

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

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)...

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.

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.

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.

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.

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?

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.

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.

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.

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

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.

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

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; ?>

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

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
#4139 (comment).

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).

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.

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.

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.

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.

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

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:

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

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
#4139 (comment).

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

There's also the alert of course:

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.

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

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.

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

Does it?

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:

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

@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

As always Hils you write far more eloquently than me

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.

@brianteeman learning from a master perhaps

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.

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
#4139 (comment).

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.

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
#4139 (comment).

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

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 *.

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

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.

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

What is the status of this? Is it to be closed for the B/C issues or is someone going to create the PR with the deprecated notice as @nicksavov requested or something else?

So, to re-iterate for clarity, are we are all agreed that:

• All instances of <span class="star">&nbsp;*</span> in rendered markup should be marked as deprecated for 4.0.
• Default templates for 4.0 will use pure CSS implementations to insert * as CSS content?

?

1. agreed from me
2. agreed from me but I guess as no plans have been done for 4.x yet that can only be an aim and not a firm guarantee

On 5 January 2015 at 09:42, Seth Warburton notifications@github.com wrote:

So, to re-iterate for clarity, are we are all agreed that:

• All instances of  * in rendered markup should be marked as deprecated for 4.0.
• Default templates for 4.0 will use pure CSS implementations to insert * as CSS content?

?

—
Reply to this email directly or view it on GitHub
#4139 (comment).

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

Note: We also have <span class="star">&#160;*</span>

@nternetinspired are you going to submit a PR that marks this as deprecated or shall I just close this

@brianteeman can you add the Reevaluate for v4.0 label so this will be on the list for 4.0?

@brianteeman @nicksavov It would be imprudent to mark these instances as deprecated when there seems to be no clear direction on the template issue, wouldn't it?

If we are to stay with 's in the near future then any markup changes really need to occur hand-in-hand with a template-based alternative.

From my point of view as end user and beginner, I would prefer to remove that span * asap as from one perspective in this discussion that point was not mentioned is, that all users which uses screenreaders have with the current solution a problem that they only "hear" The field title and the content "star" which has nothing todo with the required aspect of that field.

Instead, using the required atribute, is help those programs to give more information about what the user have to fill out, give them a chance to optimize the Layout on client site, etc Those attributes like input type="[number|date|etc]" in HTML5 , more gives the Browser and mobile clients a chance to change to right input layout, check the validity and range.. To increase the accessibility for disabled visitors take more advance than just leaving that span * for BC...

Just my 2c

@bluezeyes Thank you! This is probably the best argument presented in this thread, * is not an accessible solution to the problem of informing a user about required fields.

Closing as this issue have the Re-evaluate for v4.0 label