Karl, I fear that, even if you get this working, as Greg mentioned earlier, if
any module sends even the smallest error which causes the content not to
strictly validate-- like an open quote which doesn't close at the end of a
verse, that the browser may drop out of XHTML mode. I do find it odd that
lenient HTML mode is extra forgiving, and yet doesn't forgive a valid XHTML
tag. Not sure who decided on that logic but we have to work with what we've
got, so we can target perfection and make all things work in XHTML or we can
assume non-perfection (which, sadly I fear there are likely many places in our
modules which don't have perfect markup) and change the self-closing div. I
think we should probably do both: shoot for perfection, but avoid the one thing
which seems to trip non-perfection mode. I'll try to have something out this
weekend for you.
On April 18, 2020 5:09:29 AM MST, Karl Kleinpaste <k...@kleinpaste.org> wrote:
>On 4/17/20 11:43 AM, Greg Hellings wrote:
>> the HTML WG suggests, and apparently all browsers implement, ignoring
>> those directives and instaead caring only about the Content-Type
>> header/directive. So if you have that header/directive in Xiphos,
>then
>> try updating that to the appropriate "application/xhtml+xml" and see
>> if that fixes Xiphos/WebKit's behavior?
>As I showed in my original note on this, the opening stanza includes
>
><meta http-equiv=\"content-type\" content=\"application/xhtml+xml;
>charset=utf-8\">
>
>and it doesn't help. On a whim, I tried Content-Type in the event a
>case-sensitive match was required, but that didn't help, either.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
