we don't. webflow[0] is the best I've seen. there's an OSS clone called grapejs[1], but it's still very alpha. one reason we don't see greater adoption is that WYSIWYG editors for the web occupy a sort of middle ground between template-based hosts like squarespace, weebly, etc, and opinionated low-barrier-to-entry frameworks like bootstrap. I think there's some market, especially for prototyping, one-off marketing pages, and people who don't already have a preferred design workflow, but I don't think WYSIWYG will return in a large way until these editors begin doing "real" front-end lifting -- i.e., "drag and drop this react/vue/whatever component within a grid, without having to know what react/vue/whatever is." the appeal of dreamweaver, frontpage, and all of those editors in the 90s was that not everyone and their mother was a coder, but everyone and their mother did want to be on the internet, and there were none of the aforementioned saas or framework solutions to rely on. in 2016, there's no lack of coders and tooling, so if you don't want to write your own code, you may as well just spend the $10 for a shop overseas to turn your static layout into a responsive webpage overnight.
React Studio is trying to do that:
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.
> 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?
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...
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.
When it comes to the high-end, there are Mac apps such as Hype and Sparkle which are used especially for developers who want to create animated websites.
It's also the case that creating a webpage isn't the most important thing anymore. Many businesses only exist on Etsy and Facebook. The time when knowing what html is and knowing how Dreamweaver works meant you could make a living off of anyone who wanted to be "on the Internet" is kinda over.
All the developers that might do static frontends code by hand or use a library like Bootstrap or a theme like a WordPress theme. So there is not really much room for a tool like Dreamweaver in the landscape of web design. It's all about modifying existing things to make them fit the problem.
WYSIWYG requires a fixed layout size, which was common back when dreamweaver/frontpage were around.
And there are still issues like css being polite suggestions rather than rules a browser has to follow. Firefox recently introduced a readability mode for instance.
That's wrong, and analogous to saying that people who understand low level programming don't need IDEs.
Different screen sizes and WYSIWYG use are orthogonals. Any WYSIWYG editor worth its salt has supported media queries, previewing on different screen sizes, breakpoints, etc for ages.
They aren't entirely gone though, this was posted to HN a while ago: https://preview.webflow.com/preview/flexbox-game?preview=d1a... It's a game in their editor that teaches you flexbox.
Now add in progressive enhancement.
We're not dealing with the largely fixed desktop viewport anymore.
That I suspect is why WYSIWYG hasn't taken off, Dreamweaver did quite well, but then the web ran away to multi-platform as the default.
There is also Sketch, which is a vector design tool that shines at designing user interfaces. And unlike Photoshop, it is extremely friendly to the web - if you can do something in Sketch, that can be done in CSS.
We're building a tool that converts these designs into code (HTML, CSS, SASS, React, ERB etc). That gives a sort of WYSIWYG workflow for pro users. You can have an expert designer do your design, and then have a developer run with it by generating quality code from them.
Adobe Edge is dead.
https://www.adobe.com/products/edge-animate.html
Note: As of November 2015, Edge Animate is no longer being actively developed.
Prior to cessation of development it stagnated for a few years before finally being put down. Shame, really.
We've used WebFlow for a couple of years; it doesn't suck and you can actually build an early stage [pre-rev] business with it before committing to a full stack team/budget.