Re: Does the Crystal Goblet apply?

On 01/05/2014 04:21 PM, Tony Graham wrote:
> 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.
And what's ironic is, very many web pages, of any footprint, are 
effectively paginated. Almost all the time I as a developer need/want to 
consider how I am going to get content into a space of fixed or nearly 
fixed dimensions. I may navigate between HTML fixed dimension pages by 
different mechanisms than a PDF or a printed book, but it's mostly all 
still pages.

You're right though, CSS is associated with production of (X)HTML web 
pages, and way more people do that than produce printed material.
> 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.
>
> [SNIP]
Almost inevitable. If there isn't already a rule that is given someone's 
name, that states that software specifications almost always increase in 
complexity with time, I'll put my surname on that. :-)

Lehman and Belady had some thoughts about this in the 1970's. Their 
thinking applies also to specs.

There's also an obvious cycle with specs: one gets too complex, that 
applies to a given domain, and a new group of people declares that they 
will simplify. This new group does simplify. But then *their* spec gets 
too complex. And so on.
>> 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.
>
>
[SNIP]

I don't want to sound elitist when I make that statement about XSLT. But 
I believe that it's not an easy language. Neither is C++ or Prolog, we 
all know this.

I'd put it differently somewhat: I'd say that CSS is _ostensibly_ easier 
to grasp.

A sidenote: it's not actually necessary that XSL-FO need be generated 
from XML via XSLT. Liam already alluded to this: transformation from CSS 
to FO. In fact I could *directly* choose XSL-FO as a format that I 
wanted formatters to work with for printed material, and programs that 
produce FO from *any* source would work just as well. It's tunnel vision 
to think that your FO source needs to be XML via XSLT.

Arved

Received on Sunday, 5 January 2014 21:10:12 UTC