Kích thước phông chữ trong CSS -% hay em?


112

Khi đặt kích thước phông chữ trong CSS, tôi nên sử dụng giá trị phần trăm ( %) hay em? Bạn có thể giải thích lợi thế?


1
Theo tôi trong năm 2016 không có sự khác biệt giữa em và%. Nếu tôi đầu vào 1.2 em tất cả các trình duyệt hiện đại nghĩ rằng tôi đã sử dụng 120% và ví dụ nếu tôi sử dụng 0,7 em tất cả các trình duyệt hiện đại nghĩ rằng tôi đã sử dụng 70% ... Đây là những gì tôi đã có kinh nghiệm trong CSS
Mahdi Jazini

Câu trả lời:


79

Có một bài viết rất hay về kiểu chữ web trên A List Apart .

Kết luận của họ:

Định cỡ văn bản và chiều cao dòng trong ems, với tỷ lệ phần trăm được chỉ định trên nội dung (và một cảnh báo tùy chọn cho Safari 2), được hiển thị để cung cấp văn bản chính xác, có thể thay đổi kích thước trên tất cả các trình duyệt đang được sử dụng phổ biến hiện nay. Đây là một kỹ thuật bạn có thể bỏ vào túi đồ nghề của mình và sử dụng như một phương pháp hay nhất để định kích thước văn bản trong CSS đáp ứng được yêu cầu của cả người thiết kế và người đọc.


29
Trên thực tế line-heightsđược viết tốt hơn mà không có bất kỳ đơn vị nào cả. Đây được cho phép bởi spec, và hoàn toàn tránh quirks trình duyệt thực sự gây phiền nhiễu nhất định khi nói đến emdựa trên dòng cao
Mar Örlygsson

16
Tôi muốn mọi người biết rằng bài viết này có từ năm 2007. Kể từ đó, các trình duyệt hiện đại đã trở nên phổ biến hơn và các trình duyệt hiện đại thường phóng to thay vì tăng kích thước phông chữ như mặc định. Bởi vì điều này, 'px' đã trở nên phổ biến hơn và theo tôi là một cách tiếp cận tốt hơn. Tất nhiên điều đó còn gây tranh cãi nhưng cá nhân tôi đã gặp phải vấn đề trong các dự án do lồng ghép các em.
Mohag519,

5
@ Mohag519 làm tổ của em là một cái bẫy nguy hiểm. :)
Vishnudev K

@ Mohag519 không phải px sẽ cung cấp cho bạn thứ gì đó nhỏ hơn nhiều so với dự định với các thiết bị di động có mật độ điểm ảnh cao? Tôi không nghĩ rằng chúng tôi muốn các trang web của chúng tôi để được chính xác như máy tính để bàn nhưng siêu nhỏ trên điện thoại di động;)
johnb003

@ johnb003 Các thiết bị di động như vậy có tỷ lệ pixel thiết bị lớn hơn 1. Ví dụ: iPhone 4 có chiều rộng màn hình thực là 640px, nhưng xuất hiện dưới dạng "CSS" 320 pixel (DPR = 2). Vì vậy, trang web không xuất hiện nhỏ hơn!
Benjamin

14

Từ http://archivist.incutio.com/viewlist/css-discuss/1408

%: Một số trình duyệt không xử lý phần trăm cho kích thước phông chữ nhưng giải thích 150% là 150px. (Ví dụ: một số phiên bản NN4.) IE cũng có vấn đề với phần trăm trên các phần tử lồng nhau. Có vẻ như IE sử dụng phần trăm liên quan đến khung nhìn thay vì liên quan đến phần tử mẹ. Tuy nhiên, một vấn đề khác (mặc dù đúng theo thông số kỹ thuật W3C), trong Moz / Ns6, bạn không thể sử dụng phần trăm liên quan đến các phần tử không có chiều cao / chiều rộng được chỉ định.

em: Đôi khi các trình duyệt sử dụng kích thước tham chiếu sai, nhưng đối với các đơn vị tương đối thì đó là trình duyệt ít gặp sự cố nhất. Đôi khi bạn có thể thấy nó được hiểu là px.

pt: Khác nhau rất nhiều giữa các độ phân giải và không nên được sử dụng để hiển thị. Nó khá an toàn cho việc sử dụng in ấn.

px: Đơn vị tuyệt đối đáng tin cậy duy nhất trên màn hình. Tuy nhiên, nó có thể bị hiểu sai trong bản in, vì một điểm thường bao gồm một số pixel, và do đó mọi thứ trở nên nhỏ một cách kỳ cục.


Về điều pt. Tôi đã có một cuộc tranh cãi tuyệt vời về /. về điều đó (và bị mất). Tôi có cùng một điểm của quan điểm như bạn, tốt để biết nào đó chia sẻ rằng pov :)
Vincent McNabb

12
Bạn có thực sự nói rằng một số người dùng Netscape Navigator 4 có thể không xem trang của tôi một cách chính xác nếu tôi sử dụng tỷ lệ phần trăm cho kích thước phông chữ không?
newbie

4
Cuộc thảo luận được trích dẫn là từ năm 2002. Điều này có còn phù hợp không? Có trình duyệt nào đang được sử dụng với em hoặc% bug không?
Beni Cherniavsky-Paskin

1
Trích dẫn lỗi 20 năm tuổi trong trình duyệt không phải là một câu trả lời hữu ích.
d512

7

Cả hai đều điều chỉnh kích thước phông chữ tương ứng với kích thước của nó. 1,5em giống 150%. Ưu điểm duy nhất dường như là tính dễ đọc, hãy chọn cái nào bạn thấy thoải mái nhất.


Ai đó có thể giải thích cho tôi tại sao điều này lại bị bỏ phiếu không? Đây chính là cách tôi hiểu sự khác biệt giữa em & tỷ lệ phần trăm. Ngày nay không có bất kỳ lợi thế nào khi sử dụng cái này hơn cái kia. Điều quan trọng là bạn sử dụng kích thước tương ứng với kích thước phông chữ cơ bản.
Lee Theobald 25/09/08

1
Cảm ơn Lee, tôi vừa thử nghiệm điều này trong IE6, IE7, Firefox 3, Safari 3, Opera 9.5 và Google Chrome, tất cả đều trên Windows và tất cả chúng đều giống nhau đối với tôi! <p style = "font-size: 0.6em;"> đây là bài kiểm tra </p> <p style = "font-size: 60%;"> đây là bài kiểm tra </p>
Liam

7

Sự khác biệt thực sự rõ ràng khi bạn sử dụng nó không phải cho kích thước phông chữ. Đặt một paddingcủa 1emkhông giống như 100%. emluôn liên quan đến kích thước phông chữ. Nhưng %có thể là liên quan đến kích thước phông chữ, chiều rộng, chiều cao và có thể là một số thứ khác mà tôi không biết.


5

Cho rằng (gần như?) Tất cả các trình duyệt hiện thay đổi kích thước toàn bộ trang, thay vì chỉ văn bản, các vấn đề trước đây với pxso %với so với emvề thay đổi kích thước phông chữ có thể truy cập là khá tranh cãi.

Vì vậy, câu trả lời là nó có lẽ không quan trọng. Sử dụng bất cứ điều gì phù hợp với bạn.

% là tốt vì nó cho phép thay đổi kích thước tương đối.

px là tốt vì nó khá dễ dàng để quản lý các kỳ vọng khi sử dụng nó.

em có thể hữu ích khi cũng được sử dụng cho các phần tử bố cục vì nó có thể cho phép định cỡ tỷ lệ liên quan đến kích thước văn bản.


Câu trả lời gây hiểu lầm, đặc biệt là đối với những người không biết nhiều về CSS ngay từ đầu. Bỏ qua thực tế là CSS định nghĩa pixel logic, đó là một ý tưởng khủng khiếp dựa trên một quyết định vội vàng chắc chắn là có chỗ dựa cho sự tấn công dữ dội của các thiết bị di động hỗ trợ CSS một thập kỷ trước, pixel hoàn toàn nằm ở trình duyệt và người dùng tùy ý theo kích thước phông chữ mặc định , ít nhất. Ngoài ra, giờ đây chúng ta có rất nhiều tỷ lệ khung hình màn hình khác nhau (và không phải lúc nào thiết bị cũng màn hình) và độ phân giải từ 240p đến 2400p. Sử dụng pixel trong CSS mà không có JavaScript gần như vô dụng.
Amn

@amn à, lưu ý rằng câu trả lời này là 8 tuổi. Đó là một thời gian dài trong thời gian Internet. Điều đó nói rằng, các pixel vẫn tốt nếu không phải là lý tưởng. Hầu hết (tất cả?) Trình duyệt đều đáp ứng đủ kích thước phông chữ pixel trên thiết bị cụ thể. Tuy nhiên, ngày nay, tôi thường sử dụng rem làm đơn vị đo lường của mình.
ĐA.

Có thể tôi đang thiếu thứ gì đó, nhưng lợi ích gì nếu có với độ dài pixel? Tại sao họ "tốt" hoặc "lý tưởng"? Versus em, chẳng hạn. Bên cạnh đó, tôi nghĩ rằng các câu trả lời về SO nên cố gắng vượt thời gian - xét cho cùng thì đó là một cơ sở kiến ​​thức. Wikipedia về lập trình :) Vì Wikipedia được cập nhật để phản ánh sự thật, nên câu trả lời SO nên, theo ý kiến ​​khiêm tốn của tôi.
Amn

@amn Tôi không nói chúng là lý tưởng hay có lợi ích chính thực sự nào. Tôi chỉ trả lời câu hỏi của OP. Đối với việc phấn đấu vượt thời gian, nếu bạn có thể dự đoán tương lai của web trong 8 năm tới, bạn sẽ có thêm sức mạnh! Nhưng tôi không có thời gian để cập nhật liên tục các câu trả lời có giá trị của một thập kỷ ở đây. Hy vọng rằng mọi người biết đủ để nhìn vào dấu thời gian trên các câu trả lời và cân nhắc điều đó.
ĐA.

0

Về sự khác biệt giữa các đơn vị css %em.

Theo như tôi hiểu (ít nhất là về mặt lý thuyết / khái niệm, nhưng có thể không phải là cách hai đơn vị này có thể được triển khai trong các trình duyệt) thì hai đơn vị này tương đương nhau, tức là nếu bạn nhân emgiá trị của mình với 100và sau đó thay thế embằng %nó thì sẽ giống nhau?

Nếu thực sự có một số khác biệt thực sự giữa em và% thì ai đó có thể giải thích nó (hoặc cung cấp liên kết đến giải thích) không?

(Tôi muốn thêm nhận xét này của mình vào nơi nó sẽ thuộc về, tức là được thụt vào ngay bên dưới câu trả lời "Liam, answered Sep 25 '08 at 11:21"vì tôi cũng muốn biết tại sao câu trả lời của anh ấy bị bỏ phiếu từ chối, nhưng tôi không thể tìm cách đặt nhận xét của mình ở đó và do đó phải viết câu trả lời "chuỗi toàn cầu" này)


-1

Như Gal Na Uy đã đề cập, px là trang web đáng tin cậy nhất, vì mọi thứ khác bạn làm trên trang chủ yếu được trình bày liên quan đến màn hình máy tính. Vấn đề với kích thước tuyệt đối là một số trình duyệt (IE) sẽ không chia tỷ lệ các phần tử giá trị pixel trên trang web, vì vậy khi bạn cố gắng phóng to / thu nhỏ, mọi thứ sẽ điều chỉnh ngoại trừ các phần tử đó.

Tôi không biết IE8 có xử lý điều này đúng cách hay không, nhưng tất cả các nhà cung cấp trình duyệt khác đều xử lý pixel tốt và nó vẫn là một trường hợp thiểu số khi người dùng cần phóng to / thu nhỏ văn bản (hộp văn bản này trên SO có lẽ là ngoại lệ). Nếu bạn muốn thực sự khó hiểu, bạn luôn có thể thêm một hàm javascript để làm cho kích thước văn bản của bạn lớn hơn và cung cấp nút "nhỏ" / "lớn hơn" cho người dùng.


1
IE7 chia tỷ lệ giá trị pixel tốt, nếu bạn sử dụng thu phóng. IE6 không có zoom, chỉ có kích thước văn bản. Thu phóng trở thành một yêu cầu vì các nhà thiết kế đã sử dụng tỷ lệ pixel cố định thay vì cho phép trang điều chỉnh lại với các thay đổi kích thước văn bản.
Mike Dimmick 25/09/08

Nó vẫn là một vấn đề với IE6, nhưng, một lần nữa, MỌI THỨ vẫn là một vấn đề với IE6. Trong khi trước đây tôi tránh px vì điều đó, khái niệm phóng to toàn bộ trang web (so với phóng to văn bản) đã trở thành tiêu chuẩn và tôi thấy mình sử dụng px thường xuyên hơn nhiều.
ĐA.

-1

Thư viện Giao diện Người dùng Yahoo ( http://developer.yahoo.com/yui/ ) có một tập hợp các lớp css cơ sở đẹp mắt được sử dụng để "đặt lại" các cài đặt cụ thể của trình duyệt để cơ sở hiển thị trang web giống nhau cho tất cả (được hỗ trợ) các trình duyệt.

Với YUI, người ta phải sử dụng tỷ lệ phần trăm.


Tôi đã sử dụng thiết lập lại YUI, nhưng sau đó nhận ra rằng cài đặt kích thước văn bản của trình duyệt KHÔNG HOẠT ĐỘNG! Không thấy bất kỳ điểm nào khi sử dụng% nếu bạn đã đặt px trên phần thân vì nó phá vỡ cài đặt kích thước văn bản.
Jason
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.