sam
(Sam Saffron)
10월 28, 2019, 6:35오전
1
이 문제는 거의 매일 나를 미치게 합니다.
레티나 해상도의 스크린샷을 업로드합니다.
즉시 마우스를 미리보기 영역으로 가져가서 "크기 조절 컨트롤"을 찾아 크기를 줄이려 합니다.
하지만 마우스를 올렸을 때 컨트롤이 나타나지 않습니다.
마우스를 다른 곳으로 옮깁니다.
다시 미리보기 영역으로 마우스를 가져가면 이번에는 컨트롤이 보입니다.
솔직히 "크기 조절 컨트롤"을 호버에만 의존하는 방식 자체가 마음에 들지 않습니다.
이 부분을 개선할 수 있는 2가지 옵션을 생각해 봤습니다.
버그를 수정하여 업로드 → 호버 시 컨트롤이 바로 나타나도록 합니다.
"크기 조절 컨트롤"을 조건 없이 항상 표시합니다(조금 더 은은하게).
개인적으로는 (2)를 선호하지만, @codinghorror , @awesomerobot 그리고 커뮤니티의 의견을 듣고 싶습니다.
11개의 좋아요
이것을 확인하지 못하겠습니다. 지연 시간 문제인가요?
1개의 좋아요
sam
(Sam Saffron)
10월 28, 2019, 6:52오전
3
극도로 가능성 높음, 호주에서 Firefox에서 meta 대항하여 100% 재현 가능.
4개의 좋아요
2번 옵션에 제 표를 던집니다. 이 기능은 정말 유용하지만, 존재를 모르면 놓치기 쉽다고 생각합니다.
3개의 좋아요
Johani
(Joe)
10월 28, 2019, 10:41오전
6
리사이즈 컨트롤을 미리보기에 무조건적으로 표시하는 데에는 세 가지 이유로 아무런 해가 없다고 생각합니다:
첫째, 우리는 컨트롤을 단순히 opacity를 조절하여 “숨기고” 있습니다.
.button-wrapper {
box-sizing: border-box;
padding: 0.25em 0.5em;
min-width: 19em; // wide enough to contain all controls
width: 100%;
display: flex;
flex-wrap: nowrap;
align-items: center;
gap: 0 0.5em;
position: absolute;
height: var(--resizer-height);
bottom: 0;
left: 0;
opacity: 0.9;
z-index: 1; // needs to be higher than image
background: var(--secondary);
color: var(--primary);
.scale-btn-container,
.alt-text-readonly-container,
즉, 컨트롤이 보이지 않더라도 여전히 일정한 공간을 차지합니다. 래퍼는 절대 위치(absolutely positioned)로 설정되어 있지만, .image-wrapper에 일부 패딩을 추가하고 있습니다.
둘째, 이렇게 하면 모바일에서도 해당 기능이 작동하게 됩니다. 현재는 작동해야 하는데 제 환경에서는 작동하지 않습니다.
셋째, 이렇게 하면 해당 기능의 발견 가능성(discoverability)이 높아집니다.
그 외 대안으로, 개별 이미지가 아닌 미리보기 패널 전체에 마우스를 올렸을 때 모든 이미지의 컨트롤이 보이도록 설정할 수 있습니다. 또한 모바일에서의 문제(내 기기에만 제한된 문제일 수 있음)도 수정할 수 있습니다.
컨트롤을 무조건적으로 보이게 한다면, 그 외관을 더 아름답게 다듬는 데에도 조금 시간을 할애할 수 있습니다.
15개의 좋아요
네, 저는 이 컨트롤이 항상 표시되고 이미지 위에 오버레이로 겹쳐서, 작성기에서 실제 게시글과 간격이 더 넓어 보이지 않도록 하는 걸 선호합니다.
처음에 이렇게 하지 않은 이유는, 타이핑할 때 컨트롤이 심하게 깜빡였기 때문이에요. 깜빡임을 줄이는 변경 사항이 몇 가지 적용된 것 같긴 하지만, 여전히 타이핑을 시작하면 컨트롤이 DOM에서 완전히 제거되고 있습니다… 그 문제가 해결되면 @johani ! 님, 컨트롤이 항상 보이도록 스타일을 변경하는 데 전혀 문제없습니다!
8개의 좋아요
sam
(Sam Saffron)
10월 29, 2019, 4:55오전
8
투명도를 제거하면 깜빡임이 보이지 않으니, 문제를 해결한 것 같네요?
(1)은 다음 커밋으로 수정했습니다:
committed 04:52AM - 29 Oct 19 UTC
Defer placing scale buttons causes "scale image" buttons to be missing if
you ma… nage to scroll mouse to the area where the image is prior to image
rendering.
This fix ensures scale buttons are always rendered leaving all the hiding
and styling entirely to CSS.
This also corrects a bug where scaling toolbar was missing on mobile
하지만 여전히 핵심 문제는 호버에 의존하며, 문제점을 쉽게 발견하기 어렵다는 점이라고 생각합니다.
@Johani 이제 스타일링을 위한 테마 컴포넌트를 만들어 보시겠어요? (원하는 스타일을 순수 CSS로 구현할 수 있으니까요) 이 경우 매우 매우 짧은 이미지에서 테스트를 꼭 해주세요. 그런 다음 dev와 meta에 컴포넌트를 설치해서 한동안 사용해 본 후, 이 방식이 더 나은지 여부를 결정해 보죠?
8개의 좋아요
네, 어딘가에 디바운스가 추가된 것 같네요? 첫 번째 문제를 수정한 이후로는 모든 것이 정상적으로 보입니다.
3개의 좋아요
와, 2019년이 벌써 일 년 전이었다니 믿기지가 않아요
main ← ux-image-preview-controls
merged 12:43PM - 17 Jun 24 UTC
This makes it so the image resize/alt-text controls in the composer editor are a… lways visible on desktop, instead of relying on hover (they're already always visible in the mobile preview).
This makes the controls more discoverable, and if we position them over the image, it means we end up with a preview that has spacing much closer to the cooked result.
We planned on doing this long ago, but lost sight of it: https://meta.discourse.org/t/make-it-more-obvious-an-image-is-resizable-when-uploading-an-image/132030
Before:

After:

and cooked spacing...
Preview before:

Preview after:

Actual spacing in cooked post:

For tiny images... more of the image is obscured this way, but there's a slight transparency so it's still somewhat visible:
Before:

After:

Other states like grid and editing:


3개의 좋아요
개인적으로 이 변경 사항에 전혀 찬성하지 않습니다. 훨씬 더 복잡해졌거든요. 리사이징의 발견 가능성에 실제로 문제가 있었나요?
1개의 좋아요