[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.
S.
_______________________________________________
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/