Tại sao CSS hoạt động với các phần tử giả?


438

Trong lớp của tôi, tôi đã chơi xung quanh và phát hiện ra rằng CSS hoạt động với các yếu tố trang điểm.

Thí dụ:

imsocool {
    color:blue;
}
<imsocool>HELLO</imsocool>

Khi giáo sư của tôi lần đầu tiên nhìn thấy tôi sử dụng điều này, anh ấy đã hơi ngạc nhiên khi các yếu tố trang điểm hoạt động và khuyên tôi chỉ nên thay đổi tất cả các yếu tố tạo thành của mình thành các đoạn văn có ID.

Tại sao giáo sư của tôi không muốn tôi sử dụng các yếu tố trang điểm? Họ làm việc hiệu quả.

Ngoài ra, tại sao anh ta không biết rằng các yếu tố tạo nên tồn tại và hoạt động với CSS. Có phải họ không phổ biến?


62
HTML là một cách cung cấp ý nghĩa cho dữ liệu có thể được hiểu bởi nhiều phương tiện khác nhau (bao gồm cả con người và trình duyệt). Thẻ tạo thành của bạn không thêm bất kỳ ý nghĩa. Đó là một trong nhiều lý do tại sao anh ấy không muốn bạn sử dụng chúng.
punkrockbuddyholly

59
@MrMisterMan thực sự tôi nghĩ họ làm. Điều gì có ý nghĩa hơn - <p>555-212-2344</p>hoặc <supportPhone> 555-212-2344 </ supportPhone>
Yuriy Galanter

169
@YuriyGalanter <p class = "supportPhone">; P
punkrockbuddyholly

30
@MrMisterMan Chỉ cần nhớ, tất cả các quy tắc và cấu trúc lập trình này được tạo ra bởi những người không thông minh hơn bạn và bạn có thể thay đổi nó, bạn có thể tác động đến nó, bạn có thể xây dựng những thứ của riêng mình mà người khác có thể sử dụng.
L_7337

90
Tôi có thể chỉ ra rằng những gì bạn đang làm về cơ bản là XML chứ không phải HTML. XML là một ngôn ngữ đánh dấu trừu tượng hơn cho phép bạn biểu diễn dữ liệu theo cách "hữu ích" mà bạn mô tả - tức là. với ý nghĩa ngữ nghĩa kèm theo. Sau đó bạn có thể sử dụng một biến đổi XSLT để render dữ liệu của bạn trong HTML
OSE

Câu trả lời:


470

Tại sao CSS hoạt động với các phần tử giả?

(Hầu hết) các trình duyệt được thiết kế để (ở một mức độ nào đó) tương thích với các bổ sung trong tương lai cho HTML. Các phần tử không được nhận dạng được phân tích cú pháp vào DOM, nhưng không có ngữ nghĩa hoặc kết xuất mặc định chuyên biệt được liên kết với chúng.

Khi một phần tử mới được thêm vào đặc tả, đôi khi CSS, JavaScript và ARIA có thể được sử dụng để cung cấp cùng chức năng trong các trình duyệt cũ hơn (và các phần tử phải xuất hiện trong DOM để các ngôn ngữ đó có thể thao tác chúng để thêm chức năng đó ).

(Mặc dù cần lưu ý rằng công việc đang được tiến hành để xác định phương tiện mở rộng HTML bằng các yếu tố tùy chỉnh , nhưng công việc này đang ở giai đoạn đầu phát triển hiện tại vì vậy có lẽ nên tránh cho đến khi nó hoàn thiện.)

Tại sao giáo sư của tôi không muốn tôi sử dụng các yếu tố trang điểm?

  • Chúng không được phép bởi đặc tả HTML
  • Họ có thể xung đột với các yếu tố tiêu chuẩn trong tương lai có cùng tên
  • Có lẽ có một yếu tố HTML hiện có phù hợp hơn với nhiệm vụ

Cũng thế; tại sao anh ta không biết rằng các yếu tố trang điểm đã tồn tại và hoạt động với CSS. Có phải họ không phổ biến?

Đúng. Mọi người không sử dụng chúng vì họ có những vấn đề trên.


30
"Chúng không được phép bởi đặc tả HTML" Không nhất thiết phải đúng. Chúng không tuân thủ đặc tả Không gian tên HTML, nhưng thông số HTML5 là một điều rộng lớn hơn nhiều cho phép các thông số kỹ thuật tùy chỉnh và nêu rõ cách xử lý những điều đó liên quan đến xử lý CSS và API (DOM).
Ben Lesh

4
Hiện đã có thư viện, đặc biệt là Angular.js, cho phép bạn mở rộng HTML với các yếu tố tùy chỉnh. Có lẽ không phải theo nghĩa của bạn vì các yếu tố chỉ được phân tích cú pháp bởi javascript và thường được dịch sang các phần tử thực, nhưng nếu bạn đang tìm cách mở rộng html bằng các thẻ tùy chỉnh, bạn có thể làm điều đó với Angular
Charlie Martin

11
+1 Đối với "Họ có thể xung đột với các tiêu chuẩn trong tương lai". Hãy nhớ rằng nó có thể hoạt động ngay bây giờ nhưng nó phải hoạt động trong 3-4 năm sau khi bạn bắt đầu.
tim.baker

70
Tôi muốn có thẻ <ninja> để ẩn các yếu tố dom thay vì áp dụng hiển thị kiểu: không có ví dụ: <ninja> Một số nội dung ẩn </ ninja>
kiranvj

18
Một điểm thực sự quan trọng khác: Các trình duyệt đặc biệt dành cho người mù hoặc người có khả năng hạn chế sử dụng các yếu tố HTML thích hợp cho những thứ khác nhau (ví dụ như điều hướng trên trang dễ dàng bằng cách làm theo các tiêu đề). Vì vậy, ngữ nghĩa bị thiếu + kết xuất mặc định có thể không ảnh hưởng quá nhiều đến các trình duyệt thông thường, nhưng các trình duyệt đặc biệt này có thể sẽ bị nhầm lẫn, làm giảm đáng kể khả năng sử dụng trang web của bạn.
Arve Systad

98

TL; DR

  • Thẻ tùy chỉnh không hợp lệ trong HTML. Điều này có thể dẫn đến các vấn đề kết xuất.
  • Làm cho sự phát triển trong tương lai khó khăn hơn vì mã không phải là di động.
  • HTML hợp lệ cung cấp rất nhiều lợi ích như SEO, tốc độ và tính chuyên nghiệp.

Câu trả lời dài

một số đối số mà mã với các thẻ tùy chỉnh có thể sử dụng nhiều hơn.

Tuy nhiên, nó dẫn đến HTML không hợp lệ. Điều này là không tốt cho trang web của bạn.

Điểm của CSS / HTML hợp lệ | StackOverflow

  • Google thích nó vì vậy nó là tốt cho SEO.
  • Nó làm cho trang web của bạn có nhiều khả năng hoạt động hơn trong các trình duyệt mà bạn chưa thử nghiệm.
  • Nó làm cho bạn trông chuyên nghiệp hơn (ít nhất là với một số nhà phát triển)
  • Các trình duyệt tuân thủ có thể hiển thị [HTML hợp lệ nhanh hơn]
  • Nó chỉ ra một loạt các lỗi tối nghĩa mà bạn có thể đã bỏ lỡ ảnh hưởng đến những thứ mà bạn có thể chưa kiểm tra, ví dụ như bộ mã hoặc bộ ngôn ngữ của trang.

Tại sao xác nhận | W3C

  • Xác thực như một công cụ gỡ lỗi
  • Xác nhận chất lượng như một kiểm tra chất lượng trong tương lai
  • Xác nhận giúp giảm bớt bảo trì
  • Xác nhận giúp dạy các thực hành tốt
  • Xác nhận là một dấu hiệu của tính chuyên nghiệp

8
Một lập luận khác cho mã hợp lệ là, nếu bạn cần bàn giao cho nhà phát triển khác hoặc bạn đang làm việc trong một nhóm, các thành viên khác hoặc nhà phát triển mới sẽ hiểu ngay những gì bạn đang cố gắng đạt được. . . Với các thẻ được tạo không hợp lệ, điều này có thể trở nên rất khó khăn ...
Pat Dobson

9
AKA. Phát triển trong tương lai và nới lỏng bảo trì.
Dan Grahn

68

YADA (chưa có câu trả lời (khác))

Chỉnh sửa: Vui lòng xem nhận xét từ BoltClock bên dưới về loại vs thẻ vs phần tử. Tôi thường không lo lắng về ngữ nghĩa nhưng nhận xét của anh ấy rất phù hợp và nhiều thông tin.

Mặc dù đã có một loạt các câu trả lời tốt, bạn chỉ ra rằng giáo sư của bạn đã nhắc bạn gửi câu hỏi này để nó xuất hiện bạn (chính thức) ở trường . Tôi nghĩ rằng tôi sẽ giải thích sâu hơn một chút về không chỉ CSS mà cả cơ chế của các trình duyệt web. Theo Wikipedia , "CSS là một ngôn ngữ style sheet sử dụng để mô tả ... một tài liệu viết bằng một ngôn ngữ đánh dấu." (Tôi đã thêm phần nhấn mạnh vào "a") Lưu ý rằng nó không nói "được viết bằng HTML" ít hơn một phiên bản cụ thể của HTML. CSS có thể được sử dụng trên HTML, XHTML, XML, SGML, XAML, v.v ... Tất nhiên, bạn cần một cái gì đó sẽ kết xuấtmỗi loại tài liệu này cũng sẽ áp dụng kiểu dáng. Theo định nghĩa, CSS không biết / hiểu / quan tâm đến các thẻ ngôn ngữ đánh dấu cụ thể. Vì vậy, các thẻ có thể "không hợp lệ" khi có liên quan đến HTML, nhưng không có khái niệm về thẻ / phần tử / loại "hợp lệ" trong CSS.

Các trình duyệt trực quan hiện đại không phải là chương trình nguyên khối. Họ là một hỗn hợp của các "động cơ" khác nhau có công việc cụ thể phải làm. Ở mức tối thiểu tôi có thể nghĩ đến 3 công cụ, công cụ kết xuất, công cụ CSS và công cụ javascript / VM. Không chắc chắn nếu trình phân tích cú pháp là một phần của công cụ kết xuất (hoặc ngược lại) hoặc nếu nó là một công cụ riêng biệt, nhưng bạn có ý tưởng.

Trình duyệt hình ảnh có hay không ( những người khác đã giải quyết thực tế rằng trình đọc màn hình có thể có các thách thức khác đối với thẻ không hợp lệ ) áp dụng định dạng tùy thuộc vào việc trình phân tích cú pháp có để lại thẻ "không hợp lệ" trong tài liệu hay không và liệu công cụ kết xuất có áp dụng kiểu không vào thẻ đó. Vì nó sẽ gây khó khăn hơn cho việc phát triển / bảo trì, các công cụ CSS không được viết để hiểu rằng "Đây là tài liệu HTML nên đây là danh sách các thẻ / thành phần / loại hợp lệ". Các công cụ CSS chỉ cần tìm các thẻ / phần tử / loại và sau đó nói với công cụ kết xuất, "Đây là các kiểu bạn nên áp dụng." Việc công cụ kết xuất có quyết định áp dụng các kiểu hay không là tùy thuộc vào nó.

Đây là một cách dễ dàng để nghĩ về luồng cơ bản từ động cơ đến động cơ: trình phân tích cú pháp -> CSS -> kết xuất. Trong thực tế, nó phức tạp hơn nhiều nhưng điều này là đủ tốt cho người mới bắt đầu.

Câu trả lời này đã quá dài nên tôi sẽ kết thúc ở đó.


10
Mặc dù bạn đã đề cập rằng "thẻ" đã trở thành một thuật ngữ chung cho các yếu tố, điều mà tôi không thể và không đồng ý, nhưng điều đó không thay đổi thực tế rằng thuật ngữ chính xác cho chúng vẫn là "yếu tố". Thẻ đặc biệt là một tính năng cú pháp của HTML và XML và có thể không tồn tại trong các ngôn ngữ tài liệu khác tương thích với CSS. Vì vậy, nói rằng các "thẻ" kiểu CSS như mọi người thường gọi chúng không thực sự công bằng đối với thuyết bất khả tri của ngôn ngữ tài liệu về CSS.
BoltClock

53

Các yếu tố không xác định được coi là divs bởi các trình duyệt hiện đại. Đó là lý do tại sao họ làm việc. Đây là một phần của tiêu chuẩn HTML5 sắp tới giới thiệu cấu trúc mô đun có thể thêm các yếu tố mới.

Trong các trình duyệt cũ hơn (tôi nghĩ IE7-), bạn có thể áp dụng một thủ thuật Javascript sau đó chúng cũng sẽ hoạt động.

Đây là một câu hỏi liên quan tôi tìm thấy khi tìm kiếm một ví dụ.

Đây là một câu hỏi về sửa lỗi Javascript . Hóa ra IE7 thực sự không hỗ trợ các yếu tố này.

Cũng thế; tại sao anh ta không biết rằng các thẻ trang điểm đã tồn tại và hoạt động với CSS. Có phải họ không phổ biến?

Vâng, khá. Nhưng đặc biệt: chúng không phục vụ mục đích bổ sung. Và họ mới sử dụng html5. Trong các phiên bản trước của HTML, một thẻ không xác định là không hợp lệ.

Ngoài ra, đôi khi giáo viên dường như có lỗ hổng trong kiến ​​thức của họ. Điều này có thể là do thực tế là họ cần dạy cho sinh viên những điều cơ bản về một chủ đề nhất định, và nó không thực sự được đền đáp để biết tất cả mọi thứ và thực sự cập nhật. Có lần tôi bị giam giữ vì một giáo viên nghĩ rằng tôi đã lập trình virus, chỉ vì tôi có thể làm cho máy tính phát nhạc bằng cách sử dụng playlệnh trong GWBasic. (Câu chuyện có thật, và vâng, từ lâu). Nhưng cho dù lý do là gì, tôi nghĩ rằng lời khuyên không nên sử dụng các yếu tố theo yêu cầu là một âm thanh.


3
@OnoSendai Bạn khiến tôi nghi ngờ, nhưng tôi thực sự nghĩ rằng chúng được hiển thị dưới dạng 'các phần tử khối mà không cần đánh dấu bổ sung', vì vậy về cơ bản giống như divs.
GolezTrol

6
@OnoSendai Một phần tử khối có thể có thuộc tính hiển thị của khối , nhưng không bắt buộc. Chẳng hạn, các thẻ neo đã được thăng cấp thành trạng thái chặn (nghĩa là bạn được phép đặt các thành phần khối như div bên trong chúng), nhưng vẫn có thuộc tính hiển thị nội tuyến.
cimmanon

8
Giá trị ban đầu displayinline, vì vậy nhận xét của @ OnoSendai là chính xác.
BoltClock

2
@cimmanon: acác phần tử có mô hình nội dung minh bạch ngay bây giờ vì vậy chúng là khối hay nội tuyến phụ thuộc vào việc tổ tiên của chúng là khối hay nội tuyến. Câu trả lời này đang nói về các yếu tố không xác định, trong đó HTML không xác định mô hình nội dung. Theo như CSS, nếu không có displaygiá trị mặc định của trình duyệt thì nó sử dụng giá trị ban đầu.
BoltClock

1
@ BoltClock'saUnicorn Điều đó có nghĩa là <div> <a> foo </a> <a> thanh </a> </ div> sẽ hiển thị hai thẻ <a> dưới dạng khối? Điều đó có vẻ hơi nghi ngờ ...
fluffy

27

Trên thực tế bạn có thể sử dụng các yếu tố tùy chỉnh. Đây là thông số W3C về chủ đề này:

http://w3c.github.io/webcomponents/spec/custom/

Và đây là một hướng dẫn giải thích cách sử dụng chúng:

http://www.html5rocks.com/en/tutorials/webcomponents/customelements/

Như @Quentin đã chỉ ra: đây là một đặc tả dự thảo trong những ngày đầu phát triển và nó áp đặt các hạn chế về tên của các thành phần có thể là gì.


7
Cần lưu ý rằng đó là một đặc điểm kỹ thuật dự thảo trong những ngày đầu phát triển và nó áp đặt các hạn chế về tên của các thành phần có thể là gì.
Quentin

2
+1 Không biết W3C sử dụng githubnhưng thực sự họ sử dụng.
Vitor Canova

22

Có một vài điều về các câu trả lời khác chỉ là cụm từ kém hoặc có thể hơi sai.

SAI (ish): Các yếu tố HTML không chuẩn là "không được phép", "bất hợp pháp" hoặc "không hợp lệ".

Không cần thiết. Họ "không tuân thủ" . Có gì khác biệt? Một cái gì đó có thể "không phù hợp" và vẫn được "cho phép". W3C sẽ không gửi cảnh sát HTML đến nhà bạn và lôi bạn đi.

W3C để mọi thứ theo cách này vì một lý do. Sự phù hợp và thông số kỹ thuật được xác định bởi một cộng đồng. Nếu bạn tình cờ có một cộng đồng nhỏ hơn sử dụng HTML cho các mục đích cụ thể hơn và tất cả họ đều đồng ý về một số Yếu tố mới mà họ cần để làm cho mọi thứ dễ dàng hơn, họ có thể có những gì W3C gọi là "thông số kỹ thuật áp dụng khác" . (rõ ràng đây là một sự đơn giản hóa quá mức, nhưng bạn hiểu ý)

Điều đó nói rằng, các trình xác nhận nghiêm ngặt sẽ tuyên bố các yếu tố không chuẩn của bạn là "không hợp lệ". nhưng đó là bởi vì công việc của trình xác nhận là đảm bảo sự phù hợp với bất kỳ thông số kỹ thuật nào mà nó xác nhận, không phải để đảm bảo "tính hợp pháp" cho trình duyệt hoặc sử dụng .

FALSE (ish): Các phần tử HTML không chuẩn sẽ dẫn đến các sự cố kết xuất

Có thể, nhưng không thể. (thay thế "sẽ" bằng "có thể") Cách duy nhất điều này sẽ dẫn đến sự cố kết xuất là nếu phần tử tùy chỉnh của bạn xung đột với một đặc tả khác, chẳng hạn như thay đổi thông số HTML hoặc thông số kỹ thuật khác được tôn vinh trong cùng hệ thống (chẳng hạn như SVG, Math, hoặc một cái gì đó tùy chỉnh).

Trên thực tế, lý do CSS có thể định kiểu các thẻ không chuẩn là do đặc tả HTML nêu rõ rằng:

Tác nhân người dùng phải coi các yếu tố và thuộc tính mà họ không hiểu là trung lập về mặt ngữ nghĩa; để chúng trong DOM (cho bộ xử lý DOM) và tạo kiểu cho chúng theo CSS (đối với bộ xử lý CSS), nhưng không suy ra bất kỳ ý nghĩa nào từ chúng

Lưu ý: nếu bạn muốn sử dụng thẻ tùy chỉnh, chỉ cần nhớ một thay đổi đối với thông số HTML sau đó có thể giúp bạn tạo kiểu, vì vậy hãy chuẩn bị. Tuy nhiên, thực sự không chắc là W3C sẽ triển khai <imsocool>thẻ.

Thẻ không chuẩn và JavaScript (thông qua DOM)

Lý do bạn có thể truy cập và thay đổi các yếu tố tùy chỉnh bằng JavaScript là vì đặc tả thậm chí nói về cách xử lý chúng trong DOM , đó là API (thực sự khủng khiếp) cho phép bạn thao tác các yếu tố trên trang của mình.

Giao diện HTMLUn UnknownEuity phải được sử dụng cho các thành phần HTML không được xác định bởi thông số kỹ thuật này (hoặc các thông số kỹ thuật áp dụng khác).

TL; DR: Việc tuân thủ thông số kỹ thuật được thực hiện cho mục đích giao tiếp và an toàn. Không tuân thủ vẫn được cho phép bởi mọi thứ trừ một người xác nhận , với mục đích duy nhất là thực thi sự phù hợp, nhưng việc sử dụng là tùy chọn.

Ví dụ:

var wee = document.createElement('wee');
console.log(wee.toString()); //[object HTMLUnknownElement]

(Tôi chắc chắn điều này sẽ tạo ra ngọn lửa, nhưng có 2 xu của tôi)


3
HTML không chỉ xác định cách các phần tử nên được xử lý bằng cách viết CSS, thông số kỹ thuật CSS, đối với hầu hết các phần, cũng không biết ngôn ngữ tài liệu theo thiết kế (điều này đã được sắp xếp theo một số câu trả lời khác, nhưng tôi lưu ý ở đây cho tiện). Nếu có bất kỳ hành vi nào dành riêng cho HTML và / hoặc XHTML, thì nó luôn được chỉ định , ngay cả trong văn bản thông tin (ví dụ: "ID của phần tử HTML được chỉ định bởi idthuộc tính"), không chỉ là văn bản quy phạm (xem Nền và Biên giới 3 cho một thí dụ).
BoltClock

18

Theo thông số kỹ thuật:

CSS

Một công cụ chọn loại là tên của một loại yếu tố ngôn ngữ văn bản bằng cách sử dụng cú pháp của tên tiêu chuẩn CSS

Tôi nghĩ rằng nó được gọi là bộ chọn phần tử , nhưng rõ ràng nó thực sự là bộ chọn loại . Thông số kỹ thuật tiếp tục nói về việc CSS qualified nameskhông đặt ra giới hạn nào về tên thực sự là gì. Điều đó có nghĩa là miễn là bộ chọn loại khớp với cú pháp tên đủ điều kiện CSS thì đó là CSS đúng về mặt kỹ thuật và sẽ khớp với phần tử trong tài liệu. Không có hạn chế cụ thể về CSS đối với các yếu tố không tồn tại trong một thông số cụ thể - HTML hoặc cách khác.

HTML

Không có hạn chế chính thức về việc bao gồm bất kỳ thẻ nào trong tài liệu mà bạn muốn. Tuy nhiên, tài liệu nói

Tác giả không được sử dụng các yếu tố, thuộc tính hoặc giá trị thuộc tính cho các mục đích khác với mục đích ngữ nghĩa dự định phù hợp của họ, vì làm như vậy sẽ ngăn phần mềm xử lý chính xác trang.

Và nó nói sau

Tác giả không được sử dụng các yếu tố, thuộc tính hoặc giá trị thuộc tính không được phép của đặc điểm kỹ thuật này hoặc các thông số kỹ thuật áp dụng khác, vì làm như vậy sẽ khiến ngôn ngữ khó mở rộng hơn trong tương lai.

Tôi không chắc chắn cụ thể ở đâu hoặc nếu thông số kỹ thuật nói rằng các phần tử không được phép được cho phép , nhưng nó nói về giao diện HTMLUn UnknownEuity cho các phần tử không được nhận dạng. Một số trình duyệt thậm chí có thể không nhận ra các yếu tố trong thông số kỹ thuật hiện tại (IE8 xuất hiện trong tâm trí).

Mặc dù có một dự thảo cho các yếu tố tùy chỉnh , nhưng tôi nghi ngờ nó được thực hiện ở bất cứ đâu.


Tôi nghĩ rằng hầu hết chúng ta nghĩ về chúng như các bộ chọn thành phần nhưng có ý nghĩa rằng chúng là bộ chọn loại "chính thức" .
Andrew Steitz

@Andrew Steitz: Hãy nghĩ về nó theo cách này: phần tử: type :: person: name. Bạn có thể có nhiều yếu tố thuộc các loại khác nhau, với mỗi yếu tố là một loại duy nhất và theo cùng một cách bạn có thể có nhiều người, mỗi người có một tên. Bộ chọn hoạt động trên cây tài liệu và mọi bộ chọn có thể khớp với một số phần tử cây tài liệu mà bạn có thể thu hẹp với bộ chọn lớp, bộ chọn ID, bộ chọn thuộc tính ... hoặc bộ chọn loại. Dù bạn sử dụng, bạn vẫn phù hợp với các yếu tố. Vì vậy, "bộ chọn phần tử" sẽ không có ý nghĩa trong trường hợp này - tất cả những thứ này sẽ là bộ chọn phần tử.
BoltClock

@ BoltClock'saUnicorn: Đúng, nhưng lớp, ID và thuộc tính là tất cả, uh, thuộc tính (LOL) của một "phần tử", tức là "điều" trong dấu ngoặc nhọn. Chúng mô tả "phần tử" có thẻ mở mà chúng cư trú. Có, <a> và <div> là "loại" cụ thể của các phần tử, nhưng tôi nghi ngờ bất kỳ ai sẽ gọi lớp, ID và thuộc tính là "phần tử". Tôi HOÀN TOÀN đồng ý rằng tất cả các bộ chọn thực sự là bộ chọn "phần tử" nhưng trong SỬ DỤNG GIAO DỊCH, mọi người thường gọi bộ chọn "loại" là bộ chọn "phần tử". Đó là điểm nhận xét trước đây của tôi. Xin lỗi nó không rõ ràng. :-)
Andrew Steitz

@ExplumpingPills - Thông số kỹ thuật HTML không nói rằng các phần tử không xác định không được phép, nhưng vì mọi phần tử đều có một danh sách liệt kê các tên phần tử được phép là con của nó, (ví dụ như mô hình nội dung của nó), nên nó không phải. Đơn giản là không có phần tử không xác định nào được phép là phần tử con của phần tử được phép. Áp dụng HTMLUn UnknownE bổ sung cho các yếu tố như vậy là một phần của thông số kỹ thuật tiên quyết - tức là những gì người tiêu dùng HTML phải làm với các tài liệu hợp lệ hay không - và không phải là một phần của những gì tác giả phải làm để làm cho tài liệu của họ hợp lệ.
Alohci

@Alohci Ý tôi là không được phép theo nghĩa là họ sẽ bị loại khỏi DOM trái ngược với việc không hợp lệ về mặt ngữ nghĩa
Vụ nổ Pills

13

Điều này là có thể với html5 nhưng bạn cần xem xét các trình duyệt cũ hơn.

Nếu bạn quyết định sử dụng chúng sau đó, hãy đảm bảo COMMENT html của bạn !! Một số người có thể gặp một số khó khăn khi tìm hiểu xem đó là gì để một bình luận có thể giúp họ tiết kiệm rất nhiều thời gian.

Một cái gì đó như thế này,

<!-- Custom tags in use, refer to their CSS for aid -->

Khi bạn tạo thẻ / phần tử tùy chỉnh của riêng mình, các trình duyệt cũ hơn sẽ không biết thứ gì giống như các phần tử html5 như nav/ section.

Nếu bạn quan tâm đến khái niệm này thì tôi khuyên bạn nên thực hiện đúng cách.

Bắt đầu

Các yếu tố tùy chỉnh cho phép các nhà phát triển web xác định các loại yếu tố HTML mới. Thông số kỹ thuật là một trong một số nguyên tắc API mới hạ cánh dưới chiếc ô Thành phần Web, nhưng nó hoàn toàn có thể là quan trọng nhất. Thành phần web không tồn tại mà không có các tính năng được mở khóa bởi các yếu tố tùy chỉnh:

Xác định các phần tử HTML / DOM mới Tạo các phần tử mở rộng từ các phần tử khác Kết hợp hợp lý chức năng tùy chỉnh với nhau thành một thẻ Mở rộng API của các phần tử DOM hiện có

Có rất nhiều thứ bạn có thể làm với nó và nó làm cho kịch bản của bạn đẹp vì bài viết này thích đặt nó. Các yếu tố tùy chỉnh xác định các yếu tố mới trong HTML .

Vì vậy, hãy tóm tắt lại,

Ưu

  • Rất thanh lịch và dễ đọc.

  • Thật tuyệt khi không thấy nhiều như vậy divs. : p

  • Cho phép cảm nhận độc đáo về mã

Nhược điểm

  • Hỗ trợ trình duyệt cũ hơn là một điều mạnh mẽ để xem xét.

  • Các nhà phát triển khác có thể không biết phải làm gì nếu họ không biết về các thẻ tùy chỉnh. (Giải thích cho họ hoặc thêm ý kiến ​​để thông báo cho họ)

  • Cuối cùng, một điều cần xem xét, nhưng tôi không chắc chắn, là các yếu tố khối và nội tuyến. Bằng cách sử dụng các thẻ tùy chỉnh, bạn sẽ kết thúc việc viết thêm css vì thẻ tùy chỉnh sẽ không có mặt mặc định cho nó.

Sự lựa chọn hoàn toàn phụ thuộc vào bạn và bạn nên dựa trên những gì dự án đang yêu cầu.

Cập nhật 1/2/2014

Đây là một bài viết rất hữu ích tôi đã tìm thấy và hình dung tôi sẽ chia sẻ, Các yếu tố tùy chỉnh .

Tìm hiểu công nghệ Tại sao các yếu tố tùy chỉnh? Yếu tố tùy chỉnh cho phép tác giả xác định các yếu tố riêng của họ. Các tác giả liên kết mã JavaScript với tên thẻ tùy chỉnh và sau đó sử dụng các tên thẻ tùy chỉnh đó như bất kỳ thẻ tiêu chuẩn nào.

Ví dụ: sau khi đăng ký một loại nút đặc biệt gọi là siêu nút, hãy sử dụng nút siêu như thế này:

Yếu tố tùy chỉnh vẫn là yếu tố. Chúng ta có thể tạo, sử dụng, thao tác và soạn thảo chúng dễ dàng như mọi tiêu chuẩn hoặc ngày nay.

Đây có vẻ như là một thư viện rất tốt để sử dụng nhưng tôi đã nhận thấy rằng nó không vượt qua trạng thái Build của Window. Đây cũng là một bản pre-alpha tôi tin vì vậy tôi sẽ để mắt đến điều này trong khi nó phát triển.


3
" Other developers may have no clue what to do if they don't know about custom tags." Tôi ghét lập luận đó. Các nhà phát triển khác cũng phải học các công cụ mới và nếu họ không hiểu các kỹ thuật được sử dụng trong mã của bạn, họ nên biết ơn bạn vì đã chỉ ra những thiếu sót trong kiến ​​thức của họ. Có thể đó là một chút không công bằng trong trường hợp này, bởi vì các thẻ tùy chỉnh chỉ tồn tại dưới dạng bản nháp, nhưng tôi đã nghe thấy lập luận tương tự khi sử dụng các kỹ thuật được tiêu chuẩn hóa phù hợp.
GolezTrol

1
Tôi không nói rằng tôi ủng hộ điều đó nhưng rất nhiều nhà phát triển không tiếp tục học hỏi. Hầu như không có lý do để không bình luận một cái gì đó nếu nó là một chút phức tạp hoặc mới. Tất cả chúng ta nhận xét kịch bản của chúng tôi chính xác? Để hiển thị những gì chúng tôi đang thực hiện và làm thế nào, tương tự với các thẻ tùy chỉnh.
Josh Powell

1
Tất nhiên, nếu đó chỉ là về việc thêm ý kiến. Tôi mặc dù bạn có nghĩa là bạn hoàn toàn không nên sử dụng các yếu tố tùy chỉnh vì người khác sẽ không hiểu. Thêm một nhận xét nhỏ khi bạn thêm một kỹ thuật ít sử dụng là một việc nên làm. Hãy cẩn thận với các bình luận trong HTML, mặc dù. Họ có thể kết thúc trên máy khách, tiêu tốn băng thông và có thể tiết lộ chi tiết triển khai mà bạn không muốn khách truy cập tìm hiểu. Nhưng ngoài ra, bạn có thể thêm nhận xét dưới dạng nhận xét PHP / ASP, vì vậy chúng vẫn ở trong mẫu, nhưng vẫn ở trên máy chủ.
GolezTrol

1
@GolezTroi, không phải là bạn không bao giờ nên làm những điều thách thức các nhà phát triển khác, đó là một câu hỏi về lợi ích chi phí. Nếu làm điều gì đó theo cách khó hơn cho nhà phát triển tiếp theo một cách hợp pháp làm cho mã của bạn tốt hơn và sạch hơn, hãy làm điều đó. Nhưng đừng làm những việc sởn gai ốc chỉ để cho vui.
BostonJohn

1
@JoshPowell Nhận xét không nên nói về cái gì và như thế nào (mã đã nói điều đó và nếu nó không đủ rõ ràng, hãy viết lại mã cho đến khi nó), nhưng nên cho tôi biết lý do . Có một vài điều tồi tệ hơn vô số bình luận chỉ nói rằng sendmailchức năng gửi thư hoặc một cái gì đó tương tự. Tôi sẽ quan tâm hơn về lý do tại sao bạn gửi thư - và nếu tên hàm làm cho điều đó rõ ràng, thật tuyệt! Sau đó, tôi không cần một bình luận, đó là trường hợp lý tưởng. Tôi sẽ đọc mã nào.
Christopher Creutzig

4

Tại sao anh ta không muốn bạn sử dụng chúng? Chúng không phổ biến cũng không phải là một phần của tiêu chuẩn HTML5. Về mặt kỹ thuật, chúng không được phép. Họ là một hack.

Tôi thích bản thân họ, mặc dù. Bạn có thể quan tâm đến XHTML5. Nó cho phép bạn xác định các thẻ của riêng bạn và sử dụng chúng như một phần của tiêu chuẩn.

Ngoài ra, như những người khác đã chỉ ra, chúng không hợp lệ và do đó không thể mang theo được.

Tại sao anh ta không biết rằng chúng tồn tại? Tôi không biết, ngoại trừ việc chúng không phổ biến. Có thể anh ta chỉ không biết rằng bạn có thể.


2
Không có XHTML5 - có một nhóm làm việc đang cố gắng mang lại XHTML 2 nhưng nó đã bị xáo trộn nhiều năm trước.
tối đa

1
@papirtiger: XHTML5 là HTML5 được phân phát như XML, nhưng bạn đúng ở chỗ không có tiêu chuẩn XHTML độc lập nào ngoài XHTML 1.1.
BoltClock

1
Vì vậy, có XHTML5, nhưng nó có vẻ khác nhau hầu như không từ HTML5 liên quan đến chủ đề này của các thẻ tùy chỉnh. Do đó, tôi nghĩ rằng tuyên bố về XHTML5 cho phép bạn xác định các thẻ bổ sung trái ngược với HTML5 là sai, điều này có thể giải thích cho downvote, mặc dù tôi không chắc chắn về XHTML5 để upvote hoặc downvote câu trả lời này.
GolezTrol

1
Theo dự thảo HTML5 của W3C, HTML và XHTML là "cú pháp cụ thể" (hiện tại) đại diện cho cùng một "ngôn ngữ trừu tượng". Chúng có các tính năng cơ bản giống nhau, ngoại trừ các tính năng chỉ có ý nghĩa trong một cú pháp (không gian tên XML, trình chuyển đổi trình phân tích cú pháp HTML): w3.org/TR/html5/int
sinhtion.html # html

2

Thẻ tạo sẵn hầu như không bao giờ được sử dụng, vì không chắc là chúng sẽ hoạt động đáng tin cậy trong mọi trình duyệt hiện tại và mọi trình duyệt trong tương lai.

Một trình duyệt phải phân tích mã HTML thành các phần tử mà nó biết, các thẻ tạo thành sẽ được chuyển đổi thành một thứ khác để phù hợp với mô hình đối tượng tài liệu (DOM). Vì các tiêu chuẩn web không bao gồm cách xử lý mọi lỗi nằm ngoài các tiêu chuẩn, các trình duyệt web có xu hướng xử lý mã không độc lập theo các cách khác nhau.

Phát triển web là đủ khó khăn với một loạt các trình duyệt khác nhau có những điểm kỳ quặc riêng mà không cần thêm một yếu tố không chắc chắn nào. Đặt cược tốt nhất để gắn bó với những thứ thực sự nằm trong tiêu chuẩn, đó là những gì các nhà cung cấp trình duyệt cố gắng tuân theo, để có cơ hội tốt nhất để thực sự hoạt động.


2

Tôi nghĩ rằng các thẻ trang điểm chỉ có khả năng gây nhầm lẫn hoặc không rõ ràng hơn so với p với ID (nói chung là một số khối văn bản). Chúng ta đều biết ap với ID là một đoạn văn, nhưng ai biết thẻ trang điểm được dùng để làm gì? Ít nhất đó là suy nghĩ của tôi. :) Vì vậy, đây là một vấn đề phong cách / rõ ràng hơn là một chức năng.


3
Cảm ơn cổ tích ngữ pháp :)
runelynx

2

Những người khác đã đưa ra những điểm tuyệt vời nhưng đáng chú ý là nếu bạn nhìn vào một khung như AngularJS , có một trường hợp rất hợp lệ cho các thành phần và thuộc tính tùy chỉnh. Chúng truyền tải không chỉ ý nghĩa ngữ nghĩa tốt hơn cho xml, mà chúng còn có thể cung cấp hành vi, giao diện và cảm nhận cho trang web.


2

CSS là ngôn ngữ biểu định kiểu có thể được sử dụng để trình bày các tài liệu XML, không chỉ các tài liệu HTML (X). Đoạn mã của bạn với các thẻ đã tạo có thể là một phần của tài liệu XML hợp pháp; nó sẽ là một nếu bạn đặt nó trong một phần tử gốc duy nhất. Có lẽ bạn đã có một <html> ...</html>xung quanh nó? Bất kỳ trình duyệt hiện tại có thể hiển thị các tài liệu XML.

Tất nhiên nó không phải là một tài liệu XML rất tốt, nó thiếu một ngữ pháp và một tuyên bố XML. Nếu bạn sử dụng tiêu đề khai báo HTML thay thế (và có thể là cấu hình máy chủ gửi loại mime chính xác) thì đó sẽ là HTML bất hợp pháp.

(X) HTML có lợi thế so với XML đơn giản vì các yếu tố có ý nghĩa ngữ nghĩa rất hữu ích trong ngữ cảnh của bản trình bày trang web. Các công cụ có thể làm việc với ngữ nghĩa này, các nhà phát triển khác biết ý nghĩa, nó ít bị lỗi hơn và tốt hơn để đọc.

Nhưng trong các bối cảnh khác, tốt hơn là sử dụng CSS với XML và / hoặc XSLT để trình bày. Đây là những gì bạn đã làm. Vì đây không phải là nhiệm vụ của bạn, bạn không biết mình đang làm gì và HTML / CSS là cách tốt hơn để sử dụng phần lớn thời gian bạn nên tuân thủ trong kịch bản của mình.

Bạn nên thêm một tiêu đề HTML (X) vào tài liệu của mình để các công cụ có thể cung cấp cho bạn các thông báo lỗi có ý nghĩa.


2
Không, đó không phải là XML hợp pháp (được định dạng tốt). Có một <style>yếu tố, và sau đó ... một <body>yếu tố. Một tài liệu XML phải chỉ có một phần tử gốc; trong trường hợp này, <style>phần tử là phần tử gốc nhưng phần tử <body>bị can thiệp hoặc phần tử gốc cần được thêm vào làm cho cả hai phần tử trở thành phần tử con của nó. Trừ khi bạn thay thế <style>phần tử bằng tham chiếu biểu định kiểu (thậm chí URI dữ liệu như thế <?xml-stylesheet href="data:text/css,imsocool { color: blue; }"?>sẽ hoạt động tốt) sao cho phần tử gốc trở thành <body>.
BoltClock

2

... Tôi chỉ đơn giản là thay đổi tất cả các thẻ đã tạo thành các đoạn có ID.

Tôi thực sự có vấn đề với đề nghị của ông về cách làm điều đó đúng.

  1. Một <p>thẻ dành cho đoạn văn. Tôi thấy mọi người sử dụng nó mọi lúc thay vì div - đơn giản chỉ vì mục đích giãn cách hoặc vì nó có vẻ nhẹ nhàng hơn. Nếu nó không phải là một đoạn văn, đừng sử dụng nó.

  2. Bạn không cần hoặc không muốn dán ID lên mọi thứ trừ khi bạn cần nhắm mục tiêu cụ thể (ví dụ như với Javascript). Sử dụng các lớp hoặc chỉ là một div thẳng.


2

Ngay từ những ngày đầu, CSS đã được thiết kế để trở thành thuyết bất khả tri vì vậy nó có thể được sử dụng với bất kỳ ngôn ngữ đánh dấu nào tạo ra các cấu trúc DOM giống như cây (ví dụ SVG). Bất kỳ thẻ nào tuân thủname token sản xuất là hoàn toàn hợp lệ trong CSS. Vì vậy, câu hỏi của bạn là về HTML hơn là chính CSS.

Các yếu tố với các thẻ tùy chỉnh được hỗ trợ bởi đặc tả HTML5. HTML5 chuẩn hóa cách các phần tử không xác định phải được phân tích cú pháp trong DOM. Vì vậy, HTML5 là đặc tả HTML đầu tiên cho phép các thành phần tùy chỉnh nói đúng. Bạn chỉ cần sử dụng <!DOCTYPE html>tài liệu HTML5 trong tài liệu của mình.

Theo tên thẻ tùy chỉnh ...

Tài liệu này http://www.w3.org/TR/custom-elements/ khuyến nghị các thẻ tùy chỉnh bạn chọn để chứa ít nhất một ký hiệu '-' (dấu gạch ngang). Bằng cách này, họ sẽ không xung đột với các yếu tố HTML trong tương lai. Do đó, bạn nên thay đổi tài liệu của mình thành một cái gì đó như thế này:

<style>
so-cool {
    color:blue;
}
</style>

<body>
    <so-cool>HELLO</so-cool>
</body> 

2

Rõ ràng không ai đề cập đến nó, vì vậy tôi sẽ.

Đây là sản phẩm phụ của các cuộc chiến trình duyệt .

Quay trở lại những năm 1990 khi Internet lần đầu tiên bắt đầu đi vào xu hướng, sự cạnh tranh đã xuất hiện trên thị trường trình duyệt. Để duy trì tính cạnh tranh và thu hút người dùng, một số trình duyệt (đáng chú ý nhất là Internet Explorer) đã cố gắng hữu ích và thân thiện với người dùng bằng cách cố gắng tìm hiểu ý nghĩa của các nhà thiết kế trang và do đó cho phép đánh dấu không chính xác (ví dụ:<b><i>foobar</b></i> sẽ hiển thị chính xác như in đậm- chữ in nghiêng).

Điều này có ý nghĩa ở một mức độ nào đó bởi vì nếu một trình duyệt tiếp tục phàn nàn về lỗi cú pháp trong khi một trình duyệt khác ăn bất cứ thứ gì bạn ném vào nó và đưa ra một kết quả chính xác (ít nhiều), thì mọi người sẽ tự nhiên đổ về cái sau.

Trong khi nhiều người nghĩ rằng cuộc chiến trình duyệt đã kết thúc, một cuộc chiến mới giữa các nhà cung cấp trình duyệt đã được tổ chức lại trong vài năm qua kể từ khi Chrome được phát hành, Apple bắt đầu phát triển trở lại và đẩy Safari và IE mất đi sự thống trị. (Bạn có thể gọi nó là một cuộc chiến tranh lạnh giữa các nhà cung cấp do sự hợp tác và hỗ trợ về tiêu chuẩn của các nhà cung cấp trình duyệt.) Do đó, không có gì ngạc nhiên khi ngay cả các trình duyệt hiện đại được cho là tuân thủ nghiêm ngặt các tiêu chuẩn web thực sự cố gắng trở thành thông minh. cho phép hành vi phá vỡ tiêu chuẩn như thế này để cố gắng đạt được lợi thế như trước.

Thật không may, hành vi dễ dãi này đã dẫn đến một khổng lồ ( một số thậm chí có thể nói ung thư) tăng trưởng của các trang web kém đánh dấu lên. Bởi vì IE là trình duyệt phổ biến và phổ biến nhất, và do Microsoft tiếp tục bỏ qua các tiêu chuẩn, IE trở nên khét tiếng vì khuyến khích và thúc đẩy thiết kế xấu và tuyên truyền và duy trì các trang bị hỏng.

Bây giờ bạn có thể thoát khỏi việc sử dụng quirks và khai thác như vậy trên một số trình duyệt, nhưng ngoài câu đố hoặc trò chơi thường xuyên hoặc một cái gì đó, bạn phải luôn tuân thủ các tiêu chuẩn web khi tạo trang web và trang web để đảm bảo chúng hiển thị chính xác và tránh việc chúng bị hỏng (có thể bị bỏ qua hoàn toàn) với bản cập nhật trình duyệt.


Tôi cho rằng việc đổ lỗi cho trò chơi đặc biệt này trên IE là hơi lạc hậu, bởi vì khi một loạt các thẻ mới được thêm chính thức (cho HTML5), IE là trình duyệt chính duy nhất yêu cầu một "shim" cụ thể để làm cho chúng có thể tạo kiểu . Điều này một phần là do chế độ cập nhật mạnh mẽ hơn của các trình duyệt khác (có nghĩa là các phiên bản IE cũ tồn tại lâu hơn các phiên bản Chrome cũ của Firefox), nhưng hoàn toàn trái ngược với IE là "nhẹ nhàng nhất".
IMSoP

HTML5? Huh? <imsocool>không phải là một thẻ mới trong HTML5. Điều này không liên quan gì đến HTML5 hoặc IE 8, 9, v.v. Loại hành vi này không phải là một trò chơi mới ; nó là sản phẩm phụ của các cuộc chiến trình duyệt lâu năm . Ngay cả khi IE không chịu trách nhiệm đối với các vi phạm tiêu chuẩn hiện tại (mặc dù đối với các nhà phát triển web, họ vẫn từ chối tuân thủ đúng cách), họ chắc chắn đã nổi tiếng vì thúc đẩy các hoạt động mã hóa kém trong nhiều năm. Cụ thể hơn các trình duyệt khoan dung (IE là kẻ phạm tội tồi tệ nhất) đã đến vào thời điểm tồi tệ nhất, ngay khi Internet bắt đầu tắt và các nhà phát triển web bắt đầu học HTML Sai không chính xác.
Synetech

Tôi không nói điều này có liên quan gì đến HTML5, nhưng nó phải làm với các thẻ không chuẩn (ví dụ như <header>cho đến khi HTML5 trở thành tiêu chuẩn được nhắm mục tiêu) mà các phiên bản IE cũ chắc chắn không "khoan dung". Lenience cũng không giống như không tuân thủ - HTML5 là một tiêu chuẩn cực kỳ thực dụng, chấp nhận rằng HTML hình thành xấu sẽ tồn tại, không giống như chủ nghĩa lý tưởng của thông số kỹ thuật W3C trước đây và "sự khoan hồng" này có thể mang lại lợi ích cho sự phát triển dân chủ của web.
IMSoP

Một lần nữa, tôi không nói về bất kỳ trình duyệt hoặc phiên bản cụ thể nào. Tôi đang giải thích rằng sự khoan hồng nói chung là tác dụng phụ của các cuộc chiến trình duyệt. IE chấp nhận rất nhiều hành vi không chuẩn và thậm chí loại bỏ các hành vi bị hỏng như thẻ bị thiếu, thẻ và thuộc tính không hợp lệ và thẻ khớp sai ( <b><i>foobar</b></i>). Đây không phải là bí mật và thậm chí là một vấn đề bị chỉ trích nhiều và sai lầm. Như tôi đã nói, IE không phải là trình duyệt duy nhất cho phép đánh dấu kém, nhưng vì nó có thị phần lớn như vậy và xuất hiện đúng lúc (hoặc sai), nên nó đã đóng góp một lượng lớn cho việc đánh dấu kém nói chung .
Synetech

1

Mặc dù các trình duyệt thường sẽ liên kết CSS với các thẻ HTML bất kể chúng có hợp lệ hay không, nhưng bạn KHÔNG nên làm điều này.

Về mặt kỹ thuật không có gì sai với điều này từ góc độ CSS. Tuy nhiên, sử dụng các thẻ đã tạo là điều bạn KHÔNG BAO GIỜ nên làm trong HTML.

HTML là một ngôn ngữ đánh dấu, có nghĩa là mỗi thẻ tương ứng với một loại thông tin cụ thể.

Thẻ tạo thành của bạn không tương ứng với bất kỳ loại thông tin. Điều này sẽ tạo ra các vấn đề từ trình thu thập dữ liệu web, chẳng hạn như Google.

Đọc thêm thông tin về tầm quan trọng của đánh dấu chính xác .

Biên tập

Div tham khảo các nhóm của nhiều yếu tố liên quan, có nghĩa là được hiển thị ở dạng khối và có thể được thao tác như vậy.

Các nhịp đề cập đến các yếu tố được tạo kiểu khác với bối cảnh hiện tại và có nghĩa là được hiển thị nội tuyến, không phải là một khối. Một ví dụ là nếu một vài từ trong câu cần phải là tất cả các chữ hoa.

Thẻ tùy chỉnh không tương quan với bất kỳ tiêu chuẩn nào và do đó, span / div nên được sử dụng với các thuộc tính lớp / ID thay thế.

Có những miễn trừ rất cụ thể cho vấn đề này, chẳng hạn như Angular JS


3
"Không bao giờ" không bao giờ là câu trả lời đúng - dường như bạn đã quên về XHTML;)
Izkata

div và spans cũng không tương ứng với bất kỳ loại thông tin. Google và trình đọc màn hình dường như xử lý tốt những điều đó. Điều quan trọng là sử dụng đánh dấu ngữ nghĩa, nhưng nó không phải là một đối số chống lại việc sử dụng các thẻ tùy chỉnh.
GolezTrol

2
Divs đề cập đến các nhóm của nhiều yếu tố liên quan, có nghĩa là được hiển thị ở dạng khối và được thao tác như vậy. Các nhịp đề cập đến các yếu tố được tạo kiểu tương tự và có nghĩa là được hiển thị nội tuyến, không phải là một khối. Thẻ tùy chỉnh không tương quan với bất kỳ tiêu chuẩn nào và do đó, span / div nên được sử dụng với các thuộc tính lớp / ID thay thế.
Dan Green-ERICciger

Tôi đã loại bỏ bit của bạn về trình đọc màn hình vì nó không chính xác. Công nghệ hỗ trợ sẽ đọc <imsocool>some awesome text</imsocool>tốt bởi vì nó sẽ được hiểu là <>...</>. Điều không xảy ra là họ sẽ không thể nhảy vào đoạn văn bản đó một cách độc lập như thể đó là một <p>. Tất nhiên, nếu bạn đã viết DOCTYPE của riêng mình và được ánh xạ imsocooltới p, nó sẽ hoạt động.
Ryan B

0

Mặc dù CSS có một thứ gọi là "bộ chọn thẻ", nhưng thực tế nó không biết thẻ là gì. Điều đó để lại cho ngôn ngữ của tài liệu để xác định. CSS được thiết kế để được sử dụng không chỉ với HTML, mà còn với XML, trong đó (giả sử bạn không sử dụng DTD hoặc sơ đồ xác thực khác), các thẻ có thể là bất cứ thứ gì. Bạn cũng có thể sử dụng nó với các ngôn ngữ khác, mặc dù bạn sẽ cần đưa ra ngữ nghĩa của riêng mình để biết chính xác những gì như "thẻ" và "thuộc tính" tương ứng.

Các trình duyệt thường áp dụng CSS cho các thẻ không xác định trong HTML, vì điều này được coi là tốt hơn so với phá vỡ hoàn toàn: ít nhất là chúng có thể hiển thị một cái gì đó. Nhưng nó là rất xấu thực hành để sử dụng "giả" thẻ cố tình. Một lý do cho điều này là các thẻ mới thỉnh thoảng được xác định và nếu một thẻ được xác định trông giống như thẻ giả của bạn nhưng không hoạt động theo cùng một cách, điều đó có thể gây ra sự cố với trang web của bạn trên các trình duyệt mới.


0

Tại sao CSS hoạt động với các phần tử giả? Bởi vì nó không làm tổn thương bất cứ ai vì dù sao bạn cũng không nên sử dụng chúng.

Tại sao giáo sư của tôi không muốn tôi sử dụng các yếu tố trang điểm? Bởi vì nếu phần tử đó được xác định bởi một đặc tả trong tương lai thì phần tử của bạn sẽ có hành vi không thể đoán trước.

Ngoài ra, tại sao anh ta không biết rằng các yếu tố tạo nên tồn tại và hoạt động với CSS. Có phải họ không phổ biến? Bởi vì anh ấy, giống như hầu hết các nhà phát triển web khác, hiểu rằng chúng ta không nên sử dụng những thứ có thể phá vỡ ngẫu nhiên trong tương lai.

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.