"Snapping" Responsive Design Width to 100% for Small Viewports (Mobile Devices)

responsive-design

#61

Ty,

Give these files a try, please.

The box-shadow has replaced the gradient on the .banner. As I said before, it leaves less width for content. See the notes in the CSS where the body margin is changed to hide the shadow at the narrowest width. Removing the box-shadow will require changing the body margins in the media queries.

The bottom (third) section of content is hidden at the the first media query breakpoint (700px). Either delete the class “last” on that third section or comment out or delete the CSS if you change your mind.

I put boxes around the content images. The images are not floating. Their containers are. They stop floating at the second media query (600px). Not too small. I think the images behave better but your taste may differ.

Check the content for errors. While the code is valid, it may be possible to write it more efficiently so don’t hesitate to ask questions.

Tested in FF and Chrome.

FirstRateFreight58b.html (5.4 KB)
homepage58b.css (6.9 KB)


#62

Well, the box-shadow on .banner is stunning. :money_mouth_face:
There’s nothing much more to say about that.

I’m unsure why your cleared image floats and margin: 0 auto; seems to center the images in the media queries. I used almost the exact same code prior to this update.

Additions:
-I adjusted the font size of the absolutely positioned <h1> because the text was protruding from behind the logo images. It is 2em in size now and 1em at small widths.

-I removed the line break in the text of .slogan and used padding instead to try to preserve the visual presentation of the slogan under the arrows. The line break was causing some weird text wrapping as the page expands & shrinks.

Issues:
-At low widths, some element is leaving excess space at the bottom of the page (not shrinking or adjusting). Should I revive borders again for all the elements? I need to learn how to isolate the element that’s causing this.

Observations / questions (condensed version):

  1. .banner::after has background-size: contain assigned to it at line 80. Upon researching this property, is this necessary so that the browser will scale the image to fit its container similar to border-image-repeat: round ? :dizzy_face: Maybe I’ll remove that property as an experiment and see how the arrows respond.

  2. .content has a border-image-outset of 5px and a 5px left/right margin to offset. Why not just make the border offset 0?

  3. In my dabbling with clearing the floated images, I used last-of-type to get the last .right div. You’re using a new class of last. Where can I refer to when I feel that the first-of-type or last-of-type targets may be appropriate? What I used didn’t perform as intended. I’ll look it up on the Mozilla developers’ site.

  4. The links are displayed like a table. I’m assuming this is because the elements will stack neatly on top of each other without the links being activated on the entire block level. A revisit to the display property should reveal some info.

  5. I’m dumbfounded how hidden visibility and font-size adjustments account for the padding of .scrolldown when it disappears. That will remain a mystery but a noted hack in the media queries.

Goals / objectives:
-The “contact us” link needs some emphasis with these link arrows I mentioned before:
(before and after pseudo-elements are not an option with link elements, apparently, but another div seems redundant.)
linkarrows.zip (43.3 KB)

-The full size of the layout could be made a bit bigger as an experiment. I’ll give that a go on my own.

This page is starting to look complete, but I’m still in draft mode on my sales copy. The text will probably be altered a couple dozen more times.

-ty :smashy:


#63

Glad you like it smile
 

Just an FYI reminder, change the width of the page by changing the max-width in .outer. Nothing else.

 
The space at the bottom of the page is because I forgot to put a minus in front of the offscreen value:

    .right.last {  /* this moves the last content section offscreen left at this breakpoint.) */
        position:absolute;
        left:-9999em;  /* ADD minus here */
    }

 

Those properties are assigned to <div class="imgwrap">, not to the images. The <img> element is preset at the top of the CSS to:

img {
    display:block;
    width:100%;
    height:auto;
}

I broke training… I made a personal preference error when limiting the width of the images in the content portion of the page. :eek:
Please change this:

.right .imgwrap,
.left .imgwrap {
    display:table;
    max-width:288px;  /* set max-width of images here.  some images may be narrower. */
    border:4px ridge #000;
    margin:0;
}

to this:

.right img,
.left img {
    max-width:288px;  /* set max-width of images here.  some images may be narrower, none will be wider. */
}
.right .imgwrap,
.left .imgwrap {
    display:table;
    border:4px ridge #000;
    margin:0;
}

In your current code, the widths are not the same. You can split the selectors in my example and change the widths as desired. Easy.

.imgwrap is assigned to {display:table} because a table is a block and it shrinks to fit the width of its content by default. Floats override {display:table} and also shrink to fit so there should be no change in the size of the image when negating the float in the media query.

I think this covers the mentions at the top of your post. I’ll work on those at the bottom later tonight.

cat-sm


#64

Correction: Change the width of the page by changing the max-widths in .outer AND .contentwrap.

(1)

Yes. In this case, one could use contain, cover, or 100%. The background-size property specifies the size or coverage of a background-image. background-size has a choice of several values: ( auto | cover | contain | length[with a unit of measure] | initial | inherit )
NOTE: If only one non-keyword value is specified, the other one is assumed to be “auto”.

The first three references listed below offer “demos” where you can compare the effects of values.

https://www.w3schools.com/cssref/css3_pr_background-size.asp



(useful) https://www.w3schools.com/cssref/css_units.asp

(2)

They serve complementary purposes.

.content {border-image-outset:5px} is required to make the border-image overlay the body background-image by 5px on each side. Remember the corner boxes on the border-image are 10px wider than the middle segments. Without the border-image-offset, the body background-image is visible outside of the middle segments.

The max-width of .contentwrap is 770px so it would be 30px narrower than the banner box, 15px on each side, at desktop width. However, the border-image-offset uses 10px of the 30px, 5px on each side. The added margin applied by .content {margin:0 5px} counteracts the 5px border-image-offset to preserve the full width space around .content to 30px at desktop width.

As the page narrows to less than 800px, that 30px of difference collapses until .contentwrap is the same width as .outer. However, .content {margin:0 5px} contines to give the middle segments of the .content section’s border-image a 10px narrower width than the .banner. At the narrowest width, the left and right edges of the corner boxes (at the bottom of the page) would be sliced off without .content {margin:5px}.

(3)

last of type does not work the way you think it works. It would find the last <div> and if it matches class “right” then it would apply your code, if it does not match class “right” your code would not be applied.

Play with this:

<!doctype html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width,initial-scale=1.0">
    <link rel="stylesheet" href="css/stylesheet.css">
    <title>:last-of-type</title>
<!--
:first-of-type, :last-of-type demo
-->
    <style>
p.green:first-of-type {
    color:green;
}
p:last-of-type {
    color:red;
}
p.blue:last-of-type {
    color:blue;
}

    </style>
</head>
<body>

<p class="pink">Your HTML here</p>
<p>Your HTML here</p>
<p class="blue">Your HTML here</p>
<p>Your HTML here</p>

</body>
</html>

We can change the HTML so :last-of-type works but I would recommend not specifying a className.

Change the div

   <div class="footer"> <!-- footer -->
       <div class="anchorwrap"><a href="#">Contact Us!</a></div>
       <div class="anchorwrap"><a href="#">Read Our Shipping Guide</a></div>
       <h4>&copy;2018, First Rate Logistics. All rights reserved.</h4>
   </div> <!-- end footer -->

to footer

   <footer class="footer"> <!-- footer -->
       <div class="anchorwrap"><a href="#">Contact Us!</a></div>
       <div class="anchorwrap"><a href="#">Read Our Shipping Guide</a></div>
       <h4>&copy;2018, First Rate Logistics. All rights reserved.</h4>
   </footer> <!-- end footer -->

 

(4) I believe #4 was addressed in my last post.
 

(5)

{visibility:hidden} should be obvious enough, it renders the text invisible but does not delete it. Reducing the size of the invisible font reduces its height. I picked a size that is close to your padding. I felt that this was easier than removing the text with {display:none} and adding padding to provide some height.
 

Check for typos.

smile


#65

Okay, I have uploaded a new version of homepage.css. I’m on root folder 18. Your last edition was listed as # 58b. The max-width of .outer is now 980 px, and .contentwrap is 940 px at widest. This update is quite different as there are adjustments to all of the font sizes throughout.

There is a lot to respond to in your last 2 posts after reading the page links and making the suggested changes to the code. :pig:

If I really want to grasp at a full understanding of any one thing mentioned in the last 2 posts, it is this right here - how you seemed to know that the left value for the absolutely positioned .right div needed to be negative. I can see myself in this same scenario trying to debug this seemingly small issue. I would be running amok without much direction changing values anywhere and everywhere, adding borders, etc. in aimless attempts leading me deep into the night :crescent_moon: and driving me to pull all my hair out, trying to find out why that empty space existed at the closing of .contentwrap. In fact, there would have likely been a thread here at Sitepoint dedicated to this issue in lieu of this fruitful dialogue. :kiwi_fruit:

Perhaps, you can describe your thought process or link to a resource about debugging design blunders in CSS / HTML. Otherwise, I can only assume that your ability to pinpoint the solution with relative ease comes from your extensive experience.

After tinkering with left, I found that a positive value moves an absolutely positioned element to the right, and with a negative value, it moves to the left. I am not educated enough to comprehend if the positive value affects its parent container, .contentwrap, giving it the unwanted space.

(1)
background-size
I had a read of the background-size reference pages, and yes, one can use contain or cover or 100% in this instance; however, cover is slightly different as a preset value as it is described as it may result in the browser trimming a bit of the image off, whereas a value of contain ensures that the entire background image is shown.

(2)
I think what you are describing about the 5px margin and border outset is that the content body design does not align completely at the edges of the graphic (The bar is in the middle of the squares.). This goes back at least 20 posts to finding out how to keep the lighter body background color from protruding outside of its graphic. At least, that’s the result when I remove the border-image-outset. These values have purpose in preserving the box since the green fancy bar design is not flush at x = 0. The bars sit in the middle.

Although, the new width difference between .outer and .contentwrap is now 40 px, and the effect is the same.

(3)
Okay. I’m really not grasping the last-of-type pseudo-class.

This is the result of the demonstration of last-of-type:
Capture

As you know already, only the last <p> received a red color.

<!doctype html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width,initial-scale=1.0">
    <link rel="stylesheet" href="css/stylesheet.css">
    <title>:last-of-type</title>
    <style>
article:last-of-type {
     background-color:pink;
}
    </style>
</head>
<body>
<article>
  <div>This `div` is first.</div>
  <div>This <span>nested `span` is last</span>!</div>
  <div>This <em>nested `em` is first</em>, but this <em>nested `em` is last</em>!</div>
  <b>This `b` qualifies!</b>
  <div>This is the final `div`!</div>
</article>
</body>
</html>

If you see the result of the above on the Mozilla reference page, the pink background color displays in seemingly random places (over the nested spans and last of the <em> elements… weird). Perhaps, that is a confusing example as I perfectly understood how your example worked.

I was assuming that it would find the last element with a class of .right, but it’s not quite so simple.

This will be something that will be explored more in depth as last-of-type / first-of-type may come in handy in the <footer> for the emphasis arrows on the “Contact Us” link, seeing that there are two identical .anchorwrap divs for the bottom links.

(4)
I think I’m clear on display:table concept in relation to .imgwrap since table display causes a shrink-to-fit effect, but I am not clear on why the links are displayed like a table because the links have no graphical content. You addressed this in relation to .imgwrap, but I was asking in reference to the links in the footer. When I remove table display from the links, all I see is a small amount of vertical space trimmed from in between the links. See line 227 of the most recent CSS file on the test site.

(5)
Aha! So, this exhibits the difference between visibility:hidden and display:none. Hidden visibility just simply makes the element invisible (but presently there in its height and width), and display:none removes the element entirely as if it does not exist. Since this is invoked within the media queries to hide the scroll down text, hidden visibility can be used instead of padding-top because the text element itself is the padding.


I’m sure I can drag this down with more questions seeing that you linked a CSS unit reference page, but unfortunately, like learning guitar :guitar:, to be proficient with these CSS properties, it requires much experience and practice. That’s life. Fortunately, with the combination of reading material and threads like this one, I know that I am becoming more equipped to do this on my own as I have a couple of other small web projects to complete after this freight biz page is laid to rest. I feel my confidence is rising greatly.

Now, going forward with the last goal I have for this home page (thereby concluding this thread), shall I attempt to use first-of-type to sufficiently target the first .anchorwrap div? I read above that you would not recommend using a new class name, but I doubt the following will apply styles correctly:

.anchorwrap:first-of-type::before {
      background:url("../images/linkarrows.png") no-repeat;
      width:40px;
      height:30px;
}
.anchorwrap:first-of-type::after {
      background:url("../images/linkarrows.png") no-repeat right center; /* only display the right arrow on this side */
      width:40px;
      height:30px;
}

You chose to go with an HTML5 element of <footer>. I don’t understand why this is favorable over a regular div, but I don’t know how engulfed you should become with me and all of my “questions”. I need to continue to do my own research, but hopefully some other reader can gather a little bit of insight from this discussion as this thread has been viewed quite a few times.

Until next time. Take care.

-ty :smashy:


#67

(A)

We need to clarify a couple of things…
Pages may be extended down (most commonly) or to the right, but not to the top or left. To position an element off-page, it must be positioned to the top “above the fold” or to the left. The missing negative sign positioned the last content box off-screen to the right which did not negate the vertical space originally occupied by the third box, it just moved it over - waaaaay over to the right. Had you noticed the horizontal scrollbar at the bottom and scrolled to the right, you would have found it, too. The scrollbar and the empty space were the giveaways. Like you said, experience (understanding how the elements were supposed to behave) led me to check for a missing negative sign preceeding the large {left:value}.
No, the positive value does not affect the parent container of the targeted div.

(1)

Just for clarification: “cover” sizes the image so its container is fully covered by the image. If the aspect ratio of the image differs from that of its container, the overflow is “trimmed”. “contain” fits the entire image into its container. An image whose aspect ratio differs from that of its container will show white space along the edge(s) that do not reach the edges of the container. When in doubt, use “cover” to assure full coverage. A pixel or two trimmed from from an edge or two will not be noticed.

(2)

Although border-image-outset applies 5px to the width of the green content border box (adding a total of 10px to its width), that width is compensated for (negated) by {margin:0 5px} in the same element for a net increase in width of zero, so your math is correct and the effect is the same. :slight_smile:

(3)

Let’s read the code.

article :last-of-type {
  background-color: pink;
}

<article>
    <div>This `div` is first.</div>
    <div>This <span>nested `span` is last</span>!</div>
    <div>This <em>nested `em` is first</em>, but this <em>nested `em` is last</em>!</div>
    <b>This `b` qualifies!</b>
    <div>This is the final `div`!</div>
</article>

The first thing to notice is the space between article and :last-of-type in the CSS.
If there were no space, the entire block <article> would be pink because <article> is the first and last (only) <article> in the html.
If the selector were written article div:last-of-type, then only the last <div> would be pink.
But because the selector has that space, article :last-of-type examines all of the elements inside <article> like so:

<article>
<!-- the first <div> is not targeted -->
    <div>This div is first.</div>
<!-- the last (and only) <span> inside this next <div> *is* targeted -->
    <div>This <span>nested `span` is last</span>!</div>
<!-- the second (last) <em> inside this next <div> *is* targeted -->
    <div>This <em>nested `em` is first</em>, but this <em>nested `em` is last</em>!</div>
<!-- the only (first and last) <b> element within <article> *is* targeted -->
    <b>This `b` qualifies!</b>
<!-- the last <div> element in <article> *is* targeted -->
    <div>This is the final `div`!</div>
</article>

last-of-type%3Dmozilla

(4)

There are sooo many ways to skin that cat…

The absence of graphical content is irrelevent.

The links are given {display:table} because tables shrink to fit and you want the clickable area limited to the width of the text. Because tables are blocks, they can also can be centered very easily by assigning .footer a {margin:0 auto}. I could have easily used {display:inline-block} because .footer {text-align:center} centers the text in the paragraphs and header and would center {display:inline-block} anchors, but I didn’t. I put the divs around the anchors because I like to put a container around an anchor, just like I like to put a container around images (most of the time). In the case of anchors the box around them is helpful for screen readers. Both {display:table} and {display:inline-block} allow the dimensions of the anchor to be expanded with padding, thus increasing their clickable area and potentially their visible area.

My casual intent with that change was to keep the CSS intact by modifying the HTML slightly. The result was “busy” but it worked correctly. This current version changes the CSS and HTML and is cleaner. For the demo I used grayish, blue and red coloring on the anchors. You may wish to add JS or another method to make the links mobile-friendly since touch devices do not respond to :hover.

Demo. Even this can be improved.

<!doctype html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width,initial-scale=1.0">
    <title>footer anchors demo</title>
<!--
for etidd
-->
    <style>
footer * {outline:1px dashed red;}  /* TEST Outline. To Be Commented Out or DELETED */
body > p {
    text-transform:uppercase;
    margin-top:3rem;
}

.footer {
    text-align:center;  /* is inherited by descendants */
}
/* properties that do not change */
.footer a {
    display:table;
    border-width:1px;
    border-style:solid;
    border-color:transparent;  /* a color here is optional */
    border-radius:0.375rem;
    padding:0.5rem;
    margin:1rem auto;
}
/* properties that change */
.footer a:link, .footer a:visited {
    border-color:#888;  /* specify initial color here */
    color:#222;
    background-color:white;
}
.footer a:hover, .footer a:focus {
    box-shadow:0 0 0.25rem 0.0625rem;  
    border-color:inherit;  /* remaining color changes are inherited */
    color:blue;
    background-color:#f8f8ff;
}
.footer a:active {
    color:red;
    background-color:#fff8f8;
}
    </style>
</head>
<body>

<p>unstyled divs around anchors</p>
<footer class="footer">
    <p class="thanks">Thanks for Reading Our Page!</p>
    <div><a href="#">Contact Us!</a></div>
    <div><a href="#">Read Our Shipping Guide</a></div>
    <h4>&copy;2018, First Rate Logistics. All rights reserved.</h4>
</footer>
<p>no divs around anchors</p>
<footer class="footer">
    <p class="thanks">Thanks for Reading Our Page!</p>
    <a href="#">Contact Us!</a>
    <a href="#">Read Our Shipping Guide</a>
    <h4>&copy;2018, First Rate Logistics. All rights reserved.</h4>
</footer>

</body>
</html>

(5)

Yes!!!

(Last Goal)

I apologize. My information was correct, but the presentation was very unclear/misleading. Let me have another go at it.

You wrote the .content child selector .right:last-of-type in the first media query with which you intended to target the last .content <div class="right"> and send it off-screen left.

Then along comes cat-sm. To help solve a problem with the links in the “footer”, I added a containing <div> around the “footer” elements which promptly changed the target of the .right:last-of-type selector. So I changed the CSS so you just needed to add the class “last” to the element to be moved off-screen.

But you didn’t understand why .right:last-of-type didn’t work any more. So, in post #64, I explained the reason, made a demo, and provided links to resources. BUT, ALSO in post #64 changed the <div> surrounding the .footer elements to <footer> with a className of .footer and in the next paragraph told you that .right:last-of-type should work now without specifying that it would work where you had it originally because now the last <div> in .content would be targeted by .right:last-of-type as desired. I think that leap caused the discussion about :last-of-type to jump the track. Sorry.

I hope that you understand that because the “footer” is surrounded by a <footer> element and is no longer surrounded by a <div>, the className .right will target the last <div> in .content, and because that <div> has a className of right your original .right:last-of-type selector should now work.

(Footer Code)

First, because it is the semantically appropriate choice. Screen readers recognize the footer element and identify it accordingly to the visually impaired user.
Second, it is no longer the last div in the .content section, the div above it is; so your .right:last-of-type selector should work again.

You had asked whether the .anchorwrap divs around the anchors were necessary. The answer is not necessarily. The demo in question 4 above shows that the centering and spacing of the anchor elements does not change using either method. Then why add <div class="anchorwrap">? In this case, it’s personal preference. I do not like to leave anchors and images outside of a containing element unless it is prudent to do so. I routinely assign borders around images to a wrapping container rather than to the image itself, too, but there is a practical reason for that. There are always exceptions, and the sky won’t collapse if I break training and forget my routine. But if it mattered, it could be seen or measured during testing.

This is my latest version of the footer code for your currently active page. I don’t think adding the images beside the top link is a good idea because they add to the width of the content and they don’t play nice at narrow widths. You would probably want to assign {display:none} to them to reduce the width required of the top anchor. Personally, I don’t think they add any appeal to the page whereas the “Thanks for reading our page” imparted a personal touch. Tastes differ. Be sure to check for typos or errors. Have fun!

EDIT (about 3 hours later)
I seem to have forgotten to add the code for the footer for the current page. So, I’ll just include the whole page. Check carefully for errors.

FirstRateFreight65a.html (5.2 KB)

homepage65a.css (8.3 KB)

Whew!


#69

The files on the test site have been updated.

I tried to re-incorporate the “Thanks for reading” blurb at the bottom using a smaller font size, but I decided it doesn’t add enough to the page, so I removed it.
You’re right that the link arrow emphasis does not wrap well at low widths, so I came up with a new idea. I turned the “Contact Us” link into a “button” :flying_disc: using a background gradient, i.e.:

footer div:first-of-type a {
        padding:1rem 1rem;
	background-color:#59ffb7;
	border:3px ridge #ccc;
	background:#18b4a2; /* Old browsers */
	background:linear-gradient(to bottom, #18b4a2 0%,#6cf29f 100%); /* W3C, IE10+, FF16+, Chrome26+, Opera12+, Safari7+ */
	box-shadow:0.2rem 0.2rem 0.4rem #000;
}

Its padding is slimmed within the 700 px max-width media query.
That seems to play very nice and is easy on the eyes and achieves just a bit of emphasis on the link (…I think). Looks good! :+1:
I may even experiment with using a nature background image with an opaque, light green overlay for the hover effect as welll as add that image to the DOM (document object model) prefetch so there is no “blink” between the hover and regular states .

As a side note, the selector with attached pseudo-classes like this:
footer div:first-of-type::before does successfully target an element for styles.

(A)
Okay. So I understand now that top and left (as directions on the page) are associated with each other in this way So bottom and right can be attributed to how far down the page stretches, although I wonder if this means it is always prudent to utilize a negative value for either left or right for absolutely positioned divs.

(1)

Yes. I guess that’s the way I understood it. cover will cause the browser to clip off any remainder of the image.

(3)

Wow! :scream_cat:
That means the background-color for whatever the last element is within each div. Notice it says: “nested span is last”. That makes sense now!

(4)

I now see the necessity for putting a container around most links and/or images, too, in its relationship here to using display:table so the links
display:inline-block will cause the links to sit directly next to each other (if they are without a container).

Yes, I definitely would like to refer to JavaScript for any way I can add a small improvement to enhance the user experience if they have a touch device that does not respond to :hover or :active especially since I am using creative hover effects. Do you know of a page that discusses the issue? Do I need to refer / post a thread within the JS forum?

pointer-events:click
Am I on to something relevant here?

Your demo displays the anchors in a like manner to what I have now. The box shadow idea is good, but I used it on the plain state of the first link only (Contact Us). It looks brilliant. The last thing I’m going to do with the design is experiment with a custom hover background state that is pre-fetched into the browser’s cache.

I think I have a cleared up the fog :cloud: on this, but your explanation that it would work now because it is the last div before the footer is easy to follow.
++
++
++
Almost done.
The last thing I’m going to toy with is custom border images for the Contact Us link.

-ty :smashy:


#70

I think I have given up on my experiments with background images with textures or something (unless you have an idea). It’s just not worth it given the gradient shift that I placed now provides an appropriate color shift effect.

I want to know more on where I need to go to retrieve the JavaScript snippets appropriate to account for the absence of :hover on touch devices.


#71

Because (most) touch devices are not capable of responding to :hover, and because none of your menu buttons have drop-downs, I believe that this page doesn’t require JS. There may be nuances of the buttons/links that can be enhanced with JS, but it doesn’t seem necessary to me.


#72

Well, I definitely need to be more educated about the JavaScript snippets in relation to their effects on :hover and other states on touch devices. That sounds like it’s already a standard practice and required knowledge for a modern web development professional.

You know… my plan after this website is to revisit the “section” pages on World Review Group and re-design the pages (on my own… I know how I’m going to do it, too…), but World Review Group has 2 sets of drop down menus on the home page - widemenus.css, remember? So, I would like to explore more about JavaScript and other HTML “hacks” that improve the user experience on touch devices such as phones, tablets, etc.

I started to read this page. Perhaps, this is useful literature for such education: :grapes:

I may go ahead and implement some hacks on this First Rate Freight page depending the outcome of my testing on several different touch devices. Restricting zoom / scaling functionality may be immediately useful (but maybe not if older / visually impaired viewers want / need super big fonts).

IDEAS

(1)
Would it be a neat idea to put the Contact Us form within this page to be toggled (expanded downward below the “Contact Us” button) to display with animation using JavaScript, or would it be better in the case that a device is not running JS to just use a separate contact.html page file for the user to navigate to?

edit: I think that’s what I want to do, making “Contact Us” a button.
People have been using the World Review Group form we made (it uses JS and PHP), and I’ve collected over 100 signups… Just sayin’.

(2)
For the next thread on this site, I need to go over to the General Web Dev forum and make a community inquiry about displaying a massive amount of text and images (some floated, some centered, etc.) from the Shipping Guide article that I have written and am editing. For one, I know that I am going to offer a link to a .pdf file version, but I would also like to render the Shipping Guide on the website somehow (divs that “change pages” by page links using JS to toggle the pages or just a very long page with text and images, etc.

++
++
++
Thankful for you. :cat2:


#73

I would be wary of overvaluing that article. The date on it is August 21st, 2011. There have been many changes in Javascript (and CSS) during those seven years. I didn’t know that anyone had ever advocated restricting zoom/scaling functionality. It certainly isn’t recommended today. I’d suggest that you look for some newer articles. There has been plenty of discussion on SitePoint. I don’t advocate using JS where it isn’t necessary. Guess I’m hanging on to the principle of progressive enhancement, ie. using JS to enhance the user experience but not “break” the site if the user has JS disabled.

If you intend to redesign the World Review Group pages, be sure to keep write-protected copies of the working originals just in case. Always work on a copy.

Thank you. It’s been fun smile


#74

I don’t intend on re-designing the home page at all for WRG, but I will be learning more about how to use JS to improve the user experience when necessary (if the drop down menus don’t function properly). I was mentioning I will be designing the section pages, i.e. health.html, business.html, dating.html, etc. That should be very simple to do.

However, First Rate Freight :truck: is what is on the front burner :fire: for completion.

I have a huge, almost 4,000 word document (Shipping Guide) with images that I am currently editing.

Should I display it all on one HTML page with floated images in various positions (left, right, centered below text w/ small caption, etc.)?

It will also be a link for PDF file download on the Shipping Guide (shipping.html).


#75

It sounds like one long page divided into distinct sections (each section identified with an ID) with the sections listed in a slide-out menu for instant jump-to access via the fragment identifier (ID). An additional button on the menu might send the user back to the WRG home page. Each section could be arranged in such a way that it emphasizes the message in that section (if reasonable). However, if the sections follow basically the same pattern, then coding and maintenance become easier. It’s really your call, and fortunately, you have a creative mind. smile

I built a very long page for my Oregon friend’s club’s web site that was divided into 10 sections. Most sections were fairly long, so when I created the index menu, I also listed the “subsections”. The page was 99+% text, so the structure didn’t change too much from section to section.

To me, a disadvantage of a long page, especially one that has been narrowed to smartphone size, is the rather exaggerated distance that the scrolled position on the page can change with any change in the width of the page or font-size. The number of words that can wrap simultaneously or nearly so above the scrolled point increases as one scrolls toward the bottom of the page. In real life, that’s probably not an issue, though, because browsers occupy the full screen. The width doesn’t change.

A practical issue could be the loading time of the page if it contains a bunch of images.


closed #76

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.