Re: [sword-devel] trying to get proper xhtml to work in webkit

[Karl Kleinpaste]

On 4/18/20 11:28 PM, Troy A. Griffitts wrote:
> I hope this fixes the issue for you.
Thank you, yes, that does it. I've committed a re-work patch of Xiphos'
handling of intro material on that basis.
Of course, this means I'm committed, I can't release a new Xiphos now
without a preceding or concurrent Sword release...
___
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

Re: [sword-devel] trying to get proper xhtml to work in webkit

[Troy A. Griffitts]

OK Karl,

I've committed a fix for this.  We handle a bunch of OSIS div types
specifically, but we weren't handling type="introduction" which is what
the ESV used, so the div was simply passed thru.  I'm now checking div
types we don't handle and if they are trojan milestones (they include
sID and eID) I convert them to start tags and end tags respectively.  I
hope this fixes the issue for you.

Troy

On 4/18/20 4:19 PM, Karl Kleinpaste wrote:
> On 4/18/20 6:32 PM, Caleb Maclennan wrote:
>> ESV modules have been pulled from every public SWORD repository
> Uh-huh.
> Do you suppose that there aren't several tens of thousands of people
> who still have it, including Troy?
>
> ___
> 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
___
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

Re: [sword-devel] trying to get proper xhtml to work in webkit

[Karl Kleinpaste]

On 4/18/20 6:32 PM, Caleb Maclennan wrote:
> ESV modules have been pulled from every public SWORD repository
Uh-huh.
Do you suppose that there aren't several tens of thousands of people who
still have it, including Troy?
___
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

Re: [sword-devel] trying to get proper xhtml to work in webkit

[Caleb Maclennan]

On Sun, Apr 19, 2020 at 1:27 AM Karl Kleinpaste  wrote:

> On 4/18/20 5:25 PM, Troy A. Griffitts wrote:
>
> Do you have a module and entry key value I can use for testing?
>
> ESV2011, intro commentary paragraphs at every book's 1:1.
>

The ESV modules have been pulled from every public SWORD repository that I
know of.
___
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

Re: [sword-devel] trying to get proper xhtml to work in webkit

[Karl Kleinpaste]

On 4/18/20 5:25 PM, Troy A. Griffitts wrote:
>
> Do you have a module and entry key value I can use for testing?
>
ESV2011, intro commentary paragraphs at every book's 1:1.
___
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

Re: [sword-devel] trying to get proper xhtml to work in webkit

[Troy A. Griffitts]

Hey Karl,

Do you have a module and entry key value I can use for testing?

Troy


On 4/18/20 2:10 PM, Karl Kleinpaste wrote:
> On 4/18/20 2:48 PM, Greg Hellings wrote:
>> This is the HTML header. Not the HTTP header.
>
> I had thought that's what the  content=\"application/xhtml+xml; charset=utf-8\">was supposed to give
> me, for the case of a directly-loaded text blob that didn't arrive via
> HTTP. Apparently not.
>
>> For manually loading the text you don't have an HTTP header, but you
>> still tell the widget what content type when you call
>> wk_html_open_stream or webkit_web_view_load_string or similar
>> functions. It's this value that is telling Webkit what to do.
>
> 
>
> It hadn't occurred to me that this was done other than in the header
> directives as I began to fill the widget.
>
> Unfortunately, still no joy. There are 6 occurrences of "text/html" in
> 3 files that do webkit widget loading:
> src/editor/editor.c
> src/editor/webkit_editor.c
> src/webkit/wk-html.c
> And the one that is immediately relevant is of course the last, which
> has 1 of the 6. Changing them all from "text/html" to
> "application/xhtml+xml" had precisely zero effect. The self-closing
>  still makes my .introMaterial bleed through to the end of the
> chapter.
>
> I can't win. Sorry. I think I'm done with this exercise in madness.
>
> For the record, this is the patch that restores -non-destructive
> behavior, with which I've been testing all these variants. The 
> is gone, all the other  and DOCTYPE are gone, all that's added
> is the namespace spec, plus the code change proper that simply pastes
> the engine's returned content into the widget, rather than engaging
> the  wiping.
>
> Ohwell. I tried.
>
> --- src/main/display.cc    2020-04-18 16:39:59.743635867 -0400
> +++ ../databits/display.cc.FAIL    2020-04-18 16:44:35.607215035 -0400
> @@ -89,7 +89,7 @@
>  N_("This module has no content at this
> point.");
>  
>  #define HTML_START \
> -    " content=\"text/html; charset=utf-8\"> \
> +    "http://www.w3.org/1999/xhtml\";> \
>  

Re: [sword-devel] trying to get proper xhtml to work in webkit

[Karl Kleinpaste]

On 4/18/20 2:48 PM, Greg Hellings wrote:
> This is the HTML header. Not the HTTP header.

I had thought that's what the was supposed to give
me, for the case of a directly-loaded text blob that didn't arrive via
HTTP. Apparently not.

> For manually loading the text you don't have an HTTP header, but you
> still tell the widget what content type when you call
> wk_html_open_stream or webkit_web_view_load_string or similar
> functions. It's this value that is telling Webkit what to do.



It hadn't occurred to me that this was done other than in the header
directives as I began to fill the widget.

Unfortunately, still no joy. There are 6 occurrences of "text/html" in 3
files that do webkit widget loading:
src/editor/editor.c
src/editor/webkit_editor.c
src/webkit/wk-html.c
And the one that is immediately relevant is of course the last, which
has 1 of the 6. Changing them all from "text/html" to
"application/xhtml+xml" had precisely zero effect. The self-closing
 still makes my .introMaterial bleed through to the end of the chapter.

I can't win. Sorry. I think I'm done with this exercise in madness.

For the record, this is the patch that restores -non-destructive
behavior, with which I've been testing all these variants. The  is
gone, all the other  and DOCTYPE are gone, all that's added is the
namespace spec, plus the code change proper that simply pastes the
engine's returned content into the widget, rather than engaging the
 wiping.

Ohwell. I tried.

--- src/main/display.cc    2020-04-18 16:39:59.743635867 -0400
+++ ../databits/display.cc.FAIL    2020-04-18 16:44:35.607215035 -0400
@@ -89,7 +89,7 @@
 N_("This module has no content at this
point.");
 
 #define HTML_START \
-    " \
+    "http://www.w3.org/1999/xhtml\";> \
 

Re: [sword-devel] trying to get proper xhtml to work in webkit

[Greg Hellings]

On Sat, Apr 18, 2020, 07:09 Karl Kleinpaste  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
>
>  charset=utf-8\">
>

This is the HTML header. Not the HTTP header.

For manually loading the text you don't have an HTTP header, but you still
tell the widget what content type when you call wk_html_open_stream or
webkit_web_view_load_string or similar functions. It's this value that is
telling Webkit what to do.

--Greg

>
> 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.
>
___
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

Re: [sword-devel] trying to get proper xhtml to work in webkit

[Troy A. Griffitts]

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  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
>
>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

Re: [sword-devel] trying to get proper xhtml to work in webkit

[Karl Kleinpaste]

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



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.
___
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

Re: [sword-devel] trying to get proper xhtml to work in webkit

[Greg Hellings]

On Fri, Apr 17, 2020 at 6:33 AM Karl Kleinpaste  wrote:

> On 4/16/20 11:08 PM, Greg Hellings wrote:
>
>  will give you HTML 5, not XHTML. XHTML would be much
> wordier:
> https://en.wikipedia.org/wiki/Document_type_declaration#XHTML_Basic_DTDs
>
>
> Well... That link itself says:
>
> In XHTML5  the DOCTYPE must be a
> case-sensitive match of the string "".
>
> So I'm already confused. Didn't take much, huh?
>
> - begins with  line
>>
>
> Doesn't seem to be strictly needed by browsers for XHTML rendering, but it
> shouldn't hurt, either.
>
> I used it based on the examples seen at
> https://www.crosswire.org/pipermail/sword-devel/2019-March/046664.html
> which I saved at the time and used as a reference now.
>
> - changes content type to application/xhtml+xml (also tried just xhtml, no
>> diff)
>>
>
> That's not necessary to get you into XHTML mode.
>
> OK, keep that thought in mind -- now, ready for my next confusion? Here
> goes:
>
>  They only thing they care about is the Content-Type: in the HTTP header.
> Of course, you don't have an HTTP header, but surely you have a way to set
> it to "application/xhtml+xml"?
>
> See, on the one hand you say "not necessary" but in your next breath you
> say it's "the only thing they care about." OK, which is it?
>
> There has been this "meta" directive in the header to induce general
> HTMLness via content-type since years before I got involved, and I've never
> touched that particular aspect of it until now.
>
> Trust me, I remain wide open to suggestions, but just in your one response
> here, you've given me 2 completely self-contradictory indications, one
> about DOCTYPE and one about content-type.
>
> Small wonder people have trouble writing code to deal with this, I guess.
>

I think the confusion comes from me mixing my response. Discussion of
proper DOCTYPE and the necessity of the  directive
are about what makes a valid XHTML document

But, as I read more, I came to find that 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?

--Greg
___
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

Re: [sword-devel] trying to get proper xhtml to work in webkit

[Karl Kleinpaste]

On 4/17/20 8:14 AM, Troy A. Griffitts wrote:
> Let me see if I can get the XHTML filters to stop outputting milestone
> divs.

I wouldn't mind them at all, since they're standards-conformant after
all, if I could just convince WebKit not to act stupid. But I'll take
either result, honestly, smarter WebKit or no self-closing .
___
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

Re: [sword-devel] trying to get proper xhtml to work in webkit

[Troy A. Griffitts]

Let me see if I can get the XHTML filters to stop outputting milestone divs.

The XHTML filters were meant to use updated HTML/CSS practices, which at the 
time was XHTML. Now it would probably be HTML5 so, I chose a poor name for the 
filters. Anyway, if milestone divs are causing you a world of hurt, let me just 
output 


On April 17, 2020 4:33:26 AM MST, Karl Kleinpaste  wrote:
>On 4/16/20 11:08 PM, Greg Hellings wrote:
>>  will give you HTML 5, not XHTML. XHTML would be much
>> wordier:
>>
>https://en.wikipedia.org/wiki/Document_type_declaration#XHTML_Basic_DTDs
>
>Well... That link itself says:
>
>In XHTML5  the |DOCTYPE| must
>be a case-sensitive match of the string "||".
>
>So I'm already confused. Didn't take much, huh?
>
>> - begins with  line
>>
>>
>> Doesn't seem to be strictly needed by browsers for XHTML rendering,
>> but it shouldn't hurt, either.
>I used it based on the examples seen at
>https://www.crosswire.org/pipermail/sword-devel/2019-March/046664.html
>which I saved at the time and used as a reference now.
>>
>> - changes content type to application/xhtml+xml (also tried just
>> xhtml, no diff)
>>
>>
>> That's not necessary to get you into XHTML mode.
>OK, keep that thought in mind -- now, ready for my next confusion? Here
>goes:
>>  They only thing they care about is the Content-Type: in the HTTP
>> header. Of course, you don't have an HTTP header, but surely you have
>> a way to set it to "application/xhtml+xml"?
>See, on the one hand you say "not necessary" but in your next breath
>you
>say it's "the only thing they care about." OK, which is it?
>
>There has been this "meta" directive in the header to induce general
>HTMLness via content-type since years before I got involved, and I've
>never touched that particular aspect of it until now.
>
>Trust me, I remain wide open to suggestions, but just in your one
>response here, you've given me 2 completely self-contradictory
>indications, one about DOCTYPE and one about content-type.
>
>Small wonder people have trouble writing code to deal with this, I
>guess.

-- 
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

Re: [sword-devel] trying to get proper xhtml to work in webkit

[Karl Kleinpaste]

On 4/16/20 11:08 PM, Greg Hellings wrote:
>  will give you HTML 5, not XHTML. XHTML would be much
> wordier:
> https://en.wikipedia.org/wiki/Document_type_declaration#XHTML_Basic_DTDs

Well... That link itself says:

In XHTML5  the |DOCTYPE| must
be a case-sensitive match of the string "||".

So I'm already confused. Didn't take much, huh?

> - begins with  line
>
>
> Doesn't seem to be strictly needed by browsers for XHTML rendering,
> but it shouldn't hurt, either.
I used it based on the examples seen at
https://www.crosswire.org/pipermail/sword-devel/2019-March/046664.html
which I saved at the time and used as a reference now.
>
> - changes content type to application/xhtml+xml (also tried just
> xhtml, no diff)
>
>
> That's not necessary to get you into XHTML mode.
OK, keep that thought in mind -- now, ready for my next confusion? Here
goes:
>  They only thing they care about is the Content-Type: in the HTTP
> header. Of course, you don't have an HTTP header, but surely you have
> a way to set it to "application/xhtml+xml"?
See, on the one hand you say "not necessary" but in your next breath you
say it's "the only thing they care about." OK, which is it?

There has been this "meta" directive in the header to induce general
HTMLness via content-type since years before I got involved, and I've
never touched that particular aspect of it until now.

Trust me, I remain wide open to suggestions, but just in your one
response here, you've given me 2 completely self-contradictory
indications, one about DOCTYPE and one about content-type.

Small wonder people have trouble writing code to deal with this, I guess.
___
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

Re: [sword-devel] trying to get proper xhtml to work in webkit

[Greg Hellings]

On Thu, Apr 16, 2020 at 9:31 PM Karl Kleinpaste  wrote:

> From discussion here in March of last year, I am attempting to get Xiphos
> to operate in a proper xhtml mode, rather than its apparent heretofore html
> mode, because I honestly wasn't aware that WebKit could operate other than
> xhtml in the first place. The specific goal is to leave self-closing 
> tags alone, as delivered by the Sword engine, rather than having to
> obliterate them in a post-delivery hack. To this end, using suggestions
> from Nathan Phillip Brink at the time, I've made this change to the opening
> stanza of Xiphos' main display widget:
>
> #define HTML_START \
> -   " content=\"text/html; charset=utf-8\"> \
> +   " \
> + \
>

This line is wrong.  will give you HTML 5, not XHTML. XHTML
would be much wordier:
https://en.wikipedia.org/wiki/Document_type_declaration#XHTML_Basic_DTDs

+http://www.w3.org/1999/xhtml\";
> > \
> + charset=utf-8\"> \
>
> Notable:
> - begins with  line
>

Doesn't seem to be strictly needed by browsers for XHTML rendering, but it
shouldn't hurt, either.

- includes DOCTYPE (either html or xhtml) (also tried leaving this off
> entirely, no diff)
>

You will almost certainly need this to put the browser into XHTML mode

- adds namespace to 
>

That will be needed, for sure.

- changes content type to application/xhtml+xml (also tried just xhtml, no
> diff)
>

That's not necessary to get you into XHTML mode.


> Result so far is an all around no-joy. I am evidently still getting WebKit
> behavior in HTML mode because the self-closing  leads to my
> .introMaterial format/color change bleeding through to the end of the
> chapter, as most clearly seen in the (technically defunct, but I still have
> & use it) ESV2011 module, in every book's 1:1. If I leave the post-delivery
> hack in place, the self-closing  is eliminated entirely, and the
> .introMaterial section is properly highlighted.
>

So here's a thing I've learned:
The moment a browser finds anything that violates the XHTML standards it
will dump you back into HTML 4.01 mode. That seems to be what you're
getting, because  is valid in XHTML but not in HTML 4.01. Secondly,
all browsers ignore the doctype declaration at the top of a file. At least
all modern browsers do. They only thing they care about is the
Content-Type: in the HTTP header. Of course, you don't have an HTTP header,
but surely you have a way to set it to "application/xhtml+xml"?

Relevant:
https://stackoverflow.com/questions/97522/what-are-all-the-valid-self-closing-elements-in-xhtml-as-implemented-by-the-maj

--Greg

>
> Can anyone offer any further suggestions on how to induce the right sort
> of behavior?
> ___
> 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
___
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

[sword-devel] trying to get proper xhtml to work in webkit

[Karl Kleinpaste]

>From discussion here in March of last year, I am attempting to get
Xiphos to operate in a proper xhtml mode, rather than its apparent
heretofore html mode, because I honestly wasn't aware that WebKit could
operate other than xhtml in the first place. The specific goal is to
leave self-closing  tags alone, as delivered by the Sword engine,
rather than having to obliterate them in a post-delivery hack. To this
end, using suggestions from Nathan Phillip Brink at the time, I've made
this change to the opening stanza of Xiphos' main display widget:

#define HTML_START \
-   " \
+   " \
+ \
+http://www.w3.org/1999/xhtml\";> \
+ \

Notable:
- begins with  line
- includes DOCTYPE (either html or xhtml) (also tried leaving this off
entirely, no diff)
- adds namespace to 
- changes content type to application/xhtml+xml (also tried just xhtml,
no diff)

Result so far is an all around no-joy. I am evidently still getting
WebKit behavior in HTML mode because the self-closing  leads to my
.introMaterial format/color change bleeding through to the end of the
chapter, as most clearly seen in the (technically defunct, but I still
have & use it) ESV2011 module, in every book's 1:1. If I leave the
post-delivery hack in place, the self-closing  is eliminated
entirely, and the .introMaterial section is properly highlighted.

Can anyone offer any further suggestions on how to induce the right sort
of behavior?
___
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