why is there no INCLUDE function in html?

[Greg N.]

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?

 

[Jan Faerber]

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.

 

[Greg N.]

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.

 

[Richard Brooks]

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.

 

[Jukka K. Korpela]

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.

 

[Greg N.]

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?

 

[Spartanicus]

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.

 

[Greg N.]

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>

 

[Spartanicus]

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.

 

[Greg N.]

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 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.

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.

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?

 

[Spartanicus]

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.

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

Name an example.

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.

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.

 

[Greg N.]

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.

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.

 

[Spartanicus]

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.

 

[Greg N.]

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.