天的早讀課,筆者將介紹Display的相關屬性,主要涉及的內容包含:
如下段代碼所示,我們有三個紅、藍、綠的方塊,如下段代碼所示:
#box-1 { width: 100px; height: 100px; background: red; } #box-2 { width: 100px; height: 100px; background: blue; } #box-3 { width: 100px; height: 100px; background: green; } div { display: inline-block; } body { background: #efefef; } <div id="box-1"></div> <div id="box-2"></div> <div id="box-3"></div>
首先我們先使用 display: none 屬性隱藏藍色的方塊,如下段代碼所示:
#box-2 { display: none; width: 100px; height: 100px; background: blue; }
如上圖所示,使用Display: None,我們可以看出藍色方塊從中“刪除”,中間的空位也被綠色的方塊補位。
接著我們使用 visibility: hidden 屬性隱藏藍色方塊,如下段代碼所示:
#box-2 { width: 100px; height: 100px; background: blue; visibility: hidden; }
從上圖我們看出,使用Visibility: Hidden,我們實現了藍色方塊的“隱藏”,中間的位置空缺保留。
Block塊級元素默認填滿父級元素內容區域,旁邊不能有其他元素,最常見的塊級元素就是<div>,<p>,<ul> 等。
Inline行內元素在一行文本內生成元素框,不打斷所在的行。最常見的行內元素比如:<span>,<img>,<a>。首先我們下段沒有CSS的Html代碼:
<body> <p>I'm a paragraph</p> <p>I'm a paragraph too</p> <span>I'm a word</span> <span>I'm a word too.</span> </body>
從上圖我們看出:
兩個<p>元素占了兩行,兩個<span>元素占了一行,由此可見每個Html元素都有個默認的display屬性:block或inline。
以下是關于 Block 和 Inline 差異的總結:
Block
如下代碼示意:
p { height: 100px; width: 100px; background: red; color: white; }
從中我們可以看出設置了元素的寬和高,每個紅色方塊會獨占一行,如下圖所示:
inline
如下段代碼所示,我們更改<p>標簽display的默認屬性,讓其成為行內元素:
p { height: 100px; width: 100px; background: red; color: white; display: inline; }
從上圖所示,我們看出,<p>元素變成了行內元素,我們設置的寬和高并不起效,三個<P>元素排成一行。
某些情況下,行內元素和塊級元素并不能滿足我們的設計需求,因此有了Inline-block這個屬性,從屬性的名字,我們就可以分析出其綜合了兩者的一些特征。
我們可以這樣理解,這個屬性是個行內屬性,可以設置width和height或者我們可以理解成一個塊級元素,不用換行。
為了理解這個屬性,我們還是從一段代碼開始,如下所示:
p { display: inline-block; height: 100px; width: 100px; background: red; color: white; }
從上面的效果圖,我們可以看出,使用此屬性后,我們讓行內元素具備了寬高屬性。
今天的早讀課就到這里,希望通過本篇文章,你明白了display的這些屬性。
更多精彩內容,請微信關注“前端達人”公眾號!
HTML 中添加 onclick 事件時,可能會遇到事件沒有反應的情況。這可能由多種原因引起,如錯誤的語法、事件綁定方式、作用域問題、元素狀態問題、跨域安全性限制、網絡連接問題等等。為解決這些問題,需要仔細檢查代碼、采取適當措施,如使用正確的事件綁定方式、檢查作用域、避免跨域安全性限制等。如果仍無法解決問題,可以尋求其他開發者或社區的幫助,并使用調試工具和控制臺來進一步分析和解決問題。使用現代的前端框架或庫也可以幫助簡化事件處理和交互邏輯,提高代碼的可維護性和可重用性。
如果您已經確認您的 HTML 代碼正確編寫,但是 onclick 事件仍然沒有任何反應,則可能有以下原因:
1、代碼錯誤:請確保您的 onclick 事件代碼正確,沒有語法錯誤或拼寫錯誤。您可以嘗試將其替換為簡單的 console.log 語句以確保事件綁定成功,并在控制臺中查看是否有輸出。
2、元素被覆蓋:如果其他元素位于您的<span>元素上方,則可能會阻止您的 onclick 事件被觸發。您可以嘗試使用 z-index 屬性將您的<span>元素置于其他元素之上。
3、CSS 問題:如果您的<span>元素被其他 CSS 樣式影響,例如 display:none; 或 visibility:hidden;,則它可能不會顯示在頁面上,并且 onclick 事件將無法被觸發。請檢查您的 CSS 樣式并確保它們不會影響您的<span>元素。
4、JavaScript 框架沖突:如果您的頁面中使用了其他 JavaScript 框架或庫,它們可能會干擾 onclick 事件的觸發。您可以嘗試使用純 JavaScript 或禁用其他框架以解決問題。
5、瀏覽器兼容性問題:某些瀏覽器可能不支持某些 JavaScript 特性或事件,這可能會導致 onclick 事件無法被觸發。您可以嘗試在不同的瀏覽器中測試您的代碼,或者使用 JavaScript 庫或框架來處理瀏覽器兼容性問題。
6、安全性問題:如果您的 onclick 事件代碼涉及到用戶輸入或數據傳輸,那么請確保您的代碼已經進行了必要的安全性檢查和過濾,以避免安全漏洞或攻擊。
7、異步加載問題:如果您的<span>元素是通過異步加載或動態添加到頁面中的,那么 onclick 事件可能無法被正確地綁定。在這種情況下,您需要使用事件委托或者在元素添加到 DOM 后再綁定 onclick 事件。
8、使用了禁用事件的 CSS 屬性:某些 CSS 屬性可能會禁用元素的默認事件處理行為。例如,使用 pointer-events: none; 將阻止鼠標事件的觸發,這也會包括 onclick 事件。因此,您需要確保您的 CSS 樣式不會禁用任何事件處理。
9、其他事件監聽器或腳本的干擾:如果您的頁面中存在其他事件監聽器或腳本,它們可能會干擾 onclick 事件的綁定或觸發。您可以嘗試在頁面上禁用其他事件監聽器或腳本來診斷問題,或者使用 JavaScript 調試工具來查看代碼的執行順序和事件觸發情況。
10、onclick 事件被其他元素覆蓋:如果您的<span>元素被其他元素完全或部分覆蓋,那么 onclick 事件可能會被覆蓋或無法觸發。您可以嘗試更改元素的位置或層次關系,或者使用 z-index 屬性將其置于其他元素之上來解決問題。
11、元素的尺寸或位置問題:如果您的<span>元素的尺寸或位置不正確,那么 onclick 事件可能會無法被正確觸發。請確保您的元素在頁面上顯示正確,并且它們具有足夠的大小和可點擊區域以便用戶能夠點擊它們。
12、原型鏈污染:如果您的頁面中存在來自第三方庫或插件的代碼,并且它們可能污染了全局作用域或 JavaScript 原型鏈,那么 onclick 事件可能會受到影響。在這種情況下,您需要確保您的代碼與其他庫或插件不會產生沖突,并且您的代碼使用了適當的命名空間和封裝技術。
13、元素狀態問題:如果您的<span>元素處于禁用狀態、只讀狀態或其他狀態,那么 onclick 事件可能會被阻止。請確保您的元素的狀態正確設置,并且您的事件處理代碼能夠正確地處理這些狀態。
14、跨域安全性限制:如果您的頁面中存在來自不同域名或協議的內容,并且它們試圖通過 onclick 事件來交互或傳遞數據,那么可能會受到瀏覽器的安全限制。在這種情況下,您需要了解并遵守瀏覽器的安全性限制,并使用跨域通信技術來傳遞數據。
15、使用了錯誤的語法或方法:如果您的 onclick 事件處理代碼中存在語法錯誤或錯誤的方法調用,那么事件可能無法正確觸發。請確保您的代碼使用正確的語法和方法,以及正確的事件綁定方式。
16、其他 JavaScript 錯誤:如果您的頁面中存在其他 JavaScript 錯誤,它們可能會影響 onclick 事件的綁定或觸發。在這種情況下,您需要檢查控制臺中是否有其他錯誤消息,并修復這些錯誤。
17、網絡連接問題:如果您的頁面中包含需要從服務器加載的資源,例如腳本文件或圖像,那么網絡連接問題可能會影響 onclick 事件的綁定或觸發。在這種情況下,您需要確保您的網絡連接正常,并且您的頁面能夠正確地加載所有需要的資源。
onclick 事件沒有反應可能會由多種原因引起,包括錯誤的語法、事件綁定方式、作用域問題、元素狀態問題、跨域安全性限制、網絡連接問題等等。您需要仔細檢查您的代碼,并采取適當的措施來解決這些問題。如果您無法解決問題,您可以尋求其他開發者或社區的幫助,并使用調試工具和控制臺來進一步分析和解決問題。使用現代的前端框架或庫可以幫助您簡化事件處理和交互邏輯,并提高代碼的可維護性和可重用性。
一篇文章我們將來學習安全防范這一塊的知識點。總的來說安全是很復雜的一個領域,不可能通過一篇文章就學習完。在這里,我們主要學習常見的一些安全問題及如何防范的內容。在當下,其實安全問題對前端開發已經越來越重要,已經逐漸成為前端開發必備的技能了。
涉及面試題:什么是 XSS 攻擊?如何防范 XSS 攻擊?什么是 CSP?
XSS 簡單點來說,就是攻擊者想盡一切辦法將可以執行的代碼注入到網頁中。
XSS 可以分為多種類型,但是總體上我認為分為兩類:持久型和非持久型。
持久型也就是攻擊的代碼被服務端寫入進數據庫中,這種攻擊危害性很大,因為如果網站訪問量很大的話,就會導致大量正常訪問頁面的用戶都受到攻擊。
舉個例子,對于評論功能來說,就得防范持久型 XSS 攻擊,因為我可以在評論中輸入以下內容
這種情況如果前后端沒有做好防御的話,這段評論就會被存儲到數據庫中,這樣每個打開該頁面的用戶都會被攻擊到。
非持久型相比于前者危害就小的多了,一般通過修改 URL 參數的方式加入攻擊代碼,誘導用戶訪問鏈接從而進行攻擊。
舉個例子,如果頁面需要從 URL 中獲取某些參數作為內容的話,不經過過濾就會導致攻擊代碼被執行
<!-- http://www.domain.com?name=<script>alert(1)</script> --> <div>{{name}}</div>
但是對于這種攻擊方式來說,如果用戶使用 Chrome 這類瀏覽器的話,瀏覽器就能自動幫助用戶防御攻擊。但是我們不能因此就不防御此類攻擊了,因為我不能確保用戶都使用了該類瀏覽器。
對于 XSS 攻擊來說,通常有兩種方式可以用來防御。
轉義字符
首先,對于用戶的輸入應該是永遠不信任的。最普遍的做法就是轉義輸入輸出的內容,對于引號、尖括號、斜杠進行轉義
function escape(str) { str=str.replace(/&/g, '&') str=str.replace(/</g, '<') str=str.replace(/>/g, '>') str=str.replace(/"/g, '&quto;') str=str.replace(/'/g, ''') str=str.replace(/`/g, '`') str=str.replace(/\//g, '/') return str }
通過轉義可以將攻擊代碼 <script>alert(1)</script> 變成
// -> <script>alert(1)</script>
escape('<script>alert(1)</script>')
但是對于顯示富文本來說,顯然不能通過上面的辦法來轉義所有字符,因為這樣會把需要的格式也過濾掉。對于這種情況,通常采用白名單過濾的辦法,當然也可以通過黑名單過濾,但是考慮到需要過濾的標簽和標簽屬性實在太多,更加推薦使用白名單的方式。
以上示例使用了 js-xss 來實現,可以看到在輸出中保留了 h1 標簽且過濾了 script 標簽。
CSP
CSP 本質上就是建立白名單,開發者明確告訴瀏覽器哪些外部資源可以加載和執行。我們只需要配置規則,如何攔截是由瀏覽器自己實現的。我們可以通過這種方式來盡量減少 XSS 攻擊。
通常可以通過兩種方式來開啟 CSP:
這里以設置 HTTP Header 來舉例
Content-Security-Policy: default-src ‘self’
Content-Security-Policy: img-src https://*
Content-Security-Policy: child-src 'none'
當然可以設置的屬性遠不止這些,你可以通過查閱 文檔 的方式來學習,這里就不過多贅述其他的屬性了。
對于這種方式來說,只要開發者配置了正確的規則,那么即使網站存在漏洞,攻擊者也不能執行它的攻擊代碼,并且 CSP 的兼容性也不錯。
涉及面試題:什么是 CSRF 攻擊?如何防范 CSRF 攻擊?
CSRF 中文名為跨站請求偽造。原理就是攻擊者構造出一個后端請求地址,誘導用戶點擊或者通過某些途徑自動發起請求。如果用戶是在登錄狀態下的話,后端就以為是用戶在操作,從而進行相應的邏輯。
舉個例子,假設網站中有一個通過 GET 請求提交用戶評論的接口,那么攻擊者就可以在釣魚網站中加入一個圖片,圖片的地址就是評論接口
<img src="http://www.domain.com/xxx?comment='attack'"/>
那么你是否會想到使用 POST 方式提交請求是不是就沒有這個問題了呢?其實并不是,使用這種方式也不是百分百安全的,攻擊者同樣可以誘導用戶進入某個頁面,在頁面中通過表單提交 POST 請求。
如何防御
防范 CSRF 攻擊可以遵循以下幾種規則:
SameSite
可以對 Cookie 設置 SameSite 屬性。該屬性表示 Cookie 不隨著跨域請求發送,可以很大程度減少 CSRF 的攻擊,但是該屬性目前并不是所有瀏覽器都兼容。
驗證 Referer
對于需要防范 CSRF 的請求,我們可以通過驗證 Referer 來判斷該請求是否為第三方網站發起的。
Token
服務器下發一個隨機 Token,每次發起請求時將 Token 攜帶上,服務器驗證 Token 是否有效。
涉及面試題:什么是點擊劫持?如何防范點擊劫持?
點擊劫持是一種視覺欺騙的攻擊手段。攻擊者將需要攻擊的網站通過 iframe 嵌套的方式嵌入自己的網頁中,并將 iframe 設置為透明,在頁面中透出一個按鈕誘導用戶點擊。
對于這種攻擊方式,推薦防御的方法有兩種。
X-FRAME-OPTIONS
X-FRAME-OPTIONS 是一個 HTTP 響應頭,在現代瀏覽器有一個很好的支持。這個 HTTP 響應頭 就是為了防御用 iframe 嵌套的點擊劫持攻擊。
該響應頭有三個值可選,分別是
JS 防御
對于某些遠古瀏覽器來說,并不能支持上面的這種方式,那我們只有通過 JS 的方式來防御點擊劫持了。
<head> <style id="click-jack"> html { display: none !important; } </style> </head> <body> <script> if (self==top) { var style=document.getElementById('click-jack') document.body.removeChild(style) } else { top.location=self.location } </script> </body>
以上代碼的作用就是當通過 iframe 的方式加載頁面時,攻擊者的網頁直接不顯示所有內容了。
涉及面試題:什么是中間人攻擊?如何防范中間人攻擊?
中間人攻擊是攻擊方同時與服務端和客戶端建立起了連接,并讓對方認為連接是安全的,但是實際上整個通信過程都被攻擊者控制了。攻擊者不僅能獲得雙方的通信信息,還能修改通信信息。
通常來說不建議使用公共的 Wi-Fi,因為很可能就會發生中間人攻擊的情況。如果你在通信的過程中涉及到了某些敏感信息,就完全暴露給攻擊方了。
當然防御中間人攻擊其實并不難,只需要增加一個安全通道來傳輸信息。HTTPS 就可以用來防御中間人攻擊,但是并不是說使用了 HTTPS 就可以高枕無憂了,因為如果你沒有完全關閉 HTTP 訪問的話,攻擊方可以通過某些方式將 HTTPS 降級為 HTTP 從而實現中間人攻擊。
以上就是我們平時開發過程中一些常見的前端安全方面的知識以及我們應該如何防御這些攻擊。但是安全的領域相當大,這些內容只是滄海一粟,如果大家對于安全有興趣的話,可以去網上多進行拓展學習,深入原理。
*請認真填寫需求信息,我們會在24小時內與您取得聯系。