- From: Robin Berjon <robin@w3.org>
- Date: Mon, 03 Jun 2013 18:25:47 +0200
- To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
- CC: spec-prod@frink.w3.org
On 03/06/2013 17:10 , Henry S. Thompson wrote: > Robin Berjon writes: >> If that's the case, I'm afraid the only fix will be to switch to >> HTML (at least for the media type), because removing all uses of >> innerHTML would be a major undertaking. > > The fact that it works with specStatus="unofficial" suggests that your > use of innerHTML is pretty modest, so I have some hope . . . Well, yes and no. Our use of innerHTML intersected with the ReSpec features that your draft uses is relatively modest, but that's less the case across the full code base. We use innerHTML *directly* for at least: • Syntax highlighting • Markdown support • WebIDL processing • References (when they still use the old HTML-based form) • Saving generated documents (via the interface) I also have no idea how much the libraries we depend on use it; but clearly at least in the following cases: • Including and transforming external resources • Examples • Figures • Issues and Notes • ToC • SotD So yanking it is going to be hard at best. The strange thing is that the innerHTML-in-XHTML seems to trip things up in only *some* of the above uses. Which, and why, I don't know. Browsers are being pretty uncooperative in their error reporting. > I'll send you a private note as to where you can find the doc't, as > it's not ready for public viewing just yet. . . So I ran your document with the non-optimised build and I get the same results. I haven't been able to debug it fully but I believe that the problem boils down to this: when using specStatus=unofficial, the W3C logo is not prepended to the draft, whereas it is for all other modes. jQuery notices that there's an <img> in the template we're injecting, and it does something with it to handle the /> (I'm not exactly clear on what just yet) which browsers don't like in an XHTML context. That's as far as I'll get tonight — but to be honest I doubt that we can make this work with XHTML. The fact that you're the first to notice, for a script that's been in extensive use since 2009, should give you an idea of how common using XHTML is, even in this community. Note that this does *not* prevent you from creating your documents as XHTML, editing them with XML tools, etc. It's only a problem if they then get served as such. Is that an issue? If it is a problem, I can try to dig to see if there's a workaround for you. But I won't ever be able to make it work across the board, only perhaps (and it's a big perhaps) for the basic features that you're currently using. As far as I can tell at this point it would involve patching jQuery to notice that it's being used in XHTML, or at least do something that mucks with its internals. -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Monday, 3 June 2013 16:25:55 UTC