Loading ...
Sorry, an error occurred while loading the content.

Re: {Spam?} [xml-doc] Simplicity works

Expand Messages
  • Werner Donné
    I m in favour of using HTML/CSS for writing documents. This manual (http://www.re.be/css2xslfo/1_2/manual.pdf) is an example of combining XHTML and CSS through
    Message 1 of 17 , Dec 4, 2005
    • 0 Attachment
      I'm in favour of using HTML/CSS for writing documents. This manual
      (http://www.re.be/css2xslfo/1_2/manual.pdf) is an example of combining
      XHTML and CSS through an alternative method.

      Werner.

      dirtroad30534 wrote:
      > In the past, I've argued (on XML-doc) that complex, expensive "solutions" are only going to
      > drive the bulk of technical writers away from XML, like SGML before it. The other side of that
      > coin is a requirement for simplicity. If you want technical writers to embrace XML, you need
      > to introduce them to something easier to understand and work with -- I've suggested that
      > something little (or no) more complex than HTML is the right level.
      >
      > Now it turns out, for book publishing anyway, HTML/CSS *is* all you need. The book authors
      > describe their setup in http://www.alistapart.com/articles/boom -- ah, sweet validation. :-
      > P :-)
      >
      > Judicious use of the CLASS attribute is perhaps the key here. I'll pontificate some more when
      > it's not midnight local time....
      >
      > -- Larry
      >
      >
      >
      >
      >
      >
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >
      >

      --
      Werner Donné -- Re BVBA
      Engelbeekstraat 8
      B-3300 Tienen
      tel: (+32) 486 425803 e-mail: werner.donne@...
    • David Tolpin
      ... CSS is a way of hacking styling into XML or HTML pages. As any hack made by good programmers, it works well enough for many practical purposes when you
      Message 2 of 17 , Dec 5, 2005
      • 0 Attachment
        >
        > So I don't think we're quite ready to replace FrameMaker
        > with DreamWeaver yet, Larry... <vbg> Even with Adobe
        > owning both of them now. ;-)

        CSS is a way of hacking styling into XML or HTML pages. As any hack
        made by good programmers, it works well enough for many practical
        purposes when you master it. As any hack it stands in your way the very
        moment you decide to go beyond the needs of the hacker who wrote the
        tool.

        CSS is non-orthogonal and eclectic, full of ad-hoc functions and
        syntactic tricks. It should be compared to TeX and troff syntactically,
        not to XML+XSL(T,FO), and functionally, it (both the specifications and
        implementations thereof) stays far behind both TeX and troff in
        capabilities it provides for printed media. If one can give up unified
        extensible solution (obtained for the price of verbose XML syntax and
        bringing streamlined unified approach) and still serious about batch
        book publishing; there are better alternatives.

        CSS is backed by two ideas: rules for adding declarations must be
        declarative, and syntax for specifying the rules must be
        human-readable. Both ideas are great. CSS fails on both ideas for any
        non-trivial case, adding imperative "add thing there, add thing here"
        constructs and filling the syntax with cryptic combinations which
        should probably work, but actually are only usable in tools created by
        the specification authors. XSLT provides much better and more powerful
        means for declarative specification of decorations, but has ugly
        anti-humane syntax. It is also a general document tree manipulation
        tool, and its creator has been talented enough to choose just right
        abstractions for most things. I am talking about XSLT 1.0 and James
        Clark.

        XHTML is a simple semantic markup in wide use; most people will
        probably be able to learn it for simple tasks. It is a kind of markup
        with default presentation rules permanently attached to it. Works for
        starters. CSS is a non-XML syntax for a problem-oriented subset of XSL,
        suitable for assigning decorations to an XML tree. As such, it works
        for simple cases when learning by example is sufficient -- that's why
        it works well for web pages: anything complex would not work anyway
        because of diversity and deficiency of current browsers. Any
        non-entry-level task requires better, or different,
        decoration/transformation language. Lacking that, XSL is mostly used --
        it is hard-to-use but does the job.

        Regarding prepress issues, as someone who worked in a team which went
        from a PDFLIB-(very-early-version)-based prototype to an engine which
        is widely used in book publishing and has many bells and whistles in
        that field, I'd like to say that prepress features (or lack of them) of
        Prince are unrelated to the input language. At least directly unrelated
        -- they are functionally separate issues: you can use CSS and still
        have bleeding and cropping and proper spot colors and color separation
        and PDF tags and whatnot. On the other hand, adopting amateur design
        for the input probably influences quality of the output.

        David Tolpin
      • Larry Kollar
        ... My bad... I tend to think XHTML when I think HTML, although that s often/usually not the case (at least outside a mailing list that talks primarily about
        Message 3 of 17 , Dec 5, 2005
        • 0 Attachment
          > ... I have several "buts":
          >
          > 1. Technically, the solution DOES require XML because, unless I'm
          > mistaken, Prince needs to operate on XHTML rather than non-XML HTML.
          > So you're already assuming an author who's in the habit of composing
          > well-formed, valid XHTML rather than anything-goes HTML.

          My bad... I tend to think XHTML when I think HTML, although that's
          often/usually not the case (at least outside a mailing list that
          talks primarily about XML). Any XML authoring tool that provides
          (X)HTML editing capabilities can be helpful here.


          > 2. The sample book finesses the issue of metadata. Say you have a bunch
          of
          > these HTML books and want to create a catalog: how are you going to
          build
          > it? With XHTML, you're going to have to create your metadata by adding
          > "alien" content in the form of Dublin Core <meta> headers or a pointer
          to
          > an RDF file, maybe. With a dedicated XML document markup language like
          > DocBook or TEI, the metadata is an integral part of the tagset.

          I'm not sure that's a problem, or maybe I'm emphasizing the wrong
          (or just a different) kind of metadata.

          For the Dublin Core type of metadata, which I assume means the
          elements defined in http://dublincore.org/documents/dces/ , can
          the XHTML [meta] element not be used as-is? For example:

          [meta name="subject" content="cable modem installation procedure"/]

          For lower-level metadata, the CLASS attribute can carry the load.
          The definition of CLASS allows for such marking, rather than to
          strictly specify formatting operations. Parts of documents can be
          wrapped in, say [div class="database api reference"]...[/div] to
          specify their purpose in life (the [body] element also supports
          the CLASS attribute, just to be pedantic). Wrapping sections in
          div elements can be done with a script (especially if you have
          well-formed XHTML), I've done it.

          The [link] element (in the head) might be helpful as well, at
          least as a way to specify relationships to other documents, but I
          haven't looked closely enough to decide.

          Yes, feeding the system is important. But it's just as important
          to make the system easy to feed.


          Which, of course, leads to....

          > 3. Is rich XHTML that relies on careful and consistent use of multiple
          > @class attributes really that much simpler than simplified DocBook or
          > TEI-Lite?

          I think so, for several reasons. First, many writers are already
          familiar with XHTML, even if their primary exposure is through
          tweaking stuff that Reamwhatever bobbles -- familiarity leads to
          confidence, which is a big help toward eventual success. If "we"
          want a chance of getting non-gearheads on board, this is where
          we have to start. (IMHO, naturally)

          Second, the conventional wisdom (at least with DocBook) is that
          it's necessary to add or eliminate elements to suit the situation.
          Using generic DIV/SPAN elements, and the CLASS attribute, you
          can stick with bog-standard XHTML and not get into the arcana of
          DTD/schema modification -- just agree on a set of classes and
          get to work; if you need to add more classes, do it. The idea is
          to provide enough structure "hooks" for current and future pro-
          cessing needs, without the structure getting in the way. Again,
          if the goal is widespread "uptake" (or whatever the buzzword du
          jour is), minimizing the amount of non-writing work is important.

          Finally, and this sort of goes back to the confidence argument,
          most word processors can convert XHTML to their native formats
          out of the box (with Frame being a partial exception) and at
          least write a debased form that can be fixed. Thus, those who
          want to try can step out -- knowing they can step back easily
          enough if the project doesn't pan out.


          > I might be misreading your intent--if the point is that the XHTML/Prince

          > approach is a good place to start, and that someone who masters it may
          > then be ready to go beyond the limitations of HTML, I'd agree. But I
          > couldn't agree that "for book publishing HTML/CSS is all you need"
          unless
          > you're talking about limited self-publishing.

          I have several points, actually, and "a place to start" (or
          "gateway drug," if you prefer ;-) *is* one of them. Trans-
          forming an XHTML document to some other XML format, especially
          one with decent element-level metadata, is easy when the time
          comes.

          I also want to point out that Prince isn't a necessity even
          at this most basic of levels; you can put whatever tools you
          have at hand to work. For example, if you have valid XHTML &
          aren't fussy about typesetting quality, open it with your
          favorite word processor, apply styles, and print. If you can
          work with a loosely-coupled set of tools, in which any of
          the tools can be replaced at will, you've just liberated
          yourself from software obsolescence and the upgrade treadmill.

          A more important point is that -- once again, if the goal is
          to get more people on board -- you don't need huge budgets,
          support contracts, or even a resident gearhead to make this
          XML stuff work. There are situations (aerospace leaps to mind)
          where this approach would be terribly inadequate -- but those
          are just the people who *can* afford the six-figure deployment
          and five-figure support budgets for large-scale content man-
          agement and publishing systems. The rest of us need something
          we can piece together, then get real work done with it. Just
          as important, it needs to be simple enough that it won't be
          abandoned because the resident gearhead left or got re-org'ed
          out of the department.

          --
          Larry Kollar, Senior Technical Writer, ARRIS CPE Products
          "Content creators are the engine that drives
          value in the information life cycle."
          -- Barry Schaeffer, on XML-Doc
        • Michael Day
          Hi David, ... I think that this is a very misleading description of CSS, Before the introduction CSS, the web was full of real styling hacks , such as the use
          Message 4 of 17 , Dec 5, 2005
          • 0 Attachment
            Hi David,

            > CSS is a way of hacking styling into XML or HTML pages.

            I think that this is a very misleading description of CSS,

            Before the introduction CSS, the web was full of real "styling hacks",
            such as the use of transparent spacer GIF images for alignment, pages full
            of hundreds of <FONT> tags to control text appearance and tables used for
            layout covered in hard-wired presentational attributes like bgcolor.

            CSS replaced all of these hacks with a clean and declarative styling
            language that is easier to learn than the old methods as well as being
            more powerful. This has led to the web of today, in which documents can
            have clean markup and meaningful semantics without sacrificing style.

            The site that started this thread, alistapart.com, is a perfect example of
            the CSS philosophy. The site looks beautiful, with great attention paid to
            the style, and yet the markup is still incredibly simple and the site is
            just as readable in Lynx on a terminal as it is in a graphical browser.

            To return to your original comment, I think a better way to phrase it
            would be simply that "CSS is a language for styling XML or HTML pages", or
            if you wanted to get more technical, that "CSS is a language for
            annotating tree-based markup with style properties".

            > Regarding prepress issues, as someone who worked in a team which went
            > from a PDFLIB-(very-early-version)-based prototype to an engine which
            > is widely used in book publishing and has many bells and whistles in
            > that field, I'd like to say that prepress features (or lack of them) of
            > Prince are unrelated to the input language.

            This is very true. For example, Prince already supports PDF bookmarks and
            encryption, two PDF-related features that really don't have anything to do
            with CSS, or XML for that matter. Support for CMYK color and cropping are
            on our development roadmap and we always welcome new feature requests :)

            Best regards,

            Michael

            --
            Print XML with Prince!
            http://www.princexml.com
          • Jirka Kosek
            ... How would you style general image or link? Consider sampla link Current CSS
            Message 5 of 17 , Dec 6, 2005
            • 0 Attachment
              Michael Day wrote:

              > To return to your original comment, I think a better way to phrase it
              > would be simply that "CSS is a language for styling XML or HTML pages", or
              > if you wanted to get more technical, that "CSS is a language for
              > annotating tree-based markup with style properties".

              How would you style general image or link? Consider

              <ulink url="http://example.org">sampla link</ulink>

              <imagedata fileref="photo.png"/>

              Current CSS specification doesn't provide means to properly style such
              general markup. So CSS can be used with general XML, but you will get
              only static text, without links and images.

              Does Prince offer some proprietary properties for this, or it is able to
              fully process only XHTML based vocabularies?

              Jirka

              --
              ------------------------------------------------------------------
              Jirka Kosek e-mail: jirka@... http://www.kosek.cz
              ------------------------------------------------------------------
              Profesion�ln� �kolen� a poradenstv� v oblasti technologi� XML.
              Pod�vejte se na n�� nov� spu�t�n� web http://DocBook.cz
              Podrobn� p�ehled �kolen� http://xmlguru.cz/skoleni/
              ------------------------------------------------------------------
              Nejbli��� term�ny �kolen�:
              ** XSLT 13.-16.3.2006 ** XML sch�mata 24.-26.4.2006 **
              ** DocBook 15.-17.5.2006 ** XSL-FO 12.-13.6.2006 **
              ------------------------------------------------------------------



              [Non-text portions of this message have been removed]
            • Michael Day
              Hi Jirka, ... Prince has its own property to define links (prince-link), which is similar to the CSS-based approach taken by Opera. Prince also supports simple
              Message 6 of 17 , Dec 6, 2005
              • 0 Attachment
                Hi Jirka,

                > <ulink url="http://example.org">sampla link</ulink>

                Prince has its own property to define links (prince-link), which is
                similar to the CSS-based approach taken by Opera.

                Prince also supports simple XLinks, which can be used in any XML document.

                There is still debate in the XHTML/CSS community over the best way to
                handle links in arbitrary XML; there are a number of different approaches,
                but no single standard that is recommended for use in all situations.

                > <imagedata fileref="photo.png"/>

                CSS 2.1 supports hard-wired image URLs, like this:

                imagedata { content: url("photo.png") }

                CSS 3 has a general attr() function that Prince supports, allowing
                arbitrary images to be included like this:

                imagedata { content: attr(fileref, url) }

                In practice, when supporting a new XML vocabulary you can write a single
                default style sheet that takes care of basic default styling for blocks,
                links, images and so on; subsequent styling can be done by author or user
                style sheets. This is actually how Prince supports XHTML styling: simply
                by including a default XHTML style sheet.

                One of the advantages of CSS is that multiple style sheets can be combined
                together in a very intuitive fashion :)

                Best regards,

                Michael

                --
                Print XML with Prince!
                http://www.princexml.com
              • David Tolpin
                Hi Michael, ... I didn t want to insult. But I stand behind this viewpoint. ... Right. ... Right. ... Wrong. CSS stylesheets of most sites are where the mess
                Message 7 of 17 , Dec 6, 2005
                • 0 Attachment
                  Hi Michael,

                  > I think that this is a very misleading description of CSS,

                  I didn't want to insult. But I stand behind this viewpoint.

                  >
                  > Before the introduction CSS, the web was full of real "styling hacks",

                  Right.

                  > CSS replaced all of these hacks

                  Right.

                  > with a clean and declarative styling

                  Wrong. CSS stylesheets of most sites are where the mess has moved to.
                  Just hidden from the eyes of a naïve observer pressing the 'view source
                  button'.

                  > The site that started this thread, alistapart.com, is a perfect
                  > example of
                  > the CSS philosophy. The site looks beautiful, with great attention
                  > paid to
                  > the style, and yet the markup is still incredibly simple and the site
                  > is
                  > just as readable in Lynx on a terminal as it is in a graphical browser.

                  I can't judge the site's adherence to the philosophy; but I trust your
                  words.

                  However, alistapart.com's CSS is a very usual example of how horrible
                  CSS styling is;
                  and how far it is from any reasonable publishing approach.

                  The site is readable in Lynx but not in the browser of my smartphone,
                  because its stylesheets are a closed design with fixed pixel widths and
                  hacks
                  for particular browsers to work with. And my browser (which happens
                  to be Opera!) fails to display it in a reasonable way.

                  The style mixes font units and pixels in the same content -- look for
                  padding attributes on
                  padding for '#navbar li' and '#navbar li a', uses font sized in
                  pixels, breaking all proportions
                  on displays with too high or too low resolution:

                  > #navbar {height: 2.4em;
                  > padding: 0 0 0 215px;
                  > background: #FBFAF4;
                  > border-top: 5px solid #333;
                  > font: 18px Georgia, Times, serif; overflow: hidden;
                  > min-width: 750px;}
                  > #navbar li {float: left; padding: 0 23px 0 13px; margin-right: 5px;
                  > background: url(/pix/diamond-black.gif) 100% 66% no-repeat;}
                  > #navbar li a {display: block; padding: 0.75em 0 0.25em;
                  > text-transform: uppercase; color: #000;}
                  > #navbar #feed {background: none;}

                  Further on, it contains a hack of changing display attribute of 'a'
                  element, instead of using appropriate
                  markup for each, and, of course, it contains hacks for browsers, not
                  able to handle 'a' with display="block". By the way, the hack redefines
                  padding-top in font-relative units on the same element in which it was
                  originally defined in pixels. This is a mess:

                  > /* IE5/Mac hacks */
                  > /*\*//*/
                  > #navbar {padding-top: 0.75em; height: 1.66em;}
                  > #navbar li a {display: inline;}
                  > /**/

                  And the site uses side-floats for page regions. This is just like using
                  tables for page regions -- the two tricks are exactly at the same level
                  of inappropriateness. Floats are not page regions -- they are floats,
                  rectangles obstructing the main flow. For paged media, this technique
                  is a failure.

                  >
                  > To return to your original comment, I think a better way to phrase it
                  > would be simply that "CSS is a language for styling XML or HTML
                  > pages", or
                  > if you wanted to get more technical, that "CSS is a language for
                  > annotating tree-based markup with style properties".

                  CSS is a language. It is a language for hacking styling into XML or
                  HTML pages in such a way that the original HTML, easily accessible
                  through the 'View Source' button can be left untouched, and the
                  customer is happy viewing clean and pure XHTML, as the current fashion
                  dictates (as though the customer views the browser's binary code with a
                  hex viewer before accepting the work -- or investigates contents and
                  internal layout of all raster images used). By itself, the idea is not
                  bad -- it makes it possible to make slightly more money with slightly
                  less effort.

                  Besides that, it is just the same FONT tags everywhere. They are just
                  called 'class'. And the same tables. They are now called "float:
                  left;". And the same pixel widths. They can be now more dangerous: one
                  can mix pixels, points and font units and do wonders with the way page
                  looks on anythin 1024x768 17'' TFT. And the best tool for
                  parameterizing a style is still a perl script: how else you are going
                  to change the color #658aac to color #856caa, in a few places in a few
                  stylesheets of your site?

                  CSS is good for amateur sites with simple look; so that it is easy to
                  maintain them. It becomes a disaster when its adopters pretend that it
                  can be used for professional design. It cant. It is still possible to
                  start from the original ideas of CSS and design a clean human-oriented
                  problem-specific language for styling. But in the meantime, there is no
                  such language.

                  David
                • Jirka Kosek
                  ... Hmm, I can t say that I like this idea when behaviour of property is defined by type of the assigned value. Wouldn t it be better to introduce new
                  Message 8 of 17 , Dec 6, 2005
                  • 0 Attachment
                    Michael Day wrote:

                    > CSS 3 has a general attr() function that Prince supports, allowing
                    > arbitrary images to be included like this:
                    >
                    > imagedata { content: attr(fileref, url) }

                    Hmm, I can't say that I like this idea when behaviour of property is
                    defined by type of the assigned value. Wouldn't it be better to
                    introduce new property, e.g.: image-content: attr(fileref)

                    Are there any means to extract image URL from an element content
                    (<image>photo.png</image>)?

                    How is xml:base handled in this situation?

                    > One of the advantages of CSS is that multiple style sheets can be combined
                    > together in a very intuitive fashion :)

                    And sometimes unpredictable from users point of view ;-)

                    You can gain same with XSL-FO if you assign properties to formatting
                    objects using xsl:attribute-set.

                    --
                    ------------------------------------------------------------------
                    Jirka Kosek e-mail: jirka@... http://www.kosek.cz
                    ------------------------------------------------------------------
                    Profesion�ln� �kolen� a poradenstv� v oblasti technologi� XML.
                    Pod�vejte se na n�� nov� spu�t�n� web http://DocBook.cz
                    Podrobn� p�ehled �kolen� http://xmlguru.cz/skoleni/
                    ------------------------------------------------------------------
                    Nejbli��� term�ny �kolen�:
                    ** XSLT 13.-16.3.2006 ** XML sch�mata 24.-26.4.2006 **
                    ** DocBook 15.-17.5.2006 ** XSL-FO 12.-13.6.2006 **
                    ------------------------------------------------------------------



                    [Non-text portions of this message have been removed]
                  • Werner Donné
                    Hi, XHTML and CSS alone are certainly not sufficient for printing. You always need a number of extensions. Note that even the example on the A List apart site
                    Message 9 of 17 , Dec 6, 2005
                    • 0 Attachment
                      Hi,

                      XHTML and CSS alone are certainly not sufficient for printing. You
                      always need a number of extensions. Note that even the example on
                      the A List apart site uses Prince extensions. The number of required
                      extensions is, however, not that high in order to cover a consideral
                      range of printed documents. Even books that are not too fancy can
                      be made with it. You wouldn't have all the layout freedom you have
                      with other approaches and you wouldn't have the best of designs either,
                      but plenty of real books are no better. Some books are even made with
                      MS Word.

                      A very important range of documents are business documents such as
                      reports, manuals, specifications, etc. For those an approach based
                      on CSS, with the few extensions, is viable for printing. Now, a lot
                      of people use MS Word for that, resulting in bad typesetting on top
                      of the limited layout possibilities.

                      XHTML is an interesting language because it so simple. With a handful
                      of tags you can write a complete day-to-day document. Making an ad hoc
                      editor for that is feasible. But as soon as you start using the "class"
                      attribute heavily, you are creating another language. The extreme case
                      is a document with only "div" and "span" elements. Perhaps it is better
                      to consider something else then.

                      The CSS approach is also interesting. The scenario I usually follow is
                      first a preprocessing step, XHTML to XHTML for example, in which things
                      like tables of contents and indexes are added, followed by the application
                      of a CSS style sheet. The latter can be easily customised at the level
                      of the document. The end-user should, however, not be required to write
                      CSS in order to achieve customisation. If I'm writing a DocBook document,
                      for example, and if I would want to set a particular paragraph in italic
                      say, it should be sufficient to select the paragraph and change the
                      property. In XHTML you have the "style" attribute for this, but the
                      general approach in XML could be to generate, behind the scenes, an ID
                      for the element and a piece of CSS in another style entity, which only
                      contains stuff like that. This style entity would be an integral part
                      of the document.

                      The hacking that usually comes with web-pages, be it in HTML or CSS,
                      is simply part of the web-browser culture. The specifications and their
                      implementations are not good enough. I have been following this and
                      my conclusion is that this is a small club of people, all working on
                      their browser, trying to agree on the next great feature, while never
                      abiding to the specification that is already there. The specification
                      process is simply following slowly what is being implemented in the
                      browsers. It is not ahead. It doesn't set the direction. CSS3 is an
                      attempt to advance, but when will we ever see a proper implementation
                      and when will it become a recommendation?

                      The web started off in a prototyping way and seems to have never left
                      it. The tools that produce web-pages are no better, considering the
                      misery they generate.

                      My biggest complaint is that the CSS "print" medium is not getting the
                      attention it should get. In CSS2.1 some elements were removed from the
                      specification, with respect to CSS2, simply because nobody implemented
                      them. An example is the "named pages" feature, which is clearly a
                      page-oriented feature.

                      Regards,

                      Werner.
                      --
                      Werner Donné -- Re BVBA
                      Engelbeekstraat 8
                      B-3300 Tienen
                      tel: (+32) 486 425803 e-mail: werner.donne@...
                    • Håkon Wium Lie
                      ... I thought your description was well written and entertaining. After reading it, however, I wasn t sure what points you were trying to make. Let s try to
                      Message 10 of 17 , Dec 6, 2005
                      • 0 Attachment
                        Also sprach David Tolpin:

                        > > I think that this is a very misleading description of CSS,
                        >
                        > I didn't want to insult. But I stand behind this viewpoint.

                        I thought your description was well written and entertaining. After
                        reading it, however, I wasn't sure what points you were trying to
                        make. Let's try to sort it out.

                        Let me start with an observation. CSS and XSL (T+FO) are very similar;
                        both lanugages style structured documents into final presentations
                        using mostly the same properties, values and units. Where they differ
                        is syntax and degree of Turing-completeness.

                        You clearly don't like the CSS syntax:

                        > CSS is non-orthogonal and eclectic, full of ad-hoc functions and
                        > syntactic tricks.

                        But you don't like XSLT either:

                        > XSLT provides much better and more powerful
                        > means for declarative specification of decorations, but has ugly
                        > anti-humane syntax.

                        So, what's worst -- syntactic tricks or an anti-humane syntax? Let's
                        look at one example. I'm willing to bet that you don't like this
                        fragment from our sample style sheet [1]:

                        ul.toc a::after { content: leader('.') target-counter(attr(href), page) }

                        Fair enough, I'm willing to admit that the value of the 'content'
                        property is a bit cryptic. It has a few syntactic tricks in it and it
                        takes a paragraph or two to explain what it it does. Unlike most other
                        property values I have to consult a reference to write it. However, I
                        challenge you to write the XSL code that generates the same
                        presentation as the above one-liner. How many lines does it require?
                        Given that this is something every book needs, I think most of us are
                        willing to live with a trick or two if the alternative is layers of
                        anti-humane code.

                        You also make a remark about "tools created by the specification
                        authors":

                        > CSS fails on both ideas for any non-trivial case, adding imperative
                        > "add thing there, add thing here" constructs and filling the syntax
                        > with cryptic combinations which should probably work, but actually
                        > are only usable in tools created by the specification authors.

                        It's true that most major CSS implementors are represented in the W3C
                        CSS WG. We make tools according to the specifications we write. We
                        publish our specifications, though, to encourage others to support
                        them as well. You're most welcome if you want to join the group, help
                        develop the specifications, and/or support the CSS specifications.

                        > However, alistapart.com's CSS is a very usual example of how
                        > horrible CSS styling is; and how far it is from any reasonable
                        > publishing approach.

                        One motivation for doing CSS in the first place was to rescue
                        structured documents on the web. The web was quickly turning into a
                        big bowl of FONT tags when we started. While it's easier to sell CSS
                        for its styling capabilities, it has also made it possible to write
                        structured, semantic HTML like the alistapart.com site does. If you
                        don't like the style sheet, you can easily turn it off (shift-G in
                        Opera). You can discard the style sheet instantly, but the content and
                        structure can live forever.

                        That being said, I think CSS makes alistapart.com a beautiful site.
                        They have their fair share of IE workarounds, but that's what living
                        in the real world gives you.

                        [1] http://people.opera.com/howcome/2005/ala/boom.css

                        Cheers,

                        -h&kon
                        Håkon Wium Lie CTO °þe®ª
                        howcome@... http://people.opera.com/howcome
                      • David Tolpin
                        ... syntactic tricks are worse. They are an end-road. No exit. Machine-oriented syntax, on the other hand, is just a base to build a human-friendly one on top
                        Message 11 of 17 , Dec 6, 2005
                        • 0 Attachment
                          > So, what's worst -- syntactic tricks or an anti-humane syntax? Let's
                          > look at one example. I'm willing to bet that you don't like this
                          > fragment from our sample style sheet [1]:

                          syntactic tricks are worse. They are an end-road. No exit.
                          Machine-oriented syntax, on the other hand,
                          is just a base to build a human-friendly one on top of it.

                          > ul.toc a::after { content: leader('.') target-counter(attr(href),
                          > page) }
                          >
                          > However, I
                          > challenge you to write the XSL code that generates the same
                          > presentation as the above one-liner.

                          A nice thing about XSL is that it is reusable. And the code (in XML,
                          not in XSL) will be

                          <TOC/>

                          That's all. I don't -write XSLT code- for every single document. I use
                          XSLT stylesheets
                          someone other wrote for me. And change parameters occasionally. I
                          woulnd't like the
                          idea to be challenged by someone to programmatically parameterize a set
                          of CSS stylesheets.

                          David Tolpin
                        • Håkon Wium Lie
                          ... CSS 2.1 trimmed features that were not widely implmented at the time the work started. Alas, several print-related features were among those. However, the
                          Message 12 of 17 , Dec 7, 2005
                          • 0 Attachment
                            Also sprach Werner Donné:

                            > My biggest complaint is that the CSS "print" medium is not getting the
                            > attention it should get. In CSS2.1 some elements were removed from the
                            > specification, with respect to CSS2, simply because nobody implemented
                            > them. An example is the "named pages" feature, which is clearly a
                            > page-oriented feature.

                            CSS 2.1 trimmed features that were not widely implmented at the time
                            the work started. Alas, several print-related features were among
                            those. However, the CSS WG has been working on two print-oriented
                            specifications since then:

                            CSS Print Profile
                            http://www.w3.org/TR/2004/CR-css-print-20040225/

                            CSS3 Paged Media Module
                            http://www.w3.org/TR/2004/CR-css3-page-20040225/

                            The first of these is addresses the needs of printing to low-cost
                            devices (say, a mobile phone connected to a cheap printer), while the
                            second adds more advanced features like headers and footers.

                            The W3C CSS Working Group is also trying to describe more advanced
                            features like leaders and footnotes. Some of the work is described here:

                            CSS3 Generated and Replaced Content Module
                            http://www.w3.org/TR/2003/WD-css3-content-20030514/

                            > XHTML and CSS alone are certainly not sufficient for printing. You
                            > always need a number of extensions.

                            I would agree with this statement if you said "XHTML and CSS 2.1". The
                            "extensions" are expressed in CSS and most of them are described in
                            working drafts for CSS3. The exception is leaders, which isn't
                            described in WD yet.

                            Cheers,

                            -h&kon
                            Håkon Wium Lie CTO °þe®ª
                            howcome@... http://people.opera.com/howcome
                          • Peter Ring
                            Some of us would have preferred s-expressions to rule -- after all, you can t get more machine-processable and expressive power than that. But the mass
                            Message 13 of 17 , Dec 7, 2005
                            • 0 Attachment
                              Some of us would have preferred s-expressions to rule -- after all, you can't get more machine-processable and expressive power than that. But the mass adoption of any 'new' technology depends more on convenience that anything else. Most people need immediate benefits from marginal changes in their working life, and have no patience with anything that require a complete change of mindset -- hence, 'worse is better'.

                              You can't seriously mean that <FONT>, <CENTER>, <BLINK>, GIF-spacers, tables etc. is no worse than CSS?

                              My main gripe with CSS is not that it isn't Turing-complete, or that the syntax doesn't resemble SGML markup (or Lisp). XPath, e.g., isn't a general programming language and doesn't resemble SGML markup either. So what? We get useful work done now, while XQuery, XSLT 2 and whatnow fight about becoming the next big thing.

                              > That's all. I don't -write XSLT code- for every single
                              > document. I use XSLT stylesheets someone other wrote for me.
                              > And change parameters occasionally. I woulnd't like the
                              > idea to be challenged by someone to programmatically
                              > parameterize a set of CSS stylesheets.

                              Well, here's where I might agree -- somewhat. CSS is short for '*Cascading* Style Sheets', and a lot of parameterization can be done by cascading CSS rules. This is why CSS is seriuosly better than HTML presentation tag soup.

                              While most use of CSS involves using CSS files, CSS properties can be build and applied to the DOM in an user agent from scratch, without involving any CSS files. In this case, you are free to model presentation and other behavioural properties as you please.

                              In any case, if you want your set of CSS rules to be easily customizable, you must factor out a number of 'access points', CSS declarations that can be overruled in a meaningful way. It is not much different from designing a modular XML schema, and it isn't any easier -- it can't be.

                              But in the CSS file syntax, I miss a simple way to model 'mix-in'-like aspects, properties that represent general design decisions and might appear in lots of places. Along the lines of named property sets. Are there any good design patterns for this?

                              Kind regards
                              Peter Ring

                              > -----Original Message-----
                              > From: xml-doc@yahoogroups.com
                              > [mailto:xml-doc@yahoogroups.com]On Behalf
                              > Of David Tolpin
                              > Sent: 7. december 2005 03:04
                              > To: xml-doc@yahoogroups.com
                              > Subject: Re: [xml-doc] Simplicity works
                              >
                              >
                              > > So, what's worst -- syntactic tricks or an anti-humane syntax? Let's
                              > > look at one example. I'm willing to bet that you don't like this
                              > > fragment from our sample style sheet [1]:
                              >
                              > syntactic tricks are worse. They are an end-road. No exit.
                              > Machine-oriented syntax, on the other hand,
                              > is just a base to build a human-friendly one on top of it.
                              >
                              > > ul.toc a::after { content: leader('.') target-counter(attr(href),
                              > > page) }
                              > >
                              > > However, I
                              > > challenge you to write the XSL code that generates the same
                              > > presentation as the above one-liner.
                              >
                              > A nice thing about XSL is that it is reusable. And the code (in XML,
                              > not in XSL) will be
                              >
                              > <TOC/>
                              >
                              > That's all. I don't -write XSLT code- for every single
                              > document. I use
                              > XSLT stylesheets
                              > someone other wrote for me. And change parameters occasionally. I
                              > woulnd't like the
                              > idea to be challenged by someone to programmatically
                              > parameterize a set
                              > of CSS stylesheets.
                              >
                              > David Tolpin
                              >
                              >
                              >
                              >
                              > Yahoo! Groups Links
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                            Your message has been successfully submitted and would be delivered to recipients shortly.