I just discovered pjax and I find it completly awesome. If I understand it correctly, it's AJAX, but without its problems (fully degradable, the URL and the title of the page is changing when using it, compatible with search bots...).
But I am very curious as how it's working ? How can we change the URL in the browser, without the page to change... I read somewhere you need Firefox 4, is that a new "web" feature then ?
It's just a wrapper around "$.ajax()". It uses the new "pushState" and "replaceState" methods to manipulate the history.
Also see this SO question too, and notably the link to History.js.
edit — note that by writing "just a wrapper" I do not mean to belittle the pjax plugin. I simply meant that it's not some radical new functionality; it's still XMLHttpRequest under the covers.
Related
I want a single online web page for my bookmarks. The page should include small windows which opens the following pages:
Fizy, Facebook, Guardian.
There should also be a button for adding a new window with an URL text input.
Here's an illustration of how the page should look: http://i54.tinypic.com/2hrkb48.jpg
I've built a version of this at http://bit.ly/heqEd1, but as you may see, it uses iframes under javascript windows, which can not open frame-breaking sites (like fizy.com), or Facebook.
I'll make the research and but I am not sure how to proceed. Any solution will be accepted, like HTML5, XUL, Flex, AJAX or others. A solution with a local installation(like a Firefox extension) is not preferred, but still be ok.
Note: Piro Sakura has built a Firefox extension called split-browser. There's an element of the project called "subbrowser". An AJAX window that can show a subbrowser MAY solve the problem. I know the page will only be available from Firefox, but that is ok. (Again, a solution without an installation is preferred)
Any suggestions? How should I proceed? What should I learn? Is this possible?
Thanks.
I think you should use a Javascript with iFrames to do this. I'm not too sure what you're trying to accomplish with this, but it should be possible. As for which framework you'll use, it's up to you, but there will be a lot of custom code needed to implement this.
You can make multiple draggable windows in FLEX same as you have in you app
Please check sample as Starting point Movable/Draggable window and its demo
also u knows JS-DESKTOP lib with little customization to achieve that one of them are
jsdesk
sonspring-JQuery based
also you can do this using
Hopes that helps
I recall reading somewhere that in HTML5 it was no longer okay to use target="_blank" in HTML5, but I can't find it now.
Is it alright to continue to use target="_blank"?
I know it's generally considered a bad idea, but it's by the easiest way to open a new window for something like a PDF, and it also doesn't require you to rely on JavaScript.
It looks like target="_blank" is still alright. It is listed as a browsing context keyword in the latest HTML5 draft.
It is ok to use target="_blank"; This was done away with in XHTML because targeting new windows will always bring up the pop-up alert in most browsers. XHTML will always show an error with the target attribute in a validate.
HTML 5 brought it back because we still use it. It's our friend and we can't let go.
Never let go.
Though the target="_blank" is acceptable in HTML5, I personally try never to use it (even for opening PDFs in a new window).
HTML should define meaning and content. Ask yourself, “would the meaning of the a element change if the target attribute were removed?” If not, the code should not go in the HTML. (Actually I’m surprised the W3C kept it… I guess they really just can’t let go.)
Browser behavior, specifically, interactive behavior with the user, should be implemented with client-side scripting languages like JavaScript. Since you want the browser to behave in a particular way, i.e., opening a new window, you should use JS. But as you mentioned, this behavior requires the browser to rely on JS. (Though if your site degrades gracefully, or enhances progressively, or whatever, then it should still be okay. The users with JS disabled won’t miss much.)
That being said, neither of these is the right answer. Out there somewhere is the opinion that how a link opens should ultimately be decided by the end user. Take this example.
You’re surfing Wikipedia, getting deeper and deeper into a rabbit hole. You come across a link in your reading.
Let’s say you want to skim the linked page real quick before coming back. You might open it in a new tab, and then close it when you’re done (because hitting the ‘back’ button and waiting for page reload takes too long). Or, what if it looks interesting and you want to save it for later? Maybe you should open it in a new background tab instead, and keep reading the current page. Or, maybe you decide you’re done reading this page, so you’ll just follow the link in the current tab.
The point is, you have your own workflow, and you’d like your browser to behave accordingly. You might get pretty frustrated if it made these kinds of decisions for you.
THAT being said, web developers should make it absolutely clear where their links go, what types and/or formats of sources they reference, and what they do. Tooltips can be your friend (unless you're using a tablet or phone; in that case, specify these on the mobile site). We all know how much it sucks to be taken somewhere we weren't expecting or make something happen we didn't mean to.
it's by the easiest way to open a new window for something like a PDF
It's also the easiest way to annoy non-Windows users. PDF open just fine in browsers on other platforms. Opening a new window also messes up the navigation history and complicates matter on smaller platforms like smartphones.
Do NOT open new windows for things like PDF just because older versions of Windows were broken.
Most web developers use target="_blank" only to open links in new tab. If you use target="_blank" only to open links in a new tab, then it is vulnerable to an attacker. When you open a link in a new tab ( target="_blank" ), the page that opens in a new tab can access the initial tab and change its location using the window.opener property.
Javascript code:
window.opener.location.replace(malicious URL)
Prevention:
rel="nofollow noopener noreferrer"
More about the attribute values.
While target is still acceptable in HTML5 it is not preferred. To link to a PDF file use the download attribute instead of the target attribute.
Here is an example:
<a href="files/invoice.pdf" download>Invoice</a>
If the original file name is coded for unique file storage you can specify a user-friendly download name by assigning a value to the download attribute:
Invoice
Keep in mind that while most modern browsers support this feature some may not. See caniuse.com for more info.
It sure is!
http://www.w3.org/TR/2010/WD-html5-20100624/text-level-semantics.html#the-a-element
I think target attribute is deprecated for the <link> element, not <a>, that's probably why you heard it's not supposed to be used anymore.
You can do it in the following way with jquery, this will open it in a new window:
<input type="button" id="idboton" value="google" name="boton" />
<script type="text/javascript">
$('#idboton').click(function(){
window.open('https://www.google.com.co');
});
</script>
I've read how the anchor tag is holy, it should not be used with javascript:
Popup
that it should ONLY be used for a link to another page:
Take me over there
So what is the proper use of the anchor tag with javascript? Should I be using:
Energize!
or some other variant? I'm somewhat confused by different views on the subject. Also is it only SEO that I should be worried about if making the href a javascript piece? Or is it more of a proper web standards compliance deal?
Thoughts? Hopefully I'm not the only one confused.
You are not alone Jakub; even the biggest WWW companies use different approaches.
However based on experiences since Netscape days I wouldn't use :
Popup
which can make some troubles on some browsers, like opening an empty page or breaking the event order on the current page.
However;
Energize!
or;
Link
don't make a serious trouble and are ok to use. Note that the prior one may reset the scroll to the top.
You should use meaningful link targets and unobtrusive javascript wherever possible, but this is not always possible in real life examples. It's not a defined standard, but a method highly agreed by most of the web developers.
When it comes to standards, there is one related with this situation:
You should consider using a 'button' for inputs which doesn't really send the visitor to a page, but does an operation. This is also important for SEO.
As #Sime says (and it should be an answer really), it is considered "bad practise" to now directly reference javascript in any HTML object. So in these cases you attach the event using something like jQuery using the concepts laid out in "unobtrusive javascript".
As you mention another consideration is SEO and accessibility. If SEO is important to your site, make sure that the site is fully navigable using just standard links. Again you can manage this using "unobtrusive javascript", etc.
I've always gone with using an anchor as normal (i.e. specify either an alternate url that is another location where the user could perform what's being done through javascript, or use javascript:void() / #) then use the onclick event for anything you want executed.
You could also use a <span> if you're that worried about conformance, just would need to perhaps style it (change cursor, perhaps color as well) to make it visually obvious you're making it an action.
I think Facebook is the best-case example. Almost all of their links are javascript tied in, but they also have a "backup" page for those that either have disallowed javascript or don't have it (the later, in this day and age, being far less common). Take a look at a module that reacts like you'd like yours to and see how they've done it. They also invested a bunch of work in best-practices that you can benefit from.
If anything, you should bind your anchor links to javascript methods only by using unobtrusive javascript like Paul mentioned.
This means, using separation of concerns and leaving your markup being just that, html markup:
<a id="Jolter">Energize!</a>
and later
<script type="text/javascript">
$(document).ready(function(){
$("#Jolter").click(function(){
// doStuffHere ...
});
});
</script>
Ajaxify is quite a well known jQuery plugin. But I just used Chrome and try this page:
http://max.jsrhost.com/ajaxify/demo.php
for the New v2 features: History & Bookmarking. When I click on Link 1, 2, and 3, and click the back button on Chrome, the content is not refreshed. So for now, this feature doesn't work on Chrome? Is it because the newest Chrome doesn't work well with it, but previous version of Chrome did?
I dont have the complete answer, but I can give you a start, as I am attempting to make it work as we speak..
The newest jquery.history.js file does work in chrome:
http://www.serpere.info/jquery-history-plugin/samples/ajax/
and, not to be putting down on ajaxify, I have used it for years, but I sometimes think it has been a bit of a crutch for me, not really learning the simplicity of ajax myself since 'Max' did such a sweet job with ajaxify itself.
I am currently just utilizing that little ajax demo from the history.js site itself, for my needs, its working just fine..but I am still trying to get ajaxify back..
It really seems simple, ajaxify is using the old history file, and a history.fixed.js file, and the both use the old style of historyInit() instead of the new history.init(), I spent a few minutes, ok hours, trying to get it to work, but could not, I am gonna give it a try again, but have just put in a email to 'Max' from ajaxify per his site:
http://max.jsrhost.com
but it didnt seem to send..
I will keep you posted!
(hats off to stackoverflow!! thank you thank you thank you for being you!!)
I have a site with anchor navigation (like gmail, when the anchor value changes a new content for a page is loaded with ajax). In Firefox, when I change the anchor (with js or with a page) a new item in the history is created and works perfectly. But in IE6 it doesn't stores this new item and the back button doesn't work as expected.
Is there anyway to add this new item using javascript?
This is possible because gmail does it but I don't know how it does it.
I've done a lot of work with history and using the hash. Almost all of the existing history plugins have some sort of gap in them. The one I've used that's pretty close to perfect is this one which is a jQuery plugin:
http://www.mikage.to/jquery/jquery.history.js
It was updated in March of this year handles IE 8 issues and it also deals with IE6 pretty successfully. One thing I've noticed is that IE really hates having ? in the hash after the #. It stops properly handling the hash when the ? is present. Even this one I think needs a little patch for the ?, I really need to send that along to Mikage. The way to handle this is instead of using location.hash in the plugin when referencing the hash, use this function:
function getHash(loc) {
loc = loc.toString();
if (loc.indexOf("#") != -1)
return loc.substring(loc.indexOf("#"));
else return "";
}
So in those spots where you need the hash, pass location the to function...
getHash(location)
...instead of using location.href. But note that for IE, because it's using the iframe, you want to use iframe.location instead.
getHash(iframe.location)
Yahoo's Bug
You can see that Yahoo doesn't gracefully handle ?'s in IE when looking at this URL:
http://developer.yahoo.com/yui/examples/history/history-tabview.html#tabview=tab1?7236471234
It should just ignore the non-existent module, (which it does for other names which have no ?'s in them). But it raises a JavaScript error when a ? is in the URL.
(I will extend this list in a moment)
Really Simply History
Frankly, it's primary issue seems to be it's gone dormant. I've experienced this issue and just didn't want to dig through it:
Also, even though no changes appear to
take place on the page while I travel
backward through the history, the back
functionality will return once I hit
the pages that I had been navigating
before the one using RSH. So, if I
clicked on four links in the RSH page,
back functionality will return after
I have clicked on the back button four
times. I hope that makes sense.
I think you may have a different problem. IE6 certainly handles # links in history as it should for me on any given test page, so I believe either you have broken this in some way or you have a bug with your particular version of IE.
I suggest you try a few different copies and versions of IE6 on other machines to rule out the latter, and then try simplifying your code and rebuilding it to see if and when the problem appears. Turning off JS may (html depending) be a fast way to test this.
If all else fails I suggest you look at Really Simple History which (last time I checked) solves almost all JS/history problems you can throw at it.
Yahoo has a history manager too.