- From: Richard York <richy@smilingsouls.net>
- Date: Thu, 15 Sep 2005 09:29:01 -0500
- To: www-style@w3.org
- CC: Anne van Kesteren <fora@annevankesteren.nl>
Anne van Kesteren wrote: > > Quoting Orion Adrian <orion.adrian@gmail.com>: > >> 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. Regards, Richard York -- Mail_IMAP: A PHP/C-Client/PEAR solution for webmail Author: Beginning CSS: Cascading Style Sheets For Web Design http://www.richard-york.com
Received on Thursday, 15 September 2005 14:29:14 UTC