SSteven
-
Posts
27 -
Joined
-
Last visited
-
Days Won
1
SSteven's Achievements
Newbie (1/7)
1
Reputation
-
Seems JS is needed to solve this problem: Fixed sidenav bar w/ non-fixed header leaves gap at the top after scrolling
-
The following webpage authored by me contains a TopNav and fixed SideNav. The TopNav isn't fixed. So it can scroll. Only the SideNav is fixed at the left. Both Navbars are created using flexboxes. Here's the key CSS: /* Top navigation bar */ .topnav { display: flex; background-color: #777; /* gray */ } /* Side navigation bar */ .sdnav { display: flex; flex-direction: column; width: 200px; height: 100%; position: fixed; overflow: auto; background-color: #f1f1f1; /* light gray */ } And here's the key HTML: <body> <!-- Top Navigation Bar --> <div class="topnav"> <a href="#">Home</a> <a href="#" class="active">News</a> <a href="#">Contact</a> <a href="#">About</a> </div> <!-- Side Navigation Bar --> <div class="sdnav"> <a href="#">What</a> <a href="#" class="active">Where</a> <a href="#">When</a> <a href="#">How</a> </div> <div class="main"> ... </div> </body> A problem occurs when I scroll down. This causes the TopNav to move off the top of the screen (since it isn't fixed). And here's the problem: A gap at the top of the SideNav then appears. Basically the problem occurs since: 1) The TopNav isn't fixed whereas the SideNav is fixed. 2) The SideNav occurs in the markup below the TopNav. One way to solve this problem is to make the TopNav fixed. Then a gap would obviously not appear above the SideNav, since the TopNav couldn't disappear in the first place. Is there any other solution using just CSS? Note: Both Navbars are responsive. The responsive part is working fine. It's just the gap while scrolling that's the problem. Thanks.
-
The following codepen illustrates positioning items using grid-column-start: grid-areaname. It sets grid-auto-flow to column and works as I expect. It is from the quackit page on grid-column-start. #grid { display: grid; grid-template-rows: 1fr 1fr 1fr; grid-template-areas: "a b c" "d e f" "g h i"; grid-auto-flow: column; grid-gap: 1px; } #grid > div:nth-child(4) { grid-column-start: f; background: limegreen; } <div id="grid"> <div>1</div> <div>2</div> <div>3</div> <div>4</div> <div>5</div> <div>6</div> <div>7</div> <div>8</div> <div>9</div> </div> However, when I set grid-auto-flow to row (the default value), a gap is left in the layout, for the auto-placed items, as seen in the following codepen: Why does this difference in behavior occur?
-
Note: I have edited the above codepen, but the results are still not as per my understanding. However, here's another codepen, which seems to illustrate the syntax option more correctly. This example is from the quackit page on grid-column-start.
-
According to the MDN reference page for grid-column-start, the following syntax is a valid option for grid-column-start: /* <integer> + <custom-ident> values */ grid-column-start: somegridarea 4; The page gives the following description of the above syntax option: As I understand the above syntax option, this means that if we have a grid area named "somegridarea", the item would be placed at the 4th column line named somegridarea-start. Is this correct? I have written the following codepen to test this; however obviously the results are not as desired. What example can be be used to correctly illustrate the above syntax option for grid-column-start?
-
OK, got it. Thanks for the inputs.
-
dsonesuk, I understand that Chrome pioneered the concept of "evergreen browser". Firefox and Edge lag behind Chrome in this regard. Also (as I already mentioned), Chrome supports multi-track listings in the grid-auto-rows property. Therefore, should Chrome usage be preferred over other browsers?
-
My CSS for a grid layout is as follows: .grd { display: grid; grid-template-columns: repeat(3, 1fr); grid-auto-rows: 100px 200px; grid-gap: 10px; border: 2px solid #f76707; /* orange */ border-radius: 5px; background-color: #fff4e6; /* pale orange */ } https://jsfiddle.net/SSteven/bdza8sxf/ This should make Implicitly-created rows display with heights of 100px, 200px, and so on in a 2-row track repeating pattern. However, this doesn't happen on Firefox 64.0.2 (32-bit version), which instead displays the 2 rows with the same height. Why does this happen? I thought Firefox fully supported CSS grid. https://caniuse.com/#feat=css-grid Chrome renders the rows correctly, though.
-
OK, Thanks for this. Here's my new CSS for the div.gallery element: div.gallery { margin: 10px auto; width: 100%; text-align: center; } However, I'm not clear about a few things: 1) Why isn't float: left required in div.gallery? Is that the default for inline-block elements? 2) Why does text-align: center work? Its supposed to work for centering _text_. Here, the content of the gallery isn't text; its <div> elements. Thanks.
-
I have written the following code for an image card gallery. The 1st row contains 1 image card. The 2nd row contains 2 image cards. The 3rd row contains 3 image cards. The image cards are displaying correctly. However, each row must be horizontally centered, and that's not happening. How can I fix this? Thanks. https://jsfiddle.net/SSteven/zo79psbd/ Here's the CSS: <style> body { margin: 25px; } div.gallery { margin: 10px auto; width: 90% border: 1px solid #ccc; /* light gray */ float: left; } div.card { display: inline-block; background-color: white; box-shadow: 0 4px 8px 0 rgba(0, 0, 0, 0.2), 0 6px 20px 0 rgba(0, 0, 0, 0.19); } div.desc { text-align: center; padding: 10px 20px; } </style> And here's the HTML: <body> <h2>Image Card Gallery</h2> <!-- 1 card per row --> <div class="gallery"> <div class="card"> <img src="https://loremflickr.com/800/600/paris?random=1" alt="Paris"> <div class="desc"> <p>Paris</p> </div> </div> </div> <p style="clear: both;"> <!-- 2 cards per row --> <div class="gallery"> <div class="card"> <img src="https://loremflickr.com/400/300/rio?random=2" alt="Rio"> <div class="desc"> <p>Rio</p> </div> </div> <div class="card"> <img src="https://loremflickr.com/400/300/rio?random=3" alt="Rio"> <div class="desc"> <p>Rio</p> </div> </div> </div> <p style="clear: both;"> <!-- 3 cards per row --> <div class="gallery"> <div class="card"> <img src="https://loremflickr.com/300/200/london?random=4" alt="London"> <div class="desc"> <p>London</p> </div> </div> <div class="card"> <img src="https://loremflickr.com/300/200/london?random=5" alt="London"> <div class="desc"> <p>London</p> </div> </div> <div class="card"> <img src="https://loremflickr.com/300/200/london?random=6" alt="London"> <div class="desc"> <p>London</p> </div> </div> </div> </body>
-
HTML page containing Google Fonts accessed on Android
SSteven replied to SSteven's topic in HTML/XHTML
I've just discovered I had made a syntax error when linking to the google fonts. On correcting it, the google fonts work perfectly on both PC as well as Android. https://jsfiddle.net/SSteven/83dkauht/2/ -
About the em and rem length units, w3schools states the following: em and rem are relative units, relative to the font size of the element or the root element respectively. Example from w3schools: p { font-size: 16px; line-height: 2em; } In the above CSS code, for <p> elements, the line-height will be twice the font-size, 2 x 16px = 32px. A pixel is an absolute length unit (1 pixel = 1/96th of an inch). Therefore, in the above example, line-height will also be fixed. Therefore, where does the scalability come in? Secondly, regarding the vw unit: It is relative to the viewport's width. As the viewport width decreases, a property expressed as x number of vw units will also shrink. Thus, vw is scalable. However, on smaller viewports, such a dimension is too small to read. Therefore, how useful is vw in practice? Do you know of a (small) example that can demonstrate the utility of vw? Thanks.
-
What about Company logos? Is it advisable for image sprites to be used for Company logos?
-
The Image sprite examples in the w3schools tutorial were about icons. 1) Is it recommended to use Image sprites for general images (and not just icons)? For example, if a web-site displays an image gallery of scenery-images, should we use a sprite in this situation? 2) For such general images, which are large in dimension, should we first shrink the images, before combining them into a sprite? If so, to what size (width and height) is it advisable to shrink general images? Thanks.
-
This is a cool trick.
