Slashdot Mirror

Good points to think about.

I'd settle for eliminating plug-ins entirely, but solidifying support for W3C standards such as SVG and X3D.

With some work in ECMAscript (Javascript), dynamic illustrations in SVG could be turned into the various widgets that people expect from a modern GUI, but they'd be built-in to a browser and be cross-platform.

Then IE, Mozilla, Opera and anyone else would be free to implement renderers and interactors without fearing whether they're infringing on someone's patent.

Widespread adoption of these standards for interactive and scalable graphics would be a tremendous benefit in getting rid of all the various paper-centric publishing solutions that plague us today.

The problem with flash is not that it's not useful, but that it's not an open standard, and doesn't integrate with webpages, instead it is either embededed in a box in the page, or it replaces the page.

Instead there are the Scalable Vector Graphics and Synchronized Multimedia Integration Language Specifications.

The problem with flash is not that it's not useful, but that it's not an open standard, and doesn't integrate with webpages, instead it is either embededed in a box in the page, or it replaces the page.

Instead there are the Scalable Vector Graphics and Synchronized Multimedia Integration Language Specifications.

I've been reading Zeldman's book Designing for Web Standards at safari.oreilly.com and it addresses this quite well. Safari and Mac IE 5.2 are very compliant to standards moreso than any version of IE on Windows, so it's not as big a deal now as it once was during the browser war era. Yeesh what a mess that was.

If you can move away from using old pre-war coding practices you'll be a step ahead in the fight. Check out these sites for more info on coding pages that look good in any browser on any platform:

• The Web Standards Project

• Zeldman's site of course.

• A List Apart

• Netscape's DevEdge is a great source of info.

• Validate your source.

• Validate your CSS.

• Another html validator.

• Accessibility is not only a good thing it's the right thing, especially if you ever make a government site.

• Bluerobot has some pre-cooked layouts to cut your teeth on.

Designing with XHTML and CSS means not leaving anybody out. From Web-enabled phones to IE 6 to text only browsers like lynx or links you'll only need to write your code once. I say do away with javascript browser detection scripts and write once, run (almost) anywhere!

There is a last resort you can go to if you must. Macromedia Flash looks the same in any browser provided you have the proper plugin. :) Although that is not my recommended solution.

I've been reading Zeldman's book Designing for Web Standards at safari.oreilly.com and it addresses this quite well. Safari and Mac IE 5.2 are very compliant to standards moreso than any version of IE on Windows, so it's not as big a deal now as it once was during the browser war era. Yeesh what a mess that was.

If you can move away from using old pre-war coding practices you'll be a step ahead in the fight. Check out these sites for more info on coding pages that look good in any browser on any platform:

• The Web Standards Project

• Zeldman's site of course.

• A List Apart

• Netscape's DevEdge is a great source of info.

• Validate your source.

• Validate your CSS.

• Another html validator.

• Accessibility is not only a good thing it's the right thing, especially if you ever make a government site.

• Bluerobot has some pre-cooked layouts to cut your teeth on.

Designing with XHTML and CSS means not leaving anybody out. From Web-enabled phones to IE 6 to text only browsers like lynx or links you'll only need to write your code once. I say do away with javascript browser detection scripts and write once, run (almost) anywhere!

There is a last resort you can go to if you must. Macromedia Flash looks the same in any browser provided you have the proper plugin. :) Although that is not my recommended solution.

I've been reading Zeldman's book Designing for Web Standards at safari.oreilly.com and it addresses this quite well. Safari and Mac IE 5.2 are very compliant to standards moreso than any version of IE on Windows, so it's not as big a deal now as it once was during the browser war era. Yeesh what a mess that was.

If you can move away from using old pre-war coding practices you'll be a step ahead in the fight. Check out these sites for more info on coding pages that look good in any browser on any platform:

• The Web Standards Project

• Zeldman's site of course.

• A List Apart

• Netscape's DevEdge is a great source of info.

• Validate your source.

• Validate your CSS.

• Another html validator.

• Accessibility is not only a good thing it's the right thing, especially if you ever make a government site.

• Bluerobot has some pre-cooked layouts to cut your teeth on.

Designing with XHTML and CSS means not leaving anybody out. From Web-enabled phones to IE 6 to text only browsers like lynx or links you'll only need to write your code once. I say do away with javascript browser detection scripts and write once, run (almost) anywhere!

There is a last resort you can go to if you must. Macromedia Flash looks the same in any browser provided you have the proper plugin. :) Although that is not my recommended solution.

I've been reading Zeldman's book Designing for Web Standards at safari.oreilly.com and it addresses this quite well. Safari and Mac IE 5.2 are very compliant to standards moreso than any version of IE on Windows, so it's not as big a deal now as it once was during the browser war era. Yeesh what a mess that was.

If you can move away from using old pre-war coding practices you'll be a step ahead in the fight. Check out these sites for more info on coding pages that look good in any browser on any platform:

• The Web Standards Project

• Zeldman's site of course.

• A List Apart

• Netscape's DevEdge is a great source of info.

• Validate your source.

• Validate your CSS.

• Another html validator.

• Accessibility is not only a good thing it's the right thing, especially if you ever make a government site.

• Bluerobot has some pre-cooked layouts to cut your teeth on.

Designing with XHTML and CSS means not leaving anybody out. From Web-enabled phones to IE 6 to text only browsers like lynx or links you'll only need to write your code once. I say do away with javascript browser detection scripts and write once, run (almost) anywhere!

There is a last resort you can go to if you must. Macromedia Flash looks the same in any browser provided you have the proper plugin. :) Although that is not my recommended solution.

I've been reading Zeldman's book Designing for Web Standards at safari.oreilly.com and it addresses this quite well. Safari and Mac IE 5.2 are very compliant to standards moreso than any version of IE on Windows, so it's not as big a deal now as it once was during the browser war era. Yeesh what a mess that was.

If you can move away from using old pre-war coding practices you'll be a step ahead in the fight. Check out these sites for more info on coding pages that look good in any browser on any platform:

• The Web Standards Project

• Zeldman's site of course.

• A List Apart

• Netscape's DevEdge is a great source of info.

• Validate your source.

• Validate your CSS.

• Another html validator.

• Accessibility is not only a good thing it's the right thing, especially if you ever make a government site.

• Bluerobot has some pre-cooked layouts to cut your teeth on.

Designing with XHTML and CSS means not leaving anybody out. From Web-enabled phones to IE 6 to text only browsers like lynx or links you'll only need to write your code once. I say do away with javascript browser detection scripts and write once, run (almost) anywhere!

There is a last resort you can go to if you must. Macromedia Flash looks the same in any browser provided you have the proper plugin. :) Although that is not my recommended solution.

The HTML spec has always _REQUIRED_ the TITLE element...

from the RFC:

5.2.1. Title: TITLE

Every HTML document must contain a <TITLE> element.

The title should identify the contents of the document in a global
context. A short title, such as "Introduction" may be meaningless out
of context. A title such as "Introduction to HTML Elements" is more
appropriate.

NOTE - The length of a title is not limited; however, long titles
may be truncated in some applications. To minimize this
possibility, titles should be fewer than 64 characters.

A user agent may display the title of a document in a history list or
as a label for the window displaying the document. This differs from
headings (5.4, "Headings: H1 ... H6"), which are typically displayed
within the body text flow.

Safari has CSS bugs that Mozilla doesn't, and IE's Javascript parser does things differently than Opera's.

CSS advocates claim that it can help with cross-browser problems, by eliminating the complicated HTML that includes tables, frames, and "spacer" images. If you try to browse Slashdot in Netscape 7.1, you're inclined to think that they have a point. But there's no real way to test this until more browsers implement more of CSS2 -- and implement it correctly.

Meanwhile, the W3C people continue to invent new CSS stuff faster than the browsers add support for it. Oh well!

As I work in webshop (yes, we're still around after the dot bomb), we regularly have clients that don't give a crap about browser compatibility or standards. However, our development team (myself included) do care.

We code and validate our sites to HTML 4.01 or XHTML 1.0. But we still test our sites on IE (for both Mac and Windows), Mozilla-based browsers, and Safari. Why? Because while coding to standards works great for us developers, these browsers still have bugs (especially CSS bugs). We routinely find CSS bugs in IE 5.5 for Windows, a few here and there in Safari, and (ironically enough) the current worst of the lot: IE 5 for Macintosh (ironic because, as some of you know, this browser used to be considered the most CSS-compliant). We don't sniff for browsers - we just try to avoid markup and style definitions that don't consistently work across the board.

Yes, it takes more work than just validating code. However, it still 10x less work than doing hacks and tricks to make stuff work in that piece-of-crap Netscape 4.

If only HTML validation were as simple as submitting pages to the proper emulator, and viewing the results.

Yeah, if only... oh, wait, it is.

Of course, testing for validation and compliance to standards is not quite the same thing as "does my web page look okay in Arbitrary Browser Foo," which is what the submitter was asking about. At some point you simply have to say, "any browser will work as long as it doesn't suck with regards to published open standards."

If only HTML validation were as simple as submitting pages to the proper emulator, and viewing the results.

If only Slashdot HTML validation were as simple as submitting pages to the W3C Validator, and viewing the results.

http://validator.w3.org/check?uri=http://slashdot. org

We have language standards to make cross-platforming easier. If you'd like to check to see if your page is w3c complaint, go here.

Hmm. Can't say about "wavy-underlined" spell check, but spell checking where spelling errors are detected and highlighted on the fly have been around since the 80's. Both in WYSIWYG form for the mac and text for PC-DOS / DR-DOS.

DOM was around a few years before most considered MSIE usable, so your claim strikes me as specious. Likewise with smart tags or dumb tags, if it's in MS-Word, then only Microsoft can produce it and by definition they're first. If it is similar to the "Smart Tags" in MSIE that got canned.

Innovation is certainly involved, but Steve and Bill seem to use the word in the wrong context.

I worked at a local ISP who managed to get a demo for a cache server a while back. (I don't anymore.) The machine arrived. We plugged it in, and started to take tech calls.

Sounds like this was your mistake. You "managed to get a demo" speaks volumes. Sounds like an expensive proprietary product from a small company. If you had just downloaded Squid, I don't think you would have encountered all these problems.

The server had a difficult time with virtual hosting of any kind. About 4 out of 5 requests to a virtual host would go through. About 20% of the time, there was some critical piece of information that the cache server would mangle so that the vhost mechanism would be unable to serve the right data. This was a couple years ago, so bugfixes might have happened. Maybe.

Sounds like it only supported IP-based virtual hosting. Back in the day, most sites would have had separate IPs for everything they hosted, so that percentage sounds right. The 20% that failed needed a "Host: www.virtual.com" header.

The server definitely had a hard time with dynamic content that wasn't built with a GET url (thus triggering the pass-thru proxy). If the request was posted, encrypted, hashed, or referenced a server side directive of some kind (server-side redirects were a nasty) the cache would fail. A server side link equating something like "http://www.server.net/redirect/" to a generated URL or dynamic content of some kind was the most frequent case we rean into with this. The server simply couldn't parse each and every http request or every variety and try to decide if it should pass-thru or not. I can't think of a logical way around this that wouldn't break any given implimentation. Can you?

First, I think you mean a POST query would trigger the pass-through. GET is the normal method.

Second, there are pretty simple ways for triggering a cache or not. The full rules are here, but very roughly a page should be cached if and only if:

• There is an "Expires", "Last-modified", or "E-tag" header set
• There is no "Cache-control: no-cache" header set
• There was no authorization domain required (HTTP authorization; this doesn't catch forms of course)

If one is in the cache other than the Expires (which doesn't even need to be checked), it will query the server and check if the content is the same as before (with a special header that instructs the server not to send anything if it's unchanged).

This is a nice rule because webservers tend to automatically set the Last-modified: date on plain files and never do on dynamic stuff, so you have to explicitly add it in your dynamic code after considering it. So it gets most of the static stuff automatically (and that's generally the big stuff - images) but is cautious with anything dynamic. That's the correct approach.

This scheme really only breaks down when clock used by the requester (cache server in this case, browser also) or by the content generator (possibly the webserver, but also maybe the desktop used to generate stuff and then upload to the webserver) is skewed. And even then, it just gives stale data; not one person logged in as someone else. And this problem occurs even without a caching server, since browsers implement caching by themselves. Really, having a correct time is important to lots of things on computers. For example, don't ever try to do development without your clock being correct; build tools will be completely unable to tell what's up-to-date and what's not. Ticket-based network authentication systems (like Kerberos implementations, including Microsoft's shiny new ActiveDirectory) will refuse to log you on. etc, etc.

We used dynamically assigned IPs at the time, so proxy requests made

The reason their is a Opera complaint icon at the bottom is for mutual benifit. In opera you can type "a searchterm" in the URL bar to search alltheweb directly, alltheweb repay the favour by linking to Opera. Also both companies are based in the same city.

Exactly. RSS works just like HTTP because it is HTTP. It's just like visiting a website except that you use a feed reader instead of a browser, and that the feeder usually comes with an automatic refresh feature.

FWIW, you can watch RSS feeds with any recent browser just as well (well, Mozilla and IE, haven't tried Opera), if you don't mind being shown a tree of XML tags.

If the XML document has an XSLT transformation sheet associated with it, it will be displayed as nice HTML so even that isn't a problem. Check this out to see an example.

That's a good idea, now go write an RSS aggregator that supports HTTP auth,

You mean like this?

and then go convince everyone to support it in their servers.

No, only people who want private RSS files need to support it in their servers. And it's not like HTTP autentication is some sort of mystery, all reasonable web servers support it out of the box. After all, guess what, it's part of HTTP/1.0.

But first, you might want to think about how auth will interfere with RSS discovery (which is already screwed up enough).

Easy, it doesn't. Either you can get to the RSS feed or you can't, either way the aggregator has to handle it (people type in wrong URLs all the time, for instance, so any real aggregator has to handle errors).

You seriously overestimate the difficulty of this. Unusual, usually people underestimate difficulties. I hope you aren't a professional coder.

Hehe, Slashdot's not really a shining example of web accessibility, but it's a good place to ask for help none-the-less.

The first stops for help (as someone's no doubt pointed out already) should be:

Section 508

Mark Pilgrim's excellent "Dive Into Accessibility"

The W3C's web accessibility guide

The UK Disabled Rights Commission website, paying particular attention to the superb Interactive Demos (e.g. Inaccessible Website Demo).

Buy these books:

Constructing Accessible Websites

Building Accessible Websites

Oh, and a copy of Zeldman's Designing With Web Standards for good measure.

Write your pages using validating HTML or XHTML, and style the pages using CSS.

Validate your webpages using the W3C Validator and your CSS using the W3C CSS Validator. Use Watchfire's Bobby to validate your pages, and aim for AAA rating (also note that Bobby has some helpful hints when it does find errors).

Other excellent resources (in no particular order):

http://www.webstandards.org/
http://www.w3.org/WAI/References/QuickTips/
http://www.mezzoblue.com/
http://www.meyerweb.com/
http://www.simplebits.com/
http://www.whatdoiknow.org/
http://www.stopdesign.com/

Hehe, Slashdot's not really a shining example of web accessibility, but it's a good place to ask for help none-the-less.

The first stops for help (as someone's no doubt pointed out already) should be:

Section 508

Mark Pilgrim's excellent "Dive Into Accessibility"

The W3C's web accessibility guide

The UK Disabled Rights Commission website, paying particular attention to the superb Interactive Demos (e.g. Inaccessible Website Demo).

Buy these books:

Constructing Accessible Websites

Building Accessible Websites

Oh, and a copy of Zeldman's Designing With Web Standards for good measure.

Write your pages using validating HTML or XHTML, and style the pages using CSS.

Validate your webpages using the W3C Validator and your CSS using the W3C CSS Validator. Use Watchfire's Bobby to validate your pages, and aim for AAA rating (also note that Bobby has some helpful hints when it does find errors).

Other excellent resources (in no particular order):

http://www.webstandards.org/
http://www.w3.org/WAI/References/QuickTips/
http://www.mezzoblue.com/
http://www.meyerweb.com/
http://www.simplebits.com/
http://www.whatdoiknow.org/
http://www.stopdesign.com/

Hehe, Slashdot's not really a shining example of web accessibility, but it's a good place to ask for help none-the-less.

The first stops for help (as someone's no doubt pointed out already) should be:

Section 508

Mark Pilgrim's excellent "Dive Into Accessibility"

The W3C's web accessibility guide

The UK Disabled Rights Commission website, paying particular attention to the superb Interactive Demos (e.g. Inaccessible Website Demo).

Buy these books:

Constructing Accessible Websites

Building Accessible Websites

Oh, and a copy of Zeldman's Designing With Web Standards for good measure.

Write your pages using validating HTML or XHTML, and style the pages using CSS.

Validate your webpages using the W3C Validator and your CSS using the W3C CSS Validator. Use Watchfire's Bobby to validate your pages, and aim for AAA rating (also note that Bobby has some helpful hints when it does find errors).

Other excellent resources (in no particular order):

http://www.webstandards.org/
http://www.w3.org/WAI/References/QuickTips/
http://www.mezzoblue.com/
http://www.meyerweb.com/
http://www.simplebits.com/
http://www.whatdoiknow.org/
http://www.stopdesign.com/

Hehe, Slashdot's not really a shining example of web accessibility, but it's a good place to ask for help none-the-less.

The first stops for help (as someone's no doubt pointed out already) should be:

Section 508

Mark Pilgrim's excellent "Dive Into Accessibility"

The W3C's web accessibility guide

The UK Disabled Rights Commission website, paying particular attention to the superb Interactive Demos (e.g. Inaccessible Website Demo).

Buy these books:

Constructing Accessible Websites

Building Accessible Websites

Oh, and a copy of Zeldman's Designing With Web Standards for good measure.

Write your pages using validating HTML or XHTML, and style the pages using CSS.

Validate your webpages using the W3C Validator and your CSS using the W3C CSS Validator. Use Watchfire's Bobby to validate your pages, and aim for AAA rating (also note that Bobby has some helpful hints when it does find errors).

Other excellent resources (in no particular order):

http://www.webstandards.org/
http://www.w3.org/WAI/References/QuickTips/
http://www.mezzoblue.com/
http://www.meyerweb.com/
http://www.simplebits.com/
http://www.whatdoiknow.org/
http://www.stopdesign.com/

links are good

Wow. based solely on this logic, I am convinced we should [...] remove plugin capability from our web browsers (no more flash, ra, java, acrobot or others, please).

Want to see some of the original discussion on this patent? Go to this discussion on the www-talk mailing list from 1995, including posts from Mike Doyle of Eolas and other players (including Pei Wei, whose work Microsoft claims as prior art).

I'll be happy to as soon as someone actually implements it.

Ironically, being able to see again has meant Mr May has had to re-learn some activities, such as skiing or crossing the road, where he had become proficient when blind."

Interestingly, most blind people don't really consider blindness a "disability" per se, but simply a challengee to get used to. I've met countless people with various types of disabilities that really don't count them as "disabilities". For instance, I've spoken with the Deaf/Hard of Hearing who don't consider themselves "disabled", merely more of a "linguistic minority".

The problems they run into are simply a lack of equal access that people without a disability (or a severe disability) take for granted. For instance, in that old building that has yet to be renovated, a person with full usage of their legs will have no issue getting up the stairs, but someone who requires the use of a wheelchair, or might be in crutches, or has to use a walker, etc., will find it impossible to get into that building.

What most people forget, when responding to ADA laws, Section 508 of the Rehabilitation Act, W3C WAI, etc., is that these principles of equal and timely access do not just help those with disabilities, but those without as well.

For instance, trying to move a big cart full of computer equipment into that building? It sure would be easier with curbcuts, an elevator, and recessed door frames. Trying to access the web via that shiny new PDA you just bought? Too bad the site uses Flash navigation without a text equivalent... ad nauseum

The fact that this disability was part of his life, means that it wasn't a roadblock for him, merely an alternate route. He simply did things a different way.

Yeah, I'd like to see a major Linux player working on something beyond the bitmapped desktop. If Apple can do it, surely IBM with its vast resources can get cracking in this arena. Even the alleged copycat Microsoft is actively developing a scalable desktop solution for Longhorn. How about SVG? Any implementations of that on the desktop in development?

"At this time, the Target Request site only works with Internet Explorer (IE). It was developed and tested with IE 6 / Windows 98 SE and IE 5.2.3 / Mac OS X (10.2.6). It is impractical for us to make it work with every browser on every platform, due to the incompatibility of various browsers."

- Burn them!

Tyler Close wrote:

Your issue is easily handled by the bookmark file keywords provided by Mozilla Firebird. After you've bookmarked a page, you can return to it by typing in your personally chosen keyword.

It is interesting how this simple user interface feature provides a function you thought could only be provided by a central bureaucracy like the DNS. Hold off on the hyperbole a bit. There are some good solutions if you look.

DNS was developed in 1981; The WWW was developed in 1990. That right there is a clue that DNS is for more than just web addresses.

Off the top of my head here are some uses of DNS that just don't seem to fit with the YURL concept:
1) Configuring security policy
2) Configuring routing policy
3) Troubleshooting routing issues (ping, traceroute, etc)
4) Command line internet tools (ssh, rsync, cvs, etc)
5) Configuring distributed functionality in a large application across an enterprise (databases, directory services, etc)

In all the above, I need machine identifiers to be both reliable (something YURL and nym offers and DNS doesn't), and human readable (something DNS offers and YURL and nym does not). Since there's nothing out there that offers everything I need, I stick with DNS, it doesn't require I implement anything new.

Now if something like YURL or nym were combined with something like DNS's CNAME feature in a way that allows for human readable, reliable and secure addresses, then I'll sit up and take notice. I'm sorry, I just can't take any alternative naming scheme seriously if its solution to complex identifiers is "let the bookmarks handle it".

No, it won't. Hope this helps.

Never mind simple things like italics and colored fonts. When you're doing any kind of serious workflow, you need to be able to do complex tables, simple diagrams, etc. I don't just want HTML support in my workflow, I want vector graphics. For online collaboration to get serious, online collaboration tools have to come out of the dark ages.

If MUTT works for you, fine. But don't assume your needs are the only ones any mail user can have.

Specifically, if code is data, then data should be code, right?

Not at all. How did you come up with that stupid leap in logic? Because LISP does it, so it must be right?

Data as code violates the principle of least power and leaves you wide open to doing things in "data" that are very nasty. There is no good reason for it.

So I ditched my original idea of using an XML file format, and decided to use regular python scripts as the config files.

That's great. Now you've effectively tied your system to a single language. Pretty much any language can parse XML, a config file written in Python is only going to have crude workarounds available to it for other languages.

They even have the same primary author, James Clark, producer of the ubiquitous expat XML parser.

DSSSL is Scheme-based, and Scheme is a rarefied dialect of LISP.

Thus turns the circle.

dude, SVG is vector graphic, and has completely different purpose.

That's fine. XML had a completely different purpose when it was developed also. Did you look at the "overlaying, scaling, tiling, cropping" features of SVG? It's all there! You can do amazing things with transformation, filter effects etc.

Masking, clipping, etc. in SVG

Filters, transforms, etc. in SVG

Also I'm yet to find any usable image in SVG format.

What does that mean? What is a "usable image?" Download SodiPodi and draw something. That's a usable image. You should use SVG to have AfterStep leap ahead of competitors in standards compliance and sophistication. If you want to talk about it more, you should join one of hte SVG mailing lists like SVG=developers.

<element x="0" y="0">
<component name="red" value="10" /> ...

Yep, the standard XML-bloat joke. Here is the serious solution: binary encoding. I have done some testing by defining a simple demonstration XML image format as:

<XmlDemoImage version="1.1.0">
<Header>
<Width>x</Width>
<Height>y</Height>
<SampleType>byte</SampleType>
</Header>
<Scanline row="i"> <!-- optional attr: filter="diff" -->
<RgbSamples>r g b r g b ...</RgbSamples>
</Scanline> ...
</XmlDemoImage>

If we can avoid the bizarre and hugely self-defeating but all-too-common urge to way-overstructure the pixel representation and use raw binary encoding especially for the dense arrays of numbers, the representation and performance is essentially equivalent to that of PNG format itself (though for some images, BZIP2 compression is significantly better). Here is a study of the issue. On an Athlon-XP1800+ Linux box, I get a raw (Binary)XML reading speed of 188 MB/sec for an uncompressed image. W3C is holding a workshop on binary XML encoding in September, so it may finally be prepared to humour such radical efficiency with XML.

try this:

cp image.svg image.xml

clicky...

Neither does /. for that matter.

By the way, Google has attempted to acheive this concept of human ranking by watching to see how long you stay at a page you clicked on. If they rank a page 1, and you click it, and immediately return to the search page, they penalize that page.

Do you have a reference for that? According to the HTTP RFC, user-agents aren't supposed to talk to the server when users hit their back buttons, but rather display what the user last saw (despite it possibly being stale). It seems odd that Google would try to circumvent this, especially as there isn't a reliable way of doing so.

What should we assume about your candidacy by the fact that your web page doesn't validate?

Strangely enough, I mostly agree. You see, if you use more text than graphics, you can easily design for all sizes of pages. Especially with CSS. Enough said, but go to w3.org and see their site. Low on graphics, high on content. If you don't have good content, the graphics don't matter, even on a pr()n site...
Enough said

Why doesn't Slashdot respect open standards and produce valid HTML?

Instead of pestering someone else to port Macromedia Flash, why don't you learn how to use SVG. And instead of pestering someone else to port Adobe Photoshop, why don't you start using the gimp.

Everyone who wants to see linux on the desktop should support the people who develop applications for it, not the people who don't.

Why doesn't Slashdot respect open standards and produce valid HTML?

or an instance HTTP, it could use some on the fly compression (which would speed up things a bit).

HTTP supports on-the-fly compression. Your browser can specify which compression types it accepts with the Accept-Encoding header.

Your web server can support it by sending a Content-Encoding header.

For apache support, see mod_deflate.

or an instance HTTP, it could use some on the fly compression (which would speed up things a bit).

HTTP supports on-the-fly compression. Your browser can specify which compression types it accepts with the Accept-Encoding header.

Your web server can support it by sending a Content-Encoding header.

For apache support, see mod_deflate.

...For E-mail and the Web? Let's have a look.

They've encouraged pollution of E-mail with HTML and rich text that's readable only on a client that can interpret the code. I mean, c'mon... If you can't get your message across using well-written sentences in plain ASCII text, then no amount of coloration, fancy fonts, or flashing widgets are going to help.

They've done a lot, both in the past and more recently, that bends or outright breaks W3C Consortium open standards. Granted, they've gotten a little better, but how many web sites still have interactive features that only work if you use IE? And how many have that stupid "Best viewed with Internet Explorer" blurb at the bottom? How are Flash animations and fancy graphics going to help a vision-impaired or outright blind user, who depends on text-to-speech software or simple high-contrast colors, find what they need on the web?

Outlook (known among myself and many of my friends as 'Lookout Distress') is still one of the best virus carriers on the planet. Only Microsoft would come up with an E-mail client insecure enough that it seems almost to have been designed expressly to aid virus and worm transmission.

And now UncaBill and Steve "Uncle Fester" Ballmer want to try and "Ballmerize" (my word -- like it?) Usenet? Sheesh... With their track records, they'll probably try (and, hopefully, fail miserably) to borg the whole thing into one big "Web Experience" that will be "Best Viewed with Internet Explorer" all over again.

As others have so accurately pointed out, Usenet is fine the way it is. Noisy, a bit tough to navigate, and definitely a place where you would want to have your Nomex undies handy to grab at a moment's notice, but perfectly usable to those of us who CARE ENOUGH ABOUT IT to LEARN how to use it right.

Speaking for myself, I think I can say, with confidence, that Balmy should leave Usenet to those who know it best: The admins around the world who carry it, and the thousands of users who make it a most interesting place indeed.

You are wrong. Tim Berners-Lee invented HTTP in 1989, and wrote the first web server and web browser in 1990.

The W3C was formed in 1994.

Next time you think you might be wrong, do some research. You might learn something.

You are wrong. Tim Berners-Lee invented HTTP in 1989, and wrote the first web server and web browser in 1990.

The W3C was formed in 1994.

Next time you think you might be wrong, do some research. You might learn something.