Slashdot Mirror

The Libwww Line Mode Browser

There are some questions that really affect which direction you should go. Where is the content coming from? Is it all locally produced? Is it produced live-to-tape, or is there a lot of postproduction?

You may be interested in A $300 video server tivo-based hack, which is kinda cool.

Anyway - For in and out, you could consider ASI-based transport. An advantage of using DVB-ASI out from your server is that you can easily transition to digital transmission when the time comes. The physical characteristics are similar to SDI, ie a 270mbs signal, but you're dealing with MPEG2 transport streams. You could have multiple program streams if you want. The idea here is that you can use external encoder/decoder boxes that go between audio/video (analog or SDI) and ASI (compressed domain). All you need to do is splice the files at I-frames and stream them out to the device. Hardware's pretty cheap - have had good experience with the cards from DVEO/Computer Modules. Cheap and stable, and they come with linux drivers. You'll need to write some code to make it all work, though. And external encoders/decoders aren't the cheapest thing, but they should be cheaper than most video servers

There are also ASI/MPEG stream splicers to look at - from companies like Leitch/Harris, Thales, and EVS. But you've noted they're a bit expensive.

SDI-based playout is going to be rather expensive no matter how you go. Offloading this work to an external decoder is pretty cost effective. You can also use IP as a transport instead of ASI, to an external decoder, but ASI is a bit simpler and more reliable.

In college, I wrote an automated air playout system on a mac - had a mysql db for asset management and scheduling. This was synced every so often to the website db. Had a pretty simple set of perl scripts (which included calling applescript from the command line via osascript) that handled playing to air. (used quicktime player, actually, with great success). Created blocks of clips using SMIL, which you should check out. Was able to key bugs/logos/time/temp info, too.

Between scheduled programs we cut to an Apple Keynote presentation, started and stopped by the same scripts [using applescript]. The actual presentation was auto-generated during the programming by another perl script, from another database. (Including events from a central campus events database, updated weather forecast, program schedule db for coming up next/later, advertisements/PSAs [another db with this info], and video interstitials)...

Now that was a fun project. But quite a mess at the same time.

Lemme guess, his next book will be "Why Websites Suck"

http://validator.w3.org/check?uri=http%3A%2F%2Fwww .suckbusters.com%2F

Have you any idea how much that'd break?

Yes, nothing that isn't broken already.

Nevermind all the sites using Javascript menus and the like that'd stop functioning, goodbye anything that resembles AJAX (guess what the J stands for).

Only if I win a prize, because off-hand I can't think of anything beginning with the letter 'j' that means 'hype'.

Forget all the cool things you can do manipulating the DOM tree, it's back to web pages that have to reload the whole page every time someone clicks a button so you wnat to change the UI. It's like "securing" online banking by going back to paper and phone. As annoying as Javascript is, I don't want to have to use a Java applet / flash plug-in / whatever for everything.

Ajax is frames done in javascript and the speed increases are true in rare cases but a myth in others. Use HTTP headers to force caching of all your static content and gzip your full page content. Static page elements can be fragment cached server side, you assemble a page from cached fragments and a single dynamic element, gzip and and send it to the client.

Ideally we would use deflate for stream compression because there is less overhead than gzip's headers but browser support is spotty. There's around 11 bytes overhead for gzip and not generally a reduction until 100 bytes. Allow around 150-200 bytes for HTTP headers and with typical MTU that leaves well over 1k before you even exceed a single packet. Gzips delta compression hits around 50% for markup at over 3k or about 2 packets and ramps up the compression from there with average sizes levelling off around 33% (sometimes better).

So using javascript like you describe is not just bad for assessibility but sending smaller chunks can actually be a false economy bandwidth-wise. Obviously every case (if not request) is unique but if the overhead of static page elements is a problem, it may be time for a usability audit. Speed wise on the client, if using javascript & the DOM is as fast as uncompressing data and applying a cached stylesheet, you need to file a bug report with your browser vendor.

In English "correctly coded" means the same thing as "conforms to my own idiosyncratic fetishes"?

You might want to lose the omniscience complex.

It's just possible that the user knows best, so I'll stop popping windows all over a users screen and overriding their browsers navigational functionality. Thank you for the suggestion.

Have fun with Lynx.

Hey that's mean because phishing, XSS, CSRF and malware can be lots of fun too.

see the section "11. About Color Tables." in http://www.w3.org/Graphics/GIF/spec-gif89a.txt

It clearly allows local palletes for the images (frames in animated gif speak) rendered to the logical screen.

and section "8. The Decoder." clearly states that a decoder should render without delays other than those specified (unfortunately most browsers seem to ignore this part of the spec and insert a minimum delay).

so loophole or not such images ARE compliant with the spec, thier existance is more a curiosity than a practical feature though.

but the implementations should get better, much better (think Flash-like performance and possibilities; it's all in the standard)

I think Opera is way ahead of the Mozilla folks on the SVG implementation. That being said, I understand Firefox 2.x will implement SVG 1.1 stuff, like scripting. How well will it implement the new features? Pretty poorly at first, I'm sure. My needs are for basic multimedia implementations, like getting SVG to animate and sync with an audio file. Which is why I'm particularly interested in:

SMIL: http://www.w3.org/AudioVideo/ Internet Explorer and RealPlayer implement some or all of the current SMIL specs, Firefox hasn't even heard of it, Opera is said to be a bit buggy. I'm hoping this catches on in a big way, but I'm not holding my breath.

Oh, and Flash can be very buggy on Linux. A real estate broker client of mine had his company Website done. It was done almost completely in Flash...barely 6 lines of HTML on the entire site (of course I'm being hyperbolic but not by much). Renders swell on Windows, but for me the entire right half of his property description page just simply disappears. Mid-word, mid-photo. Very strange. I'm guessing a white rectangle is getting rendered above where it should be (wrong Z-index in HTML terms...I don't do Flash so I don't know Flash's terminology). He was livid when I showed him what his Website looked like on my monitor, and Adobe doesn't seem to be in a big hurry to update the Flash plugins for Linux.

One thing I do like about using a scripting language to animate DOM objects in HTML (the current SVG way) is that your "bounding box" can be larger than the browser's display window. Meaning that you can have objects move into the display from off-screen (done this in the past on a development site; will be doing this on a redesign of my company's site). Perhaps you can do this with Flash as well, but I've never seen it. Flash almost always gives me the feeling of looking through a small porthole that appears as a very obvious child window of the browser's parent; manipulating DOM objects via a scripting language means the entire browser window (and beyond) is my canvas to play with and there's no "porthole" effect. I like that.

* * * * *

An advertising agency is 85 percent confusion and 15 percent commission.
—Fred Allen

VML is a standard from almost a decade ago.

It isn't a standard, it was a submission to the W3C for consideration, by Microsoft and some of its useful idiots (HP, Macromedia, Autodesk, Visio). Submissions don't automagically get the thumbs up from the W3C. According to Wikipedia, Adobe, Sun and others submitted a proposal for a competing technology called PGML. Best features of the two technologies were then merged and improved upon to produce:

SVG: http://www.w3.org/TR/SVG10/

SVG became a W3C recommendation on September 4, 2001. Later versions of Opera, Firefox and some other browsers implement at least limited support for SVG. It's also a standard vector graphics creation/exchange format for many open source graphic apps like Inkscape and Scribus. Adobe Illustrator and CorelDraw also support SVG fairly capably. Guess whose browser pointedly doesn't support SVG?

http://en.wikipedia.org/wiki/Vector_Markup_Languag e Check out the code samples. The SVG code is quite a bit more compact than its VML equivalent.

Folks on SVG-rendering browsers (Firefox 1.5.x, Opera 8 and above) will possibly enjoy this little demonstration: http://isthis4real.com/orbit.xml

* * * * *

It's a small world, but I wouldn't want to have to paint it.
—Stephen Wright

I had no idea what VML was, so I did a little digging and found the following links.

W3C's introduction to VML: http://www.w3.org/TR/NOTE-VML

Microsoft's brief introduction to VML: http://msdn.microsoft.com/workshop/author/vml/defa ult.asp

Interestingly, the MS page includes a demo "oval with red background" which doesn't work in my Firefox browser.

Yes. Slashcode is a horrible mess of Perl that never created standards-compliant HTML. After a lot of refactoring, it now generates valid HTML 4.01 Strict, but this took a lot of work by the developers. Getting it to work nicely on other devices is probably the next step.

When a new TLD is created because of a style issue: the web is broken. This approach of splitting mobile content from "normal" content is the wrong way to do this. CSS has media types and a media type of "handheld" FOR EXACTLY THIS PURPOSE!

The only benefit to .mobi is to be cash cow for the registrar. That's it. A properly design site should take advantage of the already existing method for handling this very situation. The website should change to me, not the other way around.

Since when did Web 2.0 = forgetting all about usability and going with 'it looks minimal, so therefore cool'

I wanted to use a modern, CSS-based liquid layout. So I bought a book, and dove in.

There's your first problem. No book is going to give you all of the latest techniques for doing "cool" things with CSS. For that you need to poke around online at places like CSS Zen Garden, A List Apart, Liquid Designs, etc. If you must buy a book, a pocket reference is the best way to go (and even that really isn't necessary, since you can find good references online).

It seems like CSS does OK for fixed layouts but if you want to have a 200 pixel left sidebar and leave the rest of the page for content, I just can't figure out how to do it and have it look as nice as a simple table-driven layout.

Odd, I've done exactly that using a non-table layout, and I certainly didn't invent the technique. It's not purely semantic, as you end up with a couple extra divs to get your layout right, but it's a damn sight closer than table layouts. In fact, your example is actually quite trivial, compared to something like a three-column layout with bounding fixed-size sidebars around a liquid middle (there's a reason that's called the Holy Grail of CSS-based design).

Worse, after playing around with it I could not see where the advantages were over tables. Tables work, they don't take long to code up, and I feel I understand them completely with minimal effort. It seems like with a CSS layout, you waste a lot of time fighting bizarre browser compatibilty issues, while if you use tables, they "just work", far as I can tell -- and I've tested in IE, Safari, FireFox and a few others.

Oddly enough, movietally's table-based layout for its rounded-corner "Discover" box is broken on IE7 (the corners don't line up correctly). So much for "tables work". I'll grant you that CSS-based layouts can run into some funky cross-browser issues, but 9 times out of 10 the problem is not with the layout but with the designer who demands pixel-perfect magazine-like layouts in a medium that was never meant to do that (if you want that, build a PDF). If you get over your obsession for having everything lining up just so and instead focus on making the page accessible and understandable while still looking good, you'll find that CSS is often a lot easier and nicer to work with than table layouts. Besides, it makes it quite a bit easier to give your page a makeover to keep it fresh without having to recode everything (CSS Zen Garden is the prime example, but look at what Slashdot did with the recent site skinning contest -- that was limited to only CSS manipulation, which would've been impossible had Slashdot stuck with its outdated table-based design).

Nobody's saying that tables aren't useful. We're just saying that they should be used semantically. If you have some tabular data you want to display (say, a calendar), knock yourself out with tabley goodness.

HO LY SHIT !!!! that is easily the worst thing I have seen online (with the vague possiblility of a few, very select myspace profiles). What I find extra amusing is that their "why use IE" site doesn't even render quite correctly in IE (well, not IE7, the only version I have installed anywhere). Of course, given that FrontPage produces code more standards-compliant than is used in their source, I'm amazed it renders as well as it does... (*only* 411 errors and an invalid doctype). Their explanation of why you really need to reset your screen resolution to 800x600 is almost as bad, by the way; you might think a web programmer would know how to have multiple stylessheets and select the apropriate one using javascript, but hey, why not break further that which is already broken. Oh, and the way your ppoup blocker pings you as the site opens? You're prventing their RealAudio streaming pages from opening. Leaving aside the issue of their decision to use Real, are they honestly implying that the decision to use popups is better than an invisible frame that doesn't change on every link click (their justification for not using a stream in the main page) a la AJAX? Sometimes people truly terrify me. I'm tempted to take a screenshot of their site in a Linux system without Windows fonts, using 800x600 on a natively 1440x900 widescreen LCD, using IE4 installed in Wine... Nah, it's not worth it if I don't get to see their faces. (On a side note, though, I could pretty easily send them one of the site in Konqueror, sans Flash, at my native resolution... it'd be worth creating a throwaway email address for.)

The w3c Slidy package, from the folks who brought you "tidy", is also excellent.

A colleague here at the World Wide Web Consortium (Dave Raggett) wrote a JavaScript-based tool called Slidy to do presentations; it degrades to plain HTML without JavaScript/ECMAScript support. Changing the style involves putting some CSS in your HTML file, but it's fairly clearly documented. Most of us use it for our talks now.

If you put the talk up on the Web before the conference, you aren't tied to using your own laptop to present, which can be useful if you're sufficiently prepared. I rarely am, since I like to tailor a talk to the audience.

Liam

Well, first thing I did was run their page through http://validator.w3.org/ It came back with nine validation errors, and their code is pretty ugly. So I don't think I'll bother pursuing it any further.

It's not that it's not quite there yet. Native browser support for SVG is non-existing. However, you can download plug-ins to view SVG. And being a W3C Recommendation, Netscape and IE are promising future browser support for SVG, and with browser support, the plug-in will eventually be phased out. The main problem with SVG for the moment is that hardly anyone uses it.

One sweet duo is SVG + Ajax, that can vastly improve the interface with the end-user, without eating up a lot of bandwidth and most importantly, can be easily implemented so that the browser gracefully presents an downgraded version of the page if one is not supported...

Give it all to the ones that can handle it, but degrade gracefully if one cannot handle it all. That is (or should be) the future of the web.

You really need to read the article before you go off on such a rant. Nowehere in the courts, in the ADA, or in my earlier posting has anyone suggested that the entire visual universe should be somehow translated into sound, or that the entire aural universe should be translated into sight.

It's only a slight exaggeration of the W3C's WCAG 1.0, section 14, which requires audio or captioned alternatives for any multimedia content. Images probably don't count as multimedia, but I could see some braindead lawyer arguing that they do.

It is possible to address more than one act of discrimination at a time in a country our size.

There's a balance. If we covered all the streets with nerf foam, it might be safe for blind people to drive. That doesn't mean we should do it, because it would be ridiculously expensive. Similarly, expecting every last website out there that sells something to be accessible is nuts. A lot of State of California websites aren't accessible--if the state doesn't follow its own laws, why should anyone else have to?

Ignoring the fact that this case has essentially nothing to do with your wife's web site unless she runs a physical store as well

Not true--read up on the case. Any online website in the US that sells stuff is subject to the ruling.

why isn't it possible to test yourself?

If I wanted to test whether the site works in screen readers like JAWS, I'd have to buy one, and they're damn expensive. I already explained that.

You made a web site and it works, making it accessible is no more difficult. Go to the W3C and follow their guidelines. Cost is $0, they have dozens of free tools in multiple languages for evaluating accessibility and lists of issues to look out.

You clearly haven't spent much time looking at the guidelines. section 10. 3 tells you to test your site with self-voicing browsers, screen readers, etc. Screen readers are expensive, which means the cost for doing this is going to run pretty damn high for a small business. You also haven't addressed my original point, which is that the probability of a visually-impaired person wanting to buy visual art is about zero, making all of this an exercise in futility.

If the essential information is available in Lynx, you're peachy, though going beyond the minimum will result in a more compatible site overall that is easier to update.

Lynx is a good start, but it's no guarantee that your site will work the same in a screen reader. The screen readers have known bugs, and it's not at all clear from the ruling whether it's enough to design to the first parts of WCAG, or whether you also have to test with screen readers.

Considering this only deals with information about physical stores on the website, yeah, I think it's a great idea. Adding three lines of text to your website is far less onerous than building wheelchair ramps and wider doorways, and stores deal with those requirements.

No, the suit also concerns the fact that blind people can't complete a transaction on target.com, as it requires mouse clicks in specific places. The information about physical stores is just part of the complaint.

You really need to read the article before you go off on such a rant. Nowehere in the courts, in the ADA, or in my earlier posting has anyone suggested that the entire visual universe should be somehow translated into sound, or that the entire aural universe should be translated into sight.

It's only a slight exaggeration of the W3C's WCAG 1.0, section 14, which requires audio or captioned alternatives for any multimedia content. Images probably don't count as multimedia, but I could see some braindead lawyer arguing that they do.

It is possible to address more than one act of discrimination at a time in a country our size.

There's a balance. If we covered all the streets with nerf foam, it might be safe for blind people to drive. That doesn't mean we should do it, because it would be ridiculously expensive. Similarly, expecting every last website out there that sells something to be accessible is nuts. A lot of State of California websites aren't accessible--if the state doesn't follow its own laws, why should anyone else have to?

Ignoring the fact that this case has essentially nothing to do with your wife's web site unless she runs a physical store as well

Not true--read up on the case. Any online website in the US that sells stuff is subject to the ruling.

why isn't it possible to test yourself?

If I wanted to test whether the site works in screen readers like JAWS, I'd have to buy one, and they're damn expensive. I already explained that.

You made a web site and it works, making it accessible is no more difficult. Go to the W3C and follow their guidelines. Cost is $0, they have dozens of free tools in multiple languages for evaluating accessibility and lists of issues to look out.

You clearly haven't spent much time looking at the guidelines. section 10. 3 tells you to test your site with self-voicing browsers, screen readers, etc. Screen readers are expensive, which means the cost for doing this is going to run pretty damn high for a small business. You also haven't addressed my original point, which is that the probability of a visually-impaired person wanting to buy visual art is about zero, making all of this an exercise in futility.

If the essential information is available in Lynx, you're peachy, though going beyond the minimum will result in a more compatible site overall that is easier to update.

Lynx is a good start, but it's no guarantee that your site will work the same in a screen reader. The screen readers have known bugs, and it's not at all clear from the ruling whether it's enough to design to the first parts of WCAG, or whether you also have to test with screen readers.

Considering this only deals with information about physical stores on the website, yeah, I think it's a great idea. Adding three lines of text to your website is far less onerous than building wheelchair ramps and wider doorways, and stores deal with those requirements.

No, the suit also concerns the fact that blind people can't complete a transaction on target.com, as it requires mouse clicks in specific places. The information about physical stores is just part of the complaint.

I have to disagree. A good friend of my wife's is disabled, and knows what real discrimination is like.

What if the site is inaccessible from Mac browsers? Can I sue on the grounds that being a Mac user is a disability?

The problem is that now, because of this ruling, my wife will be faced with two options:

1) Keep running the business in potential violation of the ADA and hope she doesn't get sued.
2) Close the business because she can't afford to pay for an accessibility audit of the website.

Testing the site ourselves isn't possible.

Do you still think this ruling was a good idea, NMerriam? Should all mom-and-pop online businesses be closed down because of the ADA?

Just think of the killing some unscrupulous lawyers could make off this. Just build a webcrawler that finds "unaccessible" websites, then sue the owners. Free money!

Making a site 508 compliant is not really all that hard and it essentially consists of making sure your site validates as XHTML 1.0 (preferably 1.0 Strict) or even better, XHTML 1.1.

XHTML 1.1 cannot be served as text/html, many user agents do not and may never accept application/xhtml+xml. If you're serving XHTML 1.1, you're either violating the spec or making your site less accessible.

The only downside to writing a site to be 508 compliant is that AJAX must be used carefully.

That's not a downside, it's best practise to make a site accessible to people with script disabled and UA's that don't (and never will) use the W3C DOM (see above).

You need to know a little something about real web development but the end your site will be better, cleaner, and more easily maintainable. I've done it. It's ain't that hard.

Where do I go to learn about real web development since I'm obviously doing it wrong?

"Now here is the problem: where is the responsibility? Is it also Target's responsibilty to pay for the blind's computer access equipment? Do they have to provide them transport to and from the store, since they can't drive on their own? Does there need to be a guy with a megaphone standing on every Target billboard declaring the contents of the sign in an audible format?"

Nice straw man. You, along with many others, are ignoring (wilfully?) the fact that Target has had to explicitly decide to make their site inaccessible. Take a look at their site as it is right now; they've chosen to use images for functional links and they have rarely, if ever, included an alt attribute in the image element where all they would have needed to do was bloody-well duplicate the text already in the image in the alt attribute. They have taken a medium that's fundamentally accessible (i.e. one which, by virtue of being text-based, can be intelligently parsed by a screenreader), and intentionally or ignorantly rendered it inaccessible.

Not only are they morons for apparently not understanding accessibility concerns, they must also be pretty dim-witted about e-commerce if they're too dense to provide textual equivalents for the UI elements required to make purchases.

"It's not immediately evident what the way of reconciling disability with this new medium should be"

What is evident is that you're not well-informed enough to be commenting on this event; check items 25 through 34 of the complaint and get back to us. Basic compliance with the WAI Guidelines or Section 508's guidelines (though not required by law for private industry) would likely have prevented this ever becoming an issue for Target--as would simply running the cart application's code through the w3c validator and correcting the resulting errors...

Forget flash sites, have you ever tried implementing a Captcha system that was usable by the blind?

Sure. "The capital of Texas is Austin. What state has it's capital located in Austin?"

If the person types in "Texas", they're human and can read/hear English. Obviously you use multiple questions and vary the order of things. Plugins for logic and multiple choice text tests are available on every major web publishing system I'm aware of.

The w3c has several alternatives for captchas on their site, there's nothing magical about captchas that a web site would collapse without them.

You may as well ask "how do I make a staircase accessible to poeple in wheelchairs?" You build a ramp.

Check out the Web Accessibility Initiative for standards info.

Smaller businesses can take years to squeeze the cost of a total site re-design out of their profits.

Well, no problem there, then, because website accessibility issues have been discussed and understood in professional circles since the late 1990s. That's lots of time. The Web Accessibility Initiative, for example, is driven by the same organisation that defines HTML and XML. They've been promoting accessibility publicly since about 1998. So someone could hardly call themselves a web professional and not know about this issue in detail.

Unless you've been sucked in by some fly-by-night operator who thinks that FrontPage and an undergrad arts course are all that's needed to create the public face of your business, you're already good to go. Because you know that standards compliance saves you money in the long run, and that the most common blind person to visit your site is a web crawler, meaning that accessbility and search engine ranking can be directly correlated.

Yep, as long as you diluted the commercial, proprietary snake-oil with just a few dollops of common sense, ensuring accessiblity is a simple matter of picking up the WAI checklist and having an intern spend a few days verifying the few minor problems that somehow leaked into production.

So what was your objection, again?

"How do you define 'accessible'?"

I'd point you to section508.gov, but ... it's inaccessible (i.e. "Firefox can't establish a connection to the server at www.section508.gov"). Granted, Section 508 only legally applies to government agencies, but I would imagine (IANAL, of course) that compliance by commercial websites would be sufficient in cases like this.

WAI's WCAG might be a good place to start if you're concerned about whether your site is accessible. I'm also pretty sure there are Section 508 and WCAG validators out there.

"How do you define 'accessible'?"

I'd point you to section508.gov, but ... it's inaccessible (i.e. "Firefox can't establish a connection to the server at www.section508.gov"). Granted, Section 508 only legally applies to government agencies, but I would imagine (IANAL, of course) that compliance by commercial websites would be sufficient in cases like this.

WAI's WCAG might be a good place to start if you're concerned about whether your site is accessible. I'm also pretty sure there are Section 508 and WCAG validators out there.

First, the inspirational quote: "The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect." -- Tim Berners-Lee, W3C Director and Inventor of the World Wide Web

Some info for people who want to learn more:
"Website Accessibility Initiative (WAI)", published in 1999 by the "World Wide Web Consortium (W3C)".

Lighthouse.org A lot of help on designing with vision-impaired people in mind.

And finally, (Please don't slashdot this poor guy's site)... online classic stories (Twain, H.G. Wells, etc.). It's called www.readeasily.com , and was setup specifically for vision-impaired, but with such good stories that I often go there myself.

how the f*k are we supposed to know what is considered 'inaccessible' - ie worthy of being sued over - without some specific, clearly defined guidelines.

You mean like... the Web Content Accessibility Guidelines?

So does this mean the death of flash only websites lol.

Not necessarily. New versions of SWF include ways to make objects accessible. But on the other hand, it could spell doom for sites that exclusively use visual CAPTCHAs.

Good. I see the connection: Scott McNealy is from Sun, Sun produced java, and Jigsaw was written in java. Glad there's no namespace confusion here.

The specs are all on-line.

OK, I'm joking, but it would be nice, wouldn't it?

One of the first principles taught to those learning Web design, is to avoid using white text on a black background. Such Web pages usually try to appear cool and edgy, but instead often comes off as immature in the eyes of an Internet veteran, and sinister to the Internet newbie. It doesn't work on Web sites

Immature and sinister are not always bad things! (I feel I have to stand up for my white on black site, even though I'll just get flamed again).

Books:
The Zen of CSS Design, Eric Meyer on CSS. Two excellent books to get you started. The concept of CSS layout design is the big hurdle, once you figure it out, it's a breeze and quite fun.

Websites
www.w3schools.com - Excellent for html too. Read up here about semantics. http://www.w3.org/Style/Examples/007/ - Something else from W3C. This shows you some stuff you will need once you start getting the concepts of CSS down.

Here's some advice from me: Start with healthy HTML. If your HTML is not valid AND semantic, CSS will be very difficult to learn. If you are not familiar with xhtml semantics, I recommend you spend some time here: http://www.w3schools.com/xhtml/default.asp . If your code is not neat and organized, if you are not closing all your tags, CSS will not be nice to you.

I hope this points you in the right direction!

Here is the best manual, from W3C themselves:

http://www.w3.org/TR/REC-CSS2/

"A new initiative spearheaded by a University of Georgia professor aims to produce a library of 1,000 wiki textbooks by tapping the collaborative power of wiki. Inspiration for the project came from a computer science course that wrote its own textbook on XML"

A very cool idea in principle, but if the XML book they've done is typical, they should stop now. Just for grins, I opened to a subject I know quite well, which is XML and Schemas. There we find:

"Entities are basically the objects a Schema is created to represent. As stated before, they have attributes and relationships. We will now go much further into explaining exactly what they are and how to write code for them.

There are two types of Entities: simpleType and complexType. "

Well no. That's about as wrong as you can be. The term "entity" in XML has a rather precisely defined meaning and it has very little to do with simpleTypes or complexTypes. Entities are a really fundamental concept in XML. While it's no doubt tempting to someone who views the world in entity/relation terms to use "entity" in that sense (which I suspect is what the author had in mind), that's no excuse for writing textbooks that are wrong. Whoever wrote this section obviously didn't have a student's much less a textbook author's grasp of XML details.

As it stands, this example suggests that wikibooks are at risk of producing some strikingly inaccurate teaching materials, and that's very troubling. Looks like some much for serious fact checking will be needed if books like this are to to more good than harm. Too bad, because the idea of wikibooks does seem very appealing.

Exactly.

In a sound-proof room, with very high-quality equipment, with my hearing aids on I have (IIRC) about 95% recognition of two-syllable words with no context. I don't have my audiogram handy right now, but I think it was around 60% without my hearing aids on. My loss is classified as "moderate", but is also progressive. My dad's loss is quite severe now with most of his speech recognition coming from lip reading, not from actually hearing the words.

I highly recommend that anyone thinking about captcha read this article: http://www.w3.org/TR/turingtest/

Probably the best approach is for everyone to create content on their own site. The content must be signed, and then a reference submitted as a contribution. The site receiving the contribution can verify the signature, and check the web-of-trust associated with the key. The essence here being a web-of-trust to avoid abuse. The biggest problem being the need for widespread (global) adoption to be usable.

PS. I post here (occaisionally) as AC only because I'm not really interested in creating an account, and the site doesn't let me supply my email address in place of a username.

I for one think its time to just scratch HTML as it currently exists and scratch CSS right along with it, and come up with something that actualy works smoothly and works as designed!

I'll grant you that, yes, there are some limitations and frustrations with CSS. But to scrap it entirely is nonsense - why start over from scratch, when CSS 2 and 3 are actually steps in the right direction? The newer specifications for CSS contain much more power and control over layout and style. The problem is not with CSS 1, it's mostly with getting browser makers to implement a bug-free and consistent engine for CSS (think IE).

Basic fundemental layout strategies like Areas, Menus, Images, scrolling, layers and all the primitives sould be part and parsle of an HTML-Like specifcation, not an add-on cludge like CSS.

According to you. According to some others, HTML should get farther away from that crud (think XHTML). And if you ask me, I think they are right. I'd rather have HTML become more objective. I shouldn't have to remove pre-defined styles from HTML elements with CSS (like one has to with unordered lists, which have margins, padding, layout, and list-styles by default).

If you are passionate and want to have a say in the direction of HTML / CSS, you could join the w3. It's a joke, but hey...

But the NFB website itself is not standards compliant. http://validator.w3.org/check?uri=http%3A%2F%2Fwww .nfb.org%2Fnfb%2FDefault.asp

Here's the link for XHTML: http://www.w3.org/TR/xhtml1/

And here's how its described:

XHTML(TM) 1.0 The Extensible HyperText Markup Language (Second Edition)

A Reformulation of HTML 4 in XML 1.0

Extensible HTML is NOT HTML 4 any more than SGML in HTML. XHTML is a superset of HTML. For example, "All dogs are animals, but not all animals are dogs."

This has got to qualify as the WTF of the Day:

"One would assume, seeing as it's 2006 and all, that he intends to rebuild the site as a modern standards compliant site. Even if he chose html 4.01 instead of xhtml it's still best practice to close all your tags."

HTML 4.01 IS the current HTML (as opposed to XHTML) standard. And some of those bullshit "best practices", like "closing all tags", are forbidden by that very standard. Its not like its hard to read. I linked to the specific page on the W3C site.

So stop being a Microsoft Weenie (yes - you're easily identified by your willingness to break standards, just as FrontPage breaks those same standards by doing "best practice" shit like closing tags that don't need them).

List of tags that the standard forbids having a closing tag: http://www.w3.org/TR/REC-html40/index/elements.htm l

1. AREA
2. BASE
3. BASEFONT
4. BR
5. COL
6. FRAME
7. HR
8. IMG
9. INPUT
10. ISINDEX
11. LINK
12. META
13. PARAM

Do you close your image tags? Then you're not in compliance with the published standard. So please spare the bullshit about "modern standards compliant site. Even if he chose html 4.01 instead of xhtml it's still best practice to close all your tags.". You don't know what you're talking about, and it shows.

In case you missed it, the article's title asked what was in your HTML toolobx, not you XML toolbox, or XHML toolbox.

http://validator.w3.org/

http://jigsaw.w3.org/css-validator/

Along with awk, sed, vi/pico/nano, and occasionally perl for really complex alterations.

http://validator.w3.org/

http://jigsaw.w3.org/css-validator/

Along with awk, sed, vi/pico/nano, and occasionally perl for really complex alterations.

no it's not HTML is still SGML, and still alive and well.

HTML is not XML.

First, before bitching about something, you should take a moment to learn about it.

"It has all the usual problems: paragraph tags with no ending tag"

There's no end tag required for paragraphs, as per the official spec: http://www.w3.org/TR/REC-html40/index/elements.htm l

HTML is not XML. Closing tags are optional for some elements, and forbidden for several others. and putting a slash at the end of a tag that doesn't have a closing tag, so it looks "xml-y" is an affectation and a waste of bytes.

• HTML Tidy
• A text editor (I like vim and gedit)
• The GIMP (image editor)
• ImageMagick
• W3C validator
• Various docs and tips such as Checklist of Checkpoints for Web Content Accessibility Guidelines from W3C
• CSS Cheat Sheet

• HTML Tidy
• A text editor (I like vim and gedit)
• The GIMP (image editor)
• ImageMagick
• W3C validator
• Various docs and tips such as Checklist of Checkpoints for Web Content Accessibility Guidelines from W3C
• CSS Cheat Sheet

• HTML Tidy
• A text editor (I like vim and gedit)
• The GIMP (image editor)
• ImageMagick
• W3C validator
• Various docs and tips such as Checklist of Checkpoints for Web Content Accessibility Guidelines from W3C
• CSS Cheat Sheet

W3C has a link validator you might be interested in.