- From: Robin Berjon <robin.berjon@expway.fr>
- Date: Wed, 11 Jan 2006 15:38:58 +0100
- To: thomas.deweese@kodak.com
- Cc: www-svg@w3.org
On Jan 11, 2006, at 14:53, thomas.deweese@kodak.com wrote: > I personally can't believe the WG has made this change. It > means that > no compliant > renderer can inform users that they have made a mistake because of > course > they haven't > they have simply indicated to the UA to ignore the value of the > attribute. It isn't the job of a renderer to inform users of errors in the content. That's the job of compliance verifying tools. UAs aren't things that are made for developers, they're made for users. Users don't care, and they shouldn't. > Well, if we didn't have 'tag soup' before it will now quickly > proliferate. With the strict rules in previous specs we already have relative tag soup. It's clearly not a strategy to get vendors to cooperate. But neither of the above are the most important reason for considering that the halt and catch fire approach of 1.1 was wrong, and needs changing. The major problem it has is versioning, and deployment of content using new versions. If you want to create content that uses features from a new version but will degrade reasonably well to older versions the only approach defined by 1.1 is to use switch. This is impractical at best, and experience shows that authors simply don't use it. Switch does have its uses, but wrapping everything in a conditional is hardly better than testing navigator make and version in scripts as used to be done in HTML. This new approach means that deploying new content is much more straightforward. If you want the previous B&D approach, it's still available by setting the version attribute. No functionality is lost, we've just taken reality's feedback into account. Incidentally, the TAG's work on versioning concurs that the MustIgnore strategy in vocabulary design is sound. It's also in line with strategies adopted by other WGs for their vocabularies. > Implementations are now free to add what ever new attributes & > elements they want without having to do anything pesky like indicate > that they are a proprietary extension by adding a namespace prefix, > safe in the knowledge that their competitors will ignore them with > no-one allowed to provide an embarrassing error message pointing out > that element 'foo' is really not part of SVG. SVG is now ripe for > embrace and extend. We didn't exactly get freedom from proprietary extensions with the strict approach. A spec can't stop vendors being stupid. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Received on Wednesday, 11 January 2006 14:40:03 UTC