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.
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 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 have a question about Javascript widgets. The widget I am working on simply embeds content on a page instead of using iframes. So far it looks good. But there are cases where some users layouts are messing up the widget. For example, the widget might require a width of 300px to appear. But the parent div is set to 250px and hence the right part of the widget is cut off.
I was wondering what sort of precautions should be taken to prevent this? I was talking to the product manager who mentioned he wanted me to check the parent div elements and get the size and then show an alternate message if their size is not accurate. But again, since this is Javascript and the widget is supported in many diff browsers(including IE6), I am wondering how fail-safe this method would be? What if I need to iterate the DOM all the way up before getting a valid size? I am also worried about performance here. This extra checks would slow down the delivery of my widget content to "good users" since I am adding a layer of complexity to all users. I don't want to penalize good users just because of the few errant ones.
I am not using any sort of JS library here, so any solution should not suggest the use of one. Also, the reason for not using a library was simply not to add extra weight to the page load to deliver a widget. I understand that "jquery" for example is small, but in my case, even 24k compressed seems like an overkill for a widget delivery that contains no core code for the widget.
Has anyone dealt with such issues before? What are your solutions to these?
There are reliable ways of determining the size of an element using JavaScript. You're quite right that you may need to iterate up the tree in some cases, but the answer you get will ultimately be quite valid.
Although you don't want to directly include any library code in this project, you may consider looking at how the major libraries implement their "what's the width of this element" functions to drive your own implementation.
Beware of quirks mode too.
I'd check to see of the page has Jquery, if not load it into the page using no-conflict mode. Then use jQuery to examine the page.
See: How to embed Javascript widget that depends on jQuery into an unknown environment
I need to create a function that will produce a balloon popup in the
taskbar using javascript.
Is it possible? Whats the shortest and easiest way to do this?
or else what will be the available method..
Thanks.
The closest you could get is to make one fixed to the bottom of the viewport of the browser. You could tailor it to appear as though it were part of the windows chrome, but this does tend to annoy users, who don't appreciate attempts to 'fool' them into believing a dialogue/popup/whatever is coming from their OS when it actually isn't.
See: Jeff Atwood on the horrors of fake interfaces
Impossible from a browser. And a good thing.
eum.. no ?
Wouldn't be cross-platform anyway. Just don't try to do things outside of the browser. Internet explorer can eventually let you, the others not.
You could probably come pretty close with jGrowl. But you'll have to reset the position to bottom-right (it defaults to top-right).
The Yahoo Widget Engine (previously called Konfabulator) allowes to do so; you'll be not in a browser anymore, but in a lightweight web-based desktop application, which probably is rather what you want anyway.
Anybeast from a webpage should never ever leave it's frame/browser.
I could write this, but before I do, I wanted to check to see if there are existing solutions out there since it seems a lot of websites already do this, so I was wondering if there was a quick way to do this.
Also, I am talking about "popout" windows, not "popup" windows. All JavaScript libraries support "popup" windows, but I want ones where they originally open as "popup" windows in the same browser window, but there is also a link to open them up in a brand new browser window.
Check out Cappuccino, it's more of a windowing framework than a web 2.0 framework. It's based off of Apples Cocoa, and uses a Superset of Javascript called Objective-J. Superset meaning that any JS is valid, but it extends on the language with additional syntax that is similar to Cocoa and Objetive-C.
http://cappuccino.org
var oDiv = document.getElementById('mydiv');
var oWindow = window.open("about:blank");
oWindow.document.body.appendChild(oDiv.cloneNode(true))
You will probably also need to move stylesheets there as well.
I don"t know a framework to do that for you. But the JS code to do that might be simple.
For the in-page-popup part, just open an absolute div. If you want the div to become a real popup, open a popup window then remove your div content from the main document and append it to the popup window document (you way have to clone it because JS may not like passing around DOM nodes between different documents).
JQuery - Look for Dialog.
http://docs.jquery.com/UI/Dialog
You can customize with CSS to control the title bar, if it can be moved or resized, etc.
PS: Follow the link for an example.
you can try http://mochaui.com/demo/, it's written in mootools