Supporting XHTML5?

[Felistrix]

I had spend several hours of trying to get bootstrap to work. After I get it work, I searched more to find the background. I have answered in another report, but there comes no new answer. Maybe because it was closed and "no one" have seen it.

#29235

One of the reasons for closing was:

this is the first time it's been ask I believe

So now it will be at least the second time, you've been asked.

Also as seen in the post, there are 3 downvotes for this decission and "just" 2 upvotes. The other reasons, why this support should be implemented, I wrote already in the other report.

And a link to stack overflow: https://stackoverflow.com/questions/61369623/why-does-bootstrap-dropdown-dont-open

[mdo]

I'm still not in support of any changes here. HTML5 has long been the implicitly preferred doctype for frontend development. XHTML is nearly dead as far as I can tell: https://softwareengineering.stackexchange.com/questions/149839/is-xhtml5-dead-or-is-it-just-an-synonym-of-html5.

So now it will be at least the second time, you've been asked.

Not trying to be mean or anything here, but this is the second time in a year that it's been asked about, and as far as I know only the second time in the ~9 years of Bootstrap. So I'm still not inclined to adopt a competing spec, recommend it anyway, or even support it in anyway.

[herbalite]

In the end it is a standards issue and one not easily solvable on grounds of the standards. At the same time the bootstrap team might run into issues while developing bootstrap5, because of some really weird quirks.

Read this discussion on SO
https://stackoverflow.com/questions/27223756/is-element-tagname-always-uppercase

And then examine the page(s) linked to in there. I used Firefox

https://programming.enthuses.me/tag-node-case.php?doc=x

Notice the differences when rendering the same page in XHTML and HTML5. Most startling is the uppercase section in the SVG part.

Imagine the following scenario. Bootstrap 5 apparantly (correct me if I am wrong) uses more SVG elements. So users will start editing some of the SVG stuff. And casing might be changed by the preferred editor automatically.

Won't be long if there is a discussion about XML/XHTML and case preserving of tags in here.

If nothing else, it's good to be aware of unexpected issues popping up.

From a developers perspective, I can use camel-case tags in XML/SVG too, hence I think about these issues as I enjoy the freedom that comes with it. Never understand the fixation of either lower- or uppercase

Hence I build my own code accordingly to deal with tags that might even use mixed case. The W3C guy mentioned in the SO discussion in the link above, might be unhappy with my stance, but I'm personally fed up with bug hunting for issues like mixed cases that might creep up. Been there, done that. In this case I don't see much value to enforce a certain case for tags.

I do understand however the stance of the bootstrap development team. It's not a problem they created, and the usage for XHTML is indeed small. In the past I've also posted bug reports to the jQuery team for XHTML pages, that thankfully got resolved, as XHTML was more popular back then. My point is: bootstrap 4 relies on jQuery,.

My wish for the future is that we developers are free from these uppercase/lowercase issues, as they are partially remnants of old OS wars. The Internet strives to be come more accessible in any form, and that should apply for mixed case in HTML too. HTML is a subset of XML, that case restriction issu never, ever made sense at all, no matter from what side I look at it.

[Felistrix]

Not trying to be mean or anything here, but this is the second time in a year that it's been asked about, and as far as I know only the second time in the ~9 years of Bootstrap. So I'm still not inclined to adopt a competing spec, recommend it anyway, or even support it in anyway.

And how many requests did you need to change your mind?

What do you say to this:

Sorry, but for me it sounds weird not to do so. HTML is a very, very loose standard.

HTML says <html> is valid code and <HTML> is valid code; even <Html>, <HtMl>, <HtmL> - all valid code. Even any combination for opening and closing tag, like <HtmL></hTMl> is valid code. XHTML is a strict standard, which is case sensitive and differences them.

Now is your argumentation, you want to be compatible with the "everything is correct" standard, that need to convert all tags in uppercase, just to make it possible to handle it and you are using strict comparsion (=== and !==) for it but don't want to be compatible with the XHTML standard, which is strict by itself?

And what to the fact, that even html5 sometimes use lower case, as said in the answer before?

https://programming.enthuses.me/tag-node-case.php?doc=5
https://jsfiddle.net/j6rpox8y/

[Felistrix]

And as I see, there are 4 people, who want's to get the support and 5 people who vote up for your post.

Maybe a bit offtopic: I would like to know, why html makes tags to uppercase. I don't find an answer to it.

[tiesont]

why html makes tags to uppercase

Not sure what you mean by that. Uppercase tags (i.e. <BODY>) was really just something people used to do before text editors that provided syntax highlighting - it was easier to see what was markup and what was content.

[fsologureng]

So the reason is a very old reason. I expect that boostrap reason not be the same.

[herbalite]

@tiesont
To me uppercase is like shouting. Even my eyes tend to ignore it. Even when syntax highlighting wasn't there, I'd write lowercase, did tag matching as soon it was essential for xhtml, etc..

As a full stack developer I appreciate that modern browsers have been designed rather smartly:
An example
<a href="index.html" ...> ... </a>

A style sheet apprently matches all these selectors regardless of the case
'a[href=index.html] { ... }'

'A[href=index.html] { ... }'

'a[HREF=index.html] { ... }'

'A[HREF=index.html] { ... }'

Internally this happens because browsers, according to the built in browser dev tools, changes standard html/css related things to lowercase. In other words the software helps to smooth out user preferences and choices being made by standard committees. Browser developers seems to 1) see the big picture how these technologies interact with one another. 2) Are feed up to deal with issues in the example above.

And the real fun for me is that my point that I am trying to make can be seen as an argument of either side of the isle. xhtml/xml (not the custom tags) is a bit restrictive in many regards (hence many developers dropped it). Yet I also try to promote the idea, that libraries such as bootstrap should be agnostic to the user preferences and deal with anything, as it is. bootstrap and many other libraries have apparently adopted the infamous gigo approach in that matter.
( https://en.wikipedia.org/wiki/Garbage_in,_garbage_out )

Again I'm happy that browser developers seem to see things differently.

[Felistrix]

why html makes tags to uppercase

Not sure what you mean by that.

I mean this:

https://developer.mozilla.org/en-US/docs/Archive/Web/Writing_JavaScript_for_HTML
Scripts that used getElementsByTagName() with an upper case HTML name no longer work, and attributes like nodeName or tagName return upper case in HTML and lower case in XHTML.

I can see, why xml use lower case; because it don't change the case and returns it like it is and most developers (as far, as I have seen it) write their code in lower case. But why did nodeTage and tagName transform to upper case in html, not lower case? Who have decided this and what was the reason for it? That could be really interesting to know.

[mdo]

Going to convert this to a discussion since it's an open ended convo.

[sdh4]

The XML syntax of HTML5 (colloquially known as XHTML5) has its merits: It provides a far simpler and easier to parse representation. It also helps find errors quickly because any syntax error causes the entire document to become invalid rather than potentially causing subtle incorrectness. I would add myself to the chorus that thinks it is important.

Since the underlying data model is identical, the differences are in the interaction with Javascript. For example document.write() is not available, the case of tag names may be different and programatically created elements may have to be in the xhtml namespace to be interpreted properly. Fortunately little of this is directly relevant to Bootstrap itself, more to libraries that Bootstrap uses.

Popper has recently been updated to be xhtml5 compatible and is a (the?) primary source of xhtml5 compatibility: floating-ui/floating-ui#575 So upgrading to popper v2.x would likely cover things (migration guide: https://popper.js.org/docs/v2/migration-guide/)