다른 프로그래머가 다른 날 질문을 받았습니다. 나는 아주 오래 전에 궁금했던 것을 아주 오래 전 기억합니다. 브라우저 측 포함 태그가 고려되지 않은 이유는 무엇입니까? 아니면?
특히 브라우저에 다른 소스의 추가 HTML을 포함하도록 지시 한 태그가 있습니다. 예 <include src="http://server/foo/bar.html">. 많은 사람들이 innerHTML자바 스크립트 엔진 외부에서 브라우저로 동일한 것을 달성 할 수있을 때, 자바 스크립트 호출을하고 이를 달성하기 위해 채 웁니다 .
그것은 고통스러운했을 중첩 된 것으로 <HTML>의 <BODY>의 (예)하지만 우리는 어디 어쨌든 측면을 고려해야합니다.
답변
( Netscape 4 전용 ) layer및 ilayer태그 를 기억하는 지구상에서 마지막 사람 입니까?
넷스케이프 4도 허용div 태그가 가지고 src같은 일을 수행 속성을.
넷스케이프는 W3C에 제출했는데, 이들은 W3C에 포함시키지 않기로했다 iframe.
답변
브라우저 측 포함 태그가 고려되지 않은 이유는 무엇입니까? 아니면?
서버 측 포함을 아직 해결하지 않은 모든 초보자 웹 작성자는 www-html 목록에서 초기에 다시 요청했습니다. 그러나 그 당시 W3는 웹 작가의 압력을 완전히 무시하게되어 기뻤습니다.
사이트 간 포함이 허용되면 보안 재해가됩니다. 사용자의 은행에서 페이지를 가져 와서 내용을 읽을 수 있습니다. (원래 DOM 스크립팅은 제한되었지만 대상 페이지에 의해 삭제 된 스크립팅 함수 document.links등에서 계속 읽을 수있었습니다 document.images. 그 이후로 가져온 컨텐츠로 원하는 작업을 수행 할 수 있습니다.)
교차 사이트 포함이 허용되지 않은 경우 …이 기능은 서버 측 포함에 비해 이점이 없습니다. 서버가 더 잘 처리 할 수 있도록 클라이언트의 작업 속도가 더 느려질 것입니다. 와 달리 <iframe>포함은 페이지로드를 차단해야합니다. SSI는 모든면에서 우수 할 것입니다.
답변
그들은했다. <frameset>태그 가되었습니다 . 얼마 후 그들은 <iframe>태그 를 추가했습니다 .
초기 웹 서버의 대부분은 서버 측 포함을 지원 했으므로 동일한 기능을 프레임에서도 사용할 수 있다는 점에서 클라이언트 측 텍스트 포함은 필요하지 않은 것으로 생각되었습니다.
답변
개체는 여전히 프레임에서 렌더링되며 “데이터”에 대한 DOM 액세스 권한이 없습니다. 몇 년 전에 개발자에게 제공된 것은 간단한 태그로 스 니펫을 포함시키는 방법입니다. 이 태그에 도메인 샌드 박스 제한이 있더라도 기능을 구획화하고 유지 관리를 개선하며 브라우저 캐싱을 활용하는 것이 매우 유용합니다.
이 작업을 수행하는 좋은 jquery 플러그인과 서버 측 스크립트가 많이 있다는 것을 알고 있지만 그러한 태그를 지원하지 않는 이유는 없습니다. IMO의 좋은 질문은 “클라이언트 측 포함 태그가없는 이유는 무엇입니까?”
jquery를 좋아한다면 좋은 클라이언트 측 include 스크립트가 있습니다 : inc : 매우 작은 클라이언트 측 include JavaScript jQuery 플러그인
답변
당신이 시도 했습니까
<object type="text/html" data="page.html" height="500" width="500">
What I see if that didn't work
</object>나는 그것이 대부분의 브라우저에서 구현되었다고 생각합니다.