Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML vocabulary for expressing constraints?
 On 12/19/13 11:14 AM, Steve Newcomb wrote: John Cowan had good answers, but mine are at least somewhat different, and there are at least three versions: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. 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 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 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 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.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. Thanks, -- Simon St.Laurent http://simonstl.com/ 
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
