Why don't all HTML elements have a src attribute?

In the middle of writing a blog post about generating placeholder text (think lipsum..coming soon) I started wondering why there is no HTML-native way to load arbitrary content into an element.

API's and RESTful services are all over the web these days, but we continue to have to jump through hoops to access them. Either we have to use AJAX (which is essentially a clever hack) or we have to resort to server side technologies like cURL. This isn't the case if the "arbitrary content" is an image, a script, some css or audio/video in HTML5. For those we have clever HTML elements like <img>, <script> <link> or in HTML5 even <video> or <audio> and if you want to fetch a whole document you can use the (imo horrendous) <iframe> tag. Most of these use a "src" attribute to go off and fetch some content, check if its appropriate for the tag, and then render it appropriately.

Why can't we do that with a <p>, <h#> or <div> tag?

Imagine twitter has an additional API that just returns bits of text or HTML rather than XML/json for our hoop jumping ajax/curl type requests.

On my blog page, I could do this:

<div src="twitter.com/erisds/latest">sorry, my latest tweet could not be loaded</div>

I could use RESTful requests directly in my page, without having to jump through hoops, without needing additional javascript & serverside code. Fetching content from a URL is effectively the core function of a browser, as is handling the resulting HTML. It just seems odd, that given HTML has this functionality (fetching and handling/rendering responses from a URL) built in for complex stuff like images, video and audio, why can it not do it for the simple stuff?

Sure this could be abused, but is it not even worth considering?

It turns out this was in the XHTML2 spec: http://www.w3.org/TR/xhtml2/mod-embedding.html So where did it go? Why didn't it make it into HTML5?

More detail...

Updated: This wouldn't replace AJAX entirely, as these would be synchronous requests on page load, but if we only need the content to be updated once per page refresh, it would make perfect sense. We'd still be using AJAX to submit forms etc, but there are a lot of cases I can think of where there's no need for the requests to be asynchronous, it's just that AJAX is the current easiest method of going to get data from somewhere else.

Also there's the potential problem of people trying to load in all their content from different places and making tonnes of requests. Or alternatively abusing this to recreate the frameset / iframe hell of the 90's. Whilst obviously this would be an issue, we've already learned the frameset lesson, and now people know how to use these tools properly (or not at all). In most cases, the request would just be replacing one that was being made some other way.

Also some people have raised the point, what would the browser do if it didn't recognise the content fetched? This is already handled for images, video, audio etc. I don't see why it is a hard problem to solve for HTML and plain text - this is what a browser is for!!

Some more examples...

I'm not suggesting doing an API call for every single variable that might go into an HTML page, but it would still be possible to massively reduce the complexity of some templating or theme systems.

For example, in Symfony there is the concept of components. These are standalone templates which might draw part of the page - for example the menu, or a sidebar. WordPress' templates & business logic isn't separated in the "MVC" style same way, but it still has the concept of sidebars, widgets & menus. These components, or separate templates, are still driven by PHP but usually are completely standalone - they work outside of the context of a page. So an archive widget is still an archive widget whether it's on page X, Y, or completely on it's own.

In Symfony, components are pulled in using a glorified PHP include. WordPress is full of "template tag" functions which echo HTML by default and are always available to the theme.

If we had a src attribute for all attributes we could do things like:

<aside src="/widgets/archive">Archive Unavailable</aside>

or

<nav src="/menus/main-menu"><a href="/">Home</a></nav>

or

<section src="/products/t-shirts/mens/">0 products available</section>

Each time we can specify some default or placeholder content, and then rely on the browser to query the URL, and place the response into the right part of the page. All while keeping our HTML nice and clean and separating our business logic from our templates in the same way we have been separating our content & styling with HTML & CSS for years.

For WordPress, it wouldn't make a great deal of sense currently, because you'd effectively have to have a PHP file at the location of /widgets/archive with:

<?php wp_get_archives('type=monthly'); ?>

But MVC style applications which use routing systems with controllers already know how to handle a URL like /menus/main-menu, send it to a certain controller to do some business logic and then render a partial template. For example an e-commerce platform may already have a product controller - this would probably take a couple of arguments, go off to the database (via a model) fetch the right products based on those arguments, then do some logic before passing the data to a partial templates.

So my /products/t-shirts/mens example would send the arguments category = t-shirts, sub-category = mens to the product controller, get all the products from the database and pass the list of products to a template to render a pre-formatted list of products. This could be used anywhere a list of products is needed on the site, and could potentially be exposed to the wider internet so that other sites can show your products (think amazon affiliate programs).

The MVC pattern is widely accepted as being one of the better application patterns - partly because it encourages a RESTful / stateless system which is basically an API with templates built on top of it. More and more websites and web applications are offering APIs and it makes sense to build your application with an API and use it yourself. I can't help feeling that if we had this src functionality, this would encourage this style of programming much more and make the tendancy towards publishing an API even more widespread.

(And if you want to know what's great about APIs... maybe start here)