01:14:07 <nsITobin> rest well frg
01:14:09 <nsITobin> else if (html && Preferences::GetBool("content.html.disable", false)) {
01:14:09 <nsITobin>       if (viewSource) {
01:14:10 <nsITobin>         mParser->MarkAsNotScriptCreated("view-source");
01:14:10 <nsITobin>       } else {
01:14:10 <nsITobin>         mParser->MarkAsNotScriptCreated("plain-text");
01:14:12 <nsITobin>       }
01:14:14 <nsITobin>     
01:14:16 <nsITobin> ;)
01:14:21 <nsITobin> html is plain text
01:14:27 <nsITobin> while everything else stays working
01:19:35 <nsITobin> I think this means I have won..
01:19:43 <nsITobin> i can kill html5
01:19:45 <nsITobin> LOL
01:43:10 <nsITobin> tomman:
14:05:51 <nsITobin> oh i should apply this patch to seamonkey see how composer reacts
14:06:05 <nsITobin> might shed some light on how the code works at a deeper level
14:08:27 <nsITobin> https://dpaste.org/pxi1Z/raw
14:09:07 <nsITobin> HTML5 as a choice.. what a novel concept
14:37:29 <nsITobin> seamonkey may be too modern to get away with this hack
14:37:36 <nsITobin> consider that lol
14:38:47 <nsITobin> been a while since I went to some fun but ridiculous means to prove something .. what am I out to prove? I dunno that also makes it fun!
15:09:03 <nsITobin> oh that is fun..
15:10:13 <nsITobin> if this were a serious patch for seamonkey I'd likely have the pref default html mail to text regardless but not html as text lol.. now composer
15:13:01 <nsITobin> composer seems completely unphased must not use nsHTMLDocument cause its the editor
16:51:33 <Sompi> Paypal's security check doesn't let Seamonkey through anymore
19:37:35 <tomman> lolPaypal
19:37:39 <tomman> I avoid them like the plague
19:40:38 <nsITobin> paypal doesn't serve valid xml
19:41:40 <nsITobin> cause html by the pref i added is treated as xhtml
19:41:59 <nsITobin> tomman: the web is much simpler without html5
20:17:22 <jonadab> Eww, Paypal.
20:18:20 <jonadab> Fundamentally dishonest company.  Their whole schtick is to convince users that they are essentially a financial service, while steadfastly telling the government that they are a social media site or something and don't provide any financial services, nosiree.
20:18:59 <jonadab> (To avoid having to comply with inconvenient laws and regulations, naturally.)
20:19:09 <nsITobin> basically yeah tho given the fact that xhtml documents are not ever actually validated against a schema or dtd and the fact that it gets access to any of the defined dom elements AND chrome can do xhtml as well maybe not as well but well enough so i figure let's all just switch to xhtml anywhere we can
20:20:00 <jonadab> My biggest complaint about XHTML is, you can't put block-level elements inside of paragraphs.  But HTML5 doesn't fix this.
20:23:08 <jonadab> I don't understand why more people don't complain about this deficiency.  Am I the only one who thinks it's preposterous, that paragraphs can't contain block-level elements?  It makes the p element essentially useless, and we all have to use div (possibly with a class) instead.
20:23:43 <jonadab> And then style it to have a bottom margin, or whatever.
20:24:10 <jonadab> Which, fine, I *guess* that's ok, but why even have a p element in the doctype then?
20:27:55 <nsITobin> jonadab: well .. first things first.. revive xhtml
20:47:09 <jonadab> Revive?  Has something happened to it?
20:47:18 <jonadab> I mean, other than all the "cool kids" not using it any more?
20:47:29 <nsITobin> yeah no one uses it let alone sends it as xml
20:47:35 <jonadab> Because, you know, I still use it.
20:47:42 <tomman> fun fact: if you're a JavaServer Faces developer, XHTML _is_ your native doctype :D
20:47:45 <jonadab> Oh, I don't send as XML, that causes a level of stricture I don't want.
20:48:04 <jonadab> I send as text/html, IIRC.
20:48:13 <tomman> (and only old IE complained if you DARED serving that as the proper mimetype)
20:48:18 <nsITobin> jonadab: what structure.. self closing tags and end tags and a couple of entities?
20:48:25 <nsITobin> that's the most of it
20:48:35 <jonadab> If I wanted to send as XML, I'd just use XML, no need for HTML at all in that case.
20:48:52 <nsITobin> good use xml with xlst to xhtml
20:49:03 <nsITobin> that is totally acceptable in my book lol
20:49:11 <jonadab> nsITobin: IIRC, if you send as XML, browsers refuse to apply stylesheets.
20:49:32 <nsITobin> well xml+xhtml of course
20:49:35 <jonadab> (Maybe that's been fixed?  I haven't tried it recently.)
20:49:48 <nsITobin> seamonkey.thereisonlyxul.org is sent as xhtml
20:49:53 <jonadab> nsITobin: Yes, I mean xml+xhtml
20:50:09 <nsITobin> uses css fine
20:50:25 <jonadab> I suppose I could try again.
20:50:30 <jonadab> Though I'm not sure I see the advantage.
20:50:40 <nsITobin> you will be the very best
20:50:44 <nsITobin> like no one ever was?
20:50:45 <jonadab> There's nothing really wrong with text/html as a content-type.
20:51:00 <jonadab> The doctype says XHTML, of course.
20:51:19 <nsITobin> jonadab: there could still be some chrome quirks but why not try and see if you can maintain strict markup even if you just send it to html5
20:51:33 <jonadab> I have no use for HTML5.
20:51:45 <jonadab> All of the things it adds (like embedding video) are irrelevant to me.
20:51:50 <nsITobin> xhtml is only processed as xml when the content type is sent otherwise uses html5 parser
20:52:00 <tomman> nsITobin: IE versions prior to 11 (IIRC) would throw a fit if you sent text/xml+xhtml, every other browser would cope
20:52:11 <nsITobin> you are using html5.. ANYWAY unless you send as xml+xhtml
20:52:20 <tomman> but IIRC on Mozilla browsers this came with a interesting side effect: now your tags were case sensitive :D
20:52:38 <tomman> (this bite me HARD when debugging a weird JS problem with some boring LoB app at $WORKPLACE
20:52:53 <nsITobin> who mixes caps and noncaps tags or case change their tags normally one sticks with one form
20:53:13 <jonadab> Case-sensitive and lowercase, I hope?  I haven't used uppercase element names since the mid nineties.
20:53:18 <nsITobin> but best to stick to lower case for forward compatibility to backwards systems
20:53:39 <tomman> IIRC my case was associating some script to some elements, but turns out the script declarated them as uppercase and in my document they were lowercase
20:53:51 <jonadab> Though I do *remember* when uppercase element names were conventional, and HTML didn't have version numbers, and ...
20:53:54 <tomman> so when I flicked the switch from HTML to proper XHTML, suddenly my script broke
20:54:00 <tomman> (it was some 3rd-party lib)
20:54:26 <tomman> had to hijack a function and explicitly handle both uppercase and lowercase tags for the desired use csases
20:54:51 <tomman> IIRC in my case it involved <INPUT>, which in JSF/XHTML would be rendered as <input>
20:54:56 <jonadab> I don't use third-party libraries to generate HTML.  I have my own code for that.
20:55:21 <tomman> if your mimetype was HTML, then INPUT and input were the same deal for the script, and everything worked out of the box
20:55:36 <nsITobin> and why is this a good thing?
20:55:38 <tomman> but on XHTML... your script will never fire because <input> is.. Swiss cheese
20:55:52 <nsITobin> var BEER and var beer are not the same var in javascript now used to generate code
20:56:18 <jonadab> I don't use a lot of third-party JS libraries either.
20:56:22 <tomman> wait, I think I still have a link to that lib
20:56:31 <tomman> jonadab: I avoid 3rd-party dependencies whenever posible
20:56:38 <jonadab> Mostly because I don't use heavy javascript.  A few bits and pieces, but no core functionality.
20:56:41 <tomman> and if I absolutely need to bring one, it must be self-contained
20:56:47 <tomman> and as minimal as possible
20:56:58 <jonadab> I use third-party libraries on the server side, e.g., Perl libraries from the CPAN.
20:57:02 <nsITobin> tomman: in mozilla browsers xhtml elements will use the same dom elements as html5 and if it still functioned the old htmlparser would mozilla has never enforced conformance
20:57:08 <jonadab> DateTime.pm and so on.
20:57:28 <tomman> oh yay, Giggityhub is completely unusable on SeaMonkey
20:57:43 <tomman> now I can't find the bug I filed on Mousetrap for that very behavior on XHTML :/
20:57:49 <nsITobin> yeah webcomponents
20:57:58 <nsITobin> or some dom telemetry api
20:58:05 <nsITobin> UXP got some abort updates lately
20:58:08 <nsITobin> soo
20:58:16 <tomman> oh, i can still use /issues?q=blah
20:58:24 <tomman> https://github.com/ccampbell/mousetrap/issues/312 here is it
20:58:49 <tomman> wow, I reported that 10 years ago
20:58:53 <tomman> ...and never got triaged, even!
20:59:26 <tomman> (and apparently the lib got abandoned 6 years ago, but still...)
21:01:32 <nsITobin> yeah
21:02:01 <tomman> element.tagName will always uppercase... on HTML documents
21:02:21 <tomman> on XHTML? sorry, you get original case, and XHTML won't generate uppercase or mixedcase, this is not legal .D
21:02:23 <tomman> :D
21:02:49 <tomman> (solution for me that had to be deployed into production: hijack a event handler and handle both cases)