OT: Toward WYSIWYG Web Page Authoring

Discussion in 'ASP .Net' started by Frankie, Oct 2, 2005.

  1. Frankie

    Frankie Guest

    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
     
    Frankie, Oct 2, 2005
    #1
    1. Advertising

  2. Frankie

    Mr Newbie Guest

    Re: Toward WYSIWYG Web Page Authoring

    Great question Frankie.

    I think it begs the question, what exactly IS WYSIWYG ?, in your world of
    definition is seems to mean that you want a system where developer whether
    professional or layman can use a tool and irrespective of what the final
    output medium is can produce something which will render on-screen as
    identical to the final output.

    This could only be possible if the output device monitors printers etc could
    all be 'Rendered As 'Equal' by some unique measure. Some kind of fraternal
    IWysiwygDisplay interface so to speak.

    But do we really need this, or is a close approximation near enough for most
    people? Folks generally expect some minor differences in colour depth,
    spacing etc between browsers, and as long as it does not look outlandishly
    different, then people are usually reasonably happy.

    Thinks are getting better as we move forward; pages generally look quite
    similar between the later browsers with a few discrepancies here and there.
    It's a bit of a pain still to have to test between browsers, as a general
    watchword, produce code which has the greatest conforming reach by rendering
    to the lowest common denominator of the browser classes your application
    supports. Trade-offs are always there to be had unfortunately in a world
    where competitive edge forces features which are not unique to make your
    product more ubiquitous or saleable.

    That's my two euros anyway!


    -----------------------------

    "Frankie" <> wrote in message
    news:...
    > 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
    >
     
    Mr Newbie, Oct 2, 2005
    #2
    1. Advertising

  3. Re: Toward WYSIWYG Web Page Authoring

    > 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 sheet. 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 sheet 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" <> wrote in message
    news:...
    > 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
    >
     
    Kevin Spencer, Oct 2, 2005
    #3
  4. Frankie

    Frankie Guest

    Re: Toward WYSIWYG Web Page Authoring

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

    -F


    "Kevin Spencer" <> wrote in message
    news:...
    >> 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 sheet. 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 sheet 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" <> wrote in message
    > news:...
    >> 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
    >>

    >
    >
     
    Frankie, Oct 2, 2005
    #4
  5. Frankie

    Mr Newbie Guest

    Re: Toward WYSIWYG Web Page Authoring

    OP's name mentally stored for future reference :-|





    "Frankie" <> wrote in message
    news:...
    > Thanks Kevin for taking the time. Your response was, as usual, very
    > helpful and insightful.
    >
    > -F
    >
    >
    > "Kevin Spencer" <> wrote in message
    > news:...
    >>> 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 sheet. 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 sheet 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" <> wrote in message
    >> news:...
    >>> 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
    >>>

    >>
    >>

    >
    >
     
    Mr Newbie, Oct 2, 2005
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    340
  2. Replies:
    1
    Views:
    324
    Mats Lycken
    Mar 9, 2006
  3. Mark Tarver
    Replies:
    2
    Views:
    423
    Travis Newbury
    Mar 26, 2008
  4. Vince C.
    Replies:
    2
    Views:
    109
    Vince C.
    Sep 5, 2003
  5. Narushima Hironori
    Replies:
    0
    Views:
    87
    Narushima Hironori
    Nov 11, 2003
Loading...

Share This Page