Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.5.4

Bug #1072 HTML_CSS Not cascading properties
Submitted: 2004-03-25 20:32 UTC
From: jausions Assigned: thesaur
Status: Closed Package: HTML_CSS
PHP Version: Irrelevant OS: All
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 42 - 7 = ?

 
 [2004-03-25 20:32 UTC] jausions
Description: ------------ The package is not cascading style when a "selector" is part of a group. Reproduce code: --------------- <?php require_once('HTML/CSS.php'); $oCSS = new HTML_CSS(); $sCSS =<<<__CSS__ p { font-family: Arial; } p { font-family: Courier; } p, td { font-family: Times; } td p { font-family: Comic; } __CSS__; $oCSS->parseString($sCSS); echo $oCSS->getStyle('p', 'font-family'); ?> Expected result: ---------------- Times Actual result: -------------- Courier

Comments

 [2004-03-25 20:40 UTC] jausions
Just a note: when fixing that bug, one should keep in mind that the properties should be cascaded in the order they were declared. Therefore, the properties should be updated when being parsed and not when generated, IMHO. -Philippe
 [2004-03-25 21:06 UTC] thesaur at php dot net
That is because groups are always listed initially. When implementing CSS, it seems illogical to insert a selector group declaration after declaring settings for individual selectors. Considering your example, I can see why someone would implement a group of selectors prior to tweaking it individually. The CSS in your example, of course, is ficticious and serves merely as an example of the problem. However, when someone declares a group in real life subsequent to defining individual properties, I assume they have merely confused the order of declaring them. The individual tweak is therefore left intact and the groups are output first. I am planning to add an HTML_CSS_Advanced class, which will allow maximum flexibility at the cost of comfort. It will perhaps not allow for removing or altering values, but they can be redefined. All will be output precisely as the developer inputs it. That will probably be implemented in 0.6 or so. No guarantees. At any rate, it will be implemented before the package goes stable. However, I recognize the problem as far as parsing a string is concerned. I will modify the parseString method to attempt to correct the problem. I will implement a check to see if one of the selectors already has the values set and will then unset them. Unfortunately the class is not yet advanced enough to return values in selector groups when merely the selector is specified. It seems that the solution would be to build a registry of which selectors are contained in which group, the latest group declaration overriding previous group declarations, of course. This will be on the list for the 0.4.0 release. If I fix it before then, of course, it will be released in the normal succession of releases. - Klaus
 [2004-04-27 03:51 UTC] dufuz
Just want to point out that it should give back Times ;) Since your just saying it like this: p use Arial, p use Courier, p and td use Times p with in td use Comic So Times is right ;) Unless I'm not getting the point of this one
 [2004-05-19 17:41 UTC] thesaur
This bug has been fixed in CVS. In case this was a documentation problem, the fix will show up at the end of next Sunday (CET) on pear.php.net. In case this was a pear.php.net website problem, the change will show up on the website in short time. Thank you for the report, and for helping us make PEAR better. This will be included in tomorrow's release. parseString and getStyle both work as expected.