---Oleg Kobchenko wrote: > It is clear that you mean with good intentions, but > for the problem of text representation there is no > clear cut ideal solution. There are different browsers, > compatibility, different tools to convert text, etc. > Even large and expensive commercial systems that provide > multi-targeted text handling, as used in MSDN or Apple > documentation, don't provide clean solutions suitable for > all purposes. Even less would they fit in the economical > concepts of handling things in APL/J culture.
I agree that there are lots of options other than HTML and CSS. If someone want to make the case for any of them, they should feel free. I also agree that a search for an "ideal" solution is not practical, however I'm hoping that agreeing on a solution that is "better" than the current one is both desirable and within our capabilities. > So the representation chosen by Roger strikes a compromise > between content and representation with simple choice of tags. > Looking at http://keiapl.info/ for example, the result is > very well organized aesthetically, and achieved with very > simple HTML formatting means. I agree with Roger, that it > should be possible to revise existing markup incrementally > and introduce gradual changes without major disruptions. > So approach is not "new format", but stepwise improvement > of already good existing format. OK perhaps I would have been better describing my proposal as an improved rather than new format. The visual presentation is very similar to the current and the underlying code isn't that different to the current one! > For example, what Roger was hinting at is finding instances > of format-based tags and suggesting a corresponding semantic > tag, > <font size=+1>Title</font> > with > <h2>Title</h2> I will have a go at sketching the skeleton of the suggested structure and documenting the steps I took to move from the current format to the suggested one. > Tables aren't all bad, if viewed as semantic placeholders, > as long as you can identify the meaning of particular table or > it sells, possibly with a help of class or id attributes, > which can also be used for applying CSS replacing <font> or > <center>. In my opinion, going to the trouble of identifying the roles of tables and their individual cells would be more work than replacing instances of table layout markup with divs and lists as appropriate. > A bunch of DIVs or LIs paired with CSS tricks aren't so much better. I agree that any form of code can be obtuse and obscure its purpose, however IMHO the structures I've suggested are reasonably clean, and as far as I'm aware the CSS that I've suggested is pretty standard and doesn't include any "tricks". Do you have any suggestions on how to make it better? > Due to ubiquity of HTML, it makes perfect sense to utilize > it as the primary source of the document, which happens > to be rendered as is by the browsers. With good choices of > tags and attributes, it should be possible to convert it > to other formats. Couldn't agree more. > Lately there've been many solutions that take HTML, possibly with > some hints, and produce PDF directly. Such as Acrobat Professional > or HTMLDOC. They can provide TOC with page numbers, etc. Agreed, and I think that those solutions could do an even better job if the structure of the document was more evident from its markup. Let's try and come up with a plan! ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
