Getting past the HTML / XML splits
A few years ago, I stopped talking about XML and starting talking about markup. After a few too many conversations with developers who had found XHTML, web services, and various other things that had proudly branded themselves with the “X,” it was clear from hostile responses that XML’s boom was done.
Many of Wednesday’s Balisage talks wrestled with the challenges XML tools face in a world dominated by competitors, especially HTML5. Today opened with a talk on making XForms work in HTML5 with browsers, followed immediately by a talk on replacing DocBook XML with XHTML5 (at O’Reilly). Two more abstract talks looked at filtering and an info space model, but the afternoon asked “Where did all the document kids go?” and then sought world domination by making XML invisible.
FtanML looks for the best of both
Today’s Balisage conference got off to a great start. After years of discussing the pros and cons of XML, HTML, JSON, SGML, and more, it was great to see Michael Kay (creator of the SAXON processor for XSLT and XQuery) take a fresh look at what a markup language should be.
You thought CSS was weak? Think again.
After years of complaints about Cascading Style Sheets, many stemming from their deliberately declarative nature, it’s time to recognize their power. For developers coming from imperative programming styles, it might seem hard to lose the ability to specify more complex logical flow. That loss, though, is discipline leading toward the ability to create vastly more flexible systems, a first step toward the pattern matching model common to functional programming.
Way back when I was writing about styling XML in browsers, I didn’t even have to stop to think about how difficult it would be to repurpose CSS selectors for XML documents. Since they weren’t tightly bound to assumptions about HTML beyond the existence of elements and attributes, they just worked.
The tool that most vividly demonstrated the real power of selectors, though, was jQuery. I may have annoyed some people by referring to jQuery as “that framework that lets you use CSS selectors instead of DOM tree walking” for a while, but Remy Sharp makes clear the power of that:
The ease in which jQuery could be learnt was the appeal to me. All the DOM navigation was done using CSS expression using some insane black box magic that John Resig had come up [with] – saving my limited brain power, and once I had those DOM nodes, I could do what I wanted to them (usually some combinations of showing, hiding, fading and so on).
Over time, as Sharp notes, Web browsers learned from jQuery, building this basic lesson deeper into their tools and making it work more efficiently:
In those 7 years, quite a bit has happened. Probably one of the most important steps forward was the introduction of querySelectorAll.
Being able to give a native function of a browser a CSS expression, and it doing the work to navigate the DOM is a huge (literally) part of jQuery.
Doing less and more than XML.
It’s easy to forget that XML started out as a simplification process, trimming SGML into a more manageable and more parseable specification. Once XML reached a broad audience, of course, new specifications piled on top of it to create an ever-growing stack.
That stack, despite solving many problems, brings two new issues: it’s bulky, and there are a lot of problems that even that bulk can’t solve.
Two proposals at last week’s Balisage markup conference examined different approaches to working outside of the stack, though both were clearly capable of working with that stack when appropriate.
The blurry line between markup and programming.
When XML exploded onto the scene, it ignited visions of magical communications, simplified document storage, and a whole new wave of application capabilities. Reality has proved calmer, with competition from JSON and other formats tackling a wide variety of problems, while the biggest of the big data problems have such volume that adding markup seems likely to create new problems.
However, at the in-progress Balisage conference, it’s clear that markup remains really good at solving a middle category of problems, where its richer structures can shine without creating headaches of volume or complication. In the past, Balisage often focused on hard problems most people didn’t yet have, but this year’s program tackles challenges that more developers are encountering as their projects grow in complexity.
How one vowel creates a limiting design paradigm
The first group/publisher/company/person who moves away from the ebook and to content — content that can be delivered to a variety of media, digital and non-digital, with display and style applied separate from and after content creation — wins.