Web Layouts for Mobile View- Code Updates

Looking at this finished page here, resizing the window here to simulate different size screens, at first glance it appears that this page would be done, but resizing the browser window does not actually simulate a mobile device. So there is a couple little extra pieces of code that we need to add to make sure that actually when viewing this on a mobile device that it will look as we think it will look. And to show you what I'm talking about here, if I open up the developer tools here in Chrome by right-clicking and inspecting, I'm going to click on this button here, toggle device toolbar.

When I click on that, this is going to switch to a mobile device kind of emulator, if you will. There are different dimensions. Now notice it just says dimensions.

These are not actually simulating what it will exactly look like on iPhones or Samsungs or iPads. This is just the size of those devices. The reason I emphasize that is because we are in Google's Chrome browser.

We're not in Safari. Safari is a different browser rendering engine. Even though they were originally based on the same browser rendering engine, Chrome, well Google, decided to splinter off of the Safari rendering engine and make their own.

So the Safari on mobile devices, iOS, so iPhones and iPads, they can render some things differently. But for the most part, if we're just judging things like size and those kind of things, just looking at the width of, let's say an iPhone SE or a 12 Pro, these are the width and height of those different devices. From a size perspective, then we're going to get a general idea of how this looks.

And let's just look at this. Look at how small this type is here. This is kind of big, but the lines are kind of close together.

So it doesn't exactly look like this design reflowed like this. So here, notice these should be on different lines. They should be bigger, relatively speaking.

This type looks good. This is how we want it to look. But it's not just taking that and making it look like that on a mobile device.

So what's going on here? What's the story? So the coding that we have right now is we're lacking a piece of code that tells a browser, hey, I was designed for mobile phones in mind. So you've got to understand a little bit about the history as to why we need this code. Back in the early days before iPhones were invented, when we just had desktops, desktops would go through various different size screens.

So desktops and laptops, they used to be small and then screens got bigger and then screens got bigger. And we were designing fixed layouts for specific screen sizes. We didn't have phones, we didn't have tablets.

And when the iPhone first came out, we had never designed a website that was going to change and be good for a phone or a desktop. Then eventually tablets came out. Now we need to be good across all different screen sizes.

But when the iPhone first came out, the average desktop display was 1024. So 1024 pixels wide. And so if I resize this and I watch this little dimensions indicator right here, 1024.

I'm just going to get roughly about like that. So about 1024. And if you had 1024 for your screen size, and then you subtracted for your scrollbars, which everybody saw scrollbars back then, you had about 980 pixels of screen space for your content.

So 980 pixels was the visible area that you had. You had a lot of height, whatever you wanted. But when we're just talking about the width, we had 980 pixels of width.

Now, if you take this layout, just look at it like this. Imagine this is the iPhone just came out. Nobody had optimized their website for the iPhone.

So what the iPhone just did is it just scaled it down. And actually look at that nav. And doesn't it look like this just scaled down? I know this text is bigger, but all it did is just take this 980 pixels of content and just scaled it down to fit the iPhone.

Now, because this text is simply laid out, you know, it's just a big column of stuff. The iPhone said, well, I think I can resize that without wrecking the layout. So they also artificially just made that text bigger because they know it would be hard to read.

Now this text here, they didn't want to just make that bigger because they weren't sure if they could change, if it would change the layout or not. So based on some sort of algorithm or something, they decided sometimes they'd make the text bigger, but they didn't increase the line height. They just increased the text size.

And sometimes they wouldn't. So first of all, I don't want browsers. I know I'm using the iPhone in this example, but this is not just limited to iPhone.

This is also Android and so on. So I don't want those mobile devices to decide to sometimes increase my type size if they feel like it. So that's the first thing I want to disable is that sometimes it'll make it bigger, sometimes it won't.

And so there's a little bit of code that we're going to add into our CSS. This is code that we would always be adding to our CSS. And I've got it over here in a snippet file just so we can copy and paste it.

And this is something you'd want to copy and paste into every website you do. I'm going to copy and paste that into our CSS. This is a shared CSS that the entire site is using.

And let's just analyze what it does. Text size adjust. So there's this text size adjustment.

Is it going to decide to adjust the text? I don't want it to. 100% is the normal size. Anything less than that would make it smaller.

Anything more than that would make it bigger. Sometimes they decide to make it 120%, 150%, maybe 200%. I don't want them to adjust the size at all.

I want them to keep it at 100%. Now, theoretically here, we could just have this text size adjust, and we wouldn't need these vendor prefixed versions. Now, vendor prefixed versions start with a dash, and vendors are the different people making the browsers.

So Moz is short for Mozilla. They're the creators of Firefox. WebKit is the rendering engine of Safari.

It used to be that Chrome was a WebKit browser, and then they splintered off and they forked the WebKit rendering engine that Apple created for Safari. And they created something called Blink, which they eventually renamed Chromium. Now Chromium browsers use kind of a splintered-off, forked-off version of WebKit.

But WebKit is addressing WebKit-based browsers, so basically Safari. And the idea is that eventually everything would, normally speaking, adopt a standard CSS. But back in the days when mobile devices were first coming out, the web was innovating very quickly.

And before the web standards were decided, vendors such as Firefox and Safari, they wanted to implement some CSS in their browser, and they didn't want to potentially implement something that would be different than a standard. So they had to put a vendor prefix, meaning this only works in our browsers. It's not official CSS.

It's not standard CSS. And eventually the hope is that we'd move away from the vendor prefixed ones once we have agreed upon a standard, that eventually those things would fall away. And for the most part, we have moved away from those things in web development.

But for a while, we kind of used those. In this case, we still do need to use it. And how would you know if you need to use a vendor prefixed version? Well, there's a website called caniuse.com. I always remember the name of this because I'm like, if it's a new thing, can I use it yet? And technically this is not a new thing.

It's been around for quite a while, but let's just see here, text size adjust. So I'm going to look up text size adjust here. And when we look at this, this gives you all the kind of the main browsers here on the left and lesser known browsers over here on the right.

But these are mobile ones over here. We've got Chrome. And if you look at Chrome, notice that for quite a long time here, since released, it says October 11th, 2016.

I'm going to make this a little bit bigger here so we can For a long time, this has been widely supported. Now, if you look at something like Safari, first of all, these are desktop browsers. This thing that we're doing does not affect desktop.

We're going to actually ignore the desktop. And we're going to look at the mobile browsers over here, ignoring the kind of the lesser browsers here, but looking at things like Safari on iOS. When we look at this here, notice that they say Dash WebKit.

So the regular version of Chrome, Chrome for Android, does not have a little dash there. But this yellow dash, and it says in the little tooltip there, it says Dash WebKit. So they're only supporting this with Dash WebKit, even in the most current version.

This is the most current version here. Up here are past versions. And then down below it are future versions that are going to be coming out soon.

So you could see maybe if something isn't supported here, but it's going to be supported in the next version, you know it's coming soon, for example. But Safari is still requiring the Dash WebKit. Also over here, Firefox for Android is still requiring Dash Moz.

So because those are still requiring that, and they have not moved on to the regular non-vendor prefix version like Chrome has, we still need to keep using those. But maybe at some point in the future, they will drop those vendor prefixes, maybe. But it's up to the browser makers to do that.

So in the meantime, we always put our vendor prefix versions first, with the idea that the official CSS, the standard CSS, comes last. And hopefully at some point we'll be able to delete these, but not yet. So this just says everywhere in my HTML page, just never adjust the text size.

Don't make it bigger, don't make it smaller, keep it 100% whatever size I make it. This is something you should put in every web page you ever do. And now when I hit refresh, now notice that it is not changing the size.

Now I know it's still not mobile-optimized. That's one more piece of code that we're going to need to add. But let me just take this off.

And now if you take a look at this 980 pixel wide page, it just literally scales it down to fit onto let's say an iPhone or Android device. It's doing the scaling, and it's not changing any font size whatsoever. That's good.

I don't want browsers to artificially increase font size based on some arbitrary decision. Okay, so that's step one. Now the next step is to say, I don't want you to just scale it down.

I've designed for this device in mind. So the idea here is that for the original iPhones, and same thing happens on Android today, it would just render this on a 980 pixel canvas, if you will, and then scale that down to fit the viewable area. So there's this concept of how big is what's called the viewport.

So the viewport is, is it the same size as the device or is it not? If it renders on a 980 pixel viewport and then scales that down to fit your device, everything's going to get a lot smaller because this iPhone is only 375 pixels wide. So it's going to scale a 980 pixel viewport rendered page down to 375. That's why everything gets a lot smaller.

Now, if it was an iPad, if an iPad was let's say 768, it wouldn't scale it down that much, which is why things actually looked pretty decent on day one of the iPad, because it wasn't scaling very much. In fact, when you rotate it sideways, it would actually scale up from 980 up to 1024 because the iPad didn't have scroll bars. So things looked pretty decent on tablets without even really adjusting it too much, depending on the size of the tablet.

But on a phone, we definitely need to say, don't render on this 980 pixel viewport. No, actually the viewport should be the same size as the device. If the device is 375, the viewport should be 375.

So this is something that we need to add to every HTML page that we do. I'm going to hop over here to the San Francisco page, right after the meta tag for our Unicode to say all of our special characters should be encoded with the same encoding. We're going to put in another meta tag, and it's the viewport meta tag down here, the VP version of it.

VP is short for viewport. And I'm just going to close this up. So here, the meta tag, meta tags say this is additional metadata, things that the browser should know.

For example, it should know what character set we're using. We're using Unicode. What should it know about the viewport? How big should it be? We have this content attribute, and we say the width of the viewport should not be 980 pixels like it is by default.

It should be the same as the device width. If you're a small device, a medium device, a large device, just tell me what you are. Essentially, don't lie to me saying you're a 980 pixel device, render it at 980 pixels, and then scale it down to fit.

No, just actually tell me the device you are. And because users can scale in and out by pinching to zoom in and out, just in case the browser might have assumed to apply a scale, either zooming in or zooming out, we're going to say that the initial starting scale, right, initial means to start, the starting scale should always be scale of one. You can say a scale of one or 1.0, it doesn't really matter either way.

Either way works. So these are two different settings. One is to say the width equals the width of the device.

And secondly, make sure that you are not scaling the page up or down. So it's just going to be a normal scale at the size of the device. This is something we need to do to say to browsers, we have designed for all different devices in mind.

We've created this fluid, flexible, or responsive page that will adapt and look good. I'm not some really old page designed before phones that was never designed for phones. So I'm going to save that.

And now when I hit refresh, now the page looks as I expect. Because it's not just rendering it on a 980 pixel viewport and then scaling it down. No, it's actually the viewport is the same size as this device.

If it's 375, it's going to render as though it's 375 wide. For another device that maybe is wider, it'll render as a 390 pixel screen there. And let's just see if we can tell that the text wraps a little differently.

Yeah, see the text wraps a little differently. Also, if I went to responsive, that just means that I can play with this and see how it just changes. Notice how it's not scaling things.

It's just reflowing because the viewport is whatever size I'm choosing to make it. So that is something that you will always add. These two things, this code right here, and this code right here, you will always add that to every web page that you create from now on to make sure that it treats you like a modern web page, assuming that you're developing a page that will look good across all screen sizes.

One final thing here that is more of a warning of don't do this is there's this thing called initial scale, which is our default starting scale. There is also a maximum scale, and I'm going to say do not do this. So maximum scale, if you set the initial scale and the maximum scale, so think about pinch to zoom in and out.

If you start at a scale of one, and the biggest you can make your scale is one, you're basically preventing people from zooming in and out on the page. This is really bad for accessibility, and sometimes I've seen people do this on websites, and it's just it's a really bad idea because then you can't zoom in and out on the page.

Have you ever been on your phone, and you try to pinch, and it just won't zoom? That's because somebody's put in that the starting scale and the maximum are the same, meaning you can't change it.

Do not do this, and if you ever get websites that do do this, delete that code because it's bad for accessibility because those people that need to zoom to be able to see things better, we should allow them to zoom. Why arbitrarily decide no, I don't want people to zoom. I don't want people to be able to see my content.

It's very bad for accessibility, so make sure that you do not add that, and if you ever see it, make sure you delete it because it's not good for accessibility. You're going to go ahead and do this in exercise 4d. Even though it's not adding a lot of code, it is very important that we do this, and that we also remember to do this on every single website we do.

If you're only previewing these things on desktops, you will not see them unless you're using that mobile device emulator, and once we're done with this, by the way, just make sure that you click off to take that off so that when you're in the normal dev tools, you're seeing how it will look on a desktop, and then only when you want to see the mobile preview, click that button there, and then use that.

So that's always something you want to make sure you see it in both kind of the desktop and the mobile version just to see these because you're only going to see this issue when you either view it on a mobile device or you're using this emulator which emulates a mobile device.

All right, so go ahead and do exercise 4d where you can see this and practice yourself.