Slashdot Mirror

The list of valid link types does not include "Nofollow", but "Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types."

Too lazy to search, huh? Ok, I'll give up moderation and search for you :)

And the answer, of course, is yes. "rel" attribute, valid for "a" and "link" element types. Take a look at the source of any Wordpress weblog and you'll see it being used for many things already.

The caveat is that you should define a profile about the valid keywords you'll be using in "rel"; I don't know if Google is using a profile, but it's not mandatory.

It's an interesting idea, but it's probably a matter of short order before MS starts to use this to cut out non-MS sites.

It's an interesting idea, but it's probably a matter of short order before MS starts to use this to cut out non-MS sites.

• Linux version
• Advanced mode interface (access to EXIF data for instance)
• Album and collection oriented classification (two levels)
• Comment and tags on photo areas (auto detecting human heads)
• Integration with popular blogging software (MT, WP, etc) not only blogger
• More date related auto classification features (detecting and grouping photos in different time ranges: hours, days, etc)
• L10n
• In addition to tags additional ways of stablishing relation between pictures
• Import from Internet
• Be faster

Not meant to offend, just a joke (however, /. people could better check articles...).
This kind of calls can be done, since some years, with Web Services protocols (i.e., XML-RPC, SOAP, etc).
Look at W3C .

All right I understand, a lot of you /kids don't like the XML. But look at it this way, XML is exactly as dumb as you think it is, you just don't realize how dumb everything else you do is.

Since it's the topic of conversation, let's take programming languages. Now, I know you're all saying "why write in xml when I can write in (insert something here, for example parent's reference to "english"). Sureley, there's no one here, of all places, who thinks that english (a la Pascal, etc.) is a good markup language (oops I mean syntax) for a program. Even a language like C, that embraces non-textual delimiters, still has its issues. As I'm sure a many former tcl programmer (or, for arument's sake current tcl programmer) will agree with me when I say that keywords are preposterous. (note to lisp programmers: special forms are very special keywords).

In the end, wouldn't programming within a framework where structural elements of the language can be differentiated from naming constructs be a good idea?

You say that XML is so simple it's not structure, but this is only because you think that structure is easy. What happens when I want to mix structure with truly unstructured data (or even with other structures)? The fact of the matter is that extracting structured data like the loop represented by "for i in $* ;do echo $i ;done" from an otherwise unstructiured source (say this posting) is next to imposible -- Note here I've made it "easy" for you by using quotes, but even that doesn't tell you much, since I accidentally quoted the word easy as well.

Of course, XML is not needed for this endeavor. As I mentioned, tcl (a thing near and dear to my perverse heart) is an example of an compact and elegant language expression. It smounts to what you might call good markup (Mind you, no one uses it). But herein lies the heart of understanding XML. It's not that we need it; I mean, it's not actually good for anything. It's just that, as a common denominator, it is pretty good (a hell of a lot better than bare ASCII), for doing just about anything at all.

So, in the case of a language, you could write a parser that balances case with esac, or you could get one of IBM's code-monkeys to do it for you, which do you prefer?
Me, I've always wanted a monkey.

Then, once you've got your XML-based language, you can let it play with other xml documents. For example, if you are the one-in-a-million programmer who thinks that documentation is a good thing, you could add marked up documentation to your program without resorting to arcane @incantations in your comments.

Listen, I'm not saying that XML programming languages are a brilliant idea (it's probably a bit wordy to make a lot of programmers happy). And, of couse, I didn't bother to RTFA, since XML-based programming languages have been around for a while. But, saying XML is dumb is really missing the point (by which I mean, that's the whole point)

The goal, of course is that we can leverage this

Errrrrr deft - i hate to tell you this, but your homepage site isn't compliant.
What kind of message does THAT put out to your prospective customers?
It will be especially bad if you wrote it ;)

Heres the link so you can see and rectify, it might be something or nothing.

Workflow engines have done this for years. Xforms can be extensible in this fashion as well. Basically, any engine that interprets some type of XML tag that describes a condition and runs a proceedure call based on that condition with a list of parameters does what this guy is talking about.

My point is, why reinvent the wheel, when half of a wheel is aleready invented in XEXPR?

I've done lots of programming in XSLT, which is an XML-based programming language.

It's annoying as heck.

As you use it more and more, you find that there are lots of situations that you can deal with in a "normal" language that have no equivalent expressibility in XML. The problem comes in the strict matching of open/close tags. The easiest way to explain it is in terms of the English language, but code flow is similar. A simple liguistic example is as follows.

Consider the sentence: The dog walked. This might end up as the following XML: <sentence>The dog walked</sentence>

But now suppose you have the sentence: He said, "Hello." You CANNOT do: <sentence>He said, <quote>Hello</sentence></quote> Instead, you have to do: <sentence>He said, <quote>Hello</quote></sentence> And then your period ends up on the wrong side of the quote.

The same thing happens with logic flow statements, and you end up having to copy and paste code or create all kinds of extra functions. For example, suppose you are writing a simple "program" that puts either "<b>...</b>" or "<i>...</i>" around some text depending on whether it is to be bold or italic.

You can't do this:

<if bold==true><b></if>
<if italic==true><i></if>
Complex code here for inserting text
<if bold==true></b></if>
<if italic==true></i></if>

Instead, you have to do ...

<if bold==true><b>Complex code here for inserting text</b></if>
<if italic==true><i>Complex code here for inserting text</i></if>

It's a big pain because you end up having to break your code into lots of small, unnatural functions that are called a bunch of times from the same small section of code, but nowhere else.

XML has its place, but as a programming language, it's pretty cumbersome.

Jakob Nielsen does seem like a bit of a flea-market seller... and his website makes him seem rather like a hack. Not only does he FAIL to adhere to his own guidelines, FAIL to adhere to web standards ( http://validator.w3.org/check?verbose=1&uri=http%3 A//www.useit.com/ ), he also utterly FAILed to make his website tolerable to browse. A perfect example of someone talking far more than they are worth.

Every second link (or far more in some cases) leads to some miraculous report with conspicuously high number of rules that he is trying to sell. And chances are the little short snippets available freely combined with common sense are about worth as much as the 15,314 guidelines he is selling for the same topic.

Needs to learn to write valid HTML (-:

Uh, IFRAME is in the W3C standard. (here, actually). It is HTMLs concept of an "inline frame". But the javascript part may very well be a problem :-)

Use it to access my resume and you'll find a really nasty Javascript bug. (The link to my email is generated on the fly, to hide it from spambots. The hover behavior works correctly in IE but not Firefox.)

I don't see any nasty bug in Firefox. I do see a minor bug in Internet Explorer, and some bad HTML design in that code.

The IE bug is that it displays, when you hover over the image, "click here to send me email". It is getting that from the alt tag on your image, and shouldn't. The alt tag is to "specify alternate text to serve as content when the element cannot be rendered normally". However, the image is being rendered normally, so IE shouldn't be rendering that tag. If there were a title tag, it should render that, though.

Now, think about why the alt attribute is mandatory on img elements. It's to achieve device independence. When somebody isn't loading images (because they're blind and using a screen reader, or using a cellphone or other low-bandwidth device, or because they haven't started X and are using lynx, or for whatever reason) then they should be able to get a coherent web page. The web community has been trying for years to get authors to include alt tags; they wrote the accessibility guidelines mostly just to be able to officially say to include alt tags. Finally, in HTML 4, the alt tag was made mandatory.

So, what's the point of your alt tag? It doesn't replace the image in a non-image setting. In fact, in most cases when there are no images (blind, cellphone, lynx, etc) there is no mouse, so your replacement text is usually inappropriate. In some such cases, there may not even be JavaScript. (You can handle that gracefully too.)

Now, suppose I saw your sig and was considering hiring you. One thing I'd do is to check your resume. I see that you spent most of your career as a tech writer, and still can't think about the range of your audience. Since (in this hypothesis) I saw your sig on /., I'd check your posting history and see your post. Here, you flame about a "really nasty JavaScript bug" which, as far as I can tell, has nothing to do with JavaScript, and is also not a bug but a correct implementation of the XHTML spec. You claim to be qualified in XHTML, but don't understand something as simple and well-documented as the purposes of alt vs title. Did you never actually read the XHTML spec? What gave you the idea that alt should provide tooltips? Mr. Rabinovitch, why (in this hypothesis) should I continue to consider you?

That's a rhetorical question, by the way. I don't care about hiring you; my team is currently full of people who do think about cross-compatibility, and read documentation, and understand their tools. I'm just telling you that you've done yourself a disservice in posting this. If I were you, I'd think about fixing that resume webpage before somebody also thinks that you don't learn from your mistakes.

Use it to access my resume and you'll find a really nasty Javascript bug. (The link to my email is generated on the fly, to hide it from spambots. The hover behavior works correctly in IE but not Firefox.)

I don't see any nasty bug in Firefox. I do see a minor bug in Internet Explorer, and some bad HTML design in that code.

The IE bug is that it displays, when you hover over the image, "click here to send me email". It is getting that from the alt tag on your image, and shouldn't. The alt tag is to "specify alternate text to serve as content when the element cannot be rendered normally". However, the image is being rendered normally, so IE shouldn't be rendering that tag. If there were a title tag, it should render that, though.

Now, think about why the alt attribute is mandatory on img elements. It's to achieve device independence. When somebody isn't loading images (because they're blind and using a screen reader, or using a cellphone or other low-bandwidth device, or because they haven't started X and are using lynx, or for whatever reason) then they should be able to get a coherent web page. The web community has been trying for years to get authors to include alt tags; they wrote the accessibility guidelines mostly just to be able to officially say to include alt tags. Finally, in HTML 4, the alt tag was made mandatory.

So, what's the point of your alt tag? It doesn't replace the image in a non-image setting. In fact, in most cases when there are no images (blind, cellphone, lynx, etc) there is no mouse, so your replacement text is usually inappropriate. In some such cases, there may not even be JavaScript. (You can handle that gracefully too.)

Now, suppose I saw your sig and was considering hiring you. One thing I'd do is to check your resume. I see that you spent most of your career as a tech writer, and still can't think about the range of your audience. Since (in this hypothesis) I saw your sig on /., I'd check your posting history and see your post. Here, you flame about a "really nasty JavaScript bug" which, as far as I can tell, has nothing to do with JavaScript, and is also not a bug but a correct implementation of the XHTML spec. You claim to be qualified in XHTML, but don't understand something as simple and well-documented as the purposes of alt vs title. Did you never actually read the XHTML spec? What gave you the idea that alt should provide tooltips? Mr. Rabinovitch, why (in this hypothesis) should I continue to consider you?

That's a rhetorical question, by the way. I don't care about hiring you; my team is currently full of people who do think about cross-compatibility, and read documentation, and understand their tools. I'm just telling you that you've done yourself a disservice in posting this. If I were you, I'd think about fixing that resume webpage before somebody also thinks that you don't learn from your mistakes.

Use it to access my resume and you'll find a really nasty Javascript bug. (The link to my email is generated on the fly, to hide it from spambots. The hover behavior works correctly in IE but not Firefox.)

I don't see any nasty bug in Firefox. I do see a minor bug in Internet Explorer, and some bad HTML design in that code.

The IE bug is that it displays, when you hover over the image, "click here to send me email". It is getting that from the alt tag on your image, and shouldn't. The alt tag is to "specify alternate text to serve as content when the element cannot be rendered normally". However, the image is being rendered normally, so IE shouldn't be rendering that tag. If there were a title tag, it should render that, though.

Now, think about why the alt attribute is mandatory on img elements. It's to achieve device independence. When somebody isn't loading images (because they're blind and using a screen reader, or using a cellphone or other low-bandwidth device, or because they haven't started X and are using lynx, or for whatever reason) then they should be able to get a coherent web page. The web community has been trying for years to get authors to include alt tags; they wrote the accessibility guidelines mostly just to be able to officially say to include alt tags. Finally, in HTML 4, the alt tag was made mandatory.

So, what's the point of your alt tag? It doesn't replace the image in a non-image setting. In fact, in most cases when there are no images (blind, cellphone, lynx, etc) there is no mouse, so your replacement text is usually inappropriate. In some such cases, there may not even be JavaScript. (You can handle that gracefully too.)

Now, suppose I saw your sig and was considering hiring you. One thing I'd do is to check your resume. I see that you spent most of your career as a tech writer, and still can't think about the range of your audience. Since (in this hypothesis) I saw your sig on /., I'd check your posting history and see your post. Here, you flame about a "really nasty JavaScript bug" which, as far as I can tell, has nothing to do with JavaScript, and is also not a bug but a correct implementation of the XHTML spec. You claim to be qualified in XHTML, but don't understand something as simple and well-documented as the purposes of alt vs title. Did you never actually read the XHTML spec? What gave you the idea that alt should provide tooltips? Mr. Rabinovitch, why (in this hypothesis) should I continue to consider you?

That's a rhetorical question, by the way. I don't care about hiring you; my team is currently full of people who do think about cross-compatibility, and read documentation, and understand their tools. I'm just telling you that you've done yourself a disservice in posting this. If I were you, I'd think about fixing that resume webpage before somebody also thinks that you don't learn from your mistakes.

Ok, I'll bite. Here's mine: HTML primary version or PDF edition.

I get unsolicited mail from people impressed by it, and asking if they can use the same format. Feel free (I retain all rights to the text, of course).

I also just got a new job, so I'm doing something right (although it could be despite the CV, heh).

My CV guidelines:

• Fixed size of four pages.
• Use clear English in text passages.
• Use a clean, professional format that looks good on screen and paper.
• Start with Career Objective, since it demonstrates motivation and bundles the career history together.
• Follow with the skill checklist, which is all that some recruitment people will look at anyway.
• Follow with the employment history, most recent at the top with the most detail. Every time I've moved job, I've compressed the wording for older entries.
• Successes are interesting. Highlight them in a way that entices discussion at interview. Corollary: you must be able to discuss absolutely everything mentioned in your resume, in depth and detail.
• I don't bother with an education section. At my career stage, it's irrelevant. I'm not interested in working for people who think it is.
• Keep the miscellaneous section to a single page.
• Original is HTML, revision-controlled. I prefer to send the PDF version when submitting applications, because it guarantees format, and because I've known recruiters to deliberately edit Word format etc without my authorization.
• HTML version should be validating XHTML 1.0 Transitional and the underlying HTML source should be very clean and professional.

I don't think so. Marked-up binary similar to what's in EBML has been around in the telecommunications industry for a while. There's ASN.1 (complete with standardised XML encoding), and also WBXML (oh, and this *is* a W3C standard). Still, their design is at odds with many of the principles behind XML, but they're extensible and contain tag-like metadata.

I had to be compatible with .NET SOAP (XML) and I had hard time guessing how to behave to be compatible with the Microsoft SOAP server.

I was using Perl SOAP::Lite, see its section on Microsoft compatibility issues. Still Microsoft conforms to the specification although only the Microsoft way of using standards is correctly recognized. Clearly anti-competitive behavior while still standards compliant - simply perfect.

Just look at DOM Level 2 Style which shows you how to manipulate style rules and stylesheets programmatically. Mozilla supports this API per the spec (at least *I* didn't find any deviations from it in Moz); MSIE supports most of it with a few MS-specific wrinkles.

For that matter, you can use DOM to change the src attribute of a LINK element, which is how a lot of style switchers work.

The DIR element was designed to be used for creating multicolumn directory lists. The MENU element was designed to be used for single column menu lists. Both elements have the same structure as UL, just different rendering. In practice, a user agent will render a DIR or MENU list exactly as a UL list.

We strongly recommend using UL instead of these elements.

The DIR element was designed to be used for creating multicolumn directory lists. The MENU element was designed to be used for single column menu lists. Both elements have the same structure as UL, just different rendering. In practice, a user agent will render a DIR or MENU list exactly as a UL list.

We strongly recommend using UL instead of these elements.

The DIR element was designed to be used for creating multicolumn directory lists. The MENU element was designed to be used for single column menu lists. Both elements have the same structure as UL, just different rendering. In practice, a user agent will render a DIR or MENU list exactly as a UL list.

We strongly recommend using UL instead of these elements.

The DIR element was designed to be used for creating multicolumn directory lists. The MENU element was designed to be used for single column menu lists. Both elements have the same structure as UL, just different rendering. In practice, a user agent will render a DIR or MENU list exactly as a UL list.

We strongly recommend using UL instead of these elements.

PNG supports arbitrary text blocks...there's no reason why you couldn't embedd EXIF data, someone would just have to standardize the way to do it....

I was kidding about having "invented" it, or it being an "alternative" to Dreamweaver templates (I've used them, and they are quite powerful and useful). That said, I do indeed manage my sites like that, simply because I do all my XHTML by hand; I am a standards freak, and if the (X)HTML editor of the W3C itself doesn't do semantics right (with commands like "bold," or "bulleted list"), I see no reason to trust graphical editors in general.

You linked to the second issue out of three.

The first issue out of three is not fixed in Firefox 1.0.

The third issue out of three might not be fixed in Firefox 1.0; the article does not mention this version with any certainty.

Firefox 0.9 has three vulnerabilities. Firefox 1.0 has one vulnerability. The only way to be secure is to use a different browser, no matter how crappy it may be.

In my capacity as a web developer, here are the software packages that I feel you should have a firm understanding of:

1. XHTML - not just 'HTML', XHTML has a few changes that you should get used to (such as closing all tags, even <img src="..."/> and <br/> tags, and all tags being lowercase). For the upcoming specifications, such as XHTML 2.0, which will be very different (you can apply an href="..." property to ANY object, instead of having to wrap it in an <a href=..."> tag), it never hurts to be prepared.
2. CSS3 - May as well read up now, it's going to be relevant in not too long.
3. Photoshop - Use The GIMP if you must, but I find Photoshop generally does what I need it to with less hassle.
4. PHP, ASP, Coldfusion, and J2EE - You don't have to learn how to program in each one, but learn about these solutions, if for no other reason than to make compelling arguments against them if the bosses ever ask you about them (or worse, fail to ask you about them)
5. Apache and IIS - for the same reasons as listed above; also, a lot of things in Apache (mod_rewrite, for example) can help you solve problems down the road. Good things to know.
6. A good editor. I use ViM myself, but what you use is up to you. What you'll want is syntax highlighting, auto-indenting, and a powerful (preferably regex) search/replace. Learn to use your editor and you will save hours of work with seconds of typing.

And now for some soft skills. First, you'll need to learn to give effective presentations. You could use Powerpoint for this, or Keynote or Impress or just print them on transparencies and put them on an overhead projector. How you do it is up to you. Will you ever need to give presentations? Not really, but effective presentations require a lot of soft skills - eye contact, graphic design, pacing, speech tones, body language - that to be skilled in presentations in general means to be skilled in a lot of other areas.

You should also familiarize yourself with colour. Learn about Pantone, just so that you know about it. Learn how colours play off each other, which colors look good on which backgrounds. Learn about bordering, whitespace, balance, and form. Consider the Pantone Guide to Communicating with Color - out of 61 reader reviews, it got 4.5/5 stars, and is a good place to start.

Learn about logos. How companies make logos, and why. What goes into making a logo, subconscious suggestions from logos (there's a reason Playboy picked a bunny for their logo, and it's not obvious). This will help in your graphic design and page layout.

Learn about accessibility and colour-blindness.

I'm probably missing a ton of important stuff, but if you do it right and are willing to learn (and posting on slashdot seems to imply that), you'll probably learn what you need to know as you go. If not, just come back and post another Ask Slashdot.

In my capacity as a web developer, here are the software packages that I feel you should have a firm understanding of:

1. XHTML - not just 'HTML', XHTML has a few changes that you should get used to (such as closing all tags, even <img src="..."/> and <br/> tags, and all tags being lowercase). For the upcoming specifications, such as XHTML 2.0, which will be very different (you can apply an href="..." property to ANY object, instead of having to wrap it in an <a href=..."> tag), it never hurts to be prepared.
2. CSS3 - May as well read up now, it's going to be relevant in not too long.
3. Photoshop - Use The GIMP if you must, but I find Photoshop generally does what I need it to with less hassle.
4. PHP, ASP, Coldfusion, and J2EE - You don't have to learn how to program in each one, but learn about these solutions, if for no other reason than to make compelling arguments against them if the bosses ever ask you about them (or worse, fail to ask you about them)
5. Apache and IIS - for the same reasons as listed above; also, a lot of things in Apache (mod_rewrite, for example) can help you solve problems down the road. Good things to know.
6. A good editor. I use ViM myself, but what you use is up to you. What you'll want is syntax highlighting, auto-indenting, and a powerful (preferably regex) search/replace. Learn to use your editor and you will save hours of work with seconds of typing.

And now for some soft skills. First, you'll need to learn to give effective presentations. You could use Powerpoint for this, or Keynote or Impress or just print them on transparencies and put them on an overhead projector. How you do it is up to you. Will you ever need to give presentations? Not really, but effective presentations require a lot of soft skills - eye contact, graphic design, pacing, speech tones, body language - that to be skilled in presentations in general means to be skilled in a lot of other areas.

You should also familiarize yourself with colour. Learn about Pantone, just so that you know about it. Learn how colours play off each other, which colors look good on which backgrounds. Learn about bordering, whitespace, balance, and form. Consider the Pantone Guide to Communicating with Color - out of 61 reader reviews, it got 4.5/5 stars, and is a good place to start.

Learn about logos. How companies make logos, and why. What goes into making a logo, subconscious suggestions from logos (there's a reason Playboy picked a bunny for their logo, and it's not obvious). This will help in your graphic design and page layout.

Learn about accessibility and colour-blindness.

I'm probably missing a ton of important stuff, but if you do it right and are willing to learn (and posting on slashdot seems to imply that), you'll probably learn what you need to know as you go. If not, just come back and post another Ask Slashdot.

In my capacity as a web developer, here are the software packages that I feel you should have a firm understanding of:

1. XHTML - not just 'HTML', XHTML has a few changes that you should get used to (such as closing all tags, even <img src="..."/> and <br/> tags, and all tags being lowercase). For the upcoming specifications, such as XHTML 2.0, which will be very different (you can apply an href="..." property to ANY object, instead of having to wrap it in an <a href=..."> tag), it never hurts to be prepared.
2. CSS3 - May as well read up now, it's going to be relevant in not too long.
3. Photoshop - Use The GIMP if you must, but I find Photoshop generally does what I need it to with less hassle.
4. PHP, ASP, Coldfusion, and J2EE - You don't have to learn how to program in each one, but learn about these solutions, if for no other reason than to make compelling arguments against them if the bosses ever ask you about them (or worse, fail to ask you about them)
5. Apache and IIS - for the same reasons as listed above; also, a lot of things in Apache (mod_rewrite, for example) can help you solve problems down the road. Good things to know.
6. A good editor. I use ViM myself, but what you use is up to you. What you'll want is syntax highlighting, auto-indenting, and a powerful (preferably regex) search/replace. Learn to use your editor and you will save hours of work with seconds of typing.

And now for some soft skills. First, you'll need to learn to give effective presentations. You could use Powerpoint for this, or Keynote or Impress or just print them on transparencies and put them on an overhead projector. How you do it is up to you. Will you ever need to give presentations? Not really, but effective presentations require a lot of soft skills - eye contact, graphic design, pacing, speech tones, body language - that to be skilled in presentations in general means to be skilled in a lot of other areas.

You should also familiarize yourself with colour. Learn about Pantone, just so that you know about it. Learn how colours play off each other, which colors look good on which backgrounds. Learn about bordering, whitespace, balance, and form. Consider the Pantone Guide to Communicating with Color - out of 61 reader reviews, it got 4.5/5 stars, and is a good place to start.

Learn about logos. How companies make logos, and why. What goes into making a logo, subconscious suggestions from logos (there's a reason Playboy picked a bunny for their logo, and it's not obvious). This will help in your graphic design and page layout.

Learn about accessibility and colour-blindness.

I'm probably missing a ton of important stuff, but if you do it right and are willing to learn (and posting on slashdot seems to imply that), you'll probably learn what you need to know as you go. If not, just come back and post another Ask Slashdot.

Everything *ML-related you can learn from the W3C's Technical Reports. They also have a wide selection of examples/quick reference material in their tutorials.

I would advise not using JavaScript. Learn it all you want, but don't use it.

While we could have a PHP vs Perl flame war, I'd suggest you take your time and try them both. And for the heck of it, throw Python into the mix. Learn them all, learn their quirks, and decide for yourself which is better for the job.

Whenever you design a page, test it in lynx first. If it look good text-only, it will look good in anything (IE-related CSS hacks aside).

Ah, and pull random people from somewhere and have them test your sites. Don't help them navigate it; they'll let you know if it absolutely sucks or not. :)

Okay, well nothing is always that obvious I suppose. While I agree completely that "standard" ASCII is generally used to mean the 7-bit binary values 0-127 and their graphic representations, today's programmers and most systems--whether right or wrong--understand what is meant by the terms 8-bit ASCII and extended-ASCII (in that the values are full eight-bit with special characters in the 128-255 range); for example, this link. I started computers when we didn't have extended sets and made "special" characters with "escape sequences" so standardized extended sets and/or unicode would have been welcomed. As more and more systems use unicode for extended character sets and foreign languages, the whole ASCII issue may someday disappear (along with all that "great" ASCII art). Back to someone's original comment, it's pretty easy to display a mu on most people's computer screens (though not necessarily in /. posts) through the ISO Latin-1 set (a superset to "standard ASCII").

http://maypole.perl.org/

FYI: to create a link you need to use an Anchor tag, the spec for the Anchor is here.

But here is a brief example of a "link", "hyperlink"

<a href="http://maypole.perl.org/">Maypole</a>

I used your site in the example but you could replace http://maypole.perl.org/ with any URL from the internet, and Maypole could be any text

Link text should be meaningful enough to make sense when read out of context -- either on its own or as part of a sequence of links. Link text should also be terse. For example, in HTML, write "Information about version 4.3" instead of "click here". In addition to clear link text, content developers may further clarify the target of a link with an informative link title (e.g., in HTML, the "title" attribute).

there's an HTML way to do it. Tada, the <acronym> tag.

Well... if you want to get into pdeantic details... the <abbr> tag is probably to be favored. The W3C spec spells out the difference down in section 9.2.1. Of course, finding out which versions of which browsers support which tags is another problem altogether.

BTW, I find the WDG's guides to be more technically accurate and helpful. Much of that could be due to their documentation being machine generated from the official DTD's and such.

This is indeed a problem - caused by stupid clueless web designer-monkeys, basically.

But because it's so annoying to so many people who have a clue about graphics, as a workaround, the CSS spec actually says that on hi-res displays, web browsers should interpret "web pixels" as being at a natural size independent of the "physical pixels" (and I note some graphics file formats like png also include space to specify what natural size a pixel from the particular file is supposed to be, which most browsers also happily ignore...d'oh!) - so it sounds like Opera is doing the Right Thing and other browsers Lose.

This doesn't quite matter yet except for us lucky so-and-sos with 1600x1200 monitors, but it will matter when resolutions get even higher.

For the site you mention:
www.titantv.com is NOT valid HTML 4
www.titantv.com is NOT valid CSS

Validation of both shows about 50 errors - some of them very serious and obviously wrong.

FireFox isn't broken, some web sites are. You should be clicking the "contact us" links on sites that render badly, and ask them to clean their act (and code) up.

Don't ditch FireFox dude... more sites will work with it as time passes.

For the site you mention:
www.titantv.com is NOT valid HTML 4
www.titantv.com is NOT valid CSS

Validation of both shows about 50 errors - some of them very serious and obviously wrong.

FireFox isn't broken, some web sites are. You should be clicking the "contact us" links on sites that render badly, and ask them to clean their act (and code) up.

Don't ditch FireFox dude... more sites will work with it as time passes.

Saying "My web page is perfect because the validator said so" is like saying "My application is perfect because I didn't get any compile-time warnings."

Valid XHTML+CSS doesn't necessarily look pretty, and pretty XHTML+CSS doesn't necessarily validate. Likewise, it's not hard to make pages that look great in Firefox but not in IE (or, for that matter, KHTML-based browsers like Safari).

Lastly, the W3C doesn't have any "standards." It has recommendations. To test all the W3C recommendation support, you would have to test your web pages with a screen reader, a printer terminal, graphical and non-graphical browsers, and so on. Validators don't do that. They also don't test style, like setting appropriate alternate text for images and so on.

A clean design? Valid HTML? Valid CSS? Useful info? No ads?

What's the catch?

A clean design? Valid HTML? Valid CSS? Useful info? No ads?

What's the catch?

• ... designed for visualizing and exploring software architecture and any other information space. SHriMP (Simple Hierarchical Multi-Perspective) is a domain-independent visualization technique designed to enhance how people browse and explore complex information spaces. Among the applications we are actively exploring is the exploration of large software programs, and the understanding of complex knowledge-bases (via the Protégé tool)."

Currently SHriMP runs both as a standalone application and, using the Creole plugin, inside Eclipse to augment its existing, extensive code browsing capabilities. There's also a plugin for Protégé, a Stanford project to build "an ontology editor and a knowledge-base editor" supporting new techologies such as OWL.

While Creole is currently Java-specific, SHriMP is a generic framework for code visualization.

The odd site that still doesn't work right
Has nothing to do with Opera.
But lazy mediocre webmasters that design only for IE.

In fact Opera has done a lot recently to "accomodate" to such shit websites.

Before if a site had nasty bugs (ie misplaced tags, unclosed tags, crap mistakes like ) - it wouldn't render period.

I don't know about now but their standards what the closest to w3C as possible.

Maybe it was a market decision that they should go the Microsoft way and allow for shitty brainless coding.

Had they kept to their firm beliefs as before, you probably would see far less sites rendering well on Opera.

Report to them which sites look bad.
Or better report to me.

I run an effective w3c vigilante group that enforces standards.
Basically we track down the webmaster and with clubs and the likes beat the crap out of him - ya know .. set an example to the community.

Hope this helps :)

The X+V spec unifies HTML & VoiceXML and is currently undergoing the W3C process for standardization.

The W3C don't have a process for standardisation. They have a process for publishing recommendations.

it's using browser sniffing to send Opera some ancient crap which doesn't work in any browser.
Bzzt Wrong. http://www.w3.org/MarkUp/2004/xhtml-faq
an HTML 4.0 compliant browser will render any HTML 1.0 compliant code just as easily, in fact the ties to legacy design implimentation lead to the need for xhtml(aka XML). Sorry AC not a relevant point in your entire post. btw the 'slashdot rendering issue' is purely cosmetic, not one single function of /. is affected, and it is already patched as another poster pointed out.

Maybe in Generation 14 it has fixed it's DOCTYPE.

Yeah all the worm guy needed was a doctype html 4.01 trans http://validator.w3.org/check?uri=http%3A%2F%2Fwww .sherwoodoregon.com%2F&charset=%28detect+automatic ally%29&doctype=HTML+4.01+Transitional

The ADDRESS element may be used by authors to supply contact information for a document or a major part of a document such as a form. This element often appears at the beginning or end of a document.

http://www.w3.org/TR/html401/struct/global.html#ed ef-ADDRESS

I've used it for years. By the way, how often do you review the html source of webpages you visit?

According to W3C, It's not even valid HTML 2.0. The least they could do is write valid code. Sheesh.