> Embedded and inline editors would include the textarea tag, which is > clearly > not WYSIWYG for HTML (but is for plain text) so both are poor terms. Embedded, inline editors would include "contenteditable" areas and documents with "designMode" on, like the box I'm typing in right now in Gmail. Quite a number of the cheap HTML to PDF conversion processes don't support > CSS. Additionally, syndicated HTML (via Atom, RSS etc) tends to have > inline > CSS removed because of cross site scripting vulnerabilities (you can embed > > JavaScript in CSS and at least IE will execute it). It's not so much "cheap" as lightweight. A "heavyweight" converter can automate the process of opening a page in a browser window, print what's in the browser (more or less, some do more than just activate the browser's "print" function). A lightweight converter might natively try to interpret the HTML and try to render it as postscript. I think better solutions are coming along for the case of converting an HTML document to PDF in all its graphical glory on a server without X Window, etc. (e.g. a way of using Gecko to do the work without opening a window.) I don't think it's necessary to cater to these systems by allowing presentational markup.
Received on Wednesday, 2 May 2007 01:40:11 UTC