- From: Robin Berjon <robin@berjon.com>
- Date: Thu, 24 Sep 2009 15:21:29 +0200
- To: marcosc@opera.com
- Cc: public-webapps WG <public-webapps@w3.org>
On Sep 23, 2009, at 16:51 , Marcos Caceres wrote: >> But instead of ignored it says skipped — and it's not clear >> whether skipped has the same meaning. > > Good point. The second must not be processes because it is not the > first. It don't matter that is serviceable. It might just be that I > used ignore where skip was intended. That's not a very strong versioning approach. >> If the second element is not taken into account, then we have a >> potential >> problem with forward compatibility. Let's imagine that we have v2 >> out, for >> which the following is correct: >> >> <content uri='http://berjon.com/cool-widgets/dahut'/> >> <content src="perfectly-good-start-file.html"/> >> >> Clearly the desired behaviour is for v2 runtimes to process the >> first, and >> v1 runtimes to fallback to the second. > > IMO the correct behavior would be for src attributes to take URIs and > for the second to be skipped. However, I'm sure you can dream up other > examples. Yes, I can. > The "only ever use the first, even if b0rked" behavior is based on > HTML's behavior (particularly the <title> element). I'm happy to break > ranks with HTML parsing if that is what the WG thinks would be best. > However, it's a pretty big change to the parsing model, but if it > future proofs us, then it might be worth it. HTML has that behaviour to unify the mess that browsers are — there's a rationale there. We don't have to stick to the same thing because we really don't have that baggage. And thankfully this affects not at all the parsing model, but only processing — which is a lot easier. Furthermore I'm not convinced it's a change — we'd have to ask implementers which one they picked. >> The same issue applies to other elements that refer to the skip/ >> ignore >> distinction. We believe that some editorial improvements to those >> definitions would be welcome. > > Agreed. I'll work on improving those but that depends on if we change > the parsing behavior or not to match what you suggested above. The definitions need to be improved either way. I don't have a strong opinion as to whether the change should go through or not so long as it's clarified. The modification concerns cases that aren't all that common. I have a preference for the more versioning-friendly approach of just skipping (which is also slightly simpler to implement since you don't need to remember anything). But if it risks being considered substantial I don't want it. -- Robin Berjon - http://berjon.com/
Received on Thursday, 24 September 2009 13:22:06 UTC