Trio 홈페이지 - 성능(Performance), 적용(Implementation), 설계(Design)에 대한 주석

다음 주석들은 지명적이 아니고 정보를 주기 위한 것이다. "...하여야 한다" 등의 단어들이 나오더라도, 이 항목의 모든 필요 사항들은 이 규격의 다른 부분에 기술되어 있다.

이 규격은 규격에 부합하는 사용도구들이 일반적인 오류 상태를 포함하여, 이 문서에 정의되지 않은 엘레멘트들, 애트리뷰트들, 애트리뷰트 값들, 또는 엔티티(entity)들을 만날 때, 어떻게 처리 할 것인가를 정의하고 있지 않다.

그러나, 실험은 돕고, HTML의 다양한 버전들에서의 상호 적용성등을 고려하여, 다음과 같은 처리를 추천한다. 만일 사용도구가

또한 사용도구가 사용자에게 이 오류들을 알려주는 기능을 제공 할 것을 추천한다.

사용도구들의 오류 처리 방법이 서로 다를 수 있으므로, 제작자와 사용자는 특정 오류 수정 처리 방법에 의존하지 말아야한다.

HTML 2.0 규격[RFC1866]에서 많은 HTML 2.0 사용도구는, '참조 문서 타입 선언으로 시작하지 않는 문서들은 HTML 2.0 규격을 참조한다'고 가정하였었다. 이것은 빈약한 가정이고, 현재 규격에서는 그렇게 하는 것을 추천하지 않는다.

예를 들어, 새로운 엔티티 정의로 DTD를 확장하는 등, 공통적인 사용 문제들 때문에, 제작자는 HTML에서 사용 할 수 있는 SGML 기능을 통하여 확장하지 말아야한다.

B.2 URI 애트리뷰트 값들에서의 특수 글자들

B.2.1 URI 애트리뷰트 값에서 비아스키(non-ASCII) 글자

URI들은 비아스키(non-ASCII) 값을 갖지는 않으나[URI의 항목 2.1], 때로 제작자는 URI(DTD에서 %URI;로 정의)를 위하여 애트리뷰트 값에 비아스키(Non-ASCII) 값을 지정한다. 예를 들어, 다음 href의 값은 틀린 것이다.

사용도구는 다음 비아스키(non-ASCII) 글자 처리 방법을 채용 할 것을 추천한다.

이 과정은, URI가 HTML 문서로 재고딩(transcode) 될 때, 글자 엔코딩에 영향을 받지 않으며, 문법적으로 유효한 URI[RFC1738 항목 2.2 또는 RFC2141 항목 2에 정의]를 만들어 준다.

주석: 일부 이전의 사용도구들은, 받은 문서 안의 글자 엔코딩 이진수(byte)들를 사용하여, 하찮게 HTML의 URI들을 처리하였다. 일부 이전 사용도구들은 이 방법에 의존하여 트랜스코드 될 때 깨졌었다. 옛날 문서들을 처리하기를 원하는 사용도구들은, 유효하지 않은 글자를 포함 한 URI를 받으면, 우선 UTF-8에 기초하여 변환하여야 한다. 결과 URI이 문제를 해결하지 못하는 경우에 만, 받은 문서의 글자 엔코딩 이진수(byte)들에 따라 URI 구성을 시도하여야 한다.

주석. 주석: A 엘레멘트의 name 애트리뷰트 값에도 UTF-8에 따른 같은 변환이 적용된다.

B.2.2 URI 애트리뷰트 값들에서의 앰퍼샌드('&')

폼(form)이 송신되어 구성되는 URI는 앤커(anchor) 연결(예: A 엘레멘트의 href 애트리뷰트)로 사용 될 수 있다. 불행하게도, 폼 필드(form field)를 분리하기 위한 "&" 글자의 사용은 글자 엔티티 참조 범위에서 SGML 애트리뷰트 값에 사용되는 것과 혼동된다. 예를 들어, URI "http://host/?x=1&y=2"를 연결로 사용하는 URI로 하기 위해서는, <A href="http://host/?x=1&y=2"> 또는 <A href="http://host/?x=1&y=2">로 써야한다.

제작자가 이 방식으로 "&" 글자를 변환(escape)하는데 문제의 발생을 피하기 위하여, HTTP 서버 적용자(implementor)들, 구체적으로, CGI 적용자들은 "&" 대신 ";"의 사용을 지원 할 것을 추천한다.

B.3 SGML 적용 주석들

B.3.1 줄바꿈들

SGML[ISO8879, 항목 7.6.1]에서 시작태그(tag) 바로 다음과 종료태그 바로 앞의 열바꿈(line break)은 무시되어야 한다고 정의한다. 이는 예외 없이 모든 HTML 엘레멘트(element)에 적용된다.

B.3.2 비 HTML(non-HTML) 데이터의 정의

스크립트(script)와 스타일(style) 데이터가 엘레멘트(element)의 내용으로 또는 애트리뷰트(attribute) 값으로 나타날 수 있다. 이 항목들은 HTML 작성(markup)과 외부 데이터와의 구별을 설명한다.

주석: DTD는 스크립트와 스타일 데이터를 엘레멘트 내용과 애트리뷰트 값의 CDATA로 정의한다. SGML 규칙은 CDATA에서 글자 참조가 엘레멘트 내용에서는 허용되지 않고, 애트리뷰트 값에서는 허용된다. 제작자들은 스크립트와 스타일 데이터 사이에서 엘레멘트 내용과 애트리뷰트 값을 잘라 부칠 때 특히 주의하여야 한다.

풍부한 서류에서 빈약한 글자 엔코딩으로 코드 변경(transcoding) 할 때, 코드 변경자(transcoder)는 스크립트나 스타일 데이터에 있는 변환 할 수 없는 글자를 해당 숫자 참조로 제공 할 수 없다는 의미도 된다. 데이터를 올바르게 처리하기 위해서는, 코드 변경자은 HTML 문서를 변환(parse)하고, 각 스크립트와 스타일 언어의문법를 알아야한다.

엘레멘트 컨텐트(content)

스크립트(script)나 스타일(style) 데이터가 엘레멘트(element)의 내용(content)이면(SCRIPT와 STYLE), 데이터는 엘레멘트 시작태그(tag) 바로 뒤에서 시작하고, 첫번째 종결자(delimiter) </"에서 끝나며, 그 다음에는 이름 글자[a-zA-Z]가 나온다. 이 </는 엘레멘트의 종료태그가 아닐 수 있슴에 주의하라. 이때는 제작자가 내용 안에서 "</"로 변환(escape)하여야 한다. 에스케입(escape) 기능들은 각 스크립트나 스타일쉬트 언어에 설명되어있다.

자바스크립트(Javascript) 안에서, 이 코드는 SGML 이름 시작 전에 종결자(delimiter) ETAGO(</)를 감추면서 유효하게(legally) 표현 될 수 있다.

<SCRIPT type="text/Javascript">
 document.write ("<EM>이것은 작용 함.<\/EM>")
</SCRIPT>

Tcl(tool command language)에서는, 이 다음과 같이하면 된다.

<SCRIPT type="text/tcl">
 document write "<EM>이것은 작용 함.<\/EM>"
</SCRIPT>

비주얼베이식 스크립트(VBScript)에서는, Chr() 기능을 사용 할 수 있다.

 "<EM>이것은 작용 함.<" & Chr(47) & "EM>"

애트리뷰트(attribute) 값들

스크립트(script)나 스타일(style) 데이터가 style 또는 본질적 이벤트(intrinsic event) 등 애트리뷰트의 값이면, 제작자는 스크립트 또는 스타일 언어에 따라, 그 값 안에서 단일 혹은 이중 따옴표를 닫도록 변환(escape)하여야 한다.

제작자는 또한 "&"가 글자 참조의 시작이 아니면, "&"으로 해석(escape)하여야 한다.

B.3.3 SGML 기능의 제한 된 지원

[ISO8879]에 부합하는 SGML 시스템들은 HTML 사용도구들에 의하여 널리 지원되지 않는 여러 기능을 인식하므로, 제작자는 이 기능들을 사용하지 않을 것을 추천하다.

B.3.4 불린(boolean) 애트리뷰트

많은 사용도구들은 완전한 것이 아닌, 축소 형식의 불린 애트리뷰트(attribute) 만을 인식한다는 점을 제작자는 알아야한다.

B.3.5 표시 된 항목들

표시 된 항목들은 C 사전처리자(preprocessor)에서 #ifdef로 인식되는 구조와 유사한 기능을 한다.

SGML은, 시작태그가 아닌 "<" 안에서, CDATA 내용(content)에서 표시 된 항목들의 사용도 정의한다. 예를 들어:

사용도구가 표시 된(marked) 항목을 인식하지 못하며, 숨기려 해도 저절로 드러내는(telltale) 기호는 "]]>"로나타나는데, 이 것은 "<!["로 시작하는 한 것에 대한 첫번째 ">"로 종료하는 것으로, 사용도구가 실수한 것으로 보인다.

B.3.6 처리 지시

처리 지시(processing instruction)들은 프레트홈에 따른(platform-specific) 문구(idiom)를 잡아내는 기능(mechanism)이다. 처리 지시는 <?로 시작하고>로 끝난다.

제작자는 사용도구의 많은 표현 처리 지시들을 문서 텍스트의 일 부분으로 알아야한다.

B.3.7 약식(shorthand) 마크업(markup)

일부 SGML SHORTTAG을 타이핑을 줄이기 위하여 구성하지만, SGML 적용(application)에 특기 할 능력을 추가하지는 않는다. 기술적으로 모호 함이 없이 구성되지만, 문서의 견고성을 감소 시킨다. 특히 그 언어가 새로운 엘레멘트(element)를 포함하도록 보완되었으면 더욱 그렇다. 그래서 SGML SHORTTAG 구성은 애트리뷰트(attribute)와 관련하여 널리 사용되고 있으나, 엘레멘트와 관련해서는 그렇지 않다. 이것을 사용하는 문서들은 SGML 규격에 맞는 문서이나, 많은 현재의 HTML 도구들에서는 그렇지 않을 가능성이 높다.

NET 태그들:
```
<name/.../
```
시작태그의 종료:
```
<name1<name2>
```
빈(empty) 시작태그:
```
<>
```
빈 종료태그:
```
</>
```

B.4 Web 싸이트 검색 엔진 도움 색인에 대한 주석

이 항목은 검색 엔진들이 더 쉽게 문서에 접근하기 위한 간단한 암시들를 제공한다.

B.4.1 검색 로봇(search robot)

robots.txt 화일

로봇이, http://www.foobar.com/와 같은, 웹 싸이트를 방문하면, 이는 먼저 http://www.foobar.com/robots.txt 화일을 점검한다. 이 화일이 발견되면, 문서의 읽어 드림이 허용되는가를 알기 위해 그 내용을 분석 할 것이다. robots.txt 화일을 특정 로봇들에 만 적용하고, 특정 디렉토리등이나 화일들에 접근하지 못하게 위하여 필요에 맞게 만들 수 있다.

아래 예제 robots.txt 화일은 모든 로봇들이 전 싸이트를 통하여 방문하는 것을 금지하고 있다.

싸이트가 특정 호스트(host)와 포트(port) 번호에서 HTTP 서버로 운영되는 것으로 정의되었으면, 로봇은 단순히 싸이트 URI에서 "/robots.txt"를 찾을 것이다. robots.txt의 위치 예제를 보라.

싸이트에는 하나의 "/robots.txt" 만을 가질 수 있다. 구체적으로, "robots.txt" 화일들은 로봇은, 그것을 사용자 디렉토리에서 찾지 않기 때문에, 사용자 디렉토리에 위치시켜서는 않된다. 사용자가 자신의 "robots.txt"를 만들기를 원하면, 단일 "/robots.txt" 안에 모두 통합(merge)할 필요가 있다. 만일 그렇게 하기를 원하지 않으면, 사용자는 그 대신 로봇 META 태그를 사용 할 수도 있다.

싸이트 URI	`robots.txt`의 URI
http://www.w3.org/	영어 http://www.w3.org/robots.txt
http://www.w3.org:80/	영어 http://www.w3.org:80/robots.txt
http://www.w3.org:1234/	http://www.w3.org:1234/robots.txt
http://w3.org/	영어 http://w3.org/robots.txt

URI는 대소문자 구별하며, "/robots.txt" 문자열은 모두 소문자이어야 하며, 공백은 허용되지 않는다.

각 레코드(record) 마다 꼭 한개의 사용도구의 필드(field)를 가져아한다. 로봇은 이 필드의 해석에서 자유스러워야 한다. 대소문자 구별 없는 부분 문자열에 맞는 이름에 버전 정보 없이 사용하는 것이 추천된다.

만일 그 값이 "*" 이면, 그 레코드는 다른 레코드들과 하나도 맞지 않는 어떤 로봇에서나 가능한 디폴트 접속(access) 정책(policy)을 나타낸다. "/robots.txt" 안에서 여러개의 그렇한 레코드를을 갖는 것은 허용되지 않는다.

"Disallow"(허용 안함) 필드는 방문 할 수 없는 부분 URI를 지정한다. 이는 완전 경로(full path) 또는 부분 경로가 될 수 있다. 이 값으로 시작되는 URI는 읽혀지지 않을 것이다. 예를 들어

"Disallow"에서 빈 값은, 모든 URI들이 읽혀 질 수 있슴을 가리킨다. robots.txt 화일에는 최소한 한개의 "Disallow" 필드(field)가 있어야 한다.

로봇(robot)과 META 엘레멘트(element)

HTML 제작자가 방문하는 로봇들에게 문서가 색인 될수 있는가, 또는 다른 연결들을 위해 사용되었는가를 알려 줄 수 있도록, META 엘레멘트는 허용한다. 서버 관리자(administrator)의 어떤 활동을 필요로 하지 않는다.

주석: 1997년 초반에는 이것이 적용되는 로봇들이 몇개 없었으나, 이것들이 로봇 색인(indexing) 제어를 위하여 더 일반적인 주목을 받을 것으로 기대된다.

B.5 표(table)에 대한 주석

B.5.1 설계의 합리성

HTML 표(table) 모델은, SGML 표 모델, 일반 문서 편집기에서 표의 처리, 잡지, 도서와 다를 페이지를 갖는 문서들의 표들의 양식에 대한 연구들에 의하여 발전되었다. 단일 표가 단순하게 표현 될 수 있도록 모델이 선택되었고, 필요하면 쓸 수 있는 복잡성을 추가하여 사용 할 수 있게 했다. 이는 실제적으로 일상 텍스트 에디터(editor)들로 HTML 표의 자동적으로 작성을 할 수 있게 하고, 공부를 시작하는 사람들의 배우는 시간을 단축하게 할 것이다. 이 기능은 오늘날 성공적인 HTML에 대단히 중요한 것으로 되었다.

사람들은 다른 문서 양식(format)들으로 부터 변환(convert)하거나, 직접 WYSIWYG 편집기로 표를 만드는 경우가 늘어나고 있다. 이들 편집기들에서 HTML 표 모델에 잘 맞아야 한다는 것은 중요하다. 이는 복수의 열(row)들이나 컬럼(column)들에 확장 된(span) 셀(cell)들의 표현 방법, 정렬 방법, 셀들의 구룹들과 연결 된 기타 표현 특성들에 영향을 준다.

탄력적 재 양식화(dynamic reformatting)

HTML 표(table) 모델에서 하나의 중요한 고려 사항으로, 제작자는 사용자가 표의 크기를 지정하지 않고, 사용하는 폰트 등을 제어하지 않는다는 것등 이다. 컬럼(column) 너비를 절대적인 단위인 픽셀(pixel)에 의존하는 것은 위험하다. 그 대신 표는 현재의 창(window) 크기와 폰트(font)에 맞추어 탄력적으로 변경되어야 할 필요가 있다. 제작자는 상대적인 컬럼의 너비로 윤곽을 제공 할 수 있으나, 사용도구는 셀의 내용(content)들 중에서 기장 큰 것이 표현되기에 충분하도록 컬럼들이 넓을 것을 확인하여야 한다. 만일 제작자의 규격이 덮어 씌워(overridden)져야 하더라도, 상대적인 개별 컬럼의 너비들은 심하게 변경되지는 않는다.

점진적 디스플레이(incremental display)

큰 표(table) 또는 속도가 느린 네트워그(network) 연결에서, 표의 점진적 디스플레이는 사용자 만족을 위하여 중요하다. 사용도구는 모든 데이터들을 다 받기 전에, 표를 디스플레이 하기 시작 할 수 있어야 한다. 대부분의 사용도구에서 디폴트 창(window)의 너비는 약 80 글자이고, 많은 HTML 페이지들의 그래픽들은 이 디폴트를 고려하여 디자인되었다. 컬럼(column) 갯수를 지정하므로서, 또 표 너비의 제어(control)와 다른 컬럼들의 너비를 위 한 항목을 포함 함으로서, 제작자는 표 내용(content)의 점진적인 디스플레이를 허용하도록 사용도구에게 힌트를 줄 수 있다.

점진적 디스플레이를 위해서, 브라우저(browser)는 컬럼들의 갯수와 그 너비들이 필요하다. 표의 디폴트 너비는 현재 창 크기(width="100%")이다. 이는 TABLE 엘레멘트의 width 애트리뷰트를 설정함으로서 변경 될 수 있다. 디폴트로 모든 컬럼들은 같은 너비들을 갖지만, 데이터가 시작되기 전에, 한개 또는 여러개의 COL 엘레멘트로 컬럼 너비들을 지정할 수 있다.

나머지 문제는 컬럼들의 갯수이다. 일부 사람들은 첫번째 열(row)이 받아질 때까지 기다릴 것을 제안하였으나, 셀(cell)들이 긴 내용들을 가지고 있으면 오랜 시간이 걸린다. 점진적 디스플레이가 필요하면, 제작자가 TABLE 엘레멘트 안에 컬럼의 갯수를 정확하게 지정하는 것이 전체적으로 더 효과적일 것이다.

제작자는 여전히 사용도구에게 점진적 디스플레이를 사용하는가 또는 내용에 맞게 자동적으로 표의 크기를 조정 것인가를 알려 줄 필요가 있다. 두 단계의 자동 크기 모드 중, 컬럼의 갯수는 첫번째 과정에서 결정된다. 점진적 모드에서, 컬럼들의 갯수가 COL나 COLGROUP 엘레멘트로 먼저 나와야한다.

구조와 표현

HTML에서 문단(paragraph)이나 따옴(quotation)과 같은 구조적 작성과, 마진(margin), 폰트(font), 색상(color), 등의 표현적 문구를 구별한다. 이것들이 표(table)에 구별 된 영향을 미치는가? 표의 셀들 안에서 텍스트의 정렬과 셀들 사이의 테두리(border)는 표현의 문제이고, 구조 문제가 아니다. 그러나 실제적으로, 이 기능들은 한 적용에서 다음 적용으로 대단히 쉽게 유동 할 수 있기 때문에, 이것들은 구조적 정보로 구룹 지우는 것 효과적 일 것이다. HTML 표 모델에서 대부분의 표현 정보는 연관 된 스타일쉬트(style sheet)로 넘기는 것이 좋다. 이 규격의 그 모델은 그런 스타일쉬트의 장점을 갖도록 설계되었으나, 필수사항은 아니다.

오늘날의 편집 도구들은 표의 표현에 대한 대단히 풍부한 제어(control)를 제공한다. 그리고, RTF나 MIF와 같은 텍스트가 풍부하고 방대한 양식(format)으로 HTML을 만들지 않고는, HTML 안에서 재생산 하는 것은 어려울 것이다. 그러나, 이 규격은 제작자가 테두리 스타일들의 일반적으로 사용되는 클라스(class)들의 세트로 부터 선택하도록 제공하지는 않는다. frame 애트리뷰트는 표(table) 주위의 테두리(border)의 모양을 제어하고, rules 애트리뷰트는 표안에서 줄(rule)들의 선택을 결정한다, 더 세밀한 표현은 애니메이션(annotation)을 통한 표현으로 지원된다. style 애트리뷰트는 개별 엘레멘트의 표현 정보를 지정하는데 사용 될 수 있다. 문서의 헤드(head) 안에서 혹은 연결 된 스타일쉬트를 통하여, STYLE 엘레멘트로 추가적인 표현 정보를 줄 수 있다.

이 규격이 발전하는 동안, 여러번 표의 줄(rule) 페턴을 지정하기 위한 연구가 있었다. 한 가지 문제는 할 수 있는 선언의 종류에 관한 것이었다. 변두리 제거 지원을 포함시키는 것이나 변두리 추가는 상대적으로 복잡한 기능을 유발 시켰다. 예를 들어, TABLE 엘레멘트들에 frame과 rules 애트리뷰트를 포함하여 완전 세트를 만드는 작업은, 셀(cell)의 특정 변두리(edge)에 줄(rule)을 긋는가 아닌가를 결정하는데, 한 기능이 24 단계를 거치게 된다. 이 추가적인 복잡성에도 불구하고, 표에 필요한 완전한 범위의 표현 제어에 충분하지 못했다. 현재 규격은 대부분의 목적에 충분한 단순한 모델로 되어있다. 더 복잡한 접근이 표준화되기 위해서는 추가적인 실험들이 필요하다.

열(row)과 컬럼(column) 구룹(group)

이 규격은 HTML+의 초기 작업에서 제시된 간단한 모델의 서브세트를 제공한다. 표(table)들은 하나의 선택적 제목(caption)과 함께 여러개의 열들, 이 열(row)은 다시 여러개의 표(table)의 셀들로 구성되어, 형성되는 것으로 고려되었다. 이 모델은 헤더(header)와 데이터 셀(cell)들로 더 차별화되고, 여러개의 줄과 컬럼이 확장(span) 될 수 있게 하였다.

[CALS]) 표 모델에 따라, 이 규격은 표의 열들이 머리글, 본체와 바닥글 항목들로 구룹지워 질 수 있게 하였다. 이는 정보의 표현을 간단히 한다. 표의 머리글과 바닥글 열을, 표가 페이지 경계에서 끊어 질 때, 또는 굴리(scroll)는 본체 창 상부에 고정된 헤더(header)가 제공 될 때, 반복하여 사용 될 수 있다. 작성(markup)에서는 바닥글(foot) 항목은 본체(body) 항목들보다 먼저 위치한다. 이것은 대단히 긴 표를 처리하기 위하여 최적화를 CALS의 것과 같이 방법을 쓴다. 모든 표의 처리를 기다릴 필요 없이 바닥글(foot)의 표현을 허용한다.

접속성

시각 장애자를 위하여, HTML은 그래픽 사용자 인터페이스에 기초한 윈도우의 채용으로 유발되는 피해를 개선하도록 희망을 제공한다. 음성으로 변환하는 고 품질 텍스트를 지원하기 위하여, HTML 표 모델은 각 셀(cell)의 라벨(label)링을 위한 애트리뷰트를 포함했다. 데이터베이스(database)나 스프레드쉬트(spreadsheet)로부터 표 데이터의 자동적인 수입(import)과 수출(export)을 지원하기 위하여 이들 애트리뷰트들이 또한 사용된다.

B.5.2 추천되는 배치 기능(layout algorithm)

만일 COL 또는 COLGROUP 엘레멘트(element)가 있다면, 이것들은 컬럼들의 갯수를 지정하고, 그 표는 고정 된 배치(fixed layout)를 사용하여 표현 될 것이다. 그렇지 않으면, 아래 설명 된 자동 배치 기능(autolayout algorithm)이 사용 될 것이다.

만일 width 애트리뷰트 가 설정되지 않았으면, 보는(visual) 사용도구는 양식화에 디폴트 값인 100%로 간주해야한다.

셀(cell)의 내용들은, 그렇지 않으면 넘치는 경우, 사용도구가 표의 너비를 width에 의하여 지정 된 값 이상으로 증가시킬 것이 추천된다. 지정 된 너비를 덮어 씌우는 사용도구는 이유있는 범위 안에서 그렇게하여야 한다. 사용도구는 과도 한 수평 굴리기(scroll)를 피하기 위하여, 또는 그런 굴리가 적당하지 않거나 바람직하지 않을 때, 단어들을 다음 열들로 자를 수 있다.

배치(layout)의 목적을 위하여, 사용도구는 셀들과 같이 작용하는 CAPTION 엘레멘트에 의하여 지정되는 표의 제목(caption)들을 고려하여야 한다. 각 제목은 확장(span) 된 한개의 셀(cell)이며, 만일 표(table)의 위쪽이나 아래쪽이면 표의 컬럼들이고, 표의 왼쪽이나 오른쪽이면 열들 이다.

고정 배치 기능(layout algorithm)

이 기능에서는, 컬럼(column)의 갯수가 알려진 것으로 가정하고, 컬럼 너비들은 디폴트로 같은 크기로 설정된다. 제작자는 COLGROUP 또는 COL 엘레멘트(element)를 사용하여 상대 또는 절대 컬럼 너비를 지정하여 덮어 씌울(override) 수 있다. 표(table)의 디폴트 너비는 현재의 왼쪽과 오른쪽 마진(margin)들 사이의 공간이다. 이를 TABLE 엘레멘트의 width 애트리뷰트(attribute)로, 또는 지정 된 절대 컬럼 너비로 덮어 씌울(override) 수 있다. 절대와 상대 컬럼의 혼합 너비들을 다루기 위해, 첫번째 단계로, 표 너비를 절대 너비를 가진 컬럼들의 너비에 공간을 할당하는 것이다. 그 후, 나머지 공간을 상대 너비를 가진 컬럼들 사이의 너비를 분배한다.

표(table) 문법 단독으로는 애트리뷰트 값의 일관성을 보증하기에는 불충분하다. 예를 들어 COL과 COLGROUP 엘레멘트의 갯수는 표의 셀들에 의해 의미하는 컬럼의 갯수와 맞지 않을 수 있다. 걸럼들의 너비가 셀(cell)의 내용의 넘처 흐름(overflow)을 피하기에 너무 좁을 때 발생하는 문제가 있다. TABLE 또는 COL 엘레멘트에 의하여 지정 된 표의 너비는 셀 내용(content)의 넘처 흐름을 초래 할 수 있다. 사용도구들은 이와 같은 상황에서, 우아하게 회복하도록 시도 할 것을 추천한다. 예를 들어, 단어에 하이픈(-) 넣기(hyphenating)에 의한 것과 하이픈 넣은 위치를 모를 때 분리된 단어들을 재배치 시킴 등이 있다.

개별 엘레멘트가 셀의 넘처 흐름을 유발 시킬 경우, 사용도구는 컬럼 너비의 조정하고, 표를 다시 표시하는 것을 고려 할 수 있다. 만일 컬럼 너비 조정과/이나 굴리는(scrollable) 셀 내용이 가능하지 않을 때, 최악의 경우, 잘라냄이 고려 될 수 있다. 어느 경우나, 셀의 내용이 분리(split)되거나 잘라(clip)지면, 이것을 사용자에게 적당한 방법으로 알려야한다.

자동 배치 기능(autolayout algorithm)

만일 COL과 COLGROUP 엘레멘트(element)에 의하여 컬럼(column)들의 갯수가 지정되어 있지 않으면, 사용도구들은 다음 자동 배치 기능을 사용하여야 한다. 이는 표(table)의 데이터를 통해 두 단계를 사용하고 표의 크기를 길이로 계산한다.

첫번째 단계, 자동 줄바꿈(line wrap)이 않은 상태에서, 사용도구는 각 셀(cell)의 최소와 최대 너비를 찾아낸다. 최대 너비는 가장 긴 줄에 의하여 주어진다. 자동 줄바꿈이 중지되었으므로, 문단들은 BR에 의하여 강제 줄바꿈되지 않는 한 긴 줄로 처리된다. 최소 너비는 앞에 나오는 목록(list)의 들여쓰기와 불렛(bullet) 등을 포함하여 가장 긴 엘레멘트(단어, 이미지, 등)에 의하여 주어 진다. 자신의 창 안에서 셀의 넘처 흐름(overflow)이 시작되기 전에 요구되는 최소 너비를 결정하는 것을 말한다. 사용도구에 단어 분리(split)를 허용하는 것은 수평 스케이링의 필요를 최소화하고, 또는 최악의 경우 셀 내용의 자르기(clip)를 한다.

이 과정은 셀의 내용(content)에서 네스트(nest) 된 표에도 적용된다. 네스트 된 표에서 셀들의 최소와 최대 너비들은 표들의 최소와 최대 너비들과 모체(parent) 표의 셀(cell) 자체 너비를 결정하는데 사용된다. 이 기능은 셀 내용의 선적(linear) 집합(aggregate)이며, 넓게 말해서 네스팅의 깊이(단계)에는 관계가 없다.

셀 내용의 글자 정렬(alignment)을 달성하기 위하여, 이 기능은 각 컬럼에 작동하는 세가지 최소/최대 합계들을 보유한다. 이 세가지들은 글자 왼쪽 정렬, 글자 오른쪽 정렬과 정렬 안됨이다. 컬럼의 최소 너비는 max(min_left + min_right, min_non-aligned)(의미는 최소 왼쪽 정렬 + 최소 오른쪽 정렬과 정렬 않된 것 중 큰 수치)이다.

셀들의 최소와 최대 너비들은 상응하는 컬럼들의 최소와 최대 너비들 결정하기 위하여 사용된다. 이들은 다시 표의 최소와 최대 너비를 결정하는데 사용된다. 셀들은 네스트(nest) 된 표를 가질 수 있는데, 코드를 현저히 복잡하게 하지 않는다. 다음 단계는 현재 왼쪽과 오른쪽 마진들 사이의 가용 공간에 따라 컬럼 너비들을 지정하는 것이다.

여러 컬럽들에 확장(span) 된 셀을 위하여, 간단한 접근은 최소/최대 너비들을 각 구성 컬럼들에 균일하게 배분하는 것이다. 약간 더 복잡한 접근은 확장(span) 된 너비들이 어떻게 배분되었는가하는 비중에 따라, 확장되지 않은 셀들에 최소/최대 너비들을 사용하는 것이다. 실험들은 이 두가지 접근의 혼합으로 폭 넓은 표들에서 좋은 결과를 얻을 것이라는 것을 말해 준다.

표 테두리(border)와 셀사이 마진(margin)들이 컬럼 너비 지정에 포함 될 필요가 있다.

이 할당 과정이 네스트(nest) 된 표에, 첫번째 과정에서 나뉘어진 모든 표(table)의 최소와 최대 너비들을 사용하여, 반복된다. 이런 경우, 모체(parent) 표 셀의 너비가 위에 기술 된 창(window) 크기의 기능을 한다. 이 과정이 모든 네스트 된 표에서 반복적으로 되풀이 된다. 그런 후 가장 상위의 표가 주어진 너비를 사용하여 표현된다. 네스트 된 표가 모체 표의 셀 내용으로 후속 표현된다.

만일 표의 너비가 width 애트리뷰트로 지정되었으면, 사용도구는 이 컬럼 너비를 설정하기를 시도한다. 컬럼들의 너비가 개별 컬럼의 최소 너비보다 작으면 width 애트리뷰트는 무시된다.

만일 COL 엘레멘트로 상대 너비들이 지정되었으면, 이 기능은 컬럼 너비들을 상대 너비 내용에 맞추기 위하여, 최소 너비 이상으로 증가하도록 수정된다. COL 엘레멘트는 암시로만 받아져야 함으로, 컬럼들은 그들의 최소 너비보다 작게 설정되지 못한다. 마찬가지로, 표가 창의 범위를 넘도록 넓게 컬럼들은 만들어 질 수 없다. 만일 COL 엘레멘트가 상대 너비를 0으로 설정하면, 그 컬럼은 항상 그 최소 너비를 설정하여야 한다.

이 두 과정의 배치 기능을 사용 할 때, 명시적 또는 전달된(inherited) charoff 애트리뷰트가 없으면, 디폴트 정렬 위치는 align="char"를 갖는 컬럼 안에서 어느 줄(line)에서나 정렬(alignment) 글자 앞과 뒤에 오는 그 너비들이 최대 값들을 갖고 줄들을 중앙에 오게하는 위치를 선택할 수 있다. 점진적 표 배치의 디폴트는 charoff="50%"로 제안되었다. 같은 컬럼의 다른 여러 열(row)들이 글자 정렬을 사용하면, 어느 글자가 정렬에 사용되었는가에 관계 없이, 디폴트로, 모든 그렇한 셀들은 줄을 맞추어야한다. 명시적 또는 암시적 정렬이 데이터가 컬럼에 지정 된 너비를 초과하는 상황이 발생되면, 다루는 오브젝트(object)들이 컬럼에 너무 클 때의 규칙이 적용된다.

애트리뷰트 이름(name)의 선택. frame 애트리뷰트의 값을 선택하면 rules 애트리뷰트에 정렬(alignment)에 사용되는 값, 예를 들어 none, top, bottom, topbot, left, right, leftright, all등 을 구성하는 것이 선호된다. 불행하게도, SGML은 각 엘레멘트에 유일하고, 그 애트리뷰트 이름에 영향을 받지 않는, 숫자가 주어진 애트리뷰트 값을 필요로한다. 이 는 "none", "left", "right" and "all"에서 즉시 문제를 일으킨다. frame 애트리뷰트의 값들은 rules, align, valign 애트리뷰트와 충돌을 피하기 위하여 선택되어 왔다. 이 규격의 향후 버전에서 frame와 rules 애트리뷰트가 다른 table 엘레멘트들에 추가 될 예정이므로, 이는 향후에 대 한 안전성을 제공할 것이다. 하나의 대체 방법은 frame을 만드는 CDATA이다. W3C HTML 워킹구룹(Working Group)은 번호 매겨진 값에 기초하여 애트리뷰트를 점검하는 SGML 점검 도구(validation tool)를 사용할 수 있는 잇점들을 위한 확실한 이름의 필요성이 비중을 잃었다는 것을 공감했다.

B.6 입력 폼(form)에 대한 주석

B.6.1 점진적 디스플레이(incremental display)

네트워그(network)로 부터 받아지는 문서의 점진적 디스플레이는 폼의 견지에서 어떤 문제를 일으킨다. 송신(submit)되는 폼이 폼 엘레멘트들를 모두 받을 때 까지 사용도구는 문제를 방지하여야 한다.

문서의 점진적 디스플레이는 탭에 의한(tabbing) 항해에서 몇 가지 문제를 일으킨다. 문서의 tabindex에서 가장 낮은 값으로 초점(focus)이 주어진 계통(heuristic)은 처음에는 합리적으로 보인다. 그러나 이는 문서의 텍스트를 모두 받을 때 까지 기다려야 한는 의미를 내포하는데, 이는 그 때까지는 가장 낮은 값의 tabindex는 계속 변경 될 수 있기 때문이다. 만일 사용자가 그 전에 탭 키를 누르면, 사용도구가 현재 가능한 가장 낮은 tabindex 값에 초점을 주는 것은 당연 할 것이다.

만일 폼이 사용자측(client-side) 스크립트(script)와 연관되어 있으면, 다른 문게가 발생 될 수 있다. 예를 들어 스크립트 처리자(script handler)는 주어진 필드(field)를 조회하는데, 존재하지 않는 필드를 조회 할 수 있다.

B.6.2 향후 프로젝트

이 규격은 일반적인 폼(form)의 제작을 수행하는데 충분히 강력한 엘레멘트(element)와 애트리뷰트(attribute)의 세트를 정의한다. 그러나 아직 개선의 여지는 많이 남아 있다. 다음은 향후 검토 될 문제들이다.

하나의 가능한 확장은 "type=image" 일 때 사용자측(client-side) 이미지맵으로 사용하기 위하여 INPUT에 usemap 애트리뷰트 의 추가 될 것이다. AREA 엘레멘트는 클릭 된 해당 지역의 값을 서버에 전달하는데 사용된다. 서버측 스크립트(script)의 변경을 피하기 위해서, INPUT 엘레멘트와 함께 사용 할 수 있도록, AREA에 x 와 y 값을 제공하여 확장하는 것이 합당 할 것이다.

B.7 스크립팅(scripting)에 대한 주석들

B.7.1 향후 스크립트(script) 마크로(macro)들을 위한 예약 문법

이 규격은 향후 스크립트 마크로를 HTML CDATA 애트리뷰트 안에서 지원하기 위한 문법을 예약하고 있다. 그 의도는 페이지에서 앞에 나온 오브젝트의 특성에 따라 애트리뷰트를 설정되도록 허용하는 것이다. 그 문법은:

현재 스크립트(script) 마크로(macro)들의 사용 상태

마크로(macro) 본체는 본질적 이벤트 애트리뷰트에 따라, 디폴트 스크립트(script) 언어로 된 한개 이상의 문장으로 만들어 진다. 쎄미콜론(;) 다음의 "{"는 항상 필요하며, 오른쪽 "}" 까지 마크로의 본체(body)로 처리된다. 따옴 표시도 스크립트 마크로를 포함하는 애트리뷰트에 항상 필요하다.

문서가 로드(load)되고, 문서의 다시 크기 지정, 다시 색칠하기 등이 일어나기 전에, 마크로 처리가 일어난다.

불량한 예제:
Javascript를 사용한 예제. 첫번째 것은 문서의 배경색을 무작위 수로 하는 것이다.

<BODY bgcolor='&{randomrbg};'>

저녁에 보기 위하여 배경색을 어둡게하기를 원하여,

<BODY bgcolor='&{if(Date.getHours> 18)...};'>

다음 예제는 사용자측(client-side) 이미지맵의 좌표(coordinate)를 설정하려고,

<MAP NAME=foo>
  <AREA shape="rect" coords="&{myrect(imageuri)};"
	href="&{myuri};" alt="">
</MAP>

다음 예제는 문서 특성에 따라 이미지 크기를 지정한다.

<IMG src="bar.gif" width='&{document.banner.width/2};'
	height='50%' alt="banner">

연결을 위 한 URI 지정 또는 스트립트에 의한 이미지 지정이 가능하다.

<SCRIPT type="text/Javascript">
  function manufacturer(widget) {
      ...
  }
  function location(manufacturer) {
      ...
  }
  function logo(manufacturer) {
      ...
  }
</SCRIPT>
 <A href='&{location(manufacturer("widget"))};'>widget</A>
 <IMG src='&{logo(manufacturer("widget"))};' alt="logo">

마지막 예제는 SGML CDATA 애트리뷰트가 단일 또는 이중 따옴표를 사용하여 어떻게 인용 될 수 있는가를 보여 준다. 만일 애트리뷰트 문자열 주위에 단일 따옴표를 사용하면, 애트리뷰트 문자열(string) 부분에는 이중 따옴표를 포함 시킬 수 있다. 다른 방법은 이중 따옴표를 위하여 "를 사용하는 것이다.

<IMG src="&{logo(manufacturer(&quot;widget&quot;))};" alt="logo">

B.8 프레임프레임(frame)에 대한 주석

프레임(frame) 목표(target) 이름이 유일(unique)하다는 보장이 없으므로, 프레임에서 주어진 목표 이름 찾기의 현재의 사용 방식을 설명하는 것이 좋을 것이다.

B.9 접속성에 대한 주석들

B.10 보안에 대한 주석

URI를 파라메터(parameter)로 갖는 앤커(anchor), 깔린(embedded) 이미지와 모든 다른 엘레멘트들은 사용자의 입력에 반응하여 URI의 참조 철회(dereference)를 발생시킬 수 있는, [RFC1738, 항목 6]의 보안 문제를 고려하여야 한다. 널리 사용되는 폼의 송신(submit) 요청하는 HTTP와 SMTP 방법은 비밀 유지를 조금 밖에 제공하지 못한다. 폼을 통해 예민한 정보를 요청하는 정보 제공자들은 특히 INPUT 엘레멘트의 type="password"로는 비밀 유지에 불충분하다는 것을 알고 그들의 사용자도 알게하여야 한다.

B.10.1 폼의 보안 문제

사용도구는 사용자가 확실히 보내기를 요청한 것이 아니면 화일로 보내지 말아야한다. 그래서 HTML 사용도구들은 INPUT 엘레멘트의 value 애트리뷰트로 제안되는 디폴트 화일 이름을 확인 할 것을 기대한다. 감추어진(hidden) 제어에는 화일을 지정하지 말아야한다.

이 규격에는 데이터의 암호화(encryption) 기능이 포함되어 있지 않다. 이는 데이터의 안전한 송수신을 위하여 다른 어떤 기능(mechanism)으로도 처리 될 수 있다.

처리 대리자는 화일이 읽혀지면, 적절하게 처리하고 저장하여야 한다.

이

문서(http://trio.co.kr/webrefer/html/attendix/notes.html)는 자유로이 연결 사용이 가능함.

부록 B: 성능, 적용과 디자인 주석들

B.1 유효하지 않은 문서들에 대한 주석들