// NOTE: this is a WIP draft

            On one occasion I casually insulted HTML/CSS/Javascript mid sentence,
            only to be called out to explain my position.
            Before that moment I thought their poor quality was self-evident to every one.
            Not only did I turn out to be wrong,
            I also had to realize my inability to into words my frustration with the system.

            Therefor, bellow, I will be committing the ultimate example of making up a repost
            after one already walked away defeated from an argument.

            I think i would like to declare: "muh historical reasons!"
            is not a valid defense in the context of the
            most dynamic and volatile ecosystem in tech
            which continuously breaks compatibility
            (while how much this applies to core technologies is arguable,
            but the higher level abstractions everyone flees to ARE getting away with it).


            Lack_of_separation_of_structure_and_display:
                This is a string input:
                {@begin=html@
                  
                @end=html@}

                This is a select:
                {@begin=html@
                  
                    Dog
                    Cat
                    Elephant
                    Quoka
                    Giraffe
                  
                @end=html@}

                This is a radio:
                {@begin=html@
                  
                     Dog
                  
                  
                     Cat
                  
                  
                     Elephant
                  
                  
                     Quokka
                  
                  
                     Giraffe
                  
                @end=html@}

                Quick recap/reminder on the nature of a radio:
                    >radios are grouped together by their "name" attribute
                    >"A tree must not contain an input element whose radio button group contains only that element."
                    >only one from the group can be so called "checked" at any given time

                Self-evidently, the  and the 
                are practically equivalent in functionality,
                but are very different from DOM-structure perspective.
                While the  is a single input element providing a value,
                in the meanwhile  takes a many-to-one approach.
                So say we wanted gather all the values of all input tags,
                not with a form,
                but with a script.
                The text input and the  is collected flawlessly,
                but the  would slip through our hands.

                However that should not be a problem, right?
                2 things are designed different and behave different,
                that's in fact consistent.

                Except  is always rendered either as a dropdown or
                an option list box if "multiple" is specified and
                 necessary takes up the appearance of this markable circle thingy.
                So now we are torn: either we use the layout we want or take the look we want.
                We certainly cannot have both. Not without making our code a big hack anyways.

                One could argue that it's not HTML fault, per se,
                but rather all implementation went astray from the true path.
                Thing is: it could have not happened if only had HTML defined
                -say- an attribute to specify how to display inputs.


            Tag_and_style_redundancy:

                This text is italics:
                {@begin=html@
                    text
                @end=html@}
                This text is also italics:
                {@begin=html@
                    text
                @end=html@}

                This text is underlined:
                {@begin=html@
                    text
                @end=html@}
                This text is also underlined:
                {@begin=html@
                    text
                @end=html@}

                This text is bold:
                {@begin=html@
                    text
                @end=html@}
                This text is also bold:
                {@begin=html@
                    text
                @end=html@}

                This text is very bold (supposedly, but rendered exactly like bold):
                {@begin=html@
                    text
                @end=html@}
                This text is also very bold:
                {@begin=html@
                    text
                @end=html@}

                This text is subscripted:
                {@begin=html@
                    text
                @end=html@}
                This text is also subscripted:
                {@begin=html@
                    text
                @end=html@}

                This text is superscripted:
                {@begin=html@
                    text
                @end=html@}
                This text is also superscripted:
                {@begin=html@
                    text
                @end=html@}

                ...And I could go on.


            Two_wrongs_regarding_OOP_do_not_make_one_right: // ?! no clue what this title supposed to mean
                CSS:
                    A key feature of CSS are classes.
                    Classes allow for arbitrary distinction between
                    (otherwise possible equivalent) elements.
                    Classes use the "." notation, clownishly mocking OOP.
                    The way a CSS rule is structured is in many ways extremely similar to object notation:
                    {
                        .example {
                          color: blue;
                          font-size: 18px;
                        }
                    }
                    It's a unique name identifying a group of key-value pairs.
                    So say we have another rule:
                    {
                        .special_example {
                          background-color: lightgray;
                        }
                    }
                    It is clear that every "special_example" is also an "example".
                    The display of each special_example is eternally dependent on the display of example.
                    Yet there are no good ways to define this relationship.
                    While there is inheritance in CSS,
                    it does something else and is also outstandingly sinister,
                    but I digress, fear comes later.
                    So the point is, all of our special example elements will have to look like this:
                    {@begin=html@
                        text
                    @end=html@}
                    Which is error prone, undebuggable and takes longer to type.

                    Something similar goes for the times when one would like to
                    group multiple style classes into one by polygamous inheritance. 

                Javascript:
                    // i forgot what i wanted to say

                CSS inheritance:
                    "\
                    In CSS, inheritance controls what happens when no value is specified for a property on an element.\
                    \
                    CSS properties can be categorized in two types:\
                    \
                    inherited properties, which by default are set to the computed value of the parent element\
                    non-inherited properties, which by default are set to initial value of the property\
                    "

                You may ask to yourself: "What rules determine whether a property is inherited or not?".

                The answer is simple: "Lmao RTFM frfr no cap 😜😜😜".

                And I wish i was joking.
                I mean yeah some are self evident I guess, but not most of the time.

                // the original version was in html; theres no good way to convert this to cdd
                {@begin=html@
                    
                    Here, take a trial in it:
                    

                        
color:              yes
                        
background (color): no
                        
opacity:            no
                        
scrollbar-color:    yes
                        
background-repeat:  no
                        
text-decoration:    no
                        
text-shadow:        yes
                        
scale:              no
                        
word-break:         yes
                        
box-sizing:         no
                        
paint-order:        yes
                    
                    Might as well email me your score.
                    

                @end=html@}

            Resource_management:
                The browser consistently uses the "src" attribute
                to fetch various external resources
                then use (render) them according to the parent tag.
                This gives an easy,
                highlevel solution to what otherwise would be tedious.

            Scripts on the other hand can create "lower level" request and or sockets
            to then do whatever with the raw response.
            This allows for much more flexibility.

            The problem arises from the absolute disconnect between the two.

            Say we have the following page:
            {@begin=html@
                
                    
                
                
            @end=html@}
            Extremely simplistic.
            Now say we magically know (perhaps from a socket) that #pic changed.
            The resource "example.jpg" was rewritten on the server.
            Obviously the browser has no clue about this,
            good thing we know about the change,
            so all we need to is tell the browser too.
            Except our tip meets deaf ears.

            I'm fairly confident the browser internally uses a fetch queue to load resources and
            there is some sort of mapping between resource and requesting tag to enable caching.
            Yet is no way to interact with this queue. It's totally unexposed, 	

            // ?! elaborate!!!

            Cookies:
                Let me quote "https://www.w3schools.com/js/js_cookies.asp>https://www.w3schools.com/js/js_cookies.asp":
                    "The document.cookie property looks like a normal text string. But it is not."
                They have unironically abstracted cookies into a pseudo-string type.
                A high level concept. abstracted. into. a string.
                    "\
                    Deleting a cookie is very simple. [...]\
                    Just set the expires parameter to a past date.\
                    "
                No fucking comment.


            PHP:
                >yet another analysis of why PHP is terrible
                >i would like to clarify, im aware that PHP is no longer considered
                  "modern", yet it refuses to die for some reason

                Error_reporting:
                    // 
                    Great.
                    Except it specifies nowhere how "error reporting is done".
                    As far as I'm concerned it might as well be
                    a single underpaid 3th worlder delivering mail by foot across the globe.
                    But assuming we limit our imagination to the rational
                    (which is quite generous with PHP), it could be:
                        >stored in a global waiting to be queried
                        >pasted into the server logs
                        >pasted into special error logs
                        >returned back to the user


            Defaults:
                Please read the code bellow:
                {@begin=html@
                    
                        
                            
                        
                        
                            

                            

                        
                    
                @end=html@}
                Now let me ask a simple question: how tall will the website be?

                You may logically think that
                if the only element we have is as tall as the screen,
                then the page will surely be as tall as the screen, right?

                Well, no.

                I will give you a hint,
                save out the above code to a file,
                open it in your browser,
                open the Inspector,
                select body
                and view its CSS properties.

                Extra hint:
                if you are on Firefox, get fucked.

                The body element has the implicit styling of:
                "body { display: block; margin: 8px; }" (Chromium 110.0.5481.30).
                These stylings are part of the default stylesheet.
                Firefox is also so kind that it simply just doesnt display
                such defaults while inspecting elements.

                Because of this, our webpage is 16 pixels too tall,
                unless we manually override the relevant CSS rule.

                Ok,
                so now we know that defaults exist,
                but how do we know what ĐareĐ the defaults?

                On firefox, you may consult the 922 lines long stylesheet (LibreWolf 125.0.3-1)
                "resource://gre-resources/forms.css".
                Which is an internal page, so websites cannot dynamically access it.
                Or for chrome you may look it up online. Some where.
                These are your options,
                since browsers may make them whatever the fuck they want them to be.

                I will note this here: this is plain sloppiness.
                Designing anything on a sloppy framework
                is like building a house of cards on a moving train:
                you can do it if you hate yourself,
                but claiming it to be a great and simple experience is retarded.

            Alignments:
                I hope you hate centered things buddy,
                or this is going to be extremely painful for you.
                // ?! TODO

            Forms:
                The following is a perfectly valid html form:
                {@begin=html@
                    

                        <textarea>
                        <button type='submit'>Submit</button>
                    </form>
                @end=html@}
                It sends a POST request to the site path "/destination_path"
                with the user input of the text area when the button is pressed.
                Its a marvel of modern computer engineering.
                A complex operation have been abstracted away to markup in a non-tedious way!

                Oh, what do you mean you dont want the page to automatically refresh
                because its CURRENT_YEAR and we no longer do stuff like that?

                Ugh, i got just the solution for you buddy, its easy:
                {@begin=html@
                    <form id="myform" action="/destination_path" method="POST" onsubmit="return handleSubmit(event)">
                        <textarea name="body" id="mytextarea">


                        Submit
                    
                    
                @end=html@}
                Questions?

            Documentation:
                The largest "documentation provider" is
                "https://developer.mozilla.org/en-US/docs/Web>https://developer.mozilla.org/en-US/docs/Web".
                Too bad it is in a constant identity crisis
                whether it's actual documentation or a pile of tutorials.

            Writer's YYY:
                https://stackoverflow.com/questions/311990/how-do-i-get-a-div-to-float-to-the-bottom-of-its-container