JavaScript는 스타일 속성을 정확하게 얻습니다(1부)_javascript 기술
- WBOY원래의
- 2016-05-16 18:37:21832검색
JQuery, mootools, Ext 및 기타 클래스 라이브러리는 이 부분에서 구현하기가 매우 어렵습니다. 복잡한 메소드를 많이 사용하므로 이 부분을 추출하는 것이 매우 어렵습니다. 축적된 CSS 지식을 바탕으로 구현에 대한 심층적인 연구 끝에 마침내 매우 간결한 버전을 만들었습니다. JQuery.cssCur와 동일하지만 더 많은 기능을 가지고 있을 수도 있습니다. 케이터링 업계에 따르면 "가격을 올리지 않고 양을 늘리십시오"라고 합니다. 내 것은 "양을 늘리되 가격을 낮추십시오"라고 할 수 있습니다. 버전은 아직 베타 단계입니다. 유틸리티 기능이 클래스로 만들어지지 않은 유일한 버전이기 때문입니다.
코드 복사 코드는 다음과 같습니다.
var getStyle = function(el, style) {
if(! "v1"){
style = style.replace(/-(w)/g, function(all, letter){
return letter.toUpperCase();
} );
return el.currentStyle[style];
}else{
return document.defaultView.getCompulatedStyle(el, null).getPropertyValue(style)
}
}
사용된 값은 W3C 사람들이 만든 것이기 때문에 document.defaultView.getCompulatedStyle은 기본적으로 이동하지 않고 문제의 99%를 해결합니다. IE는 더 복잡합니다. Microsoft가 스타일, currentStyle 및 RuntimeStyle을 개발했지만 아직 getCompulatedStyle과 유사한 구현이 없습니다. 가장 가까운 것은 내부 스타일만 가져올 수 있는 currentStyle이며 값을 가져올 때 CSS를 사용해야 합니다. 속성을 camelCase 스타일로 변환합니다. 편의상 지금은 분리하겠습니다.
코드 복사 코드는 다음과 같습니다.
var camelize = function(attr){
return attr.replace(/-(w)/g, function(all, letter){
return letter.toUpperCase();
})
}
따라가 보겠습니다. IE의 투명성 문제를 해결하기 위해 기본적으로 모든 주요 라이브러리에서 이 문제가 얼마나 어려운지 보여줍니다. Microsoft의 천재들에게 정말 감사드리고 싶습니다.
코드 복사 코드는 다음과 같습니다.
var getIEOpacity = function(el){
var filter
if(!!window .XDomainRequest){
filter = el.style.filter.match(/progid:DXImageTransform.Microsoft.Alpha(.?opacity=(.*).?)/i)
}else{
filter = el.style.filter.match(/alpha(opacity=(.*))/i);
}
if(filter){
var value = parseFloat(filter[1]);
if (!isNaN( value)) {
반환 값 ? value / 100 : 0
}
}
return 1; >이때 우리 함수는 다음과 같습니다.
코드 복사
코드는 다음과 같습니다. var getStyle = function(el, style) { if(! "v1"){
if(style == "opacity"){ return getIEOpacity(el)
}
return el.currentStyle[camelize(style)] ;
}else{
return document.defaultView.getCompulatedStyle(el, null).getPropertyValue(style)
}
}
그런 다음 float 속성 문제가 발생합니다. IE는 styleFloat이고 W3C는 cssFloat입니다. 해결책은 문제가 없지만, Ext 구현을 기반으로 매번 변환하기에는 너무 번거롭습니다.
}
return el.currentStyle[camelize(style)] ;
}else{
return document.defaultView.getCompulatedStyle(el, null).getPropertyValue(style)
}
}
그런 다음 float 속성 문제가 발생합니다. IE는 styleFloat이고 W3C는 cssFloat입니다. 해결책은 문제가 없지만, Ext 구현을 기반으로 매번 변환하기에는 너무 번거롭습니다.
코드 복사
코드는 다음과 같습니다. var propCache = []; var propFloat = ! "v1" ? 'styleFloat' : 'cssFloat'; var camelize = function(attr){
return attr.replace(/-(w)/g, function(all, letter) return letter.toUpperCase();
});
}
var memorize = function(prop) { //의미: 양식 캐시 확인
return propCache[prop] || propCache[ prop] = prop == 'float' ? propFloat : camelize(prop))
var getIEOpacity = function(el){
//********** ** ***************************
}
var getStyle = 함수(el, 스타일){
if ( ! "v1"){
if(style == "opacity"){
return getIEOpacity(el)
}
return el.currentStyle[memorize(style)]
} else {
if(style == "float"){
style = propFloat;
}
return document.defaultView.getCompulatedStyle(el, null).getPropertyValue(style)
}
}
이제 어려운 부분이 다가옵니다. 높이와 너비를 정확하게 구하는 것입니다. JQuery를 사용해 본 사람이라면 John Resig가 이 두 속성을 별도로 처리한다는 것을 알고 있을 것입니다. 사실 JQuery뿐만 아니라 다른 라이브러리에도 이러한 문제가 있습니다. 문제의 원인은 이 두 속성을 명시적으로 설정할 수 있는 인라인 스타일이나 내부 스타일이 없으면 IE에서 정확한 값을 얻을 수 없거나 백분율, 빈 문자열, 자동, 상속, 등등, 뭔가 무력합니다. 게다가 중국인들에게 있어서 px의 위상은 em보다 훨씬 높습니다. 우리가 이 두 가지 속성을 포기할 수 없는 데는 다 이유가 있습니다. 이 두 속성의 정확한 값을 얻으려면 CSS 상속 문제를 연구해야 합니다. 이 문제에 대해 논의하기 위해 관련 블로그 게시물 "CSS Inhert and Auto"도 작성했습니다. 아직 읽지 않으신 분들은 읽으신 후 다시 방문해 주시기 바랍니다.
CSS 분류에 따르면 width와 height는 상속되지 않는 속성이므로 값을 설정하지 않으면 기본값은 auto인 것을 알 수 있습니다. 이 자동은 블록 요소인 경우 너비가 100%와 동일하며 부모 요소의 콘텐츠 영역을 채웁니다. 물론 이는 패딩, 테두리 및 여백을 고려하지 않은 것입니다. 인라인 요소인 경우 박스 모델이 없기 때문에 너비와 높이를 설정하는 것은 의미가 없습니다. Firefox에서도 반환된 변환의 정확한 값이 표시되는 것과 완전히 일치하지 않습니다. 설정하지 않고 바로 자동으로 돌아갑니다. px 단위의 정확한 값을 얻으려면 블록 요소와 인라인 요소를 차단하기 위해 생각을 바꿔야 하지만 CSS 속성에만 집중해야 합니다. 이때 Microsoft는 좋은 일을 하여 offsetXX, clientXX 및 scrollXX의 세 가지 주요 제품군을 개발했으며 이제 마침내 W3C 표준에 포함되었습니다. 그러나 그 오래 전에 브라우저는 이미 이를 따랐습니다.
표준 모드에서 offsetWidth에는 패딩, borderWidth 및 너비가 포함됩니다. 스크롤 막대가 있는 경우 해당 offsetWidth는 각 브라우저에서 매우 일관되게 17px입니다. 너비에서 17px를 선택하고 스크롤 막대를 사용하여 누락된 공간을 채웁니다. offsetWidth 패딩과 패딩이 존재하는 경우 패딩과 패딩을 빼야 합니다. 쿼크 모드에서 offsetWidth는 너비와 같고 너비에는 패딩과 borderWidth가 포함됩니다. offsetHeight에도 동일하게 적용됩니다. clientXX 제품군은 이해하기 쉽지만 borderWidth 및 스크롤 막대가 포함되어 있지 않습니다. scrollXX 계열은 말할 것도 없고, 5개 주요 브라우저에서 일관성이 없습니다. 따라서 표준 모드에서는 높이와 너비를 얻으려면 clientXX 계열이 선호되고, 쿼크 모드에서는 offsetXX 계열이 먼저 선호됩니다.
지금은 quirk 모드에 대해 이야기해야 합니다. IE8로 업그레이드하고 해당 DocType을 설정하면 웹 페이지에서 그렇지 않은 부분이 너무 많기 때문에 재난을 피할 수 있다고 생각하지 마십시오. 표준에 따라 작성되면 IE도 호환 모드로 전환됩니다. IE8에는 IE5 쿼크 모드, IE7 표준 모드, IE8 거의 표준 모드, IE7 호환 모드 및 HTML5를 지원하는 엣지 모드 등 5가지 렌더링 모드가 있기 때문에 이 호환성 모드가 쿼크 모드와 같은지 여부는 의문스럽습니다. 모드가 이렇게 많은데 document.compatMode == "CSS1Compat"만으로 살아남을 수 있다고 생각하시나요? ! 참을 수가 없네요. 새로운 모드를 추가하면서 IE8에서는 document.documentMode 속성도 추가했습니다. 따라서 쿼크 모드에서 실행 중인지 확인하는 코드는 다음과 같습니다.
http://www.mangguo.org/x-ua- Compatible-ie8- Compatible-mode/
var isQuirk = (document.documentMode) ? (document.documentMode==5) ? :
false : ( (document.compatMode=="CSS1Compat") ? false : true)
따라서 다음과 같은 의사코드가 있습니다:
var getWidth = function(el){
if(isQuirk){
return el.offsetWidth
}else{
return el.clientWidth -parseFloat(getStyle(el, "padding-left"))-parseFloat(getStyle(el, "padding-right"))
}
}
Ext 구현 비교(핵심 부분만 잘림):
getWidth : function(contentWidth){
var me = this,
dom = me.dom,
w = MATH.max (dom.offsetWidth, dom.clientWidth) || 0;
w = !contentWidth ? w : w - me.getBorderWidth("lr") - me.getPadding("lr"); 0 ? 0 : w;
},
Prototype의 구현보다 더 나빠서 다른 부분에서 수정할 수 없는 매우 위험한 접근 방식이므로 UI의 크기가 너무 큽니다. 또한 측면에서 뛰어난 JQuery 구현 방법을 강조합니다. 그러나 JQuery의 구현도 상당히 복잡합니다. 이 요소의 정확한 값을 얻을 수 없으면 상위 요소부터 시작해야 합니다. 이 순회에는 많은 비용이 소요됩니다. 또한 Dean Edwards로부터 훌륭한 해킹을 빌렸습니다.
var ConvertPixelValue = function(el, value){
var style = el.style,left = style.left,rsLeft = el.runtimeStyle.left
el.runtimeStyle.left = el.currentStyle.left; ;
style.left = 값 || 0;
style.left =
rsLeft; 🎜> }
//이 기능은 Dean Edwards에서 제공하며, 최초 소스는 아래 링크에서 확인할 수 있습니다
// http://erik.eae.net/archives/2007/07/27/18.54 .15/#comment-102291
//두 번째 매개변수는 em', 'ex', 'cm', 'mm', 'in', 'pt'와 같은 단위의 숫자 값이어야 합니다. , 'pc'
//Percentage 문제가 있는 것 같습니다
//또한 IE 이외의 브라우저에서는 사용하지 마세요
//사용법: ConvertPixelValue($("drag4") ,'10em')
var ConvertPixelValue = function(el, styleVal ){
//원래 값을 왼쪽 및 rsLeft에 저장
var style = el.style,left = style.left,rsLeft = el.runtimeStyle.left;
//다음 단계가 핵심입니다.
// el.currentStyle.left를 el.runtimeStyle.left로 대체하여 해킹을 활성화합니다.
el.runtimeStyle.left = el .currentStyle.left; 픽셀이 아닌 단위 값을 스타일 .left로 대체합니다(예: 10em).
style.left = styleVal || 0//style.pixelLeft를 사용하세요. 그렇지 않으면 값이 부정확해집니다.
//style.pixelLeft를 사용하면 160이 되고, style.left를 사용하면 150px가 됩니다.
//모든 것이 변환된 경우 style.left는 부정확하다.
var px = style.pixelLeft;
style.left = left;//데이터 복원
el.runtimeStyle.left = rsLeft;//데이터 복원
return px; >
이 핵은 물론 백분율을 제외하고 em, pc, pt, cm, in, ex 및 기타 단위를 px로 변환하는 데 사용됩니다.
돌아와서 내 getWidth 함수를 살펴보세요. 주요 문제는 padding-left 및 padding-right 값을 가져오는 것입니다. 표준 브라우저에서는 getCompulatedStyle을 사용하여 변환된 정확한 값을 px 단위로 쉽게 얻을 수 있습니다. IE에서는 2em의 값을 주면 2em을 반환하는데 이는 게으르다. "CSS의 상속 및 자동" 기사에서 나는 또한 패딩이 상속되지 않는 속성임을 지적했습니다. 즉, 자동 목록에서 상속의 무의미한 값을 처리할 필요가 없으며 패딩이 나열되지 않는다는 것을 의미합니다. auto의 퍼지 값을 처리할 필요성을 줄입니다. 또한 이는 측정 가능한 단위이며 각 브라우저는 기본값을 0px로 설정할 만큼 친절합니다. 값의 단위가 px가 아닌 경우 px로 변환합니다. 우리는 Dean Edwards의 해킹을 기본 기능인 getStyle에 통합했습니다. padding-left가 백분율인 경우 상위 요소의 너비에 백분율을 곱하면 됩니다. 전체적으로 통과하는 레벨 수와 계산 수가 최소화됩니다. 이런 점에서 이 측면을 처리하는 것이 JQuery의 처리보다 훨씬 낫습니다(JQuery에는 계산 범위에 테두리와 여백도 포함되지만 IE에서는 테두리와 여백에 퍼지 값이 있어서 JQuery가 상위 값을 계산하도록 강제합니다). 즉, 요소는 상위 속성을 5번까지 다시 계산해야 하며 이상한 모드에서는 한 번만 필요합니다. 때로는 IE에서 얻은 값이 getCompulatedStyle을 사용하는 Firefox보다 더 정확할 수 있습니다(단, 너무 정확한 것 같으므로 정확도를 직접 조정하려면 toFixed를 사용하세요).
코드 복사
코드는 다음과 같습니다.
});
}
var memorize = function(prop) { //의미: 양식 캐시 확인
return propCache[prop] || propCache[ prop] = prop == 'float' ? propFloat : camelize(prop))
var getIEOpacity = function(el){
//********** ** ***************************
}
var getStyle = 함수(el, 스타일){
if ( ! "v1"){
if(style == "opacity"){
return getIEOpacity(el)
}
return el.currentStyle[memorize(style)]
} else {
if(style == "float"){
style = propFloat;
}
return document.defaultView.getCompulatedStyle(el, null).getPropertyValue(style)
}
}
이제 어려운 부분이 다가옵니다. 높이와 너비를 정확하게 구하는 것입니다. JQuery를 사용해 본 사람이라면 John Resig가 이 두 속성을 별도로 처리한다는 것을 알고 있을 것입니다. 사실 JQuery뿐만 아니라 다른 라이브러리에도 이러한 문제가 있습니다. 문제의 원인은 이 두 속성을 명시적으로 설정할 수 있는 인라인 스타일이나 내부 스타일이 없으면 IE에서 정확한 값을 얻을 수 없거나 백분율, 빈 문자열, 자동, 상속, 등등, 뭔가 무력합니다. 게다가 중국인들에게 있어서 px의 위상은 em보다 훨씬 높습니다. 우리가 이 두 가지 속성을 포기할 수 없는 데는 다 이유가 있습니다. 이 두 속성의 정확한 값을 얻으려면 CSS 상속 문제를 연구해야 합니다. 이 문제에 대해 논의하기 위해 관련 블로그 게시물 "CSS Inhert and Auto"도 작성했습니다. 아직 읽지 않으신 분들은 읽으신 후 다시 방문해 주시기 바랍니다.
CSS 분류에 따르면 width와 height는 상속되지 않는 속성이므로 값을 설정하지 않으면 기본값은 auto인 것을 알 수 있습니다. 이 자동은 블록 요소인 경우 너비가 100%와 동일하며 부모 요소의 콘텐츠 영역을 채웁니다. 물론 이는 패딩, 테두리 및 여백을 고려하지 않은 것입니다. 인라인 요소인 경우 박스 모델이 없기 때문에 너비와 높이를 설정하는 것은 의미가 없습니다. Firefox에서도 반환된 변환의 정확한 값이 표시되는 것과 완전히 일치하지 않습니다. 설정하지 않고 바로 자동으로 돌아갑니다. px 단위의 정확한 값을 얻으려면 블록 요소와 인라인 요소를 차단하기 위해 생각을 바꿔야 하지만 CSS 속성에만 집중해야 합니다. 이때 Microsoft는 좋은 일을 하여 offsetXX, clientXX 및 scrollXX의 세 가지 주요 제품군을 개발했으며 이제 마침내 W3C 표준에 포함되었습니다. 그러나 그 오래 전에 브라우저는 이미 이를 따랐습니다.
표준 모드에서 offsetWidth에는 패딩, borderWidth 및 너비가 포함됩니다. 스크롤 막대가 있는 경우 해당 offsetWidth는 각 브라우저에서 매우 일관되게 17px입니다. 너비에서 17px를 선택하고 스크롤 막대를 사용하여 누락된 공간을 채웁니다. offsetWidth 패딩과 패딩이 존재하는 경우 패딩과 패딩을 빼야 합니다. 쿼크 모드에서 offsetWidth는 너비와 같고 너비에는 패딩과 borderWidth가 포함됩니다. offsetHeight에도 동일하게 적용됩니다. clientXX 제품군은 이해하기 쉽지만 borderWidth 및 스크롤 막대가 포함되어 있지 않습니다. scrollXX 계열은 말할 것도 없고, 5개 주요 브라우저에서 일관성이 없습니다. 따라서 표준 모드에서는 높이와 너비를 얻으려면 clientXX 계열이 선호되고, 쿼크 모드에서는 offsetXX 계열이 먼저 선호됩니다.
지금은 quirk 모드에 대해 이야기해야 합니다. IE8로 업그레이드하고 해당 DocType을 설정하면 웹 페이지에서 그렇지 않은 부분이 너무 많기 때문에 재난을 피할 수 있다고 생각하지 마십시오. 표준에 따라 작성되면 IE도 호환 모드로 전환됩니다. IE8에는 IE5 쿼크 모드, IE7 표준 모드, IE8 거의 표준 모드, IE7 호환 모드 및 HTML5를 지원하는 엣지 모드 등 5가지 렌더링 모드가 있기 때문에 이 호환성 모드가 쿼크 모드와 같은지 여부는 의문스럽습니다. 모드가 이렇게 많은데 document.compatMode == "CSS1Compat"만으로 살아남을 수 있다고 생각하시나요? ! 참을 수가 없네요. 새로운 모드를 추가하면서 IE8에서는 document.documentMode 속성도 추가했습니다. 따라서 쿼크 모드에서 실행 중인지 확인하는 코드는 다음과 같습니다.
http://www.mangguo.org/x-ua- Compatible-ie8- Compatible-mode/
코드 복사 코드는 다음과 같습니다.
var isQuirk = (document.documentMode) ? (document.documentMode==5) ? :
false : ( (document.compatMode=="CSS1Compat") ? false : true)
따라서 다음과 같은 의사코드가 있습니다:
코드 복사 코드는 다음과 같습니다:
var getWidth = function(el){
if(isQuirk){
return el.offsetWidth
}else{
return el.clientWidth -parseFloat(getStyle(el, "padding-left"))-parseFloat(getStyle(el, "padding-right"))
}
}
Ext 구현 비교(핵심 부분만 잘림):
코드 복사 코드는 다음과 같습니다.
getWidth : function(contentWidth){
var me = this,
dom = me.dom,
w = MATH.max (dom.offsetWidth, dom.clientWidth) || 0;
w = !contentWidth ? w : w - me.getBorderWidth("lr") - me.getPadding("lr"); 0 ? 0 : w;
},
Prototype의 구현보다 더 나빠서 다른 부분에서 수정할 수 없는 매우 위험한 접근 방식이므로 UI의 크기가 너무 큽니다. 또한 측면에서 뛰어난 JQuery 구현 방법을 강조합니다. 그러나 JQuery의 구현도 상당히 복잡합니다. 이 요소의 정확한 값을 얻을 수 없으면 상위 요소부터 시작해야 합니다. 이 순회에는 많은 비용이 소요됩니다. 또한 Dean Edwards로부터 훌륭한 해킹을 빌렸습니다.
코드 복사 코드는 다음과 같습니다.
var ConvertPixelValue = function(el, value){
var style = el.style,left = style.left,rsLeft = el.runtimeStyle.left
el.runtimeStyle.left = el.currentStyle.left; ;
style.left = 값 || 0;
style.left =
rsLeft; 🎜> }
//이 기능은 Dean Edwards에서 제공하며, 최초 소스는 아래 링크에서 확인할 수 있습니다
// http://erik.eae.net/archives/2007/07/27/18.54 .15/#comment-102291
//두 번째 매개변수는 em', 'ex', 'cm', 'mm', 'in', 'pt'와 같은 단위의 숫자 값이어야 합니다. , 'pc'
//Percentage 문제가 있는 것 같습니다
//또한 IE 이외의 브라우저에서는 사용하지 마세요
//사용법: ConvertPixelValue($("drag4") ,'10em')
var ConvertPixelValue = function(el, styleVal ){
//원래 값을 왼쪽 및 rsLeft에 저장
var style = el.style,left = style.left,rsLeft = el.runtimeStyle.left;
//다음 단계가 핵심입니다.
// el.currentStyle.left를 el.runtimeStyle.left로 대체하여 해킹을 활성화합니다.
el.runtimeStyle.left = el .currentStyle.left; 픽셀이 아닌 단위 값을 스타일 .left로 대체합니다(예: 10em).
style.left = styleVal || 0//style.pixelLeft를 사용하세요. 그렇지 않으면 값이 부정확해집니다.
//style.pixelLeft를 사용하면 160이 되고, style.left를 사용하면 150px가 됩니다.
//모든 것이 변환된 경우 style.left는 부정확하다.
var px = style.pixelLeft;
style.left = left;//데이터 복원
el.runtimeStyle.left = rsLeft;//데이터 복원
return px; >
이 핵은 물론 백분율을 제외하고 em, pc, pt, cm, in, ex 및 기타 단위를 px로 변환하는 데 사용됩니다.
돌아와서 내 getWidth 함수를 살펴보세요. 주요 문제는 padding-left 및 padding-right 값을 가져오는 것입니다. 표준 브라우저에서는 getCompulatedStyle을 사용하여 변환된 정확한 값을 px 단위로 쉽게 얻을 수 있습니다. IE에서는 2em의 값을 주면 2em을 반환하는데 이는 게으르다. "CSS의 상속 및 자동" 기사에서 나는 또한 패딩이 상속되지 않는 속성임을 지적했습니다. 즉, 자동 목록에서 상속의 무의미한 값을 처리할 필요가 없으며 패딩이 나열되지 않는다는 것을 의미합니다. auto의 퍼지 값을 처리할 필요성을 줄입니다. 또한 이는 측정 가능한 단위이며 각 브라우저는 기본값을 0px로 설정할 만큼 친절합니다. 값의 단위가 px가 아닌 경우 px로 변환합니다. 우리는 Dean Edwards의 해킹을 기본 기능인 getStyle에 통합했습니다. padding-left가 백분율인 경우 상위 요소의 너비에 백분율을 곱하면 됩니다. 전체적으로 통과하는 레벨 수와 계산 수가 최소화됩니다. 이런 점에서 이 측면을 처리하는 것이 JQuery의 처리보다 훨씬 낫습니다(JQuery에는 계산 범위에 테두리와 여백도 포함되지만 IE에서는 테두리와 여백에 퍼지 값이 있어서 JQuery가 상위 값을 계산하도록 강제합니다). 즉, 요소는 상위 속성을 5번까지 다시 계산해야 하며 이상한 모드에서는 한 번만 필요합니다. 때로는 IE에서 얻은 값이 getCompulatedStyle을 사용하는 Firefox보다 더 정확할 수 있습니다(단, 너무 정확한 것 같으므로 정확도를 직접 조정하려면 toFixed를 사용하세요).
코드는 다음과 같습니다.
var getStyle = function(el, style) { if(! "v1"){ if(style == "opacity"){ return getIEOpacity(el) }
var value = el.currentStyle[memorize(style )]; if (/^(height|width)$/.test(style)){
var 값 = (style == 'width') ? ['left', 'right'] : ['top' , 'bottom'], size = 0;
if(isQuirk){
return el[camelize("offset-" style)]
}else{
var client = parseFloat(el[camelize ("client-" 스타일)]),
paddingA = parseFloat(getStyle(el, "padding-" 값[0])),
paddingB = parseFloat(getStyle(el, "padding) -" 값[1 ]));
return (클라이언트 - paddingA - paddingB) "px";
}
}
if(!/^d px$/.test(value)) {
/ /측정 가능한 값 변환
if(/(em|pt|mm|cm|pc|in|ex|rem|vw|vh|vm|ch|gr)$/.test(value)) {
return ConvertPixelValue(el,value);
}
//전환율
if(/%/.test(value)){
return parsFloat(getStyle(el.parentNode, "너비" )) * parsFloat(값) /100 "px"
}
}
반환 값;//예: 0px
}else{
if(style == "float "){
style = propFloat;
}
return document.defaultView.getCompulatedStyle(el, null).getPropertyValue(style)
}
}
说多无谓，我们测试一下吧。
window.onload = function(){
alert(getStyle(_("text"),"width"))
alert(getStyle(_("text2"),'width'))
alert(getStyle(_("text2"),'padding-left'))
};
[Ctrl+A 全选 注:如需引入外部Js需刷新才能执行]
发现在IE取得值太精确了，比火狐还准确，不过我也不打算在程序内部设置取精度的运算，因为我不确定现实中究竟会向上遍历多少次。在某一父元素的padding与width取精度，很可能会严重影响其最终值的精度。基本上，width与height与padding的取值就到此为止，我们再来看盒子模型的两个东西：margin与border。
margin的auto通常为0px，但在IE6下，当我们将其父元素的text-align设为center，它不但把文本居中，连块级元素本身也忧患中了，这是IE6居中布局的基石。很难说这是BUG，就像IE5的怪癖模式的盒子模型那样，很符合人通常的思维习惯，但是较难实现，加之W3C是偏袒被微软阴死的网景，于是网景的盒子模型成为标准了。IE6庞大的用户基础不容忽视，我们不能随便给0px了事。我也说了，auto有个对称性，因此好办，我们求出其父元素的width然后减于其offsetWidth再除以2就行了。因为offsetWidth是针对于offsertParent的，因此我们用时临时把其父元素的position设为relative，让子元素来得offsetWidth后，再将父元素的position还原。
//转换margin的auto
if(/^(margin).+/.test(style) && value == "auto"){
var father = el.parentNode;
if(/MSIE 6/.test(navigator.userAgent) && getStyle(father,"text-align") == "center"){
var fatherWidth = parseFloat(getStyle(father,"width")),
_temp = getStyle(father,"position");
father.runtimeStyle.postion = "relative";
var offsetWidth = el.offsetWidth;
father.runtimeStyle.postion = _temp;
return (fatherWidth - offsetWidth)/2 + "px";
}
return "0px";
}
borderWidth的默认值为medium，即使它为0px，但如果我们显式地设置其宽为medium呢？！它就不为0px了。这个比较恶心，我们需要判定这值是我们自己加上的还是浏览器的默认值。不过我们发现如果是默认的，其border-XX-style为none。另，除了medium外，还存在两个模糊值thin与thick。它们在浏览器的精确值见下表：
//테두리를 얇은 중간 두께로 변환
(/^(테두리).(너비)$/.test(스타일)){
var s = style.replace("너비","스타일"),
b = {
thin:[ "1px" ,"2px"],
중간:["3px","4px"],
두꺼운:["5px","6px"]
}
if(값 = = "medium" && getStyle(el,s) == "none"){
return "0px";
return !!window.XDomainRequest ? b[ value][ 1]
}
위, 왼쪽, 오른쪽, 아래를 보니 파이어폭스와 사파리가 게으르고 자동만 반환할 줄은 몰랐습니다. 정직하게 평가하세요. Microsoft의 유용한 기능이 이미 모든 브라우저에서 지원되기 때문에 솔루션도 매우 간단합니다.
var 값 = (style == 'width') ? ['left', 'right'] : ['top' , 'bottom'], size = 0;
if(isQuirk){
return el[camelize("offset-" style)]
}else{
var client = parseFloat(el[camelize ("client-" 스타일)]),
paddingA = parseFloat(getStyle(el, "padding-" 값[0])),
paddingB = parseFloat(getStyle(el, "padding) -" 값[1 ]));
return (클라이언트 - paddingA - paddingB) "px";
}
}
if(!/^d px$/.test(value)) {
/ /측정 가능한 값 변환
if(/(em|pt|mm|cm|pc|in|ex|rem|vw|vh|vm|ch|gr)$/.test(value)) {
return ConvertPixelValue(el,value);
}
//전환율
if(/%/.test(value)){
return parsFloat(getStyle(el.parentNode, "너비" )) * parsFloat(값) /100 "px"
}
}
반환 값;//예: 0px
}else{
if(style == "float "){
style = propFloat;
}
return document.defaultView.getCompulatedStyle(el, null).getPropertyValue(style)
}
}
说多无谓，我们测试一下吧。
父元素
子元素
window.onload = function(){
alert(getStyle(_("text"),"width"))
alert(getStyle(_("text2"),'width'))
alert(getStyle(_("text2"),'padding-left'))
};
[Ctrl+A 全选 注:如需引入外部Js需刷新才能执行]
发现在IE取得值太精确了，比火狐还准确，不过我也不打算在程序内部设置取精度的运算，因为我不确定现实中究竟会向上遍历多少次。在某一父元素的padding与width取精度，很可能会严重影响其最终值的精度。基本上，width与height与padding的取值就到此为止，我们再来看盒子模型的两个东西：margin与border。
margin的auto通常为0px，但在IE6下，当我们将其父元素的text-align设为center，它不但把文本居中，连块级元素本身也忧患中了，这是IE6居中布局的基石。很难说这是BUG，就像IE5的怪癖模式的盒子模型那样，很符合人通常的思维习惯，但是较难实现，加之W3C是偏袒被微软阴死的网景，于是网景的盒子模型成为标准了。IE6庞大的用户基础不容忽视，我们不能随便给0px了事。我也说了，auto有个对称性，因此好办，我们求出其父元素的width然后减于其offsetWidth再除以2就行了。因为offsetWidth是针对于offsertParent的，因此我们用时临时把其父元素的position设为relative，让子元素来得offsetWidth后，再将父元素的position还原。
复制代码 代码如下:
//转换margin的auto
if(/^(margin).+/.test(style) && value == "auto"){
var father = el.parentNode;
if(/MSIE 6/.test(navigator.userAgent) && getStyle(father,"text-align") == "center"){
var fatherWidth = parseFloat(getStyle(father,"width")),
_temp = getStyle(father,"position");
father.runtimeStyle.postion = "relative";
var offsetWidth = el.offsetWidth;
father.runtimeStyle.postion = _temp;
return (fatherWidth - offsetWidth)/2 + "px";
}
return "0px";
}
borderWidth的默认值为medium，即使它为0px，但如果我们显式地设置其宽为medium呢？！它就不为0px了。这个比较恶心，我们需要判定这值是我们自己加上的还是浏览器的默认值。不过我们发现如果是默认的，其border-XX-style为none。另，除了medium外，还存在两个模糊值thin与thick。它们在浏览器的精确值见下表：
| IE8 ,firefox等标准浏览器 | IE4-7 | |
|---|---|---|
| thin | 1px | 2px |
| medium | 3px | 4px |
| thick | 5px | 6px |
코드 복사 코드는 다음과 같습니다.
//테두리를 얇은 중간 두께로 변환
(/^(테두리).(너비)$/.test(스타일)){
var s = style.replace("너비","스타일"),
b = {
thin:[ "1px" ,"2px"],
중간:["3px","4px"],
두꺼운:["5px","6px"]
}
if(값 = = "medium" && getStyle(el,s) == "none"){
return "0px";
return !!window.XDomainRequest ? b[ value][ 1]
}
코드 복사 코드는 다음과 같습니다.
//위로 변환|왼쪽|오른쪽| 하단의 자동
if(/(top|left|right|bottom)/.test(style) && value == "auto"){
return el.getBoundingClientRect()[style]
}
글이 벌써 너무 길어졌네요. 나머지 부분은 다음에 이야기하겠습니다.if(/(top|left|right|bottom)/.test(style) && value == "auto"){
return el.getBoundingClientRect()[style]
}
성명：
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.