Quirks and strict mode; validation drive and <code><wbr /></code>

I just updated the Quirks mode and strict mode page. I added a bit about the "almost strict mode" and test pages for font sizes in TDs.

I also found one new problem in the validation drive: most of my large compatibility tables liberally use the <wbr /> tag, which is invalid. I acknowledge the problem, I will note it in the validation texts, I will remove all other validation errors, but right now I'm not going to do anything more.

Like custom attributes, the <wbr /> tag requires some more thought. As my research shows, this tag is the least bad alternative for adding soft word breaks to pages; and the compatibility tables badly need soft word breaks.

Comments

1 Posted by Anne on 29 June 2005 | Permalink

There: http://www.cs.tut.fi/~jkorpela/html/my401.dtd

2 Posted by Flo on 29 June 2005 | Permalink

However, don't forget this:
"For reasons of interoperability, authors must not "extend" HTML through the available SGML mechanisms (e.g., extending the DTD, adding a new set of entity definitions, etc.)."

http://www.w3.org/TR/html401/appendix/notes.html#h-B.1

3 Posted by John Hansen on 29 June 2005 | Permalink

I know it's not the cleanest solution, but instead of using , maybe use a fixed-width font for your compatibility tables and use javascript to insert word breaks where necessary.. I'm sure there's a better way though.

4 Posted by John Hansen on 29 June 2005 | Permalink

*instead of using the wbr tag

5 Posted by Joost Diepenmaat on 29 June 2005 | Permalink

Dit you see this solution? Seems reasonably elegant to me:
http://www.matsblog.com/stories/778902/

6 Posted by Alex Lein on 29 June 2005 | Permalink

that could be far more elegant.

.wbr {
width: 0px; /* needs the px to validate */
font-size: 1px;
font-size: 0px; /* doubled up for browsers that support the 0px font-size */
}

then in html you'd have ahugewordthat needsawbrtaginit somewhere.

7 Posted by Joost Diepenmaat on 30 June 2005 | Permalink

I just realized there is a problem with the solution I referred to: it won't work correctly on browsers that don't support css (or variable fonts), like most text-browsers. It will show a space instead. You would need a tag that is supported by all browsers and always hides its content.

8 Posted by Philip Hazelden on 30 June 2005 | Permalink

Why go to so much effort? Just use WBR with the Opera thing. It won't break future compatibility (the W3C will never implement a different version), and works in almost all browsers with no bugs (I just tested Links and Elinks: the SPAN solution shows the spaces, 8203 gives a glyph like IE, and the others don't do anything). Hacks can be acceptable if they improve functionality, but when they increase rendering and download time for validity's sake, they aren't. Code to what the standards stand for rather than what they say.

9 Posted by Joost Diepenmaat on 1 July 2005 | Permalink

I'm inclined to go with Philip Hazelden on this one for *HTML*. I don't think a useful* replacement for the <wbr> tag can be found, so just use the defacto standard. For XHTML, however, you can (and probably will) run into problems when you start serving xhtml pages as xml (instead of text/html) and you probably should use the &#shy; element, and hope for the best - it seems to be the right thing for the job.

* useful as in: works in at least all the browsers that wbr does *and* is standards compliant.

10 Posted by Anne on 2 July 2005 | Permalink

In all browsers that currently have an implementation of XHTML the implementation of HTML and XHTML is interchangeable. (That excludes IE obviously, as it doesn’t have a native implementation of XHTML.) So using the WBR element in whatever type of document is not likely to cause any serious trouble. It might be ignored, o well.

Alex Lein, a unit is never required for “nothing” in CSS. So what you state there is nonsense.

Quirks and strict mode; validation drive and <wbr />

Comments

Quirks and strict mode; validation drive and `<wbr />`