Re: [xml-dev] XML vocabulary for expressing constraints?

["Simon St.Laurent" <simonstl@simonstl.com>]

On 12/19/13 11:14 AM, Steve Newcomb wrote:
> On 12/16/2013 06:37 PM, Simon St.Laurent wrote:
>
> > There is also a growing, though I think unfortunate, school of web
> > application design that thinks of HTML as merely a serialization for the
> > underlying DOM created and manipulated through JavaScript.
> Simon, I'd be pleased to see you expand on why it's unfortunate.
> Several possibilities occur to me, but it would be interesting to know
> which, if any, of them you are thinking about.
John Cowan had good answers, but mine are at least somewhat different, 
and there are at least three versions:

Social
   Treating HTML as a mere serialization assumes people start in 
(pretty deep) JavaScript, with all the skills and background that requires.

Technical
   It is so much easier to create infinitely twisted JavaScript than it 
is twisted HTML or CSS that it cranks up the difficulty level even more.

Accessibility
   For many readers, that "mere serialization" is what their software 
can access, so things like sequence matter even when it doesn't matter 
for display.

I think these reinforce each other, though telling them seems to 
aggravate various communities in different ways.

On the social side, I've argued for a long time that much of the power 
of markup lies in the ease of tinkering with it.  That argument 
flickered a bit around XML well-formedness, but HTML has come back 
around to accepting human markup foibles.

This plays through many dimensions - I'm not expecting everyone to take 
up the markup cudgel. I do think there's tremendous value in designers 
working with HTML and CSS rather than Photoshop mockups, and in content 
contributors being able to create rich material quickly. I show such 
folks JSON and they aren't usually excited.

On the technical front, creating the HTML tree through JavaScript, even 
when using a template system (pick your poison) is almost as troublesome 
as generating markup as text from a program.  It requires much more 
program logic and testing than "load HTML".  Looking at the source code 
for a document that is basically a call to a script that then sets 
everything up is not very useful.

Invoking a Turing-complete and notoriously intricate language to, um, 
create a document seems like overkill.  Manipulate, sure.  But create? 
Why?  Also, JavaScript, despite massive recent performance improvements, 
is still far slower than the native "read HTML and CSS" built into 
browsers.  I marvel at how fast you can, for example, tell a browser to 
apply a different stylesheet to a document and have it just happen like 
that.  The costs of parsing and styling are tiny compared to the costs 
of JavaScript tree manipulation.

On the accessibility front, it's entirely possible for JavaScript 
generating a set of nodes to get it right - recent screen-readers can 
cope (though Lynx just chokes).  However, programmers seem even less 
enthusiastic about issues like document order than document creators. 
It's easy to drop nodes into a tree and have the stylesheet put them 
wherever they're needed visually, without paying attention to where they 
are in the HTML for people whose tools focus on that.  Navigation 
frequently ends up at the very end of the document, for example.

Ideally, as discussed in <http://responsivelayouts.jensimmons.com/> for 
example, I'd encourage developers and designers to start with HTML, get 
the markup structure right, then layer CSS on that, and then layer 
JavaScript on top of that.

It is _possible_ to get all of this right starting from JavaScript 
constructing a tree, but it is rare. Much as I like it, JavaScript seems 
to me to be the wrong place to start building a web application.

I understand the appeal of single page applications (SPAs) to 
programmers used to working in a single program context, but they often 
throw away the strengths of the markup layer and (though they still 
generally use HTTP) the web model of connected resources broadly.

Does that explain 'unfortunate'?  I certainly publish and encourage 
conversation on these things, but that doesn't mean that I think they're 
all equally good ideas.

(At present I'm leaning more and more heavily toward declarative 
approaches period - see for example 
<http://programming.oreilly.com/2013/12/declare-and-it-happens.html>.)

> I think an argument could be made in the other direction, too -- that
> HTML, or any other notation, should be regarded in whatever way its
> authors regarded it, because that's an attitude that's fundamentally
> necessary for communication between human beings to succeed.
I don't think that's how the world works.  It's how we describe trust 
and good will, but the reality is that we consider author context when 
we consider it valuable.

> I usually treat HTML as slightly-defective SGML; it's an attitude that
> works pretty well for me.  I must have missed the bus to the world where
> there's no SGML any more; I seem to be living in a world where there's
> still much more SGML than XML.   Considered in that light, the DOM is an
> "SGML Application" (that phrase is HyTime jargon) whose interchange
> syntaxes are described by DTDs.  As an SGML Application, the DOM seems
> to me no less valid than any other.
I think that used to work, but HTML5 for reasons of its own has made 
that more complicated.  However, I'm not sure that those theoretical 
complications create real problems.

Thanks,
--
Simon St.Laurent
http://simonstl.com/