It's thinking like yours that reminds me that the majority of the populace still views computers as means of playing games.
As long as there's a business world, the PC will exist, plain and simple. Whether as a thin or thick client, that's up to companies like IBM, Microsoft, and Sun.
I'd look into using RSS (Really Simple Syndication) with DC (Dublin Core) metadata.
I think the "coverage" tag would be probably what you're looking for.
If the memory is big enough
on
HD-Less PS3?
·
· Score: 2, Interesting
It shouldn't be too much of a concern, with a requisite "if".
If the memory cards are treated like a hard drive, there will be no problem, I can later swap in a HDD to store more data/access it quicker. If, however, the situation is similar to the one with the Playstation 2 (a hard drive evenutally came out and found little use since developers couldn't really count on one being there) then the PS3 will suffer for it and when a hdd is released, it won't see too much use.
Yours is a good point, though I'm not too big of a fan of forcing every page I write to be parsed with an engine first. (and no, I don't have access to the apache server httpd.conf/.htaccess file:( )
However, I did come across this little beauty that gives me a little hope. It seems you can indeed serve xhtml as application/xml in IE and make it work (of course, with a small workaround).
Soon of course, lynx will have to be updated in order to keep up with the times:)
XHTML does indeed mean easier parsing, if served with the correct mimetype. If you serve text/html, the parser has to be ready for all the crap of HTML, not the ease of parsing an XML document (unless you run all the incoming text/html into something like tidy, but that's cheating).
I'm not quite sure I understand your point about better code support in the future though, would you expound on that? Do you mean that this is the area where people are actively developing, so there will be better tools in the future, or what?
Namespaces do indeed rock. They make some tasks possible which were before impossible, and they provide a means to combine languages together in a way which wasn't possible before.
However, XHTML (in it's current form) totally breaks namespaces, since the mimetype of the document is text/html and the user agent only expects (or rather, should only expect) to be receiving text/html content (instead of a mish-mash of XML dialects).
I think namespaces are most useful (and powerful) in more controlled environment such as server-side applications (or even Ajax type stuff).
XHTML doesn't force you to do anything. I can make a page that passes a validator that's 8 nested tables deep that happily passed the w3c validator. There's absolutely no forcing there.
The only thing that XHTML forces you to do is stop using the font tag. That's pretty much it. Everything XHTML can do HTML 4 does and does it better (cuz existing UAs grok its mimetype).
The real promise of XHTML is the same as XML: being able to mix and match namespaces into a super-document. However, no user agents (except for some special builds of Mozilla) really accept embedded XML dialects (for an example, see SVG+XHTML on Mozilla's SVG site). This is changing in Firefox 1.1, but it won't have any real effect on the marketplace until the majority of user agents support it.
Short version: XHTML disables the use of the FONT tag and some attributes that should be done in CSS anyway.
The term's "semantic markup". Basically the notion is that using more descriptive tags can potentially tell user agents (be they browser or spider) a little bit more about the content.
However, it's not solely in XHTML. The tags exist in HTML 4.
I'm personally amazed that people talk so much about the strong and em tags so much when there's a ton of nicer introductions such as label and optgroup that get little to no press.
I don't understand why designers and technologians keep preaching XHTML. It's at best a kludge. Until you start serving XHTML documents with the correct mimetype (application/xhtml+xml I believe) XHTML provides no benefits over plain old HTML (provided you stick to the spec). Until then, User Agents will continue to accept whatever crap you throw at them, and since you're not using real XML you won't see any errors (except for the rendering).
I coordially invite someone to give me one reason why XHTML (in its current form, served as text/html or text/xml) is better than HTML 4.0 strict? Is closing my link and meta tags really that life-changing?
While I think the SP is quite good, I do find myself wishing it had bigger buttons and d-pad. That being said, the micro probably uses the same size or even smaller buttons, but it still looks beautiful.
I agree. I threw the XMA reference as a joke. My whole post was meant to be funny, not informative. Though I suppose that interesting might be an apt description. I'm pretty amazed it's gotten so modded up.
Well, since seeing Extreme Martial Arts on the Discovery Channel, I feel somewhat qualified to answer your post.
Jedi do both cut and slice, depending on your point of view. If by cut you are referring to the act of swinging a blade in order to sever (which would seem to line up with Musashi's samurai style) and by slice you refer to the act of swinging a blade in order to damage but not sever, then I would say that Jedi do both.
However, in my opinion, a slice by a lightsaber is fairly useless in the long run as any wounds incurred are instantly cauderized, so a prolonged fight would not bleed an opponent the way a traditional blade would.
Are you trying to break CSS with your markup there, or do you have a legitimate reason for making a table display inline? When you make an element inline and force it to contain non-inline children this kind of thing happens. It'd be the same as wrapping a table with a span and complaining that the span isn't being applied correctly.
Front side bus speed is another factor there. The iMac has only 533Mhz FSB, whereas the Powermac has 1/2 the clock FSB (1.8 Ghz => 900Mhz FSB).
But otherwise, yeah. For a totally different motherboard with more slots, faster FSB, Firewire 800 (which I WISH the iMac had), etc. is 200 dollars more.
So long as the code's easy to get involved with. Look at the Mozilla project, it's been fairly successful, but how many of its developers are non-Netscape people?
May I suggest you edit your profile and remove the "It's Funny Laugh" section out of your homepage? I mean, humor is subjective and all, but smile and move on!
Slashdot Mirror
It's thinking like yours that reminds me that the majority of the populace still views computers as means of playing games.
As long as there's a business world, the PC will exist, plain and simple. Whether as a thin or thick client, that's up to companies like IBM, Microsoft, and Sun.
I'd look into using RSS (Really Simple Syndication) with DC (Dublin Core) metadata.
I think the "coverage" tag would be probably what you're looking for.
It shouldn't be too much of a concern, with a requisite "if".
If the memory cards are treated like a hard drive, there will be no problem, I can later swap in a HDD to store more data/access it quicker. If, however, the situation is similar to the one with the Playstation 2 (a hard drive evenutally came out and found little use since developers couldn't really count on one being there) then the PS3 will suffer for it and when a hdd is released, it won't see too much use.
I never did finish the game. My patience runs out after about 40-50 hours for a game.
The story was quite involving though.
I take it you missed Dragon Warrior VII for the PS1?
How exactly do you define "niche?"
Cuz that's just exactly what you described.
Yours is a good point, though I'm not too big of a fan of forcing every page I write to be parsed with an engine first. (and no, I don't have access to the apache server httpd.conf/.htaccess file :( )
:)
However, I did come across this little beauty that gives me a little hope. It seems you can indeed serve xhtml as application/xml in IE and make it work (of course, with a small workaround).
Soon of course, lynx will have to be updated in order to keep up with the times
XHTML does indeed mean easier parsing, if served with the correct mimetype. If you serve text/html, the parser has to be ready for all the crap of HTML, not the ease of parsing an XML document (unless you run all the incoming text/html into something like tidy, but that's cheating).
I'm not quite sure I understand your point about better code support in the future though, would you expound on that? Do you mean that this is the area where people are actively developing, so there will be better tools in the future, or what?
Namespaces do indeed rock. They make some tasks possible which were before impossible, and they provide a means to combine languages together in a way which wasn't possible before.
However, XHTML (in it's current form) totally breaks namespaces, since the mimetype of the document is text/html and the user agent only expects (or rather, should only expect) to be receiving text/html content (instead of a mish-mash of XML dialects).
I think namespaces are most useful (and powerful) in more controlled environment such as server-side applications (or even Ajax type stuff).
XHTML doesn't force you to do anything. I can make a page that passes a validator that's 8 nested tables deep that happily passed the w3c validator. There's absolutely no forcing there.
The only thing that XHTML forces you to do is stop using the font tag. That's pretty much it. Everything XHTML can do HTML 4 does and does it better (cuz existing UAs grok its mimetype).
The real promise of XHTML is the same as XML: being able to mix and match namespaces into a super-document. However, no user agents (except for some special builds of Mozilla) really accept embedded XML dialects (for an example, see SVG+XHTML on Mozilla's SVG site). This is changing in Firefox 1.1, but it won't have any real effect on the marketplace until the majority of user agents support it.
Short version: XHTML disables the use of the FONT tag and some attributes that should be done in CSS anyway.
The term's "semantic markup". Basically the notion is that using more descriptive tags can potentially tell user agents (be they browser or spider) a little bit more about the content.
However, it's not solely in XHTML. The tags exist in HTML 4.
I'm personally amazed that people talk so much about the strong and em tags so much when there's a ton of nicer introductions such as label and optgroup that get little to no press.
I don't understand why designers and technologians keep preaching XHTML. It's at best a kludge. Until you start serving XHTML documents with the correct mimetype (application/xhtml+xml I believe) XHTML provides no benefits over plain old HTML (provided you stick to the spec). Until then, User Agents will continue to accept whatever crap you throw at them, and since you're not using real XML you won't see any errors (except for the rendering).
I coordially invite someone to give me one reason why XHTML (in its current form, served as text/html or text/xml) is better than HTML 4.0 strict? Is closing my link and meta tags really that life-changing?
While I think the SP is quite good, I do find myself wishing it had bigger buttons and d-pad. That being said, the micro probably uses the same size or even smaller buttons, but it still looks beautiful.
I agree. I threw the XMA reference as a joke. My whole post was meant to be funny, not informative. Though I suppose that interesting might be an apt description. I'm pretty amazed it's gotten so modded up.
Well, since seeing Extreme Martial Arts on the Discovery Channel, I feel somewhat qualified to answer your post.
Jedi do both cut and slice, depending on your point of view. If by cut you are referring to the act of swinging a blade in order to sever (which would seem to line up with Musashi's samurai style) and by slice you refer to the act of swinging a blade in order to damage but not sever, then I would say that Jedi do both.
However, in my opinion, a slice by a lightsaber is fairly useless in the long run as any wounds incurred are instantly cauderized, so a prolonged fight would not bleed an opponent the way a traditional blade would.
"entirely non-violent"? Is this the same guy who fashioned a whip and drove salesmen out of the temple?
Are you trying to break CSS with your markup there, or do you have a legitimate reason for making a table display inline? When you make an element inline and force it to contain non-inline children this kind of thing happens. It'd be the same as wrapping a table with a span and complaining that the span isn't being applied correctly.
Wow. You're right. That sucks. Also, I guess it's 1/3 clock for the iMac as well. (mine's a 1.6 Ghz so 533 is the FSB)
Front side bus speed is another factor there. The iMac has only 533Mhz FSB, whereas the Powermac has 1/2 the clock FSB (1.8 Ghz => 900Mhz FSB).
But otherwise, yeah. For a totally different motherboard with more slots, faster FSB, Firewire 800 (which I WISH the iMac had), etc. is 200 dollars more.
So long as the code's easy to get involved with. Look at the Mozilla project, it's been fairly successful, but how many of its developers are non-Netscape people?
I'm gonna go out on a limb here and say "Work on a Mac?"
"Maths" is a perfectly cromulent word (if speaking British English).
Chill out man, he didn't mean to insult Bubble Bobble ;)
Will moviegoers be treated to special movie-edition towels, or will our own be required for viewing?
Poor humorless bastard.
May I suggest you edit your profile and remove the "It's Funny Laugh" section out of your homepage? I mean, humor is subjective and all, but smile and move on!