why is there no INCLUDE function in html?

Discussion in 'HTML' started by Greg N., Dec 27, 2005.

  1. Greg N.

    Greg N. Guest

    This is _not_ the thousandth repetion of the question "how do I include
    a piece of HTML in another". I have seen these discussions, and I
    understand the answer: There are only server-side solutions to this
    problem.

    However, a large percentage of the world's web content is stored on
    servers whose administrators, for valid reasons, do not offer their
    users any server-side programming facility, however simple. So when I
    look at the problem, it seems real. It apperars there is a much needed
    function sorely missing in HTML.

    It is obvious that most pages cannot be rendered from a single piece of
    server data, hence there are many elements that allow a page being put
    together from various sources from different servers: There is
    <FRAMESET>, <FRAME>, <IFRAME>, <IMG>, <APPLET>, <OBJECT>, <STYLE>,
    <SCRIPT>... (did I get them all?), all of which can serve the purpose
    of letting the UA (more or less) integrate data from multiple sources
    and render them as a single entity.

    I believe the people who develop the HTML standard have discussed the
    necessity and feasibility of client-side HTML fragment inclusion. And
    they have obviously decided we don't need it.

    Why?

    --
    Gregor's Motorradreisen:
    http://hothaus.de/greg-tour/
    Greg N., Dec 27, 2005
    #1
    1. Advertising

  2. Greg N.

    Jan Faerber Guest

    Greg N. ... output:

    > This is _not_ the thousandth repetion of the question "how do I include
    > a piece of HTML in another". I have seen these discussions, and I
    > understand the answer: There are only server-side solutions to this
    > problem.
    >
    > However, a large percentage of the world's web content is stored on
    > servers whose administrators, for valid reasons, do not offer their
    > users any server-side programming facility, however simple. So when I
    > look at the problem, it seems real. It apperars there is a much needed
    > function sorely missing in HTML.
    >
    > It is obvious that most pages cannot be rendered from a single piece of
    > server data, hence there are many elements that allow a page being put
    > together from various sources from different servers: There is
    > <FRAMESET>, <FRAME>, <IFRAME>, <IMG>, <APPLET>, <OBJECT>, <STYLE>,
    > <SCRIPT>... (did I get them all?), all of which can serve the purpose
    > of letting the UA (more or less) integrate data from multiple sources
    > and render them as a single entity.
    >
    > I believe the people who develop the HTML standard have discussed the
    > necessity and feasibility of client-side HTML fragment inclusion. And
    > they have obviously decided we don't need it.
    >
    > Why?
    >


    I don't understand the purpose of this posting.


    --
    Jan

    http://www.h-tut.at
    Jan Faerber, Dec 27, 2005
    #2
    1. Advertising

  3. Greg N.

    Greg N. Guest

    Jan Faerber wrote:

    > I don't understand the purpose of this posting.


    People are being asked for an opinion. If you have none, there is no
    need for you to answer.

    --
    Gregor's Motorradreisen:
    http://hothaus.de/greg-tour/
    Greg N., Dec 27, 2005
    #3
  4. Greg N. wrote:
    > This is _not_ the thousandth repetion of the question "how do I include
    > a piece of HTML in another". I have seen these discussions, and I
    > understand the answer: There are only server-side solutions to this
    > problem.

    [snipped]
    >
    > I believe the people who develop the HTML standard have discussed the
    > necessity and feasibility of client-side HTML fragment inclusion. And
    > they have obviously decided we don't need it.
    >
    > Why?


    Why not ask these people ?

    <http://www.w3.org/>

    Richard.
    Richard Brooks, Dec 27, 2005
    #4
  5. Richard Brooks <> wrote:

    > Why not ask these people ?
    >
    > <http://www.w3.org/>


    Because they won't answer. Or they'll just pick up a boilerplate answer at
    random among the umpteen answers already given.

    Here's a new (?) one: HTML _has_ an INCLUDE function: entity declarations and
    entity references. It's a standard part of SGML, upon which HTML was
    (nominally) based. Browsers just didn't bother implementing it.

    XHTML gives it a new start, in a sense, since entities are part of XML too.
    Too bad IE hasn't implemented XHTML, and doesn't seem to have much intentions
    to do so.

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
    Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
    Jukka K. Korpela, Dec 27, 2005
    #5
  6. Greg N.

    Greg N. Guest

    Jukka K. Korpela wrote:

    >>Why not ask these people ?
    >><http://www.w3.org/>

    >
    > Because they ... just pick up a boilerplate answer at
    > random among the umpteen answers already given.


    Where can I find a summary of these answers?

    --
    Gregor's Motorradreisen:
    http://hothaus.de/greg-tour/
    Greg N., Dec 27, 2005
    #6
  7. Greg N.

    Spartanicus Guest

    "Greg N." <> wrote:

    >I believe the people who develop the HTML standard have discussed the
    >necessity and feasibility of client-side HTML fragment inclusion. And
    >they have obviously decided we don't need it.
    >
    >Why?


    Some things cannot be added to HTML without fundamentally breaking every
    single UA in existence. "Client side inclusion" of code fragments is
    such a feature. Thus addition of such a feature can only be considered
    for a version of the language that is not backward compatible by design.
    IIRC the current XHTML2 proposals offer a "client side inclusion"
    feature, XHTML2 as it stands is not backward compatible.

    Compare that with for example the hypothetical addition of a <poetry>
    element to the language. Although it would also not be backward
    compatible, existing UAs would ignore the element as per the language
    requirements and render the contents.

    --
    Spartanicus
    Spartanicus, Dec 27, 2005
    #7
  8. Greg N.

    Greg N. Guest

    Spartanicus wrote:

    > Some things cannot be added to HTML without fundamentally breaking every
    > single UA in existence.


    I don't buy that for two reasons:

    1. It's like each and every new element that was ever introduced in HTML
    history. It would not break any UA in existence, it would only
    (possibly) break pages that use it.

    2. It could be implemented in a way that does not hurt old UAs, similar
    to frame/noframe, script/noscript etc:

    <include src...>
    <noinclude>
    render this stuff here if include is not supported
    </noinclude>

    --
    Gregor's Motorradreisen:
    http://hothaus.de/greg-tour/
    Greg N., Dec 28, 2005
    #8
  9. Greg N.

    Spartanicus Guest

    "Greg N." <> wrote:

    >> Some things cannot be added to HTML without fundamentally breaking every
    >> single UA in existence.

    >
    >I don't buy that for two reasons:
    >
    >1. It's like each and every new element that was ever introduced in HTML
    >history.


    I illustrated why not. But since you decided to snip that I assume that
    you don't want to know.

    >It would not break any UA in existence, it would only
    >(possibly) break pages that use it.


    It would result in existing UAs being incapable of dealing with sites
    that use such a feature.

    >2. It could be implemented in a way that does not hurt old UAs, similar
    >to frame/noframe, script/noscript etc:
    >
    ><include src...>
    ><noinclude>
    >render this stuff here if include is not supported
    ></noinclude>


    That wouldn't work. If the content of <noinclude> were the same as what
    is in the external resource then it would defeat the point of the
    <include> element. If it were to be a link to the external resource, for
    example a SE bot would index the resource. If, as it should be, the to
    be included resource is served as text/plain (since it's not an HTML
    document), SE's would link to orphaned code fragments that wouldn't be
    scanned for HTML constructs like links.

    Fundamentally broken, and thus unacceptable.

    --
    Spartanicus
    Spartanicus, Dec 28, 2005
    #9
  10. Greg N.

    Greg N. Guest

    Spartanicus wrote:

    >>1. It's like each and every new element that was ever introduced in HTML
    >>history.

    >
    > I illustrated why not. But since you decided to snip that I assume that
    > you don't want to know.


    Ok, then I did not understand. I think it's just like, say, the
    <object> element. If the UA does not understand it, the corresponding
    info will be missing in the rendered page. Where is the difference?
    Please explain.

    >>It would not break any UA in existence, it would only
    >>(possibly) break pages that use it.

    >
    > It would result in existing UAs being incapable of dealing with sites
    > that use such a feature.


    Yes, it would result in an incomplete page being rendered. This has
    happened many times when new HTML elements were introduced.

    >>2. It could be implemented in a way that does not hurt old UAs, similar
    >>to frame/noframe, script/noscript etc:
    >>
    >><include src...>
    >><noinclude>
    >>render this stuff here if include is not supported
    >></noinclude>


    > That wouldn't work. If the content of <noinclude> were the same as what
    > is in the external resource then it would defeat the point of the
    > <include> element.


    Well, of course you'd have to use such a feature intelligently during
    the introduction time, when not all UAs support it yet. You could do
    things like that:

    <include src=my-whiz-bang-navigation-menu.html>
    <noinclude>
    a simple, rudimentary navigation section
    </noinclude>

    or this:

    <include src=current-number-of-cars-in-tukkatukkaland.html>
    <noinclude>
    Last time we counted, there were 123456 cars in tukkatukka land.
    </noinclude>

    > If it were to be a link to the external resource, for
    > example a SE bot would index the resource. If, as it should be, the to
    > be included resource is served as text/plain (since it's not an HTML
    > document), SE's would link to orphaned code fragments that wouldn't be
    > scanned for HTML constructs like links.
    >
    > Fundamentally broken, and thus unacceptable.


    You did not convonvince me that UAs would be "fundamentally broken", now
    you're telling me, SE bots will be fundamentally broken.

    Sure SE bots need to learn new HTML elements as they develop. Are you
    saying that's impossible? Was it ever a problem?

    --
    Gregor's Motorradreisen:
    http://hothaus.de/greg-tour/
    Greg N., Dec 28, 2005
    #10
  11. Greg N.

    Spartanicus Guest

    "Greg N." <> wrote:

    >>>1. It's like each and every new element that was ever introduced in HTML
    >>>history.

    >>
    >> I illustrated why not. But since you decided to snip that I assume that
    >> you don't want to know.

    >
    >Ok, then I did not understand. I think it's just like, say, the
    ><object> element. If the UA does not understand it, the corresponding
    >info will be missing in the rendered page. Where is the difference?


    That depends on what is being embedded. At worst it could result in an
    external independent resource not being embedded on a page, this is
    perfectly normal and acceptable. For example a UA may not retrieve
    images, it's up to the author of a page to make sure that a textual
    alternative is available if the image is content.

    In the case of embedded HTML the content of the object element should
    contain a link to the (complete and fully independent) HTML page. It
    does not cause any problems for UAs who do not recognize the object
    element. SEs would index the external resource and link directly to it,
    browsers would render the content (the link). Only the embedding would
    fail, the content remains available and fully intact.

    >>>It would not break any UA in existence, it would only
    >>>(possibly) break pages that use it.

    >>
    >> It would result in existing UAs being incapable of dealing with sites
    >> that use such a feature.

    >
    >Yes, it would result in an incomplete page being rendered. This has
    >happened many times when new HTML elements were introduced.


    Name an example.

    >>>2. It could be implemented in a way that does not hurt old UAs, similar
    >>>to frame/noframe, script/noscript etc:
    >>>
    >>><include src...>
    >>><noinclude>
    >>>render this stuff here if include is not supported
    >>></noinclude>

    >
    >> That wouldn't work. If the content of <noinclude> were the same as what
    >> is in the external resource then it would defeat the point of the
    >> <include> element.

    >
    >Well, of course you'd have to use such a feature intelligently during
    >the introduction time, when not all UAs support it yet. You could do
    >things like that:
    >
    ><include src=my-whiz-bang-navigation-menu.html>
    ><noinclude>
    >a simple, rudimentary navigation section
    ></noinclude>
    >
    >or this:
    >
    ><include src=current-number-of-cars-in-tukkatukkaland.html>
    ><noinclude>
    >Last time we counted, there were 123456 cars in tukkatukka land.
    ></noinclude>


    As I said, this would completely defeat any potential benefit client
    side inclusion could offer for an author.

    >> If it were to be a link to the external resource, for
    >> example a SE bot would index the resource. If, as it should be, the to
    >> be included resource is served as text/plain (since it's not an HTML
    >> document), SE's would link to orphaned code fragments that wouldn't be
    >> scanned for HTML constructs like links.
    >>
    >> Fundamentally broken, and thus unacceptable.

    >
    >You did not convonvince me that UAs would be "fundamentally broken", now
    >you're telling me, SE bots will be fundamentally broken.


    A SE bot is a UA, so is a browser, as I said before every existing UA
    will no longer be capable of handling marked up documents that use such
    a feature.

    >Sure SE bots need to learn new HTML elements as they develop. Are you
    >saying that's impossible? Was it ever a problem?


    Breaking such a fundamental principle that requires every UA to be
    updated is a big step. The minor convenience that introduction of client
    side inclusion would bring pales into insignificance compared to that.

    --
    Spartanicus
    Spartanicus, Dec 28, 2005
    #11
  12. Greg N.

    Greg N. Guest

    Spartanicus wrote:

    >>>It would result in existing UAs being incapable of dealing with sites
    >>>that use such a feature.

    >>
    >>Yes, it would result in an incomplete page being rendered. This has
    >>happened many times when new HTML elements were introduced.

    >
    > Name an example.


    Script. Iframe. Frame. Style. Img. Object. Applet.

    By the way, let me rephrase my sentence above: "It _could_ result in an
    incomplete page being rendered" is more accurate.

    Apart from that, you may take every single one of your arguments and
    replace INCLUDE with one of the elements above. Your arguments would
    have the same validity, yet all the elements above were deemend worth
    implementing.

    >><include src=current-number-of-cars-in-tukkatukkaland.html>
    >><noinclude>
    >>Last time we counted, there were 123456 cars in tukkatukka land.
    >></noinclude>


    > As I said, this would completely defeat any potential benefit client
    > side inclusion could offer for an author.


    That argument would hold for IFRAME, SCRIPT, etc., too. As always, new
    HTML elements are not overwhelmingly useful initially and have to be
    used defensively until support for them is well established.

    > Breaking such a fundamental principle that requires every UA to be
    > updated is a big step. The minor convenience that introduction of client
    > side inclusion would bring pales into insignificance compared to that.


    Please make an attempt to explain to me why this would be any worse or
    more complicated than the introduction of the, say, IFRAME element.

    --
    Gregor's Motorradreisen:
    http://hothaus.de/greg-tour/
    Greg N., Dec 28, 2005
    #12
  13. Greg N.

    Spartanicus Guest

    "Greg N." <> wrote:

    >>>Yes, it would result in an incomplete page being rendered. This has
    >>>happened many times when new HTML elements were introduced.

    >>
    >> Name an example.

    >
    >Script.


    To be used for optional fluff only, it should not result in a broken
    page. The fact that you can use Javascript or CSS in ways that would
    render an HTML page incomplete cannot be attributed to a fault in HTML.

    The introduction of the script element could result in it's content
    being parsed by non <script> aware UAs, this was dealt with by using
    HTML comments in the script element's content whilst pre HTML 3 UAs were
    relevant. This is only possible when the content isn't parsed by an SGML
    parser such as a Javascript or CSS parser.

    >Iframe.


    Embedded content, a non issue as I explained in my previous post.

    >Frame.


    A fundamentally flawed concept, a leftover from the dark days before
    some sense was applied to the language by W3C who you are now
    criticizing for not including another fundamentally flawed concept into
    HTML4.

    >Style.


    See comment on script.

    >Img. Object. Applet.


    Like iframe a non issue, again see comment on embedded content in my
    previous post.

    >Apart from that, you may take every single one of your arguments and
    >replace INCLUDE with one of the elements above. Your arguments would
    >have the same validity, yet all the elements above were deemend worth
    >implementing.


    Again: it's not an issue if *embedding* fails, this is normal expected
    behaviour for which proper fall back mechanisms exist.

    Client side inclusion would break documents, there is no fall back
    mechanism possible other than replicating the included external content
    verbatim in the calling document which makes a mockery of the purpose
    of client side inclusion.

    >Please make an attempt to explain to me why this would be any worse or
    >more complicated than the introduction of the, say, IFRAME element.


    I've done so more than once now, but apparently you've stuck your
    fingers stuck in your ears whilst lalling "nana na, can't hear you".
    Fine, I tried, bye.

    --
    Spartanicus
    Spartanicus, Dec 28, 2005
    #13
  14. Greg N.

    Greg N. Guest

    Spartanicus wrote:

    > I've done so more than once now, but apparently you've stuck your
    > fingers stuck in your ears whilst lalling "nana na, can't hear you".


    You certainly tried more than once.

    The fact that you're resorting to ad hominem slurs seems to indicate
    you're indeed running out of arguments.

    --
    Gregor's Motorradreisen:
    http://hothaus.de/greg-tour/
    Greg N., Dec 28, 2005
    #14
    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. Cloud Burst
    Replies:
    11
    Views:
    1,024
  2. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    878
    Mark Rae
    Dec 21, 2006
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,840
    Smokey Grindel
    Dec 2, 2006
  4. Andreas Bogenberger
    Replies:
    3
    Views:
    903
    Andreas Bogenberger
    Feb 22, 2008
  5. Dan Jacobson
    Replies:
    0
    Views:
    84
    Dan Jacobson
    Jul 22, 2003
Loading...

Share This Page