- From: Jon Ferraiolo <jon.ferraiolo@adobe.com>
- Date: Mon, 23 May 2005 07:05:34 -0700
- To: Bjoern Hoehrmann <derhoermi@gmx.net>, Robin Berjon <robin.berjon@expway.fr>
- Cc: www-svg@w3.org
At 04:40 PM 5/22/2005, Bjoern Hoehrmann wrote: >* Robin Berjon wrote: > >> From http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/svgudom.html > >> section A.2.7 "The result of getting and setting text content via the > >> #text mechanism is exactly the same as when using the textContent > >> attribute." This means that this feature is redundant. Please either > >> explain in detail why it is not redundant and give advice as to when > >> which of these methods should be used or remove the feature from the > >> draft to easy implementation, testing, etc. > > > >This is a case in which we've had to concede to redundancy in order to > >obtain compatibility. The #text trait is what is defined in JSR-226, and > >textContent is the field inherited from DOM 3 Core — we have resolved to > >support both as we wish to be compatible with both. > > > >If you are using the uDOM and don't intend to be compatible with JSR-226 > >(either because you're already using features not present there, or > >because you're not using Java), then the recommended one is textContent. > >In all other situations, #text is best. > >This does not satisfy me, at the very least this clarification should be >added to the draft. The #text trait is not defined in JSR-226 as far as >I can tell, it's only noted in the support table where it is only >supported for text elements and not for tspan (which is not supported at >all, it seems), desc, title, metadata, etc. So there is basically no >compatibility here that could be gained. Bjoern, Perhaps the JSR-226 specification could have been more explicit about #text beyond just listing it in a table, and perhaps #text was a bad decision, but nevertheless: * #text is clearly a part of JSR-226 * It therefore represents a backwards compatibility issue for the several companies (including Nokia and Sun, just to mention a couple, there are others also) who have existing JSR-226 implementations and who also want to support SVG-t 1.2 down the road. My understanding is that the spec for JSR-226 is all done (i.e., all review periods have passed months ago) and, as I mentioned earlier, there are commercial implementations that are either shipping on phones today or will be shipping on phones shortly (but nevertheless it is way too late to consider software changes). * For better or worse, #text was agreed to after lengthy (and sometimes painful) coordination discussions between the JSR-226 Expert Group within the Java Community Process and the SVG Working Group within the W3C. Formally, it is defined within a JCP spec and thus the decision about #text was a JCP decision, not a W3C decision, but the coordination agreement was that the JCP would do its best to maintain compatibility with existing SVG Recomemendations and the W3C would do its best to make SVG-t 1.2 upwards compatible with JSR-226. I was certainly aware of #text at the time these coordination activities occurred and I expect so was everyone else on both side (JCP and W3C). >There are also many other incompatibilities, the clarifications for >SVGElement.id for example are not in JSR-226 and it uses confusing >legacy methods like addEventListener which are not added to SVG Tiny 1.2 >either, so there is virtually nothing to be gained here. If JSR-226 uses addEventListener, then I would say that SVG-t 1.2 needs to support it also. Probably the same thing for any other incompatibilities -- if it is in JSR-226, we need to include it in SVG-t 1.2. >Please >coordinate with the Expert Group instead of having such legacy methods >and incompatibilities. Clearly the Working Group made them aware that >it is inappropriate to cite SVG Tiny 1.2 as other than work in progress, >so this should not be a problem at all. My understanding is that it is much too late to change JSR-226. Note that JCP is a different organization than W3C and that JCP has a different process than W3C. The only reason that JSR-226 and SVG-t 1.2 are compatible at all was because the JCP and W3C members agreed that it was best for the world to coordinate and achieve as much compatibility as possible. But that's it. The W3C has no formal control over JSR-226 and it is highly unlikely that the companies who worked so hard to define JSR-226 and who have developed commercial implementations will decide to change their mind on #text at this point, especially since it is so easy to just include it in SVG-t 1.2. Jon >-- >Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de >Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de >68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Monday, 23 May 2005 19:25:39 UTC