Manual talk:Coding conventions/CSS/Archive 1

Comments about colors
Does it make sense to anybody but me to demand writing comments about numbered color values in CSS? --Amir E. Aharoni (talk) 19:35, 25 July 2012 (UTC)


 * Everyone who writes CSS probably knows what #000 and #FFF stand for, but I for one don't know that #C71585 stands for "MediumVioletRed" without looking it up on the English Wikipedia (or some other CSS resource). So yes, I wholeheartedly support using comments to write out the color name in plain English. After all, comments are cheap, just like space. --Jack Phoenix (Contact) 13:55, 26 July 2012 (UTC)

LESS
The LESS section is more a guide about LESS than a coding conventions set of guidelines.

Someone has an objection to move most of the section to a Manual:LESS page? --Dereckson (talk) 21:32, 30 October 2013 (UTC)

Prefix mixins with mixin- ?
It's hard to distinguish .foo { } with .foo { .foo; } especially if you are new to LESS. I think it would be in everyones interest to prefix all mixins with mixin- to help with readability and to place mixins at the top of a file. e.g. .mixin-foo { } .foo { .mixin-foo; }

Thoughts? Jdlrobson (talk) 22:25, 7 August 2014 (UTC)
 * +1. You've convinced me this is a good idea. I don't have a strong preference on the prefix, or whether mixins have to go in the top of the file.  But it seems like a useful convention overall. Superm401 - Talk 00:03, 9 September 2014 (UTC)

Add spaces around mixin parameters ?
I'm not sure about one of the existing code conventions. I think it is useful to be able to more clearly distinguish between and In the second case we are dealing with a mixin and I would recommend that using spaces would make it clearer. e.g.

Just a suggestion. Jdlrobson (talk) 15:57, 9 April 2014 (UTC)


 * I think that's a very good idea and that, because ResourceLoader is minifying the files anyways, we should also discuss about applying whitespace for CSS property values with brackets like URIs to align CSS brackets notation with PHP and JS Coding Conventions.
 * Citing from W3C – "The format of a URI value is 'url(' followed by optional whitespace followed by an optional single quote (') or double quote (") character followed by the URI itself, followed by an optional single quote (') or double quote (") character followed by optional whitespace followed by ')'. The two quote characters must be the same." Resulting in:
 * --VEckl (WMF) (talk) 14:53, 21 July 2015 (UTC)
 * Agreed, let's update. ESanders (WMF) (talk) 18:19, 2 October 2015 (UTC)
 * --VEckl (WMF) (talk) 14:53, 21 July 2015 (UTC)
 * Agreed, let's update. ESanders (WMF) (talk) 18:19, 2 October 2015 (UTC)

Less and future CSS variable naming convention
We are currently missing a naming convention for Less and somewhen future CSS variables (custom properties). We already have conventions for PHP variables or JavaScript variables. It's time to agree on and implement a CSS/Less variable naming convention.

Throughout projects there's currently a pretty wild mix, for example in Vector:

or mediawiki.ui:

or Minerva:

A new proposal
The duplication of property name and property as variable name in applied property values is IMHO verbose and redundant. I'd propose to take popular and widely-used Emmet (section CSS) as base for shortening of property into consideration. Variables are (with the very exception of calculations and size values) almost always belonging to a certain CSS property, therefore the property doesn't need to be repeated. Even when the variable's value change, it will always be connected to a certain property!

When it comes to the variable names, I'd suggest to follow the same formatting regimen like CSS' built-in and the CSS vars standards document draft and use  as separators. Although camelCase is used across PHP and JS coding conventions, it's not common in CSS. Here's some more food for thought. To the structure of the variable naming, I think it's a good idea, to follow the HTML5 classification, so no, but   and.

CSS namespaces useful?
Naming is hard and designing CSS for scalability is even harder. CSS namespaces (example) have in my experience a great potential to gain speed working with disperse people and projects on front-end. — Preceding unsigned comment added by VEckl (WMF) (talk • contribs) 04:43, 12 September 2015 (UTC)
 * Would "Hungarian notation for CSS" be an appropriate TL;DR summary of that link? Anomie (talk) 13:24, 14 September 2015 (UTC)

Gzip heatmap of lowercase color values
Out of curiosity I wanted to see for myself how lowercased, shorthand notated color values of 2015-08's Vector CSS would look like in gzthermal heatmap, mentioned on color property section on the guidelines article:

How much of this is actually true?
Looking at core and what seem to be best practices in current extensions and skins, a lot of this just doesn't apply, and sometimes for very good reason. So how much of these conventions are, er, actually correct? -— Isarra ༆ 17:42, 30 October 2015 (UTC)
 * What are "sometimes very good reasons" for not applying on which of the topics? Knowledge and best-practices have to be shared before being applied. And even if they are shared, on best-practices like color name guidelines, there's currently no strict enforcement of those conventions. If you find problems within the current conventions, here on the talk page seems to be a good place to raise them. --VEckl (WMF) (talk) 04:39, 5 November 2015 (UTC)
 * So... this page is supposed to be real? -— Isarra ༆ 07:38, 5 November 2015 (UTC)