- From: Liam R. E. Quin <liam@w3.org>
- Date: Wed, 16 Nov 2016 16:16:59 -0500
- To: www-style@w3.org
I've been trying to compare XSL-FO and CSS and document the things you can do in FO and not in CSS. Here's a comparison of the expresison languages. tl;dr - they're more or less the same but CSS should consider adding the mod operator and some functions, maybe for a level 4? I've given a list of FO functions that I didn't find in CSS. I also included most of the colour ones although I am not sure the differences matter except for the device colour stuff. I did *not* include functions in both, nor functions that are in CSS but not FO, as these aren't a problem for people migrating to CSS. After this I plan to do comparisons of properties and of (most important really) the flow/tree/page models. For this message I primarily used https://www.w3.org/TR/css3-values and https://www.w3.org/TR/xslfo20/#d2e7915 Note: FO 2 isn't a Recommendation but incorporates some errata and is probably more useful to look at than FO 1.1, but is only partly implemented as far as I know. The editor's draft at https://drafts.csswg.org/css-values/ was in sync when I started this comparison and I needed something stable. * The two grammars (Fo expression language for all properties, and CSS calc) are actually pretty close, and issues like needing a space around "-" are pretty much the same in CSS, XPath and FO. The main differences seem to be (1) Every CSS property, when used in XSL-FO, has a value that's an expression and that supports conversion between data types. With CSS you have to use calc() and it's not clear if this is always possible. (2) For XSL-FO 2 the WG had voted to use XPath 2 (or later) for the expression language. This wasn't done because the WG closed, but the reason was that users were wanting considerably more power. The nearest eqivalent for CSS is probably to allow JavaScript functions to be called, presumably only in the "slow" profile. (3) CSS calc() lacks the mod operator and the round() function -- probably an easy addition. FO uses div instead of / for division but I don't consider that important. Similarly percentages are treated specially in CSS and not in FO - features in CSS but not FO don't in general pose a problem for moving to CSS from FO. (4) XPath 2 (instead of the basic FO expression language) would have added sqrt, sin, cos, tan, atan, all of which are likely useful with 2d transformations and with circular displays, as well as min() max() etc. I haven't listed these in the list of missing functions below. (5) XSL-FO was designed to be the output of a transformation (e.g. with XSLT) and no an authoring format. This means that some things are not in XSL-FO because you could do them in XSLT (a bit like e.g. SASS and CSS). An obvious example is the printf-like format-number capability (and in XPath 2 there's also format-date to format dateTime values), and string processing beyond concat(). Probably the use of JavaScript functions would serve the need for now, along with the use of class attributes. (6) Functions and operators not in CSS calc() ============================================= 6.1 numeric mod (operator) floor() ceiling() round() min(a, b) - seems better than using units like vmin/vmax max(a, b) abs() 6.2 colour rgb-icc() icc-named-color() system-color() (e.g. one of the CSS/X "named" colours) cymy-icc-color() cie-lab-color() cie-lch-color() device-gray-color() (uncalibrated) device-rgb-color() (uncalibrate) device-cmyk-color() (uncalibrated) (a note in the FO spec says uncalibrated device colours might be used e.g. to produce patches of colour of known ink density used for quality control) 6.3 Font functions system-font(fontname, property) (the spec doesn't list the available properties and I'm not sure how widely implemented this is; AntennaHouse lists it as unimplemented) 6.4 inheritance-related inherited-property-value(NCName?) - e.g. NCName could be "font-size" label-end(), body-start() - offsets for lists; CSS would use properties if we could agree on them :-) from-parent(name?) - gets the computed value of a property from-nearest-specific-value() - gets the value of a property by looking up the tree from-page-master-region() - Primarily useful if you have flows/regions. You can only use it to get the writing direction (writing-mode and reference-orientation) properties. There's a moderately complicated example in the FO 2 spec for why this matters. This does come up with running headers/footers in CSS, with the element() function, but I think that function is only in the WhatWG draft right now - it's where you can take direction-ambiguous text from elsewhere in the document and you need to say whether the direction used is that of the new destination or of the (inherited) source. from-table-column() - for inheriting from coldefs etc proportional-column-width() - for formtting tables merge-property-values() (listed for completeness; no-one supports it) 7 conditionally XSL-FO allows suffixes .minimum .maximum .optimum .prededence and .conditionality on most spaces, e.g. the spec has, space-before="4.0pt" (like CSS margin-top: 4pt) is equivalent to a specification of space-before.minimum="4.0pt" space-before.optimum="4.0pt" space-before.maximum="4.0pt" space-before.precedence="0" space-before.conditionality="discard" The discard describes what to do e.g. at the start or end of a page - e.g. discard the margin (usually what you eant) or keep it and set a short page. Precedence is used to decide e.g. which element's margin is used (highest precedence wins) e.g. right margin of one and left margin of another, or top/bottom, or start/end in FO speak. 8 Finally XSL-FO requires the commas between arguments. And, thanks for reading :) Liam -- Liam R. E. Quin <liam@w3.org> The World Wide Web Consortium (W3C)
Received on Wednesday, 16 November 2016 21:17:07 UTC