I think that is really important to have the «src» attrinbute in tags other
than «img» in order to include XHTML fragments without depending on
server-side mechanisms as ISS or PHP. For example:

<div src="fragment.xhtml" />

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dr. Dario de Judicibus - Italy (EU)
Site: http://www.dejudicibus.it/
Blog: http://lindipendente.splinder.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"Dario de Judicibus" <nospam@nowhere.com> wrote:
[color=blue]
>I think that is really important to have the «src» attrinbute in tags other
>than «img» in order to include XHTML fragments without depending on
>server-side mechanisms as ISS or PHP. For example:
>
><div src="fragment.xhtml" />[/color]

Again: such a feature would break all current and past UAs, they would
not be able to render such a construct. That's a very high price to pay
for such a trivial feature.

Stop whining about it and use one of the many solutions that have
already been suggested to you.

--
Spartanicus

Dario de Judicibus wrote:[color=blue]
> I think that is really important to have the «src» attrinbute in tags other
> than «img» in order to include XHTML fragments without depending on
> server-side mechanisms as ISS or PHP. For example:
>
> <div src="fragment.xhtml" />[/color]

If we've all gotten along all this time without it, how can it be
"important"?

Why is it important not to use a server-side mechanism?

"Harlan Messinger" <hmessinger.removethis@comcast.net> ha scritto nel
messaggio news:43v1edF1pg7onU1@individual.net...
| Dario de Judicibus wrote:
| > I think that is really important to have the «src» attrinbute in tags
other
| > than «img» in order to include XHTML fragments without depending on
| > server-side mechanisms as ISS or PHP. For example:
| >
| > <div src="fragment.xhtml" />
|
| If we've all gotten along all this time without it, how can it be
| "important"?
|
| Why is it important not to use a server-side mechanism?

Because it is not always available!!!!!!!!!!!!!!!
There millions of sites based ONLY on client code!
Most internet is made of personal sites, not e-commerce or company sites.
The real Internet is made by people, volunteers and free resources.

DdJ

"Spartanicus" <invalid@invalid.invalid> ha scritto nel messaggio
news:tejkt1lgq85h9upcjaorlh4bva2tu8q6uk@news.spart anicus.utvinternet.ie...
| "Dario de Judicibus" <nospam@nowhere.com> wrote:
|
| >I think that is really important to have the «src» attrinbute in tags
other
| >than «img» in order to include XHTML fragments without depending on
| >server-side mechanisms as ISS or PHP. For example:
| >
| ><div src="fragment.xhtml" />
|
| Again: such a feature would break all current and past UAs, they would
| not be able to render such a construct. That's a very high price to pay
| for such a trivial feature.
|
| Stop whining about it and use one of the many solutions that have
| already been suggested to you.

Well, this is true for any new version of XHTML or CSS. What's different?

DdJ

Dario de Judicibus wrote:
[color=blue]
> There millions of sites based ONLY on client code!
> Most internet is made of personal sites, not e-commerce or company sites.
> The real Internet is made by people, volunteers and free resources.[/color]

That's why most of it stinks. Client-side includes won't fix that.

--
philronan [@] blueyonder [dot] co [dot] uk

"Dario de Judicibus" <ddj@mclink.it> wrote:
[color=blue]
>| >I think that is really important to have the «src» attrinbute in tags
>other
>| >than «img» in order to include XHTML fragments without depending on
>| >server-side mechanisms as ISS or PHP. For example:
>| >
>| ><div src="fragment.xhtml" />
>|
>| Again: such a feature would break all current and past UAs, they would
>| not be able to render such a construct. That's a very high price to pay
>| for such a trivial feature.
>|
>| Stop whining about it and use one of the many solutions that have
>| already been suggested to you.
>
>Well, this is true for any new version of XHTML or CSS. What's different?[/color]

CSS is by design an optional technology, at worst certain presentational
aspects are not shown. All my CSS2 sites are perfectly usable in a CSS1
browser such as Opera 3.6.

HTML hasn't essentially changed since 1997. XHTML 1.x is merely a
reformulation of HTML in XML.

The elements that were added to HTML 4 since HTML 3.2 do not, or for a
few elements at least should not cause content not to be available. UAs
by design ignore unknown markup and *they render the content*. So an
HTML 3.2 UA will ignore <span> elements and render the content. That
also applies to elements like <iframe> that were added to HTML4 if
properly used: <iframe src="foo.bar"><p><a href="foo.bar">link
text</a></p></iframe>.

Supplying an URI to a code fragment as an attribute value to existing
elements as you'd like is fundamentally different since it doesn't even
allow coding of a fall back solution.

Adding a new <include src="foo.bar"></include> construct is also not an
option since unlike the with <iframe> construct it isn't possible to
code a link as content for the element, a link to a code *fragment*
would be worse than useless.

The only way to add this type of feature to HTML without causing massive
problems is by introducing it into a language that is explicitly
designed to be *not* backward compatible.

I say again, what you want is a trivial feature, not remotely worthy of
causing such a fundamental problem.

--
Spartanicus

"Dario de Judicibus" <ddj@mclink.it> wrote:
[color=blue]
>| > <div src="fragment.xhtml" />
>|
>| If we've all gotten along all this time without it, how can it be
>| "important"?
>|
>| Why is it important not to use a server-side mechanism?
>
>Because it is not always available!!!!!!!!!!!!!!![/color]

As has been pointed out to you on several occasions there are plenty of
other solutions that do not require any additional server side
solutions.

Besides, following your "logic", HTML should be extended to generate
music, because not everyone has an audio editor!!!!!!!!!!!!!!!!

--
Spartanicus

Dario de Judicibus wrote:
[color=blue]
> I think that is really important to have the «src» attrinbute in tags
> other than «img» in order to include XHTML fragments without depending on
> server-side mechanisms as ISS or PHP. For example:
>
> <div src="fragment.xhtml" />[/color]

Once XHTML becomes the widely supported standard on the web, it *might* be
possible that user-agents support the XInclude extension - it *may* be even
required for user-agents conforming to a not yet existing future version of
XHTML.

But you'll have to way some years or even decades for this to happen...

Patience is a virtue - and in the meantime get back to work ;)

--
Benjamin Niemann
Email: pink at odahoda dot de
WWW: http://www.odahoda.de/

"Spartanicus" <invalid@invalid.invalid> ha scritto nel messaggio
news:g2elt19ohgcojf0hfgreogqp6d9tsjgnik@news.spart anicus.utvinternet.ie...

| Supplying an URI to a code fragment as an attribute value to existing
| elements as you'd like is fundamentally different since it doesn't even
| allow coding of a fall back solution.

Yes, it has, if you say

<p src="fragment.html">Well, this is your fall back</p>

--
Dario de Judicibus - Rome, Italy (EU)
Site: http://www.dejudicibus.it
Blog: http://lindipendente.splinder.com

"Philip Ronan" <nobody@example.invalid> ha scritto nel messaggio
news:0001HW.C0006EF7009182E0F070D550@news.blueyond er.co.uk...
| Dario de Judicibus wrote:
|
| > There millions of sites based ONLY on client code!
| > Most internet is made of personal sites, not e-commerce or company
sites.
| > The real Internet is made by people, volunteers and free resources.
|
| That's why most of it stinks. Client-side includes won't fix that.

Internet was not born to sell products, it was born to share knowledge,
freely. A hand-made not-professional site providing by free valuable
resources, is more important to cybersurfers than a wonderful site whose
only purpose is to enrich a company, in my opinion. And HTML, XHTML and CSS,
should be intended for people who have little resources rather that rich
companies. Otherwise you will increase the digital gap and continents as
Africa will never gain value from the Net. By the way, most of people in
Internet protocol and languages committees, today, are just companies'
employees. They have a single-oriented view, and it is a pity.

--
Dario de Judicibus - Rome, Italy (EU)
Site: http://www.dejudicibus.it
Blog: http://lindipendente.splinder.com

"Spartanicus" <invalid@invalid.invalid> ha scritto nel messaggio
news:uuglt158g2eqd6hkgb35gkcp7pljicjv72@news.spart anicus.utvinternet.ie...

| Besides, following your "logic", HTML should be extended to generate
| music, because not everyone has an audio editor!!!!!!!!!!!!!!!!

Why not? I wrote an XML language to write music score many years ago. I
stopped the project because MusicXML is doing a better work and there is no
reason to duplicate efforts. But once you have a score, you can play it.

There is no limit of what Internet can be BUT our fantasy.

But REMEMBER, Internet is made for people, all people in the world.

Otherwise we would still have to work with useless ANSI-7 character set,
which is not able to render most world languages. Just english and few
others: no spanish, no italian, no french, no german, no gaelic or greek, no
chinese or arabic, no japanese, thai, cherokee or japanese.

World is much more than e-commerce or anglosaxon culture. It is plenty of
information, knowledge, experiences that can be shared to know better each
other, and technology should be designed for that. Designer should not
assume the best scenario, but the worst.

Generate audio? Seriously... have you ever thought to the fact that what is
an option for you, that is, accessing internet, could be the ONLY way for
many people to know the world? People who cannot move because of
disabilities or illness, or blind people. Generating audio for blind people
makes the difference.
It is not a matter ofphylosophy or ideology, it is a matter of priorities,
very concrete priorities.

This is far from original post, of course, but has to be said, because
people who design languages and protocol MUST always keep in mind that,
rather than the usual fight between companies to have THE STANDARD as close
as possible to the proprietary products they already have.

--
Dario de Judicibus - Rome, Italy (EU)
Site: http://www.dejudicibus.it
Blog: http://lindipendente.splinder.com

"Benjamin Niemann" <pink@odahoda.de> ha scritto nel messaggio
news:drg5rc$go5$1@online.de...

| But you'll have to way some years or even decades for this to happen...
| Patience is a virtue - and in the meantime get back to work ;)

Well, XHTML is the right direction, in my opinion, and XInclude is too. I
hope that in a world that is moving faster and faster, I will not have to
wait decades for that... ;-)

--
Dario de Judicibus - Rome, Italy (EU)
Site: http://www.dejudicibus.it
Blog: http://lindipendente.splinder.com

"Dario de Judicibus" <ddj@mclink.it> wrote:
[color=blue]
>| Supplying an URI to a code fragment as an attribute value to existing
>| elements as you'd like is fundamentally different since it doesn't even
>| allow coding of a fall back solution.
>
>Yes, it has, if you say
>
><p src="fragment.html">Well, this is your fall back</p>[/color]

No, as I demonstrated that is worse than pointless.

--
Spartanicus

"Dario de Judicibus" <ddj@mclink.it> wrote:
[color=blue]
>| Besides, following your "logic", HTML should be extended to generate
>| music, because not everyone has an audio editor!!!!!!!!!!!!!!!!
>
>Why not? I wrote an XML language to write music score many years ago.[/color]

You're missing the point. The fact that HTML can't fry eggs doesn't mean
that is should.
[color=blue]
>Generate audio? Seriously... have you ever thought to the fact that what is
>an option for you, that is, accessing internet, could be the ONLY way for
>many people to know the world? People who cannot move because of
>disabilities or illness, or blind people. Generating audio for blind people
>makes the difference.[/color]

Now you are getting even more confused than you already are. HTML is a
markup language, it applies semantics to, and structures content. What a
browser does with it is an entirely different issue.

--
Spartanicus