모듈 토크:사이드바/아카이브 3

이 페이지는 과거의 논의를 정리한 것입니다.이 페이지의 내용을 편집하지 마십시오.새로운 토론을 시작하거나 오래된 토론을 부활시키고 싶다면 현재 토크 페이지에서 다시 시작하세요.

이 편집 요청에 응답했습니다.설정 answered=또는 ans=요청을 다시 활성화하려면 매개 변수를 no로 지정합니다.

저는 2월 21일부터 템플릿의 기본 너비를 22.0em에서 20.0em으로 줄여달라는 요청을 재발송합니다.이것은, 말하자면, 첫 번째 외출이 충분한 빛을 주지 않았다고 생각하기 때문입니다.1024 x 768 이하의 화면 해상도는 현재 매우 드물지만, 1024 x 768 의 와이드 스크린으로 브라우즈 하는 고령자(예를 들면)는, 보기 쉽다고 생각합니다.게다가 이 템플릿의 현재 디폴트 폭도 Wikipedia가 전체 화면으로 표시되는 것을 전제로 하고 있는 것 같습니다만, 항상 그렇지만은 않습니다.따라서 저는 현재 22.0em과 제가 본 많은 사이드바에 의해 지정된 18.0em 사이의 절충안으로 20.0em을 제안합니다(위 참조).

라인을 교체하여 변경할 수 있습니다.

-->width:{{#if:{{{width }}} {{{width}}} 22.0em}};<!--

코드의 선두에 가까워지다

-->width:{{#if:{{{width }}} {{{width}}} 20.0em<!--this default/fallback width no greater than 20.0em, please, for the sake of smaller screens/windows-->}};<!--

CsDix (토크) 2013년 2월 24일 05:17 (UTC)응답[응답]

이로 인해 {{infobox}과(와) 올바르게 스택되지 않습니다.지난번 거절당했을 때 검열에 대한 당신의 터무니없는 주장에서 증명되었듯이, 이것은 사려 깊지 못한 요청입니다.체리로 뽑은 예(이 사이드바 그룹은 너비를 설정하기 때문에 모든 사이드바에서 사용할 수 있습니다)나 다른 사람이 많은 작업을 하도록 하는 애매한 지시({infobox}도 업데이트해야 합니다)가 아니라,낮은 해상도에 몰려든다는 막연한 주장보다 설득력 있는 주장을 제시합니다(요즘 데스크톱 PC 사용자 중 10% 미만, 와이드스크린 노트북, 사이드바가 뜨지 않는 모바일 디바이스의 경우 사용자 층의 극히 일부입니다).다시 거부: 변경에 대한 명확한 합의가 없는 한 다시 활성화하지 마십시오.Chris Cunningham (사용자:thumperward)(대화) 2013년 2월 27일 (UTC)응답[응답]

첫 번째 메시지에는 당신이 놓친 것 같은 두 가지 주장이 있습니다.컨센서스입니다만, 여기에 응원의 글을 올려달라고 부탁할 필요가 있는 것입니까?지금까지 여러 곳에서 인정받은 '대담한(변경), 되돌리기, 토론' 방법은 어떻습니까?CsDix (토크) 18:56, 2013년 2월 27일 (UTC)응답[응답]

"bold be"에는 한계가 있다.이러한 한계 중 하나는 66828페이지에 동시에 영향을 미치는 변경을 제안할 경우, 먼저 예기치 않은 결과를 초래하지 않도록 하는 것입니다.이 템플릿을 완전히 보호하지 않았다면 폭 변경은 WP에서 즉시 복구되었을 것입니다.BRD 사이클은 "토론"을 하게 됩니다.요점을 설명하려면:

1. 극소수의 독자만이, 보다 작아져, 저폭의 디스플레이를 사용하고 있습니다.
2. 2em 폭의 축소가 이 경우에 크게 도움이 된다는 주장은 논란의 여지가 있다.
3. ...최대화되지 않은 창에서 위키피디아를 볼 때 독자들이 불편함을 느낀다는 주장도 마찬가지입니다.
4. 기본 너비가 추가된 이후 18개월 동안 템플릿은 프레젠테이션에 이 너비에 의존했으며, h리스트를 사용하는 조밀한 어구의 사이드바는 낮은 너비에 의해 강제된 추가 줄 바꿈에 의해 출력이 크게 변경됩니다.기사의 선두에 있는 TOC에 사이드바가 붙어 있는 일반적인 경우, 리더의 디스플레이(특히 노트북 등 키가 작은 디스플레이)에 빈 공간이 늘어나면 이점이 없습니다.
5. {{infobox}}은(는) 거의 5년간 디폴트로 22em으로 되어 있으며, 여기서 폭을 변경하면 사이드바가 자연스럽게 인포박스와 겹치지 않게 됩니다(이것은 매우 일반적입니다).

그 때문에 폭은 가볍게 변경되어서는 안 됩니다.두 명의 편집자가 이미 거절했습니다.좀 더 중앙에서 변경을 제안하고 싶다면 RFC를 시작하는 것이 좋습니다.Chris Cunningham (사용자:thumperward)(대화) 2013년 2월 28일 (UTC)응답[응답]

• 조언해 주셔서 감사합니다.나는 그 상황에 그렇게 많이 투자하지 않기 때문에 현상의 관성이 우세할 것이다.하지만 관리자보다는 독자들이 변화에 어떻게 반응할지 알고 싶었습니다.당신은 백과사전을 전체화면이 아닌 창으로 보는 사람들에게 어떤 지원이 주어지는지에 대해 이의를 제기하고 있지만(즉, 이것은 여전히 무의미하다), 나는 당신이 다른 관찰에 대한 가치를 인식/조절하고 있는지 여전히 확신할 수 없다.우리 중 누구도 젊어졌다고 생각하지 않는다.CsDix (토크) 00:53, 2013년 3월 1일 (UTC)응답[응답]

이 편집 요청에 응답했습니다.설정 answered=또는 ans=요청을 다시 활성화하려면 매개 변수를 no로 지정합니다.

현재 "아래" 행(코드 끝 부근)을 바꾸십시오.

--> { #if : { { { tr } } < tr > < tr > < tr > style = " style : 0 . 3em 0 . 4em 0 . 3em ; bold ; { { { tr style } } > { { { tr } } > < !--

아래 버전에서는 탑 패딩이 0.15em으로 절반으로 줄었습니다.

-->{#의 경우:{{{class }}<tr><class="{class}}" style="class:0.15em 0.4em 0.3em;class-weight:bold;{{class}}}"> {{{class}}}"</tr>}}}}<!--

..."아래"선 위아래에 경계선이 지정되어 있는 경우, 그 중간(균형 잡힌 방법으로)을 배치하기 위해 이 패딩을 설정할 필요가 있습니다.

CsDix (토크) 2013년 2월 27일 05:11 (UTC)응답[응답]

예?이것이 다른 사이드바에 악영향을 미치지 않는지 확인하셨나요?지금은 사양하고 있다.Chris Cunningham (사용자:thumperward)(대화) 2013년 2월 27일 (UTC)응답[응답]

• 예?내가 본 대부분의 사이드바는 위의 설명에 부합한다.최근 예시를 보려면 여기를 클릭하십시오.지금은 다시 활성화 중입니다.CsDix (토크) 2013년 2월 27일 18:58 (UTC)응답[응답]

...예시를 포함한 링크에 대한 링크를 제공했으므로 편집 요청을 비활성화하지 마십시오.CsDix (토크) 00:57, 2013년 3월 1일 (UTC)응답[응답]

당신이 한 일은 당신의 약속 이력에 링크하는 것입니다.그것에는 최근 편집한 다양한 사이드바들이 포함되어 있으며, 그 중 일부는 당신의 강연에서 공개적으로 논란이 되고 있습니다.문제의 구체적인 예를 제시하지 못할 경우, 지나가는 관리자가 최대 66,000개의 기사의 외관을 바꾸는 변경을 가할 가능성은 거의 없습니다.이것은 CAT에 배치됩니다.EP 큐(이미 백로그되어 모니터링 부족)는 무기한입니다.당신 맘대로 하세요.Chris Cunningham (사용자:thumperward)(대화) 2013년 3월 1일 (UTC)응답[응답]

다음은 "아래"가 포함된 요약본의 템플릿 편집을 통해 확인할 수 있습니다.하지만 지금은 너무 작은 수정처럼 느껴져요.CsDix (토크) 2013년 3월 1일 18:36 (UTC)응답[응답]

• 현재로선 미완성: 죄송하지만 Thumperward의 의견에 동의합니다.WP에 따라 샌드박스 코드와 관련 테스트 케이스를 확인할 필요가 있습니다.테스트 케이스{{edit protected} 템플릿을 설정한 후 다시 활성화하십시오.베스트 — Stradivarius님^{♪ talk ♪} 2013년 3월 2일 (UTC)응답[응답]
  • 알겠어.아주 작은 수정이기 때문에 떨어뜨리지만, 만약 반복하게 되면 테스트 케이스를 조립합니다.당신과 Thumperward의 관심에 감사드립니다.CsDix (토크) 2013년 3월 2일 (UTC) 15:22 (응답)

다시 안녕.단순히 "width: Xunits"보다 더 정교한 기본 폭을 설정할 수 있습니까?제가 염두에 두고 있는 것은 "width:18.0em"과 "width:auto"를 조합한 것입니다.즉, "18.0em이지만 Wikipedia의 자동 링크 볼딩이 18.0em을 약간 초과하는 것을 의미한다면 조금 더 많은 것입니다."

18.0em은 현재의 '볼드 감응형' 22.0em보다 작습니다.22.0em은 작은 화면(예를 들어 1024 x 768 해상도) 또는 작은 창에서는 약간 폭이 넓기 때문에 편집 요청의 일부이기도 합니다.(18.0의 이유)이 해상도는 만족스럽게 동작하고 있는 것 같습니다.또, 예를 들면 정치적인 토픽에 관한 사이드바 세트의 디폴트폭으로서도 사용되고 있는 것을 알 수 있습니다.)

CsDix (토크) 2013년 2월 16일 18:13 (UTC)응답[응답]

기본값은 {{infobox}}과(와) 같아야 합니다.정확한 모양은 브라우저에 따라 다르므로 "점"에 대해 걱정하지 말고 내용을 자연스럽게 입력하도록 하십시오.Frietjes (토크) 2013년 2월 17일 18:10 (UTC)응답[응답]

Infobox의 디폴트 폭도 22.0em이므로 18.0em으로 줄이는 것이 좋습니다.(그렇지 않다면 20.0em을 사용하는 것이 좋을지도 모릅니다.)?)

행잉 도트에 대해서는, 최종적으로 각 브라우저와 그 설정에 의해서 페이지의 정확한 외관이 좌우될 수 있습니다만, 그것을 회피하지 않는 것은 좋은 이유라고는 생각하지 않습니다.사이드바 등 (잘 디자인된) 세로 방향의 것이 관리되지 않는 수평적인 것(리스트의 점 등)에 의해 손상되는 것은 유감입니다.

CsDix (토크) 23:02, 2013년 2월 17일 (UTC)응답[응답]

"점"을 제거하여 하나의 목록을 두 개로 분할합니다. 의미론적으로는 하나의 목록이어야 합니다.A와 B 사이에 점이 있지만 B와 C 사이에 점이 없으면 기본적으로 A와 B는 그룹의 일부라고 하지만 B와 C는 그렇지 않습니다.이것은 {A, B, C }를 의미할 때 {A, B}, {C} }을(를) 말하는 것과 동일한 집합입니다. Frietjes (대화) 16:40, 2013년 2월 18일(UTC)응답

좋아요, 그럼 의미론상 걸려있는 점들을 보이지 않게 만들 방법이 있을까요?? – 또는 이를 수용하기 위한 방법이 하나 이상 있을 것으로 생각되지만, 구현에 대한 노하우(또는 승인)가 없습니다.도와주세요...?CsDix (토크) 2013년 2월 18일 17:15 (UTC)응답[응답]

또는 {{A, B}, {C, D}...}은(는) {A, B, C, D,...}과(와) 동일하지 않지만 둘 다 A, B, C, D...와 올바른 순서로 단일 집합을 형성합니다.접근성에 관해 어떤 문제가 있습니까?– {{A, B}, {C, D}...} 원인..?CsDix (토크) 2013년 2월 19일 17:23 (UTC)응답[응답]

이러한 서브그룹을 작성하는 것으로써, A, B의 접속이 B, C의 접속보다 강하다는 것을 알 수 있습니다.이것은 단순히 올바르지 않습니다(토크 페이지 참조).목록은 하위 목록으로 나눌 수 있지만, 하위 목록(예: 10년 단위로 하위 그룹화)에 대한 이유가 있어야 한다.또, 리스트의 특정의 장소를 브라우저에 의존하기 때문에, 강제적으로 분류하는 것은 문제가 있다고 지적되고 있습니다.브라우저의 퍼스널 솔루션에 관해서는, MediaWiki talk에서 질문하는 것을 추천합니다.Common.css 또는 WP:VPT. Javascript로 가능할지 모르지만, 저는 그 분야에 전문가가 아닙니다.Frietjes (토크) 2013년 2월 19일 17:39 (UTC)응답[응답]

당신이 원하는 것은min-width그리고.max-width모든 주요 브라우저에서 아직 지원되지 않는 CSS(고객 자신의 CSS에서 지원되는 경우가 있습니다).지원이 있는지 아닌지는 다른 질문일 수 있습니다.그렇지 않으면 Frietjes가 말한 것을 지지합니다.--Izno (대화) 17:46, 2013년 2월 19일 (UTC)응답[응답]

• 상기의 모든 것에 대해서, 일반적으로 가능한 것(또, 할 수 있는 것)을 앞지르고 있는 것을 알 수 있기 때문에, 적어도 당분간은, 점의 달림을 받아들여 다른 곳에서 작업합니다.설명 등 모두 감사합니다.CsDix (토크) 2013년 2월 19일 23:48 (UTC)응답[응답]

IMO 위의 유익한 논의입니다.먼저 몇 가지 질문을 드리겠습니다.누구나 대답할 수 있습니다.

Q1T. 브라우저의 "행잉 도트" 의존성은 링크 F • 링크 G의 앞의 공백 행이 브라우저에 따라 링크 F의 앞의 • 텍스트 행으로 이동하는 것을 의미합니까?

Q2T. "unmanaged hlists"는 끝부분의 점들을 피하기 위해 빈 줄을 사용하지 않은 목록을 의미합니까?만약 그렇다면, 그 경우의 점 표시도 브라우저에 따라 달라집니까?

제가 질문한 다른 부분이 누락될 수 있으면 언제든지 자세히 설명해 주십시오.P.S. 2 여기 IMO의 의견은 (템플릿 A에서) 상기 제안의 장점을 보여줍니다.감사합니다. --Thomasmeeks (토크)2013년 3월 21일 (UTC)응답해 주세요.

• A1T: hlist 내의 엔트리 사이에 공백줄이 있으면 첫 번째 엔트리 뒤에 점이 배치되지 않고 두 번째 엔트리가 새 행에 시작됨을 의미합니다.(요구에 대응하기를 바랍니다.)

A2T: 위의 "관리되지 않음" 목록은 연속적인 목록, 즉 빈 선(따라서 점이 걸려 있음)과 같은 회피책이 없는 목록을 의미합니다.

링크된 사이드바 중 사이드바 A를 선호합니다(단, 몇 가지 수정이 있음).아래에 있는 별도의 V • T • E 바는 조금 이상합니다만…?

CsDix (토크) 2013년 3월 22일 01:26 (UTC)응답[응답]

나는 당신의 마지막 대사를 언급하고 있다. 그것은 매우 적절하지만 현재 목적을 위한 탈선이다. 각주를 통해.§

위의 답변은 A1T와 A2T로 다시 기재했습니다.기대했던 대로입니다.끝점 달기 문제를 해결해 주는 것 같아요.실제로 텍스트 행 사이의 빈 줄은 그렇게 설계되어 있는 것 같습니다(그렇지 않으면 우연히 고쳐진 것이 매우 우연일 것입니다).편집자가 끝점을 수정하는 방법을 알고 있는지(또는 문제가 있다고 생각하는지) 여부는 또 다른 질문입니다.여기서 뭔가 부족한 점이 있을 수 있습니다만, 계속 진행하기 전에 코멘트를 부탁드립니다.감사해요.

§ 홀수 V • T • E 박스(여기 링크의 템플릿(A) 아래에 있지만 일부가 아님)는 현재 목적과는 관련이 없습니다.그 폭은 나에게 다음과 같이 증명되었다.

{{ 사이드바 이름 = 이코노미 사이드바}}

그 자체로는 다음과 같은 결과가 나옵니다.

v t

위 링크의 사이드바 기본 폭(B)은 (A)보다 20% 넓은 사이드바를 생성하기에 충분합니다.

따라서 기본 너비로서 넓은 (B) 템플릿은 (B)의 첫 번째 코드화된 행부터 존재합니다. --Thomasmeeks (talk) 03:34, 2013년 3월 22일 (UTC)응답[응답]

• V • T • E 박스에 대해 설명해 주셔서 감사합니다.네, 빈 선을 삽입하면 점의 걸림이 방지되지만, 그렇게 하면 리스트가 깨지고 접근성이 떨어지기 때문에 결국 취소됩니다.유감스럽게도, 저는 납득할 만한 해결책을 도출할 수 있는 노하우를 가지고 있지 않고(예를 들어, 매달린 점을 보이지 않게 만드는 것), 그렇게 할 수 있을 지도 모르는 사람들에 대한 관심이나 동기를 아직 발견하지 못했습니다.CsDix (토크) 2013년 3월 22일 09:18 (UTC)응답[응답]

음, 공백 코딩 행이 접근성 문제를 일으킬 경우, 가능한 해결 방법 중 하나가 있습니다(템플릿:정치 사이드바)는 코드화된 빈 줄을 다음과 같은 코드화된 줄로 바꿉니다.

:

대신.WP에서 코드화된 빈 줄이 아닙니다.LISTGAP 가이드라인코멘트 환영합니다.--토머스멕스(토크) 13:06, 2013년 3월 22일(UTC)응답[응답]

• 나는 (슬프게도) 이것이 아무런 차이가 없으며 이렇게 표현된 hlist는 여전히 하나의 hlist로 해석되지 않을 것이라고 들었다.즉, 그것이 맞다고 가정할 때(그렇게 생각하지 않을 이유가 없습니다), 접근하기 쉬운 방법으로 도트를 제거하는 것은 보다 "낮은 수준"을 필요로 하는 것처럼 보입니다.CsDix (토크) 2013년 3월 23일 01:32 (UTC)응답[응답]

실사 이상의 감사를 드립니다(링크 BTW는 폭이 넓기 때문에 사이드바에서 텍스트 행 길이 차이를 나타내는 극단적인 예입니다).

Q3T. 좋습니다.그러면, 여기서 소개한 것과 같은 리스트와 h리스트 포맷(심각한 IMO)을 「저수준」이라고 하는 것은 의미합니까?--Thomasmeeks (토크) 16:35, 2013년 3월 23일 (UTC)응답

• 다시 말씀드리지만, {{hlist}}을(를) '플레인 리스트'에 포함시켜도 '머스타드 컷'이 되지 않습니다.그것은 플레인 리스트가 깨지는 효과가 있다고 들었습니다.그러니까 '낮은 수준'이라는 말은 단순히 인간의 능력 밖, 즉 Wikipedia를 실행하는 소프트웨어의 내장 어딘가에 있다는 뜻입니다.CsDix (토크)2013년 3월 24일 02:26 (UTC)응답[응답]

참 인내심이 많으시군요.그럼 다른 질문으로 이어지죠

Q4T. 예시로 hlist 포맷을 사용하지 않습니다(여기서 Q3T에 따라).

* {{hlist [[행동경제학][문화경제학][진화경제학][진화경제학]}},

(다른 사이드바 포맷을 사용하면) 다음과 같이 됩니다.

• 행동적·문화적·진화

사이드바의 내용 섹션 전체에 걸쳐 목록 문장과 끝 점 없이 텍스트 줄 길이를 맞춤화할 수 있습니다. --Thomasmeeks (talk) 12:06, 2013년 3월 24일 (UTC)응답[응답]

다음 옵션 중 하나라도 WP와 모순되지 않았는지 여부를 확인하는 경우:LISTGAP은 특정 목록의 HTML 소스를 표시하기만 하면 됩니다.보면

<ul> <li> 항목 1 </li> <li> 항목 2 </li> 항목 3 </li> </li> 항목 4 </ul>

잘 있다.보면

<ul> <li> 항목 1 </li> </li> 항목 2 </ul> <li> </li> 항목 3 </li> </li> 항목 4 </ul>

또는

<ul> <li> </li> 항목 1 </li> </li> 항목 2 </li> </li> </li> 항목 3 </li> </li> 항목 4 </ul> </ul> </ul>

1개의 리스트가 2개의 리스트로 분할되어 있습니다.• 기호가 보이면 목록이 완전히 깨진 것입니다. 글머리 기호 사이에 줄 바꿈 또는 : 갭을 추가하면 프리프로세서가 빈 목록 마크업을 잘라내기 때문에 동일한 작업이 수행됩니다.에서는 플레인리스트와 hlist 서브목록을 조합하여 사용해도 리스트가 분할됩니다.Frietjes (토크) 2013년 3월 24일 17:17 (UTC)응답[응답]

• 네, 아스타리스크가 없는 {{hlist}}s는 도트가 매달리는 것을 피하는 또 다른 방법일 수 있지만, 그것 역시 Frietjes가 나타내는 방식으로 접근성을 손상시킬 수 있습니다.즉, 현재의 시스템은, 점의 달림을 회피하는 것은 접근성을 해치지 않는 것 같습니다.그 때문에, 보다 낮은 레벨의 것이 필요하다고 생각합니다.유감스럽게도 위와 같이 접근과 노하우를 가진 사람들은 이 점들이 사이드바 등의 템플릿에 나타날 때 흠집이라고 생각하지 않는 것 같습니다.CsDix (토크) 2013년 3월 25일 06:35 (UTC)응답[응답]

  "접근과 노하우가 필요한 사람들은 이 점들이 사이드바 등의 템플릿에 등장할 때 흠집이라고 생각하지 않는 것 같다."는 것은 불필요하다고 생각한다.대부분의 경우 수직 템플릿의^TM hlists가 형편없다는 것에 동의합니다.어쩔 수 없습니다.--이즈노(대화) 12:54, 2013년 3월 25일(UTC)응답[응답]

  죄송합니다, 이즈노 – 이 기능에 대한 저의 실망감을 어디서 느꼈는지 몰랐습니다.하지만 나는 잠시도 그것에 대해 할 수 있는 일이 없다고 생각하지 않는다.렌더링 루틴의 어딘가에서: "다음 항목 전에 줄 바꿈이 필요한 경우(사용자의 기본 설정에서 점 없음 설정 등), 가시성이 있는 점을 렌더링합니다: 숨김(또는 생략).CsDix (토크) 2013년 3월 25일 14:40 (UTC)응답[응답]

  Javascript는 회선의 파손을 검출할 수 없기 때문에(또한 CSS는 확실히 검출할 수 없기 때문에) 실제로 브라우저(즉, Firefox 개발자가 되는 것)에 대응할 수 있습니다.그리고 어떤 Firefox(브라우저) 개발자가 한 사이트에 이러한 작은 것을 구현합니까?JS는 가능할지 모르지만, 브라우저의 세부사항을 조작해야 할 것 같습니다.브라우저 의존성을 도입해서는 안 됩니다.그렇지 않으면 브라우저 전쟁의 길을 걷게 됩니다.--Izno (talk) 15:22, 2013년 3월 25일 (UTC)응답[응답]

  브라우저에 의존하게 되면, 너무 심도 있는 것 같습니다만, 제 직감으로는 그렇게까지 되지 않습니다(혹은 아닙니다.하지만, 저는 그것이 충분한 정보를 가진 본능이 아니라는 것을 인정합니다. (하지만, 어떤 컴퓨터의 브라우저가 언제 줄바꿈을 하려는지 알 수 있는 방법이 있을 것입니다만, 아닙니다.?) CsDix (토크) 2013년 3월 25일 (UTC)응답 [응답]

위에 소화할 게 많죠마지막 질문에 대한 상기의 상세하고 보충적인 코멘트에 감사를 표합니다.참조하기 쉽도록 다음 번호를 붙입니다.

1T. WP의 조언:연속 링크 사이에 공백 행이 없는 LISTGAP은 글머리 기호 수직 리스트에 완전히 적합한 것 같습니다. 왜냐하면 공백 행은 WP:Markup에서만 표시되지만 화면 리더에 의해 "목록 끝"으로 읽히기 때문입니다(위의 Frietjes 코멘트에 따라). 따라서 보이지 않거나 더 나빠집니다.장점:글머리 기호로 표시된 세로 목록에는 공백 줄이 없습니다.

2T. WP의 장점:특정 회선 또는 연속 회선간의 링크간에 유효한 h[origental]목록 관계가 유지되는 경우, 접근성은 공백 회선의 사용을 선호합니다.그것은 WP와 일치한다.SYBA, 4-6항은 링크가 서로 관련되어 있음을 반영하며, 이 경우 특정 사이드바 행에 특정 링크 세트를 배치한다.또한 각 행은 시의 한 행과 같이 수평 리스트가 되어 개별 링크뿐만 아니라 서로 관련지어 읽혀지도록 되어 있습니다.연속행은 시의 연속행과 유사하다.

스크린 리더는 이러한 각 행(리스트의 끝이라고 읽음)에서 해당 항목을 적절히 선택합니다.따라서 빈 선을 사용하면 끝 도트가 억제됩니다.그 선상에 남아 있는 도트는 그 선상에 있는 링크를 분리하는 것만을 의미합니다.이 목적을 위해 선단 도트는 용장성이 있습니다.모든 링크가 콘텐츠섹션에 있다는 사실도 엔드오브라인의 닷을 용장하게 만들 수 있습니다.특정 콘텐츠 섹션의 모든 링크는 줄 바꿈 없이 서로 관련되어야 합니다(물론 줄 바꿈 도트는 목록 기본값으로 유지될 수 있지만, 줄 바꿈 도트는 텍스트 줄을 약간 더 넓힐 수 있습니다).

3T. 링크 간에 빈 행을 사용하여 연속적인 사이드바 행을 생성하는 것과 다른 점을 나타내는 링크는 템플릿의 재작업입니다.이코노믹스 사이드바.템플릿(A)은 일부 링크 사이에 빈 줄을 사용하여 Journal Economic Literation JEL 분류 코드에 가까운 행을 생성합니다.다음은 예를 제시하겠습니다.

건강·교육·복지.

(B) 링크 간에 공백 행이 사용되지 않습니다.그 결과, Public & Hafiness econ & after 로부터의 모든 행의 첫 번째 링크가 (의도 없이) 한 줄 위로 표시됩니다.이것에 의해, JEL 코드 친화적(A)에 비해, (B)의 설명이 무효가 됩니다.예를 들어, (B)의 이전 문단 마지막 줄은 다음과 같다.

보건 • 교육 • 복지 • 인구,

JEL 코드가 아닙니다.이는 시에서 연속되는 첫 번째 단어를 앞줄로 옮기는 것과 같다(좋지 않다).--토마스멕스(대화) 20:54, 2013년 4월 8일(UTC)응답

4T. 상단의 제안은 18em 사이드바와 22em 기본값(약 20% 더 넓어짐)에 대한 것입니다.그것은 앞의 두 가지 점을 보완한다.각 행에 대한 보완 링크를 찾는 것이 어렵고 텍스트 행 길이가 좁아지면 사이드바 너비가 수평 행 공간을 덜 낭비하게 되고 사이드바에 방해가 덜 됩니다. --Thomasmeeks (talk) 19:24, 2013년 5월 2일 (UTC)

이 편집 요청에 응답했습니다.설정 answered=또는 ans=요청을 다시 활성화하려면 매개 변수를 no로 지정합니다.

나는 그 버전을 조롱했다. child=yes가 지원하는 것과 같은 방법으로 child=yes코드는 샌드박스2에 있습니다(메인 샌드박스가 사용되고 있는 것처럼 보입니다).예를 템플릿에 나타냅니다.사이드바/테스트 케이스 #임베디드.네비게이션 바를 렌더링하지 않고 아이에 대한 아웃터틀, 프리타이틀 또는 프리이미지를 무시하도록 했습니다.프리타이틀과 프리이미지를 지원하도록 할 수는 있지만, 표 캡션의 일부이기 때문에 아웃터타이틀은 동작하지 않습니다.상대방을 무시하는 이유는 title=에서 동작하는 것과 같은 방법으로 동작합니다(즉, 공백 행을 피하기 위해 해당 행의 선두 <tr> 및 <tr>을 출력하지 않도록 합니다).코드에 문제가 없다면 편집 요청을 하고 lua 모듈과의 Marge도 알아보겠습니다.Frietjes (토크)2013년 5월 24일 (UTC)응답[응답]

제가 보기에는 좋아 보이는 걸요.코드화해줘서 고마워!Plastikspork_―Œ^(talk) 2013년 5월 25일 01:07 (UTC)응답[응답]

좋습니다.편집요구를 유효하게 합니다.템플릿을 업데이트하여 Template: sidebar/sandbox2 버전을 사용하십시오(샌드박스2가 아닌 샌드박스2 참조).매립 테스트 케이스는 템플릿에서 확인할 수 있습니다.사이드바/테스트 케이스 #임베디드.Frietjes (토크) 2013년 5월 25일 13:58 (UTC)응답[응답]

완료! Plastikspork_―Œ^(talk) 2013년 5월 27일 (UTC)응답 [응답]

많은 사이드바가 카테고리에 속합니다.내선번호로 작성된 장부에 렌더링되지 않도록 인쇄에서 제외:수집.유감스럽게도 기본 기능은 현재 고장났습니다.관련 버그 보고서에서 설명한 바와 같이 회피책이 있습니다.

PDF 에 포함되지 않는 컨텐츠는, css 클래스 「noprint」로 이미 마크 할 수 있습니다.>< div class = "noprint"> blub noprint < / div >

템플릿의 예:Navbar는 <div class="noprint">로 구성되므로 탐색 막대는 책에 포함되지 않습니다.템플릿을 사용하는 각 사이드바를 변경할 필요가 없는 대신 이 변경을 포함하도록 템플릿을 변경할 수 있습니까?--특이한 투자자(토크) 13:56, 2013년 11월 1일 (UTC)응답[응답]

이 템플릿에는 MediaWiki에 나열된 수직 내비게이터가 포함되어 있습니다.Print.css 그럼 해석은 안 되는 건가요?Frietjes (토크) 17:52, 2013년 11월 1일 (UTC)응답[응답]

유감스럽게도 확장:컬렉션에서는 MediaWiki API를 사용하지만 MediaWiki를 사용하지 않는 것 같습니다.Print.css. --독특한 투자자 (토크)2013년 11월 3일 (UTC)응답[응답]

저는 이 템플릿의 Lua 버전을 만드는 것을 시도하려고 했는데, Toohool이 약 1년 전에 하나를 만든 것을 알게 되었습니다(템플릿:사이드바/샌드박스).내가 그걸 끝내고 그걸 바꿔도 누가 반대하겠어요?Kaldari (토크) 22:52, 2014년 1월 30일 (UTC)응답[응답]

다음과 같은 파라미터가 있나요? heading1class= heading2class=여기서 일할 수 있게 되어 있나요?Sardanaphalus (대화) 2014년 6월 9일 (UTC)응답[응답]

아니요, 열거는 스타일에서만 작동합니다( heading1style=등) 있을 뿐입니다. headingclass=. "템플릿" 참조:사이드바 #지원되는 모든 파라미터의 완전한 공백 구문. - Edokter (토크) - 2014년 6월 9일 09:49 (UTC) 응답[응답]

• 감사합니다. Sardanaphalus (토크) 2014년 6월 9일 19:46 (UTC)응답[응답]