From 509f516bdefd3048e024328ac24978400b839980 Mon Sep 17 00:00:00 2001 From: Bruce Anderson Date: Mon, 17 Apr 2023 20:05:26 -0400 Subject: [PATCH] 0.0.3 --- README.md | 12 ++---------- xslt.js | 1 - xslt.ts | 1 - 3 files changed, 2 insertions(+), 12 deletions(-) diff --git a/README.md b/README.md index 9f9b36d..f277a2e 100644 --- a/README.md +++ b/README.md @@ -124,17 +124,9 @@ Since by default the decorator acts on the previous element, that becomes a prob ``` ->**Note**: When it comes to XSLT, it seems that the common lineage shared between Chrome and WebKit almost guarantees that the XSLT engines will produce identical results. Not so with Firefox. With Firefox (and the other two) this works, which seems like a hack: +>**Note**: When it comes to XSLT, it seems that the common lineage shared between Chrome and WebKit almost guarantees that the XSLT engines will produce identical results. Not so with Firefox. So although we should always include Firefox in our tests, that is even more the case when using XSLT. + -```html - -``` diff --git a/xslt.js b/xslt.js index 7f3cb84..428ee31 100644 --- a/xslt.js +++ b/xslt.js @@ -6,7 +6,6 @@ export async function xslt(xsltProcessor, realmToSurvey, derivedVals) { outer.appendChild(xmlSrc); xmlSrc = outer; } - console.log(xmlSrc.outerHTML); const { swap } = await import('trans-render/xslt/swap.js'); swap(xmlSrc, true); const resultDocument = xsltProcessor.transformToFragment(xmlSrc, document); diff --git a/xslt.ts b/xslt.ts index 0bccefe..b4dba71 100644 --- a/xslt.ts +++ b/xslt.ts @@ -6,7 +6,6 @@ export async function xslt(xsltProcessor: XSLTProcessor, realmToSurvey: Element, outer.appendChild(xmlSrc); xmlSrc = outer; } - console.log(xmlSrc.outerHTML); const {swap} = await import('trans-render/xslt/swap.js'); swap(xmlSrc, true); const resultDocument = xsltProcessor.transformToFragment(xmlSrc, document);