> Using the IFrame (or window.createPopup) means you're effectively re-writing a new document in a new window
No, that's not what is happening at all, the IFRAME is just a dummy element that is used to cover the SELECT, and nothing more. If you pay attention, you will see that the code neither sets the SRC attribute of the IFRAME nor writes to its contents in any way. The DIV that overlays it (in your case containing the calendar) exists in the same document as the IFRAME. This is actually a very common trick to bypass the pesky SELECT element in IE6.
var div = document.getElementById("yourMenuDiv");
var iframe = document.createElement("iframe");// set it to the same dimensions and position as the div
iframe.style.left = div.offsetLeft + "px";
iframe.style.top = div.offsetTop + "px";
iframe.style.width = div.offsetWidth + "px";
iframe.style.height = div.offsetHeight + "px";// inserting before the div displays it underneath it without having to fool with z-order
div.parentElement.insertBefore(iframe, div);
The IFRAME can overlay a SELECT element and obscure it, and the DIV in turn can overlay and obscure an iframe, but cannot do so to the SELECT itself--strange but real in IE world. Here's a simple page that will demonstrate that in IE6:
"From Internet Explorer 5 to Internet Explorer 6, This element is a windowed control and does not support the z-index attribute or zIndex property.
As of Internet Explorer 7 or later, this element is windowless and supports the z-index attribute and the zIndex property. The SELECT element does not require a strict doctype to enable windowless functionality."
Also, you don't really need to render the DIV inside the IFRAME, simply put the IFRAME underneath the hint DIV. The IFRAME covers the (windowed) SELECT, and the DIV covers the IFRAME--weird, but it works. Doing it this way requires very little code difference between IE6 and the rest.
> it wins because the web browser is ubiquitous and stable.
Bingo!
> Let's not pidgeon-hole ourselves in the AJAX ghetto before we've barely gotten started.
We got started a LONG time ago, just because a new class of device has become capable of running a browser doesn't automatically mean we have to develop a whole new application infrastructure. No, HTML+JS are not ideal, but they're here and they're the most widespread distributed application API in history, so that's what we use. Besides, the weak link are really HTML and CSS, not JavaScript, which is a very powerful language in its own right.
I'm quite sure I don't agree with that point in the article. The implication is that the "browser-basedness" of AJAX apps is what makes them unsuitable for phones, because somehow the mere fact of running inside a browser adds a lot of communications overhead--hence the solution to have custom apps on the phone. I think that's nonsense, because the amount of data travelling across the network and/or being cached on the client is mostly dependent on the design of the application. The presentation markup payload of a well designed AJAX app is a one-time initial download, and without too many fancy graphics and such can be quite compact. It's the data that the client then pulls while using the app that determines the bandwidth. I think Google maps and Flickr are poor examples really, because both deal with large amounts of data that are difficult to handle on a phone, regardless of the final consuming application.
I think the real issue with AJAX on phones are the ridiculously bad browsers that they often include. With many you'd be lucky to have full JavaScript support or the XMLHttpRequest object. How about they work on bringing those up to desktop standard before deconstructing the entire web application paradigm we've worked for a decade and a half to evolve?
> When the law starts saying I'm responsible for anything happens to an object I've sold in the future, where does it end?
You mean like warranty service? There are already strict regulations on warranty, I'm sure you have no objections to those, right? After all, if the item was delivered to you in working condition, if it breaks three days down the road, that's your own personal responsibility.
Making manufacturers responsible for recycling is a little bit like the Catholic Church and condoms for AIDS prevention: while in an ideal world people would simply abstain and AIDS wouldn't exist (and the Catholic Church would dearly love to be able to will this into reality), in our universe people are weak and their flesh even more so, and a more pragmatic approach is required to stem the spread of AIDS. Similarly, while the onus of disposing of products in an environmentally friendly way could be put on the end user, in reality an awful lot of punishment of transgressors would occur without much benefit to recycling.
There is another aspect to why it makes sense for manufacturers to be involved in this: in many industries in can lead to more optimized recycling and reuse, and also to potentially different and more reusable product ingredients that keep more of the product in the recycling loop, something the manufacturers would be less inclined to care about if they didn't have any recycling responsibilities. This can already be observed in some industries, such as the automobile industry: VW for example opened at least one disassembly plant that methodically deconstructs their vehicles for reuse, and in some instances has led to components that are more reusable.
Yeah, but the data source will still have to be of finite length, so you'll still be down to 8/10/12 etc bits per pixel per color, or something along those lines. Of course, they may come up with a variable bits-per-color data format to have finer control when there is one very dominant color.
> It's in their best interests to put a stop to it.
Yes, but there is a crucial difference between "interest" and "legal requirement". When one or more corporations can wiggle between the laws of multiple countries to avoid responsibility, culpability becomes a lot trickier to enforce. In the end a company in India might find it economically advantageous most of the time to play nice with an outsourcing partner, but when caught between a rock and a hard place (say a bigger incentive to sell out, or potentially large damage inflicted by some "bad apples" in the company) it might be very tempting for them to say "hey, your laws don't really apply to us anyway."
> You're trying to tell me that your data is safer because you have laws and accountability?
Yes, that's pretty much how it works. You're just creating a strawman by equating relative security with absolute security. No country in the world can guarantee total data security, but there are huge differences in relative security to be found in various countries. In this respect I will have to differentiate between Europe and the rest of the world, because most (western) European countries take data privacy a lot more seriously, esp. that of the private citizen. While the US likes to think of itself as top notch when it comes to data security, the general attitute amongst the population and in the business world is rather non-chalant when it comes to personal data. Private individuals are routinely asked for far more information than required to be rendered any given service. Social security numbers are given out like candy to the asking. And when crass data security breaches such as the leaking of thousands of credit card accounts hit the news, most people shrug and switch channels. If it's that bad in the US, don't even pretend that India is any better. Most of the so-called Third World (and I would include most of Eastern Europe and Russia for the purposes of this argument) don't even see data (or intellectual property for that matter) as something particularly valuable and worth getting worked up over. Some are still struggling with adequate law enforcement in the much more tangible physical world, let alone in the much more abstract world of bits and bytes.
To use an analogy: think of movie piracy in the US vs Asia. Yes, it happens in the US as well, and there are street corners in most larger towns where you can buy pirated DVDs for dirt cheap. But if you think the US laws in that respect make absolutely no difference, you obviously haven't travelled to Asia or Russia recently.
My SE T610 runs for 2-3 days in standby with BT on plus several short calls a day. But since I charge it nightly anyway, that's a non-issue. Phones that can't even standby a single day with BT on have a serious issue.
Re:My Grandfather the watchmaker...
on
Caller ID Watches
·
· Score: 1
Actually, I wish they added motion sensors to regular cell phones as well. If it receives calls while not having sensed movement for a while and you pick it up, it should alert you to the calls. I've missed plenty of calls while my phone was in my pants in the locker at the gym, it would be awfully nice if it alerted me to the calls when getting dressed afterwards.
Re:Kinda cool, but just Sony Ericsson ??
on
Caller ID Watches
·
· Score: 1
The T610 was one of the most popular Bluetooth phones in Europe. I'm still using one here in the US because it's still a nice phone, has solid BT implementation, and does just enough to be a useful phone and data tether.
> One reason for this is that once a set of GUI conventions has become established, change is disconcerting--you now > have to accustom yourself to the new "look" or to the new way that the GUI works.
Well said. I think some designers need to look up the meaning of the word "convention"--it is a contract with the user of the system for how to interact with it. Changing this contract with each iteration of the software leads to the same feelings you get when other types of contracts are changed on you without your consent.
I think Microsoft is definitely the most prominent and blatand transgressor against established GUI conventions. One particular area they've been dabbling in for a while now in Office (and also the Start menu of Windows XP) is the "learning" menu system, which hides "infrequently" used menu items to remove clutter. What this really does is to shift menus from being purely motor memory actions to requiring deliberate reading of the menus. Once you've learned that the options menu item is the last item on the Tools menu, you don't have to read the item--you just click the Tools menu and slide down to the bottom and click. Or if you're used to an item being the first menu item under the second divider, again, it requires very little concentration to perform the menu click. While these adaptive menus seem like a really good idea at first, it seems a lot of people don't consider them such after some use. Most experienced people I know immediately turn off this feature in new Office installations, and in Windows XP.
Better yet, it will spawn an entire garment hacking subculture, where you get your ad-supported clothing for free but hack it to not actually display the ads. We will get whole new generations of hacking-your-XBOX/TiVO/etc-is-immoral whiners.
> How much would you like to bet that only 10% of the U.S. population will really care?
I don't really know about that. The thing is that so much new code in the OS and the various players (and even the hardware) is more concerned with DISABLING playing content rather than with ENABLING it, that so many more things have to come together just right to make it all work than ever before. I can see this complexity leading to a VERY fragile media playback environment, where all sorts of (sometimes bizzare and obscure) conditions can interact to prevent media from playing, even under totally legitimate conditions. While Joe Consumer may be a dumb sheep that doesn't care one whit about the finer ethical and moral issues surrounding restrictive DRM, he sure is going to get pissed when "Mission Impossible V: Beyond Any Reason" doesn't play on his shiny new PC.
Slashdot Mirror
> Using the IFrame (or window.createPopup) means you're effectively re-writing a new document in a new window
No, that's not what is happening at all, the IFRAME is just a dummy element that is used to cover the SELECT, and nothing more. If you pay attention, you will see that the code neither sets the SRC attribute of the IFRAME nor writes to its contents in any way. The DIV that overlays it (in your case containing the calendar) exists in the same document as the IFRAME. This is actually a very common trick to bypass the pesky SELECT element in IE6.
Simple really:
// set it to the same dimensions and position as the div // inserting before the div displays it underneath it without having to fool with z-order
t ion>A sample select option</option></select>i frame>
var div = document.getElementById("yourMenuDiv");
var iframe = document.createElement("iframe");
iframe.style.left = div.offsetLeft + "px";
iframe.style.top = div.offsetTop + "px";
iframe.style.width = div.offsetWidth + "px";
iframe.style.height = div.offsetHeight + "px";
div.parentElement.insertBefore(iframe, div);
The IFRAME can overlay a SELECT element and obscure it, and the DIV in turn can overlay and obscure an iframe, but cannot do so to the SELECT itself--strange but real in IE world. Here's a simple page that will demonstrate that in IE6:
<html>
<body>
<select style="position:absolute;left:50px;top:80px;"><op
<iframe src="" style="position:absolute;left:100px;top:50px;"></
<input type="button" value="Click me" style="position:absolute;left:60px;top:90px;">
</body>
</html>
As you can see, the button is obscured by the SELECT where it doesn't overlay the IFRAME, but covers the SELECT where it does overlay the IFRAME.
As can be read on MSDN:
"From Internet Explorer 5 to Internet Explorer 6, This element is a windowed control and does not support the z-index attribute or zIndex property.
As of Internet Explorer 7 or later, this element is windowless and supports the z-index attribute and the zIndex property. The SELECT element does not require a strict doctype to enable windowless functionality."
Also, you don't really need to render the DIV inside the IFRAME, simply put the IFRAME underneath the hint DIV. The IFRAME covers the (windowed) SELECT, and the DIV covers the IFRAME--weird, but it works. Doing it this way requires very little code difference between IE6 and the rest.
> it wins because the web browser is ubiquitous and stable.
Bingo!
> Let's not pidgeon-hole ourselves in the AJAX ghetto before we've barely gotten started.
We got started a LONG time ago, just because a new class of device has become capable of running a browser doesn't automatically mean we have to develop a whole new application infrastructure. No, HTML+JS are not ideal, but they're here and they're the most widespread distributed application API in history, so that's what we use. Besides, the weak link are really HTML and CSS, not JavaScript, which is a very powerful language in its own right.
I'm quite sure I don't agree with that point in the article. The implication is that the "browser-basedness" of AJAX apps is what makes them unsuitable for phones, because somehow the mere fact of running inside a browser adds a lot of communications overhead--hence the solution to have custom apps on the phone. I think that's nonsense, because the amount of data travelling across the network and/or being cached on the client is mostly dependent on the design of the application. The presentation markup payload of a well designed AJAX app is a one-time initial download, and without too many fancy graphics and such can be quite compact. It's the data that the client then pulls while using the app that determines the bandwidth. I think Google maps and Flickr are poor examples really, because both deal with large amounts of data that are difficult to handle on a phone, regardless of the final consuming application.
I think the real issue with AJAX on phones are the ridiculously bad browsers that they often include. With many you'd be lucky to have full JavaScript support or the XMLHttpRequest object. How about they work on bringing those up to desktop standard before deconstructing the entire web application paradigm we've worked for a decade and a half to evolve?
After all that driving he didn't even nail his head to the floor!
Wow, I was actually going to fire off an empassioned response, until I landed on this jewel:
> I give it two more years and it will be the latest in a line of bad ideas - javascript, dynamic html, xml rpc, java applets, etc.
Move along, nothing to see. Hope that rock fits you comfy.
> When the law starts saying I'm responsible for anything happens to an object I've sold in the future, where does it end?
You mean like warranty service? There are already strict regulations on warranty, I'm sure you have no objections to those, right? After all, if the item was delivered to you in working condition, if it breaks three days down the road, that's your own personal responsibility.
Making manufacturers responsible for recycling is a little bit like the Catholic Church and condoms for AIDS prevention: while in an ideal world people would simply abstain and AIDS wouldn't exist (and the Catholic Church would dearly love to be able to will this into reality), in our universe people are weak and their flesh even more so, and a more pragmatic approach is required to stem the spread of AIDS. Similarly, while the onus of disposing of products in an environmentally friendly way could be put on the end user, in reality an awful lot of punishment of transgressors would occur without much benefit to recycling.
There is another aspect to why it makes sense for manufacturers to be involved in this: in many industries in can lead to more optimized recycling and reuse, and also to potentially different and more reusable product ingredients that keep more of the product in the recycling loop, something the manufacturers would be less inclined to care about if they didn't have any recycling responsibilities. This can already be observed in some industries, such as the automobile industry: VW for example opened at least one disassembly plant that methodically deconstructs their vehicles for reuse, and in some instances has led to components that are more reusable.
Yeah, but the data source will still have to be of finite length, so you'll still be down to 8/10/12 etc bits per pixel per color, or something along those lines. Of course, they may come up with a variable bits-per-color data format to have finer control when there is one very dominant color.
> It's a flawed analogy
Most analogies are flawed by their very nature.
> It's in their best interests to put a stop to it.
Yes, but there is a crucial difference between "interest" and "legal requirement". When one or more corporations can wiggle between the laws of multiple countries to avoid responsibility, culpability becomes a lot trickier to enforce. In the end a company in India might find it economically advantageous most of the time to play nice with an outsourcing partner, but when caught between a rock and a hard place (say a bigger incentive to sell out, or potentially large damage inflicted by some "bad apples" in the company) it might be very tempting for them to say "hey, your laws don't really apply to us anyway."
> You're trying to tell me that your data is safer because you have laws and accountability?
Yes, that's pretty much how it works. You're just creating a strawman by equating relative security with absolute security. No country in the world can guarantee total data security, but there are huge differences in relative security to be found in various countries. In this respect I will have to differentiate between Europe and the rest of the world, because most (western) European countries take data privacy a lot more seriously, esp. that of the private citizen. While the US likes to think of itself as top notch when it comes to data security, the general attitute amongst the population and in the business world is rather non-chalant when it comes to personal data. Private individuals are routinely asked for far more information than required to be rendered any given service. Social security numbers are given out like candy to the asking. And when crass data security breaches such as the leaking of thousands of credit card accounts hit the news, most people shrug and switch channels. If it's that bad in the US, don't even pretend that India is any better. Most of the so-called Third World (and I would include most of Eastern Europe and Russia for the purposes of this argument) don't even see data (or intellectual property for that matter) as something particularly valuable and worth getting worked up over. Some are still struggling with adequate law enforcement in the much more tangible physical world, let alone in the much more abstract world of bits and bytes.
To use an analogy: think of movie piracy in the US vs Asia. Yes, it happens in the US as well, and there are street corners in most larger towns where you can buy pirated DVDs for dirt cheap. But if you think the US laws in that respect make absolutely no difference, you obviously haven't travelled to Asia or Russia recently.
My SE T610 runs for 2-3 days in standby with BT on plus several short calls a day. But since I charge it nightly anyway, that's a non-issue. Phones that can't even standby a single day with BT on have a serious issue.
Actually, I wish they added motion sensors to regular cell phones as well. If it receives calls while not having sensed movement for a while and you pick it up, it should alert you to the calls. I've missed plenty of calls while my phone was in my pants in the locker at the gym, it would be awfully nice if it alerted me to the calls when getting dressed afterwards.
The T610 was one of the most popular Bluetooth phones in Europe. I'm still using one here in the US because it's still a nice phone, has solid BT implementation, and does just enough to be a useful phone and data tether.
> One reason for this is that once a set of GUI conventions has become established, change is disconcerting--you now
> have to accustom yourself to the new "look" or to the new way that the GUI works.
Well said. I think some designers need to look up the meaning of the word "convention"--it is a contract with the user of the system for how to interact with it. Changing this contract with each iteration of the software leads to the same feelings you get when other types of contracts are changed on you without your consent.
I think Microsoft is definitely the most prominent and blatand transgressor against established GUI conventions. One particular area they've been dabbling in for a while now in Office (and also the Start menu of Windows XP) is the "learning" menu system, which hides "infrequently" used menu items to remove clutter. What this really does is to shift menus from being purely motor memory actions to requiring deliberate reading of the menus. Once you've learned that the options menu item is the last item on the Tools menu, you don't have to read the item--you just click the Tools menu and slide down to the bottom and click. Or if you're used to an item being the first menu item under the second divider, again, it requires very little concentration to perform the menu click. While these adaptive menus seem like a really good idea at first, it seems a lot of people don't consider them such after some use. Most experienced people I know immediately turn off this feature in new Office installations, and in Windows XP.
Give me a moment and I will find a correlation between music piracy and e-coli in spinach.
Actually, they got the number wrong. It's supposed to be 88,ooo million billion jobs a year in the Greater London area alone.
Better yet, it will spawn an entire garment hacking subculture, where you get your ad-supported clothing for free but hack it to not actually display the ads. We will get whole new generations of hacking-your-XBOX/TiVO/etc-is-immoral whiners.
> I explained that my solution was asymptotically faster
Wow, you probably had them at "asymptotically", at which point they probably all rushed out of the room to consult dictionary.com.
> Mine did, sigh... and I got the job, sigh again.
> [...] Also, by the way, the snobbery at Microsoft is real.
Shut up, really? 'Cause I was gettin the warm fuzzies at first there.
> How much would you like to bet that only 10% of the U.S. population will really care?
I don't really know about that. The thing is that so much new code in the OS and the various players (and even the hardware) is more concerned with DISABLING playing content rather than with ENABLING it, that so many more things have to come together just right to make it all work than ever before. I can see this complexity leading to a VERY fragile media playback environment, where all sorts of (sometimes bizzare and obscure) conditions can interact to prevent media from playing, even under totally legitimate conditions. While Joe Consumer may be a dumb sheep that doesn't care one whit about the finer ethical and moral issues surrounding restrictive DRM, he sure is going to get pissed when "Mission Impossible V: Beyond Any Reason" doesn't play on his shiny new PC.
> The headline, however, was just too good to pass up!
Especially following a NASA article.
> There's also a healthy supply of free clicks from the likes of me
Now if we could only somehow harvest that energy before it is wasted in The Tubes.
Rats, I knew I should have applied the Smoke-And-Mirrors test!