you don't provide any kind of a response to the question as to why people should be interested in html5.
I did say:
They don't require a browser plugin (like java or flash) to play.
If you want Android and iP*d, and many Linux users to be able to play...
Perhaps your definition of "any" is not the same as mine.
Also note: The numbered sentences in my first post are valid reasons NOT to use HTML5 + JS.
I was pointing out my position: Games with HTML5+JS are possible (thats what I used to make a pacman clone), but performance is poor. I choose to keep my eye on it (and test it by using it) rather than completely ignore HTML5.
I see that a richer web is where we are heading, and suggest to others that they stay in touch with the technologies that will takes us to our destination (HTML5+JS).
----
without any kind of cross browser compatibility in prospect
Standardized audio and video tags and the API to control them via JS is a huge "cross browser compatibility" win!
I can call audioElement.play() on it and trust that the element will have the.play() method/function. That is "cross browser" enough for me.
I don't care what plugin or built in system plays the audio (neither does HTML5) as long as my code can access it via a standard API.
HTML5 is not concerned with which audio/video formats websites and browsers adopt. It's a weakness in the web, but that's between browsers (HTML5 implementations) and the sites they display -- not the markup language.
Days on Mars are almost, but not quite, equal to days on Earth. Mars meters (and feet) are also not the same as Earth measures due to the difference in gravities (and thus space-time warping).
I know Firefox is open source, but is it wise to broadcast their intentions so publicly months in advance? Especially when it has to do with competing against other browsers.
Answer is simple: Yes, because it's open source. If they want my help as a developer, then I need all the info about the product I can get.
It's not as if their new JS engine has been developed behind closed doors... This announcement just informs us open source developers that we should focus our efforts on improving JaegerMonkey instead of TraceMonkey because its scheduled to be included in FF4.
They don't require a browser plugin (like java or flash) to play.
I agree that it's not that big of a deal if your target audience is using Windows PCs... If you want Android and iP*d, and many Linux users to be able to play as well HTML5 + JS is a decent alternative.
I already use Flash's ActionScript, so why not use the almost identical JavaScript to make the game and target a wider audience?
1. Flash is made specifically for animation, so it's generally easier to get a game up and running with in than in JS+DHTML/Canvas. Game authoring frameworks for JS may fix this.
2. JS animation is sometimes jerky and slow. SVG is very slow too. Hardware acceleration will fix this.
3. The audience without flash or java is too small to worry about. This audience is growing, much the same as when Firefox was new. It's silly to not test websites in FF, Chrome, Safari and Opera now.
In short: Why? Because it's the future. HTML was originally for static content. Now web pages have rich multimedia content. In the future HTML will likely incorporate standard effects like animated style transitions, and even 3D.
You can ignore the future, but soon the future will be very relevant.
I created SnackMan (pacman clone with multiple levels and variable ghosts) in DHTML+JS with sound & music back on IE6. Over the years I gave up on JS+DOM because of the number of <object> tags I had to support for sound.
HTML5 sparked my interest in using JS for games again, so I reworked the sound system. The latest version only works in HTML5 aware browsers (eg: FF 3.5). For some reason the music stutters and cuts out. Downloading it and running the game locally solves the issue.
Also: To have multiple sounds of the same effect playing at once I had to create 10 identical <audio> audio tags for each effect.
I can't wait until the HTML5 implementations are more stable so that I can seriously use it for games.
Sure, whats the scientific stance on gay marriage?
Marriage is a legal union of two people. Marriage laws are not concerned with sexual orientation, only a person's anatomical sex.
For example: A heterosexual male can marry a bisexual or even homosexual female. A homosexual man can legally marry a homosexual woman.
Since many types of gay marriage are already legal it makes no logical sense to disallow only one specific case: A homosexual same sex marriage.
In conclusion: Sexual discrimination is illegal. Gay marriage IS ALREADY LEGAL. Let us formally and legally declare ALL gay marriages to be legal in order to clarify our stance: Discrimination based on sex is wrong.
I have found a common cold virus that is so easy to make into a biological weapon that I'm surprised we're all not dead already. I contacted every government authority and they all wanted to keep it top secret even though there are simple steps the public can take to prevent infection. I now face persecution as a "terrorist" for these "crimes against humanity" (AKA basic genetic research). I am now deeply distrustful of those in authority. I could go into hiding, but leaving the innocent public in such danger is against my morals.
The ease of discovery and manufacture of this biological terror makes it evident that our enemies may make an identical discovery very soon. In order to inform the public of the danger currently on the horizon, and to (hopefully) clear my name, I have no choice to take my findings to the media. I can only hope to force the government into action before I'm assassinated, or a plague sweeps across the world.
As for a "trivial" solution (referrer checking): It was actually non trivial for the webmaster who confronted me about the "hot-linking".
If referer-checking was non-trivial, so would any solution you propose, I would think.
No solution is trivial to provide & implement. Once standardized my solution would be trivial to use.
Writing a server side script to conditionally (dis)allow content delivery based on HTTP referral data will always be non-trivial. Just because it's common place nowadays, doesn't make it non-trivial (entire sites can go down if done incorrectly).
Adding one HTML tag to an HTML document is trivial.
Changing many documents this way is non trivial -- configuring the server to send the additional HTTP header it relatively trivial in this case, and is simpler / less processor intensive than conditionally disallowing content via referrer.
I think the point I'm trying to make is that it's not always obvious how to generalize something. Again, the obvious and dead-simple solution to hotlinking is referer-checking.
[...] I'm not saying that all problems are unforseeable, I just respectfully disagree that this particular one was so obvious as to be "silly".
If your server sends a new HTTP header that is unrecognized by the browser it will be gracefully ignored. The browser will also ignore any <meta> tag it doesn't understand.
The current HTTP, (X)HTML standards are designed to be extensible, yet a simple extension is hard to achieve.
o_O
I find this silly.
It would be like designing a system that touts its ability to easily provide feature X, but feature X is actually not realistically achievable...wait, no that is exactly what happened! LOL, silly 'eh?
I agree it's implausible that a system will have no flaws, but once a flaw is found and a simple solution exists, and a new version of the system is released (4.01), and no fix is standardized and adopted even though the system is extensible and the solution degrades gracefully (won't break the web for current browsers), then I scratch my head and think, "Gee that's either silliness or stupidity." (I'm a nice guy so I give the benefit of the doubt and go with "silly".)
You're missing the point. We want to keep rogue websites from "hot-linking" and "click-jacking" not rogue browsers.
I understand. However, you said:
Referrer validation is just as broken as TFA's frame busting JavaScript code since browsers can be configured to disable both JavaScript and the HTTP referrer.
In other words, people with oddly-configured browsers may be vulnerable, and may allow rogue websites to abuse them or other websites.
[...]
For clickjacking, if they disable JavaScript, it seems like they'd disable just about any realistic clickjacking attack.
::Sigh:: Technology moves forward; Those who don't apply updates are susceptible to the unpatched flaws. C'est la vie.
For security and privacy reasons many people disable HTTP-REFERER and/or JavaScript; A site should still (at least mostly) work with these disabled... It's not hard -- I wrote a chat site using only HTML/HTTP; no plugins or JS required (enabling JS or Flash or Java gave better experience, but these were not relied upon).
Hot-linking is allowed by most sites if you disable referrer info; A blank referrer bypasses the referral check and provides the visitor more privacy and security. What's the downside for visitors? Ah, none.
To plug these linking and framing "holes" you can require referrer info and/or JavaScript be enabled to view a site, but this will prevent legitimate (security conscious) visitors from viewing your content.
Enabling the "Allow sites to prevent unwelcome frames" security feature will not break the original sites -- it breaks the sites that ar
We rarely write software that is even robust enough to be secure against unexpected input on our current "reliable" chips (see: Viruses and other malware).
The idea of having application programmers cope with the new unpredictable hardware errors is seriously flawed.
In the end an additional "software" layer (probably actually firmware) will have to deal with this new type of hardware error; Application level coding (and existing software) will continue working as usual.
If this turns out to be faster than current techniques: Meh. A new faster processor and a new buzzword will be born.
I'll be interested when I can buy the new hardware and run *nix on it; Until then the only buzzword that comes to mind is "vaporware".
I made a clone as a bookmarklet. If you have Firefox (and JavaScript enabled) it plays from the address bar or a bookmark.
Sadly, the character limit of this comment box prevents me from posting it here, but you can get it from another post of mine.
Tetris is so simple that it's my "Hello World". Every time I learn a new programming language I make another Tetris clone; It has all of the basic elements of any game: game logic, grahics, animation, user input and feedback.
TFA clearly illustrates abuse of the DMCA. The owners of Tetris clearly know that they're abusing the DMCA -- they've been bullying hobbyists for quite some time. "Fuck 'em," I say. Put your app on your own website and link to it from a free app titled, "Say no to Tetris DMCA bullying."
P.S. Everyone has permission to use my clone's code however they see fit;-)
All copyrighted songs should be required to have at least one "Backup Singer" that sings the lyrics to the license agreement for the duration of the song.
My identity was comprised once, and since then I've hardened my security and never put all of my financial eggs in one basket.
I host my own data in an encrypted online backup, and make quarterly physical encrypted backups (stored in two cities 1,300 miles apart). Several trusted parties each have a piece of the keys.
Hell, I was stranded in the Canadian wilderness for 3 months in the winter (-40 degrees) and survived that quite easily.
I crave this world wide total data disaster! (Which will never happen.) It would give us the chance to start this mess all over and do things right (no more Patents! Yay!) I'd finally be able to use my own damn code!
That which doesn't kill me makes me harder, better, faster, smarter...
when... the <img> tag was included... "hot linking" became a problem.
For which there was a trivial solution in the form of referer -- but I also remember hotlinking not being a problem for a long time, though it was certainly possible.
The first time I used the <img> tag I "hot-linked". The origin site contacted me and asked me to stop it (even though I gave attribution and a link back). I apologized and complied immediately. This was an early and frequent problem I encountered from both sides (YMMV) which could have been prevented in successive versions. This was prior to HTML 4.0, 4.01, XHTML 1.0, and HTML 5.
I'm afraid I've miscommunicated as to which standard's "beginning" I found it silly to not have this feature included within (4)...
As for a "trivial" solution (referrer checking): It was actually non trivial for the webmaster who confronted me about the "hot-linking".
"Hot linking" and "click-jacking" are two sides of the same coin; They're only possible because there's no standard in place to tell the browser, "Don't display this content if the page's host address doesn't match the resource's address."
And in 20/20 hindsight, that makes sense and even seems obvious. But when looking at the img tag problem, I wouldn't immediately think, "Maybe one day people will be able to display HTML from another site in something, I think I'll call it a 'frame', and that won't be able to use the referer header, and it could be really bad."
Ah, but since shortly after the <img> we've needed a way to inform browsers of cases when the content should or shouldn't be displayed in mixed domain pages, yet we still don't have a standard solution; Now days its more serious than a bit of stolen bandwidth -- visitor privacy & security is at stake.
Referrer validation is just as broken as TFA's frame busting JavaScript code since browsers can be configured to disable both JavaScript and the HTTP referrer.
...WTF?
Browsers can also be configured (or written) to disable anything you might suggest.
You're missing the point. We want to keep rogue websites from "hot-linking" and "click-jacking" not rogue browsers.
If we have a way of telling the average visitor's web browser that displaying certain content is not recommended, then we have a solution that security minded folk will adopt quickly; Everyone else can choose to "upgrade" (or not) as they see fit.
Nothing can prevent these "exploits" if a user chooses to disable the default (recommended) security features or use an older browser (or craft their own browser).
It seems silly to me "hot linking" and "click-jacking" can both be prevented via a simple extension to HTTP and HTML,
And it's hard to add any "simple" extension to HTTP or HTML -- just look at the ongoing HTML5 debate. Now, it is happening in a sideways, unofficial way (to HTTP), and it may make its way into the standard, but it's still going to be awhile before we can assume users have updated their browsers to support it, assuming all browsers implement it.
It wasn't always this way, and it doesn't have to be. HTML standards have been stagnant for quite some time now; This is why its difficult to add useful features...
The fact that it is hard to add simple cross domain controls (that we've needed for several versions already) to the current/next standard is at least a bit silly, no?
Its always seemed silly to me that this wasn't in the standards to begin with...
To begin with? Are you serious?
Yep, I'm serious. I'm not sure when exactly the <img> tag was included, but that's when "hot linking" became a problem.
"Hot linking" and "click-jacking" are two sides of the same coin; They're only possible because there's no standard in place to tell the browser, "Don't display this content if the page's host address doesn't match the resource's address."
Instead, we have to do HTTP-REFERER (sic) checking on the server side to prevent "hot linking". Referrer validation is just as broken as TFA's frame busting JavaScript code since browsers can be configured to disable both JavaScript and the HTTP referrer.
It seems silly to me "hot linking" and "click-jacking" can both be prevented via a simple extension to HTTP and HTML, and yet these problems still exist.
The proposed fix is terrible. Regrettably, we're going to need browser makers to extend their browsers to really fix the problem.
I agree, but I think the task falls to HTML standards (since they gave us <iframe>). Browser makers shouldn't be left to make up disparate solutions to something that could simply be a part of the HTML and/or HTTP standard.
In HTML: <meta allowframing="false"> In HTTP: Allow-Framing: false;
A "true" value (default) would allow the resource to be <iframe>d. A "false" value would show an error placeholder or nothing at all (like broken <img>s do).
In any event, you are correct; Web browsers will still need extending. Its always seemed silly to me that this wasn't in the standards to begin with...
I eat meat. I kill cattle to eat them. They live happy lives on my grandparent's farm; Many of our stock never see the fence that surrounds them.
The cattle are so eager to get to the slaughter they sometimes fight each other for the privilege to go first.
Our cattle are killed by a pneumatic rod that quickly and painlessly ends their lives without any pain or suffering......and they are delicious.
How about FACT instead of "weak logic"? Humans have been omnivores for hundreds of millions of years. This "vegan" and "vegetarian" bullshit goes against of all prior human evolution -- specifically our nutritional needs for meat (it's not a luxury it's a necessity -- nutritionalists will tell you, "don't take supplements unless the real thing isn't available"). Those pointy teeth you have are proof that eating meat is Human nature... you might as well boycott sex (I think all vegans and vegetarians should).
Humans prolong the death of their decrepit elderly, It's illegal in most countries for the elderly to end their pain with death. I wish many of my relatives would have died as "humanely" as our cattle do instead of the ridiculous forced suffering they've endured (and pleaded with us to end).
If you're a Human (or even just a warm blooded mammalian) your DNA is constantly pouring off of you everywhere you go...
Billions of skin cells are falling off of your body (1.5g per day), and you shed hair follicles constantly as well.
Your saliva is in the disposable cup you tossed into the refuse bin.
Think that DNA from the cells in someone's pubic region should be solid proof that's admissible in rape cases? If yes: YOU'RE WRONG. Have you ever seen pubic hair on and around a public toilet or urinal -- Guess where it came from? YOU (at some point). Additionally, male mammals (including Humans) excrete semen that is left in their urethra when they urinate after having been sexually stimulated.
Your DNA is by no means private, and the appearance of it at a crime scene doesn't prove anything at all. Any premeditation on the part of murderers, rapists or thieves could easily include following YOU around (esp if you fit their physical profile) for a few hours collecting "evidence" that YOU did the crime.
Inappropriate conclusions are being made based on the presence of DNA evidence. The only thing that YOUR DNA being found at a crime scene really proves is that you (might) exist.
(For plausible non-existence of living entities even given the presence of DNA see: stem cell research & gene therapy).
However, If you ask any professional in the field how to achieve a task and they come up with a solution and implement it, and use it without a second thought thinking "This is too obvious to patent", not realizing that M$ had in fact patented the technology already, then perhaps the patent is over-broad and/or too obvious to patent.
Or maybe you saw it in a microsoft product, maybe not even realizing it, and your subconscious now "invented" it.
It's hard to tell. It takes years to process and get a patent accepted. If you just implemented something you feel is obvious, and there is already a patent on it, that means the concept has been out there for at least 5 or 10 years, making your claims of obviousness biased.
The question is, did you invent it without any knowledge (consciously or subconsciously) of the other work.
Or maybe I was using a Macintosh and Gem Desktop before I had ever seen MSWindows (All of which have menus).
Perhaps I had already been programming pages on our Intranet using applets.
Perhaps when someone said: Hey, can we have a menu for those choices? I went right ahead and unknowingly violated Mircosoft's patent because it was obvious.
There's a damn good chance that any skilled individual (knowing how to utilize applets and HTML) when asked how to create a menu on a web page will tell you -- "Hmm... we could use an Applet!" That's obvious for you, and obviousness invalidates patent claims.
I think that the most interesting points I'm taking away from this conversation are:
1) You were not skilled in the art at the time of the patent filing (I doubt you have ever used HTML and <applet> yourself) and are therefore unqualified to make the obviousness distinction (just like the patent examiners that granted the bogus patent).
2) Coders should be the ones granting patents for code. Mechanical engineers should be granting mechanical patents, and Doctors medical patents. Not some random Joe with an inkling of interest in the area who happens to be working at UPTSO.
3) The "secrecy" granted patent applications is to blame. Date and time of patent application should be enough to prove a patent's application time -- which can be used as a selection factor among similar patent applications. One or more individuals skilled in the art of the components of the patent should be consulted to determine obviousness of said patent. Free consultation is available via the Internet for many technology claims if only the initial secrecy was abolished.
4) It's much too expensive to make a counter-claim of obviousness against any patent for the ordinarily skilled in the art folk to deal with these bad patents after the fact, so they should be consulted prior to granting a patent.
5) I should patent the above method and implementation of inexpensive determination of a patent's obviousness because of only one of the following:
A) I'm a fnck!ng Genius! (Geniuses are better than most people, they can earn monopolies.)
B) The UPTSO is filled with morons that don't even read the applications (see: swinging on a swing patent).
or
C) I'm the first person to ever think of this, therefore it must be non-obvious!
The telephone was not an obvious idea when invented, but yes, Bell made it to the patent office first.
I assure you I'm not confused. I suspect you missed the point: "He who submits a patent first" should not have any merit over obviousness.
If a skilled professional creates something and thinks: "This is too obvious to patent", and someone else comes along and patents that something then we have a "Theft of idea," and prior art can corroborate...
However, if a skilled professional takes A and applies it to B to produce AB it's not innovating, it's down-right obvious to any professional skilled in the art. It's stealing of the future ideas of everyone. The very next person that approaches the problem and arrives at the same solution without prior knowledge of patented technology isn't "infringing" so much as they are proving the patent is obvious.
Patent law is designed to prevent such "I got here first" patents... However, patent examiners are ill equipped to make the obviousness distinction themselves (being uneducated and not professionals well versed in the art or trade over which they grant patents for), and so we have these oh-so-obvious patents on the books.
As a professional skilled in the trade of both websites and menus when my boss asked me in 1996 to produce a menu for our website, I did so. It was obvious how to achieve this goal. I had no knowledge of prior art. It was so fnck!ng obvious I didn't need to go searching for someone else's work... I just did what was asked of me.
Now, I know that our company was "infringing" on a M$ patent that should have never been granted due to obviousness claims.
If you ask any professional in the field how to achieve a task and they come up with "It can't be done," then the patent for that achievement should be granted.
However, If you ask any professional in the field how to achieve a task and they come up with a solution and implement it, and use it without a second thought thinking "This is too obvious to patent", not realizing that M$ had in fact patented the technology already, then perhaps the patent is over-broad and/or too obvious to patent.
Just because someone thought of something first doesn't make it patentable.
We're all building off of the ideas and culture of our forefathers. Voice = communication. Reproducing Sound = already invented. Telegraph = wired communication. Voice over wire = obvious. Patenting the fundamental process for converting sound into electrical signals and reproducing sound is so obvious that two "inventors" (aka implementors) separately arrived at the same solution... on the same day... there was a race? (This reeks of obviousness folks).
Everyone is standing on the shoulders of Giants saying: "I climbed highest! Give me the monopoly!"
I say: Screw that. I'll get to that same height eventually. Simply having enough money to help you achieve a goal first doesn't give you the right to a monopoly over the goal itself, but that's what our broken patent system does (due to uneducated unskilled non-professional patent examiners).
And if "obvious" patents could actually be revoked in a sane manor then the above swinging on a swing patent wouldn't still be a valid patent... (They could have asked any child about this perpendicular swinging motion claim -- but they didn't because the patent system is a joke.)
The problem with ideas is that they seem obvious in hindsight. Prior to that, clearly nobody had implemented it.. so the idea couldn't have been that obvious
You're saying: because something hasn't been implemented yet means it must not be obvious?
I'm saying: Perhaps M$ just got to the patent office first with an obvious idea... (much like the Bell's Telephone)
Since the patent examiners are not professionals skilled in the art It's obvious that they aren't qualified to make the non-obvious distinction, or else we wouldn't have so many of these obvious patents.
----
FYI Menus existed in 1995. Menus on a webpage == fnck!ng obvious esp. to any professional skilled in the art of making menus and web pages.
"As the Americans learned so painfully in Earth's final century, free flow of information is the only safeguard against tyranny. The once-chained people whose leaders at last lose their grip on information flow will soon burst with freedom and vitality, but the free nation gradually constricting its grip on public discourse has begun its rapid slide into despotism. Beware of he who would deny you access to information, for in his heart he dreams himself your master." - Pravin Lal of Alpha Centauri (1999)
Slashdot Mirror
'About half a mile from where I live, a Tele Atlas-based satnav will instruct you to turn off at a junction where there's only an on-ramp,'
FYI: That moderately sloped grassy area along most on-ramps is commonly known as an "alternate off ramp".
you don't provide any kind of a response to the question as to why people should be interested in html5.
I did say:
They don't require a browser plugin (like java or flash) to play.
If you want Android and iP*d, and many Linux users to be able to play...
Perhaps your definition of "any" is not the same as mine.
Also note: The numbered sentences in my first post are valid reasons NOT to use HTML5 + JS.
I was pointing out my position: Games with HTML5+JS are possible (thats what I used to make a pacman clone), but performance is poor. I choose to keep my eye on it (and test it by using it) rather than completely ignore HTML5.
I see that a richer web is where we are heading, and suggest to others that they stay in touch with the technologies that will takes us to our destination (HTML5+JS).
----
without any kind of cross browser compatibility in prospect
Standardized audio and video tags and the API to control them via JS is a huge "cross browser compatibility" win!
I can call audioElement.play() on it and trust that the element will have the .play() method/function. That is "cross browser" enough for me.
I don't care what plugin or built in system plays the audio (neither does HTML5) as long as my code can access it via a standard API.
HTML5 is not concerned with which audio/video formats websites and browsers adopt.
It's a weakness in the web, but that's between browsers (HTML5 implementations) and
the sites they display -- not the markup language.
Perhaps the units are in Martian measures.
Days on Mars are almost, but not quite, equal to days on Earth.
Mars meters (and feet) are also not the same as Earth measures due to the difference in gravities (and thus space-time warping).
Perhaps Martian math isn't an exact science...
I know Firefox is open source, but is it wise to broadcast their intentions so publicly months in advance? Especially when it has to do with competing against other browsers.
Answer is simple: Yes, because it's open source.
If they want my help as a developer, then I need all the info about the product I can get.
It's not as if their new JS engine has been developed behind closed doors...
This announcement just informs us open source developers that we should focus our efforts
on improving JaegerMonkey instead of TraceMonkey because its scheduled to be included in FF4.
They don't require a browser plugin (like java or flash) to play.
I agree that it's not that big of a deal if your target audience is using Windows PCs...
If you want Android and iP*d, and many Linux users to be able to play as well HTML5 + JS is a decent alternative.
I already use Flash's ActionScript, so why not use the almost identical JavaScript to make the game and target a wider audience?
1. Flash is made specifically for animation, so it's generally easier to get a game up and running with in than in JS+DHTML/Canvas.
Game authoring frameworks for JS may fix this.
2. JS animation is sometimes jerky and slow. SVG is very slow too.
Hardware acceleration will fix this.
3. The audience without flash or java is too small to worry about.
This audience is growing, much the same as when Firefox was new.
It's silly to not test websites in FF, Chrome, Safari and Opera now.
In short: Why? Because it's the future. HTML was originally for static content. Now web pages have rich multimedia content.
In the future HTML will likely incorporate standard effects like animated style transitions, and even 3D.
You can ignore the future, but soon the future will be very relevant.
Doh! Sorry; Link had one to many dots... Here's a working link.
I created SnackMan (pacman clone with multiple levels and variable ghosts) in DHTML+JS with sound & music back on IE6.
Over the years I gave up on JS+DOM because of the number of <object> tags I had to support for sound.
HTML5 sparked my interest in using JS for games again, so I reworked the sound system.
The latest version only works in HTML5 aware browsers (eg: FF 3.5).
For some reason the music stutters and cuts out.
Downloading it and running the game locally solves the issue.
Also: To have multiple sounds of the same effect playing at once I had to create 10 identical <audio> audio tags for each effect.
I can't wait until the HTML5 implementations are more stable so that I can seriously use it for games.
Sure, whats the scientific stance on gay marriage?
Marriage is a legal union of two people.
Marriage laws are not concerned with sexual orientation, only a person's anatomical sex.
For example:
A heterosexual male can marry a bisexual or even homosexual female.
A homosexual man can legally marry a homosexual woman.
Since many types of gay marriage are already legal it makes no logical sense to disallow only one specific case:
A homosexual same sex marriage.
In conclusion:
Sexual discrimination is illegal.
Gay marriage IS ALREADY LEGAL.
Let us formally and legally declare ALL gay marriages to be legal in order to clarify our stance: Discrimination based on sex is wrong.
Another Analogy:
I have found a common cold virus that is so easy to make into a biological weapon that I'm surprised we're all not dead already.
I contacted every government authority and they all wanted to keep it top secret even though there are simple steps the public can take to prevent infection.
I now face persecution as a "terrorist" for these "crimes against humanity" (AKA basic genetic research).
I am now deeply distrustful of those in authority. I could go into hiding, but leaving the innocent public in such danger is against my morals.
The ease of discovery and manufacture of this biological terror makes it evident that our enemies may make an identical discovery very soon.
In order to inform the public of the danger currently on the horizon, and to (hopefully) clear my name, I have no choice to take my findings to the media.
I can only hope to force the government into action before I'm assassinated, or a plague sweeps across the world.
"They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety."
- Benjamin Franklin
Also: If we outlaw the visiting of radical websites, only outlaws will visit radical websites?
At this rate it wont be long before we have a convictions based on "pre-crime" behavior ala Minority Report.
“Worker bees can leave.
Even drones can fly away.
The Queen is their slave.”
-Chuck Palahniuk
As for a "trivial" solution (referrer checking): It was actually non trivial for the webmaster who confronted me about the "hot-linking".
If referer-checking was non-trivial, so would any solution you propose, I would think.
No solution is trivial to provide & implement.
Once standardized my solution would be trivial to use.
Writing a server side script to conditionally (dis)allow content delivery based on HTTP referral data will always be non-trivial. Just because it's common place nowadays, doesn't make it non-trivial (entire sites can go down if done incorrectly).
Adding one HTML tag to an HTML document is trivial.
Changing many documents this way is non trivial -- configuring the server to send the additional HTTP header it relatively trivial in this case, and is simpler / less processor intensive than conditionally disallowing content via referrer.
I think the point I'm trying to make is that it's not always obvious how to generalize something. Again, the obvious and dead-simple solution to hotlinking is referer-checking.
[...] I'm not saying that all problems are unforseeable, I just respectfully disagree that this particular one was so obvious as to be "silly".
If your server sends a new HTTP header that is unrecognized by the browser it will be gracefully ignored. The browser will also ignore any <meta> tag it doesn't understand.
The current HTTP, (X)HTML standards are designed to be extensible, yet a simple extension is hard to achieve.
o_O
I find this silly.
It would be like designing a system that touts its ability to easily provide feature X, but feature X is actually not realistically achievable...wait, no that is exactly what happened! LOL, silly 'eh?
I agree it's implausible that a system will have no flaws, but once a flaw is found and a simple solution exists, and a new version of the system is released (4.01), and no fix is standardized and adopted even though the system is extensible and the solution degrades gracefully (won't break the web for current browsers), then I scratch my head and think, "Gee that's either silliness or stupidity." (I'm a nice guy so I give the benefit of the doubt and go with "silly".)
You're missing the point. We want to keep rogue websites from "hot-linking" and "click-jacking" not rogue browsers.
I understand. However, you said:
Referrer validation is just as broken as TFA's frame busting JavaScript code since browsers can be configured to disable both JavaScript and the HTTP referrer.
In other words, people with oddly-configured browsers may be vulnerable, and may allow rogue websites to abuse them or other websites.
[...]
For clickjacking, if they disable JavaScript, it seems like they'd disable just about any realistic clickjacking attack.
::Sigh:: Technology moves forward; Those who don't apply updates are susceptible to the unpatched flaws. C'est la vie.
For security and privacy reasons many people disable HTTP-REFERER and/or JavaScript; A site should still (at least mostly) work with these disabled... It's not hard -- I wrote a chat site using only HTML/HTTP; no plugins or JS required (enabling JS or Flash or Java gave better experience, but these were not relied upon).
Hot-linking is allowed by most sites if you disable referrer info; A blank referrer bypasses the referral check and provides the visitor more privacy and security. What's the downside for visitors? Ah, none.
To plug these linking and framing "holes" you can require referrer info and/or JavaScript be enabled to view a site, but this will prevent legitimate (security conscious) visitors from viewing your content.
Enabling the "Allow sites to prevent unwelcome frames" security feature will not break the original sites -- it breaks the sites that ar
We rarely write software that is even robust enough to be secure against unexpected input on our current "reliable" chips (see: Viruses and other malware).
The idea of having application programmers cope with the new unpredictable hardware errors is seriously flawed.
In the end an additional "software" layer (probably actually firmware) will have to deal with this new type of hardware error; Application level coding (and existing software) will continue working as usual.
If this turns out to be faster than current techniques: Meh. A new faster processor and a new buzzword will be born.
I'll be interested when I can buy the new hardware and run *nix on it; Until then the only buzzword that comes to mind is "vaporware".
I made a clone as a bookmarklet.
If you have Firefox (and JavaScript enabled) it plays from the address bar or a bookmark.
Sadly, the character limit of this comment box prevents me from posting it here, but you can get it from another post of mine.
Tetris is so simple that it's my "Hello World".
Every time I learn a new programming language I make another Tetris clone; It has all of the basic elements of any game: game logic, grahics, animation, user input and feedback.
TFA clearly illustrates abuse of the DMCA. The owners of Tetris clearly know that they're abusing the DMCA -- they've been bullying hobbyists for quite some time. "Fuck 'em," I say. Put your app on your own website and link to it from a free app titled, "Say no to Tetris DMCA bullying."
P.S. Everyone has permission to use my clone's code however they see fit ;-)
All copyrighted songs should be required to have at least one "Backup Singer" that sings the lyrics to the license agreement for the duration of the song.
...Yep!
My identity was comprised once, and since then I've hardened my security and never put all of my financial eggs in one basket.
I host my own data in an encrypted online backup, and make quarterly physical encrypted backups (stored in two cities 1,300 miles apart). Several trusted parties each have a piece of the keys.
Hell, I was stranded in the Canadian wilderness for 3 months in the winter (-40 degrees) and survived that quite easily.
I crave this world wide total data disaster! (Which will never happen.) It would give us the chance to start this mess all over and do things right (no more Patents! Yay!) I'd finally be able to use my own damn code!
That which doesn't kill me makes me harder, better, faster, smarter...
when ... the <img> tag was included ... "hot linking" became a problem.
For which there was a trivial solution in the form of referer -- but I also remember hotlinking not being a problem for a long time, though it was certainly possible.
The first time I used the <img> tag I "hot-linked". The origin site contacted me and asked me to stop it (even though I gave attribution and a link back). I apologized and complied immediately. This was an early and frequent problem I encountered from both sides (YMMV) which could have been prevented in successive versions. This was prior to HTML 4.0, 4.01, XHTML 1.0, and HTML 5.
I'm afraid I've miscommunicated as to which standard's "beginning" I found it silly to not have this feature included within (4)...
As for a "trivial" solution (referrer checking): It was actually non trivial for the webmaster who confronted me about the "hot-linking".
"Hot linking" and "click-jacking" are two sides of the same coin; They're only possible because there's no standard in place to tell the browser, "Don't display this content if the page's host address doesn't match the resource's address."
And in 20/20 hindsight, that makes sense and even seems obvious. But when looking at the img tag problem, I wouldn't immediately think, "Maybe one day people will be able to display HTML from another site in something, I think I'll call it a 'frame', and that won't be able to use the referer header, and it could be really bad."
Ah, but since shortly after the <img> we've needed a way to inform browsers of cases when the content should or shouldn't be displayed in mixed domain pages, yet we still don't have a standard solution; Now days its more serious than a bit of stolen bandwidth -- visitor privacy & security is at stake.
Referrer validation is just as broken as TFA's frame busting JavaScript code since browsers can be configured to disable both JavaScript and the HTTP referrer.
...WTF?
Browsers can also be configured (or written) to disable anything you might suggest.
You're missing the point. We want to keep rogue websites from "hot-linking" and "click-jacking" not rogue browsers.
If we have a way of telling the average visitor's web browser that displaying certain content is not recommended, then we have a solution that security minded folk will adopt quickly; Everyone else can choose to "upgrade" (or not) as they see fit.
Nothing can prevent these "exploits" if a user chooses to disable the default (recommended) security features or use an older browser (or craft their own browser).
It seems silly to me "hot linking" and "click-jacking" can both be prevented via a simple extension to HTTP and HTML,
And it's hard to add any "simple" extension to HTTP or HTML -- just look at the ongoing HTML5 debate. Now, it is happening in a sideways, unofficial way (to HTTP), and it may make its way into the standard, but it's still going to be awhile before we can assume users have updated their browsers to support it, assuming all browsers implement it.
It wasn't always this way, and it doesn't have to be. HTML standards have been stagnant for quite some time now; This is why its difficult to add useful features...
The fact that it is hard to add simple cross domain controls (that we've needed for several versions already) to the current/next standard is at least a bit silly, no?
Its always seemed silly to me that this wasn't in the standards to begin with...
To begin with? Are you serious?
Yep, I'm serious. I'm not sure when exactly the <img> tag was included, but that's when "hot linking" became a problem.
"Hot linking" and "click-jacking" are two sides of the same coin; They're only possible because there's no standard in place to tell the browser, "Don't display this content if the page's host address doesn't match the resource's address."
Instead, we have to do HTTP-REFERER (sic) checking on the server side to prevent "hot linking". Referrer validation is just as broken as TFA's frame busting JavaScript code since browsers can be configured to disable both JavaScript and the HTTP referrer.
It seems silly to me "hot linking" and "click-jacking" can both be prevented via a simple extension to HTTP and HTML, and yet these problems still exist.
The proposed fix is terrible. Regrettably, we're going to need browser makers to extend their browsers to really fix the problem.
I agree, but I think the task falls to HTML standards (since they gave us <iframe>).
Browser makers shouldn't be left to make up disparate solutions to something that could simply be a part of the HTML and/or HTTP standard.
In HTML: <meta allowframing="false">
In HTTP: Allow-Framing: false;
A "true" value (default) would allow the resource to be <iframe>d.
A "false" value would show an error placeholder or nothing at all (like broken <img>s do).
In any event, you are correct; Web browsers will still need extending.
Its always seemed silly to me that this wasn't in the standards to begin with...
I eat meat. I kill cattle to eat them. They live happy lives on my grandparent's farm; Many of our stock never see the fence that surrounds them.
The cattle are so eager to get to the slaughter they sometimes fight each other for the privilege to go first.
Our cattle are killed by a pneumatic rod that quickly and painlessly ends their lives without any pain or suffering... ...and they are delicious.
How about FACT instead of "weak logic"?
Humans have been omnivores for hundreds of millions of years. This "vegan" and "vegetarian" bullshit goes against of all prior human evolution -- specifically our nutritional needs for meat (it's not a luxury it's a necessity -- nutritionalists will tell you, "don't take supplements unless the real thing isn't available").
Those pointy teeth you have are proof that eating meat is Human nature... you might as well boycott sex (I think all vegans and vegetarians should).
Humans prolong the death of their decrepit elderly, It's illegal in most countries for the elderly to end their pain with death.
I wish many of my relatives would have died as "humanely" as our cattle do instead of the ridiculous forced suffering they've endured (and pleaded with us to end).
If you're a Human (or even just a warm blooded mammalian) your DNA is constantly pouring off of you everywhere you go...
Billions of skin cells are falling off of your body (1.5g per day), and you shed hair follicles constantly as well.
Your saliva is in the disposable cup you tossed into the refuse bin.
Think that DNA from the cells in someone's pubic region should be solid proof that's admissible in rape cases? If yes: YOU'RE WRONG.
Have you ever seen pubic hair on and around a public toilet or urinal -- Guess where it came from? YOU (at some point).
Additionally, male mammals (including Humans) excrete semen that is left in their urethra when they urinate after having been sexually stimulated.
Your DNA is by no means private, and the appearance of it at a crime scene doesn't prove anything at all.
Any premeditation on the part of murderers, rapists or thieves could easily include following YOU around (esp if you fit their physical profile) for a few hours collecting "evidence" that YOU did the crime.
Inappropriate conclusions are being made based on the presence of DNA evidence.
The only thing that YOUR DNA being found at a crime scene really proves is that you (might) exist.
(For plausible non-existence of living entities even given the presence of DNA see: stem cell research & gene therapy).
Or maybe you saw it in a microsoft product, maybe not even realizing it, and your subconscious now "invented" it.
It's hard to tell. It takes years to process and get a patent accepted. If you just implemented something you feel is obvious, and there is already a patent on it, that means the concept has been out there for at least 5 or 10 years, making your claims of obviousness biased.
The question is, did you invent it without any knowledge (consciously or subconsciously) of the other work.
Or maybe I was using a Macintosh and Gem Desktop before I had ever seen MSWindows (All of which have menus).
Perhaps I had already been programming pages on our Intranet using applets.
Perhaps when someone said: Hey, can we have a menu for those choices? I went right ahead and unknowingly violated Mircosoft's patent because it was obvious.
There's a damn good chance that any skilled individual (knowing how to utilize applets and HTML) when asked how to create a menu on a web page will tell you -- "Hmm... we could use an Applet!" That's obvious for you, and obviousness invalidates patent claims.
I think that the most interesting points I'm taking away from this conversation are:
1) You were not skilled in the art at the time of the patent filing (I doubt you have ever used HTML and <applet> yourself) and are therefore unqualified to make the obviousness distinction (just like the patent examiners that granted the bogus patent).
2) Coders should be the ones granting patents for code. Mechanical engineers should be granting mechanical patents, and Doctors medical patents. Not some random Joe with an inkling of interest in the area who happens to be working at UPTSO.
3) The "secrecy" granted patent applications is to blame. Date and time of patent application should be enough to prove a patent's application time -- which can be used as a selection factor among similar patent applications. One or more individuals skilled in the art of the components of the patent should be consulted to determine obviousness of said patent. Free consultation is available via the Internet for many technology claims if only the initial secrecy was abolished.
4) It's much too expensive to make a counter-claim of obviousness against any patent for the ordinarily skilled in the art folk to deal with these bad patents after the fact, so they should be consulted prior to granting a patent.
5) I should patent the above method and implementation of inexpensive determination of a patent's obviousness because of only one of the following:
A) I'm a fnck!ng Genius! (Geniuses are better than most people, they can earn monopolies.)
B) The UPTSO is filled with morons that don't even read the applications (see: swinging on a swing patent).
or
C) I'm the first person to ever think of this, therefore it must be non-obvious!
You're confusing obviousness with theft of idea.
The telephone was not an obvious idea when invented, but yes, Bell made it to the patent office first.
I assure you I'm not confused. I suspect you missed the point: "He who submits a patent first" should not have any merit over obviousness.
If a skilled professional creates something and thinks: "This is too obvious to patent",
and someone else comes along and patents that something then we have a "Theft of idea," and prior art can corroborate...
However, if a skilled professional takes A and applies it to B to produce AB it's not innovating, it's down-right obvious to any professional skilled in the art.
It's stealing of the future ideas of everyone. The very next person that approaches the problem and arrives at the same solution without prior knowledge of patented technology isn't "infringing" so much as they are proving the patent is obvious.
Patent law is designed to prevent such "I got here first" patents... However, patent examiners are ill equipped to make the obviousness distinction themselves (being uneducated and not professionals well versed in the art or trade over which they grant patents for), and so we have these oh-so-obvious patents on the books.
As a professional skilled in the trade of both websites and menus when my boss asked me in 1996 to produce a menu for our website, I did so.
It was obvious how to achieve this goal. I had no knowledge of prior art. It was so fnck!ng obvious I didn't need to go searching for someone else's work...
I just did what was asked of me.
Now, I know that our company was "infringing" on a M$ patent that should have never been granted due to obviousness claims.
If you ask any professional in the field how to achieve a task and they come up with "It can't be done," then the patent for that achievement should be granted.
However, If you ask any professional in the field how to achieve a task and they come up with a solution and implement it,
and use it without a second thought thinking "This is too obvious to patent", not realizing that M$ had in fact patented the technology already, then perhaps the patent is over-broad and/or too obvious to patent.
Just because someone thought of something first doesn't make it patentable.
We're all building off of the ideas and culture of our forefathers. Voice = communication. Reproducing Sound = already invented. Telegraph = wired communication. Voice over wire = obvious. Patenting the fundamental process for converting sound into electrical signals and reproducing sound is so obvious that two "inventors" (aka implementors) separately arrived at the same solution... on the same day... there was a race? (This reeks of obviousness folks).
Everyone is standing on the shoulders of Giants saying: "I climbed highest! Give me the monopoly!"
I say: Screw that. I'll get to that same height eventually. Simply having enough money to help you achieve a goal first doesn't give you the right to a monopoly over the goal itself, but that's what our broken patent system does (due to uneducated unskilled non-professional patent examiners).
Also: If our patent system weren't such a joke we wouldn't have Swinging side to side instead of forward and back as a patent.
And if "obvious" patents could actually be revoked in a sane manor then the above swinging on a swing patent wouldn't still be a valid patent...
(They could have asked any child about this perpendicular swinging motion claim -- but they didn't because the patent system is a joke.)
The problem with ideas is that they seem obvious in hindsight. Prior to that, clearly nobody had implemented it.. so the idea couldn't have been that obvious
You're saying: because something hasn't been implemented yet means it must not be obvious?
I'm saying: Perhaps M$ just got to the patent office first with an obvious idea... (much like the Bell's Telephone)
Since the patent examiners are not professionals skilled in the art It's obvious that they aren't qualified to make the non-obvious distinction, or else we wouldn't have so many of these obvious patents.
----
FYI Menus existed in 1995. Menus on a webpage == fnck!ng obvious esp. to any professional skilled in the art of making menus and web pages.
"As the Americans learned so painfully in Earth's final century, free flow of information is the only safeguard against tyranny. The once-chained people whose leaders at last lose their grip on information flow will soon burst with freedom and vitality, but the free nation gradually constricting its grip on public discourse has begun its rapid slide into despotism. Beware of he who would deny you access to information, for in his heart he dreams himself your master." - Pravin Lal of Alpha Centauri (1999)