W3C home > Mailing lists > Public > public-html@w3.org > July 2008

example with source code

From: Dailey, David P. <david.dailey@sru.edu>
Date: Sun, 13 Jul 2008 23:54:09 -0400
Message-ID: <1835D662B263BC4E864A7CFAB2FEEB3D01525539@msfexch01.srunet.sruad.edu>
To: "Ian Hickson" <ian@hixie.ch>, <public-html@w3.org>

Hi folks.
 
Ignorant of much that is in HTML5 I am wondering if a solution to this problem has already been addressed:
 
In writing instructional materials (we in teaching might call the stuff "lessons" and those in industry affectionately refer to it as "doco" *), one might often wish to speak to one's audience at two levels simultaneously, displaying both the appearance of something and its underlying mystery (source code) in the same immediate vicinity (whether vicinity be defined spatially or temporally or otherwise).
 
-------begin example-----------
Here is the text the way it appears in a browserlike application. With a line break, an ellipsis, a comma....,
and then,       several spaces in the second line.
---------------appearance above----source below---------
<p>Here is the text the way it appears in a browserlike application.  With a line break, an ellipsis, a comma...., <br/>and then,(%nbsp;5) several spaces in the second line.</p>
-----end example------
 
The markup language (be it (x)HTMLy.z, SVG, CDF, docBook ...) is largely irrelevant.
 
Is there some way to just write the source code (or wysiwyg plaintext) just once inside the appropriate tag(s), instead of having to parrot onesself?
 
I'm thinking of something like <sourceAndDisplay><p><b>Hello World</b></p></sourceAndDisplay>
which would allow the author to maintain only one sequence of characters (rather than markup and appearance being maintained separately and in parallel).
 
At NCSA (in the proto-Mosaic days) there were ways to display the /\sourcecode/\ within a clew of strings, but it was rather time-consuming and arthritis-inducing (hence failing the accessibility criterion for geriatric typists), and I believe <xmp> and <textarea> and <pre> and <code> and <samp> have all surfaced from time to time with various advocacy groups supporting them<wavingflags/>, but with generally little agreement among browser builders about how this ought to be done.Perhaps (x)html.y.z found a solution, but I was too busy to notice.
 
In the past decade or so, I have experimented a bit with the use of script to do this (e.g. http://srufaculty.sru.edu/david.dailey/javascript/HTMLserialize.html  which goes from markup to DOM to display using innerHTML, or http://srufaculty.sru.edu/david.dailey/javascript/markup6.html which approaches the problem in just the opposite way, by going from user-generated markup to rendered content using "eval" to created a virtual homunculus within the browser.), and while the idea of writing a new improved browser in JavaScript is appealing, one has the unfortunate circumstances that one has to have a browser to start with and worse yet has to have a computer rather than a Turing machine to test it in. :)
 
 The example at http://srufaculty.sru.edu/david.dailey/javascript/HTML.select.html might show, better, what I have in mind, vis a vis, using script to allow the author to maintain only one set of code per example.
A related piece of code is at  http://srufaculty.sru.edu/david.dailey/javascript/showStuff.html which was discussed briefly here http://lists.w3.org/Archives/Public/public-html/2007May/0256.html a year or so ago.
 
Anyhow, though the script needed to run some of these examples is not complex, it is not likely to be codeable within a robotscripter like FrontPage or Dreamweaver, and I'm thinking that a nice <dualpurpose>both wysiwyg<i>and</i>markup</dualpurpose> sort of container could be rather handy. Of course the use case would be limited to those who wish to make such things as specs understandable, so it may not command enough of a presence in the grand scheme of things to make it into a spec.
 
The reason it came up, is that I just encountered the equivalent problem in "Docbook", so in truth I think the identical problem is not limited to (x)html.y.z . It is a bit Goedelian, of course.
 
cheers
David Dailey
 
*"doco" is short for documentation following the 20th century English morphological construction : info<--information; ammo<--ammunition; convo<--conversation; reco<==recommendation; etc.
Received on Monday, 14 July 2008 03:54:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:56 UTC