The Omni Group Forums

The Omni Group Forums (http://forums.omnigroup.com/index.php)
-   OmniWeb Bug Reports (http://forums.omnigroup.com/forumdisplay.php?f=27)
-   -   Browsers: working on CSS 3, but still lack HTML 4 (http://forums.omnigroup.com/showthread.php?t=1459)

Bob Williams 2006-08-21 02:12 PM

Browsers: working on CSS 3, but still lack HTML 4
 
Over the past several years, I've noted that most browsers were really slow to pick up the new features that HTML 4 added to the HTML standard... features like data grouping in tables (which can save a [I]ton[/I] of markup, and is extremely helpful in building accessible web sites). I've wanted to use these features a number of times, but after doing so then having to redesign for lack of support one too many times, I finally gave up and pretty much washed that knowledge out of my head.

Yesterday, however, I found myself on the browser text page at the iCab site, where I was reminded of some of the great unimplemented features. A quick check of OW shows that even as of 5.5b3, there still remain gaps. Interestingly, Firefox seems to do okay now--they must have beefed up their HTML support in recent versions.

So my question is: what happened? With nearly every browser claiming full support of HTML 4, why is it major ones in fact don't support major features of the standard? It's like they supported 3.2 then called it quits on the v4 features, and no one noticed in the buzz surrounding CSS.

Is there any chance OW (Web Kit) will ever be able to pass a simple HTML test like that on the iCab site?

To see the page, go here:

[URL="http://www.icab.de/test.html"]http://www.icab.de/test.html[/URL]

(BTW, something that isn't tested on that page is allowing the user to click on a form control's label and have it act like a click on the control itself. This is especially important in a Mac browser, since Mac-native controls have always worked this way. And yet, it's rarely implemented.)

Forrest 2006-08-21 02:40 PM

I think some of it may have to do with HTML being depreciated and some of that not being valid XHTML. And another issue might be that some of the "features" used on that page, are common mistakes when HTML is used. It seems like if browsers rendered that code correctly, many sites would be displayed incorrectly.

Bob Williams 2006-08-21 04:26 PM

[QUOTE=Forrest]I think some of it may have to do with HTML being depreciated and some of that not being valid XHTML.[/QUOTE]

HTML 4, along with XML, is the basis for XHTML, so really, HTML is dead, but long live HTML.

As for that particular code not being valid XHTML, why would it be? The doctype on the page is HTML 4. Any browser should render the page properly according to the HTML 4 spec.

That said, there were a couple of minor issues with the page. Nothing that caught the eye of the W3C validator, but issues nonetheless--and enough to push Firefox into quirks mode. I've fixed them, converted the page to XHTML 1.0 Transitional, and posted it here:

<[URL="http://members.cox.net/bobwilliams/htmltest.xhtml"]http://members.cox.net/bobwilliams/htmltest.xhtml[/URL]>

Results: no change.

[QUOTE]And another issue might be that some of the "features" used on that page, are common mistakes when HTML is used. It seems like if browsers rendered that code correctly, many sites would be displayed incorrectly.[/QUOTE]

Like what, specifically? In fact, some of these features, like table data grouping, are extremely important for accessibility (and very useful in other ways), and they're most definitely not mistakes. Actually, you'll rarely see some of these things on sites at all because 1) very few sites use HTML/XHTML semantically, and 2) most folks use WYSIWYG editors to generate HTML, and these editors don't support these sort of high-level semantic features. Were HTML used properly, and were people to actually compose it by hand and care about things like accessibility, you'd see a lot more of these things in common use.

BTW, while I was modifying the page, I added an example of form controls that should have clickable labels. iCab gets it right, as does Firefox, but the WebKit browsers don't.

Forrest 2006-08-21 04:55 PM

I'm saying, why go back and support a dead standard?

[QUOTE=Bob Williams]Like what, specifically?[/QUOTE]

I just took a quick look at it, but things like <td><td>. I've mucked through a lot of bad code that was written just poorly enough to work in IE. Really the author wanted <td></td> or <td></td><td>. If other browser display this as the code is written, then many sites would be broken in those browsers.

On the note about click on the text next to a form element, I have noticed that the apple store has this working with WebKit. I haven't looked to see how they did it, however. I've also noticed IE does this too on some MS sites. I'm guessing neither of them are standard.

Bob Williams 2006-08-21 05:27 PM

[QUOTE=Forrest]I'm saying, why go back and support a dead standard?[/QUOTE]

Primarily because the issues the page illustrates are part of XHTML, as well (as demonstrated by my own version of the page).

As for supporting HTML properly, it would be a big violation of the original spirit of the web if browsers stopped rendering pages simply because they weren't composed with the latest and greatest standards. Non-standard pages, sure, but any page compliant with a standard should be rendered for the sake of data integrity. For example, I have plenty of pages comprised of HTML 2.0 and the like, and I want these to work.

[QUOTE]I just took a quick look at it, but things like <td><td>. I've mucked through a lot of bad code that was written just poorly enough to work in IE. Really the author wanted <td></td> or <td></td><td>. If other browser display this as the code is written, then many sites would be broken in those browsers.[/QUOTE]

No. In HTML 4, that is perfectly well-formed--and very common--code, and its use has nothing at all to do with IE. Basically, certain closing tags are optional, since their placement can be deterministically calculated by the rendering engine. Another example of such a tag is the <p> tag, which in older pages could often be found on its own between paragraphs, as though it were a paragraph break tag; this use makes no sense semantically, but it's definitely valid (well-formed) and even now in widespread use.

Implicitly closed tags, however are [I]not[/I] valid XHTML, since the XML part of XHTML's lineage requires that all tags be balanced.

If you want to see the same page in XHTML without implicitly closed tags, then take a look at the version I posted.

[QUOTE]On the note about click on the text next to a form element, I have noticed that the apple store has this working with WebKit. I haven't looked to see how they did it, however. I've also noticed IE does this too on some MS sites. I'm guessing neither of them are standard.[/QUOTE]

It can be done with JavaScript, but the (X)HTML standard itself has for years included markup to enable this. We just need browsers to support it - and the fact that Apple and MS themselves are implementing workarounds demonstrates just how badly it's needed. (Along with being a usability issue, this is also an essential accessibility issue.)


All times are GMT -8. The time now is 12:32 AM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2020, vBulletin Solutions, Inc.