4 ms·

Last 10 years I am in the business of making WYSIWYG editors of various kinds. Yet I am an author of BlockNote.net HTML WYSIWYG editor (it is pretty old but wor

by c-smile 10y ago

Last 10 years I am in the business of making WYSIWYG editors of various kinds. Yet I am an author of BlockNote.net HTML WYSIWYG editor (it is pretty old but works up until W7). HTML/CSS WYSIWYG editing from mathematician point of view: Second main task of a browser is: by having given HTML/CSS to produce set of pixels on window's surface. On other side WYSIWYG editor is aimed to solve opposite task: from desired set of pixels (those ones you want to get) to restore/produce acceptable HTML/CSS combination. The problem is that the task can be accomplished only with pure HTML. As soon as you add CSS to the equation acceptable WYSIWYG becomes barely possible: the same set of pixels (rendering on the screen) can be achieved in many different ways. Layout can use floats, absolute positioning, flexes and grids recently, etc. Direct task (rendering) is perfectly formalize-able and solvable (HTML5 and CSS specs) - we have at least three independent implementations of these formalizations. But opposite task (HTML/CSS structure synthesis from given image) has no determined solution. And so different WYSIWYG systems use different approximations. Like Microsoft Word, it produces HTML/CSS documents that are pretty close to what you just saw in it, but that HTML/CSS is barely readable and reusable as HTML/CSS. Others produce readable HTML but rendering is far from what you want to see. Therefore "ideal" WYSIWYG editing of HTML/CSS is not achieavable in principle. You need to give up something - either WYSIWYG quality per se or feature set. Like you can have WYSIWYG editing but for editable text alike islands: content area of your blog site for example.

dualogy 10y ago
Interesting thoughts! > Therefore "ideal" WYSIWYG editing of HTML/CSS is not achieavable in principle. I think users just need to be (made) aware that any & all web pages' design is always "template/theme"-driven. Even in the absence of CSS: the browser then falls back on its unique user stylesheets / factory defaults (black Times in unpredictable font-size on white background, unless maybe hi-contrast accessibility setup has the colors reversed, unless, unless, etc..) MS Word-style "WYSIWYG" looks like a "simpler" problem in this respect because a piece of paper is a piece of paper (not really though as printing settings can easily mess with what what-they-saw-they-thought-they'd-get). Any sane web-page WYSIWYG must separate the content-formatting-without-tags (bold/italic/a picture floating to the right/etc) from style editing --- so will be essentially (at least) really "2 editors" (in 1). Now as the user quickly grasps this intuitively after just a bit of tinkering, I don't really see the issue anymore?
type0 10y ago
HTML and WYSIWYG shouldn't really be in the same sentence. It is such a promiscuous but tollerant format/language that it instantly produces a mess. There are some interesting videos about it on computerphile: https://www.youtube.com/watch?v=-csXdj4WVwA https://www.youtube.com/watch?v=-csXdj4WVwA (Where HTML beats C?)
jasim 10y ago
Very well put. I've been tackling a similar problem with my product Protoship UIPad - "Find the optimal HTML and CSS for an image". By optimal I refer to code that a skilled developer would write themselves and will be happy to own and maintain themselves. We've seen terrible code generators - they make our lives harder and have no market. I chose to solve this by using Sketch, which has rich layer information - is it a text, is it centered, is it a rectangle, what is its background color etc. Sketch also has layer names, which can be mapped to component oriented CSS. The difficulty is in finding the optimal positioning for this, which we solve a little algorithmically and also through user annotations. You can read more about my approach and its trade-offs here: https://medium.com/sketch-app-sources/protoship-uipad-design-to-code-fd133f5986c1 https://medium.com/sketch-app-sources/protoship-uipad-design...
protexilu 10y ago
Tme to pull out the deep neural nets! Isn't the problem that you're describing a bit like generating, say, words given an image? Sure, there are several differences, but it's an interesting problem. Easier than caption generation? - There's only one possible outcome for HTML/CSS --> website look - And we know what this outcome is (just render the thing) - not a lot of "words" in the vocabulary... there are only so many tags and styles we can use (at most a couple hundred), with most of the complexity coming from the combinations of these elements But in some sense, it might be a harder problem, since the idea of web development is combining these "words" in a way that makes sense. So there might be a harder-to-learn grammar.

by c-smile 10y ago

dualogy 10y ago

Interesting thoughts! > Therefore "ideal" WYSIWYG editing of HTML/CSS is not achieavable in principle. I think users just need to be (made) aware that any & all web pages' design is always "template/theme"-driven. Even in the absence of CSS: the browser then falls back on its unique user stylesheets / factory defaults (black Times in unpredictable font-size on white background, unless maybe hi-contrast accessibility setup has the colors reversed, unless, unless, etc..) MS Word-style "WYSIWYG" looks like a "simpler" problem in this respect because a piece of paper is a piece of paper (not really though as printing settings can easily mess with what what-they-saw-they-thought-they'd-get). Any sane web-page WYSIWYG must separate the content-formatting-without-tags (bold/italic/a picture floating to the right/etc) from style editing --- so will be essentially (at least) really "2 editors" (in 1). Now as the user quickly grasps this intuitively after just a bit of tinkering, I don't really see the issue anymore?

type0 10y ago

HTML and WYSIWYG shouldn't really be in the same sentence. It is such a promiscuous but tollerant format/language that it instantly produces a mess. There are some interesting videos about it on computerphile: https://www.youtube.com/watch?v=-csXdj4WVwA https://www.youtube.com/watch?v=-csXdj4WVwA (Where HTML beats C?)

jasim 10y ago

Very well put. I've been tackling a similar problem with my product Protoship UIPad - "Find the optimal HTML and CSS for an image". By optimal I refer to code that a skilled developer would write themselves and will be happy to own and maintain themselves. We've seen terrible code generators - they make our lives harder and have no market. I chose to solve this by using Sketch, which has rich layer information - is it a text, is it centered, is it a rectangle, what is its background color etc. Sketch also has layer names, which can be mapped to component oriented CSS. The difficulty is in finding the optimal positioning for this, which we solve a little algorithmically and also through user annotations. You can read more about my approach and its trade-offs here: https://medium.com/sketch-app-sources/protoship-uipad-design-to-code-fd133f5986c1 https://medium.com/sketch-app-sources/protoship-uipad-design...

protexilu 10y ago

Tme to pull out the deep neural nets! Isn't the problem that you're describing a bit like generating, say, words given an image? Sure, there are several differences, but it's an interesting problem. Easier than caption generation? - There's only one possible outcome for HTML/CSS --> website look - And we know what this outcome is (just render the thing) - not a lot of "words" in the vocabulary... there are only so many tags and styles we can use (at most a couple hundred), with most of the complexity coming from the combinations of these elements But in some sense, it might be a harder problem, since the idea of web development is combining these "words" in a way that makes sense. So there might be a harder-to-learn grammar.