Posted by Spartanicus on 12/28/05 14:44

"Greg N." <yodel_dodel@yahoo.com> 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

[Back to original message]