If you follow the link you gave, you'll find the "align" attribute listed in the "Attributes defined elsewhere" section. (Although, as has been pointed out above, anybody using presentational attributes such as "align", which has been deprecated for 8 years now, really needs to realise that the technology has moved on.)
That's not something new. I can host a web page which uses a JavaScript setTimeout trigger to repeatedly download your site's homepage into an Image object - it doesn't matter that it's not an image. If I then get that page Slashdotted, all Slashdot's readers who RTFA and have JS enabled will, for the time it takes to read my page, be participating in a DDOS attack against your website. This has been possible since Netscape 3 in 1996, and doesn't involve Ajax at all. As a number of commenters to TFA and here on/. have pointed out, there's nothing in there specifically to do with a threat posed solely by the use of Ajax.
I'd love a Firefox extension that lets you quickly bring up a list of cookies applicable only to the domain of the currently-viewed page, so I can edit/delete them.
There's a facility for doing this in Chris Pederick's excellent
Web Developer extension.
It lets you view cookies for where you currently are by both domain and path, clear them, add them, disable cookies from third-party domains like advertisers, etc.
If you don't want the whole Web Developer toolbar (which may have a lot of stuff you don't need) you can use the standard Firefox toolbar manager dialog to put the Cookies menu on one of your existing toolbars.
...any embeded auto playing content...will require activation before playing. So for example, if you go to a page that has a stock ticker applet in it, instead of it automatically scrolling the current stock market stats, you will have to click it to start.
No, that's not the case. The change affects interaction with the embedded object, but any behaviour the object has that doesn't require user interaction will not be affected. For example, if the ticker had a menu allowing you to select which stock market's prices it displayed, you would have to click once on the component to enable interaction, and you could then actually make your selection with your second click; after that it would just work as expected, for the duration of that visit to the page.
As the initial display of the default set of prices doesn't require user interaction, it wouldn't be affected. Similarly, Flash movies (which is what those vastly irritating ads are) will just play, but if they have interactive controls, you will have to click once on them before you can interact with their controls.
As for why other browsers aren't affected: Eolas hasn't sued them - yet. If they get sued they'll have to do something similar.
You're lucky she pays attention when you're together. A few years ago my then GF and I were in the pub catching up on each other's day; as I was replying to a question she'd asked me, she picked up her cell phone, called a friend and started talking to them about some totally unrelated matter when I was in mid-sentence. Then she wondered why I got pissed off...
(I'm aware that these effects are caused by invalid markup, and that other browsers also have problems agreeing on what to do; but the simple fact is that the DOM is defined as a tree, and IE/Win internally uses a data structure which is not a tree. So it's difficult to see how its DOM implementation can ever work properly.)
There's always the IE Developer Toolbar from Microsoft. It's Beta 2 (but stable on my machine - YMMV) and isn't quite as wonderful as the FF extension, but it's still pretty helpful when you're trying to work out what on earth IE thinks it's playing at.
If you RTFA you'll find that he was getting many of these messages because dumb techs at various companies testing messaging services were deliberately sending their stuff to his null@ email address on the incorrect assumption that there was no such user. If they'd had a clue, they would have used something RFC2602-compliant - null@example.com, for example. That's what it's for. (Personally I don't see why he shouldn't have null as a username, if he wants. It's not as if it gives him admin rights or anything.)
In at least one case it was faults in the services sending the messages that were addressing them to him:
Messages from both the Princeton Review Service and Pill Phone were accidentally sent to Bubrouski's phone...
Messages without a "To" address were not delivered by the service. However, because of a programming flaw in the client server software, messages with an invalid address, such as a blank space, were translated as "Null," and wound up on Bubrouski's phone.
I don't suppose there's much Verizon can do to filter out stuff that's actually addresed to him. Other services were doing a similar thing:
An eMbience spokeswoman said that Bubrouski's vText account was the same as an account used by engineers for internal testing.
So it looks like clueless techs outside of Verizon are responsible for a lot of his problems. This is why, if I have to send emails to some/dev/null address, I either create a dummy account on a domain that I control, or (in a pinch) use the example.com domain. Just sending messages to a real domain owned by somebody else because you assume they won't have an account with a particular user name is just dumb and inconsiderate.
No, that's the nonsense spewed out by Google. If you go to Drew's own post on the subject at All in the <Head> you'll find some very nice valid code, complete with print stylesheet.
(The only reason I posted a link to Drew's Google page was that I'd read about this on his site just before it appeared here at/. and had looked under the hood of his example page. As he says, "Signup was painless, editing was painless, publishing was painless. The resultant markup? Painful.")
I've done WYSIWYG Content Management Systems for several clients using just JavaScript, DOM manipulation and XMLHttpRequest, with your choice of server-side stuff (ASP, PHP, JSP... whatever). Worked in IE5.5 and 6, Firefox and more recent versions of Opera; produced W3C standards-compliant code; even cleaned up the garbage that results if people paste in Word docs. It's really not that difficult, which is why I think it's pretty laughable that this is the best Google have managed.
The markup seems to be striving to be as bad as Front Page. Somebody should tell them that <font> elements are very GeoCities 1997, that <p> elements can't be nested, and that creating a bunch of <div class="foo"> elements isn't that much better than nested tables. I thought Google could afford to hire competent people?
There seem to be some pretty stupid statements in there too, such as this from the "Background of the Invention" section:
Programs such as Microsoft's Visual Basic® provide website designers with the ability to create websites more quickly by allowing designers to create websites graphically instead of by coding primarily in HTML.
What on earth is that supposed to mean? If they'd said "Microsoft Visual Basic.NET" it might have made some sense, as you can use that to create ASP.NET stuff, but to the best of my knowledge Plain Old Visual Basic allows you to create Windows apps and COM components. Not a website in sight.
function Test() { while(true) setTimeout('Test()', 100); }
The attempt was to get a sleep function going...
Creating a non-terminating loop is not the way to get a sleep function going in JavaScript. What your code is doing is going round in a loop which never terminates (while(true)), setting timeouts. As JavaScript interpreters are single-threaded, and your loop never exits, the timeouts are never handled - although if they had been, they would have just done the same thing.
(This single-threading thing seems to catch out a lot of people, for some reason.)
Just test your condition, and if it's not satisfied, set the timeout and exit. In this case, as the previous poster has pointed out, you would be better off using the image onload event anyway. As a general rule, event-driven code beats timer-based polling every time.
Slashdot Mirror
Frogger was by Konami/Sega (1981). Donkey Kong was by Nintendo (also 1981). See Videotopia's arcade games page for more.
Maybe IT realised that if everybody in the company used Firefox, there'd be fewer ActiveX catastrophes to clear up and IT could be downsized.
I do a lot of development on a Mac (in Eclipse, XCode and SubEthaEdit) and I've never found it necessary to look at the Finder for 10 minutes.
Similarly, when developing on a Windows box, I spend very little time gazing upon Windows Explorer.
What exactly is your strategy for development? Browsing the file system does not a developer make.
And whoops, you already corrected yourself while I was off checking my facts. Oh well, serves me right for showing off :-)
If you follow the link you gave, you'll find the "align" attribute listed in the "Attributes defined elsewhere" section. (Although, as has been pointed out above, anybody using presentational attributes such as "align", which has been deprecated for 8 years now, really needs to realise that the technology has moved on.)
When they get rid of Preview?
They still list books by my father that have been out of print since the late 70s and early 80s, so apparently not.
That's not something new. I can host a web page which uses a JavaScript setTimeout trigger to repeatedly download your site's homepage into an Image object - it doesn't matter that it's not an image. If I then get that page Slashdotted, all Slashdot's readers who RTFA and have JS enabled will, for the time it takes to read my page, be participating in a DDOS attack against your website. This has been possible since Netscape 3 in 1996, and doesn't involve Ajax at all. As a number of commenters to TFA and here on /. have pointed out, there's nothing in there specifically to do with a threat posed solely by the use of Ajax.
There's a facility for doing this in Chris Pederick's excellent Web Developer extension. It lets you view cookies for where you currently are by both domain and path, clear them, add them, disable cookies from third-party domains like advertisers, etc.
If you don't want the whole Web Developer toolbar (which may have a lot of stuff you don't need) you can use the standard Firefox toolbar manager dialog to put the Cookies menu on one of your existing toolbars.
What other half? 100% is "more than a half".
No, that's not the case. The change affects interaction with the embedded object, but any behaviour the object has that doesn't require user interaction will not be affected. For example, if the ticker had a menu allowing you to select which stock market's prices it displayed, you would have to click once on the component to enable interaction, and you could then actually make your selection with your second click; after that it would just work as expected, for the duration of that visit to the page.
As the initial display of the default set of prices doesn't require user interaction, it wouldn't be affected. Similarly, Flash movies (which is what those vastly irritating ads are) will just play, but if they have interactive controls, you will have to click once on them before you can interact with their controls.
As for why other browsers aren't affected: Eolas hasn't sued them - yet. If they get sued they'll have to do something similar.
Since this is Slashdot, you should have guessed that she cleared off with some other guy years ago :-)
You're lucky she pays attention when you're together. A few years ago my then GF and I were in the pub catching up on each other's day; as I was replying to a question she'd asked me, she picked up her cell phone, called a friend and started talking to them about some totally unrelated matter when I was in mid-sentence. Then she wondered why I got pissed off...
New here?
DOM Level 1 Core states that "The DOM presents documents as a hierarchy of Node objects". As IE/Win is capable of creating a node with two parents and creating a node whose parent is the child of one of its siblings - that is, a non-hierarchical structure - it can hardly be claimed that it has anything to teach anybody in this area.
(I'm aware that these effects are caused by invalid markup, and that other browsers also have problems agreeing on what to do; but the simple fact is that the DOM is defined as a tree, and IE/Win internally uses a data structure which is not a tree. So it's difficult to see how its DOM implementation can ever work properly.)
There's always the IE Developer Toolbar from Microsoft. It's Beta 2 (but stable on my machine - YMMV) and isn't quite as wonderful as the FF extension, but it's still pretty helpful when you're trying to work out what on earth IE thinks it's playing at.
It's
There's no such method as
in DOM (which, contrary to what the reviewer says, stands for Document Object Model, not Dynamic Object Model).
If you RTFA you'll find that he was getting many of these messages because dumb techs at various companies testing messaging services were deliberately sending their stuff to his null@ email address on the incorrect assumption that there was no such user. If they'd had a clue, they would have used something RFC2602-compliant - null@example.com, for example. That's what it's for. (Personally I don't see why he shouldn't have null as a username, if he wants. It's not as if it gives him admin rights or anything.)
In at least one case it was faults in the services sending the messages that were addressing them to him:
I don't suppose there's much Verizon can do to filter out stuff that's actually addresed to him. Other services were doing a similar thing:
So it looks like clueless techs outside of Verizon are responsible for a lot of his problems. This is why, if I have to send emails to some /dev/null address, I either create a dummy account on a domain that I control, or (in a pinch) use the example.com domain. Just sending messages to a real domain owned by somebody else because you assume they won't have an account with a particular user name is just dumb and inconsiderate.
Moral Panic
No, that's the nonsense spewed out by Google. If you go to Drew's own post on the subject at All in the <Head> you'll find some very nice valid code, complete with print stylesheet.
(The only reason I posted a link to Drew's Google page was that I'd read about this on his site just before it appeared here at /. and had looked under the hood of his example page. As he says, "Signup was painless, editing was painless, publishing was painless. The resultant markup? Painful.")
I've done WYSIWYG Content Management Systems for several clients using just JavaScript, DOM manipulation and XMLHttpRequest, with your choice of server-side stuff (ASP, PHP, JSP... whatever). Worked in IE5.5 and 6, Firefox and more recent versions of Opera; produced W3C standards-compliant code; even cleaned up the garbage that results if people paste in Word docs. It's really not that difficult, which is why I think it's pretty laughable that this is the best Google have managed.
The markup seems to be striving to be as bad as Front Page. Somebody should tell them that <font> elements are very GeoCities 1997, that <p> elements can't be nested, and that creating a bunch of <div class="foo"> elements isn't that much better than nested tables. I thought Google could afford to hire competent people?
Drew McLellan has knocked together a page in which all of the above flaws can be seen.
There seem to be some pretty stupid statements in there too, such as this from the "Background of the Invention" section:
What on earth is that supposed to mean? If they'd said "Microsoft Visual Basic.NET" it might have made some sense, as you can use that to create ASP.NET stuff, but to the best of my knowledge Plain Old Visual Basic allows you to create Windows apps and COM components. Not a website in sight.
Creating a non-terminating loop is not the way to get a sleep function going in JavaScript. What your code is doing is going round in a loop which never terminates (while(true)), setting timeouts. As JavaScript interpreters are single-threaded, and your loop never exits, the timeouts are never handled - although if they had been, they would have just done the same thing.
(This single-threading thing seems to catch out a lot of people, for some reason.)
Just test your condition, and if it's not satisfied, set the timeout and exit. In this case, as the previous poster has pointed out, you would be better off using the image onload event anyway. As a general rule, event-driven code beats timer-based polling every time.