Re: Toward WYSIWYG Web Page Authoring

Thanks Kevin for taking the time. Your response was, as usual, very helpful
and insightful.

-F


"Kevin Spencer" <kevin@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:e5P8Rb0xFHA.3124@xxxxxxxxxxxxxxxxxxxxxxx
>> What is the likelihood (and what would it take) of having any true
>> WYSIWYG Web page development capability on the Web - ever?
>
> First, let me give a brief history lesson, followed by some current
> events, and an optimistic theory about the future. After all, it really
> isn't logical to talk about the current issue without putting it into
> historical context, and it isn't possible to solve a problem without
> knowing something about what brought it about.
>
> All of this is due to a chain of events that began with the invention of
> HTML and the web browser, less than 2 decades ago. At that time, web pages
> were just plain text documents. HTML was markup language derived from
> SGML, and a fairly straightforward markup language for doing some fairly
> simple formatting of said documents.
>
> HTML had some serious flaws in it, most importantly the use of in-line
> attributes that were specifically defined for each type of tag, which made
> it unextensible and inflexible. HTML was originally designed to not be too
> strict about things like case, closing of tags, placement of tags, etc. My
> guess is that this was due to the fact that in the beginning, there were
> no GUIs for developing HTML documents, only text editors. This meant that
> human error was likely to occur frequently, and the lack of strictness
> accomodated humand pretty well. No doubt there's more to it, but this is
> supposed to be "brief."
>
> Despite its flaws, HTML became the standard, by means of the Mozilla
> browser being the only web browser in existence at the time. However, it
> wasn't long before other browsers began to appear. This posed a new
> problem, due to the open nature of the Internet, and the lack of a central
> authoritative agency to determine standards. New browsers introduced new
> proprietary tags, and new ways of interpreting HTML, and competition led
> to the infamous "browser wars," most notably typified in the struggle for
> supremacy between Microsoft and Netscape, which didn't really resolve any
> issues about web browsers or HTML.
>
> As the popularity of the WWW increased, HTML was upgraded, and its
> capabilities were expanded. All of this happened within the context of
> HTML being seriously flawed.
>
> It wasn't long before the flaws in HTML began to cause some serious
> problems. As HTML expanded, it became more complex. New tags and
> attributes were added, using the same not too strict model, and of course
> there were even more flawed HTML documents in proliferation on the WWW.
> HTML documents were becoming unweildy, cryptic, and more and more
> difficult to parse correctly. The complexity of the language, and the
> demands of the market brought about the development of various HTML
> editing software, with a GUI for developing HTML, advertised (somewhat
> deceptively) as WYSIWYG.
>
> Of course, even at the time of the first GUIs for developing HTML, WYSIWYG
> was already an impossible goal. New versions of HTML were appearing every
> several years. New browsers were appearing every several years. Existing
> browsers were being upgraded every several years. And finally, because of
> the extant limitations of HTML, combined with market demand for more and
> more functionality, browser manufacturers were adding proprietary markup
> to their browsers, and, by association, more "flavors" of HTML were
> emerging every several years.
>
> The first serious attempt at a rescue, and currently the most popular
> solution, was the advent of CSS (Cascading Style Sheets). CSS enabled
> style-centric and functionality-centric markup to be removed from HTML
> elements themselves, and placed into a separate style ***. This meant
> that a web document had the capability of being as extensible as possible,
> adapting to new enhancements to the language, without revising the HTML
> itself. Only the style *** needed to be changed. This was a very hopeful
> move towards a solution. However, it was not extensible enough, nor did it
> provide the most optimal separation of logic, content, and style. And of
> course, there were and are still legacy HTML documents out there all over
> the place. So, CSS, while providing a bit more sanity to the mix, is still
> a temporary and incomplete fix.
>
> Browser manufacturers have been somewhat slow to catch up, mot notably
> Internet Explorer of late. However, IE's lateness can be accounted for by
> its release cycle, which has been seriously delayed since IE6. IE 7 is
> slated to come out soon, though, and things ought to become more or less
> equal, and still present problems. After all, how much of the WWW is using
> CSS? The only possible answer is, more every day.
>
> Still, CSS is a stop-gap measure, a good one nonetheless, but not the
> best. The best answer has emerged in the form of XML. XML (Extensible
> Markup Language) is just what it sounds like: an infinitely extensible,
> infinitely applicable markup language, which can be used not only for web
> page authoring, but an unlimited host of other purposes, such as data
> storage, other types of document markup, and other forms of web messaging.
> In fact, XML is the backbone of SOAP (Simple Object Access Protocol),
> which enables objects to be accessed across the Internet via HTTP in a
> cross-platform-compatible format.
>
> XML has been going through quite a few changes as well. XSLT is the XML
> equivalent of CSS, and presents the most comprehensive and extensible
> solution for the problems that CSS addresses. One of the greatest
> attractions of XML is its core simplicity. The rules of XML are few. It
> is, however, strict in format, unlike HTML. This will eventually simplify
> the browser development process considerably. No longer will browser
> manufacturers have to make incredibly difficult decisions regarding how to
> handle poorly-formed markup, whether or not to take which of the document
> headers seriously, and what to do in this special case, or that one.
>
> XML allows totally granular control over markup, which means that, as the
> demands for ever-more-sophisticated functionality over the WWW increase,
> XML will be able to handle these demands without any modification of the
> standard. It therefore provides stability, in addition to extensibility.
> It is, to coin a phrase, "the greatest thing since sliced bread."
>
> My theory is that, over the next decade or so, XML will replace HTML on
> the WWW, and the current issues will disappear (only to be replaced by new
> and different issues, of course!). This sort of thing has happened before,
> and will happen again. In the meantime, as always, deal with it.Or, as the
> young lady says, "I say live it or live WITH it!"
>
> --
> HTH,
>
> Kevin Spencer
> Microsoft MVP
> .Net Developer
> Big things are made up of
> lots of little things.
>
>
> "Frankie" <BeansAndTacos@xxxxxxxxxxxx> wrote in message
> news:e7tzByxxFHA.2228@xxxxxxxxxxxxxxxxxxxxxxx
>> Please note that this is NOT a complaint or any sort of rant - but rather
>> a serious inquiry about the long-term expectations we can have of the Web
>> and Internet as a publication medium. I would appreciate your thoughtful
>> feedback on my observations and question (which appears at the end after
>> these observations).
>>
>> The Web as we currently have it is NOT WYSIWYG. I'm specifically
>> referring to pages that get rendered by browsers - whether based on HTML,
>> XHTML, or XML. In fact, "good Web page design" specifically separates
>> styling from content via css (while HTML-specific styling tags like the
>> <FONT> tag have been depracated). This, by definition, preempts even the
>> *possibility* of WYSIWYG Web page designer. What you see in the
>> data/content is ASCII text, more or less. What you get in the browser
>> beyond the data/content is controlled in large part by the associated css
>> and, separately, browser settings (e.g. size of font with which to
>> display everything). Never mind that we don't control the size of the
>> final page (monitors come in a variety of physical domensions and
>> resolutions). Also consider that Dreamweaver - arguably the most powerful
>> Web page development tool CLEARLY states in official documentation that
>> it's not a WYSIWYG editor and that such a thing is really NOT POSSIBLE on
>> the Web (siting differences in browsers and how each renders pages
>> according to its own interpretation of the standards as the primary cause
>> of that fact).
>>
>> This is all okay for us techies who understand all that and have agreed
>> at least with ourselves and each other to live with it. This is the
>> "state of the medium" and I've heard "if you don't like it, then chose
>> another medium." That's not helpful a helpful statement. An organization
>> may simply not be able to use another medium to accomplish its
>> objectives.
>>
>> While the lack of WYSIWYG on the Web is generally not a problem for us
>> techies, it's definitely a problem for OUR non technical customers and
>> those who don't understand the basic principle of "separate data/content
>> from presentation." (i.e., html/xhtml styled with a separate css page, or
>> CSS-P).
>>
>> This lack of understanding of [the separation of styling from data] is
>> precisely why it's nearly impossible for "non technical" people to create
>> attractive Web pages from scratch. It's also why it's nearly impossible
>> for US TECHIES to create a WYSIWYG Web page editor.
>>
>> As Web developers, everything about this separation of appearance from
>> data/content is JUST FINE as long as WE are in the loop. We know what's
>> going on. But think about the implications of that. This means that in
>> order to get a truly professional-looking Web page, a Web developer MUST
>> be involved at some point. No tool (FrontPage, VS.NET, Dreamweaver, etc)
>> can account for ALL of the relevant factors that go into creating a Web
>> page in a truly WYSIWYG way.
>>
>> THE PUNCH LINE HERE - and a significant problem for all of us (techies
>> and non techies alike) is that we, as Web developers, will never be able
>> to create a tool that will enable NON TECHNICAL users to create
>> professional-looking and behaving Web pages *from scratch*. Period. The
>> non techies are expecting WYSIWYG and are simply NOT CAPABLE of
>> understanding anything other than WYSIWYG. It's just not available on the
>> Web. That's simply a SHOW STOPPER for them.
>>
>> To illustrate the "punch line" described above, think about it from the
>> point of view of someone who is NOT a Web developer and doesn't want to
>> become one. He or she could MUDDLE their way through Word or PowerPoint
>> or PhotoShop or PaintShop Pro or Fireworks Excel and more-or-less create
>> a document he or she is happy with (slide show, jpeg graphic, Word
>> document, charts and graphs, etc). At a minimum they will know what it
>> looks like and what it will look like for everybody else. This same thing
>> can't happen on the Web as we currently know it. The same user who
>> muddles through Word or Fireworks or Excel could NEVER muddle their way
>> through ANY HTML editor and get the equivalent result. They could muddle
>> their way through - but the resulting rendered page would typically be
>> disastrous (from a purely technical perspective) and almost certainly NOT
>> result in what the user wants to create - even on one single browser.
>>
>> So - my question:
>> What is the likelihood (and what would it take) of having any true
>> WYSIWYG Web page development capability on the Web - ever?
>>
>> -Frankie
>>
>
>


.