Slashdot Mirror

Ok, validation isn't everything, and passing the validator is not 100% confirmation that your page is valid, but just for kicks (and to see if the best of web 2.0 passes the basics of web 1.0), let's pass their list through the W3C's HTML Validator and see what we get (links go to the validator results

Ok, validation isn't everything, and passing the validator is not 100% confirmation that your page is valid, but just for kicks (and to see if the best of web 2.0 passes the basics of web 1.0), let's pass their list through the W3C's HTML Validator and see what we get (links go to the validator results

Ok, validation isn't everything, and passing the validator is not 100% confirmation that your page is valid, but just for kicks (and to see if the best of web 2.0 passes the basics of web 1.0), let's pass their list through the W3C's HTML Validator and see what we get (links go to the validator results

Ok, validation isn't everything, and passing the validator is not 100% confirmation that your page is valid, but just for kicks (and to see if the best of web 2.0 passes the basics of web 1.0), let's pass their list through the W3C's HTML Validator and see what we get (links go to the validator results

Ok, validation isn't everything, and passing the validator is not 100% confirmation that your page is valid, but just for kicks (and to see if the best of web 2.0 passes the basics of web 1.0), let's pass their list through the W3C's HTML Validator and see what we get (links go to the validator results

Ok, validation isn't everything, and passing the validator is not 100% confirmation that your page is valid, but just for kicks (and to see if the best of web 2.0 passes the basics of web 1.0), let's pass their list through the W3C's HTML Validator and see what we get (links go to the validator results

Last time I was in this situation, back in 1997, I rolled my own. It's served me very well for nine years, but increasingly design commitments I made early have started to seem wrong in terms of subsequent developments. Now I'm thinking of where I go from here; I've been thinking about the features a modern software system should have. And I've got a proof of concept which generates all the elements of a Web application from a single source file.

I haven't yet decided which way I'm going to jump. But I have already ruled out a lot of approaches. Firstly, anything which mixes logic with presentation is clearly wrong. That rules out all the taglib based systems, including PHP, Cold Fusion, JSP, BRL and all the others. Ruby on Rails is sort-of OKish, since the presentation layer ('views') is separateish from the logic. But in practice it seems you can put any logic into the Rails templates. Having the templates in a different, standard language - ideally XSL - seems to me a better solution.

As to the underlying language, after ten years Java is stale for me. I spend too much of my time struggling round its limitations, and primarily, around static typing and baroque libraries. Ten years ago Java had a lot of promise, particularly in strong portability and platform independence. But everything else has caught up, and Java now looks increasingly like the wrong language for general purpose programming. So what's the right language?

Back in the 1980s everyone gave up on LISP because it needed machines which were too expensive. But the sort of horsepower LISP needs is now cheap, and, indeed, LISP is economic of machine resource compared to many modern language systems. The downside of LISP as an implementation language is that while Web hosting companies these days often provide PHP and are reasonably comfortable with Java and Ruby, a toolkit which uses a LISP foundation can only really take off with people who control their own servers. But, that apart, LISP currently looks like the best bet to me.

Interestingly enough, MSN search validates as XHTML 1.0 strict, MSN.com has only 2 errors (also XHTML 1.0 strict), and microsoft.com validates as HTML 4 transitional.

Interestingly enough, MSN search validates as XHTML 1.0 strict, MSN.com has only 2 errors (also XHTML 1.0 strict), and microsoft.com validates as HTML 4 transitional.

Interestingly enough, MSN search validates as XHTML 1.0 strict, MSN.com has only 2 errors (also XHTML 1.0 strict), and microsoft.com validates as HTML 4 transitional.

The produced pages claim to be XHTML 1.0 Strict... but it isn't! The mistakes are pretty bad such as not closing <img> and <br> tags. Also there is so ugly HTML like empty <p></p> tags that you'd think would be easily removed. Also, I don't see any support for the semantic web such as annotating your page with rel="". The battle for web-standards will be won on the web-designer front: when the tools produce correct pages that'll give impetus for everyone to produce clean pages and for all other tools to get up to snuff. Frankly, I think the best way is to create an editor that only lets you create pages that pass from valid state to valid state by producing all the necessary tags every time you add an element so that you can't forget. It can be invasive but it can also be done well.

Please mod this up so that maybe somebody at Google will notice.

PS- What if /. required all post to be valid HTML (or plain-text) before posting them? That would definitely increase awareness and encourage good HTML habits! (After that, perhaps passing a spellchecker! :P)

Your students must work at MSN, the only valid-XHTML-Strict search engine, then :)

Since when has Google ever cared about W3C validation? Google.com has 51 errors, an amazingly high number considering how small the page is visually.

lol, try to validate the page ;-)

http://validator.w3.org/check?uri=http%3A%2F%2Fdre w.mclellan.googlepages.com%2Fhome

Failed validation, 16 errors. And these are serious errors that can tell you sth about googlepages engine.

michal

MS Guy: We added tabbed browsing and upped our CSS support to what was published in 2000.

There'd be hell to pay if the MS guy actually claimed that - they are still missing whole sections of CSS 2, published in May 1998. Granted, Internet Explorer 7.0 has improved support, but it's still missing, e.g. generated content and tables.

You'll be pleased to know, however, that Internet Explorer 7.0 finally has complete support for CSS 1, published in 1996. So let's all welcome Microsoft to ten years ago!

MS Guy: We added tabbed browsing and upped our CSS support to what was published in 2000.

There'd be hell to pay if the MS guy actually claimed that - they are still missing whole sections of CSS 2, published in May 1998. Granted, Internet Explorer 7.0 has improved support, but it's still missing, e.g. generated content and tables.

You'll be pleased to know, however, that Internet Explorer 7.0 finally has complete support for CSS 1, published in 1996. So let's all welcome Microsoft to ten years ago!

MS Guy: We added tabbed browsing and upped our CSS support to what was published in 2000.

There'd be hell to pay if the MS guy actually claimed that - they are still missing whole sections of CSS 2, published in May 1998. Granted, Internet Explorer 7.0 has improved support, but it's still missing, e.g. generated content and tables.

You'll be pleased to know, however, that Internet Explorer 7.0 finally has complete support for CSS 1, published in 1996. So let's all welcome Microsoft to ten years ago!

MS Guy: We added tabbed browsing and upped our CSS support to what was published in 2000.

There'd be hell to pay if the MS guy actually claimed that - they are still missing whole sections of CSS 2, published in May 1998. Granted, Internet Explorer 7.0 has improved support, but it's still missing, e.g. generated content and tables.

You'll be pleased to know, however, that Internet Explorer 7.0 finally has complete support for CSS 1, published in 1996. So let's all welcome Microsoft to ten years ago!

IE doesn't fully support setAttribute() yet (id, class, for, onClick, etc.). Firefox doesn't support innerText, outerHTML, nor outerText.

In fairness, setAttribute() is part of the DOM standard, whilst innerText isn't, so I wouldn't be criticising Firefox here.

Don't fall into the classic trap of "Let's rewrite it and make it better". One rarely does, particularly with an installed base of several billion.

-Dom

I'm looking for a Windows driver that will capture my GDI calls and render to HTML. Any suggestions?

You might want to look at libwmf - search for SVG inside the page. It's isn't exactly what you want, but if you can capture your GDI to a WMF, you're GTG. (Good to go.)

No-one has included a link to SVG related material. There you go.

link:

http://validator.w3.org/check/?uri=http%3A//www.id kk.com/C012_052_InterstellarTravel.htm

(just to make sure you don't think I'm pulling your chain)

make your CSS valid and try again

http://jigsaw.w3.org/css-validator/validator?uri=h ttp%3A%2F%2Fwww.creimer.ws%2F

( Enter your web site URL into http://jigsaw.w3.org/css-validator/ )

It looks like you have some parse errors in your CSS.

Maybe those are causing Safari to mis-render it ?

http://jigsaw.w3.org/css-validator/validator?uri=h ttp%3A%2F%2Fwww.creimer.ws%2F

( Enter your web site URL into http://jigsaw.w3.org/css-validator/ )

It looks like you have some parse errors in your CSS.

Maybe those are causing Safari to mis-render it ?

doh

I've never understood web standards. If most browswers don't follow them, (as aparent that IE, Firefox, and Opera each failed to render the acid2 face test properly) then whose standards are they? Wouldn't the 'standards' be the most popular useage of code?

The point of an acid test is that is should be hard, something to strive for. The idea is that if you have passed this test you likely have a good implementation of CSS. It is possible to fail the acid test and be good in other aspects of the standard, or pass it and still be deficient, but it should give a good indicator. It is worth noting that every modern browser passes the first acid test, but it was considered a challenge at the day. IE didn't pass it before version 6.

The focus of the CSS Working Group in the W3C has the last five years changed focus from more features (CSS3) to more universally consistent presentation (CSS2.1). I believe this is a good move, and the Acid2 test should be viewed in that light. Opera intends to support CSS 2.1 and I presume that is the case with Firefox and Konqueror too, and we all change our implementations in tune with how CSS2.1 develops. IE is definitely far behind, but should be commended for moving in the right direction.

At some point Opera, FF, and Konqueror/Safari should render CSS2.1 more similar to each other than they would do to their own older versions, and hopefully not differ in any meaningful way. Whether IE one day is going to turn this gang of three into a gang of four remains to be seen, it won't happen with IE7, but hopefully the development won't stop there.

Jonny Axelsson, Opera Software

It supports a supristing amount of SVG tests.
Over 90% of the ones on this page work well.
http://www.w3.org/Graphics/SVG/Test/

You'd probably want to, at random intervals, ask for the user to fill in a captcha or something similar to that.

Are publicly traded companies of that size, who likely even have a government contract or two, allowed to discriminate against blind customers?

MSN? Hell, it's valid HTML (search results are valid HTML too) so it must be good. Who would use a web site with 280 errors? It's madness.

MSN? Hell, it's valid HTML (search results are valid HTML too) so it must be good. Who would use a web site with 280 errors? It's madness.

Someone is way ahead of you!

1. Add a DOCTYPE declaration at the top
   
2. Specify the character set with the Content-type header (you can use a meta tag)
   
3. Add alternate text for blind users to every image (for unimportant decorative images alt="" is fine)
   

However, it should be noted that the current XHTML 2 Working Draft doesn't have b or i tags in it, dropping them in favor of stylesheets or strong & em.

Why are you letting third parties tell you what is and isn't allowed? Just look at the specification. XHTML 1.0 refers to this specification, and XHTML 1.1 is no different.

I also get referred to it regularly, as though it's some kind of brand new idea instead of the tired old elitist piece of trash that it is.

Is a well-written rebuttal to hixie's screed available on the web?

One can send XHTML as text/html to IE and correctly to other browsers.

But then you have to sniff the Accept: header and generate either XHTML or HTML 4. This rules out users in environments that do not provide for dynamic content, such as ISP web space, university web space, and banner-supported free web space.

The thing very few XHTML advocates remember is that the interpretation of the / character differs incompatibly between conforming implementations of XML and SGML. For instance, under the (sometimes obscure) SGML SHORTTAG rules used by HTML 4, / is a shortcut for starting and ending an element body, meaning that <em/emphasized/ in HTML 4 is equivalent to <em>emphasized</em>. In XML, on the other hand, / always denotes an empty element such as <br />, but in SGML, that means the same thing as <br>>. But you're right that most existing HTML user agents support the <dl compact> part of SHORTTAG but not the <em>emphasized</em> part of SHORTTAG, which is the deficiency that makes the Appendix C hack work in practice.

Still, what about the CDATA/PCDATA differences that require inline script and CSS to be escaped using ridiculously complex ASCII art gymnastics? What about the mistaken removal in XHTML 1.1 of the value attribute of the li element, making it impossible to start an ol element at any value other than 1? And what about the differences in CSS semantics, DOM semantics, and the fact that W3C deprecated the practice?

XHTML can become what it was supposed to become: a stepping stone to more functional and powerful XML based markups.

But first we need a stepping stone to the stepping stone, in the form of a widely deployed web browser that understands the CSS and DOM semantics that go with XHTML. Then once XHTML 1.0 is adopted, how long will it be before we can move on to XHTML 1.1, which drops Appendix C and the transitional dialect entirely, or XHTML 2.0, which even renames many of the existing elements?

is not deprecated. Everyone thinks it is for some reason.
http://www.w3.org/TR/xhtml-modularization/abstract _modules.html#s_presentationmodule

then do what is recommended on the w3 FAQ

So what's the accepted DOM function that, given a string of markup, parses the markup to give me one or more nodes that I can attach?

You can do it with DOM3LS, although I don't know if that's the easiest way. I was under the impression that the W3C were going to standardise an innerHTML/innerXML property.

Given that the market at the moment is trying to squeeze as much functionality out of existing technologies and the increasing use of new markup languages such as SVG and MathML, I would have thought that more and more books would start teaching XHTML/CSS.

XHTML will allow far better flexibility when adding in new functionality provided by new markup languages as well as better machine readability for the purposes of migrating pages at a later date. Tools to assist in developing syntactically valid XHTML pages are easily available and easy to use (such as Firefox's Validator tool as well as the old trusty http://validator.w3.org/), so the argument that novices may break XHTML pages by not writing valid code is not as potent as it once was.

The challenge now lies in teaching students to write semantically correct markup. This cannot be checked by a validator or any other machine tool, as semantically incorrect markup may still follow the rules of syntax. However, it can break a braille browser or a mobile device that degrades pages' layout for the purposes of displaying it on a small screen, rendering the information inaccessible to users of these devices.

XHTML's stricter syntax far more strongly encourages users to think in terms of content/presentation rather than just writing a blob of HTML to show a nicely formatted essay/blog/gallery. The more information is both syntactically and semantically correct, the more the web will be a friendly place for users of devices other than PCs, or users who are accessing the web from a device designed to aid a disability.

It is for these reasons, forward compatibility and accessibility, that I think that XHTML should start being taught. I always hear it argued, when I recommend XHTML to a would-be developer, that "XHTML is not understood" and "it breaks pages if used incorrectly". Well, help users to understand, and teach them to use it correctly.

You are thinking of the semantic web, which is XML based; however, XHTML is not inherently semantic, just easily-parsed.

<?xml version="1.0"> isn't the XML DTD, it's the XML prolog. Any character at all, even whitespace, before the HTML DTD will cause IE to enter quirks mode, where it uses the IE 5 box model, rather than standards mode, using the W3C CSS box model. As IE doesn't understand the application/xhtml+xml MIME type, there is absolutely no point in serving XHTML to it, so the XML prolog (which isn't a mandatory requirement anyway) is just a waste of space.

IE7 won't be available for any Windows version older than XP SP2, so all those Win 2000 desktops out there will continue to run IE 6. There's not much hope of throwing away our hacks for coercing IE into just-about-standards mode for several years.

There is a new version of the W3C's Mobile Web Best Practices. The Usable Screen Size is bumped to a width of 120 pixels.

From the w3c's Mobile Web Best Practices 1.0

People have strong, but divergent opinions on this. The absolute minimum being 96 x 96 pixels. Strong support is expressed for 128 x 128, however a vocal group supports bigger still.

This article states that the most mobile users use thier devices for email and weather not browsing websites.

Hope this helps....

Especially that current standards are ridden with it :)
Yeppers, w3c-blessed DOM standard has most functions duplicated with
"NS" version, like createAttribute and createAttributeNS.

You are correct that I had misinterpreted some of the things listed on that page, though. It's been some time since I've read the entire spec, and the last time I read the entire thing, img had been pulled out. The Major Differences with XHTML 1 section still implies that it is gone, in the following text, emphasis added by me.

Images: the HTML img element has many shortcomings: it only allows you to specify a single resource for an image, rather than offering the fallback opportunities of the object element; the only fallback option it gives is the alt text, which can only be plain text, and not marked up in any way; the longdesc attribute which allows you to provide a long description of the image is difficult to author and seldom supported.

XHTML 2 takes a completely different approach, by taking the premise that all images have a long description and treating the image and the text as equivalents...

h7 was a typo, and my understanding (based on an article I read quite some time ago) was that h1-h6 were already pulled from the spec. I probably should have looked that up, but it's too late now.

I would love to go back and edit the original list, or even clarify that some of these are just "best practices," but Slashdot's commenting system prevents me from doing that.

P.S. I checked all the other tags, and the comments on them are correct.

How is that comment in any way related to what I stated?

You claimed that XHTML 2.0 has done away with the img tag, when they clearly haven't: Image Module

You claimed that XHTML 2.0 has done away with the h1 through h7 tags, when there has never been an h7 tag anyway and the h1 through h6 tags clearly still remain: Structural Module

My point was that you don't know what you're talking about. You responded by pointing out that some of the new elements of XHTML 2.0 already "work" in current browsers, such as the section and h elements, since all they do is group other elements or text. I cannot understand your train of thought.

How is that comment in any way related to what I stated?

You claimed that XHTML 2.0 has done away with the img tag, when they clearly haven't: Image Module

You claimed that XHTML 2.0 has done away with the h1 through h7 tags, when there has never been an h7 tag anyway and the h1 through h6 tags clearly still remain: Structural Module

My point was that you don't know what you're talking about. You responded by pointing out that some of the new elements of XHTML 2.0 already "work" in current browsers, such as the section and h elements, since all they do is group other elements or text. I cannot understand your train of thought.

I was looking at the latest draft, the Backwards Compatibility section to be exact.

You're way behind the times. Some of the elements that were once "removed" have been added back in. In fact, the linked article even mentions the img tag. Take a look at the latest working draft and get your facts straight.

safeDisplay(HTML page)
{
    try
    { display(page) }
    catch(ParseException pe)
    { display(tidy(page));}
}

Tired of the malformed xhtml pages
well, Tidy keeps your webpages clean

http://www.w3.org/People/Raggett/tidy/