CSS가 가짜 요소와 작동하는 이유는 무엇입니까?

Question 1

CSS는 왜 가짜 요소와 함께 작동합니까?

(대부분) 브라우저는 HTML에 향후 추가와 함께 (어느 정도) 전달되도록 설계되었습니다. 인식되지 않은 요소는 DOM에 구문 분석되지만 의미론이나 특수 기본 렌더링과 관련된 것은 없습니다.

새 요소가 사양에 추가되면 때때로 CSS, JavaScript 및 ARIA를 사용하여 이전 브라우저에서 동일한 기능을 제공 할 수 있습니다 (및 해당 언어가 해당 기능을 조작하여 해당 기능을 추가 할 수 있도록 요소가 표시되어야합니다. ).

(사양이 있습니다 맞춤 요소, 그러나 특정 명명 요구 사항이 있으며 JavaScript를 사용하여 등록해야합니다.)

교수님이 왜 제가 메이크업 요소를 사용하기를 원하지 않습니까?

HTML 사양에 의해 허용되지 않습니다
그들은 같은 이름의 미래 표준 요소와 충돌 할 수 있습니다.
아마도 작업에 더 적합한 기존 HTML 요소가있을 것입니다.

또한; 왜 그는 구성 요소가 존재하고 CSS와 함께 일했다는 것을 몰랐습니다. 그들은 드문 일입니까?

예. 사람들은 위의 문제가 있기 때문에 사용하지 않습니다.

Question 2

tl; dr

HTML에서 사용자 정의 태그가 유효하지 않습니다. 이로 인해 문제가 발생할 수 있습니다.
코드가 휴대 할 수 없기 때문에 미래 개발을 더욱 어렵게 만듭니다.
유효한 HTML은 SEO, 속도 및 전문성과 같은 많은 이점을 제공합니다.

긴 대답

거기 있습니다 일부 주장 사용자 정의 태그가있는 코드는 더 유용합니다.

그러나 그것은 유효하지 않은 HTML로 이어집니다. 귀하의 사이트에 좋지 않습니다.

유효한 CSS/HTML의 지점 | 스택 오버플로

Google은 SEO에게 좋습니다.

테스트하지 않은 브라우저에서 웹 페이지가 작동 할 가능성이 높아집니다.

그것은 당신이 더 전문적으로 보이게합니다 (적어도 일부 개발자에게)

준수 브라우저는 [유효한 HTML 더 빠르게] 렌더링 할 수 있습니다.

그것은 당신이 놓친 것들에 영향을 미치지 않았을 것입니다. 예를 들어 테스트하지 않은 것들에 영향을 미치는 모호한 버그를 지적합니다.

검증 된 이유 | W3C

디버깅 도구로서의 유효성 검사

미래 방지 품질 점검으로서의 검증

검증은 유지 보수가 완화됩니다

검증은 모범 사례를 가르치는 데 도움이됩니다

검증은 전문성의 표시입니다

Question 3

YADA (또 다른 (다른) 답변)

편집하다:유형, 태그, 요소에 관한 아래 BoltClock의 설명을 참조하세요.나는 보통 의미론에 대해 걱정하지 않지만 그의 의견은 매우 적절하고 유익합니다.

이미 좋은 답변이 많이 있지만, 교수 귀하가 (공식적으로) 그렇게 보이도록 이 질문을 게시하라는 메시지가 표시되었습니다. 학교에서.CSS뿐만 아니라 CSS에 대해서도 좀 더 깊이있게 설명해야겠다고 생각했습니다. 역학 웹 브라우저의.에 따르면 위키피디아, "CSS는 설명에 사용되는 스타일 시트 언어입니다 ...로 작성된 문서 ㅏ 마크업 언어." (나는 "a"에 강조점을 추가했습니다.) HTML의 특정 버전은커녕 "HTML로 작성"이라고 말하지 않는다는 점에 주목하세요.CSS는 HTML, XHTML, XML, SGML, XAML 등에 사용될 수 있습니다.물론, 당신에게는 뭔가가 필요합니다. 세우다 스타일을 적용할 각 문서 유형입니다.정의에 따르면 CSS는 그렇지 않습니다. 알고 있다/이해하다/관심하다 특정 마크업 언어 태그.따라서 HTML에 관한 한 태그는 "유효하지 않음"일 수 있지만 CSS에는 "유효한" 태그/요소/유형이라는 개념이 없습니다.

현대의 시각적 브라우저는 모놀리식 프로그램이 아닙니다.이는 특정 작업을 수행하는 다양한 "엔진"의 집합체입니다.에 최소한의 렌더링 엔진, CSS 엔진, 자바스크립트 엔진/VM 등 3가지 엔진을 생각할 수 있습니다.파서가 렌더링 엔진의 일부인지(또는 그 반대인지) 별도 엔진인지 확실하지 않지만 아이디어는 얻을 수 있습니다.

여부 시각적 브라우저(~~다른 사람들은 이미 화면이 있다는 사실을 언급했습니다. 독자 잘못된 태그를 처리하는 데 다른 문제가 있을 수 있습니다.~~) 형식 적용은 파서가 문서에 "잘못된" 태그를 남겨두는지 여부와 렌더링 엔진이 해당 태그에 스타일을 적용하는지 여부에 따라 달라집니다.개발/유지 관리가 더 어려워지기 때문에 CSS 엔진은 다음과 같이 작성되지 않습니다. 이해하다 "이것은 HTML 문서이므로 여기에 유효한 태그 / 요소 / 유형 목록이 있습니다." CSS 엔진은 단순히 찾을 수 있습니다 태그/요소/유형 그런 다음 렌더링 엔진에 "여기에 적용해야 할 스타일이 있습니다." 렌더링 엔진이 실제로 스타일을 적용하기로 결정했는지 여부는 위에 있습니다.

여기서 쉽게 생각하는 방법은 다음과 같습니다. 기초적인 엔진에서 엔진으로의 흐름:파서 -> CSS -> 렌더링.실제로는 훨씬 더 복잡하지만 이것은 초보자에게는 충분합니다.

답변이 너무 길어서 여기서 마치겠습니다.

Question 4

알려지지 않은 요소는 다음과 같이 처리됩니다 div현대 브라우저에 의해 s. 그것이 그들이 일하는 이유입니다. 이것은 새로운 요소를 추가 할 수있는 모듈 식 구조를 도입하는 다가오는 HTML5 표준의 일부입니다.

구형 브라우저 (IE7-)에서는 JavaScript 트릭을 적용한 후에도 작동 할 수 있습니다.

여기에 있습니다 관련 질문 예를 찾을 때 찾았습니다.

여기에 있습니다 JavaScript 수정에 대한 질문. 실제로 이러한 요소를 상자 밖으로 지원하지 않는 것은 IE7입니다.

또한; 왜 그는 메이크업 태그가 존재하고 CSS와 함께 일했다는 것을 몰랐습니다. 그들은 드문 일입니까?

예, 꽤. 그러나 특히 : 그들은 추가적인 목적을 제공하지 않습니다. 그리고 그들은 html5를 처음 사용합니다. 이전 버전의 HTML에서는 알려지지 않은 태그가 유효하지 않았습니다.

또한 교사는 때때로 지식에 차이가있는 것 같습니다. 이것은 학생들에게 주어진 주제에 대한 기본 사항을 가르쳐야한다는 사실 때문일 수 있으며, 모든 내용과 외부를 알고 실제로 최신 정보를 얻는 것은 실제로 돈을 지불하지 않습니다. 선생님이 바이러스를 프로그래밍했다고 생각했기 때문에 한 번 구금되었습니다. play gwbasic의 명령. (사실 이야기, 그리고 오래 전에. 그러나 그 이유가 무엇이든, 나는 custome 요소를 사용하지 않는 조언이 건전한 것이라고 생각합니다.

Question 5

실제로 사용자 정의 요소를 사용할 수 있습니다. 이 주제에 대한 W3C 사양은 다음과 같습니다.

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

다음은 사용 방법을 설명하는 자습서입니다.

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

@Quentin이 지적한 바와 같이 : 이것은 개발 초기의 초안 사양이며 요소 이름이 무엇인지에 대한 제한을 부과합니다.

Question 6

다른 답변에는 표현이 잘못되었거나 약간 부정확한 몇 가지 사항이 있습니다.

거짓(같은):비표준 HTML 요소는 "허용되지 않음", "불법" 또는 "유효하지 않음"입니다.

반드시 그런 것은 아닙니다.그들은 "부적합".차이점이 뭐야? 어떤 것은 "부적합"할 수 있고 여전히 "허용"될 수 있습니다. W3C는 HTML 경찰을 귀하의 집으로 보내 귀하를 끌고 가지 않을 것입니다.

W3C가 이런 식으로 방치한 데에는 이유가 있습니다.적합성과 사양은 커뮤니티에서 정의됩니다.보다 구체적인 목적을 위해 HTML을 사용하는 소규모 커뮤니티가 있고 작업을 더 쉽게 만드는 데 필요한 몇 가지 새로운 요소에 모두 동의하는 경우 W3C에서 말하는 것을 가질 수 있습니다. "기타 적용 가능한 사양".(이것은 분명히 지나치게 단순화한 것이지만 아이디어를 얻을 수 있습니다)

즉, 엄격한 유효성 검사기는 비표준 요소를 "유효하지 않음"으로 선언합니다.하지만 이는 유효성 검사기의 임무가 유효성을 검사하는 사양에 대한 적합성을 보장하는 것이지 해당 사양에 대한 "합법성"을 보장하는 것이 아니기 때문입니다. 브라우저 또는 사용.

거짓(같은):비표준 HTML 요소 ~ 할 것이다 렌더링 문제가 발생함

그럴 수도 있지만 그럴 것 같지는 않습니다.('will'을 'might'로 교체) 이로 인해 렌더링 문제가 발생하는 유일한 방법은 맞춤 요소가 HTML 사양 변경이나 동일한 시스템 내에서 적용되는 다른 사양(예: SVG, 수학 또는 사용자 정의 항목).

사실은, CSS가 비표준 태그의 스타일을 지정할 수 있는 이유 HTML 사양 때문입니다. 분명히 말한다 저것:

사용자 에이전트는 의미상 중립적으로 이해하지 못하는 요소와 속성을 처리해야 합니다.DOM(DOM 프로세서의 경우)에 남겨두고 CSS(CSS 프로세서의 경우)에 따라 스타일을 지정하지만 의미를 추론하지는 않습니다.

메모: 사용자 정의 태그를 사용하려면 나중에 HTML 사양을 변경하면 스타일이 망가질 수 있으므로 미리 준비하세요.W3C가 이를 구현할 가능성은 거의 없습니다. <imsocool> 그러나 태그.

비표준 태그 및 JavaScript(DOM을 통해)

JavaScript를 사용하여 맞춤 요소에 액세스하고 변경할 수 있는 이유는 사양은 DOM에서 어떻게 처리되어야 하는지에 대해서도 설명합니다., 페이지의 요소를 조작할 수 있는 (정말 끔찍한) API입니다.

HTMLUnknownElement 인터페이스는 이 사양(또는 기타 적용 가능한 사양)에서 정의되지 않은 HTML 요소에 사용해야 합니다.

요약:사양 준수는 통신 및 안전을 위해 수행됩니다.부적합은 여전히 모든 것에서 허용됩니다. 검증인, 유일한 목적은 적합성을 강화하는 것이지만 사용은 선택 사항입니다.

예를 들어:

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

(이게 불길을 일으킬 것이라고 확신하지만 2 센트가 있습니다)

Question 7

사양에 따라 :

CSS

ㅏ 유형 선택기 CSS 자격을 갖춘 이름의 구문을 사용하여 작성된 문서 언어 요소 유형의 이름입니다.

나는 이것이라고 불렀다 요소 선택기이지만 실제로는입니다 유형 선택자. 사양은 계속해서 이야기합니다 CSS qualified names 이름이 실제로 무엇인지 제한하지 않습니다. 즉, 유형 선택기가 CSS 적격 이름 구문과 일치하는 한 기술적으로 올바른 CSS이며 문서의 요소와 일치합니다. 특정 사양에 존재하지 않는 요소 (HTML 또는 기타)에는 CSS 특이 적 제한이 없습니다.

HTML

원하는 문서에 태그를 포함시키는 것에 대한 공식적인 제한은 없습니다. 그러나 문서는 말합니다

저자는 소프트웨어가 페이지를 올바르게 처리하는 것을 방지하기 때문에 적절한 의도 된 의미 론적 목적 이외의 목적으로 요소, 속성 또는 속성 값을 사용해서는 안됩니다.

그리고 나중에 말합니다

저자는이 사양 또는 기타 적용 가능한 사양에 의해 허용되지 않는 요소, 속성 또는 속성 값을 사용해서는 안됩니다. 따라서 언어가 향후 언어를 확장하기가 매우 어렵 기 때문에.

사양이 무한 요소가 허용된, 그러나 그것은에 대해 이야기합니다 htmlunknownelement 인식되지 않은 요소에 대한 인터페이스. 일부 브라우저는 현재 사양에있는 요소를 인식하지 못할 수도 있습니다 (IE8은 떠오른다).

이있다 사용자 정의 요소 초안, 그러나 그러나 나는 그것이 아직 어디에서나 구현되었다고 의심합니다.

Question 8

이것은 HTML5에서는 가능하지만 이전 브라우저를 고려해야합니다.

당신이 그것들을 사용하기로 결정했다면, 당신의 html에 댓글을 달아야합니다 !! 어떤 사람들은 그것이 무엇인지 알아내는 데 어려움을 겪을 수 있으므로 의견이 많은 시간을 절약 할 수 있습니다.

이 같은,

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

자신의 사용자 정의 태그/요소를 만들 때 이전 브라우저는 HTML5 요소와 같은 모습이 없습니다. nav/section.

이 개념에 관심이 있다면 올바른 방법으로하는 것이 좋습니다.

시작하기

사용자 정의 요소를 통해 웹 개발자는 새로운 유형의 HTML 요소를 정의 할 수 있습니다. 이 사양은 웹 구성 요소 우산 아래에 착륙하는 몇 가지 새로운 API 프리미티브 중 하나이지만 가장 중요합니다. 사용자 정의 요소로 잠금 해제 된 기능이 없으면 웹 구성 요소가 없습니다.

새 HTML/DOM 요소 정의 다른 요소로부터 확장되는 요소 생성 요소를 논리적으로 묶어 사용자 정의 기능을 단일 태그로 함께 기존 DOM 요소의 API를 확장합니다.

당신이 그것으로 할 수있는 일이 많이 있으며,이 기사가 그것을 넣는 것을 좋아하기 때문에 스크립트를 아름답게 만듭니다. HTML에서 새로운 요소를 정의하는 사용자 지정 요소.

그래서 요약하자.

프로

매우 우아하고 읽기 쉽습니다.
그렇게 많이 보지 않는 것이 좋습니다 divs. :피
코드에 고유 한 느낌을줍니다

단점

구형 브라우저 지원은 고려해야 할 강력한 것입니다.
다른 개발자들은 사용자 정의 태그에 대해 모른다면 어떻게 해야하는지 전혀 알지 못할 수 있습니다. (그들에게 설명하거나 의견을 추가하여 정보를 추가하십시오)
마지막으로 고려해야 할 한 가지는 확실하지 않습니다. 블록과 인라인 요소입니다. 사용자 정의 태그를 사용하면 사용자 정의 태그로 인해 더 많은 CSS를 작성하면 기본 측면이 없습니다.

선택은 전적으로 당신에게 달려 있으며 프로젝트가 요구하는 것에 근거해야합니다.

2014 년 1 월 2 일 업데이트

다음은 내가 찾은 매우 유용한 기사입니다. 맞춤 요소.

기술을 배우십시오. 왜 사용자 정의 요소? 사용자 정의 요소는 저자가 자신의 요소를 정의 할 수 있도록합니다. 저자는 JavaScript 코드를 사용자 정의 태그 이름과 연결 한 다음 표준 태그와 같이 사용자 지정 태그 이름을 사용합니다.

예를 들어, Super-Button이라는 특수 종류의 버튼을 등록한 후에는 다음과 같이 슈퍼 버튼을 사용하십시오.

사용자 정의 요소는 여전히 요소입니다. 우리는 표준이나 오늘날처럼 쉽게 만들고, 사용하고, 조작하고, 구성 할 수 있습니다.

이것은 사용하기에 아주 좋은 라이브러리처럼 보이지만 Window의 빌드 상태를 통과하지 못했습니다. 이것은 또한 내가 믿는 사전 알파에 있습니다. 그래서 나는 그것이 발전하는 동안 이것을 주시 할 것입니다.

Question 9

왜 그는 당신이 그들을 사용하기를 원하지 않습니까? 그것들은 공통적이거나 HTML5 표준의 일부가 아닙니다. 기술적으로는 허용되지 않습니다. 그들은 해킹입니다.

그래도 나는 그들을 좋아한다. XHTML5에 관심이있을 수 있습니다. 이를 통해 자신의 태그를 정의하고 표준의 일부로 사용할 수 있습니다.

또한 다른 사람들이 지적했듯이, 그들은 유효하지 않아 휴대 할 수 없습니다.

왜 그가 존재한다는 것을 몰랐습니까? 나는 그들이 흔하지 않다는 것을 제외하고는 모른다. 아마도 그는 당신이 할 수 있다는 것을 알지 못했을 것입니다.

Question 10

메이크업 태그는 거의 사용되지 않습니다. 모든 현재 브라우저와 모든 미래의 브라우저에서 안정적으로 작동하지 않을 것입니다.

브라우저는 HTML 코드를 알고있는 요소로 구문 분석해야합니다. 작성 태그는 문서 개체 모델 (DOM)에 맞게 다른 것으로 변환됩니다. 웹 표준이 표준을 벗어난 모든 것을 처리하는 방법을 다루지 않기 때문에 웹 브라우저는 비 스탠더 코드를 다양한 방식으로 처리하는 경향이 있습니다.

웹 개발은 불확실성의 다른 요소를 추가하지 않고 자체적으로 기발한 다양한 브라우저로 충분히 까다 롭습니다. 실제로 표준에있는 것들을 고수하는 것이 가장 좋습니다. 이것이 바로 브라우저 공급 업체가 따라 가려는 것입니다. 그래서 실제로 작동 할 수있는 가장 좋은 기회가 있습니다.

Question 11

메이크업 태그는 ID가있는 P보다 잠재적으로 더 혼란 스럽거나 불분명하다고 생각합니다 (일반적으로 일부 텍스트 블록). 우리는 모두 ID가있는 AP가 단락이라는 것을 알고 있지만 누가 메이크업 태그가 의도한지 누가 알고 있습니까? 적어도 그것은 내 생각입니다. :) 그러므로 이것은 기능 중 하나보다 스타일 / 선명도 문제에 가깝습니다.

Question 12

다른 사람들은 훌륭한 포인트를 만들었지 만 다음과 같은 프레임 워크를 보면 Angularjs, 사용자 정의 요소 및 속성에는 매우 유효한 사례가 있습니다. 이것들은 XML에 더 나은 의미 적 의미를 전달할뿐만 아니라 웹 페이지의 행동, 모양 및 느낌을 제공 할 수 있습니다.

Question 13

CSS는 (x) HTML 문서뿐만 아니라 XML 문서를 제시하는 데 사용할 수있는 스타일 시트 언어입니다. 메이크업 태그가있는 스 니펫은 합법적 인 XML 문서의 일부일 수 있습니다. 단일 루트 요소로 둘러싸인 경우 하나 일 것입니다. 아마 당신은 이미 가지고 있습니다 <html> ...</html> 주위에? 현재 브라우저는 XML 문서를 표시 할 수 있습니다.

물론 그것은 매우 좋은 XML 문서가 아니며 문법과 XML 선언이 부족합니다. 대신 HTML 선언 헤더를 사용하는 경우 (아마도 올바른 MIME 유형을 보내는 서버 구성) 대신 불법 HTML 일 것입니다.

(x) HTML은 원소가 웹 페이지 프레젠테이션의 맥락에서 유용한 의미 론적 의미를 가지기 때문에 일반 XML에 비해 장점을 가지고 있습니다. 도구는이 의미론과 함께 작동 할 수 있으며, 다른 개발자는 의미를 알고 있으며, 오류가 적고 읽는 것이 더 좋습니다.

그러나 다른 상황에서는 XML 및/또는 XSLT와 함께 CSS를 사용하여 프레젠테이션을 수행하는 것이 좋습니다. 이것이 당신이 한 일입니다. 이것이 당신의 임무가 아니었기 때문에, 당신은 당신이 무엇을하고 있는지 알지 못했고, HTML/CSS는 시나리오에서 그것을 고수 해야하는 대부분의 시간을 더 잘하는 방법입니다.

도구가 의미있는 오류 메시지를 제공 할 수 있도록 문서에 (x) HTML 헤더를 추가해야합니다.

Question 14

... 나는 단순히 모든 구성 태그를 ID가있는 단락으로 변경합니다.

나는 실제로 올바르게하는 방법에 대한 그의 제안에 문제를 겪습니다.

ㅏ  태그는 단락 용입니다. 나는 사람들이 단순히 간격 목적으로 또는 더 온화한 것처럼 보이기 때문에 div 대신 항상 그것을 사용하는 것을 본다. 단락이 아닌 경우 사용하지 마십시오.
구체적으로 타겟팅해야 할 경우 (예 : JavaScript)가 필요하지 않으면 모든 것에 ID를 고수 할 필요가 없습니다. 클래스를 사용하거나 단지 직진 Div.

Question 15

초기부터 CSS는 마크 업 Agnostic으로 설계되었으므로 모든 마크 업 언어를 생산하는 트리 모두 같은 DOM 구조 (예 : SVG)와 함께 사용할 수 있습니다. 준수하는 모든 태그 name token CSS에서는 생산이 완벽하게 유효합니다. 따라서 귀하의 질문은 CSS 자체보다 HTML에 관한 것입니다.

사용자 정의 태그가있는 요소는 HTML5 사양에 의해 지원됩니다. HTML5는 DOM에서 알려지지 않은 요소가 어떻게 구문 분석되어야하는지 표준화합니다. 따라서 HTML5는 사용자 정의 요소를 엄격하게 말할 수있는 최초의 HTML 사양입니다. html5 doctype 만 사용하면됩니다 <!DOCTYPE html> 당신의 문서에서.

맞춤형 태그 이름 자체로 ...

이 문서 http://www.w3.org/tr/custom-elements/ 하나 이상의 '-'(Dash) 기호를 포함하도록 선택한 사용자 정의 태그를 권장합니다. 이런 식으로 그들은 미래의 HTML 요소와 충돌하지 않을 것입니다. 따라서 문서를 다음과 같은 것으로 바꾸는 것이 좋습니다.

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

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

Question 16

놀랍게도 (내 과거 자아 포함) 아무도 접근성을 언급하지 않았습니다. 사용자 정의 태그 대신 유효한 태그를 사용하는 또 다른 이유는 화면 판독기 및 사람들이 접근성 목적으로 필요한 기타 도구를 포함하여 가장 많은 양의 소프트웨어와 호환되는 이유입니다. 또한 WAI와 같은 접근성 법률 필요하다 액세스 가능한 웹 사이트를 만드는 것은 일반적으로 유효한 마크 업을 사용해야하는 것을 의미합니다.

^{분명히 아무도 그것을 언급하지 않았으므로 그럴 것입니다.}

이것은 부산물입니다 브라우저 전쟁.

인터넷이 처음으로 주류가 시작되었을 때 1990 년대에 브라우저 시장에서 경쟁이 벌어졌습니다. 경쟁력을 유지하고 사용자를 끌어 들이기 위해 일부 브라우저 (특히 인터넷 익스플로러) 의미했다 따라서 잘못된 마크 업을 허용했습니다 (예 : foobar 올바르게 굵게 렌더링됩니다).

하나의 브라우저가 구문 오류에 대해 계속 불평하는 반면 다른 브라우저가 당신이 던진 모든 것을 먹고 (더 많은) 올바른 결과를 뱉어 내면 사람들은 자연스럽게 후자에게 몰려 들기 때문입니다.

많은 사람들이 브라우저 전쟁이 끝났다고 생각했지만 크롬이 석방 된 이후 지난 몇 년 동안 브라우저 공급 업체 간의 새로운 전쟁이 통치되었고 애플은 다시 성장하고 사파리를 밀기 시작했고 즉, 지배력을 잃었습니다. (브라우저 공급 업체의 표준에 대한 인식 된 협력과 표준 지원으로 인해“냉전”이라고 부를 수 있습니다.) 따라서 현대 브라우저조차도 놀라운 일이 아닙니다. 아마도 웹 표준을 엄격하게 준수하면 실제로 "영리"하려고 노력하고 이전과 같이 이점을 얻으려면 이와 같은 표준 중단 동작을 허용합니다.

불행히도,이 허용적인 행동은 거대한 (약간 암호로 표시되지 않은 웹 페이지의 성장이 가능할 수도 있습니다. IE는 가장 관대하고 인기있는 브라우저였으며 Microsoft의 표준을 지속적으로 위장함으로써 나쁜 디자인을 장려하고 홍보하고 홍보하고 파손 된 페이지를 장려하고 홍보하는 데 악명 높아졌습니다.

지금은 일부 브라우저에서 이와 같은 기발한 및 악용을 사용하여 도망 갈 수 있지만 가끔 퍼즐이나 게임이나 무언가를 제외하고는 항상 고수해야합니다. 웹 표준 웹 페이지와 사이트를 작성하여 올바르게 표시되고 브라우저 업데이트를 통해 깨진 (완전히 무시 될 수 있음)를 피할 수 있습니다.

Question 17

브라우저는 일반적으로 유효한 지 여부에 관계없이 CSS를 HTML 태그와 관련 시키지만 절대적으로 수행해서는 안됩니다.

CSS 관점에서 기술적으로는 아무런 문제가 없습니다. 그러나 메이크업 태그를 사용하는 것은 HTML에서 절대로하지 말아야 할 일입니다.

HTML은 마크 업 언어이므로 각 태그가 특정 유형의 정보에 해당합니다.

구성 태그는 모든 유형의 정보에 해당하지 않습니다. 이렇게하면 Google과 같은 웹 크롤러의 문제가 발생합니다.

자세한 내용을 참조하십시오 올바른 마크 업의 중요성.

편집하다

DIV는 여러 관련 요소의 그룹을 의미하며, 블록 형태로 표시되어 조작 될 수 있습니다.

스팬은 현재있는 컨텍스트와는 다른 스타일의 요소를 의미하며 블록이 아닌 인라인으로 표시되어야합니다. 예를 들어 문장의 몇 마디가 모든 캡이어야하는 경우입니다.

사용자 정의 태그는 표준과 관련이 없으므로 SPAN/DIV를 대신 클래스/ID 속성과 함께 사용해야합니다.

거기 있습니다 매우 이에 대한 구체적인 면제 각도 JS

Question 18

CSS에는 "태그 선택기"라는 것이 있지만 실제로 태그가 무엇인지 알지 못합니다. 문서의 언어가 정의해야합니다. CSS는 HTML뿐만 아니라 XML과 함께 사용되도록 설계되었으며 (DTD 또는 기타 검증 체계를 사용하지 않는다고 가정) 태그는 거의 모든 것이 될 수 있습니다. "태그"및 "속성"과 같은 내용에 대한 정확한 의미에 대해 자신의 의미론을 제시해야하지만 다른 언어로도 사용할 수 있습니다.

브라우저는 일반적으로 HTML에서 알려지지 않은 태그에 CSS를 적용합니다. 이는 완전히 깨는 것보다 더 나은 것으로 간주되기 때문입니다. 적어도 무언가를 표시 할 수 있습니다. 하지만 그것은 매우 "가짜"태그를 고의적으로 사용하는 나쁜 관행. 그 이유 중 하나는 새 태그가 때때로 정의되기 때문입니다. 가짜 태그처럼 보이지만 같은 방식으로 작동하지 않으면 새 브라우저에서 사이트에 문제가 발생할 수 있습니다.

Question 19

CSS는 왜 가짜 요소와 함께 작동합니까? 어쨌든 사용해서는 안되기 때문에 아무도 해를 끼치 지 않기 때문입니다.

교수님이 왜 제가 메이크업 요소를 사용하기를 원하지 않습니까? 그 요소가 미래에 사양에 의해 정의되면 요소는 예측할 수없는 동작을 갖기 때문입니다.

또한 왜 그는 구성 요소가 존재하고 CSS와 협력한다는 것을 몰랐습니다. 그들은 드문 일입니까? 그는 대부분의 다른 웹 개발자들과 마찬가지로 앞으로 무작위로 깨질 수있는 것들을 사용해서는 안된다는 것을 이해하기 때문에 그는 이해하기 때문입니다.