의외로 단순하지 않은 TextBox가 Tom의 이유입니다.

개시하다

저는 광고가 니코니코 생방송 프론트 데스크에서 개발한 미쓰킨입니다.
이전 글보편적인tom과molecule의 경계를 의식한 구성 요소 설계에서 포함된 구성 요소가 없으면 무의미한 구성 요소인지에 초점을 맞추어 Tom과molecule를 각 항목의 공통 입도로 보편적으로 처리할 수 있음을 소개했다.
이번에 나는 그 보도의 마지막에 열거한 Text Box Select Box Combo Box의 더욱 깊은 입도를 깊이 있게 탐구하고 싶다.

TextBox의 입도도 단순하지 않아요.

출력<input type="text" />과 같은 TextBox 구성 요소를 만들면 100% 정도가 Tom으로 식별된다.
그러나 글자틀이라고 해서 그보다 작은 입도가 없다고 할 수는 없다.
예를 들어 Google 검색 형식의 입력 표시줄을 살펴보겠습니다.

오른쪽에 있는 두 개의 단추는 입력 표시줄과 분리되어 있는 단추라고 할 수 있지만, 입력된 단추를 지우고 관심 대상과 작업의 경계에서 포착하는 것도 텍스트 상자 표준에 탑재된 기능이라고 할 수 없나요?

텍스트 상자 지우기 버튼

왜 텍스트 상자의 지우기 단추는 표준적으로 텍스트 상자를 탑재하는 기능이라고 할 수 있습니까?그것은 다음과 같은 이유 때문이다.

버튼 지우기 작업은 텍스트 상자에서 수행됩니다.

구성 요소 외부에서 제어할 필요가 없는 완전 종료 책임

구성 요소의 한쪽에 지우기 단추 제어를 숨기기를 원합니다

텍스트 상자의 입력 상황은 단추의 표시와 밀접한 관계가 있다

비어 있을 때 숨기고 입력할 때 표시

텍스트 상자를 설정하는 모든 곳에서 요청될 수 있음

지우기 단추는 텍스트 상자와 밀접한 관계를 가진다. 텍스트 상자가 없으면 지우기 단추가 존재하지 않기 때문에, 요청할 때마다 표준 단추를 설치하는 것이 현저히 번거롭다.
이를 확인하기 위해 Edge<input type="text" />에 표준 지우기 버튼이 있습니다.

모든 브라우저에 표준 지우기 단추가 없습니다

엣지는 표준으로 탑재된 텍스트 상자의 지우기 버튼으로, 유감스럽게도 모든 브라우저에 표준으로 탑재된 것은 아니다.
이렇게 되면 검색표를 만들 때'입력란에 텍스트를 입력한 후 나타나는 지우기 버튼을 붙여주세요'라는 요구가 있으면 스스로 실현해야 한다.
이렇게 되면 단순히 Tom의 구성 요소로 간주되는 제거 단추를 출력할 필요가 있습니다.

<input type="text" class="text-box" /><button class="clear-button" />

여기에 포함된 구성 요소가 없다면 무의미한 성분을 구성하는 것인지 알 수 없다며 "아, 원자여야 하는데 더 분해할 수 있는 요소가 생겨 분자화됐는데 아톰과 모레큘 중 어느 것이 옳은가?"이렇게 하면 사람을 현혹시킬 수 있다.
지식이 있다면 지우기 단추는 선택할 수 있고 그것이 없어도 주체가 될 수 있는 텍스트 상자라는 뜻이기 때문에 atom이라고 명확하게 단언할 수 있다.

예상치 못한 풍부한 텍스트 상자

많은 브라우저들이 표준적인 지우기 단추가 없으면type 속성을 바꾸면 브라우저에 설치된 다양한 요소가 나타난다.(구현 여부는 브라우저에 따라 다름)

숫자.

<input type="number" />

수치 조절 단추를 표시합니다.

일자

<input type="date" />

날짜 구덩이를 표시합니다.

속성은 세분성에 영향을 주지 않습니다.

속성만 바꾸면 위젯의 입도가 바뀌어 정리할 수 없기 때문에 텍스트 상자가 아무리 풍부한 보조 기능이 있어도 TextBox를 주체로 한다면 tom 상태를 유지해야 한다.(도대체 TextBox의 표현이 다르다는 말)
만약 TextBox라는 캐릭터가 tom이라면 더 이상 분할할 수 없다는 것을 알 수 있을 것이다.

자체 제작 구성 요소와 일치성

텍스트 상자라면 <input type="text" />로 실현하는 것은 당연한 일이지만 <input type="number" />의 회전 단추를 싫어하는 스타일 등이 있어 브라우저 표준에 대응할 수 없는 경우도 있다.
대부분의 경우 CSS는 변경 가능한 유사 요소를 준비했지만, 이에 대응할 수 없는 경우도 있다.
이 경우 동등한 기능을 구성 요소로만 직접 만들 수 있다.
이 경우 버튼 지우기와 마찬가지로 버튼 요소 등을 <input type="number" />에 추가해야 합니다.
단순히 요소의 수량으로 구성 요소의 입도를 전환한다면<input type="number" />tom이지만, 자체 제작 자전거 버튼을 추가한 구성 요소는 모레컬로 완전히 같은 표현에서 똑같은 기능을 하지만 입도는 다르다.
이렇게 물리적인 측면에서 입도를 포착하면 적당한 입도 관리를 할 수 없다.

물리적으로 입도를 포착할 수 없다

입도라고 하면 물리적으로 인상을 주지만 물리적으로 요소를 포착해 입도로 삼으면 실패한다.
이것은 입도 디자인에서 쉽게 빠져들기 쉬운 관건일 수 있다.
BCD Design에서 말한 기본, 즉 UI의 모델로 입도를 포착하면 보편적인 입도를 얻을 수 있다.
따라서 구성 요소 이름의 끝에 안정적이고 정련된 UI의 유형 이름을 더하면 구성 요소의 이미지를 더욱 명확하게 하고 입도를 명확하게 하며 의존 관계를 명확하게 하는 등 각종 애매성을 배제할 수 있다.
이처럼 어떤 주관도 포함하지 않고 정규화된 결과가 일반적이기 때문에 종목을 뛰어넘어도 활용할 수 있는 장기 자산이 된다.

더 깊은 입도라면

셀렉트박스와 콤보박스 이야기는 아직 쓰지 않았지만, 시간이 길어졌으니 이번엔 그만하자.