I've got a grid of 2 columns: label and input. I need the column width of the labels to match so the inputs are lined up. I need the labels (and they have to be label elements per deathshadow ) to be right aligned. I've tried right align on label and child div; I've tried margins; etc. I can't figure out how to do it. Jason: the CSS *is* in a file not a style tag How can I right align the labels? https://codepen.io/SLSCoder/pen/GReGrLv <style> #divQBBMgrDsgnBdrCntnr { display: grid; grid-template-columns:6rem auto; grid-gap: .6rem; overflow-y:auto; width:max-content; border:.5px solid gray; padding:6px; padding-left:0.6rem; margin-bottom:0.6rem; } </style> <div id="divQBBMgrDsgnBdrCntnr" > <div ><label for="inptQBMgrDsgnCtrlPGBarBdrWidth" >Thickness:</label></div> <div><input id="inptQBMgrDsgnCtrlPGBarBdrWidth"></div> <div><label for="inptQBMgrDsgnCtrlPGBarBdrRadius" >Radius:</label></div> <div><input id="inptQBMgrDsgnCtrlPGBarBdrRadius"></div> <div><label for="clrpkrQBMgrDsgnCtrlPGBarBdrColor" >Color:</label></div> <div><input id="clrpkrQBMgrDsgnCtrlPGBarBdrColor"></div> </div> Code (markup):
First off I wouldn't since you'd want them to be placed over it when the screen / window gets smaller, so just put them above anyways. But if I had to due to issues like massive number of inputs and/or tabular layouts... well... You've got a bunch of "DIV for nothing" in there making your life harder. First I'd kill most if not all those DIV. Next I'd probably use the labels as wrappers killing off the need for "for" and "id" on any of that. Also I don't know what's giving you those garbage cryptic ID's, but it's not doing you any favors. https://codepen.io/jason-knight/pen/dyrKRXb?editors=1100 I added media queries to show how to flip it back to labels on top when too narrow to keep them to the side. The box-sizing:border-box also makes sure oddball controls like type="color" scales the same as text inputs. Without that it ends up narrower. (Not sure why) "calc" is the big life-saver here, as it lets you subtract the room for the label text, and then normal inline flow behavior does the rest of the work meaning we don't even need to screw around with the "complexities" of flex or grid! And the BR are there so it makes sense for non-visual and/or non-CSS UA's. Easy enough to hide them for screen and put them back for our query.
As always I appreciate your response. "window gets smaller" it's grid. All those "DIV for nothing" are to denote the 2 columns in the grid (and yea it's a pain). It should collapse nicely unless I don't get grid. Most of the time this interface will be used on a computer, not something real small. The whole thing is just too big to do it on a cell phone. You can but . . . That to say, I really like the fields on the right unless the screen isn't wide enough. "garbage cryptic ID's" inptQBMgrDsgnCtrlPGBarBdrWidth It's an input for the Question Bank Manager in Design Mode and is the control progress bar border width. Cryptic to *you* Short variable names and IDs are not our friend. Yea that one's pretty long. "labels as wrappers killing off the need for "for" and "id"" interesting. Do you always put your fields inside their labels? Maybe I can just make it a policy (which means change a whole bunch of label field combinations). "border-box" thanks. I've got that at the top of my css: * { box-sizing: border-box;} "calc": Your solution dictates that all inputs need to be the same size. I realize in my example they are but for this particular interface they're actually: 150 max chars, decimal number, integer. That is, they're not the same. Generally the layout will be multiple labels on the left with fields of various types and sizes on the right. For each label there could be more than 1 field (and sometimes more labels) on the right. Of course - all fully collapsible as needed. I've been struggling with the best way to do this for years. I've been using grid (or lately flex for 1 row - thanks). I'm surprised you don't like grid given all the positive references I've gotten from you on flex. You may have shown me a simple solution. Just make the label display:block. That will instantly make the width 100% and then I can use text-align. Having gone through all this - I think I'll just go with your original solution . Leave them left aligned so if they collapse they'll look OK. Again thanks.
I'd probably still use label, but a span around the text. If you want the input variable width, just set the span width to fixed, move the BR to after the label, and target just inputs of text/email and select to the calculated width. Not sure what you even mean by that. When more than half the web is mobile, devices like tablet are on the table, and users are bumping font sizes as ppi increases, that's a hell of a gamble / assumpiton. That's the thing, it's really easy to do both. And why do you need to know any of that in the client side form? Now, if you did that in the name="" attribute then I could maybe see it... though at that point I'd probably break all that into arrays such as "questionBankManager[designMode][controlProgress][BorderWidth]" Which would be a hell of a lot clearer and easier to process. 'cause you're right: I wholeheartedly agree with that statement which is why slopping a bunch of abbreviated keys together into a single string ID is not a good idea. Just like having ID but no NAME is a really bad idea. Side note, is this a real form, or scripttardery? Remember the FormData object is your friend! And if they're scripting only elements, you should be building them from JS on the DOM, not in the markup! Not always. It used to be some older UA's would actually cock that up, but since IE is no longer relevant and Firefox pulled its head out of its arse with Quantum? I go ahead and do it now. Just because all those pointless for/id really end up pointless code bloat. Sounds more like time to NOT be using flex, grid, float, or even columns. Sounds more like time to wrap with a label, set the label to display:block, and let normal inline-flow do the heavy lifting. It's not that I don't like grid, it's that it feels like a task complexity mismatch. Grid is a great tool just like flex, but it's not a be-all end-all answer for stuff like this. I did a quick rewrite with the extra span for variable width inputs and showing how to pass the name as a structured associative array. https://codepen.io/jason-knight/pen/oNVPjWV?editors=1100
Again thanks Jason: "calculated width" What are 'scripting only elements'? I use hidden fields but not forms or fields just to get or send data. I use ajax. "collapse nicely": I just mean that grid should be responsive. The columns should collapse into rows as needed. "gamble": not really much of a gamble. I'm designing it to be responsive, it's often a lot of fields on 1 page. That's to make interfaces easy to understand and easy to use. I *hate* a checkbox under the third drop down menu #4 inside a window in a fieldset below the screen bottom - . . . I've gotta get a PhD to learn how to use the app, BAD design. So, my interfaces are sometimes rather large which is NOT generally recommended - I disagree with them. I use intro screens on 1st use mostly to assuage intimidation "Only TWO fields are required" "Don't know what the button does? CLICK IT!", etc. "client side form ids": point taken thanks. Still I don't see it hurting anything. When I get this to somewhere around a beta I'll start cleaning it up. Some of those ids aren't necessary at all. I remember you complaining about unnecessary ids. I agree. "slopping a bunch of abbreviated keys" yer serious about this yea? lol "real form": yea they're user forms. "pointless for/id bloat" Yea I see and I didn't like it much. I'll see about doing this when it'll work. "NOT be using flex" hard coded widths - ideally, both the left and right would be 'max-content' ish. It'd be nice if the label column was consistently the longest label width + a little padding and the left column was max-content of widest (responsive) column. Oh yea - it'd be great if elements on a horizontal line remained consistently in line vertically. CSS seems to have a way of putting some elements a little above or below the 'line'. You helped me with that once - you recommended flex which worked. "normal inline-flow" I'm guessing you know that good layout is imperative for clear user understanding. If you lay it out right you can sort of 'guide' the user. Marketers do it all the time. This looks like it would end up being spaghetti fields and labels random stacks of rows - confusing. "quick rewrite": thanks. I may go with it. "questionBankManager[designMode][controlProgress][border][thickness]" WOW! lol The only reason I have for ids is to get the element in javascript or for the labels (which I'll alleviate where I can - thanks). Non unique ids looked like a potential problem across multiple interfaces thus the 'cryptic' ids. I'll strip a lot of them out. Is there any way to do this without hard coding widths? Again thanks for all your help. So, what about a vid of u playing sax? :-\
Elements that are only useful or functional when javascript is present and enabled. If without JavaScript the element does nothing, it has no business in the HTML as you're just confusing users who have it blocked/unavailable. If you're building a crapplet that's kind-of not a thing, but it's still good practice as generating such elements on the DOM makes them easier to hook your events by, without bleeding scope. It's part of why: <button onclick="doSomething(this)"> Is incompetent halfwitted trash. Thus my utter distaste for the wuck-fittery of HTMX Even with AJAX, having a form so you can pull a "new FormData" instead of dicking around with trying to pull things by node walking (dumbass) or ID/selector (double dumbass) is a godsend. If it's a form, use a form tag. If possible, write it to work without your scripttardery first, THEN enhance it with scripting for your AJAX version. It's called progressive enhancement, and it's how to build pages that gracefully degrade for maximum accessibility. To me that just sounds like you have bad labels and aren't using the in-built checks like "required" and proper INPUT types. It's just the more markup you have the longer you delay the loading of sub-files. That's why I (obsess?) about not putting stuff in the HTML I don't have to. Sure it might only be a few bytes here and a few bytes there... but you start figuring in dishpit nonsense like bootcrap, failwind, "HTML First" hypermedia hyperstupidity? Those few bytes quickly become two to ten times the code needed to do the job. Which is how you end up with code that is NOT easier to maintain and work with, no matter how many framework loving nudnik's claim otherwise. To clarify I meant actually having a <form> tag. A LOT of scripting only morons right now are sleazing out "forms" that use nothing but DIV or try to make DIV be a form through "Aria role" code bloat BS. The result being broken inaccessible trash and as I said, not being able to use FormData. "pointless for/id bloat" Yea I see and I didn't like it much. I'll see about doing this when it'll work. The neat part is server-side if the language you're using isn't shite? Take PHP $_POST['questionBankManager']['designMode']['controlProgress']['border']['thickness'] It gets turned into an array of arrays. That's handy as you could for example when working with designMode: $designMode = $_POST['questionBankManager']['designMode']; So you don't have to type the full stack every time. Which is the ancient "brute force" way of handling things. As I said above, if you have a proper <form> you can... https://developer.mozilla.org/en-US/docs/Web/API/FormData Which has been a real godsend the past 13 or so years. Laugh is it's pushing well over a decade old and most people working with JS still don't even know it exists.
Thanks for your response Jason: "Elements only useful or functional when javascript is present": I don't agree. I build apps where people interact with code. The person does something, the CODE responds. Without the 'code' (javascript -> php) nothing would happen. I almost *never* use html submit buttons. I call a javascript function to do things before submission to the server. I appreciate your help but this <div onclick='doMyThing();' onkeyup='if(sKey == '13') doMyThing();' role='button' class='Button1" tabindex="18" > Code (markup): works for me If I lose the onclick I need an ID + document.querySelector("#MyID").addEventListener("click", (evt) => { doMyThing();}); document.querySelector("#MyID").addEventListener("keyup", (evt) => { if(sKey == '13') doMyThing();}); Code (markup): *That* looks like bloat to me. Oh, I should mention that (yr gonna love this) my JS is usually in the same file as the markup. Did I miss anything to make that div a viable button? I don't like <button >. I've tried it numerous times. It's got strange defaults and worse, functional limitations. "AJAX" - I use formData and ajax POST rarely. Usually I just set hidden fields if I need to and submit the form. I use AJAX just to get or send data, not directly related to a user's action. "without your scripttardery" except I don't use submit buttons (ok, very rarely). This is a hard core database app, not a promotional website or eCommerce store. I don't have a problem with users just submitting a form with no client side code - unless - the client side needs to do something (validation?) before sending the user input. "bad labels" eh, I try not to and I use title attributes extensively. "in-built checks" OK school me again lol, what are the "in-built checks"? "proper INPUT types" NO they're SELECTS!!! - just kidding. I use standard html form elements. I build interfaces to be easy to understand and use. A bigger screen is a big help - tablets should be fine. "delay the loading of sub-files" you think exclusively - one time visitors. This is an app. The first time they load it the app may be sluggish. After that the browser will already have most of the files. They download a *lot* more than the html markup. That's usually pretty small - a user interface. Watch a packet sniffer when you open facebook. See how much you download before you do anything. So far my tests aren't showing it to be particularly slow for a new user - faster than FB. I generally don't like frameworks. I write my own code, server and client. I tried bootstrap once - nope - not for me. "Aria role code bloat" - didn't know thanks. Nope I use forms. "$_POST array of arrays." Interesting; I've never used form names like that. I'll keep it in mind. It could come in handy. "$designMode = $_POST['questionBankManager']['designMode'];" - it doesn't really work that way for me. The crazy unique IDs were more so I could LOOK at the id and know what it was. The app knows. More so even, I thought I would use more JS to create interfaces. Some apps are index.php and JS everything from there. I wasn't sure I wouldn't do some of that. I didn't so the unique ids across interfaces wasn't as important as I thought. Still, the id "FirstName" in 5 different interfaces irks me. "get the element in javascript" / "formData" Sorry, I don't get the correlation here. I use formData when I need it and have for years. I use AJAX when I need more data - like details on a record for a popup from a list. Or to send data like the user sets something - the app sends it to the server to save it. The user doesn't have to click 'save'. Your a great help to this forum. I hope they realize how valuable you are to them. AND - you play SAX - well enough to open for Michael Brecker - that's impressive man. Thanks again for your help.
I think you're missing my meaning. I'm saying they don't belong in the MARKUP. That does not mean you cannot create them on the DOM. Remember, the markup gets turned into the DOM, but from there you can add to the DOM from the scripting without writing any markup! I'm not saying don't add them, I'm saying don't add them in the place where it could confuse users who don't get your scripting. Admittedly if you KNOW the only UA's accessing it -- something like Electron or a native VS app -- then you're ok... but users work in places that block JS for security, or for bandwidth, or out of just plain distrust. Thus if it's "web facing" build your JS only stuff from the JS, and be sure to give it a nice big noscript warning. And how exactly does keyboard navigation let the user focus a DIV? Or the role bullshit? Why aren't you using <button type="button"> and why are you shitting on the global namespace like it's still the dawn of the browser wars? Much less there is no onkeyup event for a DIV, so how the blazes does that even do anything? parent.appendChild( Object.assign( document.createElement("button"), { className : "doMyThing", onclick : doMyThing, type : "button" } ) ).append( "Content of the <button> here." ); Code (markup): Where parent is the element I want to append the button to. And unless "doMyThing" is used on a lot of other elements, you might even be able to sneak by with an anonymous. And being button of type button, no preventDefault worries, no dicking around intercepting the keyboard, and if your DOM order is worth a damn you likely don't have to screw around with tabindex anyways. Though I usually have helper functions like: const make = (tagName, attr = {}, ...append) => { const e = Object.assign( document.createElement(tagName), attr) ); if (append) e.append(...append); return e; }, // make makeChild = (parent, ...makeArgs) => { return parent.appendChild(make(...makeArgs); }; // makeChild Code (markup): So I can just do this when making my scripting only Elements. makeChild( parent, "button", { className : "doMyThing", onclick : doMyThing, type : "button" }, "Content of the <button> here." ); Code (markup): Though the way I "really" do it involves a small library that would reduce that to: parent.__make( "button_button.doMyThing", { onclick : doMyThing }, "Content of the <button> here." ); Code (markup): Which I'm hoping to release for public use by the end of the month, March at the latest. The whole core concept is to reformulate HTML into JSON. It's fun to be able to do this: const /* I'm using a TextNode here to demonstrate how we can store a node on a variable, and change its content after everything else is built. */ grandTotalText = new Text("0"), productTBody = document.createElement("tbody"); /* replace document.body with whatever parent container you want. */ document.body.__make( "table", [ "caption", "Products" ], [ "thead", [ "tr", [ "th_col", "Product Name" ], [ "th_col", "Quantity" ], [ "th_col", "Unit Price" ], [ "th_col", "Total" ] ] ], productTBody, [ "tfoot", [ "tr", [ "th_row", { colSpan : 3 }, "Grand Total" ], [ "td", grandTotalText ] ] ] ); let grandTotal = 0; /* let's assume this is a XMLHttpRequest we're plugging values in from, where we set responseType to "JSON" */ for (product of event.currentTarget.response) { const total = product.quantity * product.unitPrice; grandTotal += total; productTBody.__make( "tr", [ "th_row", product.name ], [ "td", product.quantity ], [ "td", product.unitPrice ], [ "td", total ] ); } grandTotalText.textContent = grandTotal; Code (markup): So that such "this is useless without JS" stuff isn't in the HTML file, AND we have all the hooks to easily populate and modify it and its values. Again, "Coming Soon" to an intarweb near you! And of course in production I'd have that inside a {} so the let/const present don't bleed scope, making merging disparate codebases easier since they can't see each-other. That or use modules if you don't care about legacy UA and want to selectively share scope. When I say "doesn't belong in the markup" that's the alternative approach I'm advocating. Scripting off, the table itself never even exists so the user only gets what works scripting off. Even if it's only a <noscript>. I wrote about that not to long ago, how many shoddy crapplications don't even tell the user "no soup for you" when they're scripting only, and confuse them with a page full of broken chazerei. https://medium.com/codex/please-tell-users-when-your-application-isnt-for-them-84e62c5da850 Seriously though using a non-focusable DIV and then throwing ARIA, keyboard interception, and so forth at it just to not use the CORRECT FLIPPING TAG?!? 100% hurr-durrz and whoever told you that's an acceptable coding technique needs a quadruple helping of sierra tango foxtrot uniform. So no caching across visits, no pre-caching across sub-pages if any, and delayed HTTP parallelism. It sounds like you might not know that the default type for BUTTON is "submit". Thus you either need to set event.preventDefault() in the event handler (dumb) or set type="button" so it doesn't submit. A LOT of people get tripped up by the default type="" for <button> is "submit" and not "button", or fail to realize the massive difference in behavior betwixt the two. Though your sharting scripting at it with onclick or onkeyup is likely also not helping matters. The difference between the JS side Element.onclick or Element.addEventListener methods and the HTMP attribute are night and day... the latter being outdated, outmoded, and making you work harder, not smarter. Especially when the latter means no scope isolation. Putting role="button" and tabindex="10" on a DIV is ignored in nearly every accessibile UA. Aria roles are bullshit to let people abuse the wrong markup and tell non-screen media to go f*** itself. It is a basic accessibility violation to just flat out use the wrong tag. Which is why as an accessibility advocate, I've lost all faith in the WAI and anything they have to say. Well, one of many reasons. For all the claims of ARIA "helping" accessibility or making HTML better, it's 100% bullshit. Just use the correct blasted markup! Which means pageloads, which is why slopping your scripttardery into the markup isn't very bright from a caching standpoint. The what now?!? You just said you were using normal forms, so how are those submitting if you're not using <submit>? If using form.submit() in your JS where does the AJAX come in or even the need for any of this scripting? Which makes me think you might be using a bunch of JavaScript for nothing. Hardcore database apps should have LESS need of all this scripted crap, not more. There is no "need" for client-side validation because you cannot trust client-side validation! That's the most basic rule of handling user input as your JS can be pimp slapped aside by any script-kiddie with an axe to grind. Client side validation is 1) something built into HTML 5 that you might enhance, but 2) cannot be trusted to work so you have to check it again on the server so 3) write a normal form and spit it back at the user on error. Enhancing it for user convenience? Fine. Relying on it or treating it as a neccessity? No. Just... No. Attributes and types like: type="email" type="date" type="number" pattern="regex here" required All the stuff HTML 5 can do for you out of the box so you don't need JavaScript for any of that crap anymore. "proper INPUT types" NO they're SELECTS!!! - just kidding. I use standard html form elements. I build interfaces to be easy to understand and use. A bigger screen is a big help - tablets should be fine. And if you can reduce the time of that sluggish first load, why wouldn't you? OF course if as you said you're slopping everything into the markup, it's likely NOT being cached unless you're 100% reliant on 100% static markup. Which is a shockingly bad way of building much of anything. And even then with packets delivering files via different routes, the sooner you can start HTTP parallelism and if you micromanage it with preload links? Much less larger files are more likely to be purged from cache when the user runs out of that limited resource. Thus why Google's "set the cache expiry really high" is mostly bullshit I only do to shut pagespeed and/or lighthouse up about it. I prefer a network waterfall in the browser, but yeah I get you on that. Thing is though being fast compared to FacePuke is like beating a sloth in a race. I was surprised when I found out you could do that like 20 years ago. I don't see it used as much as it should be, particularly in places where it could pay real benefits. Though like all user data don't blindly trust the indexes / keys and test it at each and every blasted step. NOTHING that comes from the client-side to the server should EVER be trusted to be kosher. That's why I avoid ID's by wrapping label around inputs, AND if it's scripting only I build it IN the scripting ON the DOM. (createElement with append / appendChild / insertAdjacentHTML) I'm just saying that for a submit you'd hook the form.submit and get the form inside the event via event.currentTarget, or if doing an auto-save based on an <input> changing you just hook oninput and in the event grab event.currentTarget.closest("form") Assuming you're using real events and not the derpy global scope bullshit onevent attribute in the markup we were told 26 years ago to stop using; but everyone keeps shoving their craniums up 1997's rectum instead. (see HTMX for more such inane rubbish) And that's the rub. Slopping it all in the markup? Scripting only elements in the markup? onevent attributes in the markup? No... you're building monuments to the ugliest of mid-90's development. JUST like the people who create frameworks do.
This response was a great read but painful. I hate being told I f**** again! thanks:-/ I learned quite a bit from it (OUCH!) and I want this app to work right. My problem is, I don't want to learn JS. I want to put this app on the market and hire somebody like YOU to clean it up. I can't believe there's no key event in a div; coulda sworn I tested that. Hey, it sees a TAB just fine. They coulda made it see ENTER. OK you win. The button *must* see the ENTER key press. I'm changing all those divs to buttons and I'll just deal with the restrictions and find & reset all those defaults. I'm sure I've got 500+ button divs in this app - I'm gonna be all day. I think that it's type was submit by default was part of my problem with buttons. I'll be sure to set type as button. Thanks. Yea, I'm old school. I had to strip my first css because the browsers couldn't do it yet. If I was going to write the way you suggest I'd do *everything* in JS. The only html file would be index.php. All markup would be written in JS and mostly taken from template scripts. I'm not real concerned with speed so far. The app is responding without significant delay. So far you haven't convinced me that putting stuff in the markup is bad. Speed isn't a sufficient argument; the app runs fine. Maybe under high loads I'll reconsider (but I'll have the $$ to deal with it). no-script is irrelevant because everything is under a login that filters out no-script. Overall the amount of code is *significantly* lower if I use the markup than if I write everything in JS. Yes, all validation is done on the server and the JS validation is for the user. I looked into the built in validation and didn't like it. I built my own using attribute data-vld. I'll stick with that thanks I'll probably separate the JS from the files once I'm in production but it was just too hard to develop with everything in different files for 1 interface. I tried it. Right now all the PHP, JS and Markup for an interface are in the same file for MY convenience. I do have a need for the ability to convert HTML to JSON and back. The app includes an api that will deliver reports. It responds with JSON. I wanted to include the HTML doc within the JSON format. I gave up on that. OK, I've gotta go change forty gazillion div tags into button type='button' tags now. Thanks again for all your help.
It's what I do. To be brutally frank (It's what I do), that means you don't actually want to build an app... or not take the steps you should have before you deploy it in the wild. As I often joke, there's a reason it's called "Work" and not "Liver-Lips McGrowl's Fun-Time Jamboree." Not sure what you mean by that, there's not a lot set on it you need to mess with. If you set type="button" you're set on event handling. From there it's just: display:block; border:0; padding:0; margin:0; background:transparent; color:inherit; Code (markup): That's really something that trips up a LOT of people when they start using them for scripting hooks and/or learn to use them instead of <input type="button"> You might not even need .php for the index, only what JS would call to pull data. The thing is we're basically talking technical debt. In the rush to get out the door, it's easy to forget a lot of things are much harder (and by extension expensive) to do "after the fact". It's the literal ounce of sweat to save a pint of blood. I mean how many concurrent users are you testing right now? You'd be surprised how as few as 100 users at once can bring what seemed "acceptable" to its knees. I've seen it far too many times the past 20 years or so given how most of what's out there is in fact riddled with bloat. It's been REALLY bad since stuff like React, Angular, and so forth got involved. Would that login be on the same index.php, or a separate URI? Remember, people like to be able to hot-link to content; though that depends on what your content is and/or if you even want users to be able to do so. It's why if you're updating your main content one should non-destructively push to the history/address bar and update the TITLE element content. Depends on how much you're repeating the same data. Using the markup that ends up a LOT more code since a template function client-side can plug data into the DOM without markup. This simplifies what your server-side code has to send to the point you can JUST send the data, not the data in markup. It's often a lot nicer to be able to echo json_encode($stmt->fetchAll); Code (markup): And be done with it. Particularly given how much that can lower the hosting costs when real traffic comes along. Thing is you can actually enhance the mechanism with JS to both add extra messages and to hook the error result. What part of it didn't you care for? Was it the appearance 'cause that seems to remain most people's biggest objection to it. That could be fault of your workflow or editor, not keeping it separate. I've always found the opposite to be true when it comes to keeping markup, style, and scripting separate, but I'm also a multiple display user so I can have them in separate windows side-by-side next to each-other. Which is another reason I dislike IDE's, RAD, or whatever it is the kids are calling them these days. They love to crap everything into one useless window with no ability to tile, and suck down space with reference crap on screen all the blasted time. It's like "Just show me JUST the code in it's own blasted window!" When you can put them side-by-side the "problems" tend to evaporate. Thus my left display shows code, center display shows browser, right display is used for social media, forums, chat windows, zoom, and so forth. I don't know how you'd find that convenient, having to wade through all that code slopped together, but you're in the majority on that. I most certainly am not. You're much better off applying the JSON data to a DOM structure (not markup) from the client side scripting. Just send the data and let JS do the heavy lifting on that. There is the new <template> tag, but to plug data into it you have to waste a metric arse-load of time with getElementById or querySelector on it, then copy its contents to the live DOM from the template fragment... It's more of a pain in the ass than manually just hand coding document.createElement with Object.assign and Element.append / Element.appendChild On top of <template> sharting markup into the DOM that's client side scripting only, meaning it too has ZERO business in the markup either and only further proving to my mind that the WhatWG had even less business making HTML 4 Strict's successor.
"don't actually want to build an app" yea, just getting tired. I've studied JS as long as you have or close - just not as well I'm quite sure I don't retain information as well as you. That is, I've got a memory like a sieve. Too much smoke as a teen :-/ About your candor, I appreciate it. It hurts to know you're wrong but stupid to lie to yourself or refuse to learn. With the truth my app will be a better app. Again thank you. Your offense is largely entertaining - I held a Journeyman electrical contractor's license 8 years. I'll bet it scares a lot of people off though - You don't *really* mean yer gonna kill me in my dreams do you? Bloodline OK back to work. Now you've got me a *little* concerned. It almost surprised me that you like the pure JS idea. My concern is time and money. I built it the way I did and now's a bad time to try to overhaul it. The question is: How much better in performance would pure JS be over the existing design? How long would it take me to redevelop it? What are the odds that *if* I run into trouble in operation redevelopment will be insurmountable? I think redevelopment would be 6 months+. Everything client side would have to be rewritten. As it is, I'm going to have to keep the design the way it is and I'll keep what you're saying in mind. I'm going to run out of time. I like the idea but I don't have the time/resources to overhaul it now. I've developed apps like this for 20 years and never had any speed problems. I'll take my chances Multi screen - must be nice I use a laptop, notepad++ and FileZilla. I use a split screen in notepad++ a lot. I'd love to have 3 big screens. The button div tags have all been converted to buttons - type = 'button'. A button should NOT submit a form by default - an evolutionary foopa I suppose. The buttons seem to be working fine - thanks Yea you're right. It didn't need to be index.php. As it is, the login page is stand alone login.php. Thanks again for your endless insight.
I smell of death I reek of hate I will live forever -- edit -- though this is my favorite version. Ukelele man. Where's Tiny Tim when we need him?