- From: Matthew Brealey <thelawnet@yahoo.com>
- Date: Wed, 26 Jan 2000 04:25:15 -0800 (PST)
- To: www-style <www-style@w3.org>
<blockquote> outside The marker box is outside the principal block box. Note. CSS1 did not specify the precise location of the marker box and for reasons of compatibility, CSS2 remains equally ambiguous. For more precise control of marker boxes, please use markers. </blockquote> AFAICT, all this sentence leaves to the UA is the vertical alignment of the marker box (since the horizontal offset is left to the UA by reason of marker-offset anyway), and it is not possible to make any working implementation that doesn't adopt the spec (which states that that the baseline of a marker box should be aligned with the baseline of the first line box in its principal box). - once you have a definition of a marker box, the 'location' sorts it self out. I feel that what was actually meant was: <blockquote> outside The marker box is outside the principal block box. Note. CSS1 did not specify the precise definition of a marker box and for reasons of compatibility, CSS2 remains equally ambiguous, at least in respect of marker boxes generated by elements with display: list-item. For more precise control of marker boxes, please use markers. </blockquote> , which is much closer to the truth. In any case, it was a mistake to retain ambiguity where no ambiguity could usefully be retained - clarifying the spec would have served only to improve the quality of future user agents by standardising practice, while the only effect on older user agents would be to retrospectively render them incompliant (it is hardly as if this hasn't happened before). Clarification cannot cause problems with older user agents - it is only a change that can cause this. As a result, I would suggest the following changes: <blockquote> outside The marker box is formatted in the same way as :before (or :after depending on text directionality) {display: marker}. inside The marker box is formatted in the same way as :before (or :after depending on text directionality) {display: inline}; however, user agents SHOULD give the marker box padding or margin (note that it makes no difference since they will both be transparent as you cannot specify the styles of marker boxes created by display: list-item). </blockquote> I would also propose a change in: marker-offset Applies to: elements with 'display: marker' to marker-offset Applies to: elements with 'display: marker' and 'display: list-item' and: Percentages: N/A to: Percentages: refer to width of principal block box In addition: <blockquote cite="http://www.w3.org/TR/REC-CSS2/generate.html#before-after-content"> The formatting objects (e.g., boxes) generated by an element include generated content. So, for example, changing the above style sheet to: P.note:before { content: "Note: " } P.note { border: solid green } would cause a solid green border to be rendered around the entire paragraph, including the initial string. </blockquote> This fails to define the rendering of P.note:before { content: "Note: " ; display: block} P.note { border: solid green } - does the border cover the block before. The spec does not say whether it does. Clearly the best answer is no, but on the basis that it is also possible to infer the opposite conclusion, the following examples (or words to the same effect) are omitted: <EXAMPLE> P.example:before {display: block} would produce markup like this: <BEFORE> </BEFORE> <P> </P> whereas P.example:before {/* display: inline implied */} would produce: <P> <BEFORE></BEFORE> </P> In both cases, inherited properties are 'inherited', even though in the former case the BEFORE is not a descendant of the P element. </EXAMPLE> ===== ---------------------------------------------------------- From Matthew Brealey (http://members.tripod.co.uk/lawnet (for law)or http://members.tripod.co.uk/lawnet/WEBFRAME.HTM (for CSS)) __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Received on Wednesday, 26 January 2000 07:25:16 UTC