After HTML: GUI-ML?

Discussion in 'HTML' started by Next, Mar 14, 2006.

  1. Next

    Next Guest

    Hi folks,

    Years ago, it occurred to me that a lot of the trouble
    of writing web browsers is caused by the upside-down
    arrangement of things: Javascript code exists inside
    a document, when really it should be the other way around.
    And yet, although this seems fairly obvious to me,
    having tried myself to write a web browser and given up,
    I don't see a lot of movement by major web browser
    projects in a direction that might TRULY fix the problem.
    I do see a few slow-moving projects: HTML5 and Web Applications.

    These are not hobby projects however, and it does seem
    that "industry" always has and always will have a
    preference for messy, bloated applications and poorly
    conceived standards because these things keep people
    buying new computers and justify companies' existences.
    We as consumers and/or hobbyists however should seek
    a better solution, and create it ourselves if necessary!

    I would suggest to fix the original problem. Here is my GUIML idea:
    GUIML would encode essentially the basic features of a
    modern GUI widget system, with enhancements to support
    fancier features like animated sprites that you see in some web pages.
    But basically it would reverse the fundamental problem with browsers,
    namely bad design caused by the code-in-document flaw
    that has led to enormous bloat and which has effectively
    made many perfectly usable computers obsolete,
    because web browsing is a vital app.

    I would welcome any support or criticism of this
    idea but first take a look below at a sample GUIML web design.
    My initial idea is to simply take a familiar GUI like Motif or Java's
    GUI
    and use that as inspiration.

    And, to set things right I would completely remove from HTML
    any ability to run Javascript. HTML itself need not even be
    supported but could be replaced with any number of
    document formats such as RTF or something SGML based.

    Imagine the following webpage:

    <GUIML>
    <head>
    <title> Test </title>
    </head>
    <code>
    <!-- insert here javascript code for initialization, callbacks etc
    -->
    </code>
    <design>
    <MainWindow> <!-- widget that takes a menu, frame, and scrollbar(s)
    -->
    <PulldownMenu location=top preferredPointer="hand">
    <Menu title=About code="javascript_about()">
    </Menu>
    <Menu title=Products>
    <MenuItem code="javascript_callback1()"> First
    </MenuItem>
    </Menu>
    </PulldownMenu>
    <Frame name=main >
    <Table width=100% height=100% rows=1 columns=3>
    <tr>
    <td><PushButton code="js_button_callback()" /> </td>
    <td><Image code="js_img_callback()" /> </td>
    <td><Document url="foo.html" /> </td>
    </tr>
    </Table>
    </Frame>
    <ScrollBar location=right type=vertical callback="js_callback2()" />
    </MainWindow>
    </design>
    </GUIML>

    Comments?
    Next, Mar 14, 2006
    #1
    1. Advertising

  2. Something like this has been prototyped; look up IBM papers from the
    1990's describing the Interactive Transaction System, which was a
    styling-rule-driven user interface management system.
    Joseph Kesselman, Mar 14, 2006
    #2
    1. Advertising

  3. Next

    mbstevens Guest

    Next wrote:
    > Hi folks,
    >
    > Years ago, it occurred to me that a lot of the trouble
    > of writing web browsers is caused by the upside-down
    > arrangement of things: Javascript code exists inside
    > a document, when really it should be the other way around.


    There is, in fact, server side javascript. I don't see it
    very often -- doesn't seem to have caught on. But from what
    you've said this may or may not be what you're really looking
    for.

    > And yet, although this seems fairly obvious to me,
    > having tried myself to write a web browser and given up,
    > I don't see a lot of movement by major web browser
    > projects in a direction that might TRULY fix the problem.
    > I do see a few slow-moving projects: HTML5 and Web Applications.
    >
    > These are not hobby projects however, and it does seem
    > that "industry" always has and always will have a
    > preference for messy, bloated applications and poorly
    > conceived standards because these things keep people
    > buying new computers and justify companies' existences.
    > We as consumers and/or hobbyists however should seek
    > a better solution, and create it ourselves if necessary!



    I can assume, then, that you've left the world of Windows/Mac
    behind and have embraced free operating systems?

    >
    > I would suggest to fix the original problem. Here is my GUIML idea:
    > GUIML would encode essentially the basic features of a
    > modern GUI widget system, with enhancements to support
    > fancier features like animated sprites that you see in some web pages.
    > But basically it would reverse the fundamental problem with browsers,
    > namely bad design caused by the code-in-document flaw
    > that has led to enormous bloat and which has effectively
    > made many perfectly usable computers obsolete,
    > because web browsing is a vital app.


    There is already flash, but it's hard to get standardization on
    something like that if you want to support all kinds of
    clients on all kinds of machines. Right now there are ways to
    use flash and SVG and such in a way that degrades gracefully.


    >
    > I would welcome any support or criticism of this
    > idea but first take a look below at a sample GUIML web design.
    > My initial idea is to simply take a familiar GUI like Motif or Java's
    > GUI
    > and use that as inspiration.
    >
    > And, to set things right I would completely remove from HTML
    > any ability to run Javascript. HTML itself need not even be
    > supported but could be replaced with any number of
    > document formats such as RTF or something SGML based.
    >
    > Imagine the following webpage:
    >
    > <GUIML>
    > <head>
    > <title> Test </title>
    > </head>
    > <code>
    > <!-- insert here javascript code for initialization, callbacks etc
    > -->
    > </code>
    > <design>
    > <MainWindow> <!-- widget that takes a menu, frame, and scrollbar(s)
    > -->
    > <PulldownMenu location=top preferredPointer="hand">
    > <Menu title=About code="javascript_about()">
    > </Menu>
    > <Menu title=Products>
    > <MenuItem code="javascript_callback1()"> First
    > </MenuItem>
    > </Menu>
    > </PulldownMenu>



    > <Frame name=main >

    UGH! Please don't make the new system require frames.


    > <Table width=100% height=100% rows=1 columns=3>
    > <tr>
    > <td><PushButton code="js_button_callback()" /> </td>
    > <td><Image code="js_img_callback()" /> </td>
    > <td><Document url="foo.html" /> </td>
    > </tr>
    > </Table>
    > </Frame>
    > <ScrollBar location=right type=vertical callback="js_callback2()" />
    > </MainWindow>
    > </design>
    > </GUIML>
    >
    > Comments?
    >
    >
    mbstevens, Mar 14, 2006
    #3
  4. Next

    Jim Higson Guest

    Next wrote:

    > Hi folks,
    >
    > Years ago, it occurred to me that a lot of the trouble
    > of writing web browsers is caused by the upside-down
    > arrangement of things: Javascript code exists inside
    > a document, when really it should be the other way around.


    How so? You seem to be saying the content should be contained in the
    logic...?

    > And yet, although this seems fairly obvious to me,
    > having tried myself to write a web browser and given up,
    > I don't see a lot of movement by major web browser
    > projects in a direction that might TRULY fix the problem.
    > I do see a few slow-moving projects: HTML5 and Web Applications.
    >
    > These are not hobby projects however, and it does seem
    > that "industry" always has and always will have a
    > preference for messy, bloated applications and poorly
    > conceived standards because these things keep people
    > buying new computers and justify companies' existences.
    > We as consumers and/or hobbyists however should seek
    > a better solution, and create it ourselves if necessary!
    >
    > I would suggest to fix the original problem. Here is my GUIML idea:
    > GUIML would encode essentially the basic features of a
    > modern GUI widget system, with enhancements to support
    > fancier features like animated sprites that you see in some web pages.
    > But basically it would reverse the fundamental problem with browsers,
    > namely bad design caused by the code-in-document flaw
    > that has led to enormous bloat and which has effectively
    > made many perfectly usable computers obsolete,
    > because web browsing is a vital app.


    I don't think web browsing requires a very modern PC. A friend of mine still
    uses a 800MHz machine from about six years ago with no problems, and I have
    a 233Mhz machine that runs Firefox pretty well for most sites. There are
    computers older than that still working out there, but not very many, and
    there are lightweight browsers such as Dillo (http://www.dillo.org) that
    run fine on them.

    Despite what Intel tell us, web browsing is one of the things a modern PC
    doesn't do much better than an older one.

    > I would welcome any support or criticism of this
    > idea but first take a look below at a sample GUIML web design.
    > My initial idea is to simply take a familiar GUI like Motif or Java's
    > GUI
    > and use that as inspiration.
    >
    > And, to set things right I would completely remove from HTML
    > any ability to run Javascript. HTML itself need not even be
    > supported but could be replaced with any number of
    > document formats such as RTF or something SGML based.


    I don't think RTF will be popular for the web because it is difficult to
    read and generate the code using scripting/templating languages. Besides,
    it is set up for display on the printed page.

    If you want to make older machines viable, at least base it on XML rather
    than old SGML. XML is much simpler (and therefore faster) for the computer
    to parse.

    > Imagine the following webpage:
    >
    > <GUIML>
    > <head>
    > <title> Test </title>
    > </head>
    > <code>
    > <!-- insert here javascript code for initialization, callbacks etc
    > -->
    > </code>
    > <design>
    > <MainWindow> <!-- widget that takes a menu, frame, and scrollbar(s)
    > -->
    > <PulldownMenu location=top preferredPointer="hand">
    > <Menu title=About code="javascript_about()">
    > </Menu>
    > <Menu title=Products>
    > <MenuItem code="javascript_callback1()"> First
    > </MenuItem>
    > </Menu>
    > </PulldownMenu>
    > <Frame name=main >
    > <Table width=100% height=100% rows=1 columns=3>
    > <tr>
    > <td><PushButton code="js_button_callback()" /> </td>
    > <td><Image code="js_img_callback()" /> </td>
    > <td><Document url="foo.html" /> </td>
    > </tr>
    > </Table>


    Using a table like this suggests you don't really understand the aims of the
    standards you wish to replace.

    > </Frame>
    > <ScrollBar location=right type=vertical callback="js_callback2()" />
    > </MainWindow>
    > </design>
    > </GUIML>
    >
    > Comments?
    >
    Jim Higson, Mar 14, 2006
    #4
  5. Next

    VK Guest

    Next wrote:
    > Hi folks,
    >
    > Years ago, it occurred to me that a lot of the trouble
    > of writing web browsers is caused by the upside-down
    > arrangement of things: Javascript code exists inside
    > a document, when really it should be the other way around.


    You missed the train :) This way exists for many years already and
    it's called "behaviors". Unfortunately for all these years the only
    browser supporting it was IE. But now Firefox got the idea right. OK,
    they called it "bindings" and transformed a simple structure into XML
    mess - but it is all forgiven for the break through itself :)

    See my post (author "VK") at
    <http://groups.google.com/group/comp.infosystems.www.authoring.stylesheets/browse_frm/thread/10e3360c3458471e>
    VK, Mar 14, 2006
    #5
  6. Next

    Toby Inkster Guest

    Next wrote:

    > GUIML would encode essentially the basic features of a
    > modern GUI widget system


    Google: XUL.
    Google: XAML.

    --
    Toby A Inkster BSc (Hons) ARCS
    Contact Me ~ http://tobyinkster.co.uk/contact
    Toby Inkster, Mar 14, 2006
    #6
  7. Next wrote in
    :

    > Years ago, it occurred to me that a lot of the trouble
    > of writing web browsers is caused by the upside-down
    > arrangement of things: Javascript code exists inside
    > a document, when really it should be the other way around.
    > And yet, although this seems fairly obvious to me,
    > having tried myself to write a web browser and given up,
    > I don't see a lot of movement by major web browser
    > projects in a direction that might TRULY fix the problem.
    > I do see a few slow-moving projects: HTML5 and Web Applications.


    I think the bigger issue with HTML and browser design is that it only
    supplies *hints* and *suggestions* as to the formatting, rather than making
    all browsers display a page with identical formatting, as PDF does. It would
    be so much easier as the designer of a site if you could be confident that
    everyone would see the same view of the page without the line breaks and
    table column widths being variable under user control. Let users have a zoom
    control (as for Acrobat Reader) it they need larger print but don't let them
    change the font size independent of all other objects on the page; let the
    site author retain full control over all other aspects of formatting,
    typography etc.

    This could easily develop into a debate about the philosophy of browers and
    the web. I wonder if Tim Berners-Lee and the people that devised HTML would
    still have designed it that way that it is in the light of people who are
    itching to use it as a tightly-controlled page-format tool.
    Martin Underwood, Mar 14, 2006
    #7
  8. Next

    Jose Guest

    > It would
    > be so much easier as the designer of a site if you could be confident that
    > everyone would see the same view of the page without the line breaks and
    > table column widths being variable under user control.


    No it wouldn't - don't be ridiculous. I don't give a hoot or a damn
    what the web designer thinks I ought to see. The web designer in most
    cases is a moron. I came to see the content, and I want to see it -my-
    way. The web designer isn't going to buy me a new computer or monitor
    to display their wonderous work of art (a luxury dead tree designers do
    have), and they are mistaken if they believe that the only thing I am
    interested in is their TV show. I am doing things. Often I am doing
    things with their site and another program.

    It's my goddamn computer!

    Hmmph!

    > but don't let them
    > change the font size independent of all other objects on the page


    So if I want to be able to read the text, the picture has to balloon
    too? And if I want to shrink the window so I can see my spreadsheet,
    the pictures have to become postage stamps??

    > let the
    > site author retain full control over all other aspects of formatting,
    > typography etc.


    If you actually want me to =read= your content, let =me= choose the
    formatting and typography. Let me turn off all the inane flashing
    animations that steal my attention. Let me navigate back and forth at
    will, my way.

    Do you ever browse the web as a =user=??

    Jose
    --
    Money: what you need when you run out of brains.
    for Email, make the obvious change in the address.
    Jose, Mar 15, 2006
    #8
  9. Martin Underwood wrote:

    > Next wrote in
    > :
    >
    >> Years ago, it occurred to me that a lot of the trouble
    >> of writing web browsers is caused by the upside-down
    >> arrangement of things: Javascript code exists inside
    >> a document, when really it should be the other way around.
    >> And yet, although this seems fairly obvious to me,
    >> having tried myself to write a web browser and given up,
    >> I don't see a lot of movement by major web browser
    >> projects in a direction that might TRULY fix the problem.
    >> I do see a few slow-moving projects: HTML5 and Web Applications.

    >
    > I think the bigger issue with HTML and browser design is that it only
    > supplies *hints* and *suggestions* as to the formatting, rather than
    > making all browsers display a page with identical formatting, as PDF does.
    > It would be so much easier as the designer of a site if you could be
    > confident that everyone would see the same view of the page without the
    > line breaks and table column widths being variable under user control. Let
    > users have a zoom control (as for Acrobat Reader) it they need larger
    > print but don't let them change the font size independent of all other
    > objects on the page; let the site author retain full control over all
    > other aspects of formatting, typography etc.


    I was thinking about developing a new hardware device allowing a user to
    plug into a free USB port, and having the information appear within the
    users neurons. Then, I don't care what screen size they have, i don't even
    care if they can see. My page is plunked right inside their brain, and
    they get all of the content just the way I want them to.

    Yet another layer of sarcasm... ;)

    Carolyn
    --
    Carolyn Marenger
    Carolyn Marenger, Mar 15, 2006
    #9
  10. Next

    Toby Inkster Guest

    Martin Underwood wrote:

    > I think the bigger issue with HTML and browser design is that it only
    > supplies *hints* and *suggestions* as to the formatting, rather than making
    > all browsers display a page with identical formatting, as PDF does.


    If you want PDF, then *use* PDF.

    > I wonder if Tim Berners-Lee and the people that devised HTML would
    > still have designed it that way that it is in the light of people who are
    > itching to use it as a tightly-controlled page-format tool.


    Yep, I think they would have.

    --
    Toby A Inkster BSc (Hons) ARCS
    Contact Me ~ http://tobyinkster.co.uk/contact
    Toby Inkster, Mar 15, 2006
    #10
  11. Next wrote:

    > Years ago, it occurred to me that a lot of the trouble
    > of writing web browsers is caused by the upside-down
    > arrangement of things: Javascript code exists inside
    > a document, when really it should be the other way around.
    > And yet, although this seems fairly obvious to me,
    > having tried myself to write a web browser and given up,
    > I don't see a lot of movement by major web browser
    > projects in a direction that might TRULY fix the problem.
    > I do see a few slow-moving projects: HTML5 and Web Applications.
    >
    > These are not hobby projects however, and it does seem
    > that "industry" always has and always will have a
    > preference for messy, bloated applications and poorly
    > conceived standards because these things keep people
    > buying new computers and justify companies' existences.
    > We as consumers and/or hobbyists however should seek
    > a better solution, and create it ourselves if necessary!
    >
    > I would suggest to fix the original problem. Here is my GUIML idea:
    > GUIML would encode essentially the basic features of a
    > modern GUI widget system, with enhancements to support
    > fancier features like animated sprites that you see in some web pages.
    > But basically it would reverse the fundamental problem with browsers,
    > namely bad design caused by the code-in-document flaw
    > that has led to enormous bloat and which has effectively
    > made many perfectly usable computers obsolete,
    > because web browsing is a vital app.
    >
    > I would welcome any support or criticism of this
    > idea but first take a look below at a sample GUIML web design.
    > My initial idea is to simply take a familiar GUI like Motif or Java's
    > GUI
    > and use that as inspiration.
    >
    > And, to set things right I would completely remove from HTML
    > any ability to run Javascript. HTML itself need not even be
    > supported but could be replaced with any number of
    > document formats such as RTF or something SGML based.


    So you know XUL, the GUI framework of the Mozilla project?
    http://www.mozilla.org/projects/xul/

    Of course limited to Mozilla browsers...


    --
    Benjamin Niemann
    Email: pink at odahoda dot de
    WWW: http://www.odahoda.de/
    Benjamin Niemann, Mar 15, 2006
    #11
  12. Next

    Simon Brooke Guest

    in message <5n.co.uk>, Toby Inkster
    ('') wrote:

    > Martin Underwood wrote:
    >
    >> I think the bigger issue with HTML and browser design is that it only
    >> supplies *hints* and *suggestions* as to the formatting, rather than
    >> making all browsers display a page with identical formatting, as PDF
    >> does.

    >
    > If you want PDF, then *use* PDF.


    /No-one/ wants PDF. /Ever/. There is never any good reason for using it.

    >> I wonder if Tim Berners-Lee and the people that devised HTML would
    >> still have designed it that way that it is in the light of people who
    >> are itching to use it as a tightly-controlled page-format tool.

    >
    > Yep, I think they would have.


    Tightly controlled page format has no place on a world wide web where the
    range of display devices - and the range of visual acuity of users - is
    unconstrained and unlimited. If you want tightly controlled page format,
    print it on vellum and send it by pony express or pigeon.

    --
    (Simon Brooke) http://www.jasmine.org.uk/~simon/

    I shall continue to be an impossible person so long as those
    who are now possible remain possible -- Michael Bakunin
    Simon Brooke, Mar 15, 2006
    #12
  13. Next

    :::Jerry:::: Guest

    [ Xposting restored ]

    "Simon Brooke" <> wrote in message
    news:...
    <snip>
    >
    > /No-one/ wants PDF. /Ever/. There is never any good reason for

    using it.


    Who the freck are you to tell *me* how I want to receive *my*
    documents, *don't* tell me how I should use the web...
    :::Jerry::::, Mar 15, 2006
    #13
  14. Next wrote:
    > Hi folks,
    >
    > Years ago, it occurred to me that a lot of the trouble
    > of writing web browsers is caused by the upside-down
    > arrangement of things: Javascript code exists inside
    > a document, when really it should be the other way around.


    The fundamental purpose of the World Wide Web is to transmit documents,
    not programs, and HTML was a format designed for representing documents.
    HTML does have a facility for embedding script that allows it to be
    used for limited distribution of applications. There are better and/or
    more powerful or flexible ways to do that--web services, Java applets,
    or AJAX, for example. That doesn't mean there's anything wrong with HTML.
    Harlan Messinger, Mar 15, 2006
    #14
  15. Martin Underwood wrote:
    > Next wrote in
    > :
    >
    >
    >>Years ago, it occurred to me that a lot of the trouble
    >>of writing web browsers is caused by the upside-down
    >>arrangement of things: Javascript code exists inside
    >>a document, when really it should be the other way around.
    >>And yet, although this seems fairly obvious to me,
    >>having tried myself to write a web browser and given up,
    >>I don't see a lot of movement by major web browser
    >>projects in a direction that might TRULY fix the problem.
    >>I do see a few slow-moving projects: HTML5 and Web Applications.

    >
    > I think the bigger issue with HTML and browser design is that it only
    > supplies *hints* and *suggestions* as to the formatting, rather than making
    > all browsers display a page with identical formatting, as PDF does. It would
    > be so much easier as the designer of a site if you could be confident that
    > everyone would see the same view of the page without the line breaks and
    > table column widths being variable under user control.


    HTML is simply not meant to be a page layout language. It's a document
    markup language, and presentation is meant to be secondary. There's
    normally no reason why a document needs to be displayed in a single
    fixed format, and if you try, you make life difficult or impossible for
    a large percentage of your audience.

    > Let users have a zoom
    > control (as for Acrobat Reader) it they need larger print but don't let them
    > change the font size independent of all other objects on the page; let the
    > site author retain full control over all other aspects of formatting,
    > typography etc.


    Then provide PDFs and forget about HTML. If you want to use screws
    instead of nails, then use a screwdriver rather than calling the hammer
    deficient. Doesn't that make sense?
    Harlan Messinger, Mar 15, 2006
    #15
  16. Harlan Messinger wrote in message
    :

    > Martin Underwood wrote:
    >> Next wrote in
    >> :
    >>
    >> I think the bigger issue with HTML and browser design is that it only
    >> supplies *hints* and *suggestions* as to the formatting, rather than
    >> making all browsers display a page with identical formatting, as PDF
    >> does. It would be so much easier as the designer of a site if you
    >> could be confident that everyone would see the same view of the page
    >> without the line breaks and table column widths being variable under
    >> user control.

    >
    > HTML is simply not meant to be a page layout language. It's a document
    > markup language, and presentation is meant to be secondary. There's
    > normally no reason why a document needs to be displayed in a single
    > fixed format, and if you try, you make life difficult or impossible
    > for a large percentage of your audience.


    Therein lies the problem: expecting web sites to be read on a very wide
    variety of browers and devices, rather than saying that for a browser to be
    a browser it has to conform to a very tightly-controlled standard. I know
    HTML isn't meant to be a page layout language - my question is "why isn't
    it?".

    If I send a Word document, I don't expect people to be able, at a stroke, to
    alter the sizes of all my fonts - apart from zooming in and out of the whole
    page - thus destroying my carefully-crafted page layout. I wish browsers had
    been designed with page layout given as much thought as content.
    Martin Underwood, Mar 15, 2006
    #16
  17. Jose wrote in message
    P0JRf.621$:

    >> It would
    >> be so much easier as the designer of a site if you could be
    >> confident that everyone would see the same view of the page without
    >> the line breaks and table column widths being variable under user
    >> control.

    >
    > No it wouldn't - don't be ridiculous.


    I wasn't aware that I was being ridiculous. I was asking a question in all
    innocence. From the replies, I see that I'm very much in the minority - well
    what a surprise: what's new ;-)

    > So if I want to be able to read the text, the picture has to balloon
    > too? And if I want to shrink the window so I can see my spreadsheet,
    > the pictures have to become postage stamps??
    >
    >> let the
    >> site author retain full control over all other aspects of formatting,
    >> typography etc.

    >
    > If you actually want me to =read= your content, let =me= choose the
    > formatting and typography. Let me turn off all the inane flashing
    > animations that steal my attention. Let me navigate back and forth at
    > will, my way.


    I agree that a lot of the flashing animations that people think are "cool"
    are a pain in the arse. I'm talking about simple text/page layout.

    > Do you ever browse the web as a =user=??


    Yes. It pisses me off that for some sites, as I move the margins of my
    window, the columns of tables grow/shrink and lines of text in a table or
    paragraphs of text surrounding photographs change their wrapping.
    Martin Underwood, Mar 15, 2006
    #17
  18. Martin Underwood wrote:
    > HTML isn't meant to be a page layout language - my question is "why isn't
    > it?".


    Because that isn't what it was designed to be.

    The original assumption was that styling/rendering would be handled by
    the browser, and you'd pick/configure a browser to suit your own
    preferred formatting styles.

    Unfortunately, people who didn't understand this concept began abusing
    the HTML to try to control rendering. And some of the browser authors
    exacerbated that by adding styling features to their pre-standardization
    dialects of HTML... and then, when HTML *was* standardized, the
    standards committee was unwilling/unable to break those establieshed
    (bad) practices.

    The right answer is to write pure syntactic markup in HTML -- and then,
    if you really care about how it renders, to provide a stylesheet that
    implements those preferences. That leaves the reader room to reject the
    stylesheet and use their browser's default rendering, or plug in a
    different stylesheet. Part of the reason for the move to XHTML is to
    allow XSLT (a more powerful stylesheet language than CSS) to render it
    into XSL-FO (a more powerful page-layout language than annotated HTML).

    > If I send a Word document, I don't expect people to be able, at a stroke, to
    > alter the sizes of all my fonts - apart from zooming in and out of the whole
    > page - thus destroying my carefully-crafted page layout.


    That kind of style-crafting really isn't what HTML is designed for. You
    can't defend an argument that it should have been; don't try. If you
    want to publish something in absolutely-locked-in form, render it
    yourself into something like PDF before publishing it -- but then don't
    complain when your users scream that it doesn't work well on odd-sized
    windows or paper.

    If you want to redefine "browser" you are copying *exteremly* the wrong
    newsgroups. Drop all the HTML discussions from the list. You may or may
    not want to drop XML from the list too, unless the new language you're
    inventing (and it *is* a new language, not HTML) will be based on XML.

    Or consider just authoring XSL-FO directly.

    --
    Joe Kesselman / Beware the fury of a patient man. -- John Dryden
    Joseph Kesselman, Mar 15, 2006
    #18
  19. Next

    Paul Herber Guest

    On Wed, 15 Mar 2006 16:48:10 -0000, "Martin Underwood" <a@b> wrote:

    >Harlan Messinger wrote in message
    >:
    >
    >> Martin Underwood wrote:
    >>> Next wrote in
    >>> :
    >>>
    >>> I think the bigger issue with HTML and browser design is that it only
    >>> supplies *hints* and *suggestions* as to the formatting, rather than
    >>> making all browsers display a page with identical formatting, as PDF
    >>> does. It would be so much easier as the designer of a site if you
    >>> could be confident that everyone would see the same view of the page
    >>> without the line breaks and table column widths being variable under
    >>> user control.

    >>
    >> HTML is simply not meant to be a page layout language. It's a document
    >> markup language, and presentation is meant to be secondary. There's
    >> normally no reason why a document needs to be displayed in a single
    >> fixed format, and if you try, you make life difficult or impossible
    >> for a large percentage of your audience.

    >
    >Therein lies the problem: expecting web sites to be read on a very wide
    >variety of browers and devices, rather than saying that for a browser to be
    >a browser it has to conform to a very tightly-controlled standard. I know
    >HTML isn't meant to be a page layout language - my question is "why isn't
    >it?".
    >
    >If I send a Word document, I don't expect people to be able, at a stroke, to
    >alter the sizes of all my fonts - apart from zooming in and out of the whole
    >page - thus destroying my carefully-crafted page layout. I wish browsers had
    >been designed with page layout given as much thought as content.
    >


    Your carefully-crafted page layout in Word can be destroyed quite
    easily without any assistance from the recipient by:
    a. different sized paper in the printer settings
    b. different printer margins
    c. non-available fonts
    d. missing images and embedded objects

    --
    Regards, Paul Herber, Sandrila Ltd. http://www.pherber.com/
    Electronics for Visio http://www.electronics.sandrila.co.uk/
    Paul Herber, Mar 15, 2006
    #19
  20. Martin Underwood wrote:
    >
    > Therein lies the problem: expecting web sites to be read on a very wide
    > variety of browers and devices, rather than saying that for a browser to be
    > a browser it has to conform to a very tightly-controlled standard.


    Why should information be made less useful and less accessible? Why, for
    example, should you want so badly to force people to sit at full screens
    at their desks in order to get information, preventing them from
    accessing it comfortably via their handhelds? Why should you waste your
    time laying out an entire web site for a presumed screen resolution that
    three years from now may be laughable, that may take up all of three
    inches on a 17-inch monitor and be illegible? Why should I specially
    have to turn zoom on to read your pages?

    > I know
    > HTML isn't meant to be a page layout language - my question is "why isn't
    > it?".


    That's like asking why the Unicode standard for encoding the elements of
    writing systems isn't meant to be a standard for spelling. It is what it
    is and it isn't something else, and the reason it was developed as it
    was is because there was a need for such a thing. If someone has
    information to convey, most of the time there is no reason for the
    person to be concerned with how that information *looks* to the person
    reading it.

    > If I send a Word document, I don't expect people to be able, at a stroke, to
    > alter the sizes of all my fonts - apart from zooming in and out of the whole
    > page - thus destroying my carefully-crafted page layout.


    That's because word processing exists to prepare documents for printing
    on paper. The Web does not exist for that purpose. Word processing is
    the product of a time before the vast majority of people had computers,
    had network access, had e-mail. *Now* you can send word processing
    documents via the Internet or post them on a local network, but that's
    incidental.

    To illustrate further the really low importance of formatting in the
    general scheme of things when information is transmitted through the
    Internet, consider that even now that almost everyone *has* a word
    processing application, most individuals send information through
    *e-mail*. Usually plain-text e-mail. At most emphasis is shown, maybe by
    surrounding a word or phrase in *asterisks*, and even then it's of no
    concern to me how that looks on the other end (for example, most people
    will see the asterisks; some clients might display the word boldface as
    well--which is a user-configurable option!--but most won't). Page design
    is the last thing on my mind when I send a note, a recipe, an invitation
    to a friend.

    Page layout has its (important) functions, but there's nothing
    surprising about the existence of an elementary method of encapsulating
    information without layout being a consideration.

    > I wish browsers had
    > been designed with page layout given as much thought as content.
    Harlan Messinger, Mar 15, 2006
    #20
    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. paul.foreman

    GUI - GUI value passing

    paul.foreman, Oct 22, 2004, in forum: Java
    Replies:
    5
    Views:
    734
    Michael Rauscher
    Oct 25, 2004
  2. ulysses
    Replies:
    4
    Views:
    752
    Werner Schiendl
    Oct 22, 2003
  3. Andrew Lapidas

    PyGTK GUI update without signals from GUI

    Andrew Lapidas, Apr 13, 2008, in forum: Python
    Replies:
    0
    Views:
    403
    Andrew Lapidas
    Apr 13, 2008
  4. Stefan Ram
    Replies:
    3
    Views:
    478
    Arne Vajhøj
    Nov 20, 2011
  5. Hal Fulton

    GUI and non-GUI data

    Hal Fulton, Aug 5, 2004, in forum: Ruby
    Replies:
    1
    Views:
    131
    Austin Ziegler
    Aug 5, 2004
Loading...

Share This Page