某廠面試題:為何這樣處理移動端適配不行?
參加某公司面試,當面試官問到移動端如何適配的時候,我給出的方案是:
在head裡面插入js代碼")
//假設設計稿是640的寬度
var width = (window.innerWidth)*100/640;
document.write("&然後網站用rem布局.
不知道此方法的缺陷是在哪裡,望高人指點...
這個寫法不如直接設置html的style,這樣比較不會有選擇器優先順序的問題,另外加上橫豎屏時的重置處理更好。我的建議是首先看業務如果是以文字為主的網站,比如小說網站之類的,應該考慮直接使用px作為單位。因為用戶使用大屏幕手機的時候期望的肯定是看到更多的文字,而不是更大的文字。如果是以業務交互和排版要求比較精細的網站,可以等比縮放rem值以達到展現的一致性。但同時也應該考慮Retina屏幕對排版精細度的影響,尤其是border和icon,這之間的不同可以參考網易移動端和淘寶首頁的適配區別,主要原理是縮放layout viewport達到精細的要求(Android對此方案有兼容問題,可通過判斷做降級處理),這個方案的缺點是需要對查看原圖之類的需求做放大處理。
總之,就是做到符合用戶預期的前提下,盡量精緻頁面表現
看到document.write一律先扣5分。
首先,如果你用rem來布局,設置字體大小,可以不需要使用js
html {
font-size: calc(100vw/6.40);
}
其次,如果你擔心calc或者vw的適配性,可以用js來修改html的行內樣式,而不是去再加一個行內樣式表。比如,如果頁面是下面這種情況,js加的行內樣式表,可就沒用啦!
&
&
&
而像下面這樣,並沒有增加代碼量,但是不是更好呢?
&
&
&
再其次,rem也並不是萬能的。比如說,如果你用了translate,並且移動的數值不是一個整數的話,字體可能會模糊。不知道有沒有其他朋友遇到過這個問題。解決Swiper中translate3d導致字體模糊 這個問題我也不確定是否是文章中描述的原因,但在把數值改為整數後,問題的確是被解決了!
最後,個人認為document.write容易引起未知錯誤,比如我們上面提到的小bug;不過document.write也並不是一無是處啊,畢竟寫起來簡單,看這裡——html5-boilerplate/index.html at master · h5bp/html5-boilerplate · GitHub 第26行,不也是用了document.write么?所以你們啊,naive,不要一看到document.write,就要給人扣分,將來報道出了偏差······;如果要手動創建一個style,然後再插入進去,雖然能夠精確地控制插入的位置,能夠避免『其次』中說的bug,不過多了幾多行代碼。總結一下,document.write並不建議使用,但要盡量不用。參考:javascript - Why is document.write considered a "bad practice"?以上!
首先你沒有考慮到viewport的問題,我懷疑你對viewport等概念都不清楚。不知道你面試的是什麼崗位,具體是偏樣式的前端還是偏JS的甚至是偏UX的,具體來說「移動端如何適配」是一個相當大的問題,大到我隨便想都不可能一條條給你列全。更好的問法是「做移動端適配時,如何解決字體blah blah blah」或者說「針對某種情況blah blah blah有什麼需要做的」這樣的問題。
樣式這方面比如CSS你知道會有媒體查詢這回事,藉助媒體查詢/modernizr等玩意兒這方面要做的其實是很多的,不只是字體的問題。當然了你那個設置字體的方法肯定也是不優的,就像賀叔叔說的,說什麼也不能document.write呀,你至少創建個style元素,插在head裡面,而且就算這樣你也要保證你的設置是生效的。字體之外呢,還有很多東西,比如圖片resource有些是不是要根據是否retina來載入高清圖?
(好了,這方面我說不下去了。..(冷場
JS方面的細節也是很多的,比如&
(又說不下去了UX方面呢,比如如何減少首頁白屏的時間,對於較大的網頁應用,是不是要提供相應的載入反饋?onclick/ontouchmove這個點同樣會大幅影響體驗。然後用戶tap一個東西,要給他什麼樣的反饋呢?在動畫兼容性拙計的情況下,如何做漸進式設計,給老設備一個fallback?screenorientationchange的情況下要不要做相應反饋?要不要把用戶引導到原生app?除此之外還涉及到導航欄等玩意兒的重設計...看到賀老師先自扣5分
這樣寫能用就行一個document.write();你把頁面都覆蓋了,還談什麼適配...
在文檔已完成載入後執行document.write,整個HTML頁面將會被覆蓋
去看看最近那個 網易淘寶的移動端適配方案對比!
不會用media嗎?
還有視網膜屏幕,需要通過視網膜屏幕的dpr去計算物理像素
1.容易覆蓋整個HTML頁面2.IE中起不到修改樣式的作用
做個實驗試試呀。另外write方法在文檔繪製完成後用會清除頁面,要不你試試直接改style。以前用sass,按照一個固定像素設計稿用rem做過響應,感覺過分追求元素相對尺寸一致頁面並不一定好看。
馬上看魔術團了 先標記一下
大概會遇到塊級元素 嵌套 行內元素時,瀏覽器預留寬度過高導致出現 莫名其妙的類似padding的空白需要手動設定body的font size修復推薦閱讀:
※項目中大量使用css !important 如何破局?
※前端新人願意以付出免費勞動力為代價,在職場上獲得提升,可行嗎?
※多元素浮動時的排列問題?
※手機html網頁和電腦上的html網頁在製作上有什麼區別?
※各個平台下相對比較好的 Web 英文字體分別是什麼?
TAG:前端開發 | HTML | CSS | JavaScript | 移動端 |