Well, I agree with most other posts here: from my experience, problems with semicolons or optional curly braces are countlessly more frequent than indenting problems.
But I think nobody remembered to mention this: your comparison is not valid. Dedenting too soon is not the same as failing to close a block, but rather the same as closing it too early. And that is also a runtime error, just with a different syntax.
...you don't have to rearrange everything when you include a new capture. This can be quite useful if your regular expression is somewhat complex and keeps changing, or if you'd like to use more than one regular expression (which match the captures in a different order) with the same piece of code.
I don't normally use named captures, but sometimes I fall into the situation I just described.
I just checked: though.rar files do support solid archiving, it is not enabled by default in the WinRAR archiving options.
From my experience, WinRAR (when producing.rar files, of course) provides the best compression-to-compression-and-extracting-time ratio. 7z files, when smaller than.rar files, do not show any significant advantages, while taking a considerably longer time to compress and decompress. Bz2 really excells at raw uncompressed data (like pure text,.bmp and.wav files), but operates quite slowly and tends to give less satisfactory results if the data already has some kind of compression on its own. Zip (and gzip) are quite fast, but don't compress as much as the former methods.
In the end, as much as I like open-source, I still use.rar for most of my archives. But 7zip is my favorite self-extracting generator.
If people had stuck with the original version of HTML and nothing else then would we have seen the rise of asp/jsp/php etc?
ASP, JSP and PHP have nothing, absolutely nothing to do with what version of HTML you're using (or if it ever changes). HTML is a markup language, they're server-side programming languages (or frameworks/toolkits, in some cases). Their point compared to common CGI (or other server-side page generation methods) is that they merge nicely with HTML, but they could merge with pretty much anything. Even if the web were in plain text with menus (like telnet), there would be a need for easy dynamic content generation, and such tools would eventually appear.
That said, some standards should never have been broken. I can remember when Flash really was optional and when I could go on any computer and not worry about the Internet because popups, viruses etc. were rare.
People to this day wonder why I migrated to Linux with Firefox...most of them stop when I tell them about the "virus protection" Linux has, and the benefits of Firefox.
While I agree that sticking to standards may lead to stagnation (fortunately there are active groups, like the WHAT-WG, looking for new standardized solutions for new needs), here I completely miss your point and train of thought. What does breaking standards have to do with flash and web annoyances?
It's not about complying or not to standards, but about delivering you some unuseful content rather than the same as IE6's.
For example, when I was using Firefox 0.8~0.9 Nintendo.com would say my browser is not known and must be very old, making parts of the content unavailable. As a result, I couldn't get any direct link to work, because every time I followed one I would be redirected to this warning page, where I had to confirm it and then fall into the home page.
Another example would be an website which when does not detect you as a IE user sends you standards-compliant code (gasp!), or which sends simplified code (no javascript, no flash, no frames...) when your browser is unknown.
Microsoft updated the UA after considering application compatibility issues.
Currently IE's user-agent string defines itself as a browser compatible with "Mozilla/4.0". I wouldn't doubt that line means they're changing to some new format (directly specifying it's MSIE rather than saying it's compatible with an old browser, just like Opera). That then could be what broke so many websites into not recognizing it as IE.
But as the article is too vague on this aspect, we can't really be sure.
Why would I want something that keeps breaking my applications? At least AOL disks work.
Right after I read your first sentence I remembered of all that browser-hijacking that was infamous to AOL in earlier years, and I only realized you were talking about service packs with your second sentence.
Maybe I'm being paranoid, but can anyone else see lazy PHP coders relying on this, and forgetting to do proper server-side input checking?
I may be wrong, but I believe one of the greatest advantages of XForms for the developer is exactly that, since you have all those rules and constraints defined in a XML format, it is incredibly easy (provided your server-side language supports this) for you to use the very same XML to produce a HTML form (through Web Forms) and to do server-side checking.
All you have to do is to build a form specification and a XML skeleton for input. You'll use Web Forms technology to convert that into an user-accessible form (his browser may not support XForms) with client-side checking, and XForms technology to do a redundant security check in the server side. I, for one, feel very pleased with that: easier for me and more secure at the same time.
chill answered it for me. I'm not into the suite, so I didn't know for sure what version it would be. Though I suspected there was some revision number missing, I couldn't find anything anywhere in the mozilla.org website, so I assumed it was really version "1.7".
I agree: MoFo should be more specific, just like they are on Firefox pages.
I don't want to sound like a fanboy here, but this is not a new method. They already knew the flaw, since the beginning. It was just left for later work. Then, one day the "pop-uppers" found it.
As soon as they block unwanted plug-in pop-ups, AFAIK there's no other known hole left for that. Then, and only then, I'm going to give advertisers any credit for showing a pop-up ad in Firefox or -- OMG!! -- finding a "hole" in it.
I see your point now, and it's like they said in an earlier comment... sIFR doesn't interact well with flash blockers (and now that you mention, Adblock tabs -- I have disabled the tabs long ago because of how annoying they got on pages with several flash objects, and completely forgot about them), and that's why I too agree it's just a clever hack, not a final solution.
Btw, thanks for being nice and writing an intelligent post. After my last paragraph I was afraid of ignorant replies:-)
Actually, it's still there, and it just shows up randomly for people. I, for instance, never saw it.
Google often does that: Gmail's new features are slowly appearing for everyone, and when they were testing the new layout for the results page (minor changes, like a smaller logo) only a few select people (detected based on their cookie IDs) could see it.
In flash you can embedd the font anyway.... this is a bastard child solution.
But that's exactly why they use Flash to reach their goals.
Use flash, or don't. Otherwise the existing 'problem' isn't a problem, I have installed the fonts I want, use them.
I don't get your statement. Would you prefer having Flash every time a webdesigner wants fancy fonts? This solution allows text in custom fonts proportionally sized to the viewer's display (opposed to standard fixed pixel-defined size), while still maintaining accessibility. If eye-candy is the intent, I do find this one a quite clever hack.
It seems to me you didn't understand what the article was all about.
Slashdot Mirror
Well, I agree with most other posts here: from my experience, problems with semicolons or optional curly braces are countlessly more frequent than indenting problems.
But I think nobody remembered to mention this: your comparison is not valid. Dedenting too soon is not the same as failing to close a block, but rather the same as closing it too early. And that is also a runtime error, just with a different syntax.
And I guess running a Linux install as a screensaver on them would be really helpful?
I don't normally use named captures, but sometimes I fall into the situation I just described.
Actually, it's quite simple: we should preserve the pirates to stop the global warming.
From my experience, WinRAR (when producing .rar files, of course) provides the best compression-to-compression-and-extracting-time ratio. 7z files, when smaller than .rar files, do not show any significant advantages, while taking a considerably longer time to compress and decompress. Bz2 really excells at raw uncompressed data (like pure text, .bmp and .wav files), but operates quite slowly and tends to give less satisfactory results if the data already has some kind of compression on its own. Zip (and gzip) are quite fast, but don't compress as much as the former methods.
In the end, as much as I like open-source, I still use .rar for most of my archives. But 7zip is my favorite self-extracting generator.
Though the new GDS looks very interesting to me, this summary failed to mention it is still in beta stage.kool
ASP, JSP and PHP have nothing, absolutely nothing to do with what version of HTML you're using (or if it ever changes). HTML is a markup language, they're server-side programming languages (or frameworks/toolkits, in some cases). Their point compared to common CGI (or other server-side page generation methods) is that they merge nicely with HTML, but they could merge with pretty much anything. Even if the web were in plain text with menus (like telnet), there would be a need for easy dynamic content generation, and such tools would eventually appear.
While I agree that sticking to standards may lead to stagnation (fortunately there are active groups, like the WHAT-WG, looking for new standardized solutions for new needs), here I completely miss your point and train of thought. What does breaking standards have to do with flash and web annoyances?
For example, when I was using Firefox 0.8~0.9 Nintendo.com would say my browser is not known and must be very old, making parts of the content unavailable. As a result, I couldn't get any direct link to work, because every time I followed one I would be redirected to this warning page, where I had to confirm it and then fall into the home page.
Another example would be an website which when does not detect you as a IE user sends you standards-compliant code (gasp!), or which sends simplified code (no javascript, no flash, no frames...) when your browser is unknown.
From TFA:
Currently IE's user-agent string defines itself as a browser compatible with "Mozilla/4.0". I wouldn't doubt that line means they're changing to some new format (directly specifying it's MSIE rather than saying it's compatible with an old browser, just like Opera). That then could be what broke so many websites into not recognizing it as IE.
But as the article is too vague on this aspect, we can't really be sure.
Also makes you look redundant.
So, uninstall first if you're currently using an installer build.
Author of Lunix, I guess.
While I like the current method, I agree there could be something like an advanced option (or maybe even a hidden preference) to change it.
Right! The Almighty One should have an internal universe just for development and testing. Heh, I guess he isn't even using a version control system.
Right after I read your first sentence I remembered of all that browser-hijacking that was infamous to AOL in earlier years, and I only realized you were talking about service packs with your second sentence.
I may be wrong, but I believe one of the greatest advantages of XForms for the developer is exactly that, since you have all those rules and constraints defined in a XML format, it is incredibly easy (provided your server-side language supports this) for you to use the very same XML to produce a HTML form (through Web Forms) and to do server-side checking.
All you have to do is to build a form specification and a XML skeleton for input. You'll use Web Forms technology to convert that into an user-accessible form (his browser may not support XForms) with client-side checking, and XForms technology to do a redundant security check in the server side. I, for one, feel very pleased with that: easier for me and more secure at the same time.
No, it is not. I just checked. Don't be fooled by that bunch of "$00", they're just a representing zeroes in an UTF-16-like encoding.
Problem is the Mozilla website is simply a mess when it comes to Suite versions. I couldn't find any link referring especifically to 1.7.7, sorry.
chill answered it for me. I'm not into the suite, so I didn't know for sure what version it would be. Though I suspected there was some revision number missing, I couldn't find anything anywhere in the mozilla.org website, so I assumed it was really version "1.7".
I agree: MoFo should be more specific, just like they are on Firefox pages.
I thought it was "fhqwhgadshgnsdhjsdbkhsdabkfabkveybvf".
As soon as they block unwanted plug-in pop-ups, AFAIK there's no other known hole left for that. Then, and only then, I'm going to give advertisers any credit for showing a pop-up ad in Firefox or -- OMG!! -- finding a "hole" in it.
Btw, thanks for being nice and writing an intelligent post. After my last paragraph I was afraid of ignorant replies :-)
Google often does that: Gmail's new features are slowly appearing for everyone, and when they were testing the new layout for the results page (minor changes, like a smaller logo) only a few select people (detected based on their cookie IDs) could see it.
But that's exactly why they use Flash to reach their goals.
I don't get your statement. Would you prefer having Flash every time a webdesigner wants fancy fonts? This solution allows text in custom fonts proportionally sized to the viewer's display (opposed to standard fixed pixel-defined size), while still maintaining accessibility. If eye-candy is the intent, I do find this one a quite clever hack.
It seems to me you didn't understand what the article was all about.