More Details on IE7 Tabs
GraemeDonaldson writes "Another member of the IE dev team, Tony Schreiner, has revealed details of IE7's tabbed browsing implementation including the fact that the user will retain control over how tabs are handled." From the post: "Regarding script, there is no "target='_tab'" feature or any direct access to tabs from script beyond what is available with multiple windows today. We are working on balancing the default behavior for whether a window opened from script opens as in a new frame or a tab. Currently, windows that have been customized, such as hiding a toolbar or making the window non-resizable, will default to opening in their own standalone frame, whereas ordinary pop-up windows will open in a new foreground tab. CTRL-clicking and middle-clicking links will open those links in a background tab."
Okay, I'll admitt that I use IE. And I know it's full of bugs and glitches. Most of which I never see.
Since the tabs have been a function used in other web browsers for some time, the new mass deployment will give new reason to abuse users tabs by hijack-sites, hackers, and other undesirables. I know they say there are no commands to control tabs, but that doesn't mean they aren't tamper proof.
In esscence, will IE's incorporation of common features lead to bugs (or flaws) being found in other browsers.
Bacardi + slashdot = negative karma.
Actually, it should be like this:
On Safari and Firefox Mac:
* middle click, shift click == same as left click
* cmd-click == open link in new tab
* option-click == download link
On Firefox Win:
* ctrl-click == open link in new tab
* shift-click == download link
I just plugged in a mouse with three buttons that I haven't configured and tried.
for those interested to know more about support for application/xhtml+xml mime type, let me sum it up for you:
basically, every time something loads in your browser, several headers are sent before the content, letting the browser know what to do with it. this is how it knows to display web pages in the viewport versus downloading compressed files. specifically, xhtml pages are to be served to the browser as application/xhtml+xml. now, for xhtml 1.0, you MAY serve them as the old html4.0 way (text/html), but you SHOULD use the newer way.
xhtml1.1 doesn't allow such a variance. they SHOULD be served as application/xhtml+xml (the alternative being application/xml which would be interpreted as a straight xml file)... except IE doesn't support such a mime type, thus making it IMPOSSIBLE to correctly serve a xhtml1.1 document to any IE browser. this has severly limited the ability for the web to transform to support documents within several namespaces (such as xhtml, mathml, svg all integrated into a single web page)
for more info, see http://www.w3.org/TR/xhtml-media-types/
stick that in your pipe and smoke it microsoft