Hello Dayo,

The .is-mobile is needed because we do not have control over the Joomla template. There wouldn't be a way for us to properly design the layout on mobile devices using media query alone.

Further to that, another advantage of detecting mobile devices using user agent is we do not render all the bloated html codes on mobile devices (that is forcefully hidden using css). We only render what is needed based on what we are trying to display.

I will discuss with the team to see if there's any way that we could solve with the caching issues. What caching mechanism do you use on the site?

Hi,

There is nothing you can do to influence server level caching (Nginx, Vanish etc).

Don't think JS mobile detection is a good idea in any instance but if you insist you have to go down that route, please provide a setting option to disable this.

My site only works correctly when this is disabled/overridden and it would be nice to be able to do this without hacking the code. Alternatively, if this mobile detection is linked to the AMP stuff, then do not do this when AMP is turned off.

Hello Dayo,

Sorry, I think there was some misunderstanding. We are actually not using any javascripts to inject those css classes. We are rendering those classes by determining the user agent of the requester when they are using their mobile browsers. In short, we use php to generate those class names.

Perhaps we could add a settings in the extension to disable such detection and this way, you could style it accordingly using media queries (since you are a developer / designer yourself).

On the extension level, we can't actually utilize media queries (Will get my designer to post the screenshots shortly as to why we are unable to use media queries).

Okay, here's the scenario that is problematic for extensions to fiddle with media queries. Assuming the following scenario of a Joomla template and an extension:

a. browser width 1280px, container 893px : http://take.ms/Q25zp
b. browser width 1280px, container 689px : http://take.ms/l3p53


Method 1 (media queries)
@media (max-width: 801px) { #es .mobile-btn {display:block} }
a. and b. will display .mobile-btn because the browser width is 1280px


Method 2 (JS width detection)
b. will inject .is-mobile when detected container width is below 800px. only b. will display .mobile-btn

Method 3 (PHP devices detection) Current EasyBlog Method
a. and b. will not display .is-mobile is there are non-mobile devices no matter what browser width you are.

Thanks for the detailed explanation.

Still think UA String based rendering is fundamentally flawed. Giving the option to skip this detection seems a workable compromise if you wish to maintain the detection.

BTW, reconsider your Method 1. If the default state of ".mobile-btn" was not to display, neither a. nor b. will display .mobile-btn and it would only be displayed when the browser width is 801px or below.

#es .mobile-btn {display:none}

@media (max-width: 801px) { #es .mobile-btn {display:block} }

Possible alternative is:

@media (min-width: 802px) { #es .mobile-btn {display:none} }

@media (min-width: 802px) { #es .mobile-btn {display:none} }

b. Should display .mobile-btn due to it hit the mobile breakpoint which is below 800px (container width 689px).

@media (min-width: 802px) { #es .mobile-btn {display:none} }

b. Should display .mobile-btn due to it hit the mobile breakpoint which is below 800px (container width 689px).

Sorry but that is incorrect. You are distracted by the container widths but as Mark pointed out in his examples, media queries operate on browser widths (Viewports) and not element container widths. As the viewports for Cases a. and b. are both above 801px, .mobile-btn will not be displayed in either case.

Both this...

#es .mobile-btn {display:none}

@media (max-width: 801px) { #es .mobile-btn {display:block} }

and this...

@media (min-width: 802px) { #es .mobile-btn {display:none} }

Will easily deal with the two scenarios


The whole element container width focus as the basis for choosing to go down the UA String detection road is a big red herring but in any case, I am not asking for an abandonment of your chosen approach, deeply flawed as it is, and all I want is an option to not have to hack the code to correct the flaw.

So please give an option to switch the detection off so you can continue to detect UA Strings as much as you want while those that do not want this can happily co-exist.

A. browser width 1280px, container 893px : http://take.ms/Q25zp
B. browser width 1280px, container 485px : http://take.ms/1mnmK

Ok, let's say ES components mobile breakpoints is 600px. Mobile styling should perform if the wrapper under this threshold.
Try to check the B. , how to perform mobile styling in this situation?

Hi Chang,

Again, container widths are irrelevant to media queries. All that matters is the viewport and in these cases, with viewport widths of 1280px, the user is clearly not on a mobile device no matter what the width of any specific element happens to be.

Anyway, can we focus instead on you adding the option for users to skip the detection? Clearly a win win situation if that is done.

Hello Dayo,
1280px just an example, some mobile devices can goes to 2048px width (https://mydevice.io/devices/). If skip the detection how are we perform mobile styling on ES?

Whether the client is on a "mobile" device or not is actually moot. What matters is the size of the viewport.

If the viewport is large, then you display the "desktop" view and otherwise if not.

On an iPad in landscape orientation for instance, most responsive sites would display a "desktop" view. That an iPad is actually a "mobile" device is besides the point. What matters is that is that the viewport is large enough to display something.

Again, not sure why we are going round in circles here. You are set on UA String based rendering and that is fine with me.

All I am asking for is what Mark suggested several posts ago that you add an option for user to choose to bypass your UA String detection.

I cure have to hack the code to bypass this. Can't you see that this shows there is a problem that needs to be resolved?

So please don't ask me about any more edge case container width scenarios and just kindly look into adding an option for users to not have to hack your code if they do not want your UA String detection based rendering.

You can continue your detection as much as you want in parallel.

Hello Dayo,

Here's what you can do temporarily to disable the user agent detection (We will add this as a settings in the next version). Edit the file /administrator/components/com_easyblog/includes/responsive/responsive.php and at line 390, search for the codes below:

[gist]
/**
* Determines if the current viewer is on a mobile device
*
* @since 5.1
* @access public
*/
public function isMobile($agent = null)
{
static $mobile = null;

if (is_null($mobile)) {

if (is_null($agent)) {
$agent = $this->getAgent();
}

$patterns = array_values($this->mobile);
$patterns = implode('|', $patterns);

preg_match('/' . $patterns . '/is', $agent, $matches);

$mobile = false;

if (count($matches) > 0) {
$mobile = true;
}
}

return $mobile;
}
[/gist]

Replace it with,

[gist]
/**
* Determines if the current viewer is on a mobile device
*
* @since 5.1
* @access public
*/
public function isMobile($agent = null)
{
return false;
}
[/gist]

I do agree that it is a problem and we're trying to find a way to resolve this altogether. I am actually looking at several sites like macrumors.com where it does the same user agent detection as well. I am just wondering what is the cache mechanism that is being employed there.

By the way, I also found several article that allows you to configure Varnish cache based on user agents as well and it seems quite a number of sites are also using the same user agent detection with varnish,

https://stackoverflow.com/questions/16289808/varnish-cache-for-mobile
https://spin.atomicobject.com/2013/02/11/varnish-cache-mobile-devices/
https://www.varnish-cache.org/docs/3.0/tutorial/devicedetection.html
https://drupal.stackexchange.com/questions/171623/varnish-is-serving-sometime-wrong-cache-theme-on-desktop-or-in-mobile

Thanks. Looking forward to the inbuilt option.

As for the approach itself, still think it is not a good idea but no problem if you prefer it.

Sure I could wrangle my Nginx caching to jump through the UA hoops but apart from the static caching issue, I also have issues with the actual rendering itself which I didn't want to get into.

Bottomline is that defeating the .is-mobile class insertion makes my site render properly on mobile and on desktop.

As for mac rumours, I think their site has been the same since 2005 or so and they may still be following approaches from a decade ago.

Just found this which reflects my thoughts: https://developer.mozilla.org/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent.

MDN says...

Serving different Web pages or services to different browsers is usually a bad idea.

And also say...

When considering using the user agent string to detect which browser is being used, your first step is to try to avoid it if possible. Start by trying to identify why you want to do it.

Basically says you can do this if you feel you really have to for some far out edge case that is important to you for whatever reason but you really should not be doing this and you usually don't have to.

In EB's case, the container widths and such brought up as the main reason seem to be very much avoidable and manageable with media queries.

All said though, perfectly fine for EB to do the UA detection based rendering as the team appears to have determined it to be required. With an option to avoid given, seems like a win - win!

Thanks again

Thanks for your input Dayo, we will see what we can do in the future.