How do you validate (for example using http://validator.w3.org/) a multipage jquery mobile site? For example if I navigate away from index.html the page is only a div without a header or body.
"It depends".
Validation only makes sense in the context of HTML documents, and if you are modifying a document with JavaScript you only have the initial state to validate.
You could use a tool such as Selenium to drive the site and take snapshots of the DOM (serialising it to HTML) when it is in different states, then validate those snapshots. (The markup validation series has an API you can call programatically so you could combine those).
If you are generating fragments of HTML on the server (instead of sending pure, structured data to the client) then you can embed those fragments in HTML skeleton documents and validate those. You should have such documents existing for most views anyway (since you don't want to repeat Gawker's mistake by having a fragile site completely dependant on Ajax).
See also Progressive Enhancement and Unobtrusive JavaScript
Related
Currently my Nuxt.js application serves HTML pages defined in layouts, pages, routes and components.
Is it possible to render one single route / one page as a standard JSON Response? Is that possible? I mean do not render the HTML e.g. Tags - only pure JSON!
What I already tried:
Created a completely clean layout (with basically only in it), no succcess, still HTML.
Used <pre>{{jsonObject}}</pre> hoping to get plain JSON, no success.
Would be VERY happy, if somebody could tell me whether this is possible AT ALL or not?
What you're looking for here, is an API.
Vue.js will render a template (compiled to render functions, generating a DOM tree) at the end, because it's aimed towards a frontend usage. If you want to render something like an API response with pure JSON, you need to look into Express or alike.
I know a typical practice to build an Electron app is to follow SPA (Single Page App). I still would like to split my html content into separate files for easy maintenance. There is still the main index.html file which is to be loaded on startup.
My question is: is there a protocol for inserting a part of html content from a different files? For eg. in Django, there is a include and extend tags where you can insert an entire html file into the body of another parent html file or retain certain features from another html file.
There's no way to do this directly. Django is a server-side framework, so you can assemble your HTML on the server, and the completed HTML is sent to the client/browser. With Electron, you're basically running Chromium with Node.js APIs added, loading your HTML from the filesystem, so there's no server to do any HTML assembly in.
However, if you just want to break up your HTML into pieces for easier maintenance, but you're not doing any of your include/extend dynamically, theoretically, you could use some kind of templating system or a static site generator to combine your HTML files statically at build time.
Here's an list of some JS templating engines: https://expressjs.com/en/resources/template-engines.html
Here's a list of some static site generators (filter language by JavaScript): https://jamstack.org/generators/
I am not sure whether I got the idea of express MVC right:
If I want to make a single page app and dynamically change the HTML, is it something express can help me with? or do I get static pages that if I want to change I have to use front-end JavaScript?
To be more specific, the HTML (or Jade) templates can can change the HTML that is in the front-end somehow?
If I want to make a single page app and dynamically change the HTML,
is it something express can help me with?
Yes.
or do I get static pages that if I want to change I have to use
front-end JavaScript?
Yes, you will need to use JavaScript in the front-end to change the pages if you don't want to refresh the entire page.
To be more specific, the HTML (or Jade) templates can can change
the HTML that is in the front-end somehow?
Typically the HTML (or Jade) templates that you use in Express.js will produce the initial version of the page.
As the user interacts with the page on the browser (say the user clicks on a link or selects something from a dropdown list) your client-side code will submit an Ajax request to the server, Express.js will process this request and return JSON (not HTML) back to the client, and your front-end JavaScript will repopulate some data on the client. Keep in mind that at this point you won't be producing more HTML from the server, though.
Your Express.js could return HTML instead of JSON for these requests but that gets messy pretty quick so most people writing Single Page Apps chose to return JSON back to the client and use client-side JavaScript to repopulate whatever DOM elements need to be updated.
Is it possible to make JSON data readable by a Google spider?
Say for instance that I have a JSON feed that contains the data for an e-commerce site. This JSON data is used to populate a human-readable page in the users browser. (I.E. The translation from JSON data to human displayed page is done inside the users browser; not my choice, just what I've been given to work with, its an old legacy CGI application and not an actual server-side scripting language.)
My concern here is that, the google spiders will not be able to pickup/directly link to the item in question when a user clicks on it in google, being presented with an index page full of all the items, rather than being linked directly to the item they clicked on.
Is there anyway of "informing" the google spider in the JSON that what they should feed the user a different link?
While Google does crawl and index JavaScript in some circumstances, it's still best to serve "normal" (X)HTML content if at all possible. In this case, it would help to know the rest of the site's setup, in particular: is the JSON content just used to create a feed of links to the product pages (with static content) or are all product pages also generated by JSON feeds? If the feed is only used to point to the actual product pages (which are static) then one way to make the product pages discoverable could be to create a HTML sitemap page or some other alternate form of navigation. A XML Sitemap file can also help, but I would recommend not using it as the sole way of making the product pages discoverable.
If all of the content is only accessible through JSON feeds, then I think you will have to make some bigger changes if you want that content to be accessible through search results.
One way to handle it could also be to use the new JavaScript crawling/indexing proposal, which basically would result in a headless browser being set up between your site and Google: http://code.google.com/web/ajaxcrawling/ (whether setting this up or revamping the rest of the site is easier is hard to say :-))
You should make a wrapper page in server-side code around the JSON data, and respond to requests with either the wrapper or the regular version depending on the User-Agent.
Is there a widely used standard way on how to index ajax loaded content (for search engines)?
For example, indexing HTML content that would dynamically be inserted into a page.
Thanks
You may want to consider using some sort of sitemap generator that aggregates all the content you normally load through AJAX.
Sitemaps are particularly beneficial
on websites where:
Some areas of the website are not available through the browsable
interface, or
Webmasters use rich Ajax, Silverlight, or Flash content that is
not normally processed by search
engines.
From Wikipedia - Sitemaps
Remember that:
Because most web crawlers do not
execute JavaScript code, publicly
indexable web applications should
provide an alternative means of
accessing the content that would
normally be retrieved with Ajax, to
allow search engines to index it.
From Wikipedia - AJAX Drawbacks
In addition you may be interested in checking out the following articles:
Official Google Webmaster Central Blog - A proposal for making AJAX crawlable
SoftwareDeveloper.com - How to: Get Google and AJAX to Play Nice
Crawling Ajax-driven Web 2.0 Applications
One way of doing this is using JS fallbacks for dialog boxes like thickbox: A link would point to the dialog box loading Ajax content, and the fallback href='...' would point to a search engine-readable representation of that content (i.e. the HTML snippet that the AJAX function would load, but surrounded by the necessary HTML body basics).
Example (I pulled rel='box' out of my arse, this is supposed to be the anchor for the box plugin, like rel=thickbox):
<a href='/encyclopedia/definition/mushroom.html' rel='box'>Definition of Mushroom</a>
Clicking on the link in a Ajax/JS enabled browser will open a nice dialog box with the article
Clicking on the link without JS (or as a search engine) will lead to a new page containing the article (which needs some server side intelligence to detect which channel the request came from).
That's all that comes to my mind in this direction. Ajax and search engines is a widely uncharted field otherwise.
Have Javascript fallbacks. Have a look at Amazon Diamond Search with and without Javascript enabled. Read up on http://www.seroundtable.com/archives/006889.html
I don't really know the answer, but it seems to me that ajax-loaded content won't help to improve se positions because search engine can't refer to ajax-loaded content. Another words search engine can't say: "Hey, go here and then click 3rd button from the top to see the content you're interested in.".
I think that good idea is to put this content to xml and put link to this xml at tag (like URL to RSS)...
What about using an alternative content for JS disabled clients (search engines)? I think there is no other way of letting the search engines index your AJAX site properly.
I think actually only Google really implements a specification to index AJAX content.
It's the Google AJAX crawling specification.
We have used that for our website, there is an example in our technical blog on how to do that with Django in a clean way.