내 응용 프로그램을 XHTML strict 모드 (이전에는 DOCTYPE이 없었 음)로 변환하는 중입니다. 그러나 offsetHeight/offsetWidth를 가져올 때 큰 저하가 있음을 확인했습니다. 이것은 많은 DOM 요소가있는 페이지에서 매우 눈에,니다. 1 열 x 800 행의 표가 있다고 가정 해 봅시다. 셀에는 텍스트 조각 만 있습니다. 해당 테이블의 각 자손 요소를 방문하여 오프셋 치수를 얻는 것은 IE가 페이지를 Quirks 모드로 렌더링 할 때보 다 느립니다. 왜 그런 경우입니까? 아무도 IE가 offsetValues를 계산하는 데 도움이되는 팁을 알고 있습니까?IE 8 Quirks vs 표준 검색 offsetHeight/offsetWidth
IE가 강제로 표준 모드에서 페이지를 렌더링하지 않을 것을 제안합니다. HTML 문서의 머리 부분에 메타 태그를 추가하거나 X-UA 호환 헤더를 추가하도록 웹 서버를 설정하면됩니다. 또한
<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4" />
사용 내장 등등 JQuery와, 프로토 타입, 유이, 같은 자바 스크립트 프레임 워크, 대부분은 이미 다른 렌더링 엔진에 문제를 해결 그들을합니다.
프레임 워크가 많은 도움이된다는 데 동의합니다. 나는 최근에 프로젝트에서 IE 8이 잘못된'$(). outerHeight()'를 여전히보고했다는 것을 주목했다. 그것은 나를 미치게했다! IE가 요소의 크기를 조정하는 동안 높이를 잡으려고하는 것 같았 기 때문에 동기화를 구현해야했습니다. 이것은 IE 8에서만 문제 였기 때문에 추적하는 데 약간의 시간이 걸렸습니다. –
내 문제는 표준 모드에서 렌더링 할 수 없습니다. 내 페이지가 표준 모드에서 렌더링되면 문제가 발생합니다. 사실 문제를 한 줄의 코드로 분리했습니다. 문제가되는 행은 다음과 같습니다. element.absoluteHeight=element.offsetHeight; 브라우저 리플 로우에 대해 많은 내용을 읽었으므로 문제가 발생한 오프셋 치수가 잘못 나온 것으로 잘못 생각했습니다. 그러나 일단이 줄을 깨면 DOM 요소의 속성을 설정하면 단점과 IE8 표준 모드간에 성능 차이가 커지고 후자의 모드가 훨씬 나빠집니다. –
Paul
@Paul : 대답 할 수 있습니까? 이것을 재현 할 수 있습니다 : offsetDimensions를 읽는 것을 포함하여 대부분의 작업이 IE8 표준 모드에서 훨씬 빠릅니다. 그러나 확장은 느립니다. – bobince
@bobince : 제가 생각하는 문제는 리플 로우입니다. 내 JavaScript의 논리는 절대 레이아웃 컨테이너에서 자식들이 서로 겹치고 있는지 (예측할 수없는 동적 콘텐츠를 얻었 기 때문에) 파악한 다음 부모의 css 크기와 sibbling의 css를 조정하려고 시도합니다. css 크기를 변경하면 리플 로우가 발생하고 반복 작업이 반복되는데,이 시나리오는 매우 큰 테이블의 IE8 Quirks보다 IE8 표준에서 훨씬 느립니다. 이 유형의 작업을 수행 할 때 documentFragment를 숨기거나 사용해야한다는 것을 알고 있습니다. 그러나 이동해야 할 항목이 필요하고 부정확 한 값을 가져 오는 새 오프셋 치수를 살펴야하기 때문에.
이 것을 보여주기위한 샘플이 있습니까? – lincolnk