On Wed, November 6, 2013 3:36 pm, Wendell Piez wrote:
Hi,
On Tue, Nov 5, 2013 at 6:06 PM, Tony Graham <tgraham(_at_)mentea(_dot_)net>
wrote:
So XPath -- or the possible complexity of the XPath needed to match or
select just the right thing -- is a problem?
Yes, I think it is. Two things about XPath:
1. It works over a data model that is not explicit, but must be
learned and then inferred from syntax, not read directly. This is
especially true of XPath 2.0 but it's even true of XPath 1.0.
This is true of CSS also, but the data model is (at least for
practical purposes) less complex and more amenable to fudging. In part
this is because CSS selectors only need (something like) XSLT @match
semantics, not @select.
Not exactly, possibly even not at all. The 'Introduction' section of the
next level of Selectors [1] (no longer called 'CSS Selectors', BTW, and
explicitly for 'HTML and XML') includes:
applied to an entire tree of elements to filter it into a set
of elements that match the criteria, such as in the
document.findAll() function
and the first/main point of the jQuery library is using CSS selectors to
find things.
As for less complex, try these, that I'm almost glad we haven't had to
deal with with XPath:
- E:future - an E element that is in the future in a
time-dimensional canvas
- E:invalid-drop - an E element that cannot receive the item
currently being dragged, but could receive some other item
OTOH, Jirka Kosek is having an uphill battle trying to persuade enough of
the CSS WG that Selectors 4 should be able to select attributes as well
[2], and the last slide in Dave Cramer's talk [3] at the "Publishing and
the Open Web Platform" workshop calls for "XPath-strength CSS selectors".
...
I agree with Tony that the development of really interactive
development environments for CSS has been a huge help. Of course, this
is largely possible because CSS is limited to formatting semantics,
which by definition can be displayed.
Consider this processing rule: Where the document has an empty 'div'
element with [class~=toc], substitute for it a nested list collecting
all the h1|h2|h3|h4 elements that are the first children of their
containing divs (the nesting of the list corresponding to any nesting
of the divs), show them as items, and display the list with formatting
properties X, Y and Z. Make each of the list items in the list a link
to their 'div' elements in the source (where the links are not
explicitly coded).
Suddenly a GUI has become significantly harder. Indeed, a web
developer coding this in Javascript has to visualize the process in
her head in the same way an XSLT developer does. A debugging
environment can help, but we have those for XSLT too.
My position paper for the same workshop [5] called out the need for the
Open Web Platform to include a declarative transformation language as an
alternative to using JavaScript, but I was also sceptical that the OWP
would just embrace XSLT.
I keep mentioning the "Publishing and the Open Web Platform" workshop
because it's a recent snapshot of what people are doing in publishing, and
I found it interesting (and contrary to my position paper) that several
publishers there (including O'Reilly, who champion no-markup authoring
[8]) were using XSLT to transform XHTML to XHTML to target different
devices, meaning they could easily produce the 'ToC' as well as the
'manifest' for their EPUBs along the way using XSLT.
Arbitrary transformations aside, this also bears on the question of
XSL-FO because the base-line production values of print (as Tony well
knows :-) even at the rudimentary level of XSL 1.0 (what Peter calls
"office documents") are significantly more challenging to automate
than those of web browsers -- which, in 2013, even after 20 years of
painful advance, are only a vague hint of what they ought to be and
should eventually be. The semantics of HTML5 and CSS3 represent steps
It's been years, even decades, since web browsers have sliced across lines
of text to make a page break, and for many people, what we have now is
good enough. For example, Adam Hyde in his position paper [6] argues that
book production is possible now using HTML and CSS (though the widow on
his second page undermines his position).
...
Then too, there is an elephant in the room: what happens when a
workflow devoted to achieving good results in print collides with a
workflow oriented towards online media. The old ideal of "single
The terminology (largely, I think, because Liam repeats it in lots of
presentations) is veering towards [7]:
- XML First, in which the authors supply XML;
- XML Early, in which the authors and copy editors work with
Microsoft Word and its revision tracking before conversion
to XML;
- XML Late, in which paginated PDF (or InDesign documents) are
sent out of house and converted to XML;
- XML Never, or the ?traditional? workflow in which Quark or
InDesign is used to produce PDF for print, and electronic
books are not created, or are static PDF copies of the
printed books
so, as with many things, different people come up with different answers
to the same question.
Regards,
Tony Graham tgraham(_at_)mentea(_dot_)net
Consultant http://www.mentea.net
Mentea 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
XML, XSL-FO and XSLT consulting, training and programming
Chair, Print and Page Layout Community Group @ W3C
[1] http://dev.w3.org/csswg/selectors/
[2] http://lists.w3.org/Archives/Public/www-style/2013Nov/thread.html
[3]
http://www.w3.org/2012/12/global-publisher/slides/Day2/P1-w3c-paris-hachette.pdf
[4] http://www.w3.org/2012/12/global-publisher/
[5]
http://www.w3.org/2012/12/global-publisher/statements-of-interest/17-tony-graham-mentea.pdf
[6]
http://www.w3.org/2012/12/global-publisher/statements-of-interest/02-workflow_adam_hyde.pdf
[7] http://www.w3.org/2012/12/global-publisher/report.html
[8] http://www.w3.org/2012/12/global-publisher/slides/Day1/P0-witwer_adam.pdf
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--