Simon Montagu wrote:

> STH wrote:
> 
> 
>>I looked around for a matrix of what is currently implemented from CSS 2
>>but didn't see one.  This question may be answered elsewhere.  Please
>>forgive me if I'm rehashing old ground.  I have been trying to create a
>>CSS file for the DocBook 4.1.2 XML DTD ( http://www.docbook.org ) and
>>realized the usefulness of having the "\A" described in 12.2 of the
>>CSS-2 spec
>>( http://www.w3.org/TR/REC-CSS2/generate.html#content ).  I've noticed
>>that this particular CSS feature seems not to be supported by Mozilla as
>>of the time of this message.
>>
>>I'd like to know the following:
>>
>>Is there a plan to support this "\A" functionality?
>>
>>Is there a place to look for what CSS functionality is and is not supported?
>>
>>Is anybody familiar with examples of CSS applied to DocBook?
>>
>>I know Norman Walsh has provided some XSLT for processing DocBook into
>>html, etc.  That isn't really what I want.  I want the XML to be
>>rendered by the browser using an existing style sheet and no translation.
>>
>>TIA,
>>
>>STH
>>
> 
> There are a few bugs on this issue, all resolved as INVALID or WONTFIX:
> 
> Quoting from Ian Hickson in
> http://bugzilla.mozilla.org/show_bug.cgi?id=56956#c2:
> 
> 
>>... we are using a "progressive" interpretation of the CSS
>>specification that says that the white-space property applies to generated
>>content and, since it is set to 'normal' by default, we will ignore line feeds
>>
> 
>>such as that introduced by \A. To fix this, set:
>>   *|*:after, *|*:before { white-space: pre; }
>>...in your stylesheet.
>>
> 
> Simon
> 
> 


I guess I can try the proposed workaround, though I don't fully 
understand what it means.  In general this is dissapointing.  Trying to 
work around this was very costly in terms of time spent.  From this 
user's perspective, full compliance should be a mantra when it comes to 
w3c standards.  I understand the world looks different from the POV of 
the developer.  Nonetheless, it can be a killer when a person is trying 
to use a technology and the specified behavior is not functioning.  If I 
have three days to find a solution and document it using XML, and I 
spend one of those days trying to work around a shortcoming such as 
this, the value of the XML technology is greatly diminished.

I hope I don't sound too critical.  I'm not saying I could do any better 
than the people who actually write the code.  If I could, I'd shut up 
and fix the problem myself.  What I'm saying is, these little things can 
have a big impact on the success of a product or technology.


STH


Reply via email to