Description: ------------ When writing output from an HTML_CSS object instance by explicitly or implicitly (e.g., from HTML_Page2), the styles involving multiple selectors (what the HTML_CSS API calls "group styles", e.g. "* body #right") are written out before the styles with a single selector (e.g., "body"). This is completely independent of the order in which those styles were added to the HTML_CSS object. Why is this a problem? Because relative ordering between single and group styles (such as the IE Star Body Hack) is often used in an attempt to work around defects or limitation in certain widely-used browsers. Any reordering of those rules through a mechanism such as PEAR's HTML_CSS class destroys the CSS author's ability to achieve the intended results. I recognise that this defect in HTML_CSS is unlikely to be fixed without serious redesign and reorganisation of the existing code. Specifically, a more object-oriented approach, with "single selector styles" and "group styles" deriving from a single CSS_Style class, a container of which is used by HTML_CSS to contain all styles added to the HTML_CSS object instance, properly implemented, would have prevented this from occurring. Additionally, having more self-contained "Style" objects would have made reuse (of individual styles and groups of styles) much easier. As it is, the interface to HTML_CSS is largely procedural, making it difficult to efficiently break out reusable objects in client code. Reproduce code: --------------- I have produced a small writeup at http://www.seven-sigma.com/pear_css_bug/ which demonstrates a simple HTML three-panel page based upon an example at http://glish.com/css/7.asp. Particularly interesting is this code fragment: $CSS1 = &new HTML_CSS(); /* ... */ $CSS1->setStyle( '#right', 'position', ' absolute' ); $CSS1->setStyle( '#right', 'right', '0px' ); $CSS1->setStyle( '#right', 'top', '100px' ); $CSS1->setStyle( '#right', 'background', '#fff' ); $CSS1->setStyle( '#right', 'border', '1px solid #000' ); $CSS1->setStyle( '#right', 'padding', '0px 5px' ); $CSS1->setStyle( '#right', 'width', '200px' ); $BodyRightGroup = $CSS1->createGroup( "* body #right" ); $CSS1->setGroupStyle( $BodyRightGroup, 'width', '189px' ); $CSS1->setGroupStyle( $BodyRightGroup, 'background-color', 'lightgrey' ); /* ... */ /* IE 5.5 */ $CSS1->setStyle( '#header', 'height', '81px' ); $CSS1->setStyle( '#header', 'border-top', 'solid #000' ); $CSS1->setStyle( '#header', 'border-right', 'solid #000' ); $CSS1->setStyle( '#header', 'border-left', 'solid #000' ); $CSS1->setStyle( '#header', 'voice-family', '"\"}\""' ); $CSS1->setStyle( '#header', 'voice-family', 'inherit' ); /* IE 6 */ $CSS1->setStyle( '#header', 'height', '99px' ); /* ... */ $Page = &new HTML_Page2(); $Page->addStyleDeclaration( $CSS1, "text/css" ); That code fragment is seriously distorted in the output from HTML_CSS, such that the 'height' style is written only once (with value '99px', the last value specified)) and the similar elision of the 'voice-family' style. Expected result: ---------------- The expected result of writing out the contents of an HTML_CSS2 object should be, at least by default, the reproduction of each style group and rule specified, in the order specified, with "duplicate" style specifications preserved in the order specified by the code. /* ... */ #right { position: absolute; right:0px; top:100px; background:#fff; border:1px solid #000; padding: 0px 5px; width: 200px; } * body #right { /* ... */ /* IE 5.5 */ height:81px; border-top:1px solid #000; border-right:1px solid #000; border-left:1px solid #000; voice-family: "\"}\""; /* kills IE5.x parsing */ voice-family: inherit; /* fixes everybody else */ /* IE 6 and the rest of the world */ height: 99px; /* height for compliant browsers */ } Actual result: -------------- In the verson of the page using an HTML_CSS object instance to write style information inline (at http://www.seven-sigma.com/pear_css_bug/test-object.php ), all group styles are listed before single styles. This is dreadfully unacceptable, as explained above. The code fragment quoted earlier is rendered in the output as follows: /* ... */ * body #right { width: 189px; background-color: lightgrey; } /* ... */ #right { position: absolute; right: 0px; top: 100px; background: #fff; border: 1px solid #000; padding: 0px 5px; width: 200px; }

Hi, I do not that it is a bug. In fact the voice-family is a hack for ie. and pear HTML_CSS just manage the best way he css, it does not have to take care of browsers incompatibility, but must me compliant to the CSS standard.And it is. Hope that M$ will solve their ie bug is most important, than modifying the HTML_CSS class...

Klaus, I think you'd probably want to be able to dump raw CSS at both ends of the file, something like a 'setRawCssAtTop()' and/or 'setRawCssAtBottom()' pair of methods. Unless I'm missing the point entirely and you're talking about just *replacing* the output from the styles array with the new 'raw CSS'? If this is a supplement rather than a replacement, I'd argue for naming the new method to indicate where in the CSS its output will be dumped. And can someone please explain to me (off list) why the group styles are treated separately from the single element styles? It seems to me that a) if this was all in one array, it would make this whole problem go away and b) that if you wanted to handle *processing* separately, you could make two passes through the combined array. And that still doesn't solve the issue of one style being specified more than once, as with the #header selector's 'height' style in my example stylesheet ( http://tinyurl.com/4zc4y ).

Just a quick followup to an earlier comment - people who know me know that I'm no fan of Microsoft for any number of reasons, especially quality issues, but saying things like <em>"Hope that M$ will solve their ie bug is most important, than modifying the HTML_CSS class"</em> is just plain disingenuous. HTML_CSS, like PEAR, like PHP itself, is a <em>tool</em> for building a particular class of artifact, a browser-based application. While MS may have the most obsolete, least W3C-standards-compliant browser in current use, it is the <em>predominant</em> browser in current use. Knowingly writing or using code that is known to break the 900-pound gorilla of HTML clients is a good way to tick off your actual and potential clients who are saddled with using the ruddy thing. One of these days, they will join The Enlightened Few (currently)) who use a proper, standard-compliant, easy-to-code-for browser, but until IE usage drops by an order of magnitude or so, we're stuck with having to support it as well as the clients we'd "like" to support. Historically, there have been two ways to accomplish this, both of them bad. One is to write a single style sheet that, by careful ordering and knowledge of browser-specific defects and quirks, manages to give acceptable output on both compliant browsers and Internet Exploder. That was the genesis of the current bug; taking a pure HTML/CSS demo page and rewriting it as an HTML_Page2 / HTML_CSS PHP script. (The other, of course, is to use something like Net_Useragent_Detect and multiple style sheets - I used to use one for IE, one for Netscape 4, one for Opera, and one for everything else. Blech.)