Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
CSS
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
20 Mar 2014 at 10:44 UTC
Updated:
13 Aug 2015 at 19:04 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
lewisnymanComment #2
lewisnymanI've added a list of all default rules to the issue summary. We can go through each one and decide if they are off, warning, or error. We can even write our own tests later :)
Comment #3
mgiffordThis sounds like a really amazing idea. Could go a long ways to help manage all the CSS files in Core and later in Contrib.
Comment #4
yesct commentedComment #5
sqndr commentedI've created a
.csslintrcfile with all the rules above as false as a default for now..csslintrc:
I did not create a patch yet, since I have no idea where this file should go? Any suggestions on a good location? Anyway, seems like we also need to sort out what rules are important for the Drupal css. Let's get this discussion going!
Also ... Once the file is in core, I feel like we need some really good documentation on how to use this!
Comment #6
Anonymous (not verified) commentedYou just need to create the patch in the root folder, alongside .jshintrc (which will soon become .eslintrc, but that's by the by).
Re: documentation, definitely. There's a lot we could wiki-fy for frontend tooling.
Comment #7
sqndr commentedRight, here's a first patch. Again - this is with all rules set to false at the moment.
Comment #8
lewisnymanComment #9
lewisnymanI've updated the summary and marked true/false against all of the rules. You can view the documentation for every rule here:
https://github.com/CSSLint/csslint/wiki/Rules
I think we're ready to commit this. If someone strongly disagrees with one of these rules they are easy to change. It would be great to make CSS lint a formal part of our review process.
Comment #10
sqndr commentedThe things left to do would be to:
- Create a patch
- Update the documentation.
Comment #11
sqndr commentedI'll mark this as novice. Creating the patch seems like a novice tasks.
Comment #12
Michael Hodge Jr commentedComment #13
Michael Hodge Jr commentedI went ahead and applied the patch in #7 against HEAD. I then modified the .csslintrc to match the statuses in the issue summary. Attached is that patch and the interdiff.txt.
Comment #14
Michael Hodge Jr commentedComment #15
lewisnymanIt seems like the current npm version of csslint (0.10.0) does not support json .csslintrc files but 0.10.1 does.
I had to create a small gruntfile to test this, as you can pull in the options as json in the csslint grunt task
I've attached the output of the grunt task with and without this patch, the diff between files wasn't that helpful but it's clear just from the file sizes alone that it's picking up our options.
I don't there's anything else to do here, I've attached a patch that contains the grunt task if anyone else wants to test. Finally, I've reuploaded the patch from #13 but without 'do-not-test' so we can get some green and RTBC.
Also, I found a really good example file: https://github.com/birkestroem/plopjs/blob/master/images/csslint.json
Comment #16
alexpottSo yay +1 to this. It is such a shame that the csslint shipped by npm does not (yet) support the json rc file. Having to create a local grunt project to test this is a big -- and will make integration into my pre commit hooks unnecessarily complex.
I think this patch should also fix all the errors. Since there is no point having an automated standard that we are not applying.
Comment #17
lewisnymanThanks Alex, we already have a meta to fix csslint errors #1190252: [573] Use csslint as a weapon to beat the crappy CSS out of Drupal core. I think this issue helps make that meta more achievable. It feels impossible to fix all the csslint warnings in one issue, and accurately testing for visual regressions across the whole of core, I can't see this issue ever being committed with that approach.
I'm happy to get a few more opinions in here.
Comment #18
alexpottOkay - we can always remove this before release if we don't get it done.
Committed 5f37ebc and pushed to 8.0.x. Thanks!
Comment #21
alexpottDiscussed with @xjm, @catch, @effulgentsia and @webchick - we decided that it was okay to leave in core even if core does not comply. Removing tag.