Nice to see that they forgot that the MIME type for JavaScript is "application/javascript"...
Forgot? The media types for JavaScript were only standardised this year. Before April, application/javascript was merely a common convention - and actually a less common convention than text/javascript, which is also an acceptable (if deprecated) media type for JavaScript according to the RFC.
So a) there wasn't anything to "forget", and b) they aren't doing anything wrong anyway.
Not to be the jerk here, but it really shouldn't be that big of a news story that some people discussed the idea that it might not be the best security practice to allow unvalidated user input.
Exactly. This is a minor variation on the same old mistakes web developers usually make. It's just that a lot of developers seem to have forgotten that Atom and RSS feeds need to be sanitised just as much as any other untrusted input.
This is by no means a new concept; off the top of my head, I remember Mark Pilgrim talking about this three years ago, and I remember thinking how damn obvious it was back then and being surprised that it was news to people.
I think one of the contributing factors is that a lot of borderline incompetent developers have learned to sanitise form input not because they understand the problem, but because they've simply had it hammered into their heads that they need to sanitise stuff that comes in through forms. Given a different form of input with exactly the same problem, they don't recognise that they need to sanitise it because it's not coming in through a form. They haven't learned why the problem exists, they've just memorised "form data == sanitise".
What's your point? Just because something was used back in the dark ages doesn't mean it's acceptable today.
Correct me if I'm wrong, but the Beatles' music is still considered to be good music, and is still being bought. If you agree with that, then surely you can agree that music of similar production quality is also commercially viable.
Sure, the Internet helped them gain some popularity, but as soon as they did, they signed with a real label.
After becoming a commercial success, including numerous sell-out gigs, including the Astoria. It's also worth noting that their initial success without a label is what enabled them to hold out for a decent record deal instead of compromising their artistic ideals.
You're joking, right? Have you ever heard of mp3.com? That was EXACTLY their business model.
MP3.com's business model was to stream on demand for free, and after a while they paid artists for the streaming. I'm saying that the value is in getting public attention and aggregating the content appropriately for each individual. MP3.com weren't very good at either of those things and didn't even really attempt the latter, but Google have a successful track record in this respect.
Do you think this is some brainstorm that only you have had?
Of course not, and if you weren't so eager to flame, you'd realise that. Go back and re-read my comment again. It revolves around Google having the necessary experience and market position to pull it off, not about how I've had a wonderful new idea.
The problem is that the vast majority of amateur music totally sucks.
Hence the reason why an Audioscrobbler-like scheme and Google's ranking/aggregation experience are so important.
You seem to think that all record companies do is stamp out CDs, with maybe a little promotion.
I think that's their primary purpose and all they are necessary for.
One of the big thing record companies provide is production values. Not everyone can afford that million dollar studio. Generally, not only does garage music suck, but sounds sucky as well.
You don't need a million dollar studio to make good music. The technology available cheaply to today's garage bands is better than the technology used by the Beatles to sell millions of records.
There's a reason that no web-based band has achieved mainstream popularity
Define "mainstream popularity". The Arctic Monkeys seems to be doing alright for themselves.
even after all these years of supposed technology to "bypass" the major labels.
Available technology to bypass the major labels doesn't matter. It only matters when somebody actually applies that technology. As far as I'm aware, nobody's tried to do what I described Google as being capable of. Not many companies have the relevant experience and market position.
Is it really though, or are particular business models involving digital music the real problem?
Let me elaborate. The model iTunes uses is closed and totally dependent upon the major record labels. What they say goes because Apple are simply taking what the record companies provide. Unfortunately, what they say is pretty user unfriendly, and what they say in the future can get even worse - to the point where they could just say "stop selling our music altogether" and Apple couldn't do anything about it.
Google aren't generally about providing content themselves, they are more about indexing and facilitating. They have proven that they can get public attention as an aggregation service with Google News. They have an advertising model with Adsense. They have a method of payment just rolling out now. They already stream data on a massive basis with Google Video.
What I'm saying is that they have the necessary experience and technology to be the middle-man between the artists and the fans - the job the record companies are supposed to be doing themselves. At the moment, the major labels have the industry tied up because to get public attention you need airplay, and that costs. But with a Google News-style music portal that's personalised to your tastes (like Audioscrobbler), this needn't be the case.
When you read something on Google News, it doesn't matter if it's coming from a major newspaper or a small virtual publisher - you are giving them your attention simply by virtue of it being on Google News. The same goes for airplay - it doesn't matter if you don't hear an unsigned band on the radio if you are listening to Google Radio (or whatever) already.
It's the ability of the record labels to monopolise public attention that is causing the real problems within the industry - and Google have a decent shot at not only breaking that, but making it financially viable for smaller bands to get new fans and sell directly to them online. They have all the pieces, it's just a case of whether they are willing to put them together.
I'd just vote for their opponent, but sometimes I'm getting called by both sides.
A perfect example of the fundamental problem with American democracy. The two major parties both stink, but you won't even consider voting for anybody else, to the point where you actually forget other parties exist. Both sides? You really think there are only two candidates? Go ahead and vote for Kodos.
Give us a simple, complete page that uses AJAX and is still compatible with non-AJAX browsers.
Off the top of my head: Google Suggest. The same page offers enhanced Ajax functionality and still works in Lynx, without any need for two pages or radically different layouts.
The ways you make Ajax work in a backwards-compatible manner are the same techniques decent JavaScript developers have been using for years. Unfortunately, not a lot of people are aware of JavaScript best practices and the field is still dominated by people who concentrate on making it work in their favourite browser and then bodging it to work elsewhere, rather than starting from a good solid design and enhancing it in a structurally sound manner.
If you're interested in learning more, I suggest DOM Scripting and the DOM Scripting Task Force website as decent starting points. I haven't read the book, but I've heard a lot of good things about it from people who know what they are talking about.
I think the more limiting issue is that it is so hard to do AJAX across domains. XMLHttpRequest doesn't work, nor do hidden iframes.
Not true - there's a trick to get around iframe cross-domain security. You can still see the URIs of the frame. This means that the domain you are attempting to access can supply a special page that calls XMLHttpRequest on your behalf and streams the data to you by updating the fragment identifier.
Sorry, I wasn't very clear there. My problem isn't simply with <button> (although <input type="submit"> is better supported by browsers, which is critical, and it submits the wrong data in Internet Explorer as you point out), but rather that practically everybody who uses it uses it instead of the mandatory action attribute on the <form> element - in essence, throwing away the HTML functionality and replacing it with less compatible JavaScript. I've simply never seen anybody use <button> with a properly coded form.
For one, hooking into the 'onsubmit' form event is a recipie for disaster - the event behaves entirely unpredictably across different browsers. Some allow you to cancel it, some don't, others only in certain situations.
Which browsers would these be? I find that the submit event can be reliably cancelled if you take into account a) DOM-capable browsers, b) Internet Explorer, and c) other old-fashioned browsers. There's three different ways of cancelling an event, are you sure you aren't forgetting one of them?
Anyone who has done AJAX in any reasonable amount knows, it is just too different a paradigm to integrate alongside an old HTML 4.0 compatable page in any resonable way.
I disagree. As long as you get the foundation right, it's easier, less buggy and more user-friendly to have a single codebase instead of having to maintain two separate versions. But that's dependent on getting the foundation right, and from what I can see, not many web developers do because they jump in and start learning JavaScript before they've finished learning HTML.
I don't know what you mean by "old HTML 4.0 compatible page". Ajax is completely compatible with HTML 4, I use it with HTML 4, they aren't competing technologies, they are complementary technologies, even when you create an interface that's totally dependent on Ajax, you're still working within the HTML 4 framework.
With AJAX, you usually want a totally different layout, and a totally different way to display information.
Sometimes this is the case, but it's rare. A list of items is still a list of items regardless of whether you click a button to rearrange them or drag and drop them. A form to fill out is still a form to fill out, even if the username is dynamically checked while you're still filling out the rest of the page. A list of search results is still a list of search results, even if it gets displayed while you are still typing your query. An unread message counter is still just a number regardless of whether it's updated when you refresh the page or every few seconds.
Ajax isn't usually used to create a radically different interface, just to streamline and speed up an existing interface. Even when the layout is different, that's usually a case of linking in another stylesheet, not radically altering the page itself.
The number of browsers that support AJAX is small enough that you can redirect them to the fancy site based on the User-Agent.
Horrible idea. Even if you detect the user-agent reliably (most people don't), that doesn't tell you whether it supports Ajax. I already mentioned one case where this would break - when ActiveX is disabled in Internet Explorer. Like I already said - browser detection is stupid and wrong. If you're going to go to the trouble of creating two entirely different versions, at least have the good sense to pick the right one properly.
I'm participating in an AJAX adaptation of/.'s comment page.
If you're talking about the University of Michigan's work, firstly, I'm not sure Slashdot are actually going to use anything like that, I think it's just research. But as well as that, I've been a web developer since the late 90s, and in all that time I don't think I've ever seen anything presented to an end user that is half as buggy and non-functional as that new comment system. It's horrendous.
P.S.: Does anyone know of a way to get a paragraph break without wrapping the entire paragraph in <P> and </P> tags?
It's impossible to give you advice on the matter because you've left the most important piece of information out: what is it that you are marking up? It sounds like either you do actually want <p> elements or you don't want a paragraph break, but a vertical margin/padding. A paragraph break, by definition, is a break between two paragraphs.
Zero credibility points for trying to put markup in the <title> element and hiding the printable version behind a javascript:void(0) link.
If you want the technical stuff, skip about a third of the way down. The first third of the article just repeatedly tells you that Ajax is when the page doesn't "blink".
The code he supplies is crap. For instance:
<html> <head>
<title>HTMLfs</title> </head> <framese t rows="100%,*"> <frame name="visible_frame" src="visible.htm"> <frame name="hidden_frame" src="hidden.htm"> <noframes>Frames are required to use this Web site.</noframes>
Things wrong with even this tiny snippet of code:
Invalid.
Frames (at the very least, he should have used iframes).
Cheesy "fuck off" error message instead of functional equivalent.
Skimming the rest of the article, I see the following mistakes:
Using DOM methods without testing for their existence.
Obtrusive JavaScript embedded in the page with old-fashioned HTML attributes.
Non-degradable JavaScript form submission with <button> instead of <submit>.
Confusion over what elements and tags are.
Internet Explorer-only code without error checking or a fallback.
If this is a representative sample of the book it is excerpted from, steer well clear of it. The whole approach is poor.
The best way of producing compatible, accessible Ajax applications is to start with the bare HTML and make that work. Only then do you add the JavaScript, and you do it by enhancing the page, not replacing it. For instance, don't use <button onclick="...">, use a normal <input type="submit"> and hook into the form's submit event. That way:
It works when JavaScript is unavailable.
It works when there's a problem in your code.
It works when you find you can't do something halfway through processing the event (e.g. you find that ActiveX is switched off in Internet Explorer, making XMLHttpRequest unavailable).
Even with a large team of grad students at their disposal, researchers find it difficult to tag more than a small subset of the speeches in question
Are there really that many speeches? TheyWorkForYou.com offer a similar service for the UK's Houses of Parliament, except it's done manually, and there's only a dozen volunteers working on it.
Re:What will make KDE the perfect desktop...
on
KDE 3.5.4 Released
·
· Score: 1
The issue you are having is not a kde problem.
It's not me that's having the issue, I'm merely responding to somebody that was saying that having everything lumped into one big package is fine because everybody has lots of disk space.
Re:Wow, they're actually _doing_ something
on
KDE 3.5.4 Released
·
· Score: 1
Agreed, that's useful. The disappointing thing is that this is something that web developers can fix, without waiting for browser support, simply by adding a CSS signature to their sites. Usually web developers are stuck waiting for browser support, but in this case they are not and there's really no excuse not to include them.
Re:What will make KDE the perfect desktop...
on
KDE 3.5.4 Released
·
· Score: 1
With todays large harddisks this is hardly any problem, and not worth the package maintainers
time to split the packages into even more packages.
Not many people care about disk space. But do you really want to download and compile a whole collection of packages whenever a tiny bug is fixed anywhere in that collection?
I only use KWordQuiz from the KDE Education collection. That's ~500KB. I don't want to download and compile ~30MB of source whenever a bug is fixed in any of the applications in the Education collection, especially when the chancs are that none of the changes are in anything I use. I just want to update a small utility when that small utility is updated.
Re:Wow, they're actually _doing_ something
on
KDE 3.5.4 Released
·
· Score: 1
Opera have supported replaced content for a few years.
I have to disagree there. I don't know what the web designer was thinking, but he was adding generated content to an <i> element and expecting it not to be rendered because CSS 2 limits generated content to the:before and:after pseudo-elements. Of course, CSS 3 doesn't have this limitation, so the content is rendered by CSS 3 user-agents.
So basically, the designer added generated content, expected it to be ignored, and then complained when it wasn't ignored. The bug is the web designer's, not Konqueror's. He should have just not added the generated content in the first place if he didn't want it. Is this a CSS hack? It seems like an awfully fragile one compared with the more usual hacks.
Re:Wow, they're actually _doing_ something
on
KDE 3.5.4 Released
·
· Score: 4, Insightful
If KHTML had better user CSS support I'd switch right now.
What do you mean? Konqueror has had good user stylesheet support for years. Settings | Configure Konqueror | Stylesheets. You can specify your own user stylesheet, or there's a dialog box to set up a new stylesheet in a user-friendly manner.
Speaking of CSS, this new version has improved support for various parts of CSS 3. In particular, as far as I know, no other browser has implemented the CSS 3 replaced content model yet, which is one thing that can singlehandedly wipe out massive amounts of unnecessary HTML and JavaScript for things like rounded corners, image replacement, etc.
An infix is an affix inserted inside another morpheme. This is not uncommon in Austronesian and Austroasiatic languages. For example, the Tagalog language has borrowed the English word graduate as a verb. In this language, a grammatical form similar to the active voice is formed by adding the infix -um- to the first syllable of a verb, so a speaker saying "I graduated" uses the derived form grumaduate. The Semitic languages have a form of ablaut (changing the vowels within words, as in English sing, sang, sung, song) which is sometimes called infixation, but there is often no identifiable infix common across the vocabulary.
English has very few infixes, and those it does have are marginal. A few are heard in colloquial speech, and a couple more are found in technical terminology.
We're customers of the parent organisation, JohnCompanies, and I can't recommend them highly enough. The thing that makes them stand out in my opinion is the support, you don't get clueless newbies reading from an FAQ like you do with every other hosting provider I've ever encountered.
I've been looking for an excuse to try out rsync.net, it seems like an interesting service, for example it offers WebDAV access, which is built into Windows, OS X and KDE.
Yeah, I know I sound like a fanboy or astroturfer, but I don't care, it's really rare to find a company that actually gets it so right when there are so many incompetents around, especially in the hosting business.
The harm, as the judge in this case sees it, is to the first ammendment. I happen to agree with him.
Really? I don't see it infringing on anybody's right to freedom of expression. The games would still be on sale, people would still buy them. It's not like there's book burning going on, the games would still be widely available.
There's already plenty of restrictions on freedom of speech, but people from the USA have the curious practice of referring to speech that is undesirable as not being speech, which I hope you can see is ludicrous. Freedom of speech is not absolute, it never was, and it isn't desirable unless you condone slander, libel, shouting fire in a crowded theatre, etc.
Unfortunately this "unspeech" labelling prevents a lot of people from acknowledging that sometimes restrictions on speech are a good thing - which is a fact that they already accept, but cannot recognise due to the speech/unspeech notion. I think the Fourth Amendment undermines itself somewhat by being worded so absolutely. It's impractical to implement it literally, and this causes the "unspeech" notion which is a convenient loophole that can be abused.
No, I don't belive that they always act in accordance with parent's wishes. But I do belive that teenagers that have been taught right from wrong, and have a good, trusting relationship with their parent's aren't really going to be harmed by playing GTA or some such game.
I've not argued from the position that the games are harmful, because I don't particularly think they are. I'm specifically focusing my argument around the right of the parents to be able to decide whether their children play violent games or not. I might not believe that the games are harmful, but I recognise that many parents disagree and I believe that they should have the decision rather than being usurped by shopkeepers.
To be perfectly honest, I don't think even an 18 year old should really be able to put something by you. Lord knows I tried often enough when I was 18, but Dad still knew the score, even without watching me like a hawk 24/7.
Really? I rarely had a problem getting things past my parents when I was thirteen, they were hardly stupid or inattentive, and I was a pretty good kid.
I see that as requiring *someone else* to mitigate what *they* can.
Sure. There are all kinds of laws that require other people to do things for another person's benefit. Tax is an obvious one. And, a more relevant example, it's illegal to sell kids alcohol and nicotine, and if a parent has enough control over their kids' lives to prevent them from playing violent games, then they've got enough control over their kids' lives to stop them from drinking and smoking. And yet in that case, not many people have a problem with somebody else dealing with that problem when the parents can theoretically do so.
IMO, too many people look to the law for services that should be provided by the parent or a chosen and hired nanny.
How many parents do you think can afford a nanny? I don't think it's reasonable for society to simply tell poor parents that they are on their own when it comes to raising their children.
if you have a sneaky kid, it's gaming in the family room or not at all. This isn't rocket science.
You are still assuming that you are always home when they are home. A reasonable assumption for small children, but not for teenagers.
Really, these are young children we're talking about here, not evil genuses.
I'm thinking about teenagers rather than really small children. Old enough to have a bit of money from a paper round or something, but young enough for it still to be acceptable for their parents to decide whether they should be playing violent games or not.
And heaven forbid you actualy build a relationship with the child you're raising, one where they know right from wrong, and don't feel the need to constantly sneak things by you.
Sure, but I hope you aren't under the impression that kids always act in accordance with their parents' wishes, even if they have a good relationship and have been raised well.
My point is, of all the things that a parent needs to watch out for in a child's life, video games are a minor, and easily monitored one. It's really not that hard, and we really don't need the government's help with it.
The way I see it, you need to compare potential benefit against potential harm.
One benefit is that it makes it easier for parents who don't want their kids playing violent games to enforce this rule. Another benefit is that it makes it less likely that kids whose parents don't care will play the game.
As for the harm... where is it? It doesn't tell you how you should parent, your kids can still play those games if you buy them for him. And I don't accept the claim in another reply that it causes "suffering".
All in all, I think there are positive aspects to this law and negligable downsides. Sure, you might feel like you might not need the government's help, but there are definitely people who do want it, and it doesn't cause you any harm.
Slashdot Mirror
Forgot? The media types for JavaScript were only standardised this year. Before April, application/javascript was merely a common convention - and actually a less common convention than text/javascript, which is also an acceptable (if deprecated) media type for JavaScript according to the RFC.
So a) there wasn't anything to "forget", and b) they aren't doing anything wrong anyway.
Exactly. This is a minor variation on the same old mistakes web developers usually make. It's just that a lot of developers seem to have forgotten that Atom and RSS feeds need to be sanitised just as much as any other untrusted input.
This is by no means a new concept; off the top of my head, I remember Mark Pilgrim talking about this three years ago, and I remember thinking how damn obvious it was back then and being surprised that it was news to people.
I think one of the contributing factors is that a lot of borderline incompetent developers have learned to sanitise form input not because they understand the problem, but because they've simply had it hammered into their heads that they need to sanitise stuff that comes in through forms. Given a different form of input with exactly the same problem, they don't recognise that they need to sanitise it because it's not coming in through a form. They haven't learned why the problem exists, they've just memorised "form data == sanitise".
Correct me if I'm wrong, but the Beatles' music is still considered to be good music, and is still being bought. If you agree with that, then surely you can agree that music of similar production quality is also commercially viable.
After becoming a commercial success, including numerous sell-out gigs, including the Astoria. It's also worth noting that their initial success without a label is what enabled them to hold out for a decent record deal instead of compromising their artistic ideals.
MP3.com's business model was to stream on demand for free, and after a while they paid artists for the streaming. I'm saying that the value is in getting public attention and aggregating the content appropriately for each individual. MP3.com weren't very good at either of those things and didn't even really attempt the latter, but Google have a successful track record in this respect.
Of course not, and if you weren't so eager to flame, you'd realise that. Go back and re-read my comment again. It revolves around Google having the necessary experience and market position to pull it off, not about how I've had a wonderful new idea.
Hence the reason why an Audioscrobbler-like scheme and Google's ranking/aggregation experience are so important.
I think that's their primary purpose and all they are necessary for.
You don't need a million dollar studio to make good music. The technology available cheaply to today's garage bands is better than the technology used by the Beatles to sell millions of records.
Define "mainstream popularity". The Arctic Monkeys seems to be doing alright for themselves.
Available technology to bypass the major labels doesn't matter. It only matters when somebody actually applies that technology. As far as I'm aware, nobody's tried to do what I described Google as being capable of. Not many companies have the relevant experience and market position.
Is it really though, or are particular business models involving digital music the real problem?
Let me elaborate. The model iTunes uses is closed and totally dependent upon the major record labels. What they say goes because Apple are simply taking what the record companies provide. Unfortunately, what they say is pretty user unfriendly, and what they say in the future can get even worse - to the point where they could just say "stop selling our music altogether" and Apple couldn't do anything about it.
Google aren't generally about providing content themselves, they are more about indexing and facilitating. They have proven that they can get public attention as an aggregation service with Google News. They have an advertising model with Adsense. They have a method of payment just rolling out now. They already stream data on a massive basis with Google Video.
What I'm saying is that they have the necessary experience and technology to be the middle-man between the artists and the fans - the job the record companies are supposed to be doing themselves. At the moment, the major labels have the industry tied up because to get public attention you need airplay, and that costs. But with a Google News-style music portal that's personalised to your tastes (like Audioscrobbler), this needn't be the case.
When you read something on Google News, it doesn't matter if it's coming from a major newspaper or a small virtual publisher - you are giving them your attention simply by virtue of it being on Google News. The same goes for airplay - it doesn't matter if you don't hear an unsigned band on the radio if you are listening to Google Radio (or whatever) already.
It's the ability of the record labels to monopolise public attention that is causing the real problems within the industry - and Google have a decent shot at not only breaking that, but making it financially viable for smaller bands to get new fans and sell directly to them online. They have all the pieces, it's just a case of whether they are willing to put them together.
A perfect example of the fundamental problem with American democracy. The two major parties both stink, but you won't even consider voting for anybody else, to the point where you actually forget other parties exist. Both sides? You really think there are only two candidates? Go ahead and vote for Kodos.
You can make Internet Explorer treat local web pages as if they were remote by giving them the mark of the web.
Off the top of my head: Google Suggest. The same page offers enhanced Ajax functionality and still works in Lynx, without any need for two pages or radically different layouts.
The ways you make Ajax work in a backwards-compatible manner are the same techniques decent JavaScript developers have been using for years. Unfortunately, not a lot of people are aware of JavaScript best practices and the field is still dominated by people who concentrate on making it work in their favourite browser and then bodging it to work elsewhere, rather than starting from a good solid design and enhancing it in a structurally sound manner.
If you're interested in learning more, I suggest DOM Scripting and the DOM Scripting Task Force website as decent starting points. I haven't read the book, but I've heard a lot of good things about it from people who know what they are talking about.
Not true - there's a trick to get around iframe cross-domain security. You can still see the URIs of the frame. This means that the domain you are attempting to access can supply a special page that calls XMLHttpRequest on your behalf and streams the data to you by updating the fragment identifier.
It's an awful hack, but it's been wrapped up in an XMLHttpRequest emulation by Dojo.
Looking further ahead, there's already a proper model for cross-domain communication, and Opera already supports it.
Sorry, I wasn't very clear there. My problem isn't simply with <button> (although <input type="submit"> is better supported by browsers, which is critical, and it submits the wrong data in Internet Explorer as you point out), but rather that practically everybody who uses it uses it instead of the mandatory action attribute on the <form> element - in essence, throwing away the HTML functionality and replacing it with less compatible JavaScript. I've simply never seen anybody use <button> with a properly coded form.
Which browsers would these be? I find that the submit event can be reliably cancelled if you take into account a) DOM-capable browsers, b) Internet Explorer, and c) other old-fashioned browsers. There's three different ways of cancelling an event, are you sure you aren't forgetting one of them?
I disagree. As long as you get the foundation right, it's easier, less buggy and more user-friendly to have a single codebase instead of having to maintain two separate versions. But that's dependent on getting the foundation right, and from what I can see, not many web developers do because they jump in and start learning JavaScript before they've finished learning HTML.
I don't know what you mean by "old HTML 4.0 compatible page". Ajax is completely compatible with HTML 4, I use it with HTML 4, they aren't competing technologies, they are complementary technologies, even when you create an interface that's totally dependent on Ajax, you're still working within the HTML 4 framework.
Sometimes this is the case, but it's rare. A list of items is still a list of items regardless of whether you click a button to rearrange them or drag and drop them. A form to fill out is still a form to fill out, even if the username is dynamically checked while you're still filling out the rest of the page. A list of search results is still a list of search results, even if it gets displayed while you are still typing your query. An unread message counter is still just a number regardless of whether it's updated when you refresh the page or every few seconds.
Ajax isn't usually used to create a radically different interface, just to streamline and speed up an existing interface. Even when the layout is different, that's usually a case of linking in another stylesheet, not radically altering the page itself.
Horrible idea. Even if you detect the user-agent reliably (most people don't), that doesn't tell you whether it supports Ajax. I already mentioned one case where this would break - when ActiveX is disabled in Internet Explorer. Like I already said - browser detection is stupid and wrong. If you're going to go to the trouble of creating two entirely different versions, at least have the good sense to pick the right one properly.
If you're talking about the University of Michigan's work, firstly, I'm not sure Slashdot are actually going to use anything like that, I think it's just research. But as well as that, I've been a web developer since the late 90s, and in all that time I don't think I've ever seen anything presented to an end user that is half as buggy and non-functional as that new comment system. It's horrendous.
It's impossible to give you advice on the matter because you've left the most important piece of information out: what is it that you are marking up? It sounds like either you do actually want <p> elements or you don't want a paragraph break, but a vertical margin/padding. A paragraph break, by definition, is a break between two paragraphs.
Print version here.
Zero credibility points for trying to put markup in the <title> element and hiding the printable version behind a javascript:void(0) link.
If you want the technical stuff, skip about a third of the way down. The first third of the article just repeatedly tells you that Ajax is when the page doesn't "blink".
The code he supplies is crap. For instance:
Things wrong with even this tiny snippet of code:
Skimming the rest of the article, I see the following mistakes:
If this is a representative sample of the book it is excerpted from, steer well clear of it. The whole approach is poor.
The best way of producing compatible, accessible Ajax applications is to start with the bare HTML and make that work. Only then do you add the JavaScript, and you do it by enhancing the page, not replacing it. For instance, don't use <button onclick="...">, use a normal <input type="submit"> and hook into the form's submit event. That way:
Are there really that many speeches? TheyWorkForYou.com offer a similar service for the UK's Houses of Parliament, except it's done manually, and there's only a dozen volunteers working on it.
It's not me that's having the issue, I'm merely responding to somebody that was saying that having everything lumped into one big package is fine because everybody has lots of disk space.
Agreed, that's useful. The disappointing thing is that this is something that web developers can fix, without waiting for browser support, simply by adding a CSS signature to their sites. Usually web developers are stuck waiting for browser support, but in this case they are not and there's really no excuse not to include them.
Not many people care about disk space. But do you really want to download and compile a whole collection of packages whenever a tiny bug is fixed anywhere in that collection?
I only use KWordQuiz from the KDE Education collection. That's ~500KB. I don't want to download and compile ~30MB of source whenever a bug is fixed in any of the applications in the Education collection, especially when the chancs are that none of the changes are in anything I use. I just want to update a small utility when that small utility is updated.
You're right, it used to be called -replace and -o-replace. Thanks for the pointer.
I have to disagree there. I don't know what the web designer was thinking, but he was adding generated content to an <i> element and expecting it not to be rendered because CSS 2 limits generated content to the :before and :after pseudo-elements. Of course, CSS 3 doesn't have this limitation, so the content is rendered by CSS 3 user-agents.
So basically, the designer added generated content, expected it to be ignored, and then complained when it wasn't ignored. The bug is the web designer's, not Konqueror's. He should have just not added the generated content in the first place if he didn't want it. Is this a CSS hack? It seems like an awfully fragile one compared with the more usual hacks.
What do you mean? Konqueror has had good user stylesheet support for years. Settings | Configure Konqueror | Stylesheets. You can specify your own user stylesheet, or there's a dialog box to set up a new stylesheet in a user-friendly manner.
Speaking of CSS, this new version has improved support for various parts of CSS 3. In particular, as far as I know, no other browser has implemented the CSS 3 replaced content model yet, which is one thing that can singlehandedly wipe out massive amounts of unnecessary HTML and JavaScript for things like rounded corners, image replacement, etc.
You're wrong about that - Infix:
We're customers of the parent organisation, JohnCompanies, and I can't recommend them highly enough. The thing that makes them stand out in my opinion is the support, you don't get clueless newbies reading from an FAQ like you do with every other hosting provider I've ever encountered.
I've been looking for an excuse to try out rsync.net, it seems like an interesting service, for example it offers WebDAV access, which is built into Windows, OS X and KDE.
Yeah, I know I sound like a fanboy or astroturfer, but I don't care, it's really rare to find a company that actually gets it so right when there are so many incompetents around, especially in the hosting business.
First Amendment, of course, not Fourth Amendment.
Really? I don't see it infringing on anybody's right to freedom of expression. The games would still be on sale, people would still buy them. It's not like there's book burning going on, the games would still be widely available.
There's already plenty of restrictions on freedom of speech, but people from the USA have the curious practice of referring to speech that is undesirable as not being speech, which I hope you can see is ludicrous. Freedom of speech is not absolute, it never was, and it isn't desirable unless you condone slander, libel, shouting fire in a crowded theatre, etc.
Unfortunately this "unspeech" labelling prevents a lot of people from acknowledging that sometimes restrictions on speech are a good thing - which is a fact that they already accept, but cannot recognise due to the speech/unspeech notion. I think the Fourth Amendment undermines itself somewhat by being worded so absolutely. It's impractical to implement it literally, and this causes the "unspeech" notion which is a convenient loophole that can be abused.
I've not argued from the position that the games are harmful, because I don't particularly think they are. I'm specifically focusing my argument around the right of the parents to be able to decide whether their children play violent games or not. I might not believe that the games are harmful, but I recognise that many parents disagree and I believe that they should have the decision rather than being usurped by shopkeepers.
Really? I rarely had a problem getting things past my parents when I was thirteen, they were hardly stupid or inattentive, and I was a pretty good kid.
Sure. There are all kinds of laws that require other people to do things for another person's benefit. Tax is an obvious one. And, a more relevant example, it's illegal to sell kids alcohol and nicotine, and if a parent has enough control over their kids' lives to prevent them from playing violent games, then they've got enough control over their kids' lives to stop them from drinking and smoking. And yet in that case, not many people have a problem with somebody else dealing with that problem when the parents can theoretically do so.
How many parents do you think can afford a nanny? I don't think it's reasonable for society to simply tell poor parents that they are on their own when it comes to raising their children.
You are still assuming that you are always home when they are home. A reasonable assumption for small children, but not for teenagers.
I'm thinking about teenagers rather than really small children. Old enough to have a bit of money from a paper round or something, but young enough for it still to be acceptable for their parents to decide whether they should be playing violent games or not.
Sure, but I hope you aren't under the impression that kids always act in accordance with their parents' wishes, even if they have a good relationship and have been raised well.
The way I see it, you need to compare potential benefit against potential harm.
One benefit is that it makes it easier for parents who don't want their kids playing violent games to enforce this rule. Another benefit is that it makes it less likely that kids whose parents don't care will play the game.
As for the harm... where is it? It doesn't tell you how you should parent, your kids can still play those games if you buy them for him. And I don't accept the claim in another reply that it causes "suffering".
All in all, I think there are positive aspects to this law and negligable downsides. Sure, you might feel like you might not need the government's help, but there are definitely people who do want it, and it doesn't cause you any harm.