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>
Related
Does anyone know how to open new with specific size?
brackets object does not contain any function to do that - there's only 2 brackets.app and brackets.fs object. Also if you try to open new window with window.open("http://stackoverflow.com","some title","width=500,height=500"); it won't set the window size.
Any ideas/suggestions?
It looks like a bug in brackets-shell that the size you specify is getting ignored. (It could also be bug in CEF, the underlying Chromium wrapper that brackets-shell uses, but this implies it normally works in vanilla CEF – I'm guessing it's broken by the brackets-shell code that remembers your last window size across launches).
However, it's not a good idea to open an arbitrary website inside the Brackets shell itself. For one thing, you won't get back/forward buttons, or an address bar, or any of the other standard browser functionality. If you want to open an external website, use NativeApp.openURLInDefaultBrowser() instead (though just like clicking a link in any other app, you won't get to pick the window size). Or if you're building some UI that's more like a Brackets feature (not a remote URL), then it'd be much easier to use in-window popups instead – see the Dialogs API.
That is how you open a new window, and set the size. I would assume you are coming across something else in your code, that is causing an error that you are not seeing.
Try binding it to a event call, like during a click event. Posting the code this applies to will help.
I'm guessing it's broken by the brackets-shell code that remembers your last window size across launches
Can anyone point to this code so I can take a look at it? Just get me close...
I have a page with numerous links to several external applications. The requirement is to have all the applications launch into a new window--but ONLY ONE new window. In other words if the user goes back go the link page any new launch needs to go to just the same one (already launched) window.
Is there no way to use basic HTML to do this or do I have to use javascript? target="_blank" or target="_new" obviously launches a new window with each click. I'm in kind of a weird environment here so I can't use JQuery, and a lot of added scripts tend to conflict with whats going on, so basic HTML would be ideal.
Just wanted to be sure I wasn't missing something and that this can't be done with just HTML. Suggestions appreciated.
Thanks!
You can use target="myexternalapplications" to create or reuse a window with the name "externalapplications". For target, the values _blank, _top are just specials.
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>
I have many browser windows, opened from JavaScript. And I want to manage them - place cascade, tile and resize them all at the same time. Are there any libraries that can help me?
In the past I would have just used the DOM standards documentation to figure out what I can do as a starting place. www.w3.org/TR/Window/
If you are looking for a simple library that you can use, which will work well across browsers I would take a look at jquery. http://jqueryui.com/
I really don't know if JavaScript is allowed to access anything besides the window it is currently running in. Just think about the different browser implementations e.g. when a browser always opens a new tab instead of a window (you can't resize and place them), or opens it as a child window inside the application (as Opera does) etc. Just because of that I don't think it is possible in a proper way.
If you really need a more sophisticated JavaScript window manager you might want to take a look at ExtJS. It generally gives you move control over your entire user interface.
I'm trying to use something like jQuery biggerlink or just simple window.location for making bigger and more accessible links. What I'm wondering is what happens with SEO in these cases — I have anchor link in the containing element, but does Google penalize such actions since I'm not really clicking on link. Also, are there any other solutions (besides CSS positioning) which could be better than this one? Thanks.
Setting window.location from script will not be spotted by search engines (Google has detection for simple document.write additions but this won't catch any of the more advanced DOM scripting stuff). It's also bad for usability: all the usual browser controls you get for links, like middle-click-for-new-tab, right-click-copy-location or bookmark stop working.
biggerlink avoids the SEO issue by keeping the correct <a href> markup in the HTML, and adding extra click handling over the top of that. (The ‘bigger’ parts of the biggerlinks still don't respond to eg. middle-click, but the ‘native’ parts do.) As long as you keep <a href> in an appropriate place you don't have to worry about search engines.
I'm not at all sure this stuff is necessary. The effects I've seen biggerlink do could easily be done using links with ‘display: block;’ and occasional workarounds like multiple links when you want to do things like headings inside the links. Sure it's a little more markup, but it's a lot less scripting and then all links respond in the expected way links usually do.
This doesn’t have similarly completion and code syntax to the Meta Refresh tag, although they perform alike wherever the Meta tag refresh and the JavaScript redirect occurs on the customer surface, sense at the web browser point.
<script type="text/javascript"> window.location = "http://www.example.com/path/file.html" </script>
This can be located wherever inside the HTML basis code and is most likely used more than Meta tag Refresh for encoding purpose delays seeing as in JavaScript you can make use of a lot additional other scripting include the window.location function. While this isn’t best for SEO as search engines usually ignore JavaScript code. In the recent years, Google reads javascript and talk about it’s headlell browser technology including GoogleBot crawling.
Search engines generally don’t interpret JavaScript, they just read what your HTML markup says. So your SEO attempts will be overlooked.