elements.css css lint fix

Same as #2422381: elements.css css lint fix bartik

This seems a bit wasteful to me... maybe don't believe all csslint's recommendations? Judgement call on this one needed.

With the duplicate properties, there is more chance of inconsistencies.

Change of heart here too:

• It helps be consistent with CSS lint
• The margin should probably be not based on the font-size anyways, so that should change for better Vertical Rhythem later, so they will or could be different.
• And the inherit change is just one property so feels a bit wasteful at that point.

Reading #2222049: Add a .csslintrc file that's in line with our CSS standards, the issue summary says duplicate-properties - true .
However, @sqndr changed that to false in his patch, and never updated the issue summary.

We should switch that back to true, and close this issue.

@LewisNyman, can you confirm and close? And is that true for your "lint trap" site?
http://lewisnyman.co.uk/drupalcore-frontend-toolkit/

In the #2222049: Add a .csslintrc file that's in line with our CSS standards, the original suggestion was always intended to be the beginning of a discussion. I think that we should reassess which CSSLint rules we follow and which ones we don't as we refactor the code.

I don't want to be bound by previous decisions, especially when the original issue was very quiet. We've discussed the intentions of this csslint rule in detail and I think it fits with the intentions of our CSS standards. I think we should keep the rule in place and commit this issue.

And is that true for your "lint trap" site?

The linting workflow pulls the configuration in the .csslintrc file in HEAD, see: https://github.com/lewisnyman/drupalcore-frontend-toolkit/blob/master/gu...

We've discussed the intentions of this csslint rule in detail

Where is this discussion posted? I could not find any links to it on the issue that added the .csslintrc file.

Ah yeah sorry, we discussed the same changes in this issue: #2422381: elements.css css lint fix bartik

I think blindly following some of these upstream rules without wide community discussion is wrong, and defeats the purpose of having a community CSS standard.

But that's apparently just my opinion.

I think blindly following some of these upstream rules without wide community discussion is wrong, and defeats the purpose of having a community CSS standard.

Do you mean wide discussion in #2222049: Add a .csslintrc file that's in line with our CSS standards? I agree, that's why it's good that we question/discuss these rules in issues like #2422381: elements.css css lint fix bartik.

The issues Tim's raising have been raised in multiple other issues. However, consensus in other issues has been to go ahead with csslint. I'm intending to commit these patches to get them out of the way, so we can then take a broader look and see where we're at. If it turns out this is causing more harm than good, we can adjust. I do know jslint has been really helpful, especially considering most Drupal people are not JS people (nor are they CSS people).

Committed and pushed to 8.0.x. Thanks!

However, consensus in other issues has been to go ahead with csslint.

Ah maybe I understand the concerns a little better today, the aim is not to follow csslint blindly, only to use csslint as a tool to help contributors follow our agreed CSS standards. That was the intention behind #2222049: Add a .csslintrc file that's in line with our CSS standards and something we can continue to refine as we move forward in these issues. A good example might be the !important rule, which sounds good in theory but there are actually some parts of the SMACSS methodology that allow !important:

Since the state will likely need to override the style of a more complex rule set, the use of !important is allowed and, dare I say, recommended. (I used to say that !important was never needed but on complex systems, it is often a necessity.) You won’t normally have two states applied to the same module or two states that tend to affect the same set of styles, so specificity conflicts from using !important should be few and far between.

With that said, be cautious. Leave !important off until you actually and truly need it (and you will see why in this next example). Remember, the use of !important should be avoided for all other rule types. Only states should have it.

If we follow CSSlint without questioning it, we would be acting against our agreed CSS standards, so in this situation that best thing to do would be to modify the .csslintrc file to remove this rule.