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.

Why is this not aligning correctly on phone browsers?

Discussion in 'HTML & Website Design' started by JEET, Oct 12, 2020.

  1. #1
    Why is this not aligning correctly on phone browsers?

    Kindly look at this page, on a phone browser:
    https://cheers.desi/profile/munafasutra/

    I have not checked on android, but on iPhone etc, there is so much gap on left side, and right side is getting all cut off...
    What is happening?

    All the css is on the page itself, for now. Will put it in a different file later.

    The theme file loaded is this:
    (only theme, without content)
    https://cheers.desi/themes/social.htm

    I'd prefer if I could use this theme instead,
    https://cheers.desi/themes/social2column.htm
    This one is using float to align 2 columns side by side on laptops,
    but on phone browser they will fall below each other as intended.
    Problem is, if I use this theme, then as soon as something is touched on screen, entire site starts getting re-aligned automatically.
    (kind of like starts dancing on screen... very irritating)

    This theme with content is:
    https://desicheers.com/profile/munafasutra/

    This one also has that left gap, and right cut off problem.
    What is causing this problem?

    @deathshadow could you also take a look please?
    Please let me know what specific CSS I need to change to make it appear good on phones, as it appears on firefox on laptop.
    Colors etc I will fix later.
    Alignment is the big problem.
    Thanks
     
    JEET, Oct 12, 2020 IP
  2. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #2
    I'd say it doesn't align properly on DESKTOP so I have no idea what you expect out of it on mobile. Everything just seems kind-of slopped into the page any-old-way with no rhyme nor reason.

    Which goes hand in hand with the non-semantic junk markup, inlining of style="" in the markup, static <style> in the markup, gibberish/incomplete forms, gibberish/incorrect heading orders / lack of logical document structure, endless pointless DIV for nothing, cryptic classes (seriously, WTF is "md"?), attributes like target that have no business in any markup written after 1997, ten year out of date character meta, incomplete forms, empty paragraphs doing padding's job, non-breaking spaces for no reason, NAV wrapping things that aren't even navigation, paragraphs around non-paragraph content, double-breaks doing paragraph's job, incomplete malformed tables, blocking scripts in the head, blocking scripts in the body, placeholder is not a label, scripttardery faking a placeholder doing label's job like it's still 2009, <a name="" as a hash hook like it's still 1998, button plus some scripttardery for F*** knows what in the header, scripttardery creating a menu so it's accessibility junk...

    Layout is the least of your problems. Content dictates markup, content + markup dictates layout. To be brutally frank, you don't have any of those. You don't have ANY of the proper stepping stones that should be in place before you deal with layout or style.

    No offense, but it's garbage markup and layout like this which makes me think your "ePowerPress" thing is WORSE than turdpress. LEARN HTML because what you have isn't it! What you're spewing out is as bad if not WORSE than what TP does out of the box. That's not how this works, that's not how any of this is supposed to work!

    It's funny, it's useless on screen readers and braille reader here, and I thought that was something you knew about. I honestly can't figure out what the layout's even supposed to be given it's pretty much uselessly banjaxed on everything here. It does NOT look like intentional design.
     
    Last edited: Oct 12, 2020
    deathshadow, Oct 12, 2020 IP
  3. JEET

    JEET Notable Member

    Messages:
    3,825
    Likes Received:
    502
    Best Answers:
    19
    Trophy Points:
    265
    #3
    That <a name="something"></a> is for a javascript. The photo/video/about" etc links when clicked are keeping that section in focus when clicked.

    Which form is malformed? You pointed this out earlier also to me, but never told me which form you meant.

    I don't think I have any unclosed div or paras. Which one is it, let me know.

    Attribute target is there because this website will also be loaded inside an android app webview. When an external link is clicked, it will not open inside app, will open in a real browser. That is why "target=_blank"

    The page you saw is built using a plugin for ePowerPress, its not a regular ePowerPress page.

    I really don't understand what accessibility issues you come across, because after you told me last time, I even tested with latest NVDA, works perfect, "every single thing".
    Same is with JAWS.
    Includes sections which are updated using javascript.

    The part inside the <nav> </nav> is the navigation of the site. Thats the notification with clickable links for the user.
    Right now its empty because I have not made any posts yet, and there are no notifications to show.


    Anyways,
    I want to know why is there so much gap towards left on iPhone browsers?

    I am thinking its happening because I am using fixed "px" in padding and margins. Is that right?
    I think changing it to percentages will fix the problem.

    Attached is what I see on firefox (in high contrast mode), will worry about colors later.
     

    Attached Files:

    JEET, Oct 12, 2020 IP
  4. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #4
    Then why is it in the markup? And why would scripting be changing the focus over tab links?!? (something that these days isn't even JavaScript's job?)

    Yes. As in all of them. Where are your fieldsets? Where's your labels? Why are you using JavaScript to recreate placeholder like it's 2003, when placeholder is not a label?

    I go to your forms on my braille reader or JAWS 2020, there's nothing to tell me what the input actually is for! Nothing, nada, zip, zilch.

    Not about unclosed, you've got Paragraphs around non-paragraph content, double-breaks doing paragraph's job, and DIV for nothing.

    That almost makes sense, though crapplets that launch webpages do piss me off as a user. If I wanted to browse the web, I'd be in a browser, not a crapplet.

    But that's probably part of why I'm not a fan of phone / mobile crapplets.

    Saw the same issues in your vanilla install files, NOT that I was ever able to even get it to install and run.

    It shouldn't. Your lack of semantics -- like the run-on sentences of anchors -- are a nightmare on the braille reader. You're supposed to put menus in LISTS for a reason, but you seem to insist on just slopping anchors in any-old -way with no block or break based divisions.

    Really? Buried deep down the page? So the actual main menu isn't the site navigation? that's borked.

    Whilst I don't have an iPhone, I also have zero idea what "gap" you'd be referring to as I have NO clue what you want it to look like... particularly when I'm seeing five different broken nonsensical layouts in two different browsers across all window resizes and mobile emulation.

    Percent for padding is based on screen width, so it too is wrong. Are you using %/EM fonts? Then why aren't you using EM padding and margins? You use PX, it's an all or nothing, not willy-nilly half-assed mix and match.

    Really between the broken and incomplete markup, and the broken/inconsistent layout, I have no clue what you're even trying to accomplish layout-wise, much less what your "problem" is. This is typical of the code that when people bring it to me, I tell them to throw it out and start over with PROPER semantics and separation of concerns. You simply don't have the bedrock to build a layout upon. ANY layout.
     
    deathshadow, Oct 12, 2020 IP
  5. JEET

    JEET Notable Member

    Messages:
    3,825
    Likes Received:
    502
    Best Answers:
    19
    Trophy Points:
    265
    #5
    For using PX etc, suppose I want to have
    margin: 3px;
    then how do I do that using EM?
    Right now I changed it to
    margin: 0.3%;
    but am not sure how it will work.
    I don't want too much gaps on mobile screen anyways, so if that 0.3% value comes out as very small, like 1px, still ok.
    I don't have iPhone either, so am waiting for reply from someone who checks my websites on iPhone and iPads.
    Will have to wait till tomorrow morning...

    About <a name="something"></a>
    You asked,
    Then why is it in the markup? And why would scripting be changing the focus over tab links?!?

    The link of About/Photo/Video etc are like this in js,
    <a href="#something" onclick=" loadTab(id) "> About </a>

    If I am leaving it empty, like this
    <a href="#" onclick=" loadTab(id) "> About </a>
    Then screen reader focus is going to top of page. very annoying to read the whole page again til you reach "About" again.


    About forms, really, nobody uses forms by just hitting tab tab key on keyboard. That is what you are doing.
    It still works like that also, in JAWS and NVDA both. Not sure why your version of JAWS is not reading.
    You can still read everything around the form by simply pressing up/down keys, even if you are jumping between fields using tab tab key.
    Reason I am not using labels is because I am using long descriptions around the forms, explaining what to enter, sometimes with examples.
    Like this one:
    https://cheers.desi/register/
    I am explaining how the phone number is to be entered, email will be verified, password must have what etc etc...
    If I simply do:
    <label> Phone </label>
    <input type="text" name="ph" />
    Then most people will not know how the phone number needs to be entered.
    I myself forgot what format check I coded by the time I went to actually register. That description was helpful.


    Double breaks are not doing paragraph work.
    That part is empty now. Signature will show there.


    Installing power press is very easy. It picks all settings on its own, you can still hard code.
    Problem was probably the .htaccess file I packed with that download.
    May be https was turned on in htaccess, but base URL was coded as non-https, so the installer form redirected as empty.
    This is why install was not done.
    I told you this back then also.

    <form action="non-https-link" method="post">
    and htaccess redirected the form to https after submit
    Redirection did not reposted the values, so installer did not worked.


    About links without lists,
    I tried that, don't think I did not.
    Still NVDA and JAWS both read those as they are reading it without lists.
    NVDA read it as sentence,
    JAWS as individual links.
    For NVDA, when it reads sentence of links, simply hit the tab key, and it starts reading links individually.
    Only way NVDA read links individually by default was when I wrapped it in <p></p> tag.
    Now you can see how this will become for 5 links,
    <p class="menuLink"> <a href=""> Home </a> </p>
    <p class="menuLink"> <a href=""> Login </a> </p>
    <p class="menuLink"> <a href=""> Register </a> </p>
    etc etc

    This is not an accessibility problem.
    Accessibility means people cannot click the link.
    On my website, they can very well click the link. Without any problem.


    The navigation is supposed to be on right side of screen on laptop. I did that change now.
    On mobile, it will drop down, at bottom.
    There is a "Show More" button near the blue menu, when clicked on mobile, navigation comes on top.
     
    JEET, Oct 12, 2020 IP
  6. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #6
    Generally you wouldn't... because there's ZERO fixed relationship in size between PX and EM. In fact that's WHY you're supposed to use EM.

    For you -- assuming you made no OS or browser level changes -- 1EM is probably 16px by default on HTML, but for me on the machine I'm on right now it's 20px, and on my media center it's 32px. That's WHY you're supposed to use it. It's scaled based on font-size.

    Typically I design in multiples of quarter EM.

    I mean, if you want the equivalent of 3px for "most users" that would be 0.1875em assuming you don't change the font-size on body... but you shouldn't be thinking that in the first place. I generally would have a 1EM padding or minimum margin on desktop, and drop it to half that on mobile as edge-to-edge sucks. That said, I have no idea what you're even trying to accomplish for layout much less what you're seeing as "wrong", so it's hard to say.

    0.3% as padding or margin would/should be based on the width of the PARENT ELEMENT, which is wonky and is likely not what you want or should be doing. It has nothing to do with font-size and if the element is full width, at 1080p you're looking at 1920 * 0.03 == 57.6px! Even down at a small low end phone resolution of 320px that's 9.6px.

    Note most browsers will truncate fractions down -- so 57px and 9px respectively -- but firefuxxors will round up -- 58 and 10 -- and also keeps track of fractiions subtracting off excess as needed. This behavior can be a pain in the ass if you have someone insisting on pixel-perfect out of ignorance.

    Anyhow, if you're even thinking in pixels when it comes to layout, you're not thinking.

    That's why:

    1) if you don't want a link's action to hash across the page, you event.preventDefault in the handler... which is:

    2) Don't use onevent attributes in the markup as they f*** up event handling.

    3) don't slop markup into the code from JavaScript be it by innerHTML or document.write

    4) if it's a scripting only behavior where you're not trapping the href for graceful degradation -- which you're lacking since there's no scripting off plan -- you should likely be using <button type="button"> NOT an anchor!

    Backtracing into that code... yeah, there's your problem. This isn't 1998! You don't go doing outdated rubbish like:

    
    for( x=0; x<tabs.length; ++x ){
    
    v= v + "<a id='at"+x+"' href='#pageTabs' onclick=' loadTab(\""+x+"\");'>"+ tabs[x] +"</a> ";
    
    }//for
    
    document.getElementById( "tabs_buttons" ).innerHTML = v;
    Code (markup):
    Particularly for things that probably don't even need JavaScript to be done anymore. InnerHTML is insecure outmoded, slow loading sucker-bait. DO IT ON THE DOM!

    
    if (tabs) {
    	var tabButtons = document.getElementById("tabs_buttons"),
    	for (var title of tabs) {
    		var a = tabButtons.appendChild(document.createElement('a'));
    		a.id = "at" + title;
    		a.textContent = title;
    		a.onclick = loadTab;
    	}
    }
    
    Code (markup):
    Where it will execute around 20 to 100 times faster. Though again I'd use button type="button" so that you don't have to event.preventDefault inside that loadTab handler.

    
    if (tabs) {
    	var tabButtons = document.getElementById("tabs_buttons"),
    	for (var title of tabs) {
    		var button = tabButtons.appendChild(document.createElement('button'));
    		button.type = "button"; // remember, "submit" is the default, we don't want that
    		button.textContent = title;
    		button.onclick = loadTab;
    	}
    }
    Code (markup):
    Though in both cases loadTab would have to be rewritten to target event.currentTarget, you could probably extract textContent there as the target hook. PROPER event handlers don't get passed normal variables, they get the Event object.

    Either way though big tip? If you see onevent attributes in markup, or scripting in the markup, or innerHTML being used? You're looking at two decade old broken garbage script-writing practices that should never have existed in the first place.

    Although your whole methodology there is flawed nonsense with the wasteful creation of extra copies of the code for nothing... just hide/show the originals! Why are you wasting time making copies via innerHTML?!? You just WANT the page to take forever to load and have accessibility woes?

    Again though, not that any of this is JavaScript's job if you're willing to drop IE support altogether... which even I -- Mr. "I have clients that still insist on support to IE 5.5 for CE" -- is saying "ENOUGH, we're done!"

    It's the braille reader where it's the real problem. It's not telling me what the input ARE, aka LABEL's job. Even if it works for your screen readers, LAH-DI-DAH for YOU! Lah-di-dah for me really. It's not about us, it's about using HTML properly to reach EVERYONE!

    And to do that you should have proper semantics to guarantee it! Not using LABEL, using scripttardery to replicate PLACEHOLDER for crap that is NONE of placeholder's flipping job, etc, etc, is NOT good design or proper use of HTML. Same for the omission of lists. "But it works here" is NOT sufficient justification for basically ignoring the most basic rules of HTML and document construction. Get your bloody UL/LI on your menus, LABEL and FIELDSET on your forms, and THEAD, TBODY, TH and SCOPE on your blasted tables!

    Which is either placeholders job, or properly worded text... but that does NOT mean to omit the flipping LABEL!

    Much less the way you just wrote that there's no semantic relationship between the label and the input. Either wrap the input in the label, or use for="id_of_input".

    LABEL to say what it is, PLACEHOLDER to provide an example of input, P afterwards to describe extra information about said INPUT if needed. Proper flipping semantic markup! These tags exist for a reason, use them!

    And if it really bothers you, put the full text IN the flipping label! That's what it's for!!!

    Yeah, yeah they are.

    
    <p> Latest <a href="https://desicheers.com/tag/StockMarketNEWS"> #StockMarketNEWS</a>  by <a href="https://desicheers.com/tag/MunafaSutra"> #MunafaSutra</a>  Daily Updates on homepage of <a target="_blank" href="https://MunafaSutra.com">MunafaSutra.com</a> <br />
    <br />
    <br />
    Daily News covers Nifty updates, top headlines, broker recommendations, and Munafa special pics!<br />
    <br />
    For more Intraday tips check:<br />
     <a target="_blank" href="https://munafasutra.com/nse/BestIntradayTips">munafasutra.com/nse/BestIntradayTips</a> <br />
    Upto 90% accurate!<br />
    <br />
    
    Code (markup):
    Double breaks doing paragraph's job. Those are NOT all one single train of thought.

    I may try it again, but looking at the code it's not something I'd EVER let someone deploy outside of a sandbox. Again, in terms of both security and markup output, it's WORSE than Wordpress and looks like something slopped together with HTML 3.2 and PHP 3 era practices.

    Then I would think your installs are jacked, or you've changed base settings... but regardless of if it works or not for you, blindly dumping anchors in is the wrong flipping markup!!! so it's going to be broken somewhere for someone at some time.

    If you can't be bothered to write the proper semantic HTML, you don't get to run around calling it "modern" or "powerful", much less accessible! Do not pass go, do not collect $100, go straight to jail.

    FFS it's even in the bloody specification examples.

    It does not navigate properly, nor should it. If it is for you, well good for you. Don't f*** over others by not using THE CORRECT BLOODY MARKUP!!!

    Semantic HTML is why HTML was created. It's what it's for. But no, you basically seem to want to ignore that screwing around throwing layout at INCOMPLETE CODE!

    None of the code you have would/should do that as the document structure doesn't say that, nor does your nesting orders of the DIV. What you're saying bears no resemblance to the code presented.

    Much less you seem to be thinking by specific device size instead of the needs of the content. That's probably why you're running around waiting on people with actual hardware to test when all you SHOULD be needing to do is resize your browser window.

    Make the desktop layout using techniques like negative margin floats, display:flex, or display:grid. Narrow the window until the layout breaks, figure out at how many EM that happened, add a media query to strip off columns, adjust widths/padding/margins, then lather, rinse, repeat until you get down to around 16em, the smallest we should in modern times have to worry about supporting.

    You've built the page with techniques that aren't compatible with that, using incomplete markup, in a manner that is only going to make doing any "real" layout harder and harder the deeper you get into this.

    Hence why if this:
    [​IMG]

    Is your intentional design, you've got problems... Lots and lots of them. Undersized fixed metric fonts, rounded corners and borders for nothing that are blowing past the screen width (see that extra scrollbar?). It almost looks like you're trying to apply fixed-width thinking to dynamic or elastic width elements.

    ... and please, for the love of the fairy tale about the bastard child of the magical genocidal maniac in the sky, will you axe the three separate social menus that seem to be in there for no good reason?!? If there is a reason, no user is going to be able to decipher it.
     
    deathshadow, Oct 13, 2020 IP
    Saputnik and JEET like this.
  7. JEET

    JEET Notable Member

    Messages:
    3,825
    Likes Received:
    502
    Best Answers:
    19
    Trophy Points:
    265
    #7
    Thanks for the "EM" explanation.
    So, I should be using
    margin: 0.18em;
    normally for a 3px to 5px equivalent, right?
    I am not changing the webkit font size, left it as it is.
    I'll try this method now for the design.


    I get your point about multiple <br /> statements.
    That is user input data, which is "nl2br done by PHP.
    I get your point, I can change this to use my own function.


    Which 3 social menus are you mentioning here?
    "axe the three separate social menus that seem to be in there"

    Do you mean some links below search box,
    then some in blue bar,
    then those tabs etc?

    First one is "trending" tags. Not a menu. To show what other people are posting.

    Menu in blue bar is the actual menu, to go to main sections of the site, to dashboard, to manage profiles, to login/logout etc.

    Tabs etc are specific to the page people are on.
    Tabs are there on profile page only,
    a different thing is there in dashboard (what user wants to see on dashboard, those options),
    different when managing profiles (options specific to editting profiles).
    and so on.

    Only reason I made this third (tab) menu is because too much data cannot be shown on one page itself, makes it very difficult on mobile screen to scroll down too much.

    The website has a non-js version for tabs by default.
    In case of no JS, tabs will not be shown, all content will appear below one another in DIV.

    When JS is there, all those DIV will get hidden, actually height:1px is done.
    JS will create the tab buttons, on top of the first DIV,
    and JS will load data from first DIV into a tab_DIV.
    Then when second button is clicked, data from that DIV will get loaded in tab_DIV and so on.

    To create tabs, all I have to do is this,

    Define Tab buttons, and an empty div
    <script>
    var tabs = [ "Posts", "Photo", "etc" ];
    </script>
    <p id="tabButtons"></p>
    <div id="tab_DIV"></div>

    Then write data for those buttons, like
    <div id="DIV_POSTS"> data here </div>
    <div id="DIV_PHOTO"> photo here </div>
    and so on.

    Then finally call JS function to create tabs
    <script> showTabs(); </script>

    Without this JS function, all data will still be shown, only an extra <p></p> and an extra <div></div> get added to html.

    With the function call, all of it becomes tabbed browsing like you are seeing on the site now.
    <p id="tabButtons"> buttons appear here </p>
    <div id="tab_DIV"> content of first tab appears here </div>

    Those other DIV, they all get hidden. Screen readers can still read those.

    I can generate tab links in button also, its just that buttons take more space than anchor links.
     
    JEET, Oct 13, 2020 IP
  8. JEET

    JEET Notable Member

    Messages:
    3,825
    Likes Received:
    502
    Best Answers:
    19
    Trophy Points:
    265
    #8
    I think it should be somewhat better now.
    The css file was missing a "{" in one of the media queries.

    I also changed the way those hashlinks appear on smaller screen.
    They will be an inline float on laptop wide screens, but will be hidden on mobile phone, until "trending" button is clicked.
     
    JEET, Oct 14, 2020 IP
  9. brandon_wallace

    brandon_wallace Peon

    Messages:
    23
    Likes Received:
    4
    Best Answers:
    0
    Trophy Points:
    3
    #9
    Jeet,

    It looks like you need to remove the width 100% from the
    
    <div id="main">
    </div>
    
    Code (markup):
    tag.
    
    #main {
       clear: both;
       padding: 10px; /* Try this in mobile version. */
       min-height: 500px;
       margin: 20px auto 20px auto;
       /* width: 100%; */
       box-sizing: border-box; /* Add this if you have padding set. */
    }
    
    Code (markup):
    Also the h5 tag at the bottom of the page is not centered. Add this to the CSS file.
    
    h5 {
      text-align: center;
    }
    
    Code (markup):
     
    brandon_wallace, Nov 15, 2020 IP
    JEET likes this.
  10. JEET

    JEET Notable Member

    Messages:
    3,825
    Likes Received:
    502
    Best Answers:
    19
    Trophy Points:
    265
    #10
    brandon_wallace
    Thanks, I will do this. Although now I hink its working properly. Or are you seeing issues? Is it still going off screen on phones?
    Thanks
     
    JEET, Nov 16, 2020 IP
  11. c1lonewolf

    c1lonewolf Member

    Messages:
    57
    Likes Received:
    21
    Best Answers:
    1
    Trophy Points:
    33
    #11
    You are focusing to much on a cellphone display and not on the actual HTML and CSS... strip it down to nothing and begin with the HTML then work out the css alignments then you can play with javascript. Youre pages should work in browsers first then be adapted to phones. What if someone visits your site and has javascript disabled what will they see?
     
    c1lonewolf, Nov 16, 2020 IP
  12. JEET

    JEET Notable Member

    Messages:
    3,825
    Likes Received:
    502
    Best Answers:
    19
    Trophy Points:
    265
    #12
    They will see the same thing they are seeing now, even without js.
    Only those "show more" buttons will stop working.
    And the buttons on top, "Friends/Fans", but there are other places in the website where they can be accessed.
     
    JEET, Nov 16, 2020 IP
  13. brandon_wallace

    brandon_wallace Peon

    Messages:
    23
    Likes Received:
    4
    Best Answers:
    0
    Trophy Points:
    3
    #13
    Jeet,

    You can and should add a noscript message in the HTML like this. That is for the browsers that have Javascript disabled.
    
    <noscript>
       <p style="color:#FC0000;text-align:center">Please enable Javascript</p>
    </noscript>
    
    Code (markup):
     
    brandon_wallace, Nov 17, 2020 IP
  14. JEET

    JEET Notable Member

    Messages:
    3,825
    Likes Received:
    502
    Best Answers:
    19
    Trophy Points:
    265
    #14
    brandon_wallace
    How do I do this with <button></button>

    My code is,
    <button onclick=" loadURL('url_here'); "> 2 New Friends </button>

    Thanks
     
    JEET, Nov 17, 2020 IP
  15. brandon_wallace

    brandon_wallace Peon

    Messages:
    23
    Likes Received:
    4
    Best Answers:
    0
    Trophy Points:
    3
    #15
    Hi Jeet,
    I do not use onclick="function()" in my HTML. I create an event listener in the Javascript file that listens for a click.
    This is the HTML file.
    
    <button class="bttn">New Friends</button>
    
    Code (markup):
    This is the Javascript file.
    
    const myBttn = document.querySelector('.bttn');
    
    myBttn.addEventListener('click', function() {
        console.log(`Button clicked`);
    });
    
    Code (markup):
     
    brandon_wallace, Nov 19, 2020 IP
    JEET likes this.
  16. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #16
    ... and I take it one step further, where if it's scripting only functionality it has ZERO business in the markup...

    
    var button = document.createElement('button');
    button.textContent = "New Friends";
    button.onclick = loadUrl;
    button.type = "button"; // remember, default is SUBMIT
    
    whatever.appendChild(button); // or insertBefore, or whatever
    
    Code (markup):
    Normally we'd say don't set onclick because other stuff might be trying to hook, but since we literally just created the element it's completely safe.

    Either way remember these are real event handlers, not the pretend HTML bullshit ones.
     
    deathshadow, Nov 19, 2020 IP
    JEET likes this.
  17. JEET

    JEET Notable Member

    Messages:
    3,825
    Likes Received:
    502
    Best Answers:
    19
    Trophy Points:
    265
    #17
    @brandon_wallace
    @deathshadow

    I don't think this type of "click tracking" will be accessible by screen readers...
    Now I understand why so many sites are having text which can be clicked by mouse, but screen reader does not reads it as links...

    I think this is the worst thing that can be done for accessibility.
     
    JEET, Nov 20, 2020 IP
    deathshadow and mmerlinn like this.
  18. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #18
    If you are only doing this to track clicks, you can do it in a way that won't leave screen readers in the cold.

    Code it as a normal anchor, but do an addEventListener that ONLY traps the click and doesn't cancel the event. You can do your scripted click behavior as an intercept WITHOUT overriding the anchor's normal submit behavior.

    The only issue is that non-scripted sends won't be tracked. Which is why on a LOT of websites non-scripted users are oft under-reported in statistics.
     
    deathshadow, Nov 20, 2020 IP
    JEET likes this.
  19. JEET

    JEET Notable Member

    Messages:
    3,825
    Likes Received:
    502
    Best Answers:
    19
    Trophy Points:
    265
    #19
    @deathshadow
    Why do people have non-js browsers anyways?
    All modern ones have JS, including the ones available inside apps...
     
    JEET, Nov 20, 2020 IP
  20. brandon_wallace

    brandon_wallace Peon

    Messages:
    23
    Likes Received:
    4
    Best Answers:
    0
    Trophy Points:
    3
    #20
    Some people disable Javascript for some reason and some websites are almost all Javascript so if Javascript is disabled all they will see is a blank page when visiting a website. There are some text only browsers also that do not use Javascript.
     
    brandon_wallace, Nov 21, 2020 IP
    JEET likes this.