⑴ 什麼是 HTML 標簽語義化
作為一個前端開發人員，你要是沒有聽說過 CSS，那你肯定是一個 「out-man」 。隨著 CSS 的深入人心，結構、表現與行為的逐漸分離，HTML 語義化成了炙手可熱的賣點。 語義化的 HTML 首先要強調 HTML 結構一個網頁就好像一幢房子，HTML 結構就是鋼筋混泥土的牆，一幢房子如果沒有鋼筋混泥土的牆那就是一堆廢磚頭，也就稱不上是房子了。CSS 是裝飾材料，是油漆，是用來裝飾房子的。CSS 如果沒有 HTML 結構那也就什麼都不是了，沒有了實際使用價值。CSS 完全依靠引用它的 (X)HTML 文檔。如果你想使 CSS 的能力發揮到極致，提供一個既干凈又有結構的 HTML 是非常必要的。 其實HTML 中的標簽都有他自身的含義，只是常常被忽視——就像表格一直充當著網頁布局的角色。還好隨著 CSS 的重現江湖，表格也終於回到他的本質工作——列表數據。它會告訴我們說：「這行是一個標題；這幾行組成了一個段落；這些文字是項目列表……」在做前端開發的時候要記住：HTML 告訴我們一塊內容是什麼（或其意義），而不是它長的什麼樣子。寫語義化的 HTML 結構其實很簡單，首先掌握 HTML 中各個標簽的語義，在看到內容的時候想想用什麼標簽能更好的描述它，是什麼就用什麼標簽。<Hx><h1>、<h2>、<h3>、<h4>、<h5>、<h6> 作為標題使用，並且依據重要性遞減，<h1> 是最高的等級。<p>段落標記，知道了 <p> 作為段落，你就不會再使用 <br /> 來換行了，而且不需要 <br /> 來區分段落與段落。<p> 中的文字會自動換行，而且換行的效果優於 <br />。段落與段落之間的空隙也可以利用 CSS 來控制，很容易而且清晰的區分出段落與段落。<ul>、<ol>、<li><ul> 無序列表，這個被大家廣泛的使用，<ol> 有序列表也挺常用。在 web 標准化過程中，<ul> 還被更多的用於導航條，本來導航條就是個列表，這樣做是完全正確的，而且當你的瀏覽器不支持 CSS 的時候，導航鏈接仍然很好使，只是美觀方面差了一點而已。<dl>、<dt>、<dd><dl> 就是「定義列表」。比如說詞典裡面的詞的解釋、定義就可以用這種列表。<em>、<strong><em> 是用作強調，<strong> 是用作重點強調。<table>、<td>、<th>、<caption>、 summary(X)HTML中的表格不再是用來布局。如果是為了標記列表的數據，就應該使用表格了。<th>為表格標題，屬性 summar 為摘要（要想提高搜索的排名這個絕對不應該少），<caption> 標簽為首部說明，<thead> 標簽為表格頭部，<tbody> 標簽為表格主體內容，<tfoot> 標簽為表格尾部。<ins>、<del>知道<del> ，就不要再用 <s> 做刪除線了，用 <del> 顯然更具有語義化。而且 <del> 還帶有 <cite> 和 <datetime> 來表明刪除的原因以及刪除的時間。<ins> 是表示插入，也有這樣的屬性。<abbr>、<acronym><abbr> 標簽是表示 web 頁面上的簡稱，<acronym> 標簽為取首字母縮寫。alt 屬性和 title 屬性title 屬性用來為元素提供額外說明信息，但是並不是必須的。alt 屬性為不能顯示圖像、窗體或 applets 的用戶代理（UA），指定替換文字。替換文字的語言由 lang 屬性指定。讓你語義化 HTML 結構的無數條理由：1、去掉或樣式丟失的時候能讓頁面呈現清晰的結構。HTML 本身是沒有表現的，我們看到例如 <h1> 是粗體，字體大小 2em；<strong> 是加粗的， 不要誤會這是HTML的表現，這些其實是 HTML 默認的 CSS 樣式在起作用。所以去掉或樣式丟失的時候,也能讓頁面呈現清晰的結構，增強頁面的可讀性。 2、屏幕閱讀器（如果訪客有視障）會完全根據你的標記來「讀」你的網頁。如果你使用的含語義的標記，屏幕閱讀器會根據你的標簽來判斷網頁的內容，而不是一個字母一個字母的拼寫出來。 3、PDA、手機等設備可能無法像普通電腦的瀏覽器一樣來渲染網頁（因為這些設備對 CSS 的支持較弱）使用語義標記可以確保這些設備以一種有意義的方式來渲染網頁。理想情況下，觀看設備的任務是符合設備本身的條件來渲染網頁。 4、搜索引擎的爬蟲也依賴於標記來確定上下文和各個關鍵字的權重。搜索引擎的爬蟲也是網站的「訪客」，現在它們是極其寶貴的用戶。沒有他們的話，搜索引擎將無法索引你的網站，然後一般用戶將很難過來訪問。 5、便於團隊開發和維護在團隊中大家都遵循同一個標准，可以減少很多差異化的東西，方便開發和維護，提高開發效率，甚至實現模塊化開發。
⑵ 前端語義化是什麼意思
1、「語義化」指的是機器在需要更少的人類干預的情況下能夠研究和收集信息，讓網頁能夠被機器理解，最終讓人類受益。
2、語義化的主要目的就是讓大家直觀的認識標簽(markup)和屬性(attribute)的用途和作用
3、根據內容的結構化（內容語義化），選擇合適的標簽（代碼語義化）便於開發者閱讀和寫出更優雅的代碼的同時讓瀏覽器的爬蟲和機器很好地解析。
⑶ 前端是有多難看完你就知道了
最近感覺追不動前端的發展了，寫篇文章感嘆一下。
HTML
我知道有一些學校會教一些簡單的網頁製作，就是用 Dreamweaver 點一點的那種。大多也會留作業，最後交作業的時候看起來也像模像樣。
只要不看代碼。
看了代碼感覺寧願選擇死亡。
table 布局，無意義的 dom 節點。大小寫混用，縮進混亂。
作為一個前端工程師，至少要寫明白自己寫的聲明是什麼意思對吧？
然後還得減少不必要的 dom 節點，畢竟很多文章說節點多會影響渲染速度(ps: 我是不在乎的，我覺得有點兒矯枉過正的味道了)
然後比較重要的一點兒是對於語義化標簽的見解。比如什麼時候該用 ul, 什麼時候該用 section, aside
至於 head 裡面的那些無聊的聲明只要會復制粘貼就好了，我覺得沒什麼意思
自信做到這些的應該算差不多了
文章說的是前端有多難，很多人都覺得這些標簽簡單。然而想像一下，要寫多少的標簽才能理解語義化的意義？要寫多少頁面才能真正的明白這個節點應該寫什麼標簽？如何組合才算合理？
CSS
然後是關於 CSS，我覺得這方面是很復雜的。並不像很多人覺得只是一些單詞的組合。
一開始我會改 background-color 覺得開心得不行，以為掌握了
後來無限突破視野。
在第一次寫超過50個class之後就感覺想死，重復性勞動，樣式修改調試，寫法丑。。。
接觸到 Sass 之後像是發現了新大陸，有一段時間甚至不會寫原生 css 語法了。
然後折騰: Sass -> Stylus
到這里結束了么？ naive
後面還有postcss, cssnext 這些東西。
在 react 生態中還有 css-moles, css-in-js 這些鬼東西。
雖然語法都不是很難。但是這么長時間的折騰下來，雖說提升是有的，但並沒有感覺到生產力有多少巨大的提升。
css 到這里還沒完。
還有BEM的命名方式要去理解。
到這里依舊沒有完。
css3 的新特性，還有各種 hack。比如如何實現footer始終在底部，內容始終撐滿全局？如何實現條紋？
到這里結束了么？
依舊沒完。
css stage 4 等著去學習。
還有精力？
可以試著多做些兼容性相關的東西。會崩潰，相信我
到這里？
在我的視野中差不多算結束了，然而有誰能確定明天有沒有一個什麼new-css之類的東西解決什麼問題。
JS
來了來了，前端的一個核心。
說JS輕松么？咱們來扯扯。
首先是各種 dom 的增刪改，然後是ajax相關。學會了差不多能做簡單的頁面了。
然後對非同步的理解。只有理解了非同步才能正常地寫js。
然後是對js語言特性的理解。比如ES5如何實現繼承什麼的，閉包。
總之這些就是面試題總是會問的東西。
之後還應該理解設計模式對吧？
到這里是正常的語言應該學習的內容了。然而js到這里只是起步。
之後一個前端工程師還得會 ES2015/2016 之類的吧。現在不寫個async誰好意思說自己是寫前端的？
之後應該是配合工具了，後文說。
繼續順著語言往下說。會了 ECMAScript 就能做個合格的前端了么？
還早呢。
之前火的 coffee script 現在不行了，然而 TypeScript 火了啊。不學一下怎麼好意思追前端？
ts 對於之前寫 Java, C# 的非常友好，基本語法沒什麼變化。然而可苦了那些不寫這些語言的同學。語法改變倒是其次，思維方式的轉變才是難以接受的。
現在還有 Elm 了。。。
我覺得我老了，追不上了
⑷ 前端基礎必備知識有哪些
基礎：HTML/CSS/JavaScript
框架：VUE
UI：elementUI
⑸ 為什麼前端那麼多div
其實並不是div多不多的問題，發展到現在前端代碼編寫鼓勵使用語義化標簽，如
<title>：頁面主體內容。
<hn>：h1~h6，分級標題，<h1>與<title>協調有利於搜索引擎優化。
<ul>：無序列表。
<li>：有序列表。
<header>：頁眉通常包括網站標志、主導航、全站鏈接以及搜索框。
<nav>：標記導航，僅對文檔中重要的鏈接群使用。
<main>：頁面主要內容，一個頁面只能使用一次。如果是web應用，則包圍其主要功能。
<article>：定義外部的內容，其中的內容獨立於文檔的其餘部分。
<section>：定義文檔中的節（section、區段）。比如章節、頁眉、頁腳或文檔中的其他部分。
<aside>：定義其所處內容之外的內容。如側欄、文章的一組鏈接、廣告、友情鏈接、相關產品列表等。
<footer>：頁腳，只有當父級是body時，才是整個頁面的頁腳。
<small>：呈現小號字體效果，指定細則，輸入免責聲明、註解、署名、版權。
<strong>：和em標簽一樣，用於強調文本，但它強調的程度更強一些。
等等...
但是實際編寫過程中的div使用更方便，所以頻率比較高而已
⑹ 學習前端html與html5有什麼區別
HTML代表超文本標記語言，用於使用標記語言設計網頁。HTML是超文本和標記語言的組合，超文本定義了網頁之間的鏈接；標記語言用於定義標記內的文本文檔，該文檔定義網頁的結構。此語言用於注釋（在計算機注釋中）文本，以便機器可以理解它並相應地操作文本。
大多數標記（例如HTML）語言都是人類可讀的。該語言使用標簽來定義必須對文本進行哪些操作。它用於在網頁上構造和呈現內容。
HTML5是HTML的第五個版本，HTML5中刪除或修改了許多元素。
HTML5和HTML的區別
首先，HTML5已經遠遠超越了標記語言的范疇，它的設計目的是在移動設備上支持多媒體，和HTML比起來，深度和廣度上都做了進一步提升。
接著，我們來看一下兩者的聲明文件類型：
HTML：
HTML5.0：文檔聲明HTML5方便書寫，精簡，有利於程序員快速的閱讀和開發。
2、結構語義區別
html：沒有體現結構語義化的標簽，如：<div id="nav"></div>
html5：添加了許多具有語義化的標簽，如：<article>、<aside>、<audio>、<bdi>...
相對於HTML，HTML5中新增和修改了一些元素。
3、繪圖區別
HTML：指可伸縮矢量圖形，用於定義網路的基於矢量的圖形。
HTML5：HTML5的canvas元素使用腳本（通常使用JavaScript）在網頁上繪制圖像，可以控制畫布每一個像素。
4、音頻和視頻的支持
HTML如果不使用Flash播放器支持，它不支持音頻和視頻。HTML5使用<audio>和<video>標簽來支持音頻和視頻控制。
5、語法的處理
HTML無法處理不準確的語法；HTML5能夠處理不準確的語法。
⑺ 前端設計為什麼要進行標簽語義化
打個比方，今日頭條里的新聞都是從各大新聞媒體的網站中搜集新聞（如新浪網，光明網等），頭條就需要處理大量的來自不同網站的新聞頁面，細看每個新聞頁面，需要挑出頁面里的正文內容，作者的名字還有發稿的時間等等。這時候包裹這些重要信息的標簽就起到了重要的作用——幫助識別標簽里的內容。
語意化標簽能夠讓機器可以讀懂內容。
如果希望進一步了解可以看一下知乎：http://www.hu.com/question/20455165
⑻ 前端需要哪些知識
前端前景是很不錯的，像前端這樣的專業還是一線城市比較好，師資力量跟得上、就業的薪資也是可觀的，學習前端可以按照路線圖的順序，
0基礎學習前端是沒有問題的，關鍵是找到靠譜的前端培訓機構，你可以深度了解機構的口碑情況，問問周圍知道這家機構的人，除了口碑再了解機構的以下幾方面：
1. 師資力量雄厚
要想有1+1>2的實際效果，很關鍵的一點是師資隊伍，你接下來無論是找個工作還是工作中出任哪些的人物角色，都越來越愛你本身的技術專業前端技術性，也許的技術專業前端技術性則絕大多數來自你的技術專業前端教師，一個好的前端培訓機構必須具備雄厚的師資力量。
2. 就業保障完善
實現1+1>2效果的關鍵在於能夠為你提供良好的發展平台，即能夠為你提供良好的就業保障，讓學員能夠學到實在實在的知識，並向前端學員提供一對一的就業指導，確保學員找到自己的心理工作。
3. 學費性價比高
一個好的前端培訓機構肯定能給你帶來1+1>2的效果，如果你在一個由專業的前端教師領導並由前端培訓機構自己提供的平台上工作，你將獲得比以往更多的投資。
希望你早日學有所成。
⑼ 前端常用的框架有哪些
一、 Web前端框架之Angular 2+
Angular 2+優點解析：
Angular 2+ 的最大優勢在於它的流行程度。也有人認為它和 Google 密切相關的名字，會影響團隊使用它。Angular 1 的迅速流行是因為那些來自其他互動式應用程序開發環境的人會發現對於開發單頁面 Web 應用程序具有相似的模型-視圖模式。通過對 Angular 1 進行現代化演變和重新構建框架的某些部分，Angular 2+ 已經真正的爆發了，大量的正式的和非正式培訓機構數量都讓人印象深刻，開發者有很強的市場競爭力。對於用戶來說它有一套用於構建用戶界面的豐富組件，這也是本系列中少有的幾個框架能夠做到這點。
缺點解析：
我們覺得 Angular 框架著重於在單個頁面應用程序中創建用戶界面並沒有處理構建完整的 Web 應用這個更大的關注點，如果不及早確定下來，這將會導致整個項目難以維護，在實際項目中，運行時提供不屬於核心框架的技術往往讓人覺得不可思議，這大大降低了 TypeScript 對最終開發者的價值。
發展方向：
Angular 5 剛剛發布，這看來是 Angular 已經成功的印證了快速發布版本的承諾，在 Google 的持續支持下，Angular 會越來越成熟。
像許多的大型組織一樣，Google 具有多重(分裂)的人格，從外表上看，Angular 團隊和那些專注於瀏覽器標準的團隊之間顯得很和諧。但我們的觀點是，和諧只是一層薄薄的窗戶紙。Angular 團隊對於 Web 組件和漸進式 Web 應用沒有一個真正解決方案。我們認為，業界普遍認可的標准將會在 Angular 框架中會逐步實現，這將會影響到如何更好的構建 Angular 應用將成為一個中/長期的風險。
使用環境：
如果你需要在一個大型的框架內獲取技術資源，框架內的技術通常很容易移植;或者你需要在框架中訓練開發人員，並且還要有一定的信心，他們會在短期內獲得一定的開發能力，這樣的話你可以考慮 Angular 2+ 。需要注意的是 Angular1(angular.js)與 Angular2+ 是截然不同的，其中的應用、技術和經驗不能直接移植到 Angular2+ 的開發中去。
如果你的 Web 應用能夠很好的轉化為標準的模型-視圖模式，那麼你也可以忽略其他直接考慮使用 Angular2+ 。
如果你對 Google Material UX 設計模式滿意，那麼 Material Angular 是遵循該模式的一種快速、簡單且可靠的方式。
二、Web前端框架之React + Rex
React + Rex優勢解析：
React 和 Rex 的最大優勢在於它們相對簡單和專注。做一件事情並把它做好是非常困難的，但這兩個庫都很有效地完成了它們的目標。雖然對於某些狀態容器方法可能是外部的，但大多數開發人員還是可以輕松掌握概念，並了解單向數據體系結構的好處，簡化大量的用戶界面應用程序。
缺點解析：
React 和 Rex 最大的弱點不是它們是什麼，而是它們不是什麼。要構建一個功能豐富的 Web 應用程序，你需要許多功能，一旦脫離 React 和 Rex 和其他一些庫的核心，你將發現一個非常分散的社區，擁有無數的解決方案和模式，不容易整合在一起。
因此，雖然 React 和 Rex 都是非常專注的庫，但缺乏經驗的團隊還是會很容易地生成不可維護的解決方案，而不是意識到他們所做的選擇會導致性能不佳或錯誤。即使有經驗的開發人員也可能意識到，一個鬆散的架構或慣例可能會在未來困擾他們。
假省錢是一種對自己的欺騙，組織范圍內採用 React 和 Rex 將輕松降低無效率問題。沒有其他庫和模式的廣泛約定和標准化，標准化 React + Rex 比較於我們正在採用的 JavaScript 來編寫我們的應用程序效率要高。
發展方向：
Facebook 和 React 最近從繁瑣的附加專利糾紛中抽離，他們認識到，就像其他項目一樣，更廣泛的社區能夠提高自己的聲音。我覺得這有助於 Facebook 意識到他們還不能更好地了解我們，相信我們來引導項目。希望這將繼續貫穿項目的特點和技術方向。
很難預測 React 和 Rex 的未來。但是，將庫集中在一起，確實會顯著提高適應性，大多數React + Rex 模式都會促進一個分離的體系結構，從而可以輕松地進行重構和迭代。兩年前，大家喜歡的還是React + Flux，但整個社區很快就擁抱了Rex。思維或模式的其他重大轉變可能很容易被採納。這種關鍵能力可能會持續到未來。
使用環境：
如果你很少需要手把手指導，並且正在尋找更好的庫而不是全面的框架，那麼 React + Rex 可能是正確的。在這一過程中，你不僅需要對你的團隊和組織的能力保持誠實，還要在你的初始開發過程中，以及在整個應用程序的長期維護過程中保持誠實。
三、Web前端框架之Vue.js
vue.js優勢介紹：
漸進式構建能力是vue.js最大的優勢，vue 有一個簡潔而且合理的架構，使得它易於理解和構建。
vue 有一個強大的充滿激情人群的社區，這為vue.js增加了巨大的價值，使得為一個空白項目創建一個綜合的解決方案變得十分容易。
缺點介紹：
在模型-視圖應用程序和狀態容器類型的應用程序之間的互相轉換可能會令人感到困惑，即使沒有完美包含一個模式到另一個模式的完美轉換，但讓人感覺希望能維持兩個模式的相關性。對於那些期待vue.js完美解決方案，並可能導致難以維護不一致的應用程序的人來說，這至少是令人困惑的。
一個更大的挑戰是vue.js依賴於一個單獨的人，很明顯，其他的項目基本是由一個組織提供支持，但這讓人感覺更加有意義，雖然它有一個強大文件的社區和許多有創新的新增項目，但是 vue 核心的開發基本落在一個人身上。
我們很高興看到 vue 更加容易接受新興的標准方法，但是它的類似於 Web 組件的模式，而不是真正的 Web 組件，這可能是 vue 所得不償失的地方。
發展前景：
雖然vue.js有相當廣泛的應用，但也很難預測在中期發展中這個勢頭能持續多久，它不是由一個商業組織直接支持並維護，因此，這很大程度上依賴於維護者的生存能力和繼續維護下去的願望來決定。
它也表現出了一定程度的語言適應能力，並且隨著某些模式的落伍和失寵而繼續保持自身語言的現代化和時代性，目前沒有跡象表明vue.js架構將來無法適應進一步發展。
使用場景：
如果你有一個傳統的Web應用程序，並需要一個強壯穩健的應用程序層，那麼vue.js 可能是一個很好的選擇，它有清晰的模式，即使沒有經驗的團隊也能正確或者錯誤的使用它。盡管vue UX框架沒有開箱即用的功能，但在vue.js上也能大量持續性構建應用，這將有利於你的項目。