在 parent 為 flex 的情況下,裡面放了許多圖片(img),當視窗寬度小於這些圖片時,子層的圖片高度不會因為你下了 height:auto 而改變,造成圖片被拉長。 為什麼圖片會被拉長? 因為 safari 預設的 flex 狀態和別人不太一樣,它的預設狀況為 stretch。 因此,parent 再加上 align-items:flex-start 就能解決這個只有 safari 版型會出狀況問題。 .d-flex{ display:flex; flex-wrap:wrap; } img{ width:25%; height:auto; } <div class="d-flex"> <img width="200" height="200" src="" alt=""> <img width="200" height="200" src="" alt=""> <img width="200" height="200" src="" alt=""> <img width="200" height="200" src="" alt=""> <img width="200" height="200" src="" alt=""> <img width="200" height="200" src="" alt=""> <img width="200" height="200" src="" alt=""> <img width=...
發表文章
- 取得連結
- X
- 以電子郵件傳送
- 其他應用程式
作者:
cjzopen
-
此功能新增在「Rendering」的最下面,可以模擬的模式有: ✨Blurred vision。 ✨Protanopia:無法感知任何紅光。 ✨Deuteranopia:無法感知任何綠光。 ✨Tritanopia:無法感知任何藍光。 ✨Achromatopsia:除了灰色陰影之外,無法感知任何顏色。 另外,他們也把「Audits」頁籤改名為「Lighthouse」,因為有太多人找不到 Lighthouse 在哪裡了 LMAO。 而表單元素外觀的更新……立意良善,基本上設計師依舊會設計自己想到的樣式。 提外話,Edge 的 DevTool 介面則有中文版本,且連更新訊息也是中文的👍。 Edge 的 DevTool 更新後的 bug svg favicon 裡面的 prefers-color-scheme 語法失效,造成瀏覽器上面的頁籤讀不到其中的語法。(同年 6月20日 chrome 已修正這項錯誤) <link rel="icon" href="/favicon.svg" type="image/svg+xml"> <!-- the svg file --> <svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" width="64" height="64" viewBox="0 0 64 64" enable-background="new 0 0 64 64" xml:space="preserve"> <style> path{fill:#2858aa;} @media (prefers-color-scheme: dark) {path{fill: #23A6DE;}} </style> <path d="M35.241,20.173c2.321-0...
- 取得連結
- X
- 以電子郵件傳送
- 其他應用程式
作者:
cjzopen
-
Core Web Vitals(CWVs;網站使用體驗核心指標) Google 發表新的網站品質評估指標 Core Web Vitals ,目的是提供具有代表且一致性的網站品質數據,這些指標分別為:LCP、FID、CLS 與2022年新增的 INP。但在2024年,FID將正式被INP取代。 因為評估網頁速度體驗的方法百百種,而且很難把 UX 數據量化,而因為 CWVs 會成為 Google 搜尋排名 SEO 的因素之一,一些網頁檢測工具勢必會跟上這次提出的標準。 指標的檢測標準。圖片來自 blog.chromium.org 什麼是 LCP? LCP是最大內容繪製元素(Largest Contentful Paint),視窗可見範圍內最大內容元素的渲染時間。根據 LCP API 考慮的元素類型有: img 元素 在 svg 裡面的 image 元素 有 poster image 的 video 元素 使用 CSS url() 載入圖片的元素 包含文字節點的 Block-level 元素 什麼是 CLS? CLS是累計版面配置位移(Cumulative Layout Shift),可以想成頁面載入時的穩定度。CLS 會測量在頁面整個生命週期中發生的每個意外排版位移(layout shift),並將所有單獨排版位移的分數加總,分數在0到1之間。比如使用者才剛閱讀完一句話,突然上面跑出廣告把剛才閱讀的文字往下擠,或是想點擊取消按鈕,卻在下一秒位移按到確定,造成非常糟糕的使用體驗,都會讓分數增加。 什麼是 FID? FID是首次輸入延遲(First Input Delay),用戶首次與頁面互動(點擊連結、輸入欄、下拉選單、按鈕或 JavaScript 驅動的元件)到瀏覽器能夠回應該互動的時間。而當量測工具無法測量 FID 時,可以換成評估與 FID 關係密切的 總阻塞時間(TBT) 指標,因此優化 TBT 也可直接提高 FID 的品質。 但在 INP 出現之後,基本上就被其取代了,Google也宣布將在20...
- 取得連結
- X
- 以電子郵件傳送
- 其他應用程式
作者:
cjzopen
-
什麼是 emoji? emoji 為日文 絵文字 えもじ 的發音,存在很久了,近年因 SNS (社群網路)和聊天軟體的發達,出現頻率越來越高,再加上各家瀏覽器的支援,讓 email 和網頁也能很簡單地加上 emoji 與使用者互動,但必需注意 emoji 在每個瀏覽器的外觀皆不大相同。 而另一個「顔文字」屬於字元表情,例如 ( ͡° ͜ʖ ͡°),雖然也有相同的效果,但不在這次的討論範圍內。 emoji 查詢網站: https://getemoji.com/ 以前的 emoji 在 SERP 原本的 SERP 是除非使用者在搜尋欄加上 emoji,才會出現網頁中的 emoji,要不然它會自動把其過濾掉;也因為如此,就算加上 emoji,Google bot 也是直接跳過,不會錯判其語意。 現況的改變,其好處在哪裡? 以這個頁面來說,網頁原始碼的 title 中存在 😆 ,搜尋結果並不會將它過濾掉。不確定它是不是 Google 暫時性的測試( 事後證明為測試,現在已不包含, )。 這是吸引更多使用者視線的方法之一, 但現在必需要在使用者搜尋時,關鍵字包含 emoji 才會顯示在 SERP 中(不只圖案,「emoji」這個字也可以)。 而 emoji 對 SEO 有任何影響嗎?答案是沒有任何影響。
- 取得連結
- X
- 以電子郵件傳送
- 其他應用程式
作者:
cjzopen
-
chrome80, firefox75……以上,基本上各大知名的瀏覽器都可以支援。而雖然說是 3 種語法,但其實 clamp 可以被其它兩者取代。 Sass / SCSS 它的開發環境目前還不支援(2020-06),所以若要用 Sass / SCSS 開發的話目前可以寫成: font-size: m#{i}n(m#{a}x(9vw,2.5rem),5rem); For Exmaple 這些語法可以用在 width、 font-size 、甚至是 grid 的 repeat()……等等的地方,例如: .example{ font-size:16px; /* if not support */ font-size: clamp(min, default, max); font-size: max(default, min); width: min(99.2px * 10, 100%); left: min(30%, calc(100% - 220px)); font-size: max(value1, value2, min); /* value1 and value2 are different unit. */ /* clamp() is not a necessity */ font-size: max(min(0.5vw, 0.5em), 1rem); } English bold 中文粗體 See the Pen CSS clamp()、max()、min() by cj ( @cjzopen ) on CodePen .
- 取得連結
- X
- 以電子郵件傳送
- 其他應用程式
作者:
cjzopen
-
精選摘要的力量 網頁若佔據精選摘要的話,過去有「比排名第1名還多更多曝光與點擊機會的第0名」之稱,顯見它的利益有多大。 如何讓網頁成為精選摘要? Google 並沒有提供這種功能。依照官方的說法,他們會根據使用者的搜尋要求來判斷網頁是否適合呈現為精選摘要。但可以從一些方法著手,讓自己的網頁稍微容易出現。 影片或歌詞 只要搜尋歌名就常常可以看見的精選摘要類型。 條列項次 有時使用者在查什麼情況下會發生什麼事,或者做某件事的步驟時,精選摘要就會出現副標和條列項次。 「是」的力量 一段話是精選摘要最常出現的格式,有時候還會包含一張圖片。簡短、明確、有力的一段話非常重要,且最好接在 h1 之後。 這段話常常有明確的答案,所以用字就很重要,例如「是」、「可」之類的用詞就非常明確有力,另外最好放在同一個 <p> 之中。 不超過三欄的表格(並非精選摘要) 有時使用想查詢例如產品規格的比較或是產品效益,精選摘要就會出現這種表格。但要注意 table 不要超過三欄,且盡量不要有表頭(thead),至少我沒看過很多欄位的精選摘要。 當然還有其它不常見的類型,例如直接顯示解答(不會顯示網頁)的類型,或是很像一段話的 段落排名 類型。 精選摘要的改變 以前不止出現在第0名,還常常重覆出現於第1名或第2名的位置,但這在 2020 年初的時候就改掉了,也跟 Google 的「同網站通常最多出現2次」的政策呼應。但這很明顯影響原本的覆蓋率,勢必對點擊率有重大衝擊。 另外,它也從原本的第0名變成「真正的第1名」,把第 10 名的網頁擠到第 2 頁。 精選摘要的隱憂 網頁成為精選摘要其實不見得完全是一件好事,為何那麼說?因為原本的知識圖譜與精選摘要就有出現 0 點擊搜尋的現象,使用者可能會看到自己想要的答案就離開了,連網頁連結都不會點,這對於要銷售產品或曝光廣告的網站來說,確實不是什麼好事。 所以,精選摘要也要看情況去追求,而不是盲目地覺得變成精選摘要的自己很厲害……是很厲害沒錯,畢竟獲得 Google AI 的認可,但好處其實見仁見智。 相關連結: Google 精選摘要的運作方式 精選摘要和您的網站
- 取得連結
- X
- 以電子郵件傳送
- 其他應用程式
作者:
cjzopen
-
回顧2019並望向2020 如同以前講的,Google這幾年一直想要讓「標籤」的SEO比重降低,並提到meta description與 H1~H6 對於網站排名影響微乎其微,這篇 文章 雖然說很重要,但提到是對吸引眼球與 UX 重要。 還是不相信?有人直接 問John Mueller ,也說塞關鍵字在H1~H6並不會幫助你的排名。 另外需注意 文章 7、8、9點,要做出區別或合併,不然只會互相攻擊SEO權重。另外補充,Google喜歡原創內容大家都知道,但比較少人注意圖片本身也是內容(原創>圖庫)。至於文章沒提的BERT,除了需注意文字的文法與流暢度,其它網路文章提到的優化BERT都不用太認真看待。 而文章需要什麼訊息?E-A-T要的是什麼? 可以從 Google列舉的結構化資料 查看,它旁邊列有多種類別,如果有看的話就能有走火入魔(?)的內容分類與強化方向。 或者可以看這篇 文章 寫的說明和範例。但切記,任何SEO優化都不要過度,沒讓網站排名提升,反而讓自己真的走火入魔,畢竟SEO最大宗仍然是內容。 其它補充 網路上一篇 2019 成長駭客年會的筆記 JavaScript 檢測圖片主色的方法 How conversational searches change your search strategy 搜尋從特定名詞變成 should I...,can I之類的搜尋,人們變得更想知道別人的推薦和產品比較,或如何解決問題。可以看 此文章 的整理。
- 取得連結
- X
- 以電子郵件傳送
- 其他應用程式
作者:
cjzopen
-
之前在寫JavaScript的時候,不知為何很奇耙地搞出一個怪異的選取目標,並偶然發現它會因點擊目標父層的層數而觸發相對應的次數。 $(document).on('click',':not(#nav *)',function(e){ console.log('trigger'); }); 為了把這問題解決用很多種方法嘗試,結果只要多一行就解決了… $(document).on('click',':not(#nav *)',function(e){ if (e.target !== this) return; console.log('trigger'); }); click 和 touchend 一起用 另外一個寫不好的情況是 click 和 touch 事件一起用,造成兩個事件一起觸發。 $(document).on('click touchend','.toggle-button',function(e){ e.preventDefault(); $('#element').toggleClass('--active'); }); 解決的方法是增加一個 flag: var triggerFlag = false; var triggerThreshold = 200; $(document).on('click touchend','.toggle-button',function(e){ e.preventDefault(); if (!triggerFlag) { triggerFlag = true; setTimeout(()=>{ triggerFlag = false; }, triggerThreshold); $('#element').toggleClass('--active'); } }); 類似的頻繁觸發 另外在 scroll 和 resize 時,常常會因為頻繁觸發而導致效能爆...
- 取得連結
- X
- 以電子郵件傳送
- 其他應用程式
作者:
cjzopen
-
行動裝置預設阻擋 icon font 勢必會成為趨勢,除非你也有處理未載入時的畫面呈現,或有沒有icon對使用者的 UX 都沒有影響(這裡要捫心自問,既然有沒有 icon 都可以,為何還要放icon),否則只會有更多 browser 跟進如 firefox focus 這樣的瀏覽器或套件出現,就跟使用者主動安裝 adblock 是相同的道理。 直接說結論:直接用 SVG 好於用 JS 產生 SVG,而 JS 產生 SVG 又好於載入字體檔的 CSS。 Font Awesome 的升級 若你是使用 Font Awesome 且沒有時間處理這個問題,官方剛好有出一個快速解套的解決方案,讓開發者無痛從 4 升級到 5: Upgrading from Version 4 。 但這必需多載入 v4-shims.css 和 v4-shims.js ,對使用者而言就是多兩個 request,所以有時間的話,還是全面改寫成正常的第5版會比較好,也就是不需要用CSS載入字體檔,只有JavaScript的版本(用JS產生SVG)。 就算第4版現在大部分的情況都能正常顯示,但由於 CSS 檔案肥大(因為包含字體檔),加上沒有 font-display: swap; 的語法,通常都會拖慢載入速度。所以,放棄需要載入字體檔的icon,投入 svg 的懷抱吧! 造成排版位移 網站若有使用其它字體 (例如 Google font) 的人都知道,就算有 font-display:swap 解決載入前後文字閃爍的情況,還是無法解決載入前後字體位移的問題,因為每種字體的大小與定位都有些微的不同。這個影響雖然不大,Google 強調的 CLS 看似也不把它當作問題,但這個問題確實存在。 還能更好 而前面提到直接貼<svg>的方式,難道第5版還不夠好嗎? 在 chrome 的 Lightinghouse 測試中,有無載入第5版的 Font Awesome 速度分數最多可以差到20分,Time to Interactive (TTI)更可以相差到 8 秒之多,若又選用有載入字體的CSS,分數又會差更多。所以才又提了直接放<svg>的方法,既少了一個 request,又不用載入 Font Awesome,TTI 也從 12 秒降到 4 秒,但開發上會麻煩很多。...
- 取得連結
- X
- 以電子郵件傳送
- 其他應用程式
作者:
cjzopen
-
在 IE 和 Edge 中使用 display:flex 的情況下, background-clip ( -webkit- background-clip ):text 不會有作用。 拿掉 flexbox 就又能正常顯示… 如下面 codepen 中的範例: See the Pen background-clip by cj ( @cjzopen ) on CodePen . html,body{ margin:0; padding:0; } div{ background-image:url(https://picsum.photos/1920/600/?random); background-size:cover; height:100vh; /*if display flex, background-clip will not working in ie and edge17 */ /*display:flex;*/ /*justify-content:center;*/ /*align-items:center;*/ /* fixed */ line-height:100vh; text-align: center; font-size:15vw; font-weight:700; background-clip: text; -webkit-background-clip: text; color: rgba(0,0,0,.2); position:relative; /* mix-blend-mode: difference; */ } div::after{ content:''; position:absolute; z-index:-1; left:0; top:0; width:100%; height:100%; background-size:cover; /*style1*/ /* Not all images are suitable for this gradient. You can change it. */ background-image:linea...
- 取得連結
- X
- 以電子郵件傳送
- 其他應用程式
作者:
cjzopen
-
Meta Description (網頁描述) Meta Description 為搜尋結果中,網站標題下方的敘述說明,能讓使用者初步瞭解你的網站大概擁有什麼內容,這應該大家都知道。而如果你有在經營 Facebook 粉絲團的話,「品牌故事」就會是你的 Meta Description。 提外話,請不要把你的產品命名為 AirJordanShoe ,這樣使用者在搜尋 air、jordan、shoe 這三個任一關鍵字時, AirJordanShoe 並不會被搜尋結果 match。 濫用 常常在工作中被要求,或是偷看別人家網站原始碼時會遇到,把網頁描述當 Meta Keywords 使用,或是混在一起用 (這裡就不提把 一整群 keywords 塞在 title 的網頁了),大哥別鬧啦,小學生都會造句了,寫一段包含某些字的話很難嗎? 別忘了 網頁描述的功能:「 讓使用者初步瞭解你的網站大概擁有什麼內容 」。你能想像使用者看你的網頁描述是一堆沒有組織的單詞會做何感想嗎? 濫填關鍵字說明 誤導、欺騙 這點其實很少,大多是農場網站,其實短網址的詐騙更嚴重。 網頁描述的未來 所以 Meta Description 到底會不會步入 Meta Keywords 的後塵,在未來的某一天被google視為垃圾訊息?我們從兩點google對於網頁描述的政策來看吧。 自動產生 google對於沒有設定 或他們認為不好的 網頁描述之網頁,有可能會從網站內容中 截取後取代原本的網頁描述。 加長搜尋結果頁的網頁描述 從160字元增加到320字元,中文字的話一個字佔2~4個字元。 很顯然,因為網頁描述對 UX 來說太重要了,若將它視為垃圾訊息只會打google自己的臉。但也因為如此,對於網頁描述的評審機制將會越來越完善,說不定加到320字元只是截取技術改善前的暫時性措施,所以濫用關鍵字的網站在未來是不會得到好處的。 在之後不久,推論得到證實,Google馬上又改回160字元。 ----------------------------------------- 追記 而在2019年,google不斷強調Meta Description與網站排名並無直接關聯,只會影響「點擊意願」。換句話說,要先...
