記錄--超長溢出頭部省略打點,坑這麼大,技巧這麼多?

来源:https://www.cnblogs.com/smileZAZ/archive/2023/05/25/17432677.html
-Advertisement-
Play Games

這裡給大家分享我在網上總結出來的一些知識,希望對大家有所幫助 在業務中,有這麼一種場景,表格下的某一列 ID 值,文本超長了,正常而言會是這樣: 通常,這種情況都需要超長省略溢出打點,那麼,就會變成這樣: 但是,這種展示有個缺點,3 個 ID 看上去就完全一致了,因此,PM 希望能夠實現頭部省略打點 ...


這裡給大家分享我在網上總結出來的一些知識,希望對大家有所幫助

在業務中,有這麼一種場景,表格下的某一列 ID 值,文本超長了,正常而言會是這樣:

 通常,這種情況都需要超長省略溢出打點,那麼,就會變成這樣:

 但是,這種展示有個缺點,3 個 ID 看上去就完全一致了,因此,PM 希望能夠實現頭部省略打點,尾部完全展示,那麼,最終希望的效果就會是這樣的:

 

OK,很有意思的一個需求,最開始我以為只是實現一個頭部超長溢出打點功能,但是隨著實踐,發現事情並沒有那麼簡單,下麵我們就一探究竟。

利用 direction 實現頭部超長溢出打點

正常而言,我們的單行超長溢出打點,都是實現在尾部的,代碼也非常簡單,像是這樣:

<p>Make CSS Ellipsis Beginning of String</p>
p {
    overflow: hidden;
    text-overflow: ellipsis;
    white-space: nowrap;
}

 這裡,我們可以通過 direction,將省略打點的位置,從尾部移動至頭部:

p {
    direction: rtl;
}

結果如下:

 

簡單介紹一下 direction

  • direction:CSS 中的 direction 用於設置文本排列的方向。 rtl 表示從右到左 (類似希伯來語或阿拉伯語), ltr 表示從左到右。

另外兩個與排版相關的屬性還有:

  • writing-mode:定義了文本水平或垂直排布以及在塊級元素中文本的行進方向。
  • unicode-bidi:它與 direction 非常類似,兩個會經常一起出現。在現代電腦應用中,最常用來處理雙向文字的演算法是Unicode 雙向演算法。而 unicode-bidi 這個屬性是用來重寫這個演算法的。

OK,那麼上述需求,是不是簡單的添加一個 direction: rtl 就能解決問題呢?我們嘗試一下。

direction: rtl 會導致使用下劃線 _ 連接的數字內容排版錯誤

我們給上述的代碼,添加一個簡單的結構:

<div>
    13993199751_18037893546_4477657
</div>
<div>
    13993199751_18037893546_4477656
</div>
<div>
    13993199751_18037893546_4477655
</div>
div {
    width: 180px;
    overflow: hidden;
    text-overflow: ellipsis;
    direction: rtl;
    white-space: nowrap;
}
效果如下:

~成功了!~看似好像成功了,但是出了一點小問題!

雖然實現了頭部打點,但是我們的數字結尾好像不是我們想要的結果,仔細看一下數字的結尾情況:

這是什麼情況呢?

這是由於 direction 在處理純數字、非純數字文本上的規則不一致,我們再來看這麼一段測試代碼:

<div>
    11111_22222_33333_44444
</div>
<div>
    11111 22222 33333 44444
</div>
<div>
    aaaaa bbbbb ccccc dddddd eeeeee
</div>
<div>
    aaaaa_11111_22222_33333_44444
</div>

CSS 層面不考慮溢出情況,僅作用 direction: rtl 。

div {
    width: 240px;
    direction: rtl;
}

在修改書寫方向後,效果如下:

可以看到,這裡非常核心的一點在於,對於純數字的文本內容,數字的排列順序也會跟著相應的書寫順序,進行反向排列

而形如 11111_22222_33333_44444 這種用下劃線連接的文本,處理的方式也會與 11111 22222 33333 44444 一樣,實現了從左往右的排列,改變了原有的順序。

多方案解決

因為我們的 ID是由純數字加下劃線組成,所以無法繞開這種展示。

那麼,基於這個現狀,我們可以如何去解決這個問題呢?

方案一:兩次 direction 反轉

方法一,既然最終展示的文案被反轉了,那麼我們可以嘗試通過多一層的嵌套,進行二次反轉可以解決問題。

代碼如下:

<div class="g-twice-reverse">
    <span>13993199751_18037893546_4477657</span>
</div>
.g-twice-reverse {
    overflow: hidden;
    text-overflow: ellipsis;
    direction: rtl;
    white-space: nowrap;
    
    span {
       direction: ltr; 
    };
}

嘗試後的結果如下:

可以看到,內容還是被反轉了,我們希望的結果是 ...037893546_4477657。不過不用著急,可以嘗試再配合 unicode-bidi 屬性試一下。最終發現,配合 unicode-bidi: bidi-override 可以實現我們想要的最終效果:
.g-twice-reverse {
    overflow: hidden;
    text-overflow: ellipsis;
    direction: rtl;
    white-space: nowrap;
    
    span {
       direction: ltr; 
       unicode-bidi: bidi-override;
    };
}

最終結果如下:

完美!這裡,我們利用了兩層結構:

  1. 外層的 g-twice-reverse 正常設置從右向左的溢出省略打點
  2. 內容添加一層 span,利用 direction: ltrunicode-bidi: bidi-override 的配合,在內部再反向反轉排版規則。

當然,這裡需要解釋一下 unicode-bidi

bidi-override 的作用是對文本進行覆蓋,使得其中的內聯元素(inline element)按照我們想要的書寫方向展示。而 unicode-bidi: bidi-override 取值的作用是用於覆蓋預設的 Unicode 雙向演算法以控制文本的顯示方向。

這裡,bidi-overridedirection<span> 中的組合,實現了更細粒度的文本方向處理。

方案二:通過偽元素破壞其純數字的性質

上述的方案需要完全理解其思路還是有比較高的成本的,比較燒腦。

有沒有更好理解的方案呢?我們繼續嘗試。

既然上面被反轉排版的內容是純數字或者由下劃線連接成的數字,那麼我們能不能嘗試破壞其純數字的特性

譬如,給數組的頭部添加一個看不見字母,嘗試一下,這裡構造兩組數據對比一下:

<div class="g-add-letter">
    <span>a</span>
    <span>546_4477657</span>
</div>
<div class="g-add-letter">
    <span>a</span>
    <span>13993199751_18037893546_4477657</span>
</div>
.g-twice-reverse {
    overflow: hidden;
    text-overflow: ellipsis;
    direction: rtl;
    white-space: nowrap;
}

看看效果:

 嘿,別說,這個方案看上去真的可行。只是添加一個 <span>a</span> 肯定是不合適的,後面維護的同學肯定一臉懵逼。並且這個 a 字母需要隱藏起來。思來想去,這不是和以前清除浮動的場景非常類似嗎?這裡使用偽元素再貼切不過,我們再改造下代碼:

<div class="g-add-letter">
    <span>546_4477657</span>
</div>
<div class="g-add-letter">
    <span>13993199751_18037893546_4477657</span>
</div>
.g-add-letter {
    overflow: hidden;
    text-overflow: ellipsis;
    direction: rtl;
    white-space: nowrap;
    
    span::before {
      content: "a";
      opacity: 0;
      font-size: 0;
    }
}

我們通過偽元素,使用在元素前面添加了一個字母 a,並且設置偽元素的 font-size: 0 和 opacity: 0,從外觀上,完全看不出有這麼個元素,非常好的隱藏了起來,同時,起到了破壞內容其純數字的性質。

效果如下:

方案三:通過 \200e LRM 標記位

我們繼續優化我們的方案。

上面通過偽元素的方式,已經能夠實現在對業務結構影響最小化及代碼增量較少的前提下,實現想要的結果。

問題還是在於插入的這個字母 a,一來是不夠優雅,二是這種解決方案更像是一種 HACK 的解決方式,隨著時間長河的推進,這種代碼即便留下了註釋,也容易造成可讀性上困擾。

所以,我們需要嘗試替換掉這個 a 字母。

這裡,通過查閱資料,最終找到了這樣一個字元 -- \200e

\200e:是左到右標記(Left-to-Right Mark,LRM)的 Unicode 碼點。它是 Unicode 字元方向控制工具之一,用於強制將文本的閱讀方向指定為從左到右。在前端排版中,特別是處理多語言文本時,由於不同語言書寫時有不同的書寫方向,因此可以使用 LRM 來指定文本的書寫方向,以確保文本能夠正確地顯示。

這裡,通過 \200e 替換掉 a,這裡用 \200e 的目的與 a 的目的其實是不一樣的:

  1. 在字元串前面通過偽元素添加一個 a,目的是破壞其純數字的特性
  2. 在字元串前面通過偽元素添加一個 \200e,目的是強制控制接下來文本的排版順序

添加 a 的方案類似於一種 Hack 技巧,而 \200e 可以理解為就是專門解決這種場景而誕生的特殊字元。

好,看看改造後的代碼:

<div class="g-add-letter">
    <span>13993199751_18037893546_4477657</span>
</div>
.g-add-letter {
    overflow: hidden;
    text-overflow: ellipsis;
    direction: rtl;
    white-space: nowrap;
    
    span::before {
    content: "\200e";
    opacity: 0;
    font-size: 0;
  }
}

效果如下:

這樣,我們算是比較完美的解決了這個問題。

方案四:通過 <bdi> 標簽

那麼,上述的方案已經是最佳方案了嗎?或者說,還有沒有不需要添加偽元素的方式?

在查找解法的過程中,還發現了一個非常有意思的標簽 -- <bdi>

<bdi>:是一個 HTML 標簽,表示“雙向的隔離器”(Bidirectional Isolation)。它是一個比較新的標簽,主要用於解決混合顯示多個語言文本時的排版問題。

在多語言文本中,由於不同語言之間的書寫方向和文本組織方式可能有所不同,如果直接拼合在一起顯示,容易導致排版混亂,甚至出現不合法的語言混排現象。而 <bdi> 標簽則提供了一種簡單的解決方案,可以隔離不同的語言文本,確保它們按照正確的順序呈現,並避免混亂的語言混排現象。

具體來說,<bdi> 標簽可以將一段文本從周圍文本隔離開來,創建一個獨立的文本環境,使得文本能夠按照正確的書寫方向呈現。在使用該標簽時,可以使用 dir 屬性來指定文本的書寫方向,可以是從左到右(dir="ltr")或者從右到左(dir="rtl")等。

綜上所述,<bdi> 標簽的作用是提供一種簡單的解決方案來排版混合顯示多個語言文本,通過隔離不同的語言文本,確保它們按照正確的順序呈現,並避免混亂的語言混排現象。

因此,利用 <bdi> 標簽,我們可以再進一步省略掉偽元素的部分:

<div class="g-bdi">
    <bdi dir="ltr">13993199751_18037893546_4477657</bdi>
</div>
.g-bdi {
    overflow: hidden;
    text-overflow: ellipsis;
    direction: rtl;
    white-space: nowrap;
}

此種方案就比較純粹,回歸了最初的代碼,只是多了一層 <bdi> 並且設置了其內部語言排版方向。

最終,結果如下:

 上述四種方案的完整代碼,你也可以戳這裡:CodePen Demo -- 多種方式解決下劃線數字的頭部溢出省略打點排版問題

總結一下

本文,我們介紹了一種在頭部省略溢出的情境下,對於形如 11111_22222_33333_44444 這種用下劃線連接的文本,處理的方式會被對待成 11111 22222 33333 44444 一樣的情況,導致了最終排版結果與我們的預期不符。

為瞭解決這種問題,我們介紹了 4 種不同的解決方案:

  1. 方案一:兩次 direction 反轉
  2. 方案二:通過偽元素添加字母,破壞其純數字的性質
  3. 方案三:通過 \200e LRM 標記位
  4. 方案四:通過 <bdi> 標簽

上述 4 個方案的思維與處理方式各有優劣。圍繞多語言排版涉及了不同的知識,從一個很小的需求中,能夠窺探到其中複雜的邏輯。是一個很好的業務實操案例。

本文轉載於:

https://juejin.cn/post/7226540105698197563

如果對您有所幫助,歡迎您點個關註,我會定時更新技術文檔,大家一起討論學習,一起進步。

 


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 鑒於《網路新詞網路熱詞大全ACCESS資料庫》幾百條的記錄數太少,於是找了找網路上的一些流行熱詞網站,挑了個數據量大的採集了下來,經過整理(去除重覆、去除詞長超過10字)共得到1萬4千多條記錄。 熱詞:做完核酸可以領豆油解釋:疫情期間民眾耳朵不好使現狀。其實是“做完核酸不要逗留”。源自海南某地一排隊 ...
  • 《花木百科花木大全[圖]ACCESS資料庫》資料庫是採集全X花木網的圖文數據,資料很詳細,欄位包含種名、學名、別名、花期、生態性狀、觀賞性分類、科、屬、分佈地區、形態特征、生長習性、主要病蟲害、園林用途、主要功能、園林品種推薦、其他等。 因為網站源花木的圖片有限,所以有圖片的花木只有1千多條;並且需 ...
  • 其實互聯網上關於謎語和燈謎的資料仍然是挺多的,但是要想數據量以萬來計算並且是接近10萬的量來看的話,就只能是《近8萬條謎語燈謎大全ACCESS資料庫》了。而且《近8萬條謎語燈謎大全ACCESS資料庫》的數據表欄位中也包含分類欄位,可以根據分類欄位有針對性的給出謎語。 分類情況包含:字謎、成語、人名、 ...
  • 雖然已經有《7千多兒童故事網ACCESS\EXCEL資料庫》這種記錄數的童話故事類數據,但是遇到了好採集的就總想採集下來,後續有時間或有需求可以再做合併等操作。 分類情況統計為: 兒童故事:兒童小故事(1895)、睡前故事(1229)、益智故事(233)、哲理故事(177)。民間故事:世界上下五千年 ...
  • 原本我以為《3萬5千英語句子英語例句大全ACCESS資料庫》例句已經夠多了,沒想到今天遇到一個10萬條英語單詞例句的數據,非常適合與單詞詞典進行關聯學習,例句多了單詞的用法以及句子的掌握都更有效率,例句多了單詞的用法以及句子的掌握都更有效率,例句多了單詞的用法以及句子的掌握都更有效率,例句多了單詞的 ...
  • CSS中,*的作用是通配表示“全部”。遺憾的是,並沒有一種通配元素名的方法。 例如,我有好幾個東西class都標記為了my-element-序號,就像這樣: ```html ... ``` 我現在希望讓所有這些class的東西都應用同一個css規則。可惜,css並不支持這麼一種寫法: ```css ...
  • 近日在編寫一個小程式,將日記功能移植到小程式中,雖然在手機端寫日記一般用不到Markdown,但是仍想在小程式中查看在電腦端寫的Markdown格式的內容,如代碼塊等。 經過查詢,找到一個被廣泛使用的解決方案是towxml 現記錄如下: > 首先將代碼克隆下來 ```js git clone htt ...
  • > 效果預覽 ![調節頁面.gif](https://wansherry.com/api/fc01e2c58219126e20367e856ebad24c.gif) > 關鍵代碼 ```javascript //調節視窗大小 useEffect(() => { if (conref.current) ...
一周排行
    -Advertisement-
    Play Games
  • 概述:在C#中,++i和i++都是自增運算符,其中++i先增加值再返回,而i++先返回值再增加。應用場景根據需求選擇,首碼適合先增後用,尾碼適合先用後增。詳細示例提供清晰的代碼演示這兩者的操作時機和實際應用。 在C#中,++i 和 i++ 都是自增運算符,但它們在操作上有細微的差異,主要體現在操作的 ...
  • 上次發佈了:Taurus.MVC 性能壓力測試(ap 壓測 和 linux 下wrk 壓測):.NET Core 版本,今天計劃準備壓測一下 .NET 版本,來測試並記錄一下 Taurus.MVC 框架在 .NET 版本的性能,以便後續持續優化改進。 為了方便對比,本文章的電腦環境和測試思路,儘量和... ...
  • .NET WebAPI作為一種構建RESTful服務的強大工具,為開發者提供了便捷的方式來定義、處理HTTP請求並返迴響應。在設計API介面時,正確地接收和解析客戶端發送的數據至關重要。.NET WebAPI提供了一系列特性,如[FromRoute]、[FromQuery]和[FromBody],用 ...
  • 原因:我之所以想做這個項目,是因為在之前查找關於C#/WPF相關資料時,我發現講解圖像濾鏡的資源非常稀缺。此外,我註意到許多現有的開源庫主要基於CPU進行圖像渲染。這種方式在處理大量圖像時,會導致CPU的渲染負擔過重。因此,我將在下文中介紹如何通過GPU渲染來有效實現圖像的各種濾鏡效果。 生成的效果 ...
  • 引言 上一章我們介紹了在xUnit單元測試中用xUnit.DependencyInject來使用依賴註入,上一章我們的Sample.Repository倉儲層有一個批量註入的介面沒有做單元測試,今天用這個示例來演示一下如何用Bogus創建模擬數據 ,和 EFCore 的種子數據生成 Bogus 的優 ...
  • 一、前言 在自己的項目中,涉及到實時心率曲線的繪製,項目上的曲線繪製,一般很難找到能直接用的第三方庫,而且有些還是定製化的功能,所以還是自己繪製比較方便。很多人一聽到自己畫就害怕,感覺很難,今天就分享一個完整的實時心率數據繪製心率曲線圖的例子;之前的博客也分享給DrawingVisual繪製曲線的方 ...
  • 如果你在自定義的 Main 方法中直接使用 App 類並啟動應用程式,但發現 App.xaml 中定義的資源沒有被正確載入,那麼問題可能在於如何正確配置 App.xaml 與你的 App 類的交互。 確保 App.xaml 文件中的 x:Class 屬性正確指向你的 App 類。這樣,當你創建 Ap ...
  • 一:背景 1. 講故事 上個月有個朋友在微信上找到我,說他們的軟體在客戶那邊隔幾天就要崩潰一次,一直都沒有找到原因,讓我幫忙看下怎麼回事,確實工控類的軟體環境複雜難搞,朋友手上有一個崩潰的dump,剛好丟給我來分析一下。 二:WinDbg分析 1. 程式為什麼會崩潰 windbg 有一個厲害之處在於 ...
  • 前言 .NET生態中有許多依賴註入容器。在大多數情況下,微軟提供的內置容器在易用性和性能方面都非常優秀。外加ASP.NET Core預設使用內置容器,使用很方便。 但是筆者在使用中一直有一個頭疼的問題:服務工廠無法提供請求的服務類型相關的信息。這在一般情況下並沒有影響,但是內置容器支持註冊開放泛型服 ...
  • 一、前言 在項目開發過程中,DataGrid是經常使用到的一個數據展示控制項,而通常表格的最後一列是作為操作列存在,比如會有編輯、刪除等功能按鈕。但WPF的原始DataGrid中,預設只支持固定左側列,這跟大家習慣性操作列放最後不符,今天就來介紹一種簡單的方式實現固定右側列。(這裡的實現方式參考的大佬 ...