[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] p tags in docs

Was away for a couple of days, so dropping in on this late.

On 17 Dec 2008, at 15:04, Julian Rohrhuber wrote:

Still, there's a major, higher issue here.
We want to maintain the domination of macosx in terms of ease of use.
That's ok (I'm on mac).
But cocoa compatible html generation (Helper mimics it) is really a bad trick IMHO.

if you have managed to find a stable automatic way to translate from the cocoa webkit's html format to a more human readable format that displays the same, it would be good if this script could be integrated SC on os x in a way that it works more or less in the background. It would be difficult to keep up with modifications done and resaved from os x (which will save it again in cocoa style, as far as I know).

Yes, this is correct. Once the document is opened the html is gone. It is generated anew each time the file is saved. This would not be trivial to change.

So you can convert anything you like, but the next time someone edits it in SC.app, your changes will be gone, and <p> tags will be back.

FWIW, in my experience the Cocoa HTML Writer output looks good, and surprisingly consistent, in all major rendering engines. That was in fact the appeal. w3m obviously doesn't do as well with it.

If you want to do something like this you'd probably be better off working on the Cocoa layer to edit the generated html. But you'd want to make very sure that this doesn't mess anything up, and I'd tread carefully in terms of doing anything very ambitious, as it could lead to unforeseen issues. Nobody will be happy if things become worse than what we have now, even if the html is prettier. I did start looking at something like this at one point.

<pre> tags render very inconsistently, IME. The existing version does a better job with most examples in most cases I think. I say this having tried <pre> tags in the OSX app and found them to be a colossal pain in the ass.

I don't know what Scott thinks of all this

I think any substitute for or variation on the current approach must:

- Be WYSIWIG editable, more or less, at least in the OSX app
- Render consistently in major engines.
- Not be in any way worse than the current situation.
- Have someone willing to convert and maintain it. Half converted and/ or abandoned approaches won't do.

The last is the monster job, and so far nobody has been willing.

Personally I don't think the ugly html is a big deal. There are free WYSIWYG html editors for all platforms, and the help files should be simple anyway. I know it really bugs some people, but for the most part there should hardly be a reason to look at it. Two cents, flame shield on...

Anders, if your div substitution works, and looks better on w3m, that would be an easy thing to add in the Cocoa layer. There's already a bit of cleanup on the html being done. I could easily add this, but I'd like to know that testing on this has been done first. Would in any case be nice to solve this long-standing annoyance for scel users.


sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/