W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: skipping and ignoring

From: Robin Berjon <robin@berjon.com>
Date: Thu, 24 Sep 2009 15:21:29 +0200
Cc: public-webapps WG <public-webapps@w3.org>
Message-Id: <C9E78754-F2DC-4350-92A6-BDAEF3D965D4@berjon.com>
To: marcosc@opera.com
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT