Regular ajax websites

Like everything in Active CSS, you can either set up part of your website to use this technique or a whole website. This may even be the only aspect of Active CSS that you actually want to use. So you could technically use this method for handling the SPA aspects of your website and just use regular JavaScript for everything else. If parts of Active CSS were ever implemented into the browser, this would be one of the cooler things to implement into regular CSS.

It uses the Active CSS @pages declaration, as do all the SPA techniques.

Concept

1. You create a link.
2. The user hovers over the link and clicks.
3. Before the click is processed, internally the link's URL is found in @pages and then attributes from that @pages entry are copied into the link element.
4. The click now runs and performs all the events based on the attributes now in the link. Ie. loads ajax, displays results, etc.

It's a brand new way of thinking about routing, and doing it this way allows so much more than just simple content loading.

Here's an example of a regular static HTML website that was written using @pages to handle all the SPA navigation. No other JavaScript and nothing on the back-end except HTML files. It's a 100% ACSS website. Apologies in advance for the technical terms - it's a manufacturing industry website:

https://teamframes.com

I think you'll agree that this is better in terms of performance and page transitions than most of what you will find on the internet. It's just straight up HTML, CSS and ACSS - no plugins at all. There is also a custom photo gallery on there, that only took a couple of days to write and tweak in ACSS.

With simpler technologies and a less involved stack, you can produce code that is bug-free and easier to upgrade. Enterprise systems become a lot more stable, you get less random issues, and you get respect from your employers. There's just a lot less going on in your stack, with the same (or better) end result than if you were to go complex. It's easier for a team to manage. The simpler, the better. Or, in other words, the less computing instructions, the less that can go wrong.

Description

Let's say you've got a static site. All your pages are off the root (/), and when that page is refreshed, you always get a full page, including the doctype and header tags - the whole thing. You always want to retrieve a full page on refresh regardless of whether you are setting up an SPA or not. That way your website is bookmarkable.

You need to keep your website working with the refresh button. Anything less is just amateurish and you're probably using the wrong framework on the back-end.

As you're building an SPA you have also setup files in an /html/ folder which just contains the inner content for each page without any headers.

It doesn't matter how you've done this, but you've done it (see the tutorial in the Technical articles section for the basic concept if you need to).

Now you're ready to click on a link, and only load up inner content to place into a certain content area.

You have written a page (some-other-page.html) and now want to write an ajax link in there to load up the blog page.

In Active CSS, for SPA pages you just write a regular link (this enables editors like tinymce to be used to administrate site links without things getting complicated).

For example:

<a href="/myblog.html">Blog</a>

The magic happens in the next bit.

When the user hovers, or clicks on that link, the attributes from the following @pages declaration are automatically attached to the <a> element based on the URL in the href attribute.

The @pages declaration might look something like this (this should be stored in site-wide config and not in an embedded tag):

@pages {
    "/blog.html": class="myPage" data-title="Blog" data-ajax="/html/blog.html";
    "/some-other-page.html": class="myPage" data-title="Blog" data-ajax="/html/some-other-page.html";
}

By the time the click is processed, the <a> tag ends up looking like this:

<a href="/myblog.html" class="myPage" data-title="Blog" data-ajax="/html/blog.html">Blog</a>

Which means to load your inner content you can write something like this in your config:

.myPage:click {
    url-change: "{@href}" "{@data-title}";
    ajax: "{@data-ajax}" get html;
}

.myPage:afterAjax {
    #contentArea {
        render: "{$STRING}";
    }
}

Ie. when the user clicks the link:

1. The page changes to the correct title gotten from the link element (data-title).
2. The url changes in the browser (href).
3. The content is fetched from the server (data-ajax - the file to be fetched is in the /html/ folder don't forget and only contains inner content).
4. The string that comes back from the server ($STRING) is then rendered into the content area (#contentArea).

All links mentioned in @pages declarations get the same treatment. When you hover over the link, the attributes get substituted into the link element from @pages before the click is processed.

That's it. Your page is fully bookmarkable and will work as expected when using browser navigation.

 

This is a very basic example, but you can get as complex as you like with the attributes in the @pages declaration in order to fully handle display requirements. You can then call multiple events with different conditionals in order to handle stuff like checking if a side-menu is visible, and things like that.

This method will work with any content from a server, dynamic or otherwise. Your inner pages do not have to be in an /html/ folder - it doesn't matter what URL you use to fetch your content as long as it fetches your content. You could process JSON if you wanted to output multiple things in different places - it doesn't matter with this method. You can set up your events to handle things however you want to. You could change the background to a different colour for a specific page by setting a data-color attribute in @pages - whatever you like.

This method is very flexible and it simply extends the syntax of ACSS with the use of the @pages declaration.

There's a PHP tutorial on this in the technical articles section. But the concept applies to any back-end, not just PHP.