- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 14 Jul 2004 10:09:09 +0000 (UTC)
- To: Dean Jackson <dean@w3.org>
- Cc: Chris Lilley <chris@w3.org>, Jim Ley <jim@jibbering.com>, www-svg@w3.org
On Wed, 14 Jul 2004, Dean Jackson wrote: >> >> If a UA finds XLink attributes on an SVG-namespaced element and those >> attributes are not allowed per the SVG DTD, should the UA consider the >> element to be in error or not? If not, should the UA just ignore the >> attributes, or should it attempt to apply XLink semantics to the element? > > You propose three choices: > > 1. element in error > 2. ignore > 3. apply xlink > > I'm against 2. I'm not sure which of 3 or 1 is better, but both have > problems. Especially on Mobile which won't have an xlink processor and > usually is unable to test for incorrect unknown attributes (so can't do > 1 either). > > What do you suggest? I don't mind either way, so long as it is defined so I can write tests for it. The best way would be to take the relevant tests in the SVG test suite (assuming you have some -- if you don't make some) and then check what the majority of UAs do, and codify that. I highly doubt that most UAs actually implemented XLink. So I doubt 3 will be common. Given how poorly the SVG error handling rules have been implemented, I also doubt that they cause the document to abort processing. So I doubt 1 will be common either. Thus I would guess that the most common behaviour would be 2. This is a violation of XLink, of course, but as you said, with hindsight XLink was probably not a good idea for SVG. The HTML/CSS error handling mindset is to ignore errors and pretend they never happened, so if we're not to apply the XLink semantics, then I would ignore the attributes. But like I said. I don't mind either way, just so long as I know what should happen so I can test it! :-) Cheers, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 14 July 2004 06:09:14 UTC