Indeed, there's one Asimov story in particular where the robots are specifically designed to be specialised enough that they don't need the three laws (insect-catching robots was the main example, IIRC).
"Unable to sense him, the robot's powerful hydraulic arm kept on working and [killed him]. This... would not have happened in a world in which robot behavior was governed by the Three Laws of Robotics"
Um. The three laws of robotics don't say that robots must be omniscient. If the robot doesn't sense the human, then three laws or no three laws, it's not going to behave any differently. Grumble grumble ignorant invocation of laws mumble.
Galeon uses the same rendering engine as Firefox. (Though come to think of it, the fact that you saw the protocol at all is a bug -- Gecko embedders like Galeon, Firefox, etc, are supposed to hide the wyciwyg addresses. Firefox probably does a better job of hiding them, since I've not seen them in Firefox in recent versions.)
I'm your average not-a-huge-console-fan consumer and the only thing I care about is the next GTA. Doesn't matter what the specs of the console are -- whichever console runs the next GTA is the one that I'm getting.
Not sure what you mean about overloading the class attribute... Could you expand on this?
Also, as far as I can tell XHTML2 introduces more new elements than HTML5, so I'm not sure that's a good argument. (Steven didn't list all the new elements in his talk though.)
Still, if you think we should remove some of the new elements, e-mail the WHATWG list. All input is taken into account (eventually).
Web Apps 1.0 (the spec) defines two languages: HTML5, which is a revision of HTML4, and XHTML5, which is a revision of XHTML1. They have the exact same semantics, just like HTML4 and XHTML1 are exactly the same semantics, the only difference is that HTML5 is sent as text/html and must be parsed as described in the spec, and XHTML5 is sent as application/xhtml+xml and must be parsed as described in the XML spec.
This might be a bit confusing. Basically XHTML5 is XML-compliant, and HTML5 is tag-soup-compliant. You can use either one, the spec doesn't care and doesn't prefer one over the other.
(Of course if you want your docs to work in IE, then I guess HTML5 is going to be more interesting to you.)
Regarding presentational tags; <pre>, <small> and <m> are defined in very semantic ways, and are not presentational. If you disagree, I encourage you to e-mail the list where this can be discussed and any problems you raise will be fixed.
I wish. Sadly, Microsoft are the only major browser vendor who aren't involved in the development of HTML5 (though they've been invited several times).
It has nothing to do with "cool"; SVG happens to be easier for us to produce than bitmaps, and anyone who is going to be able to read this report and view graphics will be using an SVG-capable browser. The fact that it found bugs in every SVG browser out there is merely a bonus, it means that SVG support will get better.
We used standards. It's not our fault if there was only one released browser that supported those standards well enough for you to be able to see the graphics.
"" is the HTML5 DOCTYPE, and HTML5 is why I did the study, so yeah, I used the HTML5 DOCTYPE. I don't see what's wrong with that.:-)
I didn't specify a character encoding because I used US-ASCII, which is the default for text/html, and which is also a subset of UTF-8, which is the default for image/svg+xml and text/css. Thus there was no need to set it. Nothing wrong there.
As for the entity for ">", there is no reason to use it. It takes longer to type, and is harder to maintain. Why would it be stupid?
And finally, TFA actually explicitly mentions the fact that Google's pages as a whole don't validate, in the very first paragraph. We know.
You need to chill, dude. Go play some games or something.:-)
Yeah, I misspoke on this. Set-Cookie is insecure (due to domain-crossing problems -- should a cookie sent to a.b.c get sent to z.b.c? Depends on "b" and "c" in ways that depend on month-to-month political changes around the globe), but as far as I can tell, Set-Cookie2 is also insecure. I had thought it fixed this, but apparently not.
Actually, Mozilla has supported it for about 5 or 6 years now. Still, yeah, the other browsers, not so much. In fact it was dropped from the HTTP spec due to lack of implementations.
Yes it is SO unrealistic to think that people might be so influenced by video games that they might actually ACT OUT the plot of such a video game in real life. That would never actually happen.
Slashdot Mirror
Oh wow, I didn't even see that. Man, I suck.
"At this point Vista is basically an operating systems built around one feature that nobody actually wants"
Just out of interest... which feature?
Indeed, there's one Asimov story in particular where the robots are specifically designed to be specialised enough that they don't need the three laws (insect-catching robots was the main example, IIRC).
"Unable to sense him, the robot's powerful hydraulic arm kept on working and [killed him]. This ... would not have happened in a world in which robot behavior was governed by the Three Laws of Robotics"
Um. The three laws of robotics don't say that robots must be omniscient. If the robot doesn't sense the human, then three laws or no three laws, it's not going to behave any differently. Grumble grumble ignorant invocation of laws mumble.
Nobody should be killed. Even Bush.
So what's the point of all these new privacy-violating laws and processes, then?
Galeon uses the same rendering engine as Firefox. (Though come to think of it, the fact that you saw the protocol at all is a bug -- Gecko embedders like Galeon, Firefox, etc, are supposed to hide the wyciwyg addresses. Firefox probably does a better job of hiding them, since I've not seen them in Firefox in recent versions.)
wyciwyg is "what you *cache* is what you get" and is the protocol Firefox uses to reference pages created purely using document.write().
GOODNESS GRATIOUS! God forbid you might have to WALK for 15 minutes several times a day!!! Whatever would the world come to!!!
I'm your average not-a-huge-console-fan consumer and the only thing I care about is the next GTA. Doesn't matter what the specs of the console are -- whichever console runs the next GTA is the one that I'm getting.
Not sure what you mean about overloading the class attribute... Could you expand on this?
Also, as far as I can tell XHTML2 introduces more new elements than HTML5, so I'm not sure that's a good argument. (Steven didn't list all the new elements in his talk though.)
Still, if you think we should remove some of the new elements, e-mail the WHATWG list. All input is taken into account (eventually).
(Disclaimer: I'm the editor of HTML5.)
Web Apps 1.0 (the spec) defines two languages: HTML5, which is a revision of HTML4, and XHTML5, which is a revision of XHTML1. They have the exact same semantics, just like HTML4 and XHTML1 are exactly the same semantics, the only difference is that HTML5 is sent as text/html and must be parsed as described in the spec, and XHTML5 is sent as application/xhtml+xml and must be parsed as described in the XML spec.
This might be a bit confusing. Basically XHTML5 is XML-compliant, and HTML5 is tag-soup-compliant. You can use either one, the spec doesn't care and doesn't prefer one over the other.
(Of course if you want your docs to work in IE, then I guess HTML5 is going to be more interesting to you.)
Regarding presentational tags; <pre>, <small> and <m> are defined in very semantic ways, and are not presentational. If you disagree, I encourage you to e-mail the list where this can be discussed and any problems you raise will be fixed.
Anyway, I hope this helps clear some things up.
I wish. Sadly, Microsoft are the only major browser vendor who aren't involved in the development of HTML5 (though they've been invited several times).
It has nothing to do with "cool"; SVG happens to be easier for us to produce than bitmaps, and anyone who is going to be able to read this report and view graphics will be using an SVG-capable browser. The fact that it found bugs in every SVG browser out there is merely a bonus, it means that SVG support will get better.
We used standards. It's not our fault if there was only one released browser that supported those standards well enough for you to be able to see the graphics.
"" is the HTML5 DOCTYPE, and HTML5 is why I did the study, so yeah, I used the HTML5 DOCTYPE. I don't see what's wrong with that. :-)
:-)
I didn't specify a character encoding because I used US-ASCII, which is the default for text/html, and which is also a subset of UTF-8, which is the default for image/svg+xml and text/css. Thus there was no need to set it. Nothing wrong there.
As for the entity for ">", there is no reason to use it. It takes longer to type, and is harder to maintain. Why would it be stupid?
And finally, TFA actually explicitly mentions the fact that Google's pages as a whole don't validate, in the very first paragraph. We know.
You need to chill, dude. Go play some games or something.
It did. It's third on the "name" chart, fourth on the combined chart. Or did I misunderstand your question?
Yeah, I misspoke on this. Set-Cookie is insecure (due to domain-crossing problems -- should a cookie sent to a.b.c get sent to z.b.c? Depends on "b" and "c" in ways that depend on month-to-month political changes around the globe), but as far as I can tell, Set-Cookie2 is also insecure. I had thought it fixed this, but apparently not.
Actually the type pseudo-attribute is optional on ; see the errata.
Yeah, you're right. I should have been more careful in my wording here. Still, you got the point I was trying to make! :-)
Actually, Mozilla has supported it for about 5 or 6 years now. Still, yeah, the other browsers, not so much. In fact it was dropped from the HTTP spec due to lack of implementations.
As other people pointed out, I meant the HTTP Link: header, not the HTML element.
But as to who wrote the study... well... I'm on the CSS working group. And the WHAT working group. Make of that what you will.
lol.
Yeah, that was a typo, we meant
.
was 97th. Used more often than , , , , , , , and ...
Yes it is SO unrealistic to think that people might be so influenced by video games that they might actually ACT OUT the plot of such a video game in real life. That would never actually happen.
http://www.pacmanhattan.com/
Never.