I hope that someone here can help me resolve an <aside> element. I've been researching multiple sites with no success. I have tried a number of different scenarios to pull the aside up alongside the page div, but for some reason it won't move.
There are two codepen elements which you can look at to see the full code
http://codepen.io/Cornucopia/pen/PNwxLZ?editors=1100
http://codepen.io/Cornucopia/pen/YqXpEr?editors=1100
A second question I have is why the first pen shows both the longer title name (one with 'and' and the shorter with '&') while the second one is successful at switching the title text for the larger layout. (I want one shorter title for ipad & one longer title for monitor)
I thank you in advance very much for your time and look forward to hearing your thoughts.
good day
Related
I am having a problem with high CLS (Content Layout Shift) while using Bootstrap (4.5) grid for two column layout with column order change.
CLS is a Core Web Vital metric. Basically Google sees a problem when webpage's parts are moving when the page is loading. Supposedly this metric is to affect SEO.
On high resolutions my layout consists of two columns. Main content on the right and sidebar on the left. On lower resolutions sidebar content is pushed down below main content. So HTML looks like this:
<div class="container-fluid">
<div class="row">
<div class="col-lg-8 order-lg-2">
</div>
<div class="col-lg-4 order-lg-1">
</div>
</div>
</div>
The problem is that for brief moment while the page renders on desktops, the main content appears on the left side, then milliseconds later it shifts to the right place on the right. With simple pages (with simple DOM or no external resources) the shift is not detectable.
I've prepared an example of such page. (The source code is on github). To measure CLS I am using Lighthouse in Chrome. In my case when I refresh the page I can see columns moving and Lighthouse informs me of CLS value of 0.326. The result might depend on rendering resources so you might get something different. But it seems Google Page Insight gives similar result:
Anyway, is there a way to avoid such shift while the page renders?
It seems the problem is more Chrome related then flexbox or bootstrap. It turned out that the problem is caused by premature renderation. Chrome's parser "yields" (so it triggers rendering):
after reading 65536 bytes of data,
after encountering <script> tag after reading 50 "tokens" (which I think are basically html tags).
The example I provided shows the first case (but actually my real website experiences CLS because the second one). Both of those cases have "bugs" related to them submitted: 1130290 and 1041006.
So the answer to the problem is hoping that the "bugs" will get resolved. In the meantime depending on actual cause you can limit file size or remove <script> tags.
Short Answer
Minimise the HTML and the problem seems to go away.
Longer Answer
I did a bit of digging, this isn't a complete "this is exactly what happens" answer but I got enough of an idea to come up with the above solution and to roughly explain my reasoning. I am hoping someone can expand upon the gaps in my knowledge.
So what made me come up with the above solution?
After profiling the page load I notice that there were 2 HTML parse tasks being created.
One dealt with lines 1-770 of the HTML and the other dealt with lines 771 to the end of the document.
Because of this the page appears to render the first 770 lines and then recalculates the layout on the second HTML parse task because you have swapped the order (and the .col-lg-4 column is in the second parsing pass HTML).
You won't see this on a "normal" page as if the page is rendered in DOM order layouts will be correct anyway and the second HTML parsing pass will just add more detail to the layout.
As it appeared to be pretty consistent where it cut the page off I removed all line breaks and white space. My theory being that whatever algorithm is deciding where to split the HTML up is using line number as part of that calculation.
By reducing the effective lines to 15 or so I was hoping to make that algorithm only parse the HTML in one pass.
It actually still does it in 2 but the last pass is the closing </html> tag only so doesn't matter. The result of this is when the parsed HTML is combined with the CSSOM it can calculate the layout correctly.
a bit of a hack but it should work up to certain page depths.
please note - if I doubled the DOM node count this workaround did not work again. If I changed the length of each list item (i.e. put lorem ipsum in) but didn't change the structure it did not make a difference. So it appears to be some combination of number of DOM elements and line number that decides when the HTML parser should stop its first pass.
A possible solution
Go back to old layout models. If you use float:left and float:right it should work. I think this specific issue is a combination of page complexity (number of DOM nodes) and using flexbox.
With flexbox being slightly slower than old layout models and sometimes having to use multiple passes (old layout models are single pass) I would imagine this issue would not persist with the above recommendation.
Where I found out about multiple layout passes in certain scenarios
I've been experimenting with this for over a week and I'm about to give up, as I think this is not possible, but I wanted to reach out to this awesome community first.
What I'm trying to achieve is to, somehow, overcome the stacked z-index settings.
Let me show you an example so you maybe get the idea faster:
http://raulmellado.com/clientes/zindextest/
What I'd like is to have the green div (#shouldbeontop) on top of all elements (I am setting it to position:fixed).
In other responses in stackoverflow (yes I've read dozens of threads here), the answer is to change the html, move elements around, etc, but my problem is that I'm creating the #shouldbeontop and #scrollbar elements dynamically using js (my application is a bit more complex than this example, but I've tried to simplify to share my problem here).
I've created a js that can be embedded (ideally) on any webpage which will add the elements, so I can use js if needed, but I can just assume that the #shouldbeontop and #scrollbar elements will be there; the rest could be any html/css combination that's already there.
Usually, where there is no z-index in different divs, this works beautifully, but as soon as there is some stacking, it breaks :-(
If you would like to see a real life application of this, here you can find a quick & dirty demo: http://videngage.me/demo/demo1.html (here there is no z-index, so the video [#shouldbeontop in my simplified demo] is always shown on top (when you scroll down), but here http://www.members.skolahudbyonline.eu/rytmus-trening-majstra/ the video goes behind when you scroll down)
Is there an universal solution for this (using css and/or js), or should I just give up?
Thanks sooooooooo much for your help
I am working on a web site using Bootstrap 3 to design it. I have come across a situation where the the grid system is not working as expected.
I am trying to fit in the HTML5 logo in the last line where I have set the class to visible-xs-6 col-xs-offset-3. According to me, this should create three sections where the first section should be an offset of 3 columns which is showing up fine as you can see in the image, but after that I believe that the HTML5 logo should be somewhere in the middle section and another 3 column section after that. Isn't that logical? But for some reason the second section is taking up the whole row after the offset. What am i doing wrong?
I don't believe the visible-xs-* classes are used to set the number of columns, only the display:* property. The only options are block, inline and inline-block. So your classes should be...
class="col-xs-6 col-xs-offset-3 visible-xs-block"
I made a silly mistake. I forgot to wrap the columns in a <div class="row">. And moreover I used .hidden-sm .hidden-md and .hidden-lg classes just to be extra sure.
And plus I made another silly mistake of assuming that the * in visible-xs-* means the number of columns instead of the options given in responsive utilities.
If anyone has a similar problem please take a look at Bootstrap's responsive utilities
Anyway thank you anyone who tried to help. I will accept this as an answer to close the question.
I'm using the code found here to create my text links located on this page. What I am trying to accomplish is having the rollover text be the description of the link ie: 'Insight' goes to the 'About' page. Some of descriptions are too long and are getting cut off and when I try to make them bigger they just overlap the link next to it. Any suggestions on how to fix it or a better method I should be using? Here is the HTML I'm using.
<span data-title="Services">Ingenuity.</span>
Sounds like you're asking for design advice as well.
Judging by the way you have your links presented (each list item with an equal fixed width in a row), a longer description will certainly overlap other links if you do end up finding a solution to make them not "cut off" (it exists, but I'm just not sure if it'll give you a desired result that you're looking for).
Either customize the widths of each list item so they don't overlap, or use some other cool transition (i.e. have the description slide down under the link rather than flip it). That's what I would suggest personally; however, it's up to you to choose what's considered a "better method" of displaying your descriptions.
What kinds of options do I have when a dropdown menu is faced with text that is so wide that extending the menu's width to accommodate is not feasible? i.e. It breaks the page layout, or just looks too ugly if the dropdown is adjusted to fit the long item.
Truncation?
Truncation plus full hover text?
Don't allow items that long?
Anyone encountered any elegant solutions to this?
Thanks.
I realise I'm fairly late to this question, but I've been hunting for an answer and I may have found a fairly elegant solution.
Have a look here:
http://www.getharvest.com/blog/2009/12/dropdown-problems-on-internet-explorer/
http://www.dougboude.com/blog/1/2008/05/Viewing-Option-Text-in-IE7-thats-Wider-than-the-Select-List.cfm
The first link talks about a couple of solutions before recommending a solution based on the second link.
The idea is that on click, you change the width of the <select> tag such that it is big enough to show the full text of the options. By keeping the <select> tag inside a div with overflow set to 'hidden', it doesn't screw with the rest of the page.
Try it out - it's a pretty good solution.
Truncation with tooltip would be my choice....
The last time i had to do that i used a telerik control, which was quite UI rich.
I agree with GordonB regarding truncating the options. Excessively long options can be hard to read, and as you mentioned it looks horrible.
If your dropdown is populated from user input, however, I'd restrict the length. What can be said with 15 words should be said with 5 ... if it can't, then perhaps a dropdown isn't your best option.
For example, if your options are the titles of research papers and their authors, you can probably abbreviate them down to a few key words ("String Theory and You [Brown 2008]"). On the other hand, if the options themselves differ by only a few words and lose meaning if they are truncated (e.g. a list of options like "Peanut butter and grape jelly sandwich with carrot sticks and soy milk" and "Peanut butter and boysenberry jelly sandwith with carrot sticks and 2% milk") maybe you would be better served by displaying all the options sequentially, accompanied by a checkbox or radio button as appropriate.
(If you're using ASP.NET, basically I'm saying using a repeater instead of a DropDownList)
This second approach might also allow you to incorporate other elements that you wouldn't be able to in a dropdown. Take a look at this Amazon search result page for ideas.
Give the element a maximum width with the CSS property max-width.
Most browsers show the options at full width regardless of the dropdown's actual width whereas IE crops them to the width of the select box. So the problem is really browser specific.
I've made a solution using absolute positioning on the dropdown so that I could extend it's width on hover in IE without breaking my layout. A bit hacky but it's one option.
I've been using commercial ASP.NET control that is implemented using <div> rather than <select>. This way we could put multiline elements on it, style it as we wanted and do some other stuff.
Depends how wide you are talking, what the context is. Often this comes down to a design problem rather than a coding problem. If the text is really long you will have usability problems regardless because reading long text in a dropdown is difficult. My options would be:
If the dropdown is really narrow and the longest items aren't very long (eg 3-4 words) change the design to accommodate it.
If the text is really long (eg sentences) then truncate it if you can. Sometimes text isn't amenable to this (eg. you may end up with multiple items with the same text). You can't really put tooltips on select list items.
If the text is really long and can't be truncated, you may want to consider a different UI option.
Why not create a calculated field which is based on the lengthy field.
Only create it to only be the first 50 (say) characters.
=LEFT([Title],50)
Then reference that field in the drop down.