[rkward-devel] enhancements to HTML output [was: icon soup]

[Thomas Friedrichsmeier]

Hi,

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 
work with <iframe>s or with some javascript.
 
> > 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 
worry about:
- 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
> and only a little javascript:
>  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.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20110630/5deeb4f3/attachment.sig>