Storin t'Kel 2024-04-12 Chat and CMS Roadmap version 0.55 Informative Blog Table of Contents 1. Chat function to website 2. CMS Roadmap plans 2.1. HTML choice 2.2. CSS choices 2.3. Clean codes 2.4. Javascripts? 3. Afterthought 4. References 1. Chat function to website [top] So, I was in need of a project because I was bored. It has been quite a while since I did anything truly SQL/PHP related but I believed it was time to pick that up again and so I did it.[1] The script will be shared when I feel confident enough it is safe and good enough. Having said this, my goals for this chat were to create a simple chat function that runs on PHP and SQL, of which the output is as clean as it can be. This means that my code should always be 100% validated XHTML 1.0 Strict and CSS Level 1. It also means that everything has to load fast, so I was in doubt in regards to allowing other stuff like emoji's and BB Codes. In the end, after five minutes of contemplating, I decided not to add BB Codes at all as it has no use anyway. What I then decided was to allow emoji's but I didn't want to deal with <img src="bla" /> tags within the HTML output. So instead I went for unicode[2]. This meant that I would save kilobytes in rendering the HTML, it also saves kilobytes of storage. I mean, if you're as minimalistic as I am then such things are to be considered. Furthermore I decided to separate the CSS for the chat into its own file. This should be an example that there is nothing wrong with having a few different CSS files to cater to different functions within a website. In this case the whopping 400 bytes of CSS is separated from the enormously large site.css file, which has a shocking amount of 838 bytes. I mean, for a simplistic site like this we wouldn't need much more. So that's the end of this subject. Chat is now online. Enjoy! 2. CMS Roadmap plans [top] On to this subject. I decided a while ago that I want to create a CMS that actually outputs clean codes and which creates files that are fast and furious. Keep in mind that the development will take quite a while as it is a project I will take on by myself. Expect a year at the very least. For now this document focuses on the early thoughts regarding this subject, do not expect a lot of details just yet. My roadmap is as follows: 2.1. HTML choice [top] My CMS, name still to be determined, will have a choice of XHTML 1.0 Strict and HTML5, using as much semantic tags as possible within the HTML codes. My choice to offer this choice is based on personal beliefs versus the future of webdesign. HTML5 is a living standard and XHTML is no longer recommended by the W3C[3]. Let us face it, as much as I promote the usage of XHTML, realistically I have been doing this for decades and I flat-out ignored the 2009 reports regarding continuing developing HTML and discontinuing the development of XHTML. Therefore HTML5 will be the valid choice, XHTML will be the historical choice. 2.2. CSS choices [top] Having said this, with XHTML 1.0 Strict also comes CSS Level 1 if one truly wishes to work within the confines of such strictness. CSS 3 will be offered to work with HTML5 within the CMS. 2.3. Clean codes [top] Understanding how simple I view these things, let me now discuss something important by listing them: CSS Bootstraps? : My ass! Code blobs? : Hell no! Plugin Support? : And ruin the good stuff? No! Readable code? : Yeap, both Human and Machine readable Validated codes? : Yes, no warnings, no errors, no info messages JS support? : Nope So that's how simple it gets. 2.4. Javascripts? [top] But wait, no Javascripts? Well, my hatred towards javascripts stems from the fact that people use it to make page-breaking javascripts; you'd have to whitelist such pages in your NoScript[4] addon in order to load the site in question. Mastodon[5] is such an example, and why I won't join their social media. There are many websites who hold similar views. So my CMS will not generate any JS at all within the HTML documents. I am going to use JS functionally in the backoffice of the CMS. With this I am talking about using CMS to click one button and then set in motion an event to fill in the HTML code. An example is wanting to select a bunch of words and then clicking on the <strong> button to make the text bold. The functionality of JS is then purely aimed at that. The CMS would still work if JS is disabled, but then you'd have to implement the codes yourself rather than select and click a button. In short: Back-office of CMS has functional JS, but it won't break the page if JS is disabled. 3. Afterthought [top] This was a relative short post I wanted to write. The Chat part was fun to make and, code aside, I doubt a lot will change. The CMS part is something that has been on my mind since recreating this website into what it is now. I just want to prove to the world that clean and readable codes can be achieved through a CMS, that the codes can all be properly validated and that the results are fast without having to use preload JS scripts to rapidly download megabytes of content. So think of it as me fighting against the world. :P Anyway, have a great day and enjoy it to the fullest! Storin t'Kel ------------------------------------------------------------------------ 4. References [top] [1] https://www.storin.nl/chat.php [2] https://www.unicode.org/emoji/charts/full-emoji-list.html [3] https://www.w3.org/2009/06/xhtml-faq.html [4] https://noscript.net/ [5] https://mastodon.social/