- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 9 Jan 2007 13:37:37 -0800
- To: "Cyril Concolato" <cyril.concolato@enst.fr>
- Cc: "WAF WG (public)" <public-appformats@w3.org>
On 1/9/07, Cyril Concolato <cyril.concolato@enst.fr> wrote: > >>> In Section 3.3 "Loading Style sheets", the specification says >>> contradictory things: if non-XML stylesheet contains XML, it's in error, >>> but it still needs to be processed: What is the meaning of error ? > > In the spec, in 99% of the case, when something is in error, it is ignored. > I found few exceptions: script are evaluated and the case of non-XML > stylesheet. This seems to me really weird. The actual model used by the spec is this: The implementation follows an algorithm for each part of the processing model. That algorithm doesn't consider error cases. So for example, it takes the first <template> element, or it takes all the valid tokens in an xbl:attr="" attribute, or it executes any <script> elements it finds, etc. Things that don't make sense are ignored. In this case, the algorithm is "collect all the text nodes". The nodes that don't make sense -- comments and elements -- are ignored. > Plus, I think it's wrong practice > to specify a behavior in case of error, because people will then design > erroneous content just to get the 'weird' behavior. HTML on the Web today is ample evidence that not specifying error handling behaviour doesn't prevent people from depending on error handling behaviour (over 90% of all HTML documents depend on error handling behaviour in browsers today, according to a survey of over a billion documents that I did a few months back). Given that content is going to rely on error handling behaviour regardless of what the spec says, we have a choice: either error-handling behaviour is de-jure, described by the spec, and under our control, or it is de-facto, and browsers have to reverse-engineer each other, making the error handling rules a moving target with no "correct" answer. The latter model is what led us to having to write Tag Soup processors. -- Ian Hickson
Received on Tuesday, 9 January 2007 21:37:48 UTC