-
Notifications
You must be signed in to change notification settings - Fork 1
Content formatting #5
Comments
Of course My feelings are that we'd pretty much head for the latest inventions. What we do here now will be there in 2039. |
I agree that this should be improved. However, if we want to continue using the help plugin, we need to stick to HTML 2.1 (Java support issues) Whether we do want to continue with the help plugin is a discussion for the broader community, post-3.1. |
Most of the files come with this 'meta-info' or what ever...
Some (quick display pages mostly) are "just plain html".
Hmm... In the ROW help usually launches the default www-browser. Most of them read the content online. |
Keep in mind that the metadata is just that... Metadata. The HTML renderer will simply ignore tags that it does not understand. As long as the formatting tags all existed in HTML 2, they will renderer properly. Rebuilding how help works looks like a bigger project, I'm personally not opposed to using the system browser, but let's see what comes out of the community. |
I had a look at the Help code. The parts of the manual, that have been copied to Help have been edited by a html-tool and even though both the original and the help-version look rather messy, it's a different kind of a mess. One other problem are the translations. At least some of the .es and .it files actually are in English. --> Not worth keeping the Help as a bottle-neck, when working on the manual.
You could say that again. |
The page formatting should be unified and visually clarified.
There may be a few challenges in getting it right as sometimes the visualization needs to take it's own space. However I'd suggest to:
At first I'd probably suggest .css:es. On the longer run we might consider php to collect the content of each page. That part is quite logical and effortless to use but php also offers a lot of toys, that probably would not be useful in this case (fancy ways of animating page changes etc).
Low level browser adaptation should be good enough and no device dependent adaptation. I think it is safe to assume tabletop or laptop usage and not so much pocket size devices. (Though, setting it up to recognize the platform is not that difficult but then we'd go JavaScript. Androids mostly respond in a predictable manner, but the late Windows phones were an ultimate disaster in interpreting the mark-up code.)
The text was updated successfully, but these errors were encountered: