justify-content: flex-end와 end의 차이

flex layout은 이제 스타일링에서 뺄 수 없는 기술이 되었다.
다만 비슷한 속성(이 글의 주제인 flex-end, end)들을 딱히 구분없이 사용하곤 했다.

UI를 구성하는 작업을 하던 와중, 특정 텍스트를 우측정렬로 표현해야하는 기획요소가 있었다.
깊게 고민하지 않고 다음처럼 작성하였다.

.end {
display:flex;
justify-content: end;
}

대부분의 환경에서는 정상작동 했으나, 특정 안드로이드 크롬환경에서는 우측정렬이 적용이 안되는 현상을 발견했다. 다행히 justify-content: flex-end; 로 해결은 되어 간단했지만 왜 특정 환경에서는 적용이 안될까 궁금했다.

MDN에서는 뭐가 다른지 직관적으로 설명해주는 느낌을 받지 못했다.

CanIUse 에서는?

justify-content 프로퍼티는 크롬 21버전부터 쓸 수 있는데?
해당 버그가 나타나는 크롬의 버전은 83이었다...
근데 조금 더 찾아보니 start와 end는 사용 가능한 버전이 다르다는 것을 찾았다. 왜지?

잘 모르겠다 싶으니 W3C 명세서를 훑어볼까?

W3C 스펙 영역

확인해보니 두 속성은 서로 다른 스펙을 기반으로 하고 있었다.

justify-content: end; 의 경우 CSS Box Alignment Module Level 3의 스펙이고
justify-content: flex-end; 는 CSS Flexible Box Layout Module Level 1의 스펙이다.

CSS Box Alignment Module Level 3 은 플렉스박스를 포함한 박스 레이아웃에 대한 전반적인 스펙을 정의한 제안으로, 아직 WD(working Draft) 단계를 벗어나지 못한 상태였다.

반면 CSS Flexible Box Layout Module Level 1의 경우는 CR(Candidate Recommendation) 단계이다.

일반적으로 CR단계부터 브라우저 벤더가 해당스펙에 대한 구현을 한다고 알고있다.(엄밀히 따르면 CR단계의 스펙을 구현할 가능성이 높을 뿐, 모든 스펙에 대해 대응하는건 아니라고 한다. https://www.w3.org/2021/Process-20211102/#implementation-experience 에서도 충분한 구현경험이 있다고 할 뿐 브라우저 벤더들이 구현해야하는 강제성은 부여하지 않고 있다.)

그래서 뭐가 다른데?

CSS Box Alignment Module Level 3 에서는 CSS Flexible Box Layout Module Level 1 속성을 오버라이드 하여 확장한 기능이다.

사진에서 Applies to: 영역을 보면 flex containers 타입으로 표현한 부분이 있는데 이 속성이 Layout Module Level 1 에서 사용할 수 있는 속성을 가리킨다.

start, end는 direction:rtl | lrt 을 고려하여 설계된 유연한 스펙의 속성이다. 즉 display:flex 뿐 아니라 그리드 컨테이너, 블록컨테이너, 멀티칼럼 컨테이너 등 다양한 환경에서 사용할 수 있는 스펙이다.

• flex-end 는 flex containers에서만 작동하는 속성이다.
  즉, flex-end가 end보다 좁은영역에서 사용가능하나, 적용 가능한 영역이 더 넓으므로 안전한 속성이라 할 수 있겠다.

갈무리

무분별하게 자동완성으로 나오는 속성을 적용하다간 의도치 않은 동작을 할 수 있다.

짜투리 정보: W3C Process

• GPT 한테 물어본 W3C Process가 어떤건지 물어본 결과를 아카이브 해본다.

1. Working Draft (WD)
   초기 단계: 사양의 초기 버전으로, 초안 상태에서 커뮤니티와 공개 의견을 받기 위한 문서.
   목적: 사양의 방향성을 결정하고, 피드백을 수집하여 내용을 발전시킴.
   변경 가능성: 이 단계에서는 사양이 크게 변경될 수 있음.

2. Candidate Recommendation (CR)
   안정화 단계: 사양이 어느 정도 안정화되었고, 실질적인 구현을 통해 검증되기를 원하는 단계.
   목적: 개발자 및 브라우저 벤더들이 사양을 구현하고, 그 결과를 바탕으로 피드백을 제공함.
   검증: 여러 구현 사례를 통해 사양의 상호 운용성을 검증.

3. Proposed Recommendation (PR)
   최종 검토 단계: 사양이 거의 완성되었으며, W3C 회원들에게 최종 검토 및 승인을 요청하는 단계.
   목적: 사양이 실제로 W3C의 공식 표준(Recommendation)으로 승인되기 전에 마지막 검토를 받음.

4. W3C Recommendation (REC)
   최종 표준: 사양이 W3C의 공식 표준으로 승인된 상태.
   목적: W3C 회원과 커뮤니티의 검토를 거쳐, 최종적으로 웹 표준으로 채택됨.
   안정성: 이 단계의 사양은 안정적이며, 웹 기술의 공식 표준으로 권장됨.

5. Maintenance and Updates
   사양의 유지보수: 사양이 표준으로 채택된 이후에도 필요에 따라 수정되거나 업데이트될 수 있음.
   목적: 표준의 지속적인 유효성과 현대성을 유지하기 위해 필요 시 개정됨.