Word processors such as Microsoft Word are said to be WYSIWYG: what you see is what you get. In a sense that’s true, but in another sense markup languages such as HTML or LaTeX are really WYSIWYG.
With WYSIWYG programs, what you see is what you will get visually, if all goes well. If you think of the computer file as simply an intermediary between your keystrokes and paper coming out of a printer, the paper is “what you get.”
But more fundamentally, what you get when you edit a file is a file. And the relationship between your keystrokes and the changes in the file could be quite obscure. With text files, such as files containing source code, what you see is what you get in the sense that the characters you see in your editor correspond directly to the contents of the file.
Sometimes I’m quite happy to be ignorant of how my keystrokes correspond to file contents. When I’m cropping a photo, for example, I’m grateful that I have a visual interface and can be safely ignorant of the layout of bytes in a file. But for other tasks, text files are simpler because there are no mysterious forces at work: what you see really is what you get.
“there are no mysterious forces at work”
Well, there’s the TeX interpreter between that text file and your output. I don’t think that you think of a text file as predictable if it is passed through a complex program. In fact, what you’re up against is a variant of the halting problem.
TeX is is a simple file passed through a complex program, but at least the file format is transparent. Word files are complex files passed through a complex program.
(MS Office files are more transparent than they used to be. Since 2007, Office documents are zipped XML. But the XML is still intended machine to read and write, not for humans. Hacking the XML is a last resort, though I’ve done it a few times.)
Text files are also friendlier with generic tools, such as: version control systems (svn, git, etc.); diff viewers; Unix-like tools such as grep, sed, awk, etc.. This means that if the format is text you are instantly more productive with it than if it was binary.
Precisely, WYSIWYG is a lie. Today we are creating documents where their final form is electronic. And more so we often are creating live documents that need to be maintained and updated, sometimes collaboratively. In that case “what you get” is no longer an immutable printed piece of paper, it’s that document. And you can no longer see what you get in those documents.
Open up a random word document, then move the cursor to a random location. Now, predict what will happen when you press a letter, or the enter key. Better yet, ask yourself how you would add another item to a table, or a bulleted list. Sometimes these things are easy and predictable but the important point is that due to the demon of INVISIBLE STATE in so-called WYSIWYG documents these behaviors are not nearly as predictable as they should be. I’ve had many documents where inserting letters in the middle of a word did so in a different font and color, which is not at all what you would expect.
Today the focus on paper oriented typesetting in document editors is misplaced, that is by far the minority use these days. What is needed is some predictability and more usability in terms of actually showing you “what you get” in terms of an editable document with predictable formatting when changes are made. Which is a huge reason why things like wikis and markdown based text have been making such big advancements.
Good points. Also, WYSIWYG is highly misleading on the web. What you see when you author an HTML file in MS Word may or may not be what you get. And more importantly, what you see is only a fraction of the story. What you get needs to take into account how user interactions work, how machines read/spider/archive the page, etc. (See also the Semantic Web.) And yes, editing something like Markdown gives you a rough feel for what you get, without misleading you into thinking that it’s exactly what you or others will see when it’s displayed.
Also, WYSIWYG is a horrible lie the moment you deal with people who, for example, can’t see. Accessibility is more complex than just a new stylesheet but, for some documents and some kinds of accessibility, a new stylesheet is a good start; the larger point is that WYSIWYG documents necessarily confound content and presentation in ways that you simply cannot when you need to present the same document to many kinds of people with many different ways of perceiving the world.
I still miss Word Perfect’s “reveal codes” feature. I don’t know how we as consumers let Microsoft win the word processing “wars” of nearly 20 years ago without having implementing what I think is a very important feature.
My preference is for complete control (Latex, HTML) or complete transparency (Photoshop). Compromises don’t work. Brief anecdote: a few years ago I was asked to prepare a contract from a Word template. I clicked on “track changes” and there was a previous contract with confidential information that I was not supposed to see! Couldn’t happen with Latex!
20 years ago when I designed/wrote much of the WYSIWYG code for WordPerfect, I had a a colleague who claims the correct acronym was WYSIWYS – What you see is … what you see!!!
It’s not WYSIWYG..
Neither is Notepad++ for that matter.
Despite this fact, I had an HTML instructor reject the use of Notepad++ because Notepad++ claims to be WYSIWYG. The, not really qualified for the position of teacher, instructor never bothered to use Notepad++ to determine what exactly the developers claimed to be WYSIWYG which in Notepad++’s case is the color coded text within the editor. If you print such a document from Notepad++ on a color printer, the text will print out in their perspective color (WYSIWYG).
Unfortunately, some people who should know better, are as dense as little children that cannot discern the difference between playing in the road when it is safely blocked off and playing in the road when there are no blockades. Little children by the way, have very valid and legitimate reasons for their condition; it’s called lack of conceptual ability, teaching and experience. The adult in the position of teacher that displays such denseness is both lazy and incompetent.
So be careful in using WYSIWYG, you may just may sentence a student somewhere to the use antiquated text editors such as MS notepad, rather than that nifty new program you just wrote to make it a bit easier to code.
Scott A. Tovey
In the context of discussing the advantages of LaTeX, someone said the problem with WYSIWYG is that what you see is all you get, i.e. no adjusting the visual representation according to context, no typographical fine points automatically applied, etc.
Quoting John ” someone said the problem with WYSIWYG is that what you see is all you get”. Brian Kernighan said “What you see is all you’ve got” at a documentation conference circa 1983 and probably on other occasions as well.
To use a WYSIWYG editor is to separate presentation and data. If you’re doing this then you should have the editor generate XML or JSON, giving you a lot more flexibility of what you can express and use the data for.
The problem with the WYSIWYG paradigm is that it allows arbitrary trees and the data is mostly meaningless. Despite it separating presentation and the underlining data, that distinction is meaningless because it only deals with presentational data. Paragraph here, heading there, italics here. The user can do anything they want and make a right mess. And you can’t do anything with the data anyway.
What you want instead is a WYSIWYM—“What you see is what you mean”—an editor generated from a schema. Then you can have both validation and structural coherence. The document can contain actual data. Charts and graphs, inline tagging, coordinates, statistics, dates, expiry times, etc. The editor can suggest elements that are relevant for this kind of document, disallow things that shouldn’t be in here for dumb end users, etc.
The whole set of documents can be indexed and searched and treated semantically, provided as JSON or oEmbed, etc. You need to do transformations on the content of the document? No problem, write a migration script that transforms the XML/JSON/DB schema and away you go. Give me all the links in the database. Easy. Give me all phone numbers. Easy. You gain so much by this and lose so much by the arbitrary-HTML WYSIWYG or Markdown/Wikimedia approaches.
Chris Done said what I was coming here to say, for the most part. WYSIWYG is about seeing the intended presentation of a document, and not the actual contents of the document.
Something to which Chris alluded, but did not explicitly say, is that in the WYSIWYG paradigm, there is no real content in your file. All those words you see in the final presentation are simply treated as part of the presentation by that paradigm. The letter “H” is a discretely encoded component of presentation data, rather than a character that makes up part of the content data of a document.
Semantic HTML is kind of a bridge between content data and presentation data, but the real meat of the file is content, and the real meat of presentation is CSS and rendering routines. This makes semantic HTML much more WYSIWYM than WYSIWYG.
I do believe you can reveal codes in the latest Word incarnations. On the Home tab in the Paragraph section, you can click on the paragraph symbol (a backwards looking P). I used to use WP 5.1 exclusively and know that it was far more revealing in what codes were revealed. ;)