The Omni Group
These forums are now read-only. Please visit our new forums to participate in discussion. A new account will be required to post in the new forums. For more info on the switch, see this post. Thank you!

Go Back   The Omni Group Forums > OmniWeb > OmniWeb Bug Reports
FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
Browsers: working on CSS 3, but still lack HTML 4 Thread Tools Search this Thread Display Modes
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 ton 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:

http://www.icab.de/test.html

(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.)
 
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.
 
Quote:
Originally Posted by Forrest
I think some of it may have to do with HTML being depreciated and some of that not being valid XHTML.
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:

<http://members.cox.net/bobwilliams/htmltest.xhtml>

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.
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.
 
I'm saying, why go back and support a dead standard?

Quote:
Originally Posted by Bob Williams
Like what, specifically?
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.
 
Quote:
Originally Posted by Forrest
I'm saying, why go back and support a dead standard?
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.
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 not 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.
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.)
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
Working around lack of tags for projects joshfree Applying OmniFocus 6 2013-02-08 01:12 PM
Dynamic HTML not working GreenFlowers OmniOutliner 3 for Mac 2 2010-10-28 04:04 PM
OW renders a site different from other browsers John Stalberg OmniWeb Bug Reports 2 2007-04-16 08:45 AM
zoom window behavior vs. other browsers FredH OmniWeb General 4 2006-12-06 08:59 PM
View in other browsers jimlongo OmniWeb Feature Requests 2 2006-09-29 12:32 PM


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


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