'전체'에 해당되는 글 46건
- 2008/02/14 유튜브의 발렌타인데이 센스
- 2008/02/14 구글의 에러... (1)
- 2008/01/15 구글의 센스 (3)
- 2008/01/07 웹디자인의 기본
- 2007/12/18 stophobiaとは？ (1)
- 2007/12/13 stophobia란? (2)
- 2007/10/30 근본부터 고치는 IE의 CSS버그
- 2007/10/26 올바른 웹표준 마크업의 기준
- 2007/10/26 논리적인 ID, CLASS이름을 생각한다 (4)
- 2007/10/25 주요 브라우저의 디폴트CSS (2)
이올린에 북마크하기구글의 검색페이지에서 에러가 났네요...
회사 컴터가 전부 이 상태인걸 보니 바이러스가 돌아다니고 있는건가...
일단 저 패스워드를 넣으면 정상적으로 동작은 하지만...
뭔가 찜찜...
그런데, 에러메세지가 보통이 아니군요.
친절한 듯 하면서도, 그 센스에서 약간 화가 날려고도 하는, 매우 야릇한 기분...
확대해서 봐 주세요.
해석을 하자면...
나쁜 소식은, 구글독스가 에러를 만났다는 것입니다.음...
좋은 소식은, 당신이 우리가 에러를 발견할 수 있도록 도와주셨다는 사실입니다.
당신이 초래한 불편함에 우리는 사죄드립니다.
죄송합니다. 그리고, 도와주셔서 감사합니다!
결국 내가 잘못했다는건가효?
항상 딱딱한 사죄 인사에 길들여져 있어서일까, 이런 재치있는 사죄가 익숙하지 않긴 합니다.
웬지 친근하게도 느껴지구요.
하지만... 이왕 기분좋게 만들 계획이셨다면, 60년대 유머는 좀 지양해 주셨으면...
多忙な現代社会で、周辺環境の影響で真実な安息を見つかることができず、「人間本来の価値」と表裏する物質重心の文化に尊厳な個人としてではなく単純な部品として自分のことを認めてしまう、そして「社会共通の価値」以外には何も認めない状況を表した単語であります。
[ 停止恐怖症 ]
恐怖症の一種類で、止まっていることを嫌がり、不安を感じる。
こういう不安が恐怖の状態まで致す状態が停止恐怖症である。
この病勢以外の他の病勢はないが、一般的に社会生活で大きな支障はないため恐怖症というより癖や性格だと思われます。
ところが、深刻な場合、全力を尽くして余力が残してないことにもかかわらず先進を止まらない危険もある。
僕は何の人なんでしょうか。何をするためこの世に生まれてきたのでしょうか。
こういうことを自問する時間も持たず、今、ここになぜ立ち止まっているのでしょうか。
바쁜 현대 사회에서, 주변 환경의 영향으로 진정한 안식을 찾지 못하고, "인간 본연의 가치"와 상반하는 물질 위주의 문화에 존엄한 개인으로서가 아닌 단순한 부품으로 스스로 폄하하게 된, 그래서 "사회 공통의 가치" 이외에는 아무것도 인정하지 않는 상황을 풍자한 단어입니다.
[ 정지공포증 ]
공포증의 한 형태로, 멈추어 있는 것을 꺼리고 두려움을 느낀다.
이러한 불안이 공포에까지 이르는 상태가 정지공포증이다.
이 증세 외에 다른 증세는 없는데, 일반적으로 사회생활에서 큰 지장은 없어 공포증이라기 보다는 버릇이나 성격으로 여겨진다.
하지만 심각한 경우에는 전력을 쏟아부어 여력이 남아있지 않음에도 불구하고 전진을 멈추지 않을 위험도 있다.
나는 어떤 사람일까요? 무엇을 하기 위해 이 세상에 태어났을까요?
이런 것들을 자문할 시간도 없이, 지금 이자리에 왜 서있는 걸까요?
이 문제에 대해서도 꽤 오래전 IE6의 CSS 버그를 위한 Ultra CSS Hack 라는 이름으로 세네세네님께서 친절하게 설명해 주신 문제인데요, 너무 단편적인 감이 없지 않아서, 좀 더 자세히 살펴보았습니다.
링크한 기사는 꽤 오래전에 읽은 기사이지만, 그 동안 저 스스로 연구좀 하느라고 포스팅은 좀 늦게 되어버렸습니다.
실제 마이크로소프트의 Internet Explorer Developer Center에도 관련 이슈가 있습니다. 이슈라기보다는 "해결책"이지만,
이 포스팅의 제목은 "CSS버그의 수정"이지만, 핵과는 전혀 상관 없습니다. 기본 설정값을 파악해서 근본을 약간 손대는 방법으로 CSS버그가 애초에 일어날 수 없는 환경을 만들어보고자 하는 의도입니다.
1. hasLayout 이란?
hasLayout 이란, 오브젝트가 레이아웃을 가지고 있는지를 나타내는 것입니다. hasLayout 의 값은 Read-only이기 때문에 읽기만 가능하며 false와 true로 구분합니다. false는 오브젝트가 레이아웃을 가지고 있지 않은 경우, true는 오브젝트가 레이아웃을 가진 경우입니다.
IE계통 CSS 버그중 다수를 차지하는 float, width, height 와 관련된 버그가 이 haslayout과 관련이 있습니다. 이러한 속성을 true값으로 지정해 둔다면 관련된 버그가 어느 정도는 해소될 듯 합니다.
2. hasLayout 과 관련된 버그의 예
배경색이 지정된 상위 요소 안에서 float된 하위 요소가 있으면, 상위 요소안에서 하위요소의 위에 있는 문자가 사라집니다.
float에 뒤따라오는 margin값이 무시됩니다.
width가 지정된 박스의 안에 float된 하위요소가 있으면 자동적으로 높이가 성장합니다.
(근거가 되는 에러의 예시는 11월 중순 이후 원고가 정리되는대로 자세하게 공개하겠습니다. 이것만으로도 카테고리를 하나 만들어야하지 않나 할 정도로 양이 방대하군요...)
3. 각 속성값과 true값
만약 IE계통의 브라우저 레이아웃 설정이 파이어폭스처럼 수정 가능하도록 공개가 된 상태라면 애초에 덮어쓰기용 파일이 나오지 않았을까하고 생각도 해 봅니다만...
| 속성 | 값(true값) |
|---|---|
| display | inline-block |
| height | any value |
| float | left or right |
| position | absolute |
| width | any value |
| writing-mode | tb-rl |
| zoom | any value |
그럼 실제, 이 블로그에서 hasLayout을 가진 요소는 무엇이 있는지 알아볼까요?
4. hasLayout 패블릿
여기를 눌러보세요!
위의 링크를 누르면, 이 블로그에서 hasLayout이 true인 요소는 빨강, false라면 파랑색 보더가 적용됩니다.
5. CSS버그에 효과가 있는 hasLayout 지정법
hasLayout을 변경하는 속성 중에는 float, position처럼 레이아웃을 무시하고 함부로 속성값을 지정할 수 없는 것도 있습니다.
그래서, zoom을 생각해 보았습니다. zoom은 지정한 요소의 확대/축소를 지정하는 것입니다. 대부분의 레이아웃이 100%로 유저에게 보여지는 것을 전제로 제작되고 있기 때문에 이것을 이용해도 문제는 없으리라 생각합니다.
웹표준에 무슨 마크업의 기준이 존재하겠습니까.
기준이라는 것이, 사실은 상대적인 규칙입니다. 웹 퍼블리셔 자신이 만들어가는 기준이라고 할 수 있겠죠. 좀 더 규칙적이고 이해하기 쉬운 규칙을 찾느냐 아니냐는 전적으로 웹퍼블리셔에게 달려있겠고요.
제가 제시하고자 하는 기준은 이러한 규칙을 설정하는데 있어서 어느 정도의 틀을 제공하고자 하는 것이구요.
원문의 인용은 맨 뒤에 싣도록 하겠습니다. 제가 봐도 머리가 어지러워서...
웹페이지를 출판하는데 있어서 "구조화"라는 것은 이제까지 웹퍼블리셔들이 의식하지 못했던, 그러나 분명히 존재했던 문제들을 수면위로 끌어올립니다.
바로 "자유"인데요, 이것은 "무슨 코드를 사용할 것인가"와 관련이 있습니다. 자신이 "왜 여기에 이렇게 지정을 했는가"정도만 설명할 수 있다면 특별히 문제가 없는 정도지요.
역으로 "구속"도 있는데요, 이것은 "무슨 DTD를 사용할 것인가", "특수한 경우에 있는 유저들을 위한 CSS를 표현하기 위해서는 어떠한 방식으로 CSS를 지정할 수 있는가" 등과 관련이 있겠지요. 이건 선택의 여지가 별로 없습니다.
예전에도 이러한 고민은 존재했겠습니다만, 어지간한 고민은 대충 해결해 주었던 IE6 덕분에 그리 골치 아프지는 않았던 것 같습니다.
그럼, 어디까지가 자유고, 어디까지가 속박인가... 그에 대한 기준을 알아보고자 하는 것이지요.
사실은 이러한 기준이 IETF의 문서 RFC2119에 기술되어있습니다. 이 문서는 XHTML1.0의 사양서에도 언급된 문서입니다.
구분은 대충 MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, OPTIONAL 정도가 있는 것 같지만, 제 나름대로 3단계로 나누어 보았습니다. 더 아실 분은 맨 밑의 원문을 참조해 주세요...
필수(MUST) : 문법이 문서형 정의에 어긋나지 않은가?
추천(SHOULD) : 사양서에서 정해놓은 방침을 따르는가?
가능(MAY) : 구조화나 의미의 부여, 목적이나 문맥에 의한 용법에 부합하는가?
필수 : 필수 레벨은 XHTML, XML문서에 명시되고 있는 사항으로, W3C의 밸리데이션에서 페이지의 오류를 체크하는 기준이 되는 것 같습니다. 최저한의 기준, 마지노선이 되겠지요.
혹자는 밸리데이션을 받은 것 만으로 "웹표준"이라는 사람도 있지만, 그러한 정의와는 조금 다릅니다.
테이블 레이아웃도 밸리데이션받는데 아무 문제 없으니까요.
추천 : 여기서부터는 문법 이상의 것을 요구합니다. 예를 들어, "구조와 표현의 분리"라는 것도 여기서부터의 레벨입니다.
필수 레벨과의 최대 차이는, 문맥이나 목적에 따라 올바른 마크업을 사용하고 있는지, 구조에 맞는 태그를 사용하고 있는지를 생각하게 되는 레벨이지요. 프로그램으로는 이러한 타당성을 체크하는 것이 매우 어렵습니다.
가능 : 이 부분은 완벽하게 웹퍼블리셔의 자유에 맡겨진 부분입니다. 그만큼, 초보 웹퍼블리셔와 숙련된 웹퍼블리셔를 구분짓는 부분이기도 하지요.
인용문을 <q>로 마크업할 것인지, <cite>로 마크업할 것인지, 또는 강조 구문을 <em>으로 마크업할 것인지, <strong>으로 마크업할 것인지의 문제입니다. 무엇을 쓰던 상관은 없습니다. 다만, "얼마나 납득가능한 설명을 하느냐"에 달렸다고 해도 과언은 아닐겁니다.
아래는 문서의 원본을 게재해 보았습니다.
해석 여부에 따라 다양한 생각이 나게하는 문서네요...
(조금 정확한 표현을 쓰자면... 애매하다는 뜻입니다. 결국 XHTML사양서를 잘 읽으시오! 정도로 요약이 됩니다.)
Network Working Group S. Bradner
Request for Comments: 2119 Harvard University
BCP: 14 March 1997
Category: Best Current Practice
Key words for use in RFCs to Indicate Requirement LevelsStatus of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Abstract
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.5. MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional. One vendor may choose to include the item because a
particular marketplace requires it or because the vendor feels that
it enhances the product while another vendor may omit the same item.
An implementation which does not include a particular option MUST be
prepared to interoperate with another implementation which does
include the option, though perhaps with reduced functionality. In the
same vein an implementation which does include a particular option
MUST be prepared to interoperate with another implementation which
does not include the option (except, of course, for the feature the
option provides.)6. Guidance in the use of these Imperatives
Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions) For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for
interoperability.
7. Security Considerations
These terms are frequently used to specify behavior with security
implications. The effects on security of not implementing a MUST or
SHOULD, or doing something the specification says MUST NOT or SHOULD
NOT be done may be very subtle. Document authors should take the time
to elaborate the security implications of not following
recommendations or requirements as most implementors will not have
had the benefit of the experience and discussion that produced the
specification.8. Acknowledgments
The definitions of these terms are an amalgam of definitions taken
from a number of RFCs. In addition, suggestions have been
incorporated from a number of people including Robert Ullmann, Thomas
Narten, Neal McBurnett, and Robert Elz.9. Author's Address
Scott Bradner
Harvard University
1350 Mass. Ave.
Cambridge, MA 02138phone - +1 617 495 3864
email - sob@harvard.edu
---
Copyright (C) The Internet Society (March 1997). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
사이트를 구조적으로 만들기 위해서는 의미에 맞는 마크업도 중요하지만, 마크업에 부여하는 ID, CLASS명도 중요하다고 생각합니다.
조금 빗나간 이야기지만, ID명, CLASS명 합쳐보면, 심한 경우는 코드와 비슷할 정도로 많은 바이트를 차지하는 경우도 있습니다.
그런 의미에서 보면, 이런 것도 웹표준을 위해 신경써야하지 않나 생각합니다.
일단 기본적으로 논리구조를 살펴봅시다. 논리구조를 올바로 파악하지 않고 있다면 올바른 ID명, CLASS명을 붙이기도 힘들어지니까요.
1. 종래의 이름 vs 제안
| 종래의 이름 | 제안 |
|---|---|
| ID:header CLASS:description information gloval_nav ID:body CLASS:contents hot_topics hot_products sidebar sub_nav banners ID:footer CLASS:credit privacy |
ID:site CLASS:description information navigation ID:page CLASS:recent information products related navigation services ID:publication CLASS:credit privacy |
2. 보다 구조를 의식한 CLASS이름을 붙이자!
구체적으로, 위에 나타난 예와 같이 CLASS이름을 상층에서 하층으로 늘어놓았을 때, 논리적인 일관성이 유지되도록 합니다. 하나의 기준으로, CLASS이름을 자연문(일반적인 문장)으로 바꿔보고, 부자연스럽지는 않은지 체크해 봅니다.
예를 들어, #header .description 에 들어갈 내용은, 감히 추측해 보건대, "사이트에 관한 설명"이 기술되어 있지 않을까요? 어찌되었던 "헤더에 관한 설명"이 들어가 있지는 않으리라 생각합니다.
이런 생각으로 하나하나 살펴보면
site - description: 사이트 전체에 대한 - 설명문
site - information: 사이트 전체에 대한 - 정보
site - navigation: 사이트 전체에 대한 - 안내
page - navigation: 페이지 고유의 - 안내
page - recent - information: 페이지 고유의 - 최신 - 정보
page - recent - products: 페이지 고유의 - 최신 - 제품
related - services: 관련된 - 서비스
header나 (main)contents, body, footer 등은, Web 페이지를 작성할 때에 많이 사용되는 id, class명입니다만, 보통 "header"의 공간에는 사이트 공통의 메타레벨 콘텐츠가, 또 "body"의 공간에는 그 페이지 고유의 오리지날 컨텐츠가 포함되는 경우가 많다는데에 착안하여, 사이트 공통의 정보와 페이지 고유의 정보를 구별하는 의미로, header 부분을 "site", body(혹은 (main)contents) 부분을 "page"라는 이름으로 해 보았습니다.
만약 "페이지 고유의 최신 정보"라는 문맥이 마음에 들지 않으시면, ourCompany - recent - product(우리 회사의 최신 제품)등으로 하는 방법도 있습니다.
각각의 상황이나 목적에 어울리도록, 적절하게 논리 구조를 추상화한 이름을 붙여 보면 좋을 것같습니다.
3. 논리적으로 동급의 경우에는 의식적으로 같은 class명을 붙인다.
#header .global_nav -> #site .navigation
#body .local_nav -> #page .navigation
CSS에서는 글로벌 네비게이션과 로컬 네비게이션을 구별하고 싶을 때 셀렉터의 기술만으로도 간단하게 처리할 수 있습니다. 이 쪽이 각 네비게이션을 구별하거나 동일화할 때, 어느쪽에서든지 사용할 수 있기 때문에, 더욱 유연성이 있다고 생각할 수 있습니다.
4. 종래의 이름도 상관은 없습니다만...
실제 많은 웹페이지를 출판하시는 웹퍼블리셔들이 구조를 무시한 외관 위주, 또는 습관적으로 마크업을 해 버리는 경우가 많습니다. 심지어는 어느 홈페이지던간에 구별없이 "템플레이트"라는 물건을 만들어 ID와 CLASS를 "생각할 시간을 절약"하는 경우도 있는 것 같습니다.
하지만, 더욱 구조를 생각하는 마크업을 하려 하신다면, 조금 더 생각해 보셔도 그리 시간이 아깝지 않은 문제라고 생각합니다.
웹 브라우저마다 각각 default CSS가 존재합니다. cascade한 CSS의 특성상, 제작자가 작성한 CSS도 브라우저의 디폴트 CSS의 영향을 받습니다. 웹 사이트가 브라우저마다 조금씩 다르게(경우에 따라 심각하게) 표현되는 이유가 바로 default CSS 때문입니다.라는 글을 읽고 흥미를 가지고 있던 중, 여기저기서 정보를 얻어 정리해 보았습니다.
AccessifyForum.com이라는 곳에서는 list of browsers' default CSS 이라는 이슈도 있군요.
| locations of default stylesheets | |||
|---|---|---|---|
| 브라우저 | 운영체제 | 모드 | 관련 파일 경로 |
| (W3C CSS 2.1 CR) | HTML4 | http://www.w3.org/TR/CSS21/sample.html | |
| 파이어폭스 | 윈도우즈 | HTML4 | C:\Program Files\Mozilla Firefox\res\html.css |
| Quirks | C:\Program Files\Mozilla Firefox\res\quirks.css | ||
| 맥 | HTML4 | /Applications/Firefox.app/Contents/MacOS/res/html.css | |
| Quirks | /Applications/Firefox.app/Contents/MacOS/res/quirks.css | ||
| IE6 | 윈도우즈 | DLL | |
| IE7 | 윈도우즈 | ? | |
| IE5 | 맥 | ? | |
| 오페라 | 윈도우즈, 맥 | ? | |
| 사파리 | 맥 | HTML4 | /sw/share/apps/khtml/css/html4.css |
| Quirks | /sw/share/apps/khtml/css/html4.css | ||
| 윈도우즈 | HTML4 | ? | |
| Quirks | ? | ||
흠... 뭐 별 영양가는 없지만...
