rest well frg

else if (html && Preferences::GetBool("content.html.disable", false)) {

if (viewSource) {

mParser->MarkAsNotScriptCreated("view-source");

} else {

mParser->MarkAsNotScriptCreated("plain-text");

}

 

;)

html is plain text

while everything else stays working

I think this means I have won..

i can kill html5

LOL

tomman:

oh i should apply this patch to seamonkey see how composer reacts

might shed some light on how the code works at a deeper level

HTML5 as a choice.. what a novel concept

seamonkey may be too modern to get away with this hack

consider that lol

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!

oh that is fun..

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

composer seems completely unphased must not use nsHTMLDocument cause its the editor

Paypal's security check doesn't let Seamonkey through anymore

lolPaypal

I avoid them like the plague

paypal doesn't serve valid xml

cause html by the pref i added is treated as xhtml

tomman: the web is much simpler without html5

Eww, Paypal.

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.

(To avoid having to comply with inconvenient laws and regulations, naturally.)

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

My biggest complaint about XHTML is, you can't put block-level elements inside of paragraphs. But HTML5 doesn't fix this.

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.

And then style it to have a bottom margin, or whatever.

Which, fine, I *guess* that's ok, but why even have a p element in the doctype then?

jonadab: well .. first things first.. revive xhtml

Revive? Has something happened to it?

I mean, other than all the "cool kids" not using it any more?

yeah no one uses it let alone sends it as xml

Because, you know, I still use it.

fun fact: if you're a JavaServer Faces developer, XHTML _is_ your native doctype :D

Oh, I don't send as XML, that causes a level of stricture I don't want.

I send as text/html, IIRC.

(and only old IE complained if you DARED serving that as the proper mimetype)

jonadab: what structure.. self closing tags and end tags and a couple of entities?

that's the most of it

If I wanted to send as XML, I'd just use XML, no need for HTML at all in that case.

good use xml with xlst to xhtml

that is totally acceptable in my book lol

nsITobin: IIRC, if you send as XML, browsers refuse to apply stylesheets.

well xml+xhtml of course

(Maybe that's been fixed? I haven't tried it recently.)

seamonkey.thereisonlyxul.org is sent as xhtml

nsITobin: Yes, I mean xml+xhtml

uses css fine

I suppose I could try again.

Though I'm not sure I see the advantage.

you will be the very best

like no one ever was?

There's nothing really wrong with text/html as a content-type.

The doctype says XHTML, of course.

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

I have no use for HTML5.

All of the things it adds (like embedding video) are irrelevant to me.

xhtml is only processed as xml when the content type is sent otherwise uses html5 parser

nsITobin: IE versions prior to 11 (IIRC) would throw a fit if you sent text/xml+xhtml, every other browser would cope

you are using html5.. ANYWAY unless you send as xml+xhtml

but IIRC on Mozilla browsers this came with a interesting side effect: now your tags were case sensitive :D

(this bite me HARD when debugging a weird JS problem with some boring LoB app at $WORKPLACE

who mixes caps and noncaps tags or case change their tags normally one sticks with one form

Case-sensitive and lowercase, I hope? I haven't used uppercase element names since the mid nineties.

but best to stick to lower case for forward compatibility to backwards systems

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

Though I do *remember* when uppercase element names were conventional, and HTML didn't have version numbers, and ...

so when I flicked the switch from HTML to proper XHTML, suddenly my script broke

(it was some 3rd-party lib)

had to hijack a function and explicitly handle both uppercase and lowercase tags for the desired use csases

IIRC in my case it involved <INPUT>, which in JSF/XHTML would be rendered as <input>

I don't use third-party libraries to generate HTML. I have my own code for that.

if your mimetype was HTML, then INPUT and input were the same deal for the script, and everything worked out of the box

and why is this a good thing?

but on XHTML... your script will never fire because <input> is.. Swiss cheese

var BEER and var beer are not the same var in javascript now used to generate code

I don't use a lot of third-party JS libraries either.

wait, I think I still have a link to that lib

jonadab: I avoid 3rd-party dependencies whenever posible

Mostly because I don't use heavy javascript. A few bits and pieces, but no core functionality.

and if I absolutely need to bring one, it must be self-contained

and as minimal as possible

I use third-party libraries on the server side, e.g., Perl libraries from the CPAN.

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

DateTime.pm and so on.

oh yay, Giggityhub is completely unusable on SeaMonkey

now I can't find the bug I filed on Mousetrap for that very behavior on XHTML :/

yeah webcomponents

or some dom telemetry api

UXP got some abort updates lately

soo

oh, i can still use /issues?q=blah

ccampbell/mousetrap #312 here is it

wow, I reported that 10 years ago

...and never got triaged, even!

(and apparently the lib got abandoned 6 years ago, but still...)

yeah

element.tagName will always uppercase... on HTML documents

on XHTML? sorry, you get original case, and XHTML won't generate uppercase or mixedcase, this is not legal .D

:D

(solution for me that had to be deployed into production: hijack a event handler and handle both cases)