Hi,
in 2013 i have open a similar PR / FT
FT
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31135&start=0
Joomla Dev CMS:
https://groups.google.com/forum/?hl=en&fromgroups#!topic/joomla-dev-cms/jo5pFTx4gpE

After this i have release a simple Plugin that do this job.

You can see here:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31135&start=0 (last comment)
or direktly here:
http://www.jah-tz.de/joomla-custom-css-plugin-joomla-3.html (german)
http://translate.google.de/translate?hl=en&ie=UTF8&prev=_t&sl=de&tl=en&u=http://www.jah-tz.de/joomla-custom-css-plugin-joomla-3.html (english)

Also you can find some similar plugins at the JED.

This is a small and simple change with little risk, so I am not clear why there should be any issue with implementing it.

Yes.

Personally I prefer a plugin/module approach here. You even get more flexibility here, especially if using a module because you can only apply certain styles to specific menu items.

If we merge this, it would be kind of an undocumented feature which then only a few would use.

A. There are (as far as I can find) two extensions - the one @zero-24 mentions above (which is not in the JED and not available in english - which I am therefore not as comfortable about as I would really like) and the Custom CSS extension which puts your .css into a module (which presumably means it is sent to the browser in HTML with every page rather than cached locally like a custom.css file would be).

Using a plugin extension seems to me to be a much more complex solution than this PR to a simple requirement for a an ability to provide a global css tweak to a template.

B. custom.css is in fairly common usage - so many people will expect this to be available - and it is only undocumented if it is ... um ... undocumented, easily fixed with a couple of lines in the Joomla documentation as well sites like stackoverflow documenting it which are then easily found in google.

P.S. Does anyone know what the purpose of locale-based css files is? I don't understand why we have these but there is such resistance to having a custom.css.

@Sophist-UK

(which is not in the JED ...

This is true. Is there any problems?

... and not available in english ...

This is not true. (only the website is not english)

... which I am therefore not as comfortable about as I would really like)

hmm don't understand this point. It implement your if statment you want to have into the core. With this plugin you can use it at every template (Backend and Frontend)

A. There are (as far as I can find) two extensions

There are two categories which both contain several extensions which I think will allow you to do what you want.
http://extensions.joomla.org/extensions/core-enhancements/coding-a-scripts-integration/head-code
http://extensions.joomla.org/extensions/style-a-design/templating

I didn't check which of them also work for the backend. However it should be easy to adjust an existing extension to allow it if needed. Maybe the developer would even add it as feature.

P.S. Does anyone know what the purpose of locale-based css files is?

The purpose is to provide language specific CSS rules I guess.

I don't understand why we have these but there is such resistance to having a custom.css.

You made a good point with the language CSS files actually. Imho we have to many of those undocumented features already in core which could be solved nicely by using a module or plugin approach. I just don't like it much to add even more of them when there is no real need for it. Like in this case where there are several easy-to-use and lighweight extensions which provide that function.

I agree that extensions are the best approach where the requirement is complex and somewhat niche because the performance hit of an extension would be small by comparison to the impact of putting the code in Joomla core and it doesn't make sense to have a performance hit of the complex code for people who don't need it.

I am less sure that extensions are the best approach for a very simple and generic requirement like this. If we try to provide ALL functionality through extensions, both the server-side performance and network bandwidth are likely to be severely hit.

So an extension to do this simple thing to add a custom.css for the template would need to:

1. Scan the output before it is sent to the browser;
2. See if there is already a custom.css called for the template - ignoring custom.css that e.g. is used for modules.
3. See if there is a custom.css file for the template (is it clear where this would need to be located?)
4. Decide where the last template css file is called in the HTML;
5. Insert a new call to custom.css just after this last CSS file.

Since this is complicated, the extensions previously mention put css code into a module which is sent to the browser on every page load rather than the custom.css file being cached.

So, I believe that some requirements ARE best delivered by changes to core code rather than using plugins, and that this is one of these.

Actually, the easiest extension way would be a module which you load into a module position. It doesn't have to scan anything. It just loads a file into the head. The user even can define the file himself and specify on which page it should be loaded. The module doesn't need to generate any output.
It's actually very easy and doesn't really have a performance impact.

That is true.

I guess the other thing we should strive for is consistency - either all templates have a custom.css or none do.

Agree with striving for consistency, disagree with either all or none.
Consistency to me means you act the same when circumstances are the same. You are turning it into: act the same regardless the circumstances.

That was not my intent.

For me, consistency is about user (i.e. Joomla administrator as well as end-user) expectations - that they should expect the system to operate (in both surface and underlying ways) in a consistent manner so that e.g. (in this example) there either is an ability to use a custom.css file on all templates or there is a well understood approach to need an extension (which might then through market forces narrow down to one of several de-facto extensions for different types of need). In other words, how to do such-and-such should be obvious (either immediately from the UI or easily found in Joomla documentation or a google search).

And that is what the user gets now. It works in a consistent manner. The manner being to leave the technical implementation up to de template developer. Whether and how customizations are implemented is completely his choice. Control is transferred to the template, as is consistent with modules and components.

Whether and how customizations are implemented is completely his choice. Control is transferred to the template, as is consistent with modules and components.

@sovainfo Just to clarify, the proposed code here would only add this function to the administrator templates Isis and Hathor. It has no impact on other templates at all.

@Bakual Understood that. The first time I saw this I agreed with the request. Only after reading and thinking about the complete discussion, I agree with not implementing this. You know how much I like consistency. Was trying to get the point across that doing something differently doesn't mean it is inconsistent. Take off the blindfold and look at things from a different perspective (figure of speach, not meant at you directly).
Implementing it in Hathor but not in Isis wouldn't make it inconsistent to me, because the technical implementations should have that freedom.

Concerning frontend, I have released a while ago a small plugin doing that and also that takes care of RTL vs LTR via a custom.css
http://extensions.joomla.org/extensions/style-a-design/templating/20389

Your plugin is front-end - this PR is for back-end.

Yes, this was to explain that 3rd party extensions can easily be used instead of modifying core.
#4211

For me this is the right approach. It makes no sense at all to distribute a template which CSS you cannot customise minimally without losing your changes on update. This should be in all our frontend and backend templates. With a good documentation about it I'm sure all templates will adopt the same system (a lot of them already do it).

Having to install one extension for this only makes things and site harder to maintain.

So here

@test
Tested successfully

Merged. Thanks!

✋ I know it is bad to comment on an old and closed PR (nice feature, well done guys ? but how should I check if this new feature is documented on the JDocs? @phproberto @Sophist-UK
And would it be better to link the issue to the documentation, even only rough? (at least it is started and can be improved by the JDocs Team).

As volunteers, I suppose that no body likes duplicate work and effort, especially, after having read all the comments here and on the linked issue, before creating the Wiki page. A quick search did not find anything.