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

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented

subscribing

boombatower’s picture

boombatower CreditAttribution: boombatower commented
Status: Active » Postponed

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.

rfay’s picture

rfay
Primary language English
Location Palisade, CO, USA
CreditAttribution: rfay commented
Title: Add CSS parsing capability to Simpletest » Add CSS parsing capability to Drupal
Component: simpletest.module » base system

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.

boombatower’s picture

boombatower CreditAttribution: boombatower commented

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.

boombatower’s picture

boombatower CreditAttribution: boombatower commented
Status: Postponed » Active

Based on #3 this should not be postponed if we put in base system.

RobLoach’s picture

RobLoach
he/him
CreditAttribution: RobLoach commented

BAM!

rfay’s picture

rfay
Primary language English
Location Palisade, CO, USA
CreditAttribution: rfay commented
Version: 7.x-dev » 8.x-dev
Priority: Normal » Critical

#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.

casey’s picture

casey CreditAttribution: casey commented
Issue tags: +CSS aggregation

subscribing

I am working on a fix for several issues with the CSS aggregator: #641472: Fix CSS Aggregator.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented
Priority: Critical » Major

Downgrading all D8 criticals to major per http://drupal.org/node/45111

Jacine’s picture

Jacine
she/her
Location New York
CreditAttribution: Jacine commented

subscribe :)

mattyoung’s picture

mattyoung CreditAttribution: mattyoung commented

~

MustangGB’s picture

MustangGB CreditAttribution: MustangGB commented

Subscribe

jensimmons’s picture

jensimmons CreditAttribution: jensimmons commented

subscribing

jason.fisher’s picture

jason.fisher CreditAttribution: jason.fisher commented

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?

Jeff Burnz’s picture

Jeff Burnz CreditAttribution: Jeff Burnz commented

Subscriben....

danillonunes’s picture

danillonunes CreditAttribution: danillonunes commented

Subscribe.

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers commented
Version: 8.x-dev » 9.x-dev

This would almost certainly qualify as a feature, not a task. Writing this is a huge undertaking, and the probability of this being a very expensive way of doing CSS aggregation (even though it could then be smarter) is very high. As such, this would increase risk of delayed D8 release, so moving to D9.

I'm also very tempted to simply close this; now that we have #352951: Make JS & CSS Preprocessing Pluggable, it's possible to just plug in much smarter, non-PHP CSS minifiers if a site owner wants to do that.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented
Version: 9.x-dev » 8.1.x-dev
Issue summary: View changes
Status: Active » Postponed (maintainer needs more info)
Issue tags: +Needs issue summary update

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

smustgrave CreditAttribution: smustgrave at Mobomo commented
Status: Postponed (maintainer needs more info) » Closed (outdated)

Since there hasn't been any movement since moving to PNMI 8 years ago moving to outdated.

Should also be noted simpletest is no longer used.

If you feel it's still an issue please feel free to reopen with an updated issue summary