


What is Viewport
Mobile browsers place the page in a virtual "window" (viewport). Usually this virtual "window" (viewport) is wider than the screen, so that each web page does not need to be squeezed. In a very small window (which would break the layout of a webpage that is not optimized for mobile browsers), users can pan and zoom to see different parts of the webpage. The mobile version of Safari browser recently introduced the viewport meta tag, which allows web developers to control the size and zoom of the viewport. Other mobile browsers also basically support it.
Viewport Basics
A commonly used viewport meta tag for a page optimized for mobile web pages is roughly as follows:
width: control viewport The size can be specified as a value, such as 600, or a special value such as device-width, which is the width of the device (in CSS pixels when scaled to 100%).
Height: Corresponding to width, specify the height.
initial-scale: the initial scaling ratio, that is, the scaling ratio when the page is loaded for the first time.
maximum-scale: The maximum scale the user is allowed to zoom to.
minimum-scale: The minimum scale to which the user is allowed to zoom.
User-scalable: Whether the user can manually zoom
Some questions about viewport
Viewport is not just a unique attribute on ios, there are also viewports on android and winphone. The problem they want to solve is the same, that is, ignoring the real resolution of the device and directly resetting the resolution between the physical size and the browser through dpi. This resolution has nothing to do with the resolution of the device. For example, if you take a 3.5-inch-320*480 iPhone 3 gs, a 3.5-inch-640*960 iPhone 4, or a 9.7-inch-1024*768 iPad 2, although the resolutions and physical sizes of the devices are different, you can set The viewport makes them have the same resolution in the browser. For example, if your website is 800px wide, you can set the width of the viewport to 800 so that your website can be displayed on the entire screen on these three different devices.
I believe that every student who has a little knowledge of viewport should already know the above knowledge. This is not the focus of what I want to say today. What I want to explain is some differences in the performance of viewport on ios and android.
Searching for knowledge about viewport on the Internet, basically all the information is as follows:
The meaning of this code is to make the width of the viewport equal to the physical device True resolution on, not allowing user scaling. All mainstream web apps are set up like this. Its function is to deliberately abandon the viewport and not scale the page. In this way, the dpi must be the same as the real resolution on the device. Without any scaling, the web page will appear higher. exquisite. Students who play PS should all know what it will look like when you directly scale a 1000 * 1000 picture to 500 * 500 points, right? The distortion of the picture cannot be escaped.
But the application I want to make is just the opposite. It needs to use viewport and zoom. No matter what the real resolution is, no matter what the physical size is, I want to have a uniform resolution in the browser and not allow the user to zoom. The devices I used for testing include: iPhone 4, iPad 2, htc's g11, aquos phone (android system) from an unknown manufacturer, ASUS's android pad, and Dell's winphone. Then I encountered the following problems along the way:
1) If the viewport is not set explicitly, the width defaults to 980. If the width of all elements on the page is less than 980, the width is 980. If the widest position of the page exceeds 980, then the width is equal to the maximum width. In short, the entire page can be displayed from left to right by default. If the viewport is set, for example, user-scalable=no is simply set, such as , then the width will still be displayed as 980 under ios (that is, it will be scaled by dpi by default), but it will not be displayed under android and winphone. After scaling, the browser resolution is consistent with the actual setting resolution.
2) For ios devices, setting width can take effect, but for android, setting width will not take effect. For ios devices, the scaling ratio, that is, dpi, is automatically calculated based on the width you set and the real resolution. However, under Android, the width you set is invalid. What you can set is a special field target-densitydpi. You can refer to target-densitydpi for more information. Check out this article: http://hi.baidu.com/j_fo/blog/item /748361279ebccd18908f9d7d.html. In other words, there are three variables: browser width, device real width, and dpi. Let’s simply use a formula to express the relationship between them (not a real relationship, just for simple explanation). Device real width * dpi = browser width. Among the three variables here, the device’s real width is a known value that we cannot operate. , we can set one of the other two variables to affect the other. In ios, what we can change is the browser width, and the dpi is automatically generated. In Android, what we can change is the dpi, and the browser width is automatically generated. For Android, no matter how we set the width, it will not affect the browser width.
ps: Let me talk about another strange problem here: in htc's g11 (I only have this one htc phone, and I haven't tested the others), if the dpi is set without setting the width explicitly, then user -scalable=no does not take effect, that is to say: , the user cannot be prevented from scaling the screen. We need to set the width value explicitly. Although this value does not have any impact on the browser resolution under Android (it will still have an impact on iOS), we still have to set it, and this value must be greater than 320. If it is less than or equal to 320, user-scalable=no cannot take effect. This problem only occurs on htc's g11 phone, not on aquos phone. Being compatible with android is really a headache @_@. I don’t know how many pitfalls there will be in the future. On winphone, the result is even stranger: if I set the width of the viewport to a value greater than 480, user-scalable=no will be invalid, but if I set a value less than 480, user-scalable=no will take effect. But no matter what value I set for the width of the viewport, it does not have the expected impact on the width actually displayed by winphone, and target-densitydpi has no impact either. Set the width. If it is less than 480, the screen will scale, but the scaling ratio is completely different from what I expected. I don’t know what rules it scales according to. I don't know if this is a Winphone problem or a Dell implementation problem.
3) This article should be directly related to the previous one: when the iOS device is in horizontal or vertical screen, it will automatically adjust the dpi. Regardless of the horizontal screen or the vertical screen, it can ensure that the browser width is equal to the value set in the viewport. , so when the screen is in landscape or portrait mode, the size of the content displayed on the page will automatically scale and change. When the Android phone is in landscape or portrait mode, the dpi will not change, and when the screen is in landscape or portrait mode, the web page will not be zoomed. For this reason, ios can ensure that horizontal and vertical screen pages will not have scroll bars and fill the screen, but Android cannot guarantee this. If the screen is full horizontally, it cannot be full screen vertically, and vice versa.
4) For ios devices, if the width display is defined and the widest position of the page exceeds the width, the width is invalid and will still be displayed according to the widest width (there will be no scroll bar). But a very strange problem will arise at this time. After you switch the screen of your phone between landscape and portrait several times, you will find that your page is automatically enlarged and a scroll bar appears, but in fact, the enlarged width is not the same as the width you set. It doesn't matter. To prevent this, you need to set the width to be larger than, or the same as, the widest part of the page.

本篇文章带大家了解一下HTML(超文本标记语言),介绍一下HTML的本质,HTML文档的结构、HTML文档的基本标签和图像标签、列表、表格标签、媒体元素、表单,希望对大家有所帮助!

不算。html是一种用来告知浏览器如何组织页面的标记语言,而CSS是一种用来表现HTML或XML等文件样式的样式设计语言;html和css不具备很强的逻辑性和流程控制功能,缺乏灵活性,且html和css不能按照人类的设计对一件工作进行重复的循环,直至得到让人类满意的答案。

总结了一些web前端面试(笔试)题分享给大家,本篇文章就先给大家分享HTML部分的笔试题(附答案),大家可以自己做做,看看能答对几个!

HTML5中画布标签是“<canvas>”。canvas标签用于图形的绘制,它只是一个矩形的图形容器,绘制图形必须通过脚本(通常是JavaScript)来完成;开发者可利用多种js方法来在canvas中绘制路径、盒、圆、字符以及添加图像等。

html5废弃了dir列表标签。dir标签被用来定义目录列表,一般和li标签配合使用,在dir标签对中通过li标签来设置列表项,语法“<dir><li>列表项值</li>...</dir>”。HTML5已经不支持dir,可使用ul标签取代。

在html中,document是文档对象的意思,代表浏览器窗口的文档;document对象是window对象的子对象,所以可通过“window.document”属性对其进行访问,每个载入浏览器的HTML文档都会成为Document对象。

html5支持boolean值属性;boolean值属性指是属性值为true或者false的属性,如input元素中的disabled属性,不使用该属性表示值为flase,不禁用元素,使用该属性可以不设置属性值表示值为true,禁用元素。


Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

AI Hentai Generator
Generate AI Hentai for free.

Hot Article

Hot Tools

SAP NetWeaver Server Adapter for Eclipse
Integrate Eclipse with SAP NetWeaver application server.

MinGW - Minimalist GNU for Windows
This project is in the process of being migrated to osdn.net/projects/mingw, you can continue to follow us there. MinGW: A native Windows port of the GNU Compiler Collection (GCC), freely distributable import libraries and header files for building native Windows applications; includes extensions to the MSVC runtime to support C99 functionality. All MinGW software can run on 64-bit Windows platforms.

VSCode Windows 64-bit Download
A free and powerful IDE editor launched by Microsoft

MantisBT
Mantis is an easy-to-deploy web-based defect tracking tool designed to aid in product defect tracking. It requires PHP, MySQL and a web server. Check out our demo and hosting services.

mPDF
mPDF is a PHP library that can generate PDF files from UTF-8 encoded HTML. The original author, Ian Back, wrote mPDF to output PDF files "on the fly" from his website and handle different languages. It is slower than original scripts like HTML2FPDF and produces larger files when using Unicode fonts, but supports CSS styles etc. and has a lot of enhancements. Supports almost all languages, including RTL (Arabic and Hebrew) and CJK (Chinese, Japanese and Korean). Supports nested block-level elements (such as P, DIV),
