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:
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…
Updated 2: It seems that I’ve not done a great job of explaining the potential benefits of this feature. If you’ve worked extensively with APIs, or if you’ve ever built a fully RESTful/MVC style PHP application, perhaps the benefits are clearer. Also if you’ve ever dealt with smarty or another templating language.
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:
1 | <aside src="/widgets/archive">Archive Unavailable</aside> |
or
or
1 | <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:
1 | <?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)
9th Mar
Keith Cirkel says:
I think while the base idea is cool, and it’d be great to load HTML fragments, the spec is obviously not very well thought out past the initial idea. If I threw it a media type it didn’t know about, say, a PSD file – what would happen? Even worse, what if I specified a URL which has a “Content-Disposition: Attachment” header? Will the file download to my desktop, or not display, or will it try and display it?
9th Mar
ErisDS says:
I’ve just added an update which covers some of the issues mentioned on twitter. What happens if you specify a PSD file in an <img> tag? Or if you specify a URL which has a “Content-Disposition: Attachment” header for an <iframe>?
Browsers already have to cope with these things, does it not?
9th Mar
Eric C. says:
After reading the XHTML2 spec on Embedding, I find it interesting that there isn’t a specific mention of embedding text or html ContentTypes. Perhaps there was security concerns surrounding supporting @src for common elements.
Although, I’ve been inspired to write a javascript “shim” to support the @src attribute making your twitter example easy to impliment…
9th Mar
Phil says:
If it is only once per page load, why not do this serverside? Especially with all the benefits that brings with extra processing of the return. Is there a specific advantage to doing it this way other than less typing? Or is it just as another string to the bow?
9th Mar
ErisDS says:
You’re making the assumption there is a server side!
It would make it possible to load dynamic content into a static HTML page without using server side technologies.
9th Mar
Eric says:
After reading the back-and-forth on Twitter a few minutes ago, I was skeptical. But your example with the and latest Tweet sold me. I use a lot of REST APIs that return bits of text or blocks of HTML, but I have to fetch them with AJAX and use jQuery to dump them into the appropriate element on the page. If this were built-in to the browser (and easily could be) it would save me a lot of time.
I wonder if there would be any value in a short-term JS library to do it for you. Basically, parse the src attributes, fetch the content via AJAX, and place it in the right location on the initial page load. It wouldn’t be a perfect solution, but it might fill this particular hole in the XHTML2 spec.
9th Mar
Seb Ashton says:
The HTML5 spec is far from concrete so you never know it may fall into it at some point.
If implemented I could see it being a great attribute to target for API calls so you can remove strings from your queries and make calls more generic.
10th Mar
Keith Cirkel says:
To clarify my earlier point, and to give a counter-rebuttal – if I where to give an img tag an src attribute, it is assumed that it should be an image, or not render. If I give a video tag an src, I would expect it to only take video. What content does a p tag take though? This is my concern, that there is too much scope with the idea, and no narrow definition, and without that, I can see this being used really incorrectly.
However, after mulling this over for a little while I am starting to think it has a lot of play. It would be awesome to load a static HTML homepage with small dynamic elements, or even better, a combination of Javascript and the HTML5 History API, you could have an “ajax” website where the page never “refreshes”, just loads content into the div#mainContent by changing that elements src attribute programmatically; so the user never sees the transition. (ok, before you moan, consider how this could mean it could be done properly).
10th Mar
ErisDS says:
@Eric C There are scripts out there that already do it for example this one for divs: http://turton.co.za/DIV_SRC/ and I have the basis of a jQuery plugin which I hope to finish tomorrow. I guess all I’m interested in is why this was in the XHTML2 spec but never made it to HTML5
10th Mar
ErisDS says:
This is the key question, and I would suggest text/plain and text/html. The request header could surely be used to determine which?
There is definitely scope to use this incorrectly, but that goes for a lot of our commonly used web tech. We learned frames were bad. We learned inline CSS is bad in most cases. We’re learning which bits of JavaScript are good and bad.
Because there is a learning curve to use something properly, is not a reason not to have it (well it hasn’t been so far) and as you’ve pointed out, there are so many great examples of how it could be used properly to do amazing things, easily.
11th Mar
jbk says:
You can emulate this with jQuery
$(‘[src]:not(img,iframe,script)’).each(function(k, v) { var $_this = $(this); $_this.load($_this.attr(‘src’)); });
Not EXACTLY what you asked for, but it will have to do for now!
11th Mar
jbk says:
Oh, this won’t work for cross-domain requests though.
17th Mar
sunil says:
meant to say i’ve a working prototype, and proposed a feature request to w3c.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12311