I've built a web site using jquery to make nice transitions between content.
The code works this way: there are 2 imgs (body and footer).
When I click on a link (instead of going to another page) I fade out the 2 imgs and change the src attribute of the 2. When the new imgs are loaded I fade them back in.
I'm using SWFaddress to allow user go directly to internal content.
Now I'd like to make my content indexed by google and other Search engines,
all the text content is inside the imgs, So I've got the text in ALT attribute.
My question is:
If a dynamically change the imgs ALT attribute using JS, will spiders be able to read it properly?
Consider that I'm using SWFaddress to create a sitemap.
Search engine robots generally do not process JavaScript. So no.
You're doing it wrong.
If you want a website with a lot of JS to be good for both bots and human without JS enabled (think of blinded people with screen reader for instance), you need to develop your website with content in text format and without any javascript.
Then you use high level JavaScript framework like jQuery to replace the content and change the navigation, form submission etc. as you want when the page is loaded (you know, the well-known $(document).ready(function(){/*...*/});.
This way you'll have the good parts of both worlds: "cool" animations and good accessibility (which means good SEO).
I'm not familiar with SWFaddress so my advice could be off.
But Googlebot will crawl and index some javascript. The same can't necessarily be said about Bing/Yahoo.
Google understands that sites are evolving and things like Flash and heavily used AJAX sites are popular, and to achieve their goal of "Organizing the World's Information", they need to get at it.
You can find information about Google's ability to crawl and index flash here: http://googlewebmastercentral.blogspot.com/2008/06/improved-flash-indexing.html
And more recently they talked about how they are crawling and indexing AJAX / XHR content when they're reasonably sure of the content: http://googlewebmastercentral.blogspot.com/2011/11/get-post-and-safely-surfacing-more-of.html
If you look at github they have a very slick AJAX experience, but as you navigate through the folders of a repo, it makes POST requests to get the additional XHR information. With the new Google crawling abilities, they should be able to more easily index github content without having to fall back to the non-HTML5 un-popstate experience.
But I would echo the other responses that you really should strive to make your site accessible to disabled users, which is more than just users using a screen reader. It sounds like you're doing that already, so kudos to you.
Bottom line, the AJAX content you're creating has a good chance of getting properly indexed, however, you might want to implement it in the way that Google's said they know how.
Related
I just recently started learning javascript and have a question regarding the'proper use'. I'm still trying to identify the role of Javascript within a website, and I'm curious whether or not it would be considered ok to have Javascript modified the HTML of a web page.
Let's say I have a panel on a web page. This panel houses a list. I would like users to be prompted to add items to this list.
I was thinking that it would be possible to use Javascript to generate list items to add to the list. However, this would be modifying the actual number of HTML elements on the web page... For some reason, this just seems 'hacky'. When I think of HTML, I think of a static structure that should come to life with CSS and Javascript.
So my question: is it considered okay to have Javascript modify the HTML of a web page? What about the case of adding items to a list?
Thank you!
Javascript is a programming language designed so it can modify the document that is being displayed(the DOM), the actual HTML is never touched.
Javascript has a place on a website and modifying the document/dom is perfectly acceptable and without it, would make javascript almost useless. CSS is great for certain tasks, but you can't do everything in CSS, though CSS5 is coming pretty close for many tasks.
Rewriting the entire DOM IS bad practice, but using it to shift an element's position based on an action, or creating a popup overlay is perfectly acceptable.
Remember the gold rule:
Modify as little as possible to accomplish the goal.
What matters is the user's experience of the (HTML) document. The representation of "the document" can change by utilising a language like javascript that "manipulates the DOM" - and the DOM is like an instance of the HTML document, or "document session" if you will.
So in a way, no, the HTML is touched. It is positively manhandled by javascript - indirectly and in a non-persistent way. But if you want to be pedantic... we say it isn't and leave half the readers confused.
When to use javascript and when not to. It's swings and roundabouts. You need to learn (mostly from experience) when one particular tool suits the situation. It usually boils down to some core considerations:
HTML is for markup. Structure. Meaning.
CSS is for style, feel, appearance.
Javascript is for those situations where none of the above work.
And I'm neglecting to mention server-side processing with the obvious disclaimer that all processing that ought to be done in privacy is done on the server (with a programming language like PHP or Ruby for example).
Sometimes you get the grey area in-between where you can do something either way. Those situations you may ask yourself a question like... would it be processed quicker if the client (user's computer) processes it, or the server... and that's where experience comes in.
It depends on the case to decide if you should manipulate DOM directly or let the JS do it.
If you have a static html page, just do your html and hand craft the
DOM. There is no need for JS to get a hand here.
If you have a semi static html page where the user actions change
part of it - then get the JS to do the changing part.
If you have a highly dynamic html page (like single page app) - you
should get the JS to render html mostly.
Using plain JS however is not the best for you in this age of great JS evolution. Learn it -but also learn to use good libraries and frameworks which can take you to the track very fast.
I recommend you to learn Jquery and Angular 2 which make you feel like learning a super set of JS straightaway.
Short disclamer: Javascript may modify DOM content in a browser but never change original HTML served from Web server.
Modern Web is unthinkable without javascript. JS allows to make static HTML interactive and improve User Experience (UX). As any sharp tool JS can produce a masterpiece out of nearly dead page and cut throat to a blooming static content.
Everything is up to the developer.
When not to use JS
Do not use JS to deliver ever-green content to the page. Web bots (crawlers) don't run JS, and you message "I come to this world to testify to the truth" may appear "a voice of crying out of desert" and be non-indexed and thus unread.
When JS in the must
Every time your page visitor does something the page should respond with proper action (using JS or, if possible, just CSS).
This is especially important when a prospect fills in a form. To err is human so a developer via JS should help the visitor to make wrong things right. In many cases it is possible without requesting server and in even more cases the answer should come from the server. And JS is your best friend in this case.
Javascript never lives alone. Browser object is its trustful ally. Most modern browsers support XMLHttpObject A.K.A AJAX (you may remember this name from ancient Greek history) which communicates with the server without reloading the page.
The idea of AJAX which stands for Asynchronous Javascript And Xml is to send request and receive response from the server asynchronously without blocking page in the browser.
Native javascript may be difficult to understand to many beginner developers. To make thing easier there are a lot of JS libraries with jQuery being most known.
Returning to the OP's question, Should Javascript be used to modify HTML?
The answer is: It Depends.
Our goal is to let a person, similarly to how you can embed a youtube video, embed a tree of web pages on our SaaS into their own site.
The solution should be good looking, cross-browser, responsive and simple for the end user (ideally, should be search-bot friendly as well).
We are considering two primary options where the customer only needs to copy+paste a code snippet which supports embedding in a portion of the page (ex: the middle column) or full width (ex: everything under a header):
IFRAME: Let the user embed an iframe inside a div, together with a snippet of JS that would resize the iframe as the window is resized.
JS "APP": Let the user paste in a script tag to a JS script/app which would communicate cross-domain (via CORS or JSONP) with our servers.
Ideally, we would like to be able to launch full screen modals from our content.
Questions/concerns for:
IFRAME:
Can an iframe reliably update the URL of the parent’s browser window?
Can we reliably launch full screen modals from an iframe?
Can we reliably get the iframe to resize when the window is resized or iframe content changes?
JS "APP":
How significant is the overhead of dealing with properly encapsulating our app to avoid naming/library conflicts? For example, we will ideally stick to vanilla JS but if we want to use a library like Ember and a customer of ours has an Ember site.
Any non-obvious cross domain gotchas? We will be using CORS or JSONP.
We would like input on both the:
technical limitations of what’s possible to do
practical hurdles we’d have to overcome going down each path.
p.s. We’re also considering a back-up option, which is to “fake” integration, where we host the content on our site with a subdomain URL (similarly to how Tumblr lets people host their blog on something like “apple.tumblr.com”). If we go down this path we imagine letting the user theme the subdomain. We understand the pros and cons of this path. Downsides are, it’s more work for the user, and they need to keep two different sites in sync visually.
I think the best approach is to use the same approach Google and other big companies have been using for quite some time, the embedded script. It is way better looking and semantically unharmful (as an iframe could - arguably - be), and super cross-browser and simple, in fact, just as cross-browser and simple as the code that will be pushed (it can be recommended to be put in a <script async> tag, which will eliminate the need for a crafted async script and, though it won't be as full compatible, it degrades okay and will work very well on most cases).
As to the CORS, if basic cautions are taken, there's no need to worry a lot about it. I would say, though, that if you're planning to do something in Ember or Angular to be embedded, that may be a whole load of scripts/bytes that can even slow down the site/app and impact on the whole user experience, perhaps too much for a component that would be loaded like that. So whenever possible, vanilla JS should always be used in components, especially if Ember/Angular is used because of specific features like binding (specific vanilla JS codes can cover that with much less weight).
I am working on a website for a company (my first, except of my own), and i am a little confused. i know that i knew this before, but i have forgot.
i am going to create many different pages on the site and i guess that it´s not a good idea to create one new file for each page.
and i think the best way is to make one "div" for each page, in the index file, and somehow put all of then behind each other, and show one by one when i click on the right thing in the menu... how do i do this?
can i only use CSS or do i need some Java script, and how do i write the code?
very thankful for quick help! :)
You're talking about making a single HTML page that contains all of the content for a company website. It's a bad idea to build a corporate website this way, for several reasons:
Web browsers expect to navigate through a site that has multiple pages, which is why they have a location bar and forward/back buttons. Your approach breaks both of those.
This single page would be much larger and take longer to load in users' web browsers.
The SEO of the page would be poor, because its content would be hard for Google and other spiders to understand semantically. A large page with so much text would look like keyword stuffing to Google and would be penalized.
It would be difficult to keep such a page organized; making any change to anything would require you to edit a single file, so it would be harder for you to track and/or merge changes to different documents, and much harder for the company to make content changes.
Lastly, the approach is just inappropriate. You are correct that it's not too great to create one static HTML file for every page. But the solution is not to make a single web page; the solution is to use a CMS!
Wordpress is the most popular CMS in the world. It's designed for blogs but can be used for any website.
Drupal is a powerful CMS with lots of features you may not need, but it's more modern than Wordpress and may be more visually flexible.
If you don't want to use a full-fledged CMS and you feel like flexing some programming chops, you could try using an out-of-the-box MVC framework like Rails or Django, but bear in mind that those will require you to learn a little Ruby or Python.
The main thing is that you should be using server-side templates to solve the problem you have, not client-side JavaScript.
(Some very large websites do use a JavaScript-powered approach to page navigation, but these are usually web applications like Twitter. The approach is inappropriate for a corporate web presence.)
You can use Javascript to change the innerHTML of elements.
For example, create a div and give it the ID "myDiv":
<div id="myDiv"></div>
Then, when the user clicks on a button you can change "myDiv"'s innerHTML like this (by calling the function):
function show(){
document.getElementById("myDiv").innerHTML="html code here";
}
I hope I helped :-)
I am needing to a custom widget into users of my applications websites and the initial thought it that an iframe would make it SO much simpler for a few reasons:
I can use the custom framework built for the application which provides a ton of pre-built code and features that i'll be using in the widget and thus wouldn't have to recreate. Cross browser event handlers and prototyped objects are just a few of many examples.
I don't have to worry about clashing with CSS and more specifically
won't have to use inline css for every dom element I create.
Cross domain requests are not a problem because i've already built
the functionality for everything that needs to be communicated using
jsonp, so don't let that be a downside for an embedded dom widget.
The idea as of right now is to write a quick javascript snippet that is essentially a button and loads a transparent iframe above the window that is full screen. This will give me control of the entire view and also allow me to write the widget just like I would any other part of the parent application. Maintaining the same json communication, using the same styles, using the framework etc. Clicking on any part of the iframe that was is not part of the widget (which will likely load centered in the middle of the screen, and be full screen if on a mobile device) will dismiss the widget and resume the user back to their normal navigation within the website. However, they can interact with my widget while its up, just like it were an embedded portion of the website that happened to load a javascript popup.
The widget itself does communication somewhat heavily with the server. There is a few requests on load, and then as the user interacts, it typically sends a request, changes the view and then wait for another response.
All that being said, is this a bad idea, or otherwise unprofessional idea? Should I put the extra work into embedding the widget directly into the hosts DOM and rewrite all the convenient framework code? I don't have a problem doing that, but if an iframe is a more appropriate choice, then I think i'd rather that. My only limitation is I need to support down to IE8, and of course, the widget needs to be viewable on both desktop and mobile, and the widget cannot be obtrusive to the clients website.
Some good reading from another post. Although closed, it poses some decent arguments in favor of iframes.
Why developers hate iframes?
A few points that resonate well:
Gmail, live.com, Facebook any MANY other major websites on the
internet take advantage iframes and in situations where they are
used properly...well that is what they were made for.
In situations especially like mine its considered a better practice
to prevent any possible compatibility issues with a remote website I
have no control over. Would I rather use an iframe, or destroy a
persons website? Sure I can take all possible precautions, and the
likelyhood of actually causing problems on another persons site is
slim, but with an iframe its impossible. Hence why they were created
in the first place.
SEO in my situation does not matter. I am simply extending a
javascript application onto remote users websites, not providing
searchable content.
For the above reasons, I think that taking the easier approach is actually the more professional option. Iframes in general have a bit of a misconception, I think because of their overuse in ugly ways in the past, but then again tables also have that same misconception yet believe it or not, when data is best displayed in a tabular fashion, it makes sense to use...wait for it...tables. Though we do this behind css values such as display: table-cell.
For now iframes get my vote. I'll update this answer if a little further down the development road on this project, I change my mind.
I'm creating a blog, but I need box-shadows for my boxes, so I'm asking the following.
Is it good to add shadows via a)images/css or b)javascript?
I've heard that lot of people don't have javascript enabled while browsing, so is there this a problem? It would be easier and simpler to create these shadows with javascript than adding a million divs and positioning them.
EDIT: I found this page: http://www.w3schools.com/browsers/browsers_stats.asp and it says that almoset every user has js enabled.
You could use JavaScript for your layout, but the general principal that you should keep in mind is that your HTML should be semantic: the elements on the page should have a meaning; it should project a structure that goes beyond the design of the page (although that structure can certainly be used as an indcator for the design aspects as well).
When this principal is applied, using JavaScript can help with providing the style you wish to project given the semantic meaning of the page.
Also, you should check your server logs (your hosting provider should have some sort of analytics tool/report available) which should tell you what browsers and versions are being used to visit your site. With that information, you can get a good feel for the people that you are currently reaching.
If you are using some sort of analytics package (e.g. Google Analytics) then you can possibly see the delta between two periods of time for the new visitors to your site as well, and try to gauge the capability of the browsers that new users will be using when they visit your site.
A few things to consider when using JavaScript to manipulate the DOM on the front end:
If you are using JavaScript to manipulate a good deal of the content, it's going to be a client-side process, and that can slow down the rendering of your page. You might want to consider a theme/template for your blog/cms which gives you the styling that you want and is rendered through CSS on the server-side.
Search engines do not execute your JavaScript. Because of this, you want to avoid manipulating the indexable content at all costs. You want your content to be embedded in the HTML as it is sent from the server. Using AJAX or other JavaScript to manipulate certain things is fine, but when it comes to your content, unless you are stylizing it, do not use JavaScript to manipulate it
Use CSS box-shadow for nice, up-to-date browsers: http://css-tricks.com/snippets/css/css-box-shadow/ (requires no extra markup)
And for most everyone else, serve up your js solution.
You should do it the easiest way for you and allow the page to degrade gracefully for those without JS (If you think you need to consider them, as today, I don't see any point in building none JS sites or building sites for no-js users).