Posted by rfay on June 17, 2009 at 6:57pm
14 followers
Jump to:
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | base system |
| Category: | feature request |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | active |
| Issue tags: | CSS aggregation |
Issue Summary
CSS tests in simpletest have no way currently of actually parsing the input or output CSS to see what's really going on. Most good testing will require parsing the CSS.
I have not tested it, but I found a GPL CSS parser PHP class at http://www.phpclasses.org/browse/package/1289.html
The issue motivating this request was when I developed a test for http://drupal.org/node/472820, and was constrained to using simple static input and static output test, rather than actually validating that the uncompressed input was semantically identical to the compressed output.
Comments
#1
subscribing
#2
I would really like to build on #340283: Abstract SimpleTest browser in to its own object.
We can split up the CSS parsing as a separate class or section of the Page class which will be much cleaner then dumping it all in DrupalWebTestCase.
#3
It actually turns out that we need CSS parsing for more than just simpletest. To do a reasonable job compressing and aggregating CSS, it has to be parsed. What we're doing now is pretty hacky, as exposed by #544568: CSS aggregation attempts to process @import in comment.
#4
Not sure how good of a job we want to do, but some resources to look at if we want a true parser/tokenizer.
http://csstidy.sourceforge.net/download.php
http://www.phpclasses.org/browse/package/1289.html
http://pear.php.net/package/PHP_CodeSniffer/download/1.2.0a1/
Something like this is much simpler and might be the solution for Drupal:
http://stackoverflow.com/questions/236979/parsing-css-by-regex
I'd be happy to try and write up a patch for this, just need some agreement on the approach to take.
#5
Based on #3 this should not be postponed if we put in base system.
#6
BAM!
#7
#444228: Optimize CSS option causes php cgi to segfault in pcre function "match" points out once again the folly of trying to aggregate CSS using regular expression techniques.
#8
subscribing
I am working on a fix for several issues with the CSS aggregator: #641472: Fix CSS Aggregator.
#9
Downgrading all D8 criticals to major per http://drupal.org/node/45111
#10
subscribe :)
#11
~
#12
Subscribe
#13
subscribing
#14
QueryPath to parse rules into a giant array/list/dictionary tree, then a weighted de-duplication algorithm?
I thnk if you can see each CSS rule as an incomplete transaction, where the selector is the transaction key/ID, the rules are key/values within a specific transaction, and the parsing order is the weight of updates to that transaction, you could then prototype different de-duplication/filtering algorithms of various aggressiveness in a semi-standardized manner. The CSS 'database' should be independent of dedupe or optimization, to allow community modules to improve on or provide algorithms of their own without concern of independent parsing.
Think of the node input filters .. you would want CSS input filters in a similiar vein. Colorizers would be a CSS "input fiter". CSS image-encode-and-embed would be a CSS filter. Filters are then associated with contexts and rules. The parser knows the module that generates each CSS code, so you could have a filter that removes or alters only module-specific or theme-specific CSS.
Thoughts?
#15
Subscriben....
#16
Subscribe.