Slashdot Mirror

Well just because it renders a non-standards compliant site does not mean that the browser is not standards compliance. The key is to render as many sites that are out there in the real world while still supporting the standards.

Mozilla has two rendering modes - quirks mode, for 'pea soup' style HTML and standards compliance mode for properly written HTML.

Have a look at View -> Page Info (Mozilla) or Tools -> Page Info (Firebird) to see the rendering mode on each page. Try it with slashdot.org and w3.org

The idea is, people who downloaded the Google toolbar are a prime audience for a Google browser, that removes the IE tie-in for Google and increases the percentage of standards compliant browser users out there.

Firebird isn't standards-compliant. For instance, there are many things wrong with slashdot but Firebird doesn't throw errors or warnings, it just renders the page (test system: Firebird 0.7 on Linux 2.4.20). If you wanted standards-compliance, you'd want Google-Amaya, and I doubt any sane person would use that :-).

I agree. And I agree with the story submitter; the site certainly does have that "made with Vi" look. ;)

I'm suddenly aware of just how dreamy it all is, 'cos I've been looking hard at the WSDL spec, and ohmygod I feel the need to rant. With stuff like this, how can anyone get on with doing the difficult bits of the problems of the future.

It seems to me I work in an island of sanity amidst the spewing supertankers of the W3C and their ilk... an island where a difficult decision is not always put off by adding another "optional" layer of abstraction.

Plus, not only do I work in a world with (IMHO) the best software Lego bricks around, but I also have the freedom to build with them anything that might be useful or interesting.

Only problem is it's difficult to keep the mind on continuous creative output... on "mind-fuzz" days, I sometimes wish I just stacked shelves!

It is actually pretty easy to create tree strucures using the CSS Display property and simple javascript commands. It also allows for more complex trees that contain text,radio or other user input. We use them all the time in PHP and ASPX, and they are a great way to create compact interfaces.

I have always thought that while web applications are harder to implement they usually pay off in the long run, since they are easier to update and (for the most part) side-step any OS compatability issues.

Of course I'm a web programmer, so my opinion might be bias :-)

After getting our email protected with Postfix+Amavisd-new+Clamav+SpamAssassin+F-prot I asked myself: is it possible to get same quality protection for the web-surfing?

And the answer is Yes! It is possible. Now I am using Squid along with Dansguardian and Squidguard. Working together they are catching 99% of all adware/spyware malicious scriptlets. Also they remove annoying banners and give us the required level of the parent control.

Dansguardian integrates with PICS, Platform for Internet Content Selection, which was originally designed to help parents and teachers control what children access on the Internet, but it also facilitates other uses for labels, including code signing and privacy. The PICS platform is one on which other rating services and filtering software have been built.

Unfortunately Squidguard is getting out of its suppot by its original developers. It's getting more and more false-negatives (up-to 30% was complained on getntoo forums), but it's still better to have it.

Now I am bringing same protection to the company network at work and they are happy of that.

My point is to protect your network rather than individual computers. Windows based PC are unsecure per se. Besides it is a hassle to go to each PC and install different types of filtering software (especially when you have to support 3 or more different client OSes, like win98, win2k and MacOS).

Well, you know the great thing about standards is that you have so many to choose from!

However, if you choose the current (dated 26 January 2000) W3C XHTML recommendations then yes, the quotes are required.

I love it when someone quotes an RFC, but doesn't realize that it has been superceded by a more recent RFC. (link to RFC 2396)

Ditto.

If you are referring to the URI request for comments then you are wrong, it's not a standard. Check it out for yourself, the login syntax ([ user [ : password ] @ ] hostport) is only mentined inside of telnet:// and ftp:// not http:// or https://

• httpaddress
• • h t t p : / / hostport [ / path ] [ ? search ]
  
  ftpaddress
  • f t p : / / login / path [ ftptype ]
  
  login
  • [ user [ : password ] @ ] hostport
  
  hostport
  • host [ : port ]

I actually belong to an email list that gets sent to dodgeit, that I consume with an RSS reader that then sends me an email.

So I have:
list -> email -> rss -> email -> me

Why all the hoops? Control. I can end the subscription any time I want and never ever get spammed because I was once a member of the list.

That appears to be the namespace used in the module definitions. See the XHTML 2 specification.

According to the specification, the namespace is still http://www.w3.org/1999/xhtml.

The latest version of the actual standards-track URI spec is RFC 2396 (1998-08).

An informational RFC on the meaning of the terms URL and URN in comparison to URI is RFC 3305 (2003-09)

BTW, The old informational RFC on URI's on the WWW is RFC 1630 (1994-06)

Indeed, having facts just might help a little. Mosiac wasn't the first browser; it came onto the scene a good two years after the first website, and Tim Berners-Lee invented HTTP and HTML while working at CERN, in Switzerland.

According to NCSA's own page, Mosaic started development in June of 1993. The first webserver, info.cern.ch, went online in 1991.

I forgot that a useful reference might help - try this.

Not just feeding trolls but replying to my own posts.. hmm.. bad start to the year.

Q.

Maybe one day you'll learn about those newfangled hyperlink doohickies.

Just fucking great. Instead of actually fixing the problem, they just told RFC 2396 (which is based on the ten year-old RFC 1738 and officially endorsed by the HTTP standard) to fuck itself and called it a day. And in the meantime, they recommend that users not click any links at all.

Just amazing that this is what we have to deal with.

Here's a little hint, it isn't Slashdot that collapses your two spaces into one, it is your browser, which is following the HTML specification concerning white space.

Now, the case of <code> elements is different. Although it doesn't say so in the HTML spec, most browsers handle them with white space being preserved.

This is ancient news, it has been mentioned by me on the ASRG list in November and on my blog. The original new article was published by the Post Gazette, and found by Matt McCay in his blog. Liudvikas Bukys mentioned it in his blog also. You might also want to take a look at the W3C draft on why these visual tests do not work for disabled people. And to end this off, the basic premise of C/R is that the return address is valid. Even if spammers break these visual tests, in order to do that, they must have a valid return address - ergo, making them traceable.

I was just showing an example of how shapes in SVG are reused. SVG graphics can be every bit as complex as fonts. The only feature fonts have that SVG is missing is hinting (changing drawing rules based on scaling).

In fact, there are tools for converting true type fonts to svg. The W3C has information on how to use these svg fonts.

The MathML - MusicXML connection has a history stretching back before anyone heard of MusicXML.

Ok. You really don't know what you're talking about, do you?

Admittedly, you goaded me into looking for info on how LaTeX works (I had used it, but didn't study the format up close). It tends to be more strict than XHTML/CSS actually, and does require good markup of a document. If you want to see some reference, check out this document.

CSS is very flexible for making layouts. Please suggest what you think LaTeX can do that CSS can't. Prior to that, though, you may want to take a look at the spec (and yes, most of that stuff does have good support, even in Explorer).

heh, I bumped into a website of such a moron in 2001, which stated that 'he had 10 years hands-on-experience' in building websites very nice, because the first browser was available around 1993 !`

Actually around 1990 so that still fits in the 10 year line... www

Do yourself a favour and go for the Strict versions of the (X)HTML markups directly. Don't waste time with Transitional markup, because you'll be creating the same old tag soup that all the browsers (old and new) will happily eat in quirks mode. When the day comes (after your transition?) and you finally set that DTD to Strict, all your pages will be blown to bollocks because the browsers will now render them in strict standards compliance mode.

Why bother? You can't really benefit from Style Sheets in quirks mode anyway? Remember, the rendering is completely different between quirks and strict standards compliance mode, and with good reason! The browser developers finally had a chance to do it right with strict standards compliance mode rendering because their implementations are made from scratch from the same thorough W3C spec. With quirks mode they just use their old layout engines from back during the browser wars.

You'll benefit greatly from the Strict versions of the (X)HTML markup. While taking full advantage of Style Sheets and ridding your old (X)HTML sources of the deprecated presentational tags, you'll end up with more easily maintainable (X)HTML sources. Think about it, most of your pages might already consist of 80% tags related to presentation. When you have removed these from one page and put the presentational information in an external style sheet, it won't be that much of an effort to apply these resulting style sheet rules to the rest of your pages. Why? Because most of the time you'll just be removing deprecated tags. Sure, there's still a bit of structure to deal with, but it's a worthwile task.

I've written "(X)HTML" in this comment a couple of times now. As I see it, the Transitional/Strict issue is infinately more important than the HTML/XHTML issue. When you have Strict HTML markup it's really a no-brainer to convert it to XHTML, because it's pretty much about syntax, well formedness. Try taking a look at W3C's HTML compatibility guidelines for XML. If you do yourself a favor and explicitly use closing tags, etc. you can convert your HTML to XHTML with a couple of regular expression substituions. That's pretty much it. Bottom line: the main difference between the Strict versions og HTML and XHTML is largely syntax. (There are some elements of your DOM that require special attention with respects to applying CSS, but this statement is essentially true.)

If you care about having the same result shown accross browsers (especially IE), then watch out for XHTML.

(Borrowing a bit from a previous comment I made here on /.) IE can be a stick in the wheel, because it ignores the XML declaration in XHTML documents beginning like this:

<?xml version='1.0' encoding='iso-8859-1'?>

IE expects to encounter the DOCTYPE first, which doesn't make sense - and would be non-valid XHTML markup. When IE encounters the above declaration it throws itself into quirks mode, unconditionally!

Sure, the XML declaration is not strictly required, however if you read the W3C XHTML spec it says:

An XML declaration is not required in all XML documents; however XHTML document authors are strongly encouraged to use XML declarations in all their documents. Such a declaration is required when the character encoding of the document is other than the default UTF-8 or UTF-16 and no encoding was determined by a higher-level protocol.

Another point. XHTML pages should really only be created for the purpose of being served - by your web server - as application/xhtml+xml. See W3C's document on XHTML Media Types. IE doesn't support the application/xhtml+xml media type, and this together with the above mentioned deficiency makes for quite a showstopper with respects to the adoption of XHTML - it's sad, really.

Mozilla and Opera will handle XHTML documents served as application/xhtml+xm

Do yourself a favour and go for the Strict versions of the (X)HTML markups directly. Don't waste time with Transitional markup, because you'll be creating the same old tag soup that all the browsers (old and new) will happily eat in quirks mode. When the day comes (after your transition?) and you finally set that DTD to Strict, all your pages will be blown to bollocks because the browsers will now render them in strict standards compliance mode.

Why bother? You can't really benefit from Style Sheets in quirks mode anyway? Remember, the rendering is completely different between quirks and strict standards compliance mode, and with good reason! The browser developers finally had a chance to do it right with strict standards compliance mode rendering because their implementations are made from scratch from the same thorough W3C spec. With quirks mode they just use their old layout engines from back during the browser wars.

You'll benefit greatly from the Strict versions of the (X)HTML markup. While taking full advantage of Style Sheets and ridding your old (X)HTML sources of the deprecated presentational tags, you'll end up with more easily maintainable (X)HTML sources. Think about it, most of your pages might already consist of 80% tags related to presentation. When you have removed these from one page and put the presentational information in an external style sheet, it won't be that much of an effort to apply these resulting style sheet rules to the rest of your pages. Why? Because most of the time you'll just be removing deprecated tags. Sure, there's still a bit of structure to deal with, but it's a worthwile task.

I've written "(X)HTML" in this comment a couple of times now. As I see it, the Transitional/Strict issue is infinately more important than the HTML/XHTML issue. When you have Strict HTML markup it's really a no-brainer to convert it to XHTML, because it's pretty much about syntax, well formedness. Try taking a look at W3C's HTML compatibility guidelines for XML. If you do yourself a favor and explicitly use closing tags, etc. you can convert your HTML to XHTML with a couple of regular expression substituions. That's pretty much it. Bottom line: the main difference between the Strict versions og HTML and XHTML is largely syntax. (There are some elements of your DOM that require special attention with respects to applying CSS, but this statement is essentially true.)

If you care about having the same result shown accross browsers (especially IE), then watch out for XHTML.

(Borrowing a bit from a previous comment I made here on /.) IE can be a stick in the wheel, because it ignores the XML declaration in XHTML documents beginning like this:

<?xml version='1.0' encoding='iso-8859-1'?>

IE expects to encounter the DOCTYPE first, which doesn't make sense - and would be non-valid XHTML markup. When IE encounters the above declaration it throws itself into quirks mode, unconditionally!

Sure, the XML declaration is not strictly required, however if you read the W3C XHTML spec it says:

An XML declaration is not required in all XML documents; however XHTML document authors are strongly encouraged to use XML declarations in all their documents. Such a declaration is required when the character encoding of the document is other than the default UTF-8 or UTF-16 and no encoding was determined by a higher-level protocol.

Another point. XHTML pages should really only be created for the purpose of being served - by your web server - as application/xhtml+xml. See W3C's document on XHTML Media Types. IE doesn't support the application/xhtml+xml media type, and this together with the above mentioned deficiency makes for quite a showstopper with respects to the adoption of XHTML - it's sad, really.

Mozilla and Opera will handle XHTML documents served as application/xhtml+xm

The problem with slashdot is that it *isn't* HTML 3.2 (a STANDARD!) compliant - if it was, it would validate. It doesn't.

The problem with slashdot is that it *isn't* HTML 3.2 (a STANDARD!) compliant - if it was, it would validate. It doesn't.

The W3C WAI resource page has pointers to everything you need to know. A popular tool that helps evaluating web accessibility is Bobby, but unfortunatly it isn't free.

The W3C WAI resource page has pointers to everything you need to know. A popular tool that helps evaluating web accessibility is Bobby, but unfortunatly it isn't free.

One of the major advantages of going "standard" is simply the correctness of the XHTML/HTML you'll send to the browser; no missing tags, no misordered, no proprietary tags will do 80% of the job. The W3 validator is your friend.

Most of the trouble with "IE-enhanced" pages is the interpretation of errors by parsers. If I write:

[p][strong]foo[em]bar[/strong]baz[br]

In what tags is the 'baz'? depends on who reads it, mmh?

Except for NN4, unrecognized CSS tags will just go unnoticed for lower-version browsers, so that if your structure is OK, it should be usable for most browsers.

You might want to test with Mac's browsers (IE5 at least) to make sure your ECMAscript works; some core methods are missing.

And, should you need an incentive to go table-less, there is a great presentation that summarizes the advantages.

The css Zen garden is a great example if you want to show colleagues why separating presentation from content is a neat idea.

Aiming for standards compliance is always a good thing, IMHO. However, you will find that you will have to make compromises along the way given that not all browsers comply with the standards to the same degree.

About 2 years ago I was involved in redeveloping our proprietary Web app to comply more with standards. It was a huge uphill battle to try and convince management that this was what they wanted. Complying to standards meant we had to drop or significantly change features of the app to ensure that it would work cross-browser and remain accessible.

My main advice is that whenever you ahve to make compromises on functionality and compliance, try and veer to the side of compliance. Your customers will (hopefully) thank you for it in the long run. Especially, if like me, they don't use IE or Netscape :-)

being knighted in recognition of his "services to the global development of the Internet"

Mozilla Firebird 0.7 (Gecko/20031103) here; and I definitely have this problem. I'd say approximately every fifth view of a Slashdot page only the menu on the left and the page header appear. Refreshing once or twice normally solves the problem.

I don't blame the Gecko engine for this but rather the Slashdot HTML which fails to validate as any version of HTML.

So, has anyone heard of a word processor that has an XML file format that contains all its binary data?

Does there need to be an implementation? XHTML has supported this since it was first published (Jan 2000, not including public drafts).

Specifically, you embed the binary data using the data: URL scheme, so, for example, you would write:

&lt;img src="data:image/jpeg;base64,ggifudghifudgdfig"&gt;

The data: URL scheme RFC was published in August 1998. However, to my knowledge, the only implementation was first created six months ago (the Opera web browser).

I'm sure Sun and the W3C would be interested in that claim

This version:
http://www.w3.org/TR/2001/WD-soap12-20010709/
Latest version:
http://www.w3.org/TR/soap12/
Editors:
Martin Gudgin (DevelopMentor)
Marc Hadley (Sun Microsystems)
Jean-Jacques Moreau (Canon)
Henrik Frystyk Nielsen (Microsoft Corp.)

I'm sure Sun and the W3C would be interested in that claim

This version:
http://www.w3.org/TR/2001/WD-soap12-20010709/
Latest version:
http://www.w3.org/TR/soap12/
Editors:
Martin Gudgin (DevelopMentor)
Marc Hadley (Sun Microsystems)
Jean-Jacques Moreau (Canon)
Henrik Frystyk Nielsen (Microsoft Corp.)

Honestly, HTML is a decent precedent for XML. Sure the structure is less ordered, and not so clearly delineated between logical/structral and layout/presentation halves. But the idea of using containing tags to structure text has been around since at least SGML in 1986.

If you want commercial, yet high quality examples, look at some of the tools from ArborText, Softquad, or even Altova. If you want something from the GNU project, then look at the PSGML mode for Emacs, which I recall using already in 1995. I'm sure I'm missing many examples from the 70's and 80's.

To take other recent examples, the versions of HTML prior to XHTML are in SGML. SGML and XML are the rules for defining sets of rules (aka DTDs) like HTML. You have many choices:

• HTML 2.0 (sgml)
• HTML 3.2 (sgml)
• HTML 4.01 (sgml)
• XHTML 1.0 (XML)
• Docbook 4.x (sgml + xml)
• TEI (sgml)
• TEI-lite (sgml + xml)
• ... and so on

Honestly, HTML is a decent precedent for XML. Sure the structure is less ordered, and not so clearly delineated between logical/structral and layout/presentation halves. But the idea of using containing tags to structure text has been around since at least SGML in 1986.

If you want commercial, yet high quality examples, look at some of the tools from ArborText, Softquad, or even Altova. If you want something from the GNU project, then look at the PSGML mode for Emacs, which I recall using already in 1995. I'm sure I'm missing many examples from the 70's and 80's.

To take other recent examples, the versions of HTML prior to XHTML are in SGML. SGML and XML are the rules for defining sets of rules (aka DTDs) like HTML. You have many choices:

• HTML 2.0 (sgml)
• HTML 3.2 (sgml)
• HTML 4.01 (sgml)
• XHTML 1.0 (XML)
• Docbook 4.x (sgml + xml)
• TEI (sgml)
• TEI-lite (sgml + xml)
• ... and so on

Honestly, HTML is a decent precedent for XML. Sure the structure is less ordered, and not so clearly delineated between logical/structral and layout/presentation halves. But the idea of using containing tags to structure text has been around since at least SGML in 1986.

If you want commercial, yet high quality examples, look at some of the tools from ArborText, Softquad, or even Altova. If you want something from the GNU project, then look at the PSGML mode for Emacs, which I recall using already in 1995. I'm sure I'm missing many examples from the 70's and 80's.

To take other recent examples, the versions of HTML prior to XHTML are in SGML. SGML and XML are the rules for defining sets of rules (aka DTDs) like HTML. You have many choices:

• HTML 2.0 (sgml)
• HTML 3.2 (sgml)
• HTML 4.01 (sgml)
• XHTML 1.0 (XML)
• Docbook 4.x (sgml + xml)
• TEI (sgml)
• TEI-lite (sgml + xml)
• ... and so on

Honestly, HTML is a decent precedent for XML. Sure the structure is less ordered, and not so clearly delineated between logical/structral and layout/presentation halves. But the idea of using containing tags to structure text has been around since at least SGML in 1986.

If you want commercial, yet high quality examples, look at some of the tools from ArborText, Softquad, or even Altova. If you want something from the GNU project, then look at the PSGML mode for Emacs, which I recall using already in 1995. I'm sure I'm missing many examples from the 70's and 80's.

To take other recent examples, the versions of HTML prior to XHTML are in SGML. SGML and XML are the rules for defining sets of rules (aka DTDs) like HTML. You have many choices:

• HTML 2.0 (sgml)
• HTML 3.2 (sgml)
• HTML 4.01 (sgml)
• XHTML 1.0 (XML)
• Docbook 4.x (sgml + xml)
• TEI (sgml)
• TEI-lite (sgml + xml)
• ... and so on

Validated this sample, *122* errors. Validated sample

The bad news is that the onus of work will shift onto site authors. Anyone maintaining a site using embedded objects will have to either re-code or suffer a changed "user experience".

Ahhh - that's useful. Since they are recoding, they now have the chance it make it accessible too. That would be beneficial for users.

... windows IE only calls ... using the object tag instead of applet tags,

Are you aware of the 503 Service Unavailable status code? It comes complete with an optional Retry-After header.

Well, according to the explanation of the semantic web, they can talk to eachother about pretty much everything you want them to talk about.

Mosaic? Ha! You n00b! You should be using WorldWideWeb.

Took me a while to get used to, but that is the standard now according to w3, see this link. The upshot is that XHTML should all be in lowercase because it is based on XML (which is case-sensitive), and the DTD for XHTML is in lower case. I remember the days when most standards people wanted it in uppercase to look like SGML...

Excuse me for replying to myself, but it gets worse.

As others have mentioned, the damned thing doesn't work correctly in Gecko-based browsers. I was intrigued by the article, but with a website like that, they are not going to see any of my money.

Why indeed?

Here's what the W3C thinks.

Frames and XHTML, sheesh, these guys are amatuers.