Slashdot Mirror

The word pixel meant "picture element", but CSS redefined it to mean something quite different (a particular subtended angle of view). This causes confusion: CSS pixels are not pixels. (Indeed, I have seen misinformed comments on Slashdot due to that confusion.)

My question is this: why call the subtended angle a "pixel", instead of something else (e.g. "subangle")? If CSS wanted to use the subtended angle for something, that is fine, but calling it a pixel seems to follow the approach of Humpty Dumpty—"When I use a word, it means just what I choose it to mean".

Our website was built by a "website design bureau". We told them it had to be standard, so it would work on Mozilla as well.
What they produced was an absolute mess.

You should have put it into the contract that the final product must pass W3C validation. No validation, no payment.

"howcome" this page doesn't CSS validate?

"howcome" this page doesn't CSS validate?

http://www.w3.org/Style/CSS/current-work

We'll see consistency when the SVG people put together an extensive testsuite

What's wrong with the testsuite the W3C provides?

This looks familiar.

Does this actually work on IE?

No, which was basically my point. CSS doesn't make it difficult, Internet Explorer makes it difficult.

... which makes it totally useless to me.

Next.

Wow, I thought you were full of !#@$ until I checked out W3School's CSS display page.

Why are you referring to those guys? They are pretty sleazy. Why not refer to the authorative source for whether something is valid CSS or not?

Do they differ on this one? Only in level of detail.

The last time I checked there was only display: none/block/inline.

display: table-cell has been around since 1998, and most browsers implemented it ages ago. You haven't heard of it because nobody uses it. Nobody uses it because it isn't in any tutorials. It isn't in any tutorials because Internet Explorer doesn't support it.

Oh please, I forgot it because I don't use it because it's of no use to me because IE doesn't support it. Boo hoo.

Can you crawl out from under your rock and tell me whether IE7 supports this? That would be one useful thing from this conversation.

In summary to any readers, regardless of the worthiness of Microsoft and Internet Explorer, you must learn to use a smaller, crippled subset of CSS (and workarounds) if you're going to web design, mainly because of the deficiencies of IE. You can do some pretty fancy Flash-like stuff if you use CSS that's available in Mozilla/Opera/KHTML, but downloading software is not what the internet is about, it's going to an internet cafe and checking out a site with whatever's available.

Wow, I thought you were full of !#@$ until I checked out W3School's CSS display page.

Why are you referring to those guys? They are pretty sleazy. Why not refer to the authorative source for whether something is valid CSS or not?

Does this actually work on IE?

No, which was basically my point. CSS doesn't make it difficult, Internet Explorer makes it difficult.

The last time I checked there was only display: none/block/inline.

display: table-cell has been around since 1998, and most browsers implemented it ages ago. You haven't heard of it because nobody uses it. Nobody uses it because it isn't in any tutorials. It isn't in any tutorials because Internet Explorer doesn't support it.

Perhaps you're right -- I have to admit that the only experiences I have had with XML have been with C and perl DOM parsers, and PHP5 (which handles XML as first-class data entities, and for all I know may be using the C DOM XML library underneath). I have not worked with a streaming XML parser -- though, are you sure these parsers are as flexible as you've made them out? The XML specification, section 5.1 seems to imply that a parser that parses a later section of an XML document without parsing some earlier section is out-of-spec (and for good reason -- earlier data can change the meaning of later data, and there's no table of contents in an XML document which gives the lengths of independent sections (which would mostly solve the issue)).

Sure there are other ways to represent data -- but not everyone will understand them, and there won't always be easy to understand rules to expand them [..]

This is perhaps the strongest argument in favor of using XML. Everyone's already using it, and expanding a dataset is straightforward. All I can do is wish that there was a sane, well-crafted, easily-parsed, fault-tolerant binary specification which enjoyed the same ubiquity. One of the points I was trying to make in my original post, though, is that if your situation was already well-suited to using XML, then you were in a position to create and use a nonstandard specification which lacks XML's intrinsic faults.

-- TTK

Definitely agreed – while I tend to be almost insanely obsessive about using CSS, there are a few things that I've found are just so much easier with tables; as far as I'm concerned, image galleries are "tabular" enough that it's OK to bend the no-tables-for-non-tabular-data rule just a little bit. And complex pages like the Get Ultima! page (for my distribution – not an ad, just what I feel's a good example) would be hard to implement without tables, either. Personally, I honestly couldn't care how the Web site's implemented – the only thing that I consider important for a "proper" Web site design, other than the design itself of course, is whether or not it validates.

By the way, you can even do without <div>'s if you know what you're doing – that same link's also a good example of that. Other than the actual content, everything's implemented using <ul>'s and <h1>, as well as the <body> tab itself. It's a bit broken in IE, but since it is a Linux site most of the people are probably already somewhat into open-source stuff like Firefox anyway, and honestly, I don't even use Microsoft products so I couldn't care less.

Just thought I'd add my two cents.

Dracos is (sort-of) wrong. From the specification:

If the height of the containing block is not specified explicitly (i.e., it depends on content height), and this element is not absolutely positioned, the value computes to 'auto'. A percentage height on the root element is relative to the initial containing block

The special case for the root element was undefined in previous specifications, which is why Internet Explorer doesn't get it right.

So basically, Dracos' technique should work, but only if you explicitly set the height for all parent elements or if you use absolute positioning, and only if you expect browsers to follow the more recent specification.

Dracos is (sort-of) wrong. From the specification:

If the height of the containing block is not specified explicitly (i.e., it depends on content height), and this element is not absolutely positioned, the value computes to 'auto'. A percentage height on the root element is relative to the initial containing block

The special case for the root element was undefined in previous specifications, which is why Internet Explorer doesn't get it right.

So basically, Dracos' technique should work, but only if you explicitly set the height for all parent elements or if you use absolute positioning, and only if you expect browsers to follow the more recent specification.

What's next?

XHTML2 and CSS3

But XHTML2 can't be a reality until IE can parse XHTML, or IE loses a lot more market share. (no, it can't, it can parse pretend XHTML that's served as text/html, and you can't serve XHTML 1.1 or XHTML2 as text)

What's next?

XHTML2 and CSS3

But XHTML2 can't be a reality until IE can parse XHTML, or IE loses a lot more market share. (no, it can't, it can parse pretend XHTML that's served as text/html, and you can't serve XHTML 1.1 or XHTML2 as text)

This looks like it would be a royal pain to read and write, or to write software capable of reading or writing it. In fact, I seem to remember a simple PDF is quite a bit easier, but perhaps that's just because I didn't use any of the complex features it has.

I would argue that XPS is easier since I can manually modify it by unzipping, modifying the constituent files (XML, images, fonts), then rezipping. Please correct me if I'm wrong, but with PDF I believe at least a reader/writer program is required; the format is not human readable.

The one complex feature I see with your Glyphs example is Indices, which describes the individual glyphs required to render the string, as well as spacing between glyphs. Indices and StyleSimulations are optional, so the remaining attributes are quite simple. FontUri may look scary but remember that XPS is really a ZIP file in disquise; you could have a FontUri of "myfont.ttf" if you were so inclined. Thus, Glyphs can be as simple as:

<Glyphs Fill="#ff000000" FontUri="myfont.ttf" FontRenderingEmSize="10.7" OriginX="144" OriginY="123.84" UnicodeString="centers. A stroke with a width of 0 is treated in the same manner."/>

Furthermore, Windows Presentation Foundation provides all the necessary APIs to generate XPS documents. You never have to deal with the XML or ZIP file. And hopefully as you can see from my example, writing your own code to handle all this won't be as difficult as you make it sound.

I notice that it's unusual XML in that the parameters and text are all within the angle brackets. That means normal XML readers are going to have a hard time with it, which I suspect was the idea. This is not in the open standard spirit, is it?

Your comment is simply bizarre. XML allows 0 or more attributes in an element, so any XML reader that can't read that is non-standard. Plus the XML format is XAML; you could move all the attributes to elements if you wanted:

<Glyphs>
<Glyphs.Fill>#ff000000</Glyphs.Fill>
<Glyphs.FontUri>/Documents/1/Resources/Fonts/CA78F 0B5-
3077-43A2-8AC0-53671B1EB57C.odttf</Glyphs.Fo ntUri>
<Glyphs.FontRenderingEmSize>10.6997</Glyphs.FontRe nderingEmSize>
<Glyphs.StyleSimulations>None</Glyphs.StyleSimulat ions>
<Glyphs.OriginX>144</Glyphs.OriginX>
<Glyphs.OriginY>123.84</Glyphs.OriginY>
<Glyphs.Indices>70;72;81;87;72,59;85;86,53;17;3 ,34;36;3,34;86,53;87;85,41;82;78,60;72,59;3;90,83; 76,26;87;75;3;68,58;3,36;90;76 ;71,63;87,38;75,62;3,36;82,59;73,36;3;19;3,36;76;8 6,50;3,36;87;85;72;68;87;72,58 ;71,63;3;76;81,61;3,36;87;75,62;72;3,36;86;68;80,9 6;72,59;3,36;80,96;68;81,62;81 ;72;85;17;3,34</Glyphs.Indices>
<Glyphs.UnicodeString>centers. A stroke with a width of 0 is treated in
the same manner. "</Glyphs.UnicodeString>
</Glyphs>

Back in the late 1990s and earily 2000s, I used a VRML plug-in for the Windows version of Mozilla called Blaxxun Contact. I think when X3D came along and replaced the VRML97 standards (both defined by The Web3D Consortium, things became confusing. Of course there are other graphics standards such as OpenGL and SVG that are also used. DirectX will slow you down.

Already done and fully deployed: HTTP 1.1 includes persistent HTTP connections and pipelining of requests within the same TCP session. This means that the common conception of how HTTP actually functions—i.e. one TCP setup/teardown per HTTP request—is just incorrect. Of course, this depends on both ends of the connections supporting persistent connections and having the option to use them turned on.

[B.v.L]

...reveals that EXPO is an OWL schema. Exactly as described, it's an attempt to regularize the content of experimental design into machine readable form (XML). So any discussion of whether EXPO is a good idea or not really hinges on whether you think OWL is a good idea or not.

I believe you intended refer to xml specification (rather than xhtml, which was not used at all here, at least I wouldn't know about a prepares-for-ass-kicking tag in xhtml):

http://www.w3.org/TR/REC-xml/#sec-starttags

(oh, and by the way: see 44, the white space is explicitly optional)

At my work, we've chosen the XForms route using Chiba for a recent product. It's not that surprising that I use it, because I was one of the editors of the 1.0 spec a long time ago, but it progressed even in my absence ;-) and it does fit many of the needs people describe here, in particular security and accessibility.

We write our dynamic markup in XHTML+XForms, following W3C standards (including nascent accessibility standards), and then use Chiba server-side in Tomcat to translate it into HTML4 and JavaScript. Chiba also offers a translation to HTML4 with a "refresh" button to initiate the dynamic activity via plain old HTTP, so it's fully accessible, though not as dynamic.

Longer term, please check out the Mozilla XForms XPI, which will take the XHTML+XForms markup directly. The browser does all its security stuff already, and it follows the IETF HTTP RFC and other W3C specs directly, so there's no need for funky workarounds or security lifting. The Firefox implementation is at rev 0.5 or 0.6 about now, and it's definitely usable, but when it gets to 1.0 it will be really great for dynamic behavior.

There are other implementations as well, FormFaces, which is written entirely in JavaScript and is way cool, FormsPlayer for IE, with lots of advanced features and which is a plugin, not a native implementation (as in the Firefox one); X-Smiles, the open source standalone implementation from Finland, SolidApp, another OSS one with paid support for small devices (mobile phone vendors look here), PicoForms, also for embedded apps but not OSS, Orbeon, a complete back-end server solution incorporating XForms and pipelines. I'm sure there's more major implementations I've missed, and also partial ones as well.

If you want to know more check out the XForms FAQ and XForms or HTML authors Part 1 and Part 2.

Plus, Will Wheaton likes it.

At my work, we've chosen the XForms route using Chiba for a recent product. It's not that surprising that I use it, because I was one of the editors of the 1.0 spec a long time ago, but it progressed even in my absence ;-) and it does fit many of the needs people describe here, in particular security and accessibility.

We write our dynamic markup in XHTML+XForms, following W3C standards (including nascent accessibility standards), and then use Chiba server-side in Tomcat to translate it into HTML4 and JavaScript. Chiba also offers a translation to HTML4 with a "refresh" button to initiate the dynamic activity via plain old HTTP, so it's fully accessible, though not as dynamic.

Longer term, please check out the Mozilla XForms XPI, which will take the XHTML+XForms markup directly. The browser does all its security stuff already, and it follows the IETF HTTP RFC and other W3C specs directly, so there's no need for funky workarounds or security lifting. The Firefox implementation is at rev 0.5 or 0.6 about now, and it's definitely usable, but when it gets to 1.0 it will be really great for dynamic behavior.

There are other implementations as well, FormFaces, which is written entirely in JavaScript and is way cool, FormsPlayer for IE, with lots of advanced features and which is a plugin, not a native implementation (as in the Firefox one); X-Smiles, the open source standalone implementation from Finland, SolidApp, another OSS one with paid support for small devices (mobile phone vendors look here), PicoForms, also for embedded apps but not OSS, Orbeon, a complete back-end server solution incorporating XForms and pipelines. I'm sure there's more major implementations I've missed, and also partial ones as well.

If you want to know more check out the XForms FAQ and XForms or HTML authors Part 1 and Part 2.

Plus, Will Wheaton likes it.

At my work, we've chosen the XForms route using Chiba for a recent product. It's not that surprising that I use it, because I was one of the editors of the 1.0 spec a long time ago, but it progressed even in my absence ;-) and it does fit many of the needs people describe here, in particular security and accessibility.

We write our dynamic markup in XHTML+XForms, following W3C standards (including nascent accessibility standards), and then use Chiba server-side in Tomcat to translate it into HTML4 and JavaScript. Chiba also offers a translation to HTML4 with a "refresh" button to initiate the dynamic activity via plain old HTTP, so it's fully accessible, though not as dynamic.

Longer term, please check out the Mozilla XForms XPI, which will take the XHTML+XForms markup directly. The browser does all its security stuff already, and it follows the IETF HTTP RFC and other W3C specs directly, so there's no need for funky workarounds or security lifting. The Firefox implementation is at rev 0.5 or 0.6 about now, and it's definitely usable, but when it gets to 1.0 it will be really great for dynamic behavior.

There are other implementations as well, FormFaces, which is written entirely in JavaScript and is way cool, FormsPlayer for IE, with lots of advanced features and which is a plugin, not a native implementation (as in the Firefox one); X-Smiles, the open source standalone implementation from Finland, SolidApp, another OSS one with paid support for small devices (mobile phone vendors look here), PicoForms, also for embedded apps but not OSS, Orbeon, a complete back-end server solution incorporating XForms and pipelines. I'm sure there's more major implementations I've missed, and also partial ones as well.

If you want to know more check out the XForms FAQ and XForms or HTML authors Part 1 and Part 2.

Plus, Will Wheaton likes it.

At my work, we've chosen the XForms route using Chiba for a recent product. It's not that surprising that I use it, because I was one of the editors of the 1.0 spec a long time ago, but it progressed even in my absence ;-) and it does fit many of the needs people describe here, in particular security and accessibility.

We write our dynamic markup in XHTML+XForms, following W3C standards (including nascent accessibility standards), and then use Chiba server-side in Tomcat to translate it into HTML4 and JavaScript. Chiba also offers a translation to HTML4 with a "refresh" button to initiate the dynamic activity via plain old HTTP, so it's fully accessible, though not as dynamic.

Longer term, please check out the Mozilla XForms XPI, which will take the XHTML+XForms markup directly. The browser does all its security stuff already, and it follows the IETF HTTP RFC and other W3C specs directly, so there's no need for funky workarounds or security lifting. The Firefox implementation is at rev 0.5 or 0.6 about now, and it's definitely usable, but when it gets to 1.0 it will be really great for dynamic behavior.

There are other implementations as well, FormFaces, which is written entirely in JavaScript and is way cool, FormsPlayer for IE, with lots of advanced features and which is a plugin, not a native implementation (as in the Firefox one); X-Smiles, the open source standalone implementation from Finland, SolidApp, another OSS one with paid support for small devices (mobile phone vendors look here), PicoForms, also for embedded apps but not OSS, Orbeon, a complete back-end server solution incorporating XForms and pipelines. I'm sure there's more major implementations I've missed, and also partial ones as well.

If you want to know more check out the XForms FAQ and XForms or HTML authors Part 1 and Part 2.

Plus, Will Wheaton likes it.

At my work, we've chosen the XForms route using Chiba for a recent product. It's not that surprising that I use it, because I was one of the editors of the 1.0 spec a long time ago, but it progressed even in my absence ;-) and it does fit many of the needs people describe here, in particular security and accessibility.

We write our dynamic markup in XHTML+XForms, following W3C standards (including nascent accessibility standards), and then use Chiba server-side in Tomcat to translate it into HTML4 and JavaScript. Chiba also offers a translation to HTML4 with a "refresh" button to initiate the dynamic activity via plain old HTTP, so it's fully accessible, though not as dynamic.

Longer term, please check out the Mozilla XForms XPI, which will take the XHTML+XForms markup directly. The browser does all its security stuff already, and it follows the IETF HTTP RFC and other W3C specs directly, so there's no need for funky workarounds or security lifting. The Firefox implementation is at rev 0.5 or 0.6 about now, and it's definitely usable, but when it gets to 1.0 it will be really great for dynamic behavior.

There are other implementations as well, FormFaces, which is written entirely in JavaScript and is way cool, FormsPlayer for IE, with lots of advanced features and which is a plugin, not a native implementation (as in the Firefox one); X-Smiles, the open source standalone implementation from Finland, SolidApp, another OSS one with paid support for small devices (mobile phone vendors look here), PicoForms, also for embedded apps but not OSS, Orbeon, a complete back-end server solution incorporating XForms and pipelines. I'm sure there's more major implementations I've missed, and also partial ones as well.

If you want to know more check out the XForms FAQ and XForms or HTML authors Part 1 and Part 2.

Plus, Will Wheaton likes it.

Of course - MySQL doesn't do the things you expect them all the time, but it is really good at what it does. I have tried PostgreSQL and wasn't very satisfied with it - performance like a slug or something compared to what you can get out of MySQL. The command-line UI wasn't that easy to work with either.

And still - the major issue that is causing problems doing maintenance of a web site - that is the core code that actually does the whole thing. It doesn't depend on that it's written under Linux, that you are using Apache or MySQL, but the last letter - PHP/Perl/JSP/whatever. The best way around it is to don't use a scripting language at all but a compiling language and do Java Servlets utilizing Apache ECS or whatever your favourite language is.

Downside is that still ECS is lacking some features that I would like to see, but it helps on the way anyway. By also checking the result with the HTML Validator you will get the best result. (but maybe not the flashiest)

By using a compiling language you will ensure that end-users doesn't get nasty surprises if a change is done to a file that was included by a zillion of other files. Of course - you will still have a few problems left, but that is more of a documentation issue.

I believe you intended to leave a space before the trailing / and > of that empty element:

http://www.w3.org/TR/2001/WD-xslt20-20011220/#xhtm l-output

The point of the semantic web is to allow user agents to make these connections, rather than forcing/allowing any single server (application) to do it.

But, as I've brought up with them before, the site is full of wasted space. I even wrote them a tool to remove all that guff but was told (about 6 months ago) that they were working on the problem.

I only noticed it when I was parsing the thing for an new aggregator and found a big input file to output file sise diff. The XML parser was set to discard pointless whitespace.

Validator... http://validator.w3.org/check?uri=http%3A%2F%2Fnew s.bbc.co.uk%2F

---

Sometimes I feel like I'm repeating myself. Sometimes I feel like I'm repeating myself.

Abstract:
A common method of limiting access to services made available over the Web is visual verification of a bitmapped image. This presents a major problem to users who are blind, have low vision, or have a learning disability such as dyslexia. This document examines a number of potential solutions that allow systems to test for human users while preserving access by users with disabilities.

The purpose of CSS is not to make pages pretty. It's to make pages portable. That requires the CSS to validate against the standard! http://jigsaw.w3.org/css-validator/validator?profi le=css2&warning=2&uri=http%3A%2F%2Fslashdot.org%2F tmp%2Fslashdot_redesign%2F/

I bet they've got a website...and its backend uses SOAP.

• But why "charset=iso-8859-1"? Wouldn't UTF-8 give better World Language support?
• Why pngs and gifs?
• No behaviors?
• And it's a long time since I saw script without error trapping.

As with most things, it's not really that one package is "better" than another so much as that one might be more useful to you at any given time.

I use my own package when a Web site is smaller (say, below a million hits per month) because I would rather sample some actual sessions and see where people went and what they were searching for than get an overview. If you see people are searching for Argyle Socks and are finding your page about the Duke of Argyll, you might want to add an extra page and link to it, "if you were looking for...".

The statistic you most want is the things people looked for that might have reached your Web site and didn't, and that's the one you can't easily find!

For a site getting under 1,000 hits per day, look at the server logs in detail at least once a week, and make navigation easier, add more content where it looks promising, think about why some areas don't get traffic, etc etc.

When you're getting 10,000 hits/day, unless most of them are for graphics, the data can become overwhelming. And if you're over 100,000 hits per day you probably need to go to the sorts of reports that give you a very broad overview.

A link checker and a 404 report can be useful -- Cool URIs don't change!

Oh -- for anyone interested, although I do have hololog set up on for example my words and pictures from old books Web site (in a private directory, sorry), the sourceforge page doesn't have a download, mea culpa. If it looks useful to anyone I've shared copies of "hololog" in the past. It could do with some cleaning up, alas!

Liam

Empty file in vi: 0 bytes

Why not support the PNG file format (http://www.w3.org/Graphics/PNG/ - Portable Network Graphics? Note that PNG is never mentioned anywhere in the Windows Media Photo specification document. PNG is patent free, widely supported, uses lossless compression and supports most all of the features of the proposed WMPhoto format. I see no benefit of the WMPhoto format over PNG. The only benefit I see is for Microsoft to control the specification and sell software that supports it. It is yet another way that Microsoft is trying to monopolize the desktop and make everything be about Windows. They even put Windows in the format specification name. If they wanted it to be open, they would not have included that in the name. This pisses me off.

Unfortunately, J2k seems to be stuck, and since most browsers don't support it by default (even the upcoming IE7 and Opera 9), using this format on web is suicide.

<object data="tux.j2k">
<object data="tux.png">
[Picture of tux]
</object>
</object>

I admit I don't know whether IE 6 will handle that properly, though.

16-bit per channel PNG is part of the official W3C recommendation. I'm sure most user agents don't support it, but that's another matter.

I generally don't like all the new TLDs that tends to be created nowdays.
However, the .mobi-domain actually make sense, becase domain owners are required to comply
with the .mobi Styleguide.

Yes, that means content under the .mobi domain is more or less guaranteed to work on a mobile device. Sure, todays mobile devices have great web capabilities but they will never come close
to a normal computer when it comes to screen resolution.

The styleguide is avaiable at http://www.w3.org/TR/mobile-bp/
There is also a PDF avaiable at http://pc.mtld.mobi/documents/dotmobi%20--%20Switc h%20On!%20Web%20Browsing%20Style%20Guide.pdf

wow, that dailywireless.org site has a valid html logo, yet gives 1189 errors when validated.

Yes, you have to choose to view the video, but how in the world can you choose to not download it in the first place?

Maybe there's no truth in this, but people have told me that web pages can contain these things called "links" using which you can, for example, allow people to choose whether or not to download and view large files. I'm not sure if Google's engineers are aware of this technology, but if so they may well make use of it. Perhaps they can tie it in with their plan (described in TFA) to "...display graphics promoting video ads".

There is a W3C article, Why Using TLDs for Filtering is Ineffective, Harmful, and Unnecessary, that points out all the downfalls of creating a .xxx domain. This excerpt sums up why I am personally opposed to the idea:

"7. The definition of what is offensive obviously differs greatly from country to country, from year to year, and from person to person. If bare ankles are considered obscene in some cultures, but are permitted in photos of Web sites in France selling sandals, then individuals wishing to keep photos of bare ankles out of their home using filtering on ".xxx" are unlikely to succeed. How will sites about safe sex or AIDS be treated? Who will establish what is art and what is pornography?"

Also, having read these documents it appears to me that this whole thing is nothing but a land grab by ICM.

I used XML Query templates for a project recently (there are quite a few implementations of XQuery, both proprietary and open source).

I found that development was fast (although I already knew both XQuery and XML in general) and that once my XML Query expressions passed through the compiler (static type checking is your friend) they mostly worked first time, so that I had something working in an hour and a reasonably robust site within a day.

There's a page about the image search in particular at http://www.fromoldbooks.org/Search/about.html although it's fairly high level.

Using XML as an integration language, and either XQuery or XSLT to generate HTML where needed, really does help to enforce separation. An advantage of XQuery is that the implementations are getting pretty fast, and are beginning to use indexes for multiple files or database access.

Disclaimer: I work full-time for W3C, and we publish both XML and XQuery :-)

http://validator.w3.org/check?uri=http://www.micro soft.com/windowsvista/

Looks like they have a bit more work to do before they can roll out the Windows Vista [website]. :-)

In HTML, there are two types of hyphens: the plain hyphen and the soft hyphen. The plain hyphen should be interpreted by a user agent as just another character. The soft hyphen tells the user agent where a line break can occur.

Those browsers that interpret soft hyphens must observe the following semantics: If a line is broken at a soft hyphen, a hyphen character must be displayed at the end of the first line. If a line is not broken at a soft hyphen, the user agent must not display a hyphen character. For operations such as searching and sorting, the soft hyphen should always be ignored.

In HTML, the plain hyphen is represented by the "-" character (&#45; or &#x2D;). The soft hyphen is represented by the character entity reference &shy; (&#173; or &#xAD;)

Mozilla follows the semantics as specified. In fact, despite the fact that you may prefer MSIE's implementation, it is arguably incorrect given the ambiguous/conflicting specifications for the character and its semantics.

--MarkusQ

There are 4 valid content types for xhtml, one of which is text/html. Just because it won't be treated as xhtml anymore, doesn't mean its not a valid content type.

http://www.w3.org/TR/xhtml-media-types/

SMIL works just as well.

There's no way that's valid HTML.

Yes, it is. It just uses HTML syntax that virtually no browsers have implemented. This is what the HTML 4.01 specification has to say on the matter:

Some SGML SHORTTAG constructs save typing but add no expressive capability to the SGML application. Although these constructs technically introduce no ambiguity, they reduce the robustness of documents, especially when the language is enhanced to include new elements. Thus, while SHORTTAG constructs of SGML related to attributes are widely used and implemented, those related to elements are not. Documents that use them are conforming SGML documents, but are unlikely to work with many existing HTML tools.

Can you give us a list of 3rd party modules are uncompliant?

A PHP-based content manager my company used to work with, I don't recall its name unfortunately. Actinic catalog (validate their demonstration site here: http://validator.w3.org/check?verbose=1&uri=http%3 A%2F%2Fwww.premiumtyresonline.co.uk%2Facatalog%2Fs hop.html). I'm sure there are others, but I don't remember them right now. I find that *most* web applications generate URLs in links that contain unescaped ampersands. This works with all browsers, but is *not* valid HTML (at least according to the HMTL4 spec).

I have found meeting web standards, developing with CSS rather than tables and writing (hopefully) semantic HTML has made my development process far far more efficient and no slower than the table-based layouts and non-standards compliancy days of old.

Perhaps you could help me out here. I'm not a CSS expert by any means, but I currently have a requirement to implement a site that has three vertical columns, the leftmost and rightmost of which should be the smallest possible size to fit their variable content into and the central one should expand to fill the available space. I'd love to know how I can do this without a table, but I couldn't figure it out, and all the CSS layout tutorials I've been able to find will only do columns of predetermined width. Having wasted two hours on this fairly simple requirement now, I'm about to go back to using a table like I normally would.

Are you trying to prove or disprove the grandparent? :-)

Take a look at CSS counters, I believe this is what you should be doing instead:
http://www.w3.org/TR/CSS2/generate.html#counters