- From: Ryan Cannon <ryan@ryancannon.com>
- Date: Wed, 12 Jan 2005 08:45:18 -0500
- To: fantasai <fantasai.lists@inkedblade.net>, www-style@w3.org
fantasai wrote: > > David Woolley wrote: > >>> Hi there, I've got something for the CSS3 'ideas' pile. >> >> >> Variations on this get proposed every two or three months. The >> new feature in yours is the !required, but that isn't really needed >> if you have an all or nothing grouping, and isn't particularly useful >> without that grouping. >> >> I don't know why it hasn't been accepted, although a possible reason is >> that it is unrealistic to expect browser developers to make conservative >> claims of compliance and fixing such claims made in error are likely >> to get very low priorities in the change control systems of commercial >> browser developers. Liberal interpretation of specification compliance >> is second nature to marketing departments. > > > For the particular proposal here, that wouldn't be a problem: you can > define > it such that if the browser will not parse and store the value in the > cascade, > then it must ignore all other declarations in the same !required group. > Accepting the value into the cascade implies that the UA understands > and can > handle the value, even if support is not perfectly spec-compliant by > Hixie's > standards. This level of compliance claim already exists; the proposal > merely > hooks into it. And it does so in a way that's technically > implementable at > parse time; several of the other proposals require changes in the > cascade. > > ~fantasai > I'm not sure I agree. If this does get implemented we will still run into problems, as some browsers will, intentionally or not, mis-report their own status. Combine this with a situtation similar to that of HTML's button element--where one popular browser has implemented a non-standard behavior, rendering the element nearly useless for its inteded purpose. I agree that some sort of support-based statement binding would be lovely, but I'm wondering if this might be more reliably implemented another way. Ryan Cannon
Received on Wednesday, 12 January 2005 13:45:25 UTC