[SOLVED] issues with mobile friendly test

colak · 2020-02-29 17:55:39

I’ve discovered that Chicago 16b Style used in some pages is one of the causes of the horizontal scrolling. The full url of the citation is supposed to appear at the end of the citation followed by access date in brackets. Some of those urls are long and inflexible and I do not want to shorten them as I do not trust those services.

I started experimenting on breaking this rule and have a clickable text. ‘Accessed’ is one option followed by colon and the accessed date. That is a lot of work so I will be testing it on the example page posted at the beginning of the thread.

jakob · 2020-02-29 21:25:32

colak wrote #322009:

I am currently also trying to solve an issue appearing on small screens when the title is too long (example: http://www.neme.org/texts/environmental-awareness) where the h1 covers part of the body of the article.

For that remove the declaration height: 1em; from this line (I think it’s that line: the version I see online is not the same as the one on GitHub). Maybe you meant to have line-height here instead of height: ?

colak wrote #322010:

I’ve discovered that Chicago 16b Style used in some pages is one of the causes of the horizontal scrolling … Some of those urls are long and inflexible …

You might be able to solve that using word-wrap / word-break. See this article on css-tricks.

colak wrote #322009:

Hi Julian. I am experiencing it too and trying to find a solution. I’ve made widths to 98% but that did not help.

Maybe try this within your mobile width media query:

html, body {
  overflow-x: hidden;
}
body {
  position: relative
}

colak · 2020-03-01 10:19:10

Thanks so much Julian, I implemented some of your css recomendations and I’ll have to go back to 100% re widths.

I’m currently working on a report for NeMe, deadline is tonight so I’ll continue with the site tomorrow.

colak · 2020-03-02 08:32:43

jakob wrote #322016:

For that remove the declaration height: 1em; from this line (I think it’s that line: the version I see online is not the same as the one on GitHub). Maybe you meant to have line-height here instead of height: ?

Indeed. Nice catch! That corrected it

You might be able to solve that using word-wrap / word-break. See this article on css-tricks.

Maybe try this within your mobile width media query:

html, body {...

I think that solved the overflow-x issue but more testing is needed!

colak · 2020-03-04 10:48:01

Hi all,
apologies for my blindness but I just cannot spot the persistent issue with the horizontal scroll appearing on resolutions below 960 pixels on some pages. Here is a sample url, where I also disabled pat_speeder for the section. It shouldn’t be that hard but it’s been days that I am struggling with it.

I opted not to use

html, body {overflow-x: hidden}
body {position: relative}

as they do not solve the issue, they just hide it.

Last edited by colak (2020-03-04 11:47:42)

jakob · 2020-03-04 13:23:30

Think I may have found the cause but not the resolution. Your tooltips are an actual DOM node (span class="tooltiptext") and they are set to visibility: hidden; when not visible (to sighted readers).

Unlike with display: none;, items with visibility: hidden; still occupy space on the page. On your example page, footnote #2 is right at the edge of the page and the page scrolls horizontally exactly as far as that tooltip box:

Compare this:

with this (scrolled left, e.g. normal window viewport):

colak · 2020-03-04 14:11:07

Thanks so much for checking
good catch but styling .tooltiptext with display: none; has not made the problem disappear yet:( It’s a real itch, that I cannot sooth.

colak · 2020-03-05 20:01:36

This is really strange. I am checking the site using ff dev tools where the html and body tags appear to be the only ones exceeding the 100% width. I have no idea why.

colak · 2020-03-06 15:37:10

I think that have identified the culprits with a sledgehammer.

Using the ff dev tools, I added

a,abbr,acronym,address,applet,article,aside,audio,b,big,blockquote,body,canvas,caption,center,cite,code,dd,del,details,dfn,div,dl,dt,em,embed,fieldset,figcaption,figure,footer,form,h1,h2,h3,h4,h5,h6,header,hgroup,html,i,iframe,img,ins,kbd,label,legend,li,mark,menu,nav,object,ol,output,p,pre,q,ruby,s,samp,section,small,span,strike,strong,sub,summary,sup,table,tbody,td,tfoot,th,thead,time,tr,tt,u,ul,var,video {border:1px solid red;}

~~at the last line of the media screen and (max-width:960px){ styles~~ in a small stylesheet for logged in users only .

The two elements that apparently exceed the width are the copyright notice with id #searchsites and the header. The problem is that although I am changing those widths, the overflow is persistent and no change is visible in the borders, created by the above css rule. fixed both of them but some pages still have the horizontal scroll, regardless of the borders not exceeding the widest parts of the articles.

~~Could somebody check the particular elements and recommend a way to fix this?~~ Am I wasting my time on it?

Last edited by colak (2020-03-06 17:32:36)

jakob · 2020-03-07 22:09:14

Not sure if you’ve solved this now or not, but I took another look at it by downloading a couple of sample pages and trying to go back to first principles and rebuild your basic layout.

I managed to resolve it by dealing with two aspects: first shift your tooltiptext into a media query so that the styles only apply above 960px. Make the normal state hidden and show only above 960px. Something like this:

.tooltip .tooltiptext {
    display: none;
}
@media screen and (min-width: 960px) {

    .tooltip .tooltiptext {
        display: block;
    }

...

    .tooltip:hover .tooltiptext {
        visibility: visible;
    }
}

The second part is the long links in the footnotes. For that try this:

#texts .notes li a {
    ...
    overflow-wrap: break-word;
    word-wrap: break-word;
    word-break: break-word;
    hyphens: auto;
}

which should make long links break, if need be in the middle of a word.

I’m not sure if it works exactly with your current css but I can send you my little rebuild exercise. I didn’t do everything, and rebuilt your grid with flex box. I also didn’t take account of old IE.

colak · 2020-03-08 06:25:45

Wow!!! That kind of fixed it. I moved the tooltips in the media query and the horizontal scroll disappeared!

You are also right that their hover no longer works because of my css structure. At least all I need to check now is just that functionality!

What is perplexing to me is why this behaviour did not appear in the previous version of the site.

jakob · 2020-03-08 09:45:27

colak wrote #322097:

You are also right that their hover no longer works because of my css structure. At least all I need to check now is just that functionality!

It does work, you just didn’t quite implement it as suggested, so one all-important directive is missing. There’s also a typo that might be confusing the css.

Remove the stray } (you have it twice) after the display:none; entry.
You can move .tooltip (the wrapper for the footnote number) back outside the media query. You still want that to show on mobile.
In .tooltip .tooltiptext inside the media query, you need display: block; to make them show again on desktop view. Without that, the tooltips are still hidden on desktop view.

Wow!!! That kind of fixed it. I moved the tooltips in the media query and the horizontal scroll disappeared!

I was a puzzled too why display:none; didn’t resolve it on its own. I would have thought all other css directives would be invalidated but the tooltips still occupy space. So I turned the principle around and set tooltips not show as “standard” (i.e. mobile) and then all the directives that affect positioning and display only cut in when the viewport is wide enough. On mobile you can still jump back and forth between the text and footnotes.

What is perplexing to me is why this behaviour did not appear in the previous version of the site.

Because your site has been around a long time (17 years – pretty impressive!), you probably added media queries to accommodate smaller display devices at a later stage, so your general principle is desktop display first and media query directives to take care of smaller viewports. I think we pretty much all did that when the responsive options first became available. It works on the whole, but…

… all later changes you make to the css then also affect mobile too unless you take care to check and if necessary reset their behaviour too. That’s one advantage of styling for mobile first: mobile view generally has the least frills, and you then only add special facilities to the higher viewport media queries. The mobile ones remain unaffected.

I can’t say whether that explains why it’s happening now and didn’t before.

The other thing was: I found it hard to find my way around your css and what interacts with what. Again, I guess this is because it has accrued over time (I know this only too well myself), and perhaps also because you have support for old IE versions too (which unless your own visitor stats specifically say otherwise, I think you can jettison in this day and age). In the end I downloaded the source code of two typical layout pages, commented out your css, added normalize.css (= very basic level playing field for cross-browser styles) and main.css from HTML5Boilerplate (a starting point with good style order and standard up-to-date helper classes) and then rebuilt the basic layout bringing in bits of your css where relevant (e.g. tooltips etc.).

If you can stomach offering a less fancy display to earlier versions of IE, you could now switch to flexbox as it is well-supported now everywhere. The 24-col grid css using display:inline(_block) is terribly fussy about white space in the html code. One space can occupy a tiny %-age fraction causing the layout to wrap. You can fiddle with percentages until it works but it’s unreliable and can break when a new space shows up elsewhere in the HTML. I can see you’ve “conquered” that with float:left; a few times, but floating takes the layout elements out of the page flow, so you then need clearfix to restore order. With flexbox or CSS Grid (support is good for all but IE 10/11 and old android) you can do away with all of that. In fact, as far as I can tell from my brief experiment, you’re not really leveraging the whole grid capabilities except for in a few places like the homepage, so you may not really need an all-encompassing grid at all: for the normal pages, for example, you’d be fine with main column + sidebar. CSS, while still frustrating at times, has got so much better over the years that some of the tools that leaned on as a crutch and got used to over the years are no longer really needed.

Textpattern CMS

Textpattern CMS support forum

#13 2020-02-29 17:55:39

Re: [SOLVED] issues with mobile friendly test

#14 2020-02-29 21:25:32

Re: [SOLVED] issues with mobile friendly test

colak wrote #322009:

colak wrote #322010:

colak wrote #322009:

#15 2020-03-01 10:19:10

Re: [SOLVED] issues with mobile friendly test

#16 2020-03-02 08:32:43

Re: [SOLVED] issues with mobile friendly test

jakob wrote #322016:

#17 2020-03-04 10:48:01

Re: [SOLVED] issues with mobile friendly test

#18 2020-03-04 13:23:30

Re: [SOLVED] issues with mobile friendly test

#19 2020-03-04 14:11:07

Re: [SOLVED] issues with mobile friendly test

#20 2020-03-05 20:01:36

Re: [SOLVED] issues with mobile friendly test

#21 2020-03-06 15:37:10

Re: [SOLVED] issues with mobile friendly test

#22 2020-03-07 22:09:14

Re: [SOLVED] issues with mobile friendly test

#23 2020-03-08 06:25:45

Re: [SOLVED] issues with mobile friendly test

#24 2020-03-08 09:45:27

Re: [SOLVED] issues with mobile friendly test

colak wrote #322097:

Board footer