[rkward-devel] enhancements to HTML output [was: icon soup]
thomas.friedrichsmeier at ruhr-uni-bochum.de
Thu Jun 30 14:02:41 UTC 2011
On Tuesday 28 June 2011, meik michalke wrote:
> am Dienstag 28 Juni 2011 (12:06) schrieb Thomas Friedrichsmeier:
> > I guess, having one output file per workspace would be a good default
> > behavior (but of course, users should also be able to start new output
> > files, manually, easily).
> sounds great!
yeah, but no promises as to when it will happen.
> maybe create an "in.TOC=TRUE/FALSE" option for rk.header()?
I'm not sure. Do you think there should be any rk.header()s, which are not in
the TOC (unless perhaps those with level >= n)?
> hm, frames are a bit out-dated, aren't they? but i think i see where you're
> heading. how about reserving space for the TOC as a left margin and placing
> it there in a <div style="position:fixed;"></div>? the downside would be,
> if the TOC gets longer than page height, you couldn't reach the lower end.
> but that should be solveable, somehow (or an incentive to reset your
> output at least once in a while...).
Yes, I know, frames are sort of 1990ish. But the problem is not so much the
layout (that's certainly solvable in CSS, somehow), but rather updating the
TOC. The output is generated step-by-step by simply appending to the end of
it. Having the TOC in the same file would mean considerably more complicated
modifications. In contrast, if the TOC is kept in a separate file, we can simply
append to each.
That's why I was thinking of frames. Of course, a two-file-solution could also
> > b) and c) probably cannot be done in plain HTML, indeed. Rather this
> > should probably be implemented in C++, as a context menu.
> sounds interesting ;-) i'll have a look at HTML5, too, maybe there's some
> nice and useful new stuff. if it could be done rather cleanly in the
> output document itself, it would remain more portable with its
> functionality. but it's just a vague idea now.
Well, yes. But on the other hand, I am a bit worried about the UI, too. I
imagine a context menu will be a more natural place for this functionality.
Also, I think that at least for c) (the deletion), portability is not much to
- If users want to take the HTML to a word processor, they can use the word
processor's functions to modify it.
- If users want to publish the HTML, they will not want to / be able to
support modifications of the document, anyway.
So I think this is only of interest within RKWard. It's not quite as clear-cut
for b) (the copying), but to some degree, the same argument applies, IMO.
> however, i'm often surprised what can be done in one markup file. for
> instance, some time ago i've written a simple jeopardy game with HTML, CSS
> o http://reaktanz.de/stuff/jeopardy/ircotofun.html
> not pretty, just a POC, too. but it's just that one file (i've written a
> bash script to create that file with custom questions, so you can actually
> play it).
Nice hack ;-).
But of course one thing to note is that in RKWard, as a user, I would expect a
deleted section to be truely deleted, not merely hidden by CSS, in particular,
if I ever want to publish the HTML. Also, be aware that the output file gets
reloaded on changes. That might further limit what can be done with JS.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the Rkward-devel