者:悅然wordpress建站(悅然建站)
繼續分享wordpress建站教程。不管是再好的wordpress主題或插件,它的一些樣式都是可能存在一些我們不滿意的地方,所以我們有時候可能需要修改wordpress主題或插件CSS樣式,以達到我們想要的效果。不過當我們直接修改CSS文件就會發現它不會立即生效,甚至要很久之后才會生效,這是怎么回事呢?
因為緩存!不管是瀏覽器緩存,還是服務器緩存,甚至是CDN、對象存儲的緩存都有可能導致網站的CSS樣式不能立即更新,今天悅然建站就給大家分享解決方法。
我們修改CSS文件的常規做法是直接修改主題或插件中的CSS文件,當我們修改了本地CSS文件后,還需要清楚瀏覽器緩存,刷新CDN緩存,如果使用了對象存儲,我們還需要用本地修改過的CSS文件替換對象存儲中的CSS文件。
總的來說這種做法非常不方便,很麻煩,而且容易出錯,所以悅然建站不推薦大家使用這樣的方法。
大多數功能完善的wordpress主題都會提供額外的代碼添加功能,比如很多英文外貿wordpress主題的自定義設置中都會有一個【額外CSS】選項,點開之后就可以添加CSS代碼。
如果是國內的中文wordpress主題,有一些也提供的額外代碼添加功能,比如上圖這個,把代碼添加進來,然后使用style標簽閉合即可。
如果你使用的主題沒有添加代碼的功能,那么可以使用第三方的插件代碼,進入wordpress建站后臺,在插件中心搜索就可以找到很多,如上圖中的幾個都可以。
接下來悅然wordpress建站通過實例教大家添加額外CSS。
如上圖所示,悅然wordpress建站幾天幾才發現我的網站存在一個小問題,就是列表模塊的樣式存在BUG,太靠邊了,導致有些文字溢出了,這非常影響美觀。
接下來我們在瀏覽器在按F12查看源碼,然后找到這個列表頁的CSS樣式,通過測試悅然wordpress建站發現在原來的CSS樣式下添加【padding:revert】即可解決問題。
<style>
dl, ol, ul {
margin-top: 0;
margin-bottom: 1rem;
padding: revert;
}
</style>
最后只需要把上面的CSS代碼添加到主題的的相關設置中,如果是使用的CSS插件,或者是主題的額外CSS功能,那需要把上面的style標簽刪除,只添加中間的CSS樣式即可。
最終的效果如上圖所示。
今天的wordpress建站教程就給大家分享到這了,CSS效果對一個網站來說還是挺重要的,網站的大多數顯示效果都可以通過CSS樣式來調整,大家有時間可以多研究一下。
相信大家在工作中都遇到過這樣一些奇怪的現象:
1.為什么我寫的z-index沒有生效?
2.為什么z-index大的元素卻沒有蓋住z-index小的元素?
3.如何讓父元素蓋住子元素呢?
以上這些問題都跟CSS層疊上下文有關,OK,帶著上面這些問題我們一起來了解一下什么是CSS層疊上下文,以及這些奇怪現象背后的原理!
「如果這篇文章有幫助到你,??關注+點贊??鼓勵一下作者,文章公眾號首發,關注 前端南玖 第一時間獲取最新文章~」
?
層疊上下文是HTML元素的三維概念,這些HTML元素在一條假想的相對于面向(電腦屏幕的)視窗或者網頁的用戶的z軸上延伸,HTML元素依據其自身屬性按照優先級順序占用層疊上下文的空間。
?
在CSS2.1規范中,每個盒模型的位置是三維的,分別是平面畫布上的X軸,Y軸以及表示層疊的Z軸。一般情況下,元素在頁面上沿X軸Y軸平鋪,我們察覺不到它們在Z軸上的層疊關系。而一旦元素發生堆疊,這時就能發現某個元素可能覆蓋了另一個元素或者被另一個元素覆蓋。
我們可以這樣來理解:
了解了層疊上下文,我們還要知道層疊上下文是如何產生的。
一般來講有3種方法:
?
層疊等級(stacking level,叫“層疊級別”/“層疊水平”也行),它決定了「同一個層疊上下文中元素在z軸上的顯示順序(層疊順序)」,也就是說普通元素的層疊水平優先由層疊上下文決定。
?
?
“層疊順序”英文稱作”stacking order”. 表示元素發生層疊時候有著特定的垂直顯示順序,注意,這里跟上面兩個不一樣,上面的「層疊上下文和層疊水平是概念」,而這里的「層疊順序是規則」。
?
從上面產生層疊上下文的方法,我們可以分為CSS2.1與CSS3兩類,在CSS3出來之前,相信大家都看過下面這張圖:
看到這張圖,相信大家最有疑問的是「行內元素的層疊順序要高于塊級元素與浮動元素」。
OK,有疑問就動手實踐一遍,看看是不是真是這樣:
<style>
div {
width: 100px;
height: 100px;
border: 1px solid saddlebrown;
}
.box1 {
position: relative;
z-index: -1;
background: violet;
}
.box2 {
margin-top: -50px;
margin-left: 50px;
background: salmon;
}
.box3 {
float: left;
margin-top: -50px;
margin-left: 100px;
background: wheat;
}
.box4 {
display: inline-block;
background: greenyellow;
margin-left: -50px;
}
.box5 {
position: relative;
z-index:0;
left: 200px;
top: -50px;
background: palevioletred;
}
.box6 {
position: relative;
z-index: 1;
left: 250px;
top: -100px;
background: gold
}
</style>
</head>
<body>
<div class="box1">1定位z-index<0</div>
<div class="box2">2塊級元素</div>
<div class="box3">3浮動</div>
<div class="box4">4行內元素</div>
<div class="box5">5定位z-index=0</div>
<div class="box6">6定位z-index>0</div>
</body>
這個理解起來其實很簡單,像border/background屬于裝飾元素的屬性,浮動和塊級元素一般用來頁面布局,而內聯元素一般都是文字內容,并且網頁設計之初最重要的就是文字內容,所以在發生層疊時會優先顯示文字內容,保證其不被覆蓋。
?
z-index 屬性設定了一個定位元素及其后代元素或 flex 項目的 z-order。當元素之間重疊的時候,z-index 較大的元素會覆蓋較小的元素在上層進行顯示。
?
了解完上面這些內容,現在我們再來看一看前文提到的兩個問題
這個很簡單,因為它單獨使用時不生效,一定要配合定位屬性一起,即只對指定了position屬性的元素生效——只要不是默認值static,其他的absolute、relative、fixed都可以使z-index生效。(在CSS3之后,彈性元素的子元素也可以生效)
這里我們可以來看一個有趣的現象
<style>
.box1 {
width: 200px;
height: 100px;
background: red;
}
.box2 {
width: 100px;
height: 200px;
background: greenyellow;
}
</style>
<div style="position:relative; z-index:auto;">
<div style="position:absolute; z-index:2;" class="box1">box1--z-index=2</div>
</div>
<div style="position:relative; z-index:auto;">
<div style="position:relative; z-index:1;" class="box2">box2--z-index=1</div>
</div>
這么看還挺正常的,z-index值大的在z-index值小的上方。接下來我們稍微改一改,你就能看到奇怪的現象了
<div style="position:relative; z-index:0;">
<div style="position:absolute; z-index:2;" class="box1">box1--z-index=2</div>
</div>
<div style="position:relative; z-index:0;">
<div style="position:relative; z-index:1;" class="box2">box2--z-index=1</div>
</div>
這里我們只是把它們父元素的z-index屬性從auto改成了0,兩種情況的表現卻截然相反。
產生這種現象的原因我們也能夠從上面的理論中找到答案:**position屬性為「非」static值并設置z-index屬性為具體數值才能產生層疊上下文**
當z-index為auto時,是一個普通元素,兩個box層比較不受父級的影響,按照規則誰大誰上,于是z-index為2的box覆蓋值為1的box; 當z-index為0時,會創建一個層疊上下文,此時的層疊規則就發生了變化。層疊上下文特性里最后一條規則,每個層疊上下文都是獨立的。兩個box的層疊順序比較變成了優先比較其父級層疊上下文元素的層疊順序。由于兩者z-index都是0,所以,遵循層疊規則后來居上,根據在DOM出現的先后順序決定誰在上面,于是,位于后面的box2覆蓋box1。此時box元素上的z-index是沒有任何意義的。
這里很多人是不是認為直接讓父元素的z-index大于子元素的z-index不就好了,可事實真是如此嗎?
<style>
.outer {
position: relative;
width: 100px;
height: 200px;
background: salmon;
z-index: 3;
}
.inner {
position: relative;
width: 50px;
height: 200px;
background: cadetblue;
z-index: 1;
}
</style>
<div class="outer">
父元素
<div class="inner">子元素</div>
</div>
有人是不是又有疑惑了?
我們這樣來理解,父元素定位+z-index為數值,所以它產生了一個層疊上下文,此時子元素無論怎么設置z-index都不可能在父元素的下方。唯一可以實現的方法是將子元素的z-index設為負值,而父元素只要不產生層疊上下文就可以了。
<style>
.outer {
position: relative;
width: 100px;
height: 200px;
background: salmon;
/**z-index: 3;**/
}
.inner {
position: relative;
width: 50px;
height: 200px;
background: cadetblue;
z-index: -1;
}
</style>
<div class="outer">
父元素
<div class="inner">子元素</div>
</div>
「其余規則看上面層疊順序的圖即可。」
述 | 楊曉兵
編輯 | 伍杏玲
出品 | CSDN(ID:CSDNnews)
編者前記:
編譯器是連接人類世界與機器世界之間的一座橋梁,它可將程序員理解的高級語言,轉換成程序高效執行的機器碼。在 C/C++ 編譯器里,有 VC、Borland C++、GCC、Watcom C/C++ 等國外熱門編譯器,但屬于國內自主研發的編譯器較少。
畢竟開發一款實用的編譯器不易,涉及前端詞法、語法分析、語意分析、大量的編譯優化等工作。而有一支團隊,不惜花費十余年精力完全自主研發出一款 YC 編譯器和 YC 瀏覽器內核。
為何他們不遺余力地自主研發編譯器和瀏覽器內核?這款編譯器有何優點呢?下面由 YC 編譯器的主要作者之一——楊曉兵,來講述這背后十多年來的漫漫研發路。
以下為楊曉兵自述:
初衷:“做一些對軟件行業進步有幫助的東西”
十多年前,我在中國科學院電子學研究所工作,參與設計一些硬件電路。當時我對硬件的興趣遠超軟件,后創業專門從事軟件工作。
我在創業的過程中發現,做此類軟件雖能賺錢,但無論做得怎樣,對軟件科學的進步都無絲毫作用。盡管付出很多,卻無成就感。
操作系統、數據庫、編譯器以及瀏覽器內核是不需要特殊專業知識的、開發難度非常大、最基礎的軟件產品。
我想從這幾種軟件中選擇其中一項來自主研發,雖然不能肯定做出什么成就,但我有希望能做出一些對軟件行業進步有所幫助的東西,使自己不枉踏入軟件這個行業。根據當時的情況,我發現可先從瀏覽器內核下手,于是我除了維護原有產品外,把主要精力都投入到瀏覽器的研發中。
創新將 C 代碼內嵌到 HTML
兩年后,我們研發完成瀏覽器內核的基本功能,如 HTML 的解析和顯示、JavaScript 腳本的執行等。
此時,我們發現 HTML 的標準越來越復雜,導致開發難度越來越大,如果按照這樣的發展,瀏覽器內核將無法走入市場。
于是我重新思考:如果把 C 語言處理成像 JavaScript 腳本嵌入到 HTML 中,用內嵌 C 代碼的 HTML 超文本做軟件的人機交互界面,這款內核應該會有點競爭優勢。
于是我們花費兩年半的時間將標準 C 語言以 JavaScript 相似的方式在 HTML 中執行,并擴展了一個 HTML 標簽:<user>,每個 user 標簽都可以用屬性 src 指定一個 C 源碼文件,user標簽的顯示界面和所有行為都由它的 C 代碼決定。
同時將 C 編譯器做成一個函數,用該函數編譯生成 C 程序的可執行代碼,執行代碼可被存入文件或直接執行。此時,我們將編譯器取名為 YC 編譯器,瀏覽器內核取名為 YC 瀏覽器。
三年又三年,漫漫研發路
隨后,我們繼續完善瀏覽器內核,將其中的一些內核代碼獨立出來用內嵌編譯器動態編譯執行,并將大部分內核源代碼開源。
與此同時,我們又遇到一個問題:YC 編譯器雖然編譯速度較快,生成的卻是字節碼,執行速度慢,而且與原生代碼相互調用(特別是回調函數)的處理相當繁瑣。因此用當時的 YC 編譯器難以勝任開源代碼的編譯工作。
為了解決自編譯瀏覽器內核代碼的問題,我們決定修改 YC 編譯器,使它的字節碼轉換為原生的執行碼,并擴展語法,使之具有少量的 C++ 語法。這個工作持續了三年。
三年后,YC 編譯器功能增多,它提供一個函數像調用動態鏈接庫一樣直接調用 C 源碼中的函數。此時,瀏覽器內核開源部分都可以用 YC 編譯器實時編譯執行了。
我們繼續改進瀏覽器內核,將速度很慢的 JavaScript 字節碼改為二進制原生代碼,使 JavaScript 的執行速度約提高約 100 多倍。同時將瀏覽器內核代碼全部模塊化并開源,每個模塊都用 YC 編譯器動態編譯執行,編譯器的部分源碼也開源(如內嵌匯編編譯器源碼、反匯編源碼、C/C++ 字節碼的執行源碼等),所有的開源代碼均由內嵌的 YC 編譯器自動檢測編譯,動態執行。這個工作大概耗時四年。
開發至此,我想起谷歌和火狐瀏覽器都已開源,為什么不去看看它們的源代碼呢?于是找到這兩個瀏覽器的源碼。
當時由于一些原因,我分析谷歌瀏覽器源碼沒有編譯通過,而火狐的源碼很順利就編譯成功了,于是我就走上了分析火狐源碼之路。
下載的火狐源碼由純 C 代碼和 C++ 代碼兩部分組成,經 Visual C++ 2013 編譯生成一個 xul.dll 文件和一個 firefox.exe 文件。
我首先分析了它的 C 代碼,將所有的輸出函數全部改為類接口,并讓 xul.dll 通過 YC 編譯器函數 YC_cppLoad 進行實時編譯,然后用類接口調用 C 源碼中的函數。這一步進行得很順利,若修改了火狐的 C 代碼,只要重新運行火狐瀏覽器便可生效,無需其它操作。
曾經的辦公桌
接下來開始分析火狐 C++ 代碼。YC 編譯器只實現了少數幾個 C++ 語法,不能編譯火狐 C++ 代碼,故分析起來非常困難。
為什么火狐 C 代碼容易分析,而它的 C++ 代碼難以分析呢?原來我用 YC 編譯器將它的 C 代碼生成匯編代碼文件、變量結構定義文件、宏定義文件和預編譯文件,通過這幾個文件,大大減少了分析難度。
因此我再次決定修改 YC 編譯器,使之完全支持 C++11 標準,因為火狐 C++ 代碼幾乎使用了所有的 C++11 語法特性。先使用 STL 標準模板庫代碼進行編譯器的修改和調試,出乎預料,這個過程竟用了三年時間!之后,我用 YC++ 編譯器開始調試火狐 C++ 代碼。原以為 STL 那么復雜的代碼都可以編譯通過并正確執行,火狐 C++ 代碼應該能很快就編譯通過。沒想到,很多語法細節 STL 沒有用到,而火狐 C++ 源碼用到了。于是又繼續修改 YC 編譯器,對火狐 C++ 的各個模塊進行編譯,這個過程持續了一年多。
雖然 YC 編譯器可以編譯全部火狐 C++ 代碼,但如何生成執行代碼呢?先從主程序 Firefox.cpp 入手,經整理,這個程序可用 YC 編譯器生成執行代碼 Firefox.exe,并能順利運行。
由于火狐 C++ 各模塊耦合緊密,很難拆分,經過一個多月的工作,仍未能將其拆成多個獨立的源碼模塊以便于用 YC 編譯器實時編譯,動態執行,這也許是我對火狐 C++ 源碼的整體結構還不甚清楚之故,只見其樹木不見其森林。
楊曉兵
當我準備對火狐 C++ 代碼進行再一次總體分析時,有個偶然的機會參與到一個學校管理系統的開發中,因原有的管理系統經常出故障,操作極其不方便。盡管沒有開發 Web 服務程序的經歷,但我做的軟件與 Web 服務器有極大關系。
經了解,要開發這種管理系統需要的軟件有:Apache 或 Nginx 服務器,數據庫 MySQL 或其它,編程工具 ASP 或 JSP 或 PHP 等,于是啟發我們自己研發這些工具。YC 的 C/C++ 和 JavaScript 編譯器和 HTML 解析器正好派上用場。
經過一段時間,一個穩定的、可任意擴展的、多線程高并發的 HTTP 服務器就完成了。該服務器處理 YSP 文件生成網頁傳給瀏覽器。
YSP 是我設計的與 ASP、JSP 和 PHP 功能相似的一種網頁編程語言。YC 服務器執行 YSP 文件中的內嵌 C/C++ 或 JavaScript 代碼,生成 HTML 超文本傳給終端設備。工具做好后,不久便做出了管理系統的雛形,這個雛形在發布的 YC 編譯器中可見到。
做了上述這些工作后,我想是時候該寫本書介紹一下 YC 編譯器了,經過一段時間編寫的《YC編譯器—多語言程序設計》(暫名)即將出版。
當我把書完成后,便立即投入64位的C/C++和JavaScript編譯器的開發,目前開發進展順利,已進入測試階段。
編者后記:
三年時間,可將一個呱呱落地的嬰兒變成蹦蹦跳跳的幼兒,可將一名懵懂的職場新人變成沉穩的老兵。而楊曉兵團隊沉下心,迎難而上,花費三年又三年、再一年、兩年、四年的時間只為突破一個個技術難點,最終自研出 YC 編譯器和 YC 瀏覽器內核。
在這過程中,楊曉兵坦言最大的挑戰不僅是技術,還有思維的高度。這期間不僅有大量的研發工作,還為了優化,多次重寫代碼,讓他堅持下來的是想為計算機軟件科學的發展做貢獻的匠心。
目前楊曉兵團隊正在開發 64 位 C/C++ 編譯器,談及未來,楊曉兵表示先在國內推廣,再走向海外。祝福楊曉兵。
YC編譯器傳送門:http://www.ycbro.com
*請認真填寫需求信息,我們會在24小時內與您取得聯系。