Re: [CSS21] 'page' and 'size' removal

On 2/25/03 2:23 AM, "Christian Roth" <roth@visualclick.de> wrote:

> 
> Tantek Çelik wrote:
> 
>>>  They will still appear in the relevant CSS3 module, most likely.
>> 
>> Most likely yes.  They may be improved in response to analyses made since
>> CSS2 was published.
> 
> I am assuming that stylesheets written to the CSS2 spec will not break in
> a future incarnation of CSS by giving properties that were meanwhile
> (=CSS 2.1) defunct different semantics than they had in CSS2. Is this correct?

Your question does not make any sense, because you cannot break something
that was never implemented by any UA.


> Maybe a little background for my question is in order:
> 
> I am working on a CSS based product (so I am an implementor) that is near
> release (within 1 month). I'm using 'size' for specifying the paper size,
> custom page selectors for distributing document contents on differently
> sized/margined pages along an XML instance document and the 'widows'/
> 'orphans' properties for specifying if widow-/orphan-control is to be
> turned on in the rendering engine (value >= 2) or not (< 2). I am aware
> of the fact that the rendering engine (which is out of my control) does
> not support the full semantics of each of these properties, but based on
> the declaration the best approximating configuration is used.

It is worse than that.  It is not just "not support the full semantics" - I
don't think there is any rendering engine support for these properties at
all.


> Checking our implementation just recently against the CSS21 WD, I found
> that the mentioned properties are to be dropped. So my question simply is
> whether I should make them proprietary properties (see my earlier
> questions on this issue) prior to release to decouple them from any
> further work done on CSS in the paged media realm, or if we can leave
> them as is without fear to have them semantically clash in the future,
> when stylesheets written for our product (an XML+CSS-to-RTF converter)
> will/should be used unchanged with other, possibly future products.

In my opinion it is very bad to export (output) properties which do not
currently work in implementations.

You have no way of verifying that you are exporting something that makes any
sense.

Authoring tools should NOT export tags, properties, values etc. that are not
properly supported by implementations already, because premature export of
these kinds of things can result and has resulted in "broken" content, whose
"broken-ness" is only revealed once implementations actually start
implementing those features, which actually then prevents implementations
from properly implementing those features due to the presence of legacy
broken content etc. etc.

In otherwords, by prematurely exporting 'widows' and 'orphans' properties
from your tool, you may actually be destroying the future possible use of
those properties.

For any property for which you are *not* testing against implementations
(e.g. those paged media properties), I think it is much safer to use
something with a vendor prefix for your own purposes.

Even more conservatively, you could avoid using any properties which lack
W3C test suites with test cases for them.

Then when those properties are finally properly tested, implemented,
errata'd, if there are any differences between what they do and what you
originally implemented, you can simply account for that in your
implementation (rather than the impossible task of having to go around
fixing up all the broken documents that have been exported up to that
point).

> As to the decision why we're using CSS when we could have used XSL-FO: At
> the time of project start (March-02) an estimated 90% of what needed to
> be expressed was in CSS2. We discussed the approach of a proprietary
> style language, but finally settled on CSS as documentation and knowledge
> regarding syntax and semantics was considered widespread. The 10%
> proprietary properties are essentially specific rendering hints for the
> RTF back-end to make the resulting document more accessible to editing,
> as well as stand-in's for missing paged media properties for rendering
> e.g. footnotes, headers/footers and references. UAs that do not
> understand our proprietary properties will still be able to render the
> document without major visual discrepancies (except for footnotes,
> headers and footers, but I guess there isn't any UA supporting them since
> they are not yet defined).

That seems reasonable.  In general I think it is better to avoid properties
that lack any UA support, or, if you must use such "work in progress"
properties (which much of CSS2 can still be considered), use them with a
vendor prefix, e.g. -foocorp-orphans

All that being said, you could help move things along by reviewing the CSS3
Paged Media draft, and the proposals for footnotes etc. and provide feedback
to this list.  Better yet, consider joining W3C (I didn't check to see if
you were already a member), and working directly on such drafts/proposals in
the CSS working group.

Thanks,

Tantek

Received on Tuesday, 25 February 2003 15:28:57 UTC