Slashdot Mirror

I'd guess it's the blog writer:

W3 Validator says 71 standard violations for HTML 4.0 transitional.

First off... did anyone notice that his blog doesn't format correctly in firefox? It doesn't validate either.

Second, I like this choice line:

Do I really trust a bunch of kids at some random university I've never heard of?

Also, note the desperation in lines like "Hopefully, the average person will decide that they do not trust this web site, and they will click Cancel. No Firefox for you!" Wow. That's just pathetic.

Then he attacks " a numeric IP address " (his emphasis) as being the "bastion of spammers and phishers." I'm glad Microsoft doesn't have one [or 8].

Then he gets a series of strange and bizzare dialogue boxes. Now, I recently installed Firefox on my laptop, and had none of the problems he's described. It wasn't served off an unknown unversity site, I didn't have any "7-Zip" error box (probably because Microsoft isn't running my network), and I didn't have a blank dialogue box asking me to click OK or Cancel. I think that someone might want to suggest he reinstall XP. Seriously though, isn't there supposed to be a market incentive for Microsoft employees to be "innovating" better browsers than taking pot shots about the default selection in Firefox? The idea that you would reject Firefox on security grounds, and instead accept IE, is so surreally absurd it baffles the imagination. His contention is that the code isn't signed - nobody knows about it, but Microsoft's closed-source code is trustworthy because there's a corporation behind it, so therefore it's a clear issue of security.

Yeah, Bobby has some problems, and gets a couple of things outright wrong. But the major problem is the number of things that it just doesn't get at all.

A recent spanish study found that one site passed all the Bobby tests, but was completely inaccessible. There are tools out there designed to get people involved enough to do the right testing.

If anyone speaks spanish and PHP and wants to work with accessibility and RDF, developing an application called Hera (two parts - One for manual stuff that's slow and an auto-test that is of course incomplete then llama-me ...

"If you want to work on it then you need to do that PLUS you need to make it pass the Bobby Accessibility Guidelines".

Beware that just because something passes Bobby, it doesn't necessarily mean it's completely accessible. As the W3C themselves point out, there is no automated test that can prove or disprove that your site is accessible. Several people have come up with accessibility checklists, however, which are a good place to start (as is Bobby, for that matter; it's just not a good place to finish).

Some of the Bobby guidelines are absolutely wrong, or at least they were in the past and went years without being fixed.

Nobody should blindly follow the Bobby guidelines without understanding the reasoning behind them and the implications with common user-agents like JAWS.

A better place to start would be the Web Content Accessibility Guidelines. It has problems of its own, but it's nowhere near as bad as Bobby is. But remember that they are only guidelines, and user-agents often don't do what they are supposed to.

If you do a little digging you'll see that remote web service calls from the browser are still a relatively "new" thing. There is no W3C standard as of yet.

This is incorrect, DOM 3 Load and Save was finalised back in April, and it has been implemented by multiple browsers already. You still have to mollycoddle Internet Explorer of course, so you may not think that it's worth your while to implement the W3C approach, but that's your call.

There is, but it's on the way out...

L.

One that really sticks out is all of the javascript dynamic menus. I always thought that by now there would be a tag for this purpose.

The latest XHTML 2 draft has an <nl> element type.

Seems like a logical tag to add to the specs.

Not particularly, practically every use of popup menus I have seen on the web are completely unsuitable for the situation. Sure, there are one or two cases where they are actually the best tool for the job, but mostly it's just a case of people using them for their own sake.

PS: Don't use the word "tag" when you mean "element type". 99% of the time people say the word "tag", they mean "element", "element type" or "attribute".

I'm not telling you to get rid of it. I'm telling you to make it a standard.

Already done. Well, it's not a standard, but I'm assuming you're abusing the word "standard" in the same way virtually everybody else does when it comes to web development.

Eventhough it's an M$ spawned horror - It has brought a new revolution to javascript. Now it can load data from the server without having to refresh the screen.

That's not something new, people have been doing that for a while with hidden iframes. The standard way of doing what XMLHttpRequest does is DOM 3 Load & Save, which is supported by Firefox and, I believe, the latest versions of Opera and Konqueror. Of course, it's best to include XMLHttpRequest as a fallback for when DOM 3 Load & Save isn't available (and, of course, fallbacks when XMLHttpRequest and Javascript itself isn't available), but in general you should write standard stuff first and use the non-standard stuff only as a last resort.

Actually, most people *are* fed-up with Internet Explorer. It might be allowing pop-ups once a minute, or not displaying certain websites correctly (most often https), or just behaving slowly.

I've worked on 758 help requests for college students living in dorms since September. I'd say about 20% of them had problems that were simply solved by installing a copy of Firefox, nothing more. Many of these students are sold on the idea of Firefox. They do their own advertising... I've watched the most non-technical students advocate Firefox to the kid across the hall.

Last night I got a call from a user who could pull up yahoo.com, but after entering a simple search, the page would load and give some web server error. She went to Help->About, and clicking "OK" wouldn't close the dialog box. This was with an updated version of IE. Got her to go to mozilla.org, and the green "Download Now" section wouldn't display. After linking directly to the mozilla suite, and getting that installed, she was able to properly view webpages.

Out of the 758 students I've dealt with this semester, and the equally high number I've dealt with in the past 3 years at this job, only twice have I seen a resident contact us saying that Firefox won't load a certain page.

All those webpages with ActiveX controls..... the everyday user doesn't care about them. And slashdot not loading properly, I think we all know why that is.... its reporting itself as HTML 3.2 and still gets 116 errors from http://validator.w3.org/

The point is, creating these new TLDs just splits the web in two. Does placing content in .mobi mean that content is not linkable and viewable by PC browsers? That's bad for the web.

Creating these device specific TLDs is a bad use of the system, and should be stopped. All the content on the web should be accessible by any web client. Client can't natively support a MIME type? Use a plugin, and have Content Negotiation work its magic.

Tim BL said it best in New top level domains considered harmful

I think .mobi may actually be the first "useful" domain I've heard so far. If you're on your cell phone and want to be sure that the web site you want to access will be tailored to your needs with a mobile browser, just ensure it is a .mobi domain. I suppose it's just as easy to add "mobile." to the beginning of your site for a mobile compatible page, but this BORDERS on useful.

Imagine a world where every device has its own TLD. Your mobile phone browses only in .mobi, your laptop only in .laptop, your desktop only in .desktop. And within those domains your OS matters -- run Linux on your desktop? Go to foo.linux.desktop. Got a Powerbook? Instead go to foo.mac.laptop for our site. That way you know the page you're looking at will be tailored to your needs, right?

Except this is stupid. CSS already includes a media type for PDAs and phones, with the explicit purpose of defining 'low-res' styling for those devices. So why the hell can't we use the standard we've got and try to keep our pages device-independent?

As it turns out, Sir Tim Berners-Lee doesn't like .mobi for this very reason. But what would he know? He only invented that "web" thing, which never went anywhere anyway. I'm sure that ICANN's lackeys know better.

The internet should be moving towards ensuring access to any site by any device, not segmenting certains parts for certain devices. ".mobi" sends a message to developers that they should build separate sites for cell phones instead of figuring out how to provide the same content regardless of the user's platform.

XML, semantic web, etc. are all about presenting the data to the user as the user wants it. RSS has helped popularize these concepts, and now ICANN is snubbing this progress and promoting a backwards-looking solution.

Tim Berners-Lee himself is on the record as being opposed to .mobi because it is in direct opposition to the principles of semantic web.

Maybe ICANN should seize ".ie" from Ireland and hand it over to sites that look great in IE and look like crap (or don't load at all) in every other browser.

Very disappointing development.

You're right... but even worse: all these new top level domains are just costing you money...

good reading on the subject: New Top Level Domains Considered Harmful

There is no such thing as a W3C spec. All they have is recommendations, such as the candidate recommendation for CSS 2.1. There is no way to flawlessly implement the "spec" as you call it, since the recommendations are purposefully vague and all-inclusive.

I never thought I'd see the day when we desperately needed MathML.

If browsers only displayed correct HTML then I would have a lot more hair now. ;)

There is a browser to do that. Perfect standards compliant browsing (though its meant for web designers not end users).

Geez, just look at his HTML. If you're afraid, let the Validator look at it for you: plain results (4.01 Transitional), forcing charset, forcing HTML 3.2.

What are standards good for, anyway? Just use your monopoly to push your nonstandard browser and do it your way.

Geez, just look at his HTML. If you're afraid, let the Validator look at it for you: plain results (4.01 Transitional), forcing charset, forcing HTML 3.2.

What are standards good for, anyway? Just use your monopoly to push your nonstandard browser and do it your way.

Geez, just look at his HTML. If you're afraid, let the Validator look at it for you: plain results (4.01 Transitional), forcing charset, forcing HTML 3.2.

What are standards good for, anyway? Just use your monopoly to push your nonstandard browser and do it your way.

• An XML Vocabulary from W3C
  
• implemented in Mozilla
  
• the way to exchange between different software
  
• easy to transform to and interact with Scalable Vector Graphics (SVG)
  

• An XML Vocabulary from W3C
  
• implemented in Mozilla
  
• the way to exchange between different software
  
• easy to transform to and interact with Scalable Vector Graphics (SVG)
  

Maybe he doesn't know how to write HTML. Most people don't.

Is this really a bandwidth issue or a scalability issue? I was under the impression that the problem comes with bursts of simultaneous requests. A previous /. topic discussed this.

Now, if the clients could all agree to ask at different times like CSMA/CD, then you would have a scalable solution. It's too bad that CDF never became popular because that format does about the same thing as RSS but with some additional information on the window with which requests should be made.

Amen. I blogged more open file formats for my wishlist just last week and I've just received abuse from the anti-XML faction ("too hard", "too fiddly", "just a fad"). OK, so I haven't exactly been polite about programmers who don't grok XML in the past, but believe me there is still a hard core of non-Microsofties out there who still want XML to die :-)

The fact that the format is XML is rather meaningless [...] For many things XML is unsuitable/non-optimal...

Yes, it could have been a number of formats (ODIF, anyone? :-) but XML was explicitly designed for (well, inherited its application to) textual information, so it's a little captious to say it's unsuitable for binary data, but the important long-term reason is not just that it's documented, it's that it's based on an international standard, so it's public, stable, and cannot be hijacked by corporate factions (they'll try).

You should care that it's XML...

it bugs me that it's not done right in a product developed mostly open source and by people not held back by managers and marketing strategies and all middle layer as opposed to IE or other such products.

But it is done right. If you don't like it that way, take it up with the W3C.

For a page to validate, it means your usage is correct.

If a document or stylesheet is valid, that merely means that it has no syntax errors. It doesn't mean that the document or stylesheet makes sense.

Oh and don't get me started on the link tag not being a proper block in mozilla (& family). For menus it's nice to set all their widths to a certain size and just use the :hover settings to highlight those when the mouse goes over those

If I understand you correctly, you are complaining that the link element is not block display by default. It's not in Internet Explorer either. It's just that Internet Explorer quirks gets CSS wrong by applying the width property to inline display elements. The width property doesn't apply to non-replaced inline elements.

The correct way of doing what you want is to set the <a> elements to block display. Then you can set widths all you want.

Sorry, but as much as I hate IE, I have to agree that the IE box model in IE5.x is better than the w3c one.

That's a perfectly valid opinion. It doesn't change the fact that when somebody claims that Firefox gets the box model as described by the CSS specifications wrong and Internet Explorer gets it right, they are talking nonsense.

The IE one offers many, many advantages and allows you to build columnar layouts which are plain impossible without using javascript or many many hacks in the w3c way

With all due respect, you don't know what you are talking about. I agree that it's a pain to do that using floats, because you have to use wrapper elements. It's certainly not impossible, and once you've done a couple, you don't even need to think about it. Furthermore, the "W3C way" will include the box model you describe in CSS 3 (obviously not as default). But Microsoft won't bother implementing that, so we can forget about using it.

The more important point though, is that those types of layouts are dead simple to do with CSS - or they would be if Microsoft had bothered implementing that part of CSS! Look at the CSS specification if you don't believe me.

IE6 is also actually pretty standards compliant really.

Whole sections of CSS have been ignored. But at least they implemented HTML properly, right? Wrong. HTTP? nope. PNG? Nope. So Opera isn't too good with the DOM - that hardly excuses the consistently crap implementations that Microsoft churn out - or should I say churned out, as they haven't made any significant changes in over three years.

Thanks for an irrelevant link. Here's one that talks about padding.

http://www.w3.org/TR/REC-CSS2/box.html#padding-pro perties8.4 Padding properties

Now read this also to see how the container _contains_ the padded area.

http://www.w3.org/TR/REC-CSS2/box.html#box-padding -area/

So if you understand it incorrectly, doesn't mean that the person that said something good about IE is wrong.

A little hypocritical, don't you think? Not to mention backward, nine times out of ten, when Internet Explorer acts one way and Firefox acts another, it's Internet Explorer that has got it wrong.

Anything you can use to backup this claim? Otherwise it's a little hypocriticial to not provide any facts but call others wrongs by providing wrong facts.

Thanks for an irrelevant link. Here's one that talks about padding.

http://www.w3.org/TR/REC-CSS2/box.html#padding-pro perties8.4 Padding properties

Now read this also to see how the container _contains_ the padded area.

http://www.w3.org/TR/REC-CSS2/box.html#box-padding -area/

So if you understand it incorrectly, doesn't mean that the person that said something good about IE is wrong.

A little hypocritical, don't you think? Not to mention backward, nine times out of ten, when Internet Explorer acts one way and Firefox acts another, it's Internet Explorer that has got it wrong.

Anything you can use to backup this claim? Otherwise it's a little hypocriticial to not provide any facts but call others wrongs by providing wrong facts.

Develop a CCS based look for your website. Use IE during development.... When things are supposed to be padded, the mozilla based browsers actually increase the size of the actual container.

That's the way width is supposed to work in CSS. But I guess that's what you get for using a non-compliant browser as your reference rendering and then trying to test in compliant browsers afterwards.

Just because you made it work in FireFox doesn't mean it complies.

Funny. It seems to me that you make it work in Internet Explorer, and then assume it complies. A little hypocritical, don't you think? Not to mention backward, nine times out of ten, when Internet Explorer acts one way and Firefox acts another, it's Internet Explorer that has got it wrong.

I have, from personal experience, found out that IE is the most CSS compliant of all browsers available.

Go read the spec. Internet Explorer can't handle half the selectors, can't handle tables, can't handle generated content, can't handle miscellaneous other properties... do I really have to make a list?

Plus I like the fact that MS doesn't invent new crap and start pushing it as a standard in their browser.

Okay, now I know you're either crazy or trolling. I should have twigged when you said that Internet Explorer was the most CSS compliant.

One of the ideas behind the Semantic Web is an integration like that. here's an interesting paper from Tim Berners-Lee on the idea behind it.

He was using Berkeley's computer system, so I doubt that Eolas' allegation of "not being connected to the internet" can be considered valid.

In addition to the system he used to create Viola, there's the copyright date on this article (1994), and this review of ViolaWWW by Tim Berners Lee (1992). Although there is no indication of whether Pei's embedded object archetecture predate's Eolas' the publication of his article and the availability of the libraries and samples at the same time that Eolas is patenting their new technology does cast doubt on Eolas' claim.

Eolas' argument is crap, they were likely aware of Tim Berners Lee's article and of Viola when they developed their techjnology (if you are an early developer of a new technology, it is likely that you read the works of the man who invented it), and the judge either doesn't understand the issue or the history, or he has an axe to grind (either against Microsoft, or against things being "Free").

A super versatile goodie.
Here's some explanation:

2D Web Graphics: SVG by I.Herman, W3C, Head of Offices.

Introduction to SVG

svgx.org

SVG.org

What is SVG

Yahoo svg-developers group

This is being fought on two fronts

1. They(MS) have appealed the decision by the lower court in favor of Eolas.
2. The patent itself is under dispute.

The patent has so much negative consequences that even W3C is supporting the Microsoft case.
http://www.w3.org/2003/10/28-906-briefing

Hope the web stays intact.

Sorry I just don't agree that the XHTML standard is bad. I take it that you don't consider the ESPN and Red Hat (there are many more) sites either "real-world" enough or they are "doing it wrong"?

I'm not saying that XHTML is bad. I'm saying that doing XHTML properly can be a nightmare. And no, ESPN and Red Hat and many more don't do it right; go back to Evan Goer's X-Philes list and read the criteria. Or read my by-no-means comprehensive guide to some of the things you have to do just to switch from HTML 4.01 to XHTML 1.0, and remember that these languages are element-for-element identical.

Consider the HTML 4 spec, which is syntactically difficult to decipher. After writing XHTML pages for several years now (thanks, I'm not a newbie to the web standards world) it's impossible to go back to HTML 4 and have it actually make any sense. For every open tag, you need a closing tag, except if it's horizontal line or a line break or an input or a meta tag or an image or...

And in XHTML you still don't have closing tags, you just have a closing slash on the opening tag; how is that any less confusing? And by the way, that closing slash is fine if you're doing XHTML and serving it with an XML or XHTML MIME-type, but if you serve it as text/html you're gonna give conformant SGML parsers fits (Google "SGML SHORTTAG" sometime). And there's nothing in HTML 4.01 that says you can't close your paragraphs and list items and lots of other elements... I close them because it's good coding practice no matter what version of HTML I'm using. You can do that too if you like.

It's just ugly and difficult to parse. By using XHTML, any XML parser can read a document. It's simple, if there's an open tag, close it. If there's a stand-alone tag, it better have a self-closing end. That is just one small piece of what I like about XHTML.

You've obviously never met the Yellow Screen of Death. And if you seriously believe that parsing XML is as easy as "open the tag, close the tag", I recommend you hang out on XML-related mailing lists for a while. Or just read Sam Ruby's weblog.

Insisting that if a webpage meets the XHTML Strict spec, it doesn't work in IE is just pure ignorance. Yes, typically developers have to put a little extra work into their CSS to get their pages looking as good in IE as they do in Mozilla/Firefox/Netscape/Opera/Safari/etc...

No, it's not ignorance. Go read the article by Ian Hickson I linked in my last comment; if you won't take my word, maybe you'll listen to somebody who's worked on both Mozilla and Opera and who leads the WHAT-WG. This is not about CSS bugs or quirks or rendering differences. This is about the simple fact that XHTML, according to the W3C, should be served with the MIME-type application/xhtml+xml. No version of Internet Explorer ever released on any platform anywhere is capable of dealing with that MIME-type. If you give it a page marked as application/xhtml+xml, IE will prompt you to download the page or specify another application to handle it; it literally does not know what to do with such a document.

Now, with XHTML 1.0 you are allowed to continue serving as text/html so long as you meet the HTML Compatibility Guidelines outlined in Appendix C of the XHTML 1.0 spec. Best practice here is to use some form of content negotiation to send application/xhtml+xml to user-agents which support it. However, XHTML 1.1 makes no provision of any sort for this; XHTML 1.1 is to be served as application/xhtml+xml, which means that there is no such thing as a conformant XHTML 1.1 document which will display in Intern

Look for the target attribute and the "L" flag in the 6th column of the attributes section of the HTML 4 spec. This means it is only allowed in the HTML 4 Loose DTD, not in the Strict DTD. The original poster was right, you are wrong.

there are several things that server-based aggregators can do that desktop based aggregators can't do

I assume you're speaking of server-vs-desktop in the same relationship as webmail-vs-pop3. Yes, server-based aggregators can probably do a whole lot more because of the ability to network people together with common interests and watch usage statistics, etc.

That said, there's a reason I use RSS feeds (and preferably Atom, if available) over visiting my friends' Xangas (ugh) and Livejournals. Most of my friends have an inability to color-coordinate their blogs. One person I know has an awful background image that repeats poorly, and consistently has varying colors from yellow-on-white to purple-on-black. Thanks to my desktop aggregator, I'm able to view the content in a readable color scheme. I would assume that a server-side aggregator would impose its own color scheme on me.

Just some thoughts from a POP3 user. *grin*

And as a suggestion: please make sure Bloglines validates properly against validator.w3.org.

Moderate this comment
Negative: Offtopic Flamebait Troll Redundant
Positive: Insightful Interesting Informative Funny

Sign up for a free flatscreen or LCD monitor

The following target names are reserved and have special meanings.
_blank
The user agent should load the designated document in a new, unnamed window.

The following target names are reserved and have special meanings.
_blank
The user agent should load the designated document in a new, unnamed window.

Attributes defined elsewhere

* id, class (document-wide identifiers)
* lang (language information), dir (text direction)
* title (element title)
* style (inline style information )
* shape and coords (image maps)
* onfocus, onblur, onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup (intrinsic events )
* target (target frame information)
* tabindex (tabbing navigation)
* accesskey (access keys)

Attributes defined elsewhere

* id, class (document-wide identifiers)
* lang (language information), dir (text direction)
* title (element title)
* style (inline style information )
* shape and coords (image maps)
* onfocus, onblur, onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup (intrinsic events )
* target (target frame information)
* tabindex (tabbing navigation)
* accesskey (access keys)

Attributes defined elsewhere

* id, class (document-wide identifiers)
* lang (language information), dir (text direction)
* title (element title)
* style (inline style information )
* shape and coords (image maps)
* onfocus, onblur, onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup (intrinsic events )
* target (target frame information)
* tabindex (tabbing navigation)
* accesskey (access keys)

After all, how on earth could you target a frame with an anchor or a link without using the "target" attribute?

You would use an appropriate doctype for a framed page:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/framese t.dtd">

Note: This doctype is not the same as the HTML Strict doctype

David

Close enough to be a dupe? You Decide.

Nevertheless, this is not an issue, but like the unwashed shrills squawking that the end of Social Security is nigh, RSS is far from being dead. The issue is that ignorant (maybe I should say 'stupid') people did not bother to implement the spec properly in their RSS reader code. I'm not talking about the RSS spec, but the HTML spec. This is a simple two step process (credit Charles Miller):

1. When you first pull your RSS feed, store the values you get for Last-modified ( = A) and ETag (= B).
2. When you want to next poll your feed, send If-Modified-Since: A and If-None-Match: B.

If the RSS feed has not been updated since you last polled, you will get a 304: Not Modified in response, but no RSS feed (because it has not changed, duh).

It's like in The Army, you know--The Great Prince issues commands, founds states, vests families with fiefs. Inferior people should not be employed (creating broken RSS readers).

Close enough to be a dupe? You Decide.

Nevertheless, this is not an issue, but like the unwashed shrills squawking that the end of Social Security is nigh, RSS is far from being dead. The issue is that ignorant (maybe I should say 'stupid') people did not bother to implement the spec properly in their RSS reader code. I'm not talking about the RSS spec, but the HTML spec. This is a simple two step process (credit Charles Miller):

1. When you first pull your RSS feed, store the values you get for Last-modified ( = A) and ETag (= B).
2. When you want to next poll your feed, send If-Modified-Since: A and If-None-Match: B.

If the RSS feed has not been updated since you last polled, you will get a 304: Not Modified in response, but no RSS feed (because it has not changed, duh).

It's like in The Army, you know--The Great Prince issues commands, founds states, vests families with fiefs. Inferior people should not be employed (creating broken RSS readers).

Close enough to be a dupe? You Decide.

Nevertheless, this is not an issue, but like the unwashed shrills squawking that the end of Social Security is nigh, RSS is far from being dead. The issue is that ignorant (maybe I should say 'stupid') people did not bother to implement the spec properly in their RSS reader code. I'm not talking about the RSS spec, but the HTML spec. This is a simple two step process (credit Charles Miller):

1. When you first pull your RSS feed, store the values you get for Last-modified ( = A) and ETag (= B).
2. When you want to next poll your feed, send If-Modified-Since: A and If-None-Match: B.

If the RSS feed has not been updated since you last polled, you will get a 304: Not Modified in response, but no RSS feed (because it has not changed, duh).

It's like in The Army, you know--The Great Prince issues commands, founds states, vests families with fiefs. Inferior people should not be employed (creating broken RSS readers).

Close enough to be a dupe? You Decide.

Nevertheless, this is not an issue, but like the unwashed shrills squawking that the end of Social Security is nigh, RSS is far from being dead. The issue is that ignorant (maybe I should say 'stupid') people did not bother to implement the spec properly in their RSS reader code. I'm not talking about the RSS spec, but the HTML spec. This is a simple two step process (credit Charles Miller):

1. When you first pull your RSS feed, store the values you get for Last-modified ( = A) and ETag (= B).
2. When you want to next poll your feed, send If-Modified-Since: A and If-None-Match: B.

If the RSS feed has not been updated since you last polled, you will get a 304: Not Modified in response, but no RSS feed (because it has not changed, duh).

It's like in The Army, you know--The Great Prince issues commands, founds states, vests families with fiefs. Inferior people should not be employed (creating broken RSS readers).

Close enough to be a dupe? You Decide.

Nevertheless, this is not an issue, but like the unwashed shrills squawking that the end of Social Security is nigh, RSS is far from being dead. The issue is that ignorant (maybe I should say 'stupid') people did not bother to implement the spec properly in their RSS reader code. I'm not talking about the RSS spec, but the HTML spec. This is a simple two step process (credit Charles Miller):

1. When you first pull your RSS feed, store the values you get for Last-modified ( = A) and ETag (= B).
2. When you want to next poll your feed, send If-Modified-Since: A and If-None-Match: B.

If the RSS feed has not been updated since you last polled, you will get a 304: Not Modified in response, but no RSS feed (because it has not changed, duh).

It's like in The Army, you know--The Great Prince issues commands, founds states, vests families with fiefs. Inferior people should not be employed (creating broken RSS readers).

The relevant section is here

One could argue that because the HTML spec does not mandate a target name resolution algorithm it is not to blame for this problem. (A web browser implementor ought to have the foresight to get the security right ...) However, I don't buy that. IMO, the target name resolution algorithm should be mandated (to improve script portability) and it should specifically address this security issue.