 Display, Differences between computer and mobile screens |
  |
| TW Allen |
 Nov 7 2023, 01:14 PM
Post
#1
|
|
Member  Group: Members Posts: 42 Joined: 12-April 21 Member No.: 27,890  |
Noobie here.
Ref: https://allendesigns.com/residential_remodel_projects.html and: https://allendesigns.com/projects/22310/22310.html Both display as I intend on my computer. However, on my mobile screen, everything is aligned to the left margin. Why is that? Thank you, Bill |
  |
 
|
| Christian J |
Nov 7 2023, 04:51 PM
Post
#2
|
|
. Group: WDG Moderators Posts: 9,661 Joined: 10-August 06 Member No.: 7 |
QUOTE(TW Allen @ Nov 7 2023, 07:14 PM)  on my mobile screen, everything is aligned to the left margin. In which mobile browser? In my desktop browser's mobile simulation mode everything is centered. |
|
|
|
| TW Allen |
Nov 7 2023, 08:11 PM
Post
#3
|
|
Member Group: Members Posts: 42 Joined: 12-April 21 Member No.: 27,890 |
QUOTE(Christian J @ Nov 7 2023, 04:51 PM) QUOTE(TW Allen @ Nov 7 2023, 07:14 PM) on my mobile screen, everything is aligned to the left margin. In which mobile browser? In my desktop browser's mobile simulation mode everything is centered. Android. My intent is for everything to be centered. Thank you. |
|
|
|
| Jason Knight |
Nov 7 2023, 10:03 PM
Post
#4
|
|
Advanced Member Group: Members Posts: 103 Joined: 25-December 22 Member No.: 28,719 |
There are a number of things wrong with your HTML, the least of which being that it's got TWO instances of its header back to back. If you view-source from the client side you've got two doctype, two openings of body, etc, etm.
That could be causing your issues. Do we see the problem here? CODE !DOCTYpE html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="description" content="Allen Designs, a small structural engineering firm focusing on single family residences, additions, remodels, panorama doors, bearing wall removal, ADUs and much more."> <link rel="stylesheet" href="./css/allen.css"> <title>Allen Designs Consulting Structural Engineers Home Page</title> </head> <body> <!DOCTYpE html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="description" content="Allen Designs, a small structural engineering firm focusing on single family residences, additions, remodels, panorama doors, bearing wall removal, ADUs and much more."> <link rel="stylesheet" href="css/allen.css"> <title>Allen Designs Consulting Structural Engineers Home Page</title> </head> You're also missing what's called a "viewport META". Early in modern mobile's history websites weren't built for mobile devices, so such handhelds applied all sorts of their own -- inconsistent -- rules to try and make non-mobile sites mobile friendly. This behavior can be willy-nilly across devices, so we usually say: CODE <meta name="viewport" content="width=device-width,initial-scale=1"> To tell mobile devices not to lie to us about their resolution and to not apply any arbitrary scaling or re-arranging of the content. No guarantee it will help in this case, but if you're having mobile issues it's a good place to start. There are other values people declare on viewport META that I suggest you avoid. Most of them just screw over the user's ability to zoom. Your stylesheet <link> being for setting up screen media appearance should say media="screen" on it. That way you're not sending screen only layout to screen, braille, speech/aural, or search. Though some search engines scan the screen stylesheet looking for dirtbag SEO abuse. From there, you've got some really nonsensical HTML. you're a beginner, that happens to most people. You've got DIV for nothing, DIV doing heading's job, double-breaks doing padding's job, HR where there's no topic change, tables for layout like it's still 1997... Whatever source you're learning HTML from? STOP. Go follow some tutorials on MDN. ESPECIALLY if you care about Mobile. Generally speaking HTML is for saying what things are. Structurally, grammatically. NOT WHAT YOU WANT THEM TO LOOK LIKE. Anyone telling you to use classes like "center" or using tables for a menu? Doesn't know the first thing about HTML. That might sound harsh, but that's the truth of it. Though interestingly your commented out table is actually tabular data, but it should have <th scope="row"> in there. Another tip, if every element inside a parent is getting the same class, NONE of them should have classes. We have selectors and combinators in CSS for a reason. And yes I realize between that and the "don't say what things look like" I'm sharting on how scams like bootcrap or failwind "do the deed". They're fraudulent junk, avoid them if at all possible. Same goes for all HTML/CSS frameworks and the LIES they peddle about magically being "easier" or "better". Further exacerbating matters is that in your CSS you're declaring things in pixels. This was never a good practice and today really has zero business being done. The measurements you should have used are EM and REM. REM is based on the browser default size -- a value users can change to their preference. It has no fixed relationship to pixels though for most people it's 16px. On my laptop 1rem is set to 20px. On my workstation it's 24. On my media center with the 4k "ten foot" interface I've got it bumped all the way to 32. For users like me, PX is a middle finger to accessibility. EM is scaled off the current font-size. For example if you had a anchor inside a H1 where the body is at 1rem, the H1 is set to 1.5em, and the anchor is set to 2em, you get 3rem spit out the other side. This multiplicity can be advantageous in many cases and was how we had to do things before REM was real world deployable, but today for most tasks, just use REM. Anyone telling you otherwise isn't qualified to build websites. The only exception is for scaling raster images in cases where you don't want blurring. So... how about I do a rewrite to illustrate what I mean? Gimme a few minutes and I'll belt something together. When I do these types of rewrites I do a breakdown so you can follow along and understand the how/what/why. Might as well try to be useful to someone whilst fighting insomnia. Give a man a fish, he eats for a day. Teach a man to fish, and he bores you to death on the Outdoor Life Network. |
|
|
|
| Jason Knight |
Nov 7 2023, 10:31 PM
Post
#5
|
|
Advanced Member Group: Members Posts: 103 Joined: 25-December 22 Member No.: 28,719 |
And here we are. The rewrite is here:
https://cutcodedown.com/for_others/TWAllen/template.html As with all my examples the directory is wide open for easy access (feel free to roam) https://cutcodedown.com/for_others/TWAllen/ And you'll find a .rar of the whole thing in there. Let's talk markup. Side note, I "hash linked" all the href so the navigation is disabled for the demo. The <head> of the rewrite isn't too far off from what you had -- though I have only one of them. CODE <!DOCTYpE html><html lang="en"><head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width,initial-scale=1"> <meta name="description" content="A small structural engineering firm focusing on single family residences, additions, remodels, panorama doors, bearing wall removal, ADUs and much more."> <link rel="stylesheet" href="template/allen.screen.css" media="screen"> <title>Allen Designs Consulting Structural Engineers Home Page</title> </head><body> I condense doctype through <head> to a single line as a reminder that nothing should ever be pasted between those tags. I do the same for </head><body> and </body></html> The viewport meta was added, I removed the name of the site from it as that's redundant to <title> and could trigger a duplicate content penalty. VERY unlikely, but it happens. That's where black-hat SEO scammers oft screw their clients. And of course the stylesheet got the proper media attribute so we're not sending it willy-nilly to devices that don't care. You have a clearly defined "header" for the page. Thus I used a <header> tag. CODE <header> <hgroup> <h1>ALLEN DESIGNS</h1> <p>Consulting Structural Engineers</p> </hgroup> <nav id="mainMenu"> <ul> <li><a href="#index.html">HOME</a></li> <li><a href="#about.html">ABOUT</a></li> <li><a href="#twa.html">TWA BIO</a></li> </ul> </nav> <address> 27201 Puerta Real #300<br> Mission Viejo, CA 92691<br> (949) 248-8588 </address> <a href="mailto:bill@allendesigns.com"> Bill@AllenDesigns.com </a> </header> I moved the hgroup before the navigation because the H1 -- THE heading that should describe EVERYTHING on the page -- should be the first content-bearing element on the page. No matter how many black-hat SEO scammers try to claim otherwise.. HTML has headings for a reason, that reason is to convey structure and aid in navigation for people NOT using a screen and a mouse. That's one of the biggest mental hurdles to jump when working with HTML. It's about MORE than visual appearance for screen, in fact it's not even FOR visual appearance for screen! I used the "new" HGROUP tag to group the heading and its tagline. This is the "new" format for HGROUP where the previous version was kinda dumb. I'm still not wild about it, but according to the HTML specification this is exactly how it should be used. The current rules for HGROUP is that it starts with zero or more paragraphs, followed by a numbered heading, followed by zero or more paragraphs. The <nav>igation got an ID so it can be hashlinked to later if desired for things like hamburger menus, and as a hook for style. A lot of people will say "don't use ID that way" but they're usually the same clowns who tell you to throw classes for NOTHING at every blasted element. If you bother using proper semantics (tags ot say what things ARE) you can skip a LOT of the "classes for nothing" nonsense many of the less reputable tutorials and predators online peddle. A menu is still a list of choices. In no particular order. That's <ul>'s job. Just because you have <nav> doesn't mean you can slop any-old-markup in there. Your menu is not tabular data iwth rows and columns forming a semantic relationship, so TABLE is just flat out the wrong tag! For YEARS the <address> tag was useless as it was supposed to contain the e-mail or contact information of the site maintainer, something most people didn't even want on the site. With HTML 5 they finally lifted that restriction and said "fine, use it for actual addresses for all we care". So, here we go! The anchor I left alone, though really putting an unencoded e-mail on a website is not good since you're begging for spam hell... but a full blown contact form is likely a bit beyond your skillset at this point. Baby steps. Next starts the main content. We have a tag for that too. CODE <main> <p> Specializing in the structural engineering of wood framed structures with the objective of producing clear and concise structural plans and details saving time and money at the jobsite. </p><p> Specifically, over the past 15 years, Allen Designs has focused on residential remodeling, a sometimes challenging niche market. </p> <main> lets non-visual users have a "landing" to skip to the start of the actual "meat" of a page. It's for users using screen readers, braille readers, TTY and the like. We used to add what were called "skip to content" links for this... the main tag does away with that. You had two paragraphs here, not one paragraph with a double-break. If you've ever used a screen reader the stilt a double-break makes can be... annoying. Your next section... gets a <section> tag. It has a subsection that would likely be one of many, so that is considered an <article>. Not as in a 'newspaper article" but as in a "article of clothing" or "article of confederation". An item in a set. I give this an ID so that it can be hashlinked or hooked for style specific to it. CODE <section id="remodels"> <h2>Residential Remodels (Partial Project List)</h2> <p> click on project name or image for more detailed information (structural drawings) </p> <article> <hgroup> <h3><a href="#projects/22310/22310.html">Dupree Residence</a></h3> <p>Oceanside, CA</p> </hgroup> <a href="#projects/22310/22310.html"> <img src="projects/22310/22310FloorFramingPlan-600px.png" alt="Floor Framing Plan" class="plate" > </a> <p> Remodel to existing single family residence including moving the entire rear wall outwards. </p> </article> <!-- #remodels --></section> The H2 is the title of the section. The H3 is the title of the subsection/article. The basic rule you should TRY to follow is: H1 -- THE heading describing what EVERYTHING on the page is about. A "Page Title" as it were. This might sound redundant to <title> but fact is stuff in <head> is "non-render" and thus many non-visual user-agents (a browser is a UA but a UA isn't always a browser) don't tell the user that. H1 is your document "root". Think of headings like a giant tree. An H2 marks the start of a major subsection of the page. In the old days before we had <main> The first one on the page marked the start of the main content. H3 marks the start of a subsection of the H2 before it. H4 marks the start of a subsection of the H3 before it. Care to guess what H5 and H6 mean? This is why if you see sites where the first heading isn't a H1, or they skip over heading depths as the heading number climbs -- like jumping from a H2 to a H5 -- or people pair headings back-to-back for heading and tagline? Well, you're looking at HTML written by inept ill educated clowns. Many of whom claim to be "experts" I added a class to the image to hook it for "plate" behavior. Saying that it's a "plate image". I'd be tempted to use <figure> here, but wasn't sure what text to put in the related <figcaption>. Plate is about as close as I come to using presentational classes. (classes to say what things look like as opposed to the PROPER use of them for meaning) The closing comment is something I like to do when a tag that has an id is closed far, far away. Generally my rule is that if it's more than 12 lines away, add a comment. There's a bug that comes and goes in FF that screws things up if a comment ends up between sibling level elements. Putting the comment before the close prevents this issue from rearing its hugly fead. I also don't say "end" or anything like that because that's what the slash in </section> means. It's just nice to know what <section> or <div> I'm closing. From there we just close the remaining open tags. CODE </main> </body></html> Easy-peasy, lemon squeezy. Alright, probably butting heads with the post size limit. Next post I'll break down the reasoning in the CSS and the minor layout differences. Laugh is, took me longer to write this explanation than it did the HTML and CSS. For a beginner you weren't ridiculously far off... you just haven't learned proper semantic markup. |
|
|
|
| Jason Knight |
Nov 7 2023, 10:55 PM
Post
#6
|
|
Advanced Member Group: Members Posts: 103 Joined: 25-December 22 Member No.: 28,719 |
Alright, let's talk the CSS of my rewrite. Follow the bouncing ball at:
https://cutcodedown.com/for_others/TWAllen/...llen.screen.css I start out with what's called a "reset". Resets exist because what things look like was never supposed to be any of HTML's business, so prior to CSS every browser maker had their own rules. These preferences slipped into the early CSS implementations so that every browser maker's "defaults" didn't agree with each-other. A reset attempts to fix that since even today, gecko (firefox), blink (chrome-likes), and webkit (safari) are NOT all on the same page. FF is particularly egregious in this regard. There are smaller resets like the so-called "universal reset" of: CODE * { margin:0; padding:0; border:0; } But that can wreak havoc on styling form elements between FF and RoW. (Rest of world). There are larger resets like Eric Meyer's "Reset Reloaded" or the bloated trash found in most frameworks, but those give resets such a bad name many developers rail against the very concept of using a reset at all... which leads to even more code than the reset and inconsistent broken layouts across browsers and devices. At half a k, the reset I use is small enough to be easily dismissed in terms of "performance hit", only targets what needs to be fixed, sets up useful stuff like making width be around the border not inside the padding, and is what I would say lands it in the Goldilocks zone. After the reset I set up the general page behavior. CODE body { text-align:center; padding:0 0.5rem; font-family:arial,helvetica,sans-serif; background:url(images/graybrck.jpg); color:#069; } I center text site wide, and add a minimum side gap so when the screen gets small the text isn't rubbing up against the display edge compromising legibility. Apart from that, given what you had for code you should be able to digest that. CODE body > header, body > main { max-width:52rem; margin:1rem auto; } The primary outer containers get a max-width on them so that long paragraphs don't become unwieldy and hard to follow. Max-width is your friend, use it. A lot. The auto-margin centers the header and main tag, and the top/bottom margins space things nicely. CODE body > header { margin-bottom:2rem; } Give the header an extra push. Yawn. CODE body> header > hgroup, #mainMenu ul { display:flex; align-items:center; justify-content:center; flex-wrap:wrap; } body> header > hgroup { flex-direction:column; } Flex is fun stuff. It can be used to make things behave a lot like tables without using tables for layout. We want the menu UL as a line, we flex it. We want things centered horizontally and vertically, we go ahead and set that too. Because the header HGROUP and #mainMenu UL get the same flex, I put both seelctors here. The only difference is that HGROUP flexes as a column. Why flex a column there? If we just set border-bottom on the H1 for that line you had, we'd end up having it go full screen width. Setting a manual width could kinda do it, but it's better to just have stull like that work automatically. The child of a flex-box when set to "center" behavior on an axis will shrink to the size of its content! Boom problem solved. Thus that divider goes on the H1 easy. CODE h1 { font-size:2.625rem; border-bottom:0.25rem solid #069; } Notice the use of REM for font size. Again, PX is junk. Don't use it, you're just making your pages less accessible. The menu is pretty simple: CODE #mainMenu ul { list-style:none; gap:5rem; margin:1rem 0 2rem; } #mainMenu a { display:block; padding:0 1rem font-size:2rem; } Perfectly good ID tells us what we're styling. Turn off bullets, we already set it to a flex container defaulting to row, and "gap" sets the space between our LI. Margin to space things apart. The anchor I like to set to display:block just in case I later want to add vertical padding and have it actually obeyed. The paragraphs inside <main>... CODE main p { margin:1rem 0; line-height:1.5; } Get margin top and bottom, and a taller line-height. With long lines of wrapping text a taller line-height can greatly improve legibility whe trying to follow it as it wraps back and forth. Combined with our max-width restriction on <main>, we get far more legible text than you had. Though side note, this giant fist-in-the-face 24px flow font is a bit of a wonk, even when stated as 1.5 rem. Real "punch in the face". CODE section:not(:first-child) { margin-top:1rem; padding-top:2rem; border-top:0.25rem solid #000; } top margin and top padding sace the border nicely. You had a <hr> there which is just the wrong markup since it would be redundant to both <section> and <h2> from a semantic (grammatical / structural) standpoint. Remember -- or if you've not heard this -- <hr> does NOT mean "draw a line across the screen". It means horizontal rule, as in a GRAMMATICAL break in thought that doesnt' warrant a new <seciton> or numbered heading. Almost all HTML tags have MEANINGS and that means if you're choosing your tags -- and by extension attributes, classes, or id's -- based on appearance when writing your markup, you're choosing all the wrong code for all the wrong reasons! Anyone telling you otherwise is packing your fudge. With raisins and peanuts. Finally the plate image: CODE .plate { display:block; margin:1rem auto; max-width:95%; } Since we just want it centered display:block removes a ton of headackes, simple margin to center and push it away from sibling content, and a max-width so the image is forced to shrink as the display gets too small for it. And... that's it. How I'd go about what you were trying to do. Should work well across most if not all mobile devices, though again those monster font sizes are probably not doing you any favors. Take your time, digest what I've written, go over it, and if you have questions fire away. I'm here to help and educate. |
|
|
|
| TW Allen |
Nov 7 2023, 11:33 PM
Post
#7
|
|
Member Group: Members Posts: 42 Joined: 12-April 21 Member No.: 27,890 |
Thanks, Jason.
A lot to digest, but I will, and report back. |
|
|
|
| TW Allen |
Nov 8 2023, 08:46 AM
Post
#8
|
|
Member Group: Members Posts: 42 Joined: 12-April 21 Member No.: 27,890 |
First of all, please recommend a good reference for learning HTML properly. I have a couple, the latest one published in 2019.
Thank you |
|
|
|
| Jason Knight |
Nov 8 2023, 07:45 PM
Post
#9
|
|
Advanced Member Group: Members Posts: 103 Joined: 25-December 22 Member No.: 28,719 |
QUOTE(TW Allen @ Nov 8 2023, 08:46 AM) First of all, please recommend a good reference for learning HTML properly. I have a couple, the latest one published in 2019. Sadly most of what's in print -- even new -- is 20+ years out of date because the authors themselves aren't qualified to be writing about it. What I recommend to most beginners is the MDN website. The Mozilla Developer Network. It follows the specifications, translates the spec into something us "mere content creators" can understand, and doesn't come with the "baggage" of disinformation, misunderstandings, incomplete explanations, web-rot, and sometimes outright lies you find on sites like W3Schools or TutorialsPoint. Or worse the agenda of trying to sell you something like meaningless "certifications" I don't agree 100% with everything they say -- big shock -- but it's hard to go wrong with MDN's Tutorials: https://developer.mozilla.org/en-US/docs/Web/Tutorials OR any of their references. Once you have the syntax of HTML down, I would suggest just reading the HTML reference for each and every tag. Might seem like a slog, but each of those pages aid in better understanding it. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference https://developer.mozilla.org/en-US/docs/Web/CSS/Reference https://developer.mozilla.org/en-US/docs/We...cript/Reference Don't try to memorize every little detail. Just learn what exists, and when you use something refer back to the reference to make sure you're using it right and/or what it's for. You can't possibly remember it all, just make yourself aware of what options exist. Why light money on fire with books that aren't even usually correct, on something that is inherently free online? In the HTML reference though there is one BIG thing to learn. What tags go where and when. There are rules like the fact that the only valid child of a OL or UL is LI. Or the only valid children of a TR is TD and TH. That is where most beginners make the most mistakes, tossing tags in with no care for the rules. Like if you go to MDN's reference page for the LI tag and scroll down to the technical summary: https://developer.mozilla.org/en-US/docs/We...chnical_summary Permitted content Flow content. Permitted parents An <ul>, <ol>, or <menu> element. Though not a conforming usage, the obsolete <dir> can also be a parent. You'll learn them over time, but really if you are using a tag research what is and is not allowed. This is why I point people at the element reference as a learning tool because you need to know what tags exist, what they are for structurally and grammatically and where they can and cannot be used. A detail a lot of tutorials and books seem to gloss right over. This post has been edited by Jason Knight: Nov 8 2023, 07:46 PM |
|
|
|
| Christian J |
Nov 9 2023, 05:33 PM
Post
#10
|
|
. Group: WDG Moderators Posts: 9,661 Joined: 10-August 06 Member No.: 7 |
QUOTE(TW Allen @ Nov 8 2023, 02:11 AM) QUOTE(Christian J @ Nov 7 2023, 04:51 PM) QUOTE(TW Allen @ Nov 7 2023, 07:14 PM) on my mobile screen, everything is aligned to the left margin. In which mobile browser? In my desktop browser's mobile simulation mode everything is centered. Android. My intent is for everything to be centered. Thank you. In my Android browsers (Brave, Vivaldi and Firefox) the first page is centered too. Are you sure you're not viewing an older, cached version in your phone? |
|
|
|
| pandy |
Nov 10 2023, 01:40 AM
Post
#11
|
|
🌟Computer says no🌟 Group: WDG Moderators Posts: 20,732 Joined: 9-August 06 Member No.: 6 |
QUOTE(Christian J @ Nov 9 2023, 11:33 PM) In my Android browsers (Brave, Vivaldi and Firefox) the first page is centered too. Are you sure you're not viewing an older, cached version in your phone? Both pages are centered on my Android. Only checked with FF. |
|
|
|
| Christian J |
Nov 10 2023, 08:55 AM
Post
#12
|
|
. Group: WDG Moderators Posts: 9,661 Joined: 10-August 06 Member No.: 7 |
QUOTE(pandy @ Nov 10 2023, 07:40 AM) QUOTE(Christian J @ Nov 9 2023, 11:33 PM) In my Android browsers (Brave, Vivaldi and Firefox) the first page is centered too. Are you sure you're not viewing an older, cached version in your phone? Both pages are centered on my Android. Only checked with FF. I should add that I only checked the first page... |
|
|
|
| pandy |
Nov 10 2023, 09:49 PM
Post
#13
|
|
🌟Computer says no🌟 Group: WDG Moderators Posts: 20,732 Joined: 9-August 06 Member No.: 6 |
Now you tell me.
 So a mystery then. |
|
|
|
| TW Allen |
Dec 2 2023, 02:13 PM
Post
#14
|
|
Member Group: Members Posts: 42 Joined: 12-April 21 Member No.: 27,890 |
QUOTE(Jason Knight @ Nov 8 2023, 07:45 PM) QUOTE(TW Allen @ Nov 8 2023, 08:46 AM) First of all, please recommend a good reference for learning HTML properly. I have a couple, the latest one published in 2019. A detail a lot of tutorials and books seem to gloss right over. Sorry it has taken me so long to respond. Billable hours got in the way. https://allendesigns.com/residential_remodel_projects.html looks good. https://allendesigns.com/projects/22310/22310.html looks good. The rewrite cleaned out a LOT of code! I'm working on https://allendesigns.com/index.html now. It's more difficult. First of all, in the section headed by "Types of Projects:", I want that aligned left and a unordered list with bullets. I can get it to align left, but I cannot get the bullets. I'm also struggling with image sizing to work with both a large monitor and a mobile screen without using pixel sizing. If the images are large, it pushes all of the text to the left on the mobile screen. If I make it small, like 300px, it looks fine on the mobile screen. But, as soon as I make it larger, say 600px, then the text gets pushed off to the left on the mobile screen. What am I doing wrong in both cases? Thank you, |
|
|
|
|
2 User(s) are reading this topic (2 Guests and 0 Anonymous Users)
0 Members:
|
Lo-Fi Version | Time is now: 27th April 2024 - 02:13 AM |
Invision Power Board
© 2024 IPS, Inc.
Licensed to: HTMLHelp.com, LLC