Re: block-based parsing?

Anne van Kesteren wrote:
> Quoting Orion Adrian <>:
>> Browsers can't be trusted to accurately say what features they do and
>> don't support. So they may say they support a feature and go ahead
>> with the properties in the block, but it won't in reality support it
>> and you'll end up with a mess.
> Without a testcase for every possible situation browsers will never 
> know. So
> yes, you will likely end up with a mess. Same mess as the hasFeature DOM 
> method
> is now...

Then it stands to reason, if the UA can't be trusted to tell the truth 
about what it supports, then the solution must be an independent 
third-party that can be trusted to tell the truth via a flat-text file 
similar to DTDs.  If the browser supports something like @required, then 
a third-party organization, such as the W3 will provide non-biased data 
about that browser's support of the feature in question.  But it'd also 
have to be more than a simple boolean response.  It'd have to be 
multi-tiered to accommodate partial support and incorrect support, 
perhaps based on the selector.

Just thinking out loud, I'm sure the browsers won't be very accepting of 
yet another bureaucracy, and who is going to trust someone else to come 
up with the correct data?  Maybe it doesn't need to be limited to one 
organization or be a third-party at all.  The browser can provide their 
own, but it be possible to provide a custom support file to override it.

Richard York

Mail_IMAP: A PHP/C-Client/PEAR solution for webmail
Author: Beginning CSS: Cascading Style Sheets For Web Design

Received on Thursday, 15 September 2005 14:29:14 UTC