1. Advertising
    y u no do it?

    Advertising (learn more)

    Advertise virtually anything here, with CPM banner ads, CPM email ads and CPC contextual links. You can target relevant areas of the site and show ads based on geographical location of the user if you wish.

    Starts at just $1 per CPM or $0.10 per CPC.

Should I learn Wappler instead of learning to code manually??

Discussion in 'HTML & Website Design' started by Gary-SC, Jun 3, 2019.

  1. deathshadow

    deathshadow Acclaimed Member

    Messages:
    8,859
    Likes Received:
    1,610
    Best Answers:
    230
    Trophy Points:
    515
    #21
    Only real nitpick I'd have now is the DIV for nothing around the menu UL, as UL's a perfectly good block level container unto itself.

    Though some ID's instead of classes might help for major subsections, but that hinges on future planning. I often describe my outermost wrapper or first element on the page as #top, so that if later on I want a <a href="#top">Back to Top</a> it's as easy as that. Also ID's have higher precedent than classes, which can make it easier to override styles for certain sections. Really though you've not built complex enough to warrant that, it's more just something I do out of habit.

    Oh, and initial-scale is 1, you don't have to say ".0", of course it's .0 if it's a whole number. :D I also like to include height=device-height in there because both my old cheap icoo phone and cheaper bluboo tablet go wonky in landscape view -- using "lie" height as width -- without it. A LOT of people say it isn't needed or doesn't do anything, they're just lucky enough to own a device that doesn't do it.

    They're told it before they ever get this far with HTML/CSS. It's as simple as that, nube predation. Then they become experts in that instead of HTML/CSS and that confirmation bias -- that they have "a" result, regardless of quality -- kicks in.

    It also doesn't help that systems like bootstrap use card-stacked examples. You take something like their pricing example and to 100% replicate its functionality whilst fixing its issues you end up with around 3k of HTML and 5k of CSS that you had to write of your own, whilst if we don't count the size of bootstrap itself against that total they are writing 5.52k of HTML and 211 bytes of CSS. That sounds like they had to do less work -- but it's not a fair comparison.

    Why not? Because if you want anything other than bootstrap's default colouration, you can't alter bootstrap itself (well you could, but you're not supposed to ) and instead you are expected to layer your custom colours atop theirs with more declarations in your own CSS. You want to do something that simple with your own code, you just do it. Edit the existing template, done. No worrying about specificity, dicking around with !important, adding more classes or ID's since there are no suitable targets as classes end up re-used all over the page, etc, etc. By the time you do something as simple as changing their shades of grey to shades of blue, you could be looking at as much as a 20% increase in HTML size and adding 2k of CSS... for something that using semantics and separation of concerns would require ZERO increase in code size.

    That's the lie of their approach.

    Of course, that's before we talk about the inaccessible broken mess that tells non-screen users to sod off that is their idea of HTML. It may in fact end up more code just for trying to fix all the things wrong. Something that gets even worse if you look at outright garbage examples like the Blog Template that doesn't even have a responsive menu (which I had thought was one of the points of using bootcrap), or the product template where their idea of responsive is to get rid of the menu entirely, or the Jumbotron example which is the only one to actually do a responsive menu -- but goes full Pakled on it by using JavaScript to do CSS' job! Not just any simple old JavaScript either, but requiring the bloated train wreck of developer incompetence and ineptitude that is jQuery in the process!

    That last one is probably the one most chock-full of the worst practices, hence their deploying 281k in 5 files to do what you or I would do in around 10k or less in two files. You want an epic /FAIL/ at web development, that one gets the trophy.

    But they don't think in those terms because it's all they know. They sure as shine-ola have no clue what HTML is much less what it is for! YES, I know they work for twitter and it drives twitter under the hood, that doesn't fix the problem. If anything, it's probably costing a company as large and with such high traffic money and time; but no, their guys "know what they're doing" -- of course they do.
    SEMrush
     
    deathshadow, Jun 17, 2019 IP
    SEMrush
  2. deathshadow

    deathshadow Acclaimed Member

    Messages:
    8,859
    Likes Received:
    1,610
    Best Answers:
    230
    Trophy Points:
    515
    #22
    This goes back to the history of HTML and what was happening fifteen to twenty years ago. All these redundancies were many, MANY times worse. I believe I gave you an example of what we were writing for HTML in the late '90's?

    "HTML 4 Strict" -- also referred to by many as "the REAL HTML" -- did away with a LOT of pointless redundancies. It was the entire reason it existed and was created for the sole purpose of dragging us back to good practices. From 1998 until the introduction of HTML 5, ALL NEW WEBSITES SHOULD have been written in 4 Strict... but that didn't happen.

    Part of it can just be blamed on the word "strict" which intimidated people. More of it can be blamed on the fact that the vast majority of people writing websites could never wrap their heads around not saying what things look like in the HTML. The very idea of the "separation of presentation from content" was just "too hard"... or they simply didn't want to update their skillsets past the 1997 norms that were well established. There was a whole campaign of badmouthing those who adopted it, calling us elitist, or wanting to "make things harder" when as you've seen, the results are simpler, cleaner, smaller, and easier to develop! It's been 20+ years of slander and lies.

    "HTML 4 Transitional" -- the 'transitional' part literally meaning "in transition from 1997 to 1998 practices" -- became the norm everyone used, as it allowed all the old HTML 3 and browser specific garbage to be "valid". It was meant to be the compromise for old websites that wanted to add the new features, but ended up being what the vast majority of people used and kept using. As such using endless pointless DIV to wrap sections with classes or style="" just became the new versions of <font>, <center>, align="", etc, etc... with ZERO improvement in actual methodology. This led to the creation of these frameworks like bootcrap or w3.css which again just replicate the same broken mindset and techniques.

    So where does HTML 5 fit into this? It was not created by the W3C, nor was it even really created to make HTML 5 "better" in terms of the separation of concerns. It was created by those who didn't like the direction or simplicity of 4 strict and wanted to continue down the path of saying what things would look like, and flipping the bird at semantics. The group that made it, the "What Working Group" -- aka WhatWG -- clearly didn't understand enough about HTML 4 strict to make its successor, and went about creating all sorts of extra "structural" tags to represent what people were doing with DIV, regardless of if those DIV were even needed, had an actual semantic meaning, or were presentational.

    ... and that's the problem with HTML 5. Whilst there are many improvements -- the simpler charset META, the removal of pointless attributes like type="text/css" and type="text/javascript", the new input type="", etc, etc -- a hefty chunk of the spec simply introduced new redundancies, pointless containers for those who think every damned tag needs two or three DIV around it, and allowing in old redundancies that 4 Strict specifically and intentionally said NO to -- like <embed>.

    They even created new redundancies. The original W3C plan for the next HTML -- the one shitcanned for WhatWG's nonsense -- actually planned on dropping the IMG tag. why? It's redundant to OBJECT. Those new AUDIO and VIDEO tags? Redundant to OBJECT. That EMBED tag that 4 Strict specifically told to sod off on purpose? REDUNDANT TO OBJECT!

    The OBJECT tag's entire purpose was supposed to be to imply media that was not plain text content. IT was to be a one stop shop where ANY media format could be added, be it in-built to the browser/OS or added by an extension. This would allow for sandboxing of plugins, a single interface/api to learn, and not being at the whim of browser maker's vendor lock-in as to what file formats are supported.

    Which is why the claims that AUDIO and VIDEO were created to fight the "vendor lock-in" of flash was another bald faced lie on the part of those who lost the media format wars to Flash -- like the VIDEO tag's creator Apple. If it was to fight vendor lock-in why did we spend the first five years of the VIDEO tag having to deploy four different file formats because each browser maker had their own favorite pet format they were pushing, re-igniting the format wars? Each browser maker was trying to create their own vendor lock-in to... uhm... fight vendor lock-in? If that doesn't scream bullshit, I don't know what does.

    I can prove the WhatWG didn't understand HTML, and instead were documenting what people WERE doing, instead of what SHOULD be done. <HGROUP>

    The HGROUP tag was created to let you 'pair' headings together for things like a title and tagline. The problem with this is that's all one headING and should never have been two separate tags in the fist place. You STILL see idiots slopping out code like:

    
    <hgroup>
        <h1>Digital Point</h1>
        <h2>Webmaaster and Internet Marketing News</h2>
    </hgroup>
    
    Code (markup):
    (Just an example, DP does not actually do this!)

    The problem being does that H2 actually indcate/mark the start of a new subsection of the page? No. So it's not a H2, nor should it ever be so. Pairing headings that way is gibberish. A tagline is a grammatically related part of the H1, so it should be in the H1! For something like a tagline we make the text smaller in professional writing to indicate de-emphasis... hence we have a tag for that:

    
    <h1>
        Digital Point<br>
        <small>Webmaaster and Internet Marketing News</small>
    </h1>
    
    Code (markup):
    Now, that might look like presentational markup, but again we WOULD make that text smaller for grammatical/structural reasons, so it's not. We don't even have to display the text smaller. It just means WOULD BE, not should be.

    B, I, STRONG, EM, and CITE all have the same type of relationship. People think of <b> and <i> as being presentational, they're not supposed to be. They are supposed to mean "Would be bold or italic for grammatical reasons where it is not receiving emphasis (em), more emphasis (strong), or being cited." It's a subtle philisophical difference many never wrap their heads around, even though it was 4th and 5th grade English back in the '70's. The classic example a friend of mine created a long time ago: (skipping code tags, they don't help the clarity in this case)

    <i>GURPS,</i> <b>Steve Jackson Games'</b> flagship role-playing game, was first released in 1985. Several licensed adaptations of other companies' games exist for the system, such as <i>GURPS Bunnies and Burrows.</i> However, <b>SJ Games</b> has no connection with <b>Wizards of the Coast</b>, producers of the <i>Dungeons and Dragons</i> RPG. <em>No <i>GURPS</i> content is open-source.</em> <strong>Do not plagiarize <b>SJ Games</b> work!</strong>

    EMphasis and STRONG for expression, Italic for product and book titles we are not citing, Bold for the legal entities. This is why B inside STRONG or even headings, or Italic inside EM can in fact be valid and make perfect grammatical and structural sense! They are NOT redundant as they have different meanings!

    But most people are not taught nor even think in those terms. Hence the mess that is HTML 5, and why even though the W3C has accepted PARTS of it as official, there is still a lot of differences between the WhatWG and W3C versions; only adding to the confusion.

    The first H2 should mark your main content. That H2 being a blessing in that you can put all sorts of useful stuff like navigation and search before the content. Still content should come before other 'additional' stuff on the page where practical, which is why "content first" column techniques are a thing. What could/might be in a sidebar would/should come after the content, but your primary navigation? That's more useful to users up top.

    In THEORY that's also the function of both NAV and MAIN in HTML 5, but if H2 can do the job, why do we need those? NAV is just stupid anyways... of course anchors with href on them are navigation, THAT'S WHAT ANCHORS ARE FOR! NAV going all sorts of full-on dumbass too the way people are blindly dumping anchors into it as menus without a UL/LI, completely pissing on semantics and even the rules of HTML 5 itself. The bloody spec says that a menu is still a UL/LI even if you put NAV around it, but again, people make blind assumptions then blindly copy what everyone else is doing. Just watch those lemmings run straight off the cliff.

    It depends on the site and its needs. I do feel people slop way too much stuff into menus, but there are aspects of mobile usability where a hamburger menu approach is the only "real" solution.

    One of which is the needs of a touch interface. It helps to "enlarge" the buttons so that they are better "finger sized targets'. Google even tests for this on your mobile quality. That larger padding consumes a lot of screen space, so it's better to collapse the menu out of the way for normal navigation.

    What I really dislike are full "dropdowns", aka they dropdown all the time for dozens of different subcategories. A single depth isn't too bad, but when they start having multiple flyouts two or three levels deep they not only get hard to navigate, they can also compromise usability by creating a condition in the user called "link overload". It is possible to present the user with too many options at once, or so many options they don't comfortably fit on the screen. It might seem convenient to an expert who knows the whole page inside-and-out, but it can confuse the hell out of the casual user.

    In general there are valid arguments for/against the different menu techniques, and I take it on a case-by-case basis, instead of trying to hammer everything into one round hole.
     
    deathshadow, Jun 17, 2019 IP