iframe은 '나쁜 습관'으로 간주됩니까? [닫은]

어딘가에서 나는 iframe을 사용하는 것이 '나쁜 습관'이라는 개념을 선택했습니다.

이것이 사실입니까? 그것들을 사용하는 장단점은 무엇입니까?

모든 기술과 마찬가지로 기복이 있습니다. iframe을 사용하여 제대로 개발 된 사이트를 돌아 다니는 것은 물론 나쁜 습관입니다. 그러나 때때로 iframe이 허용됩니다.

iframe의 주요 문제 중 하나는 책갈피 및 탐색과 관련이 있습니다. 콘텐츠에 페이지를 단순히 포함시키기 위해 사용한다면 괜찮습니다. 그것이 iframe의 목적입니다.

그러나 iframe도 남용되는 것을 보았습니다. 사이트의 필수 부분으로 사용해서는 안되며 사이트 내에서 콘텐츠로 사용해서는 안됩니다.

일반적으로 iframe없이 할 수 있다면 더 좋은 옵션입니다. 나는 여기에 다른 사람들이 더 많은 정보 또는 더 구체적인 예를 가지고 있다고 확신합니다. 모두 해결하려는 문제로 귀착됩니다.

따라서 HTML로 제한되고 PHP 또는 ASP.NET 등과 같은 백엔드에 액세스 할 수없는 경우 iframe이 유일한 옵션 일 수 있습니다.

그들은 나쁜 습관이 아니며 단지 다른 도구 일뿐 아니라 유연성을 추가합니다.

표준 페이지 요소로 사용하기 위해서는 콘텐츠를 여러 페이지로 분리하는 간단하고 안정적인 방법이기 때문에 좋습니다. 특히 사용자가 생성 한 컨텐츠의 경우 내부 페이지를 iframe너무 빈약 한 마크 업 으로 "샌드 박스"하는 것이 기본 페이지에 영향을 미치지 않는 것이 좋습니다. 단점은 여러 계층의 스크롤 (브라우저 하나, 하나는 iframe) 을 도입하면 사용자가 좌절한다는 것입니다. adzm이 말했듯 iframe이 기본 탐색에는 을 사용하고 싶지 않지만 비디오 또는 다른 미디어 파일이 포함되는 방식과 동일한 텍스트 / 마크 업으로 생각하십시오.

백그라운드 이벤트 스크립팅의 경우 일반적으로 현재 페이지 의 숨겨진 컨텐츠 iframe와 XmlHttpRequest로드 할 컨텐츠 중 하나를 선택합니다. 차이점은 iframe페이지로드를 생성하므로 대부분의 브라우저에서 브라우저 캐시에서 앞뒤로 이동할 수 있다는 것입니다. XmlHttpRequest모든 곳에서 사용하는 Google은 iframe경우에 따라 s를 사용하여 사용자가 브라우저 기록에서 앞뒤로 이동할 수 있습니다.

단점을 이해하지 않고 사용하는 것은 '나쁜 습관'입니다. Adzm의 게시물은 그것들을 아주 잘 요약합니다.

반면에 Gmail은 자동 파일 업로드와 같은 더 멋진 기능을 위해 iFrame을 백그라운드에서 많이 사용합니다. iFrame의 한계를 알고 있다면 iFrame 사용에 대한 징계가 있다고 생각하지 않습니다.

많은 상황에서 그들과 함께 일한 결과, iframe은 goto 문과 동등한 웹 프로그래밍이라고 생각하게되었습니다. 즉, 일반적으로 피해야 할 것입니다. 사이트 내에서는 다소 유용 할 수 있습니다. 그러나 교차 사이트는 거의 항상 가장 단순한 콘텐츠를 제외하고는 나쁜 생각입니다.

가능성을 고려하십시오 ... 매개 변수화 된 컨텐츠에 사용되는 경우 인터페이스를 작성했습니다. 그리고 전문 사이트에서이 인터페이스에는 SLA 및 버전 관리가 필요합니다.이 인터페이스는 거의 항상 온라인에 접속하기 위해 무시됩니다.

활성 컨텐츠 (스크립트를 호스팅하는 프레임)에 사용되는 경우 (다른) 도메인 간 스크립트 제한 사항이 있습니다. 일부는 해킹 당할 수 있지만 거의 일관성이 없습니다. 그리고 프레임 컨텐츠가 인터랙티브해야 할 필요가 있다면 프레임을 넘어서는 것이 힘들 것입니다.

라이센스가 부여 된 컨텐츠와 함께 사용되는 경우 참여 사이트는 자격 정보를 호스트간에 대역 외로 이동해야합니다.

따라서 사이트 내에서 가끔 유용하지만 매쉬업에는 적합하지 않습니다. 실제 포털과 포틀릿을 보는 것이 훨씬 좋습니다. 더 나쁜 것은, 그들은 모든 웹 아마추어의 사랑입니다-많은 기술 관리자가 많은 문제에 대한 해결책으로 그들을 체포했습니다. 사실, 그들은 더 많은 것을 만듭니다.

내 경험에 따르면 iframe 의 긍정적 인 측면 은 타사 코드를 호출 할 때 Document.write();명령 이있는 자바 스크립트를 호출하는 것과 관련이 있습니다 . 아시다시피, 이러한 명령은 구문 분석 방식 (DOM 파서 등)으로 인해 비동기 적으로 호출 될 수 없습니다. 이에 대한 예는 http://sourceforge.net/projects/phpadsnew/ 입니다 . ipads를 사용하여 phpadsnews를 여러 번 호출하고 사이트가 다른 렌더링을 진행하기 전에 응답을 기다리는 동안 사이트 속도를 높이는 데 도움이되었습니다. 페이지의 일부. iframe을 사용하면 사이트에서 페이지의 다른 부분을 렌더링하고 Document.write()phpads 명령을 비동기식으로 호출 할 수 있었습니다. js 잠금 방지 및.

iframe 사람들에게는 분명히 사용됩니다. 날씨 네트워크 위젯을 페이지에 어떻게 추가 하시겠습니까? 유일한 다른 방법은 XML을 가져와 구문 분석하는 것이지만, 물론 적절한 날씨 그래픽을 버릴 수있는 조건이 필요합니다 ... 실제로 가치가 없지만 시간이 있으면 더 깨끗합니다.

원래 프레임 세트 모델 (프레임 세트 및 프레임 요소)은 사용성 측면에서 매우 나빴습니다. IFrame은 원래 프레임 세트 모델만큼 많은 문제가 없었지만 단점이있는 나중의 발명품입니다.

사용자가 IFrame 내부를 탐색하도록 허용하면 링크 및 책갈피가 예상대로 작동하지 않습니다 (iframe의 URL이 아닌 외부 페이지의 URL을 책갈피로 지정하기 때문에).

기본 페이지가 HTTP 프로토콜로로드되고 페이지의 일부가 HTTPS 프로토콜에서 작동해야하는 경우 iFrame이 jsonp 핸드 다운을 이길 수 있습니다.

특히 dataType이 기본적으로 json이 아니고 서버에서 json으로 변환되고 클라이언트에서 다시 복잡한 HTML로 변환되어야하는 경우.

따라서 iFrame은 악이 아닙니다.

그들은 나쁘지 않지만 실제로 도움이됩니다. 얼마 전 트위터 피드를 임베드 해야하는 큰 문제가 있었는데 md가 동일한 페이지에 md를 허용하지 않으므로 다른 페이지에 설정하여 iframe으로 넣었습니다.

또한 모든 브라우저 (및 전화 브라우저)가 지원하기 때문에 좋습니다. 올바르게 사용하는 한 나쁜 습관으로 간주 될 수 없습니다.

사용자의 인터넷 연결 속도 나 iframe의 내용에 관계없이 iframe이 약간 (0.3 초 ​​정도) 느리지 만 페이지 다운로드 속도가 눈에 띄게 느려질 수 있습니다. 로컬에서 테스트 할 때 볼 수있는 것은 아닙니다. 실제로 이것은 페이지에 추가 된 모든 요소에 해당되지만 iframe은 더 나빠 보입니다.

IFRAME이 동적 컨텍스트 메뉴를 만드는 쉬운 방법으로 매우 성공적으로 적용되는 것을 보았지만 해당 웹 응용 프로그램의 대상 독자는 Internet Explorer 사용자였습니다.

나는 그것이 당신의 요구 사항에 달려 있다고 말합니다. 모든 브라우저에서 페이지가 동일하게 작동하도록하려면 IFRAME을 피하십시오. 좁고 잘 알려진 대상 (예 : 로컬 인트라넷)을 대상으로하고 IFRAME을 사용하면 이점이 있다면 그렇게해도 괜찮습니다.