Re: Does the Crystal Goblet apply?

On Sun, January 5, 2014 8:16 am, Dave Pawson wrote:
> On 5 January 2014 00:20, Liam R E Quin <liam@w3.org> wrote:
>> On Sat, 2014-01-04 at 14:23 +0000, Dave Pawson wrote:
>>> O
>>> I'm not proposing solutions, just options. In this case
>>> some form of simpler syntax / terminology. I hope you'll agree
>>> that CSS syntax (if not semantics) is easier than FO?
>>
>> In some ways CSS is simpler and some ways not.
>
> As a simplification, I assert it is simpler. One judgement of
> that is take-up - far greater for CSS than FO? (Cost ignored)

That is also because it's associated with something that more people do
more of -- make HTML web pages -- than people make paginated pages.

It started out simpler, but they are having to shoehorn more complexity
into the syntax.  From Bert Bos's talk for the Tokyo Digital Publishing
Workshop last year [1]:

   CSS has shown a longevity and a capability to grow that I
   certainly didn't expect back in 1994-1998, even though I
   designed it to be extensible. On the other hand, the
   increased size already means that it isn't easy for people
   to learn CSS anymore and we should ask ourselves if it
   isn't better to leave CSS alone and create a new style
   sheet standard that, from the start, is meant to be good
   enough for complex publications.

For example, I don't find the var- and var() syntax of CSS variables [2]
to be all that intuitive:

----
:root {
  var-main-color: #06c;
  var-accent-color: #006;
}
/* The rest of the CSS file */
#foo h1 {
  color: var(main-color);
}
----

>> CSS syntax is being cleaned up, but I think some of the simplicity is
>> deceptive, because it doesn't do as much as FO. Some of the complexity
>> of FO comes (unfortunately) from the spec
>
> Yes. I'd put that back to JC et al. As Liam says, it is written for

I don't know why you continue to mention James Clark when he never put his
name to the FO spec.

> implementers,
> and should be precise. I still have the feeling that it could be precise
> without
> being overly complex. Is the terminology used 'too much', too different?

The mathematical preciseness of things like section 4.2.5, "Stacking
Constraints" [3], probably aren't what most people are used to.

> Are sosofo's and flow objects so hard to grasp? Could we overlay other
> terms
> for them?

Arved's point is that the XSLT that you use to generate the FOs is hard
for many people.

So another part of why CSS is easier to grasp is that there's no
transformation involved.

>> There might also be a lot of mileage in translations (whether in XSLT or
>> otherhow) from CSS into FO, so that e.g. people could use xmlroff or fop
>> with a CSS syntax.  Some constructs might be tricky to translate - e.g.
>> static content on page masters is very different, and can be dynamic in
>> HTML+CSS (but is not so easy to position where you want it).
>
> Which makes the basic assumption that XSL-FO is the way forward.
> Documenting it, clarifying it, layering it.

My current opinion is that getting more mileage out of the XSL-FO that we
have now is the best that we could do with our current resources (and/or
with the apparent lack of resources for developing XSL-FO 2.0).

> Do others feel the same? Or could we learn from it and produce
> an alternate?

I don't think we have the resources to produce an alternative.  It's taken
nine months or so for us just to produce two instances of a XSLT extension
function, and even they still need work.  It would be interesting work,
granted, but it's the sort of thing you'd want to work on full-time, not
do a bit here-and-there as time allows.  I don't see a Kickstarter
campaign to fund someone to do it being all that successful either, do
you?

Regards,


Tony.

[1] http://www.w3.org/Talks/2013/0604-CSS-Tokyo/
[2] http://dev.w3.org/csswg/css-variables/
[3] http://www.w3.org/TR/xsl11/#area-stackcon

Received on Sunday, 5 January 2014 20:21:44 UTC