Slashdot Mirror

http://htmlhelp.com/reference/wilbur/phrase/em.html

been that way since I handcoded my first web page back at college. *wipes tear for the good ol' days*

So if I look at the pictures in the book long enough will the alt text pop up?

There's an image alt text on the comics?!?

I've been reading them to years... never noticed that. I mean in order to display that alt text I would have had to stay absolutely still for one second! Impossible!

You see I never let go of my mouse - and as its a one of those precision ones it'll pick up the pulse from my hand and remain in constant motion. And the cursor! I don't bring the cursor around where I'm looking at the page; I keep it where it belongs, at the tab bar there, and only move it away to click on things...

So I would have to be some sort of zombie with no pulse and a fearful member of the flat-screen society to having any chances of ever coming close to revealing the comments on those alt tags. And what are the chances for that, Randall !

-

Sin-celery, Yellow-fruit-ordering-of-parts.

PS: Now I have to go read all of them again! (head esplodes!)

http://htmlhelp.com/reference/html40/special/object.html + mplayer's firefox plugin. OMG I Just SOLVED ALL OF HTML5's Video problems.

I'm not sure how you missed the point so spectacularly.

Not only is there CSS to do the things people used tables, for, but table has always been an abuse of the semantic intent of that HTML document tag, muddying it and confusing parsers. Yes, HTML could use more tags, but tables are hardly necessary.

And setting aside the semantics, people who actually have to restyle your table layout later (when rewriting the site is not an option) will have every reason to curse you.

The decoupling of the layout CSS offers is a powerful tool.

And, no, web pages are not, and have never been intended to be, mapped to application UIs. Is nice that they can, but that's a very limited case, and not even the main use of web pages.

"Explore the intricacies of HTML and CSS here: http://www.htmlhelp.com/ , http://css-discuss.incutio.com/ , http://www.brainjar.com/ , http://www.htmldog.com/ , http://css.maxdesign.com.au/"
-- ZofBot db

The parser eats opening angle braces as it's assuming they're for HTML tags. Use the HTML special entities.

&lt; gives you < and &gt; gives you >

quick reference available here.

Look at this set of pictures:

http://htmlhelp.com/~liam/Hawaii/Kauai/WaimeaCanyon/

Would you know simply by looking at the photos without the sign that this was not say the grand canyon? The whole correct to 200 km aspect is troublesome when the state of the art in computer vision cannot yet even answer that this is a picture of a canyon.

Your boss is basically telling these potential customers to fuck off and take their money elsewhere. No one wins an argument with a customer. It's not a new concept.

A nice simple online guide reference would be nice if any one knows one.

I used this site a lot when I was first learning my html skillz. Be warned, /. allows a very limited subset of html in comments, so you don't have to learn too much to get around here.

Oh, and welcome from a fellow Canadian!

(how do you make a freakin' arrow in a comment?)

By using HTML entities,

"&lt;--" <-- like this

or like this --> "--&gt;"

By the way, you can escape the "&" itself by writing "&amp;", and here's a list of the rest.

Reposted from something I wrote a while ago

You cannot prove anything about the future... but you can identify trends.

Before Netscape 1.2 came out, it was a common, non-standard hack to use multiple title and body elements to get crude animation. Netscape 1.2 came out, and screwed these pages up. Following standards ensured forwards compatibility with Netscape 1.2.

Before Netscape 2.0 came out, missing quotes on the end of an attribute were detected as errors by Netscape 1.x and compensated for. Netscape 2.0 came out; it did not. Large sections of pages disappeared. Following standards ensured forwards compatibility with Netscape 2.0.

Before Netscape 3.0 came out, people were careless with their ampersands, failing to correctly encode them in URLs, for example. These were detected as errors by the current browsers, and compensated for. Netscape 3.0 came out; it did not. Lots of broken links everywhere. Following standards ensured forwards compatibility with Netscape 3.0.

Before Netscape 4.0 came out, people were still careless with character entities, omitting the trailing semicolon (I believe this was a property of many graphical editors, such as Frontpage). This was detected by the current browsers, and compensated for. Netscape 4.0 came out; it did not. Following standards ensured forwards compatibility with Netscape 4.0.

Before Netscape 6.0 came out, people used a variety of non-standard Javascript techniques and layer elements, detecting Internet Explorer, and serving them alternative code. Netscape 6.0 came out, it didn't support the proprietary Netscape-isms of previous releases. Following standards ensured forwards compatibility with Netscape 6.0.

More recent problems include stylesheets served with an incorrect content-type header, and table-layout images being broken up with lots of little gaps.

This list only includes Netscape behaviour, as that is the only list I have to hand. (Thanks to this article). I'm sure similar things apply to other browsers.

There is plenty of evidence that sticking with standard code results in forwards compatibility.

There are really only two important properties of future browsers:

• They are likely to support at least as much of the specifications as the current version
• Nobody can test in them

Thus, my overwhelming desire is to simply treat future browsers as I would any other browser I couldn't test in: code to standards, and when I get a chance to test, fix up what is necessary.

There are very few good reasons these days to write invalid code. Mostly it's just ignorance and apathy that causes people to write invalid code.

The 'u' in utorrent is the greek small letter mu and is pronounced "mew" or "myoo".
SI uses the symbol to represent the prefix micro.

http://en.wikipedia.org/wiki/Mu

Anyways, apparently the author pronounces it "you"-torrent. I personally prefer mu torrent.

Use the A html tag.

Pounds, on the other hand, is a unit of force not mass - even though it's often confused as one.

Of course, leave it to the nutty civil and mechanical engineers to have it both ways. They have two units: lbm and lbf. Pound mass and pound force, respectively. 1 lbm = 1 lbf * 32.2 ft/sec/sec. UGH! (We rounded the 32.16 up to 32.2 for our computations. Kinda like rounding to 9.8m/sec^2 in metric.)

When I took Statics and Dynamics, I can't tell you how frustrated I got with pound mass vs. pound force, and how often I'd have an extra or missing 32.2 pop into our out of somewhere. More than once I'd convert everything into metric for a problem to verify my answer.

In that same course, the prof was very particular about whether you used lb*ft or ft*lb as your units for an answer--one was for torque and the other was for work. It gets nuttier: Inside the cover of our textbook, in the conversion table, there was an entry for "1 lb*ft = 1 ft*lb." I kid you not.

--Joe (A nutty EE.)

PS. Am I the only one that finds it frustrating that Slashdot won't let you use most HTML entities? Math posts are so ugly as a result. I tried using &middot; and &sup2; in the above and it didn't work. Fortunately &amp; works...

Yup, that and http://htmlhelp.com.

Sorry about that. MSN's extremely long lines led to a Perl segfault for which I just added a workaround.

The earlier MSN validation link works better now.

--
Liam, developer of the WDG HTML Validator

Sorry about that. MSN's extremely long lines led to a Perl segfault for which I just added a workaround.

The earlier MSN validation link works better now.

--
Liam, developer of the WDG HTML Validator

...He points out their invalid webpages...

It looks like MSN's markup is more valid then Slashdot's is.

...He points out their invalid webpages...

It looks like MSN's markup is more valid then Slashdot's is.

Internet explorer will still display the alt

unless they fixed that in modern versions

Internet explorer will still display the alt

unless they fixed that in modern versions

Read up on selectors (short guide, quick read). What you're doing could be rewritten as "a.blue, span.blue, div#back { color: blue; }" as one commenter said, but more importantly, you should be naming things semantically, as another commenter hinted at. Which is to say, "blue" is a terrible class name, while "important" or "author" or "definition" or whatever are good ones, because they mean something. Your stylesheets will be a lot easier to understand if they are filled with gems like ".definition { color: blue; }".

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.

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.

Most of the beaches around here aren't very wide... maybe 50-100 yards on average. (Bigger here, smaller there.) They also aren't very crowded at all... don't really need to fear crowds getting bottlenecked at escape points.

Speaking of which, no bridges or anything like that. Beaches aren't really developed at all. You might have to run up a sand berm (full of dune grass), dirt trail, or clamber over some rocks to save time (instead of heading for a regular path)... but most places it's easy to get on/off of the beach itself.

At any of the beaches I frequent, You also gain elevation pretty quickly. Once you hit the edge of the beach, you are going up... could gain 30-50 feet in less than a minute. In some places 100 or more, if you can hack it.

In other words... you'd have to run for it, but you MIGHT just stand a chance, depending on where you are and how big it is. A 30-50 footer might get you wet, but given a minute or two you have a chance at getting to someplace where it might not kill you. Anyone know how long you get once that water starts heading out? ;)

Everywhere else I go you don't need to run... you're already looking down at the ocean from a few hundred feet above it. :)

Here are some examples of our beaches:
http://www.picturesof.net/_wallpaper/brookings_gb_ coast_87n_WP.jpg
http://www.geomembrane.com/040227%20Oregon%20Coast %20029.jpg
http://www.rawdonsbar.com/charliegallery/images/no rthwest/nw-oregon%20coast.jpg
http://www.htmlhelp.com/~liam/Oregon/Coast/Newport /beach1.jpg

Here are some pics of my favorite beaches... Sunset & Simpson Coves. (Collectively referred to as Shore Acres.) Most of the shots don't show the beaches themselves... you mostly see just the cliffs around them. (You've gotta hike some unmarked trails to get to where some of these shots were taken). But one is looking back at Sunset Cove from a tidepool area off to one side. (Note, I took none of these. Just found 'em at google. Apparently a few photographers know my spots!)

http://www.naosmm.org/confer/port-or/gifs/jackpics 2/12.jpg
http://www.naosmm.org/confer/port-or/gifs/jackpics 2/29.jpg
http://www.jobo-usa.com/gallery/images/surf_at_sho re_acres_high.jpg
http://www.hackstadt.com/adv/1998/195b-shore-acres .jpg

Some more good ones here:
http://www.coos-bay.net/coastalphotographs.html

Here's a suggestion that you might find livable, and IIRC, iCab incorporates this into its bookmark engine...

Institute a bookmark checker (like the WDG's Link Valet) and when a bookmark comes back 404, flip a metadata status flag to "broken," and notify the user. Make it extra-smart and have it follow auto-redirects and set a metadata flag to "redirected" and fill in a field "redirected URL" and then prompt the user to set this URL as a new URL for that bookmark.

As I said, iCab does the former (at least somewhat), though the latter half is wishful thinking right now. :)

p

Because they seem to be blocking the W3C validator. Try The WDG validator instead.

Thanks for the info - I'm sure changing slashcode to emit anything else at all will be a big chunk of work, and that's fair enough! No gripes about that, but it'll be great when XHTML happens.

You really don't emit HTML 3.2 though - more like a a bastardized form of it. It fails horribly with the 3.2 validator here. And blocking the W3C Validator is a bit of a giveaway too, surely?

This is going to be the hardest part. Even decent commercial web apps (i.e. Novel WebAccess) are horribly coded, taking advantages of features that are either proprietary or bugs in IE.

If you run them through an HTML validator they almost always have ridiclous and basic errors. mail.optonline.net is horrible, most of the buttons do not work because of javascript errors.

Luckily Mozilla handles a lot of these errors gracefully and Firefox is getting better. But like you said, it comes down to the webmasters and web application (commercial) developers getting on board and writing proper HTML & javascript.

No, it's part of Slashdot's shitty web design. It's so embarrassing that they've apparently taken to forbidding the w3c validator from checking it.

If Slashdot had a modern XHTML + CSS layout, everything would resize correctly as you increased and decreased the font size.

In fact, a bunch of web designers even created a standards-compliant version of the Slashdot UI, but the editors are either too lazy to implement it or don't care about how ugly the site looks.

Try posting as HTML and using the standard HTML &euro; entity, which renders like this: € (If that doesn't work, then it's your browser's fault.)

Here's a link to some other HTML 4.0 Entities.

Perhaps it's slashdot that needs to be made standards compliant! It would seem that someone doesn't want us to know how compliant it is.

It seems WDG had better luck getting through, but look at all those errors!

The CSS guide is good, and the JavaScript FAQ is VERY comprehensive.

w3schools.com is hardly the be-all end-all authority on HTML semantics. In fact, I'd say that a website that (as of 2004-01-09) uses tables for layout and <b> for navigation bar heading text wouldn't know what "semantic web" meant if it reared up and bit them in the you-know-where. (Go ahead, view the source.) The disclaimer on their homepage states, "W3Schools is for training only. We do not warrant the correctness of the content. The risk of using it remains entirely with the user." I'd listen to their disclaimer (and homepage joke-of-the-day) much more than their markup advice.

Come on: A random link does not an argument make. I've seen horrible HTML tutorials "explain" how <blockquote> is used to indent text and <h1>, <h2>, et al are good for making text bigger and smaller. If "somebody wrote it on the Internet" links constitute an argument, though, I'd say that Web Design Group offers a much more reliable and better-thought explanation of <abbr> and <acronym>.

Also, note that the W3's homepage itself uses <abbr> and <acronym> as I described, with the incomprehensible exception of their copyright-footer link to the name of the W3 itself. Their entire homepage navbar marks up abbreviations such as "HTML", "CSS", and "XMLP" using <abbr> while reserving <acronym> for pronounceable formulations such as "SMIL" and "SOAP". (Again: View the source.) I'd say that if any page has been extensively tested using a diverse spectrum of user-agents (including aural browsers and experimental semantic web applications), the W3's homepage is probably the benchmark to be exceeded.

As for the formal specs and other documentation (which really ought to be referenced here), I'm way too lazy to dig through them for a random /. argument. But that's ok, since another poster already took a decent crack at it. :-)

But the central issue remains: Assuming that <abbr> and <acronym> are to be used as you say, they're semantically indistinguishable and therefore redundant. I say that each has its own correct discrete usage. <acronym> is for acronyms, which are pronounceable by definition and often words in and of themselves (e.g., Web Design Group's example of "radar"). <abbr> is for other abbreviations, including unpronounceable initialisms, which cannot be pronounced or used as whole words in their own right. This is an important practical distinction for Web robots and aural browsers.

HTH.

w3schools.com is hardly the be-all end-all authority on HTML semantics. In fact, I'd say that a website that (as of 2004-01-09) uses tables for layout and <b> for navigation bar heading text wouldn't know what "semantic web" meant if it reared up and bit them in the you-know-where. (Go ahead, view the source.) The disclaimer on their homepage states, "W3Schools is for training only. We do not warrant the correctness of the content. The risk of using it remains entirely with the user." I'd listen to their disclaimer (and homepage joke-of-the-day) much more than their markup advice.

Come on: A random link does not an argument make. I've seen horrible HTML tutorials "explain" how <blockquote> is used to indent text and <h1>, <h2>, et al are good for making text bigger and smaller. If "somebody wrote it on the Internet" links constitute an argument, though, I'd say that Web Design Group offers a much more reliable and better-thought explanation of <abbr> and <acronym>.

Also, note that the W3's homepage itself uses <abbr> and <acronym> as I described, with the incomprehensible exception of their copyright-footer link to the name of the W3 itself. Their entire homepage navbar marks up abbreviations such as "HTML", "CSS", and "XMLP" using <abbr> while reserving <acronym> for pronounceable formulations such as "SMIL" and "SOAP". (Again: View the source.) I'd say that if any page has been extensively tested using a diverse spectrum of user-agents (including aural browsers and experimental semantic web applications), the W3's homepage is probably the benchmark to be exceeded.

As for the formal specs and other documentation (which really ought to be referenced here), I'm way too lazy to dig through them for a random /. argument. But that's ok, since another poster already took a decent crack at it. :-)

But the central issue remains: Assuming that <abbr> and <acronym> are to be used as you say, they're semantically indistinguishable and therefore redundant. I say that each has its own correct discrete usage. <acronym> is for acronyms, which are pronounceable by definition and often words in and of themselves (e.g., Web Design Group's example of "radar"). <abbr> is for other abbreviations, including unpronounceable initialisms, which cannot be pronounced or used as whole words in their own right. This is an important practical distinction for Web robots and aural browsers.

HTH.

nice, and here's the same but with the new layout.

Actually, they have been complying with HTML standards, just the old version 3.2.

That's not true.

I recently used HTML Tidy to convert my website from html to xhtml. It works well. After Tidy, I used WDG HTML Validator to verify that the code was correct. (It validates XHTML as well.) If you install your own version of the validator you can more easily check your entire website. This is important if you have a lot of pages.

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.

You may wish to avoid fixing the size of layout elements too. One way to do this is to define element widths, heights and positions in ems. An em is a standard typographical measurement defined as the width of an "m" character. In CSS an em is the width of an "m" in an element's font.

I usually use both px and em when laying out a web page. I use px to position elements accurately and I use em to define spacing that relates to text. For example, I would use ems to set paragraph spacing and padding around text. This keeps things looking nice at a variety of different text sizes.

Neither one validates.

But then again, neither do any of the other candidates' web sites (I tested Edwards, Kerry, Gephardt, Kucinich, and Sharpton).

The letter 'thorn', which looks like a deformed 'p' was pronounced 'th'. In HTML you can get it by using & thorn; or & #254; in the code (but not in Slashdot comments). As it fell out of use, it was sometimes replaced by a 'y' hence 'Ye Olde Shoppe' on signs.

If you try a different validator site, you find there are over a hundred errors on the front page.

Have you really looked at and understood the errors it found? Most cascade from putting TABLE inside FONT and serving a page as HTML 3.2 while using 4.x options. If you inserted FONT after BODY in practically any page you'd get a ton of errors too, even though they arise from a single mistake.

And I was shocked that that validator failed to recognize that the SCRIPT tag contains CDATA markup and tried to interpret "<a " as an anchor inside the SCRIPT when the SCRIPT hadn't been terminated by a sequence of "</" followed by an alphabetic character. The use of <!-- HTML comments --> around script contents isn't required for compliance.

And lastly, you can't expect full compliance at all times from a page that sources HTML from elsewhere, such as advertisements which require ads be run without any modification to the markup provided, or contain other content that hasn't been vetted for compliance like story submissions.

Yes, look at Slashdot. The geek site that is so ashamed of it's HTML, it blocks the validator.

If you try a different validator site, you find there are over a hundred errors on the front page.

Lead by example?

if (mode == "dev") {
print "<a href=\"$WEB_DEV_SERVER/validator/validator.pl?url= referrer\">Validate this page</a>";
}

Try this validator then. Doesn't validate, of course.

The page is valid XHTML. If IE can't render it, that's its problem. Most of the IE-only pages are not standards-compliant, and that's the problem.

Look at the Prius. Look at the Insight. Both are HORRIBLY UGLY CARS.

I find my Insight to be very attractive. On multiple occasions, I've had someone shout "Sweet car!" as I drove by. When stopped at a traffic light, people will honk to get me to wind down the window so they can ask about my car.

The Insight certainly looks different from other cars. I consider that a good thing.

Also, oh ye of special talents you will note that another other validator has no problem with www.slashdot.org or just slashdot.org while the w3c's keeps returning forbidden. Funny that don't ya think?

Also, oh ye of special talents you will note that another other validator has no problem with www.slashdot.org or just slashdot.org while the w3c's keeps returning forbidden. Funny that don't ya think?