Closed (outdated)
Project:
Drupal core
Version:
8.4.x-dev
Component:
CSS
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
16 Apr 2015 at 20:49 UTC
Updated:
12 Sep 2017 at 18:48 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
martin107 commentedIf you look at the last patch from this issue you can see it creep in
looks like it has been hiding since March 31, 2015
so it can't be a big issue :)
Comment #2
martin107 commentedOver in #2472269: Fix syntax errors in Drupal\Component\Plugin's composer.json, Add test
when a syntax bug was discovered in a json file the response was
The next natural question is can we do this for css - as usual stackoverflow has asked the question already
http://stackoverflow.com/questions/3330571/how-can-i-validate-css-within...
If someone can point me a css syntax checking tool ( from within php ) then I will write the test.... how is that!
Comment #3
martin107 commentedchanging component to css
Comment #4
attiks commentedI ran grunt csslint on all css files, output added below, limited to core css
Comment #5
attiks commentedIf you want to run this as well you need the following:
Run
npm install grunt-contrib-csslint --save-devin the root directoryGruntfile.js and .csslintrc in attached zip, extract inside the root directory
Run
grunt csslintto testComment #6
attiks commentedThis is already covered in #2408525: Rewrite Views UI CSS inline with our CSS standards - Part 1
For testing there's https://github.com/lewisnyman/drupalcore-frontend-toolkit
Comment #7
attiks commentedThis is already covered in #2408525: Rewrite Views UI CSS inline with our CSS standards - Part 1
For testing there's https://github.com/lewisnyman/drupalcore-frontend-toolkit
Comment #8
martin107 commentedThanks @attiks
I run something similar ... on my own work - Mostly as it bites me in the bum every day!
I am reopening this as there are 2 things that #2408525: Rewrite Views UI CSS inline with our CSS standards - Part 1 does not cover.
1) The syntax bugs identified here are not coding standard refinements - and need fixing in their own right.
2) The real advantage of a phpunit integration test is that, front-end or backend, it stops ALL developers, myself included, from submitting corrupted files.
I will try and find sometime this weekend.
Comment #9
attiks commentedTrue, good reasons to reopen, I'll ping Lewis on Twitter, he might have ideas for testing.
Comment #10
lewisnymanOk that sounds really good! If we could catch these major errors automatically that would be good.
Comment #11
martin107 commentedTo answer my own question from #2 - I have had more time to search for a solution
There is a php library,
https://github.com/sabberworm/PHP-CSS-Parser
When I run through a standard checklist asking is is safe to pull in the library ... well the responses are not great
1) Are there recent maintenance updates ..evidence for widespread support.
Err not really.
2) What are the terms of the license
PHP-CSS-Parser is freely distributable under the terms of an MIT-style license.
Copyright (c) 2011 Raphael Schweikert, http://sabberworm.com/
I'm not sure if this would conflict with any of Drupal's in-take conditions - can someone else speak to that?
3) does it work ?
It has the potential to meet our needs
$oCssParser = new Sabberworm\CSS\Parser(file_get_contents('somefile.css'), Sabberworm\CSS\Settings::create()->beStrict());
can be used to reject files with syntax errors.
Changing the subject completely
can I take the legs away from one of my arguments #8.1
After reading the related issue I have confidence the syntax error will be dealt with elsewhere in a more community orientated way. That is I plan to help out in the appropriate issue.
So barring the location of a well supported php library - I find myself looking for other ways to block css files with syntax error from ever being RTBC'ed.
I think there is a initiative to improve testbot -- by using jenkins/travis instead of the current testbot.... I need to find out more...
but if that is the case then csslint could be run as part of the review process... it would be annoying to have more than one arbiter of syntactically correct css .. as it is just going to lead to a bikeshed moment when the two standards disagree.
Comment #12
martin107 commentedComment #13
martin107 commentedadding https://www.drupal.org/project/drupalci to the issue summary
Comment #18
martin107 commented