위키백과 대화:Manual of Style/Archive 17스타일/아카이브 설명서 17

이것은 과거 토론의 기록이다. 이 페이지의 내용을 편집하지 마십시오. 새로운 토론을 시작하거나 오래된 토론을 다시 시작하려면 현재 토크 페이지에서 다시 시작하십시오.

아카이브 10

←

아카이브 15

템플릿:토크라이트

나는 이 템플릿이 일부 편집자들의 손해와 다른 사람들의 기쁨에 이용되고 있다는 우려를 표명하고 싶다. 나는 우리가 TOC의 배치를 편집하지 말아야 한다고 생각한다. 왜냐하면 a)는 페이지의 맨 위에 있기 때문이다. 스타일 관점에서 페이지 오른쪽에 이미지를 배치하는 것이 가장 좋다. 어떤 광고든 한 번 봐봐. 이것이 일반적인 관행이야. TOC를 맨 위에 있는 페이지의 오른쪽 맨 위에 놓는 것은, 단도직입적으로 말하면, 끔찍하다. 첫째, 리드 섹션을 부정하는 데 어느 정도 도움이 된다(리드 섹션이라는 것이 덜 분명해지고, TOC가 리드 섹션을 나열하지 않는 것 외에!). 또한, 우리의 큰 장점 중 하나는 일관성을 유지하는 것이다. 이 템플릿을 에 적용하면 Windows 2000이 인포박스를 없애기 때문에 허용되지 않을 것이라고 말한다. 이것은 나를 더 중요한 문제로 이끈다: 템플릿은 언제 사용되는가? 항상 기사 맨 위에? 마지막 섹션(극단점, 그러나 상승해야 함) 아래에서? 누군가가 템플릿을 변경하고 _NOTOC_를 추가하면 어떻게 되는가? 그것은 그것을 사용하는 모든 페이지에 영향을 미칠 것이다. 또한 - 만약 우리가 모든 페이지에 그것을 적용하기 시작한다면, 이것은 위키피디아에게 공연 문제를 야기하지 않을까? 이것은 유효한 지점이 될 수도 있고 아닐 수도 있다.

나는 또한 사람들이 합의를 얻지 못한 채 위키피디아의 기본 레이아웃에 변화를 강요하려 한다는 것에 대해 우려를 표하고 싶다(나는 이것에 대해 확실히 말한 적이 없고, W. Mark Felt에 적용되었을 때에만 그것을 알아차렸다 - 내가 그 페이지의 합리적으로 주요한 편집자로서 각주를 정리했기 때문에 내가 바꾼 것 - 나는 각주를 정리했다 - 나는 더 신중했다).그러한 급진적인 배치 변경에 대해 알고 있다). 만약 우리가 레이아웃을 바꾸려고 한다면, 그것은 주요 모노북 스타일시트에 있는 CSS를 통해 이루어져야 한다. 하지만 나는 이것을 바꾸려는 합의가 이루어지지는 않을 것이다. 간단히 말해서, 일부 편집자들이 TOC가 리드 섹션의 왼쪽에 있는 것을 싫어한다면, 그들은 개인 스타일시트를 수정해야 한다.

나는 이 페이지에서 이 문제를 해결하는 것을 보고 싶다. TOC와 같은 기본 요소 변경에 관한 사항 - 2005년 7월 5일 02:36(UTC)

콜 포 모스

디폴트는 정확히 디폴트, 디폴트다. 그것들은 우리가 변화를 만들지 않을 때 얻을 수 있는 것이다. 편집 도구를 사용할 수 있다. TOC 배치를 변경할 수 없다면 소프트웨어가 이 기능을 제공하지 않아야 한다.

개인 CSS에 있는 개인에 의해 변경되어야 한다는 당신의 주장 또는 내가 생각하는 기본 VSS 스타일시트에 의해 변경되어야 한다는 당신의 주장은 무효라고 생각한다. 기본 스타일시트에서 이 작업을 수행해서는 안 된다. 왜냐하면 이는 오류에 대한 변경을 의도하는 것이 아니라 특정 기사에 대한 형식 변경을 의도하기 때문이다. 그것은 특히 기사에 근거한 기사에서 그러한 조정을 할 수 있는 방법을 알지 못하거나, 하지도 못하기 때문에, 특히 그것이 의도된 많은 독자들이 특별한 독자들의 모든 독자들을 위한 것이기 때문에, 독립된 개인 CSS에서 수행되어서는 안 된다.

즉, 이것은 스타일에 관한 것이며, 템플릿의 사용 시기와 방법에 관한 스타일 가이드라인을 통해 IMO가 있어야 한다.TOCright 및 템플릿:TOC왼쪽. 예를 들어, TOC가 구간 경계를 넘도록 그것들을 배치하는 것은 아마도 좋지 않은 생각일 것이다. 템플릿:인접한 텍스트가 글머리표 목록의 일부인 경우 TOCleft는 잘 보이지 않는다. 보다 일반적으로, 이러한 임시직은 TYOC가 길지만 넓지 않을 때 사용되며, 대부분의 경우 리드 섹션 또는 리드 단락 이후에 더 잘 사용될 수 있다.

나는 이것이 여기서 논의되어야 한다고 생각한다. 가능하다면 우리는 합의에 도달해야 하고, 적절한 MOS 섹션이 기본이 아닌 TOC 배치: 언제 그리고 어떻게 해야 하는지에 대해 쓰여야 한다. DES 5 2005년 7월 16:47(UTC)

페이지 레이아웃

나는 이 선택권을 갖는 것이 좋다. 출판할 때, 사람들의 사진은 항상 페이지의 중앙, 텍스트 쪽을 보아야 한다. 왜냐하면 독자의 눈은 신체, 얼굴 또는 눈의 방향에 끌리고 우리는 독자의 눈이 텍스트 쪽으로 이동하기를 원하기 때문이다. 그러므로 우리는 사진이 항상 왼쪽을 바라보는 사진을 찾는 것이 항상 가능한 것은 아니기 때문에 사진이 항상 상단 측면에 있어야 한다는 규칙을 가지고 있어서는 안 된다. 만약 우리가 오른쪽으로 보이는 사진만 있다면, 그것은 페이지의 왼쪽에 있을 것이다. 왼쪽에 있는 사진이 있으면 TOC가 오른쪽이 더 잘 보일 수 있으니, 그건 좋은 선택이다. 일부 기사에서는 특히 긴 TOC를 가진 백색 공간을 모두 갖추기보다는 오른쪽에 TOC를 삽입하는 것도 좋다. 그러므로 나는 편집자에 대한 이러한 선택사항들이 기고자들의 창의적인 입력뿐만 아니라 내용을 향상시키는 것으로 본다. SlimVirgin 2005년 7월 5일 17:13(UTC)

고마워, 난 전적으로 동의해. 그것이 내가 TOCrift와 정확히 평행하게 TOCleft를 만든 이유다. DES 5 2005년 7월 17:25(UTC)

그렇게 해줘서 고마워. 편집이 더 재미있고, 배치 결정을 내릴 수 있다는 걸 알게 됐어. 나는 페이지를 보기 좋게 만들려고 노력해서 많은 만족감을 얻는데, 그것은 또한 본문을 더 좋게 만들고 싶게 만든다. SlimVirgin 2005년 7월 5일 17:46(UTC)

위키피디아 페이지와 같은 웹 페이지를 잡지 페이지에 비유하는 것은 결함이 있으며, 그 결함은 교훈적이다. 바운드된 잡지는 외측 여백, 이미지에 바람직한 여백, 페이지가 사라지는 도랑이라 불리는 중앙 여백을 가지고 있다. 이 중심 위치에 있는 이미지는 "잘 다듬어진 것"이라고 하며, 가독성과 외관이 훼손된다. 웹 페이지는 정확하지도 않고 완전 중립적이지도 않다. 이미지가 오른쪽 가장자리나 오른쪽 상단 모서리에 있어야 한다고 주장하는 사람들은 잘못 알고 있다. 단지 권위주의적인 훈련이나 현재의 권위를 행사하고 있을 뿐, 때로는 좋은 배치의 대가를 치르고 있을 뿐이다. --Wetman 2005년 7월 5일 18:07 (UTC)

그 비유는 불완전하지만 장점이 완전히 없는 것은 아니다. 페이지[1](Monobook + 몇 가지 사용자 스타일)를 보면 직사각형 느낌이 꽤 선명하다. 나는 모노북을 사용하는 대부분의 사람들이 내가 틀릴 수도 있지만 이런 식으로 인식할 것이라고 의심한다. 어쨌든, 나는 모든 페이지에 어떤 절대적인 기준을 가하는 것은 불합리하다는 것에 동의한다. 그러나 위키피디아 디폴트보다 우선하는 것이 적절하고 적절하지 않은 시기에 대한 지침이 있어야 한다. 도입 텍스트가 많지 않은 본질적으로 긴 리스트인 페이지는 표준에서 벗어날 수 있는 좋은 후보일 것이다. —HorsPunchKid→2005년 7월 5일 19:43(UTC)

과연 한 사람이 틀릴 수도 있다. 이 편집자에게 있어, 맨 위에 묶인 메모장조차도 "정확한 느낌"을 갖게 될 것이다. 그렇다면, 냉장고 문에 있는 자석은 어떨까? 좌회전이나 우전 개방은 거기서도 차이가 난다. 사실은 어떤 안정적이고 고립된 직사각형 형식 안에 네 개의 초점들이 있다는 것이다; 거기에는 먼저 눈 다트, 그리고 위키피디아 페이지는 직사각형 그림 같은 것이다. 그러면 책에 묶인 페이지보다, 한쪽 면에 홈통이 있는 여행 포스터를 생각해 보라. 자신의 역량의 최첨단에 도달함에 따라 자신감을 고삐를 죄기 시작할지도 모른다.... 하지만 내가 틀릴 수도 있다. --Wetman 23:16, 2005년 7월 30일 (UTC)[]

미안해, 내가 확실히 알진 못했나 봐. 그 페이지는 왼쪽에 큰 거터가 있어서 내게 딱 맞는 것 같다. 내가 하려던 말은 그게 다야. 내 스타일시트가 약간 비표준인 건 알지만, 내가 기억하기론 디폴트 모노북 스타일도 왼쪽에는 이 엄청난 마진이 있다. 주요 내용 영역은 확실히 고립된 사각형이 아니다! —HorsPunchKid→1906:23, 2005년 8월 6일(UTC)[]

자신의 역량의 가장자리에 도달하면서, 자신감을 고삐를 죄기 시작할지도 모른다.... 하지만 내가 틀릴 수도 있다. — 그런데, 이 논평의 요점이 정확히 무엇이었습니까? —HorsPunchKid→1905년 8월 7일(UTC)[]

플로팅 TOC

6월 29일에 위키피디아에서 떠다니는 TOC의 사용에 관한 섹션을 만들었다.섹션#Floating_the_TOC. 필요한 변경 사항을 언급하고 제안하십시오. —2005년 7월 5일 18:14(UTC)

Mike, TOC에 대한 토론을 연결해줘서 고마워. 나는 이미 TOCright와 관련하여 현재 삭제 제안서에 대한 코멘트를 했었다. 부유물에 대한 당신의 논의는 상당히 냉철해 보이며, 오른쪽(또는 왼쪽)에 위치하는 것이 효과적일 수 있고 그렇지 않을 수도 있는 시나리오를 추천한다. 그러나, 현재, 옳든 그르든 간에, 오른손잡이를 단순히 일반적으로 "더 좋아 보인다"고 느끼는 편집자들이 있다.어떤 기사에든. 신중하게 생각한 스타일의 지침 문서가 템플릿의 용도에 쓰여질 수 있다면, 나는 내 개인적인 투표 재 템플릿을 다시 생각할 수 있다(현재 '삭제'). 나는 위의 사람들이 a) 개인적인 주관성이 어떤 기사에 들어가 (Wetman 참조)와 b)에 동의하는 것처럼 보이기 때문에 그러한 문서는 오직 일반적인 지침이 될 수 있을 것이라고 생각한다. 그것은 적어도 그것을 재정비한 위키피디아 편집자들 이외의 편집자들의 관점에서 기사를 개선하는데 실패할 뿐만 아니라 페이지를 '나를 보기 위해' 페이지를 만들 수 있는 잠재력을 가질 것이다.과반수까지? 화이트호스1 2021년 10월 4일 00:07(UTC)

제안사항: 현재 WP에서 논의 중인 시간 고려:TFD, 그리고 이 토론이 이미 얼마나 길어졌는지, 두 토론 모두 별도의 위키백과 기사에 베끼는 것이 아마도 가장 좋을 것이다. 특히 이 토론은 아마도 이 문제에 대한 위키백과 정책을 수립하게 될 것이기 때문에, 이 토론이 별도의 페이지에서 이루어져야 하는 또 다른 이유일 것이다.

이 문제에 대한 나의 개인적인 의견은 길고 좁은 TOCs에서 오는 많은 양의 하얀 공간이 싫다는 것이다. 템플릿의 사용이나 소프트웨어의 변경을 통해서 TOC를 "플로팅"할 수 있는 어떤 방법이 있는 한 TOC가 왼쪽이나 오른쪽으로 끝나더라도 나는 정말로 신경 쓰지 않는다. (위키미디어 소프트웨어가 변경되었다면, TOC에서 섹션의 디스플레이를 제어할 수 있는 것도 좋을 텐데, 따라서 1단계와 2단계만 디스플레이 한다고 말할 수 있을 것이다. 확실히 그것을 위조할 수 있는 방법은 있지만, 그건 정말 엉터리인 것이다.) BlankVers ∅ 2005년 7월 5일 22:05(UTC)

나는 100% 동의한다. 그 물건을 띄우고, 그 주위에 텍스트를 싸서 바삭바삭한 액자와 그것을 시작하기 좋은 깨끗한 하얀 여백을 남겨라. (서명하는 것을 잊어버렸다: Wetman 00:29, 2005년 7월 14일 (UTC)[]

처음에 나는 그것에 반대했지만, 그것의 사용의 좋은 예들을 보았다. 나는 정말로 그것이 마지막 수단이 되어야 한다고 생각하고, 주로 큰 TOCs가 있는 긴 목록에만 사용하였다. 바이올렛/리가 (t) 2005년 7월 5일 23:48 (UTC)

(위에 응답하여 다음 섹션 디바운드에 상대적인 코멘트를 옮기지 않도록) 내가 이것을 보듯이 제목줄은 이미지에 못미쳐 정지하고, 약간의 공백이 있고, 그 다음엔 이미지가 있다. 나는 IE 6 (직장에서)와 AOL 전화 접속 (집에서)과 기본 위키백과 디스플레이를 사용하고 있다. DES 6 2005년 7월 02:01(UTC)

모노북의 제목줄이 템플릿을 "컷"함

오른쪽의 이미지를 참조하십시오. 제목줄이 템플릿을 "컷"한다. 이걸 어떻게 정리하지? 이 템플릿에 대해 알아낼 수 있다면, 템플릿도 분류해보고 싶다.같은 일을 하는 이슬람교. - 2005년 7월 6일 00:10(UTC)

나는 네가 "바보에서 벗어났다"고 생각하기 시작했어. 악의는 없어. :-) 네 말을 오해하지 않는 한, 나는 어떤 절삭도 볼 수 없어. TOC는 전체적이며 그 이미지에서 잘려지지 않는다. 어쩌면 당신이 정말로 원하는 것은 TOC 주위의 여백으로 헤딩 라인이 TOC에 닿지 않도록 하는 것이 아닐까? 나는 사실 그것이 보이는 방식이 마음에 들지만, 그것은 단지 나의 스타일 선호다. —2005년 7월 6일 03:28 (UTC)

미안, 가끔 상황이 어떻게 보이는지 설명하기가 힘들어 :-) 악의는 없어 (내가 미쳤을 가능성이 꽤 있어...)! 하지만, TOC를 통과하기 위해 노력한 결과, 사후적 고려로 간주되는 것 처럼 보이게끔... 템플릿과 동일:이슬람교. TOC는 이제 정리된 것 같아... - 2005년 7월 7일 00:01 (UTC)

나는 Mike가 정확히 알고 있다고 생각한다: TOC의 주위에 마진이 있으면 줄이 그 아래로 가는 것을 막을 수 있고, 마찬가지로 텍스트가 그것에 부딪치는 것을 막을 수 있다. 훨씬 더 멋져 보이는 (그리고 그것은 개인적인 주관성!) --Wetman 00:29, 2005년 7월 14일 (UTC)[]

내가 주목한 것은 '특수' 페이지(토크 페이지나 위키프로젝트 페이지 등)에서 부동 TOC를 사용할 때 마진이 흰색으로 하드코딩되고, 배경이 연청색일 때는 그저 잘못 보일 뿐이라는 점이다. 그것을 고칠 방법은 없을까? -- Titoxd 00:48, 2005년 7월 14일 (UTC)[]

나는 그것을 작동시키려 하기 전에 그것을 만지작거렸고 모노북에 대한 CSS 변경이 필요할 것이라는 결론을 내렸다. 어떤 이유에선지 모노북 스타일은 "특별한" 페이지에 다른 색을 사용하는 유일한 스타일이다. 내 공책에 있는 연한 파란색은 보통 흰색과 거의 구분할 수 없다. (대비를 보려면 화면을 비스듬히 기울여야 한다.) —Mike 06:44, 2005년 7월 21일 (UTC)

사용 시기 및 방법

이 템플릿을 정확히 어떻게 구현해야 하는지에 대한 기술적인 문제는 남겨두고, 언제 어떻게 사용해야 하는지에 대한 스타일 질문으로 돌아가자. 여기 있는 대부분의 사람들은 그것이 어떤 기사에서는 좋은 생각이고 다른 기사에서는 나쁜 생각이라는 것에 동의하는가? 모든 기사 또는 거의 모든 기사에 기본 스타일이 되어서는 안 되며, 금지되어서도 안 된다는 것? 그게 리스트에서 특히 잘 작동한다고? TOC가 길고 비교적 좁은 기사에서는 좋은 생각이 되고, TOC가 짧거나 넓거나 둘 다인 기사에서는 좋지 않은 생각이 되는 경향이 있다고? 위치는 어때? 이 템플릿은 일반적으로 리드 섹션 다음에 TOC를 띄우기 위해 사용해야 하는가, 아니면 이차 단락 뒤에 최대한 빨리 띄워야 하는가? 그리고 병렬 템플릿 템플릿:TOCleft]는 왼쪽의 TOC를 제외하고 정확히 동일한 방식으로 작동하고 사용되도록 되어 있다. 이것은 언제 고소되어야 하는가? 오른쪽 위에 이미지가 있을 때?

두 템플릿 모두 한 구역 경계선을 넘지 않을 때 더 보기 좋아 보이지만, 그것은 종종 가능하지 않다.

사람들은 이 문제에 대한 MOS 엔트리나 섹션이 있어야 한다는 것에 동의하는가?

이런 스타일의 이슈에 대해 발표해 주시겠습니까? DES 6 2005년 7월 17:26 (UTC)

폭 정의

우선, 나는 이 논의가 MoS 가이드라인이 제정되어야 할 지경에 이르렀다는 것에 동의한다. 하지만 어떤 토론이 시작되기 전에, 우리는 적어도 우리가 동의하는 것에 대한 지식을 가져야 한다.

이러한 템플릿을 가질 필요가 있다는 DES의 의견에 동의하며, 이러한 템플릿이 위키의 TOCs의 디폴트가 되어서는 안 된다는 의견과, 내 의견으로는 이미지와 목록이 있는 페이지로 제한되어야 한다는 의견(이것은 내가 융통성이 있다)에 동의한다.

만약 TOCs에 어떤 변화가 일어난다면, 나는 우리 모두가 좋은 미학을 유지하기 위해 그것들이 떠야 한다는 것에 동의한다고 믿는다. 템플릿 사용에 대한 MoS 요구 사항:TOCleft 및 템플릿:TOCright는 성가신 공백을 최소화하는 방식으로 구현되어야 한다. 우리 모두 괜찮니?

자, 자세한 것부터... 뷰어 화면의 30%를 초과하지 않는 템플릿(네비게이션 사이드바 포함 안 함)을 사용하는 경우? 이 값을 초과할 경우 TOC가 너무 넓어 기본값을 사용해야 한다. 코멘트를 요청하고 권장한다. --Titoxd 2005년 7월 7일 03:01(UTC)

좋은 계획 같아 보인다. 나는 그것을 사이언톨로지 교리의 스페이스 오페라에 방금 추가했다. TOC는 길지만, 당연하게도 그렇다. 어때? - 2005년 7월 7일 04:47 (UTC)

내 생각을 완벽하게 이해한 것 같아. --Titoxd 2005년 7월 8일 03:34 (UTC)

나는 채무불이행 TOCs가 일반적으로 과시되어야 한다는 것에 동의한다. 그리고 어떤 경우에도 나는 이 토론이 부동 TOCs로 제한된다고 생각한다. 나는 결코 비표준적이고 부동의 TOC를 위한 장소가 없다고 절대 말하지 않을 것이다. 하지만 나는 아직 TOC를 보지 못했다. 나는 30% 폭 규칙(높이가 아닌 너비에 적용하는 것을 의미한다고 가정함)이 좋은 경험 법칙이라는 것에 동의하지만, 특히 글꼴 크기가 크거나 해상도가 낮거나 둘 다 있는 사용자는 대부분의 시청자들이 30%를 훨씬 밑도는 TOC가 자신의 특정한 경우에 더 많이 차지한다는 것을 발견할 수 있다. 내 생각에 그 규칙은 평균적이거나 그럴듯한 시청자에 대해 언급해야 한다. 아니면 어떻게든 이 사건을 처리해야 한다. DES 2005년 7월 7일 21:07(UTC)

그래, 대략적인 숫자로는 30%의 너비를 의미했으니까, 너무 많은 문자를 방해하지 않는 거야. 그러니 아무도 반대하지 않는다면, 그것은 MoS에 놓여야 한다. (나는 위키 신인이기 때문에, 더 많은 경험과 더 높은 지위를 가진 사람에게 그것을 하도록 하고 싶다.) 하지만 위키백과 사용자의 평균 화면 해상도가 무엇인지 아는 사람이 있는가? 1024x768을 사용하고 있는데, 요즘 최저한도는 800x600... --Titoxd 2005년 7월 8일 03:34 (UTC)

사이언톨로지 교리에 있는 스페이스 오페라가 너의 추가와 잘 어울린다고 생각한다. 그리고 이것은 TOC를 과시함으로써 이미지가 없는 기사가 개선되는 예다. DES 2005년 7월 7일 21:07(UTC)

사용자 설정에 따라 30%가 다르기 때문에 보다 안정적인 예와 비교하는 것이 도움이 될 수 있다. 위키백과 왼쪽 탐색 열, 페이지 상단 탭의 너비 또는 "요약 편집" 입력 필드의 끝과 비교해 보는 것은 어떨까? (SEWilco 06:35, 2005년 7월 10일 (UTC)[]

30%는 적어도 내 브라우저에서 왼쪽 탐색 모음 너비의 약 1 + 1/2 ~ 2배로 번역될 것이다. 다른 resoultion을 가진 다른 사람들의 결과가 다른지 모르겠다. -- Titoxd 07:14, 2005년 7월 10일 (UTC)[]

제안서 초안

마이크가 Section MoS에서 토론에서 가져온 몇 가지 문제들을 고려하여, 나는 그 MoS에 추가하기 위한 제안서 초안을 제출하고 있다. 아래 의견, 반대 의견 또는 지원을 자유롭게 입력하십시오. Titoxd 22:31, 2005년 7월 12일 (UTC)
[]

이 제안은 받아들여졌다(7개의 지지/1 반대). --Titoxd 20:34, 2005년 8월 12일 (UTC)[]

목차(TOC)는 경우에 따라 {{}}}을(를) 사용하여 오른쪽 또는 왼쪽으로 띄울 수 있다.TOCright} 또는 {{TOCleft}}. 기본 TOC를 부동 TOC로 변경하기 전에 다음 지침을 고려하십시오.

사용하지 않은 공백을 줄임으로써 기사가 이익을 얻을 수 있다면, 띄워라.
물건의 변화가 악영향을 받는다면, 떠다니지 마라.
TOC를 플로팅할 때 사용자가 TOC를 숨길 경우 페이지 레이아웃이 손상되는지 확인하십시오.
TOC는 띄우든 아니든 필요 이상으로 길어져서는 안 된다.
기본 TOC는 첫 번째 헤드라인 앞에 배치되지만 소개 텍스트 뒤에 배치된다(페이지의 편집자가 변경한 경우는 제외). 일반적인 사용자가 TOC의 상단을 보기 위해 아래로 스크롤해야 할 정도로 소개 요약이 길면 TOC를 띄울 수 있으므로 기사 상단에 더 가깝게 나타난다. 그러나 대부분의 경우 부동 TOC는 최소한 기사 텍스트의 첫 번째 단락을 따라야 한다.
TOC가 상대적으로 길고 좁은 경우, 기본 TOC는 TOC 옆에 상당한 공백을 생성한다. 그러한 경우 당신은 TOC를 띄우기를 원할 수 있다. 단, 단면 또는 서브섹션을 컴파일하여 TOC를 유용하게 단축할 수 있는지 여부를 고려해 보는 것이 좋다.
넓은 TOC를 띄우면 해상도가 낮은 사용자에게 읽기 쉬운 텍스트의 좁은 열이 생성된다. TOC의 폭이 사용자가 볼 수 있는 화면의 30%(왼쪽 위키백과 네비게이션 바의 약 2배 크기)를 초과하면 부동하기에 적합하지 않다. (백분율은 일반적인 사용자 설정을 가정한다.)
TOC를 다른 띄운 이미지나 상자 주변에 일반적으로 배치하는 경우, 흐르는 텍스트 열이 일반 사용자의 가시 화면 폭의 30%보다 좁아지지 않는 한 띄울 수 있다.
TOC를 긴 목록 페이지에 배치하려면 해당 페이지를 띄워야 한다.
좌변 TOC는 글머리표 또는 번호표에 영향을 미칠 수 있다. TOC가 있는 경우, TOC를 오른쪽으로 띄우거나, TOC를 띄우지는 마십시오.

지원

나는 이것을 서면처럼 지지할 수 있지만, 나는 우리가 계속해서 개선점을 제안하기를 바란다. DES 23:23, 2005년 7월 12일 (UTC)[]
지원: 이미지와 마찬가지로 TOC가 가장 적합한 곳에 배치될 수 있도록 편집자에게 TOC에 대한 제어력을 강화하십시오. (SEWilco 16:32, 2005년 7월 22일(UTC)[]
지원... 그러나 권위주의적인 훈련을 받고 시각적 감각이 없는 위키피디아인이 위키피디아에서 서식을 되돌림으로써 이 "가이드라인"을 어떻게 시행하는지 보라.위키티켓 경고#7월 30일. 본능적으로 공격적인 사용자들은 "가이드라인"을 공격적으로 적용할 것이기 때문에 "가이드라인"을 너무 많이 만드는 것은 항상 현명하지 못하다. --Wetman 23:29, 2005년 7월 30일 (UTC)[]
나는 그 페이지에 대해 논평했다. DES 02:36, 2005년 7월 31일 (UTC)[]
Strong Support 기본 레이아웃은 간단한 소개와 제한된 크기의 TOC를 가진 대부분의 기사에 사용되어야 하며, 사용되어야 한다. 이를 넘어, 기사의 가독성과 접근성에 도움을 주기 위해서는 레이아웃의 유연성이 요구된다. --Cactus.man 10:33, 2005년 8월 1일 (UTC)[]
지원, 그리고 우리는 언제나 돌아가서 고쳐야 할 것은 무엇이든 고칠 수 있다. --Titoxd 20:49, 2005년 8월 3일 (UTC)[]
지원 이것은 유용한 템플릿과 수동 추가입니다. -- Sitearm Talk 17:55, 2005년 8월 5일 (UTC)
지지하다.—펜스팔론 on ζ 07:58:05, 2005-08-08(UTC)

반대하다

첫 번째 문장에 대해 강한 반대(사용하지 않은 공백을 줄임으로써 기사가 이익을 얻는다면, 뜬다). 다음 사람들이 약간의 sence를 가져오려고 하는 동안, fisrt는 이 혐오스러운 것을 어디에나 놓을 수 있는 분명한 신호로, 몇 픽셀을 절약하기 위해 읽기 흐름을 방해한다. 파벨 보제닐렉 02:04, 2005년 8월 2일 (UTC)[]
- 텍스트의 흐름이 흐트러지면, 두 번째 지점으로 언급되는 기사에 「반대로 영향을 준다」(Titoxd 20:43, 2005년 8월 3일 (UTC)[]
이건 명령 소름끼치는 소리야 우리가 TOC를 띄울 가능성을 편집자들이 인식하게 하려면 MoS에 추가해야 할 것은 다음과 같은 간단한 문장으로, "일부 경우에는 목차(TOC)를 오른쪽이나 왼쪽으로 띄우는 것이 적당할 수도 있다.TOCright} 또는 {{TOCleft}}"상세적 가이드라인은 가이드라인으로 강화될 수 있는 근거를 제공한다. 만약 그러한 소문이 유용하다면(그리고 나는 그것들이 왜 그럴 수 있는지 알 수 있다) 그것들은 별도의 기사에 담길 수 있다. 위키백과:목차 부동표. —테오 (Talk) 16:07, 2005년 8월 2일 (UTC)[]
- 왜 이것은 편집자들이 찾는 것을 모를 수 있는 별도의 페이지에 있어야 하는가? MoS는 이미 날짜 형식, 단위, 전기 기사의 주소 제목 등과 같은 세부적인 제안과 지침으로 가득 차 있다. MoS 또는 그 하위 페이지 중 하나인 MoS는 이 IMO를 논의하기 위한 곳이다. 그 요점은 과시형 ToC의 선택권을 광고하는 것이 아니라, 그것이 언제 적절할 수 있고 적절하지 않을 수 있는지, 그리고 그것을 어떻게 해야 하는지를 제안하는 데 도움을 주어 기사를 손상시키지 않도록 하는 것이다. DES 17:16, 2005년 8월 2일 (UTC)[]

마감일자

이 논의는 이제 한 달이 지났다. 투표 종료 일주일 후(그리고 제안서를 MoS에 게시하고 통과될 경우 이 토론을 보관)에 반대하는 사람이 있는가? --Titoxd 22:42, 2005년 8월 5일(UTC)[]

나는 아래 "Misc" 섹션에서 코멘트를 옮겼는데, 거기서 나는 그것이 분실될지도 모른다고 생각했다.DES 22:53, 2005년 8월 5일 (UTC)[]
사실 나는 그 보다 더 빨리 간단히 MoS 엔트리를 만들 계획을 하고 있다는 충분한 지지가 증명되었다고 생각했지만, 공식적인 마감일이 제안되었기 때문에, 나는 그것을 받아들인다. DES 22:53, 2005년 8월 5일 (UTC)[]

Titoxd 22:31, 2005년 7월 12일 (UTC)에 의해 제안[]
나는 카피 편집을 했고, 번호가 매겨지거나 글머리표 리스트와 상호 작용하는 TOCleft에 대한 제안을 좌회전시키거나 좌회전하지 않도록 변경했다. 나는 또한 일반적으로 TOC가 적어도 주요 단락을 따른다는 것을 추가했다. 만약 주요 단락이 화면보다 길다면 그것은 어쨌든 다시 작성되어야 한다. DES 22:44, 2005년 7월 12일 (UTC)[]
- 나는 부동의 권리에 동의한다. 그러나 때로는 한 문단으로만 도입을 제한할 수 있는 그럴듯한 방법이 없기 때문에, 그렇게 되면 TOC(플로트 또는 비플로트)를 첫 번째 단락 뒤에 반으로 자르는 대신 도입부 끝에 배치해야 하지 않을까? -- Titoxd 22:58, 2005년 7월 12일 (UTC)[]
  - TfD 토론에서 논의된 테스트 사례 중 하나는 TOC 권한을 사용하여 도입 첫 번째 단락 뒤에 TOC를 넣었고, 따라서 첫 번째 단락은 전체 너비로 만들었지만 나머지 리드 섹션은 전면 TOC를 따라 만들었다. 나는 적어도 그 경우 이것이 a) 불분명한 TOC보다 낫다고 느꼈다. b) 선도 부분 뒤에 있는 TOC 또는 c) 어떤 텍스트보다 먼저 TOC를 과시하는 것이 더 낫다고 생각했다. 그것이 내가 충고하는 것이다. 당장 관련된 아티펠은 기억나지 않지만, 자료실을 뒤져보면 아마 찾을 수 있을 거야. DES 23:04, 2005년 7월 12일 (UTC)[]
    - 내가 편집 내용을 잘못 읽었다는 걸 깨달았어... 다른 사람에게 그런 일이 일어나지 않도록 바꾸려고 한다. -- Titoxd 23:26, 2005년 7월 12일 (UTC)[]
  - 일반적으로 나는 일반적인 사용자가 TOC를 보기 위해 아래로 스크롤해야 한다는 것을 의미한다면 소개 섹션 끝에서 TOC가 더 잘 보이지 않는다고 생각한다. 이는 애초에 부동 TOC를 만들 때 중요한 부분이었다. Intelligent design을 참조하라. DES 23:04, 2005년 7월 12일 (UTC)[]
    - 음... 좋은 지적이야. 첫 단락 뒤에 떠 있는 TOC가 떠야 하는데, 스크롤 다운 문제가 여기서 해결하려는 것이다. --Titoxd 23:19, 2005년 7월 12일 (UTC)[]
꽤 좋아 보이는데, 나한테 두 가지 문제가 있어. 먼저, 누군가가 {{tl:TOCleft}은(는) 실제로 유용하다거나 미적으로 만족스럽다거나? 내가 보기엔 그것은 항상 나쁜 생각일 것 같고 단지 제안에서 완전히 제외되어야만 할 것 같다. 둘째로, 일반적인 의견처럼, 사용자의 결심에 관한 가정에 근거한 어떤 진술도 내 경험상 논란의 여지가 있을 수 밖에 없다. 우리 모두는 사람들이 "대부분" 어떤 결의안을 사용하는지 안다고 생각하지만, 우리는 그렇지 않다. 아마도 우리는 나중에 말다툼을 하지 않기 위해 이러한 제약조건들을 언급하는 더 좋고, 더 일반적인 방법을 찾을 수 있을 것이다. 내 브라우징 사이즈(800x900)에서는 괜찮지만! —HoresPunchKid→host 23:50, 2005년 7월 13일(UTC)

개인적으로 {{}}}}{{{{{}}}}의 예가 떠오르지 않는다.TOCleft}이(가) 유용할 것이고, 사용하지 않을 것이지만, 위에서 이미지와 함께 일부 페이지에 있을 수 있다는 논의가 있었기 때문에 TOCleft가 포함된 제안서 초안을 작성하게 된 것이다. 결의안에 대해서는, 우리가 위키백과 왼쪽 패널과 비교함으로써 제약을 진술한 이유들이다. -- Titoxd 21:20, 2005년 7월 18일 (UTC)[]

기사의 오른쪽 상단에 이미지가 있다면 TOCleft가 더 나은 선택일 것이다. DES 16:42, 2005년 7월 31일 (UTC)[]

매우 작은 이미지나 매우 작은 TOC가 아니라면 TOC를 띄우지 마십시오. 그렇지 않으면 일부 사용자는 TOC 사이에 얇은 텍스트 열이 있을 수 있다. —Mike 17:11, 2005년 7월 31일 (UTC)

확실히 하자면, 만약 이미지가 오른쪽 상단에 있다면, TOC를 1, 2문단 이후에 왼쪽으로 띄워서 전체 혹은 거의 아래쪽에 위치시키면 잘 작동할 수 있다, IMO. 예를 들어 토니 블레어를 보십시오. DES ^(talk)

나는 TOC가 어떤 상황에서도 너무 길지 않아야 한다고 언급할 가치가 있다고 생각한다. 일부 기사들은 지나치게 긴 TOC를 가지고 있고 단순히 떠다니기 보다는 잘라내야 한다. 아마도 일부 공백을 메우기 위해 이미지를 사용하는 것을 언급하고 TOC가 숨겨져 있을 때 레이아웃이 여전히 작동하는지 확인하도록 사람들에게 조언하면서 도입 레이아웃에 대해 좀 더 일반적인 논의를 하는 것이 좋을 것이다. 바이올렛/리거 (t) 00:01, 2005년 7월 14일 (UTC)[]

나는 이것을 논제로 본다. 사용자는 기사의 TOC를 매우 간단한 css로 플로팅할 수 있으며, my css는 플로팅 TOC를 포함하며 오랫동안 가지고 있다. 각 사용자가 페이지를 어떻게 표시할지 결정하도록 하십시오. 특정 형식을 강요하는 것은 좋지 않다. 겐지엔 02:33, 2005년 7월 14일 (UTC)[]

- 나는 위키피디아 사용자 중 극히 일부만이 CSS 사용자 정의 가능성을 이용하고 있으며, 아직 더 작은 사용자 정의는 그것을 알고 있고 효과적으로 사용할 수 있을 것이라고 의심한다. 사용자들로 하여금 CSS를 만지작거리게 함으로써 이것을 떨쳐버리는 것은 무책임한 일일 것이다. 아마도 MediaWiki는 이러한 특정 선호도를 명시적으로 만드는 사용자 기본 설정이 필요할 것이다. 코드 맞추기가 힘들 거라고는 생각 안 해, 비록 내가 시간을 자원봉사를 하고 있는 건 아니지만... ;) —HoresPunchKid→1902:56, 2005년 7월 14일(UTC)
  - 나는 위키피디아 사용자 중 극히 일부만이 CSS 사용자 정의 가능성을 이용하고 있으며, 아직 더 작은 사용자 정의는 그것을 알고 있고 효과적으로 사용할 수 있을 것이라고 의심한다. 사용자들로 하여금 CSS를 만지작거리게 함으로써 이것을 떨쳐버리는 것은 무책임한 일일 것이다. 전적으로 동의하다.—Exphalon ζ ζ 08:03:45, 2005-08-08(UTC)

흠. 도입 레이아웃에 대한 논의는 TOC 문제를 다루기를 원하기 때문에 이 범위에서는 약간 벗어난 것 같지만, 나는 TOC가 불필요하게 길어져서는 안 되며(때로는 어쩔 수 없는 경우도 있지만) TOC가 숨겨져 있다면 편집자들이 모든 것이 제대로 작동하는지 확인해야 한다는 것에 동의한다. 그래서 다시 돌아가서 제안서에 그 점들을 추가했다. -- Titoxd 21:28, 2005년 7월 18일 (UTC)[]
이미 널리 퍼져 있는 템플릿의 오용에 주목하여, TOC의 길이가 10개 항목 미만인 경우 이러한 템플릿이 사용되지 않는 규칙을 보고 싶다. 나는 아직 그러한 경우에 그것이 기사 디자인을 개선하는 것을 보지 못했고, 대부분의 경우 그것은 페이지의 손상에 있다. 조 D (t) 21:24, 2005년 7월 30일 (UTC)[]
"잘못했어" 벌써 7월도 안 나왔어! 사용자가 ToC 상자 포맷에 대한 "지침"을 "규칙"으로 이미 엄격하게 시행 중인 경우:슈타인스키(Steinskinski)는 '조 드(Joe D)'로 불린다.별로 좋지 않은 징조야! 보다 일반적인 공감대는 ToC 박스가 소개자료 다음에 속한다는 것으로 보이는데, 그 자체가 이미지 자체의 요구대로 왼쪽 위나 오른쪽 위쪽에 주도적인 이미지를 갖는 경우가 많다. ToC가 오른쪽으로 가야 하는 특이한 예로는 왼쪽의 들여쓰기 인용문 간섭으로 인해 갈래시아를 참조하십시오. 융통성은 최고의 "규칙"이다. 우리 모두가 "규칙"으로서 융통성을 발휘하여 가톨릭의 획일성을 불러 일으키는 교조적인 "공식주의자"로부터 두통을 구하자. 유연성 규칙! --Wetman 23:43, 2005년 7월 30일 (UTC)[]
- 기사가 더 보기 좋기 때문에 그들은 시행되고 있다. 동의하지 않을 수도 있지만, 당신의 지지는 제한되어 있다. 이 템플릿은 어떤 오래된 글에 던져지지 않고 극단적인 상황에서만 사용해야 한다고 생각하는 사람들의 지원을 받아 삭제해도 살아남았다. 계속적으로 대응한 주장을 하는 것은 부정직하다. 조 D (t) 23:49, 2005년 7월 30일 (UTC)[]
이러한 논의는 아직 "가이드라인"의 상태에 도달하지 못했고, MoS 항목이 합의되었을 때에도(이 대화 페이지의 단순한 토론과는 반대로), MoS는 명백히 편집자에게 구속력을 갖지 않으며, MoS 입력에 어긋난다고 해서 단순히 "오용"이라고 부르는 것은 증명적으로 과장된 것이다. DES 02:35, 2005년 7월 31일 (UTC)[]
또한 나는 조 D가 TfD 토론의 성격을 잘못 지녔다고 생각한다. 템플릿은 '극한 상황'에서만 사용해야 한다는 합의만한 게 없었다. 어떤 이는 아예 반대했고, 어떤 이는 넓은 범위의 용도가 좋은 아이디어라고 생각했고, 어떤 사람들은 공감대에 가장 가까운 IMO는 그것이 특정 기사를 개선할 것이라고 생각할 만한 어떤 이유가 있는 곳에서만 사용되어야 하며, 어떤 기사에도 자동적으로 적용되어서는 안 된다는 생각이었다. 그리고 서식의 장점과 특정 편집자의 장단점에 대해서는 조금 더 신경 쓸 수 있을까? DES 02:35, 2005년 7월 31일 (UTC)[]
토크에서 포장 및 포장 해제된 ToC 형식 비교를 설정했다.Central Park(사용자:Steinsky는 유연한 포맷을 반복적으로 거부해 왔으며[여러 가지 특징적인 합리화를 거부해 왔다].Wetman 01:19, 2005년 7월 31일 (UTC)[]

위에서 볼 수 있듯이, 이것은 일부 사용자들에게 논란이 되고 있다. 우리는 적어도 그러한 폭풍들을 진정시키는데 도움이 될 수 있는 실제 MoS에 들어가는 첫 번째 버전에 동의할 수 있을까? 이 제안은 거의 변화가 없고 의미 있는 반대도 없이 꽤 오랫동안 논의되어 왔다. DES 16:57, 2005년 7월 31일 (UTC)[]
위키피디아에는 이미 첫 번째 버전이 있다.섹션#Floating_the_TOC, 그러니까 지금 최종 버전으로 가는 게 좋을 거야. —2005년 8월 2일 마이크 16:51 (UTC)

미스크

토론에 참여한 다른 사람들에게 현재 변함없이 {{}}을(를) 첨가하고 있는 Wetman(토크 · 기여)에게 경고하고 싶다.TOCright}}은(는) 정당하지 않으며, VfD 토론 및 후속 토론에서 사용하는 기사에 대해 대다수의 감정에 반한다. 불행하게도 직접 처리할 시간은 없지만, 사용자에게 그만하라고 부탁했다. 조 D (t) 21:38, 2005년 7월 30일 (UTC)[]

대부분의 편집은 "일관적으로" 이루어지며 이것은 다를 필요가 없다. 많은 경우, 주요 편집이 기교에 들어가기 전이나 후에 논의될 수 있으며, 일반적으로 의견 일치가 뒤따랐다. 이 문제도 다르지 않다. 어떤 편집자도 TOC를 띄워야 하는지 여부를 포함하여 기사를 "소유"하거나 그들의 형식을 지시할 자격이 없다. DES 17:01, 2005년 7월 31일 (UTC)[]

몇 명의 사용자를 제외한 모든 사용자가 이 토론을 소홀히 하고 있는 것 같아 빌리지 펌프에 이 페이지의 공지사항을 추가했다. --Titoxd 02:58, 2005년 8월 2일 (UTC)[]

나는 Titoxd의 빌리지 펌프 링크에서 왔고 나는 당신이 무엇을 투표하고 싶은지 모르겠다. 현재 아티클 기본값인 "left toc"를 대신 "right toc"로 설정하시겠습니까? -- Sitearm Talk 17:03, 2005년 8월 5일 (UTC)

기본값은 TOC가 리드 섹션 뒤에 나타나며, 다른 모든 섹션보다 먼저 왼쪽 정렬되고 오른쪽에 공백이 있는 경우 입니다. {{}} 사용으로TOCleft}} 또는 {{TOCright}은 기사 텍스트가 왼쪽 정렬 또는 오른쪽 정렬 TOC를 감싸는 "떠 있는" ToC를 가질 수 있다. 우리는 이 템플릿들을 언제 어떻게 사용해야 하는지, 사용하지 말아야 하는지에 대한 MoS 항목에 대한 합의를 도출하기를 희망한다. DES 17:16, 2005년 8월 5일 (UTC)[]