Margin is different than what I would expect

Package version

No response

Flutter version

No response

Steps to reproduce

https://github.com/conceptadev/mix/assets/351125/07f5d6f5-bb89-4239-a481-c67c24640ef9

Expected results

I expect margin to not be included in the GestureListener, just like the web ( <a href="https://tailwindcss.com/docs" class="text-sky-500 hover:text-sky-600 bg-red-500 m-16">Read the docs &rarr;</a>)

Actual results

.

Code sample

Style(margin(16))

@bernaferrari This is not the behavior of Flutter, so I think a new widget will have to be created to have this behavior. I am working on a presentation using Mix as a demo to bring html into Flutter (still working on the title), but I think I can build an example.

Flutter barely has the margin concept. If you want a Button with a margin, the official way is Padding(child: Button).

It does through the Container; however the, the events wrap the whole widget; that is why you see that behavior; we can extend a new widget or maybe even a decorator to help with this, but the current implementation is behaving correctly, but we will implement a solution for your case.

There is another aspect to this and it is ensuring minimal touch target for the UX. Playing with the margin is one of the simpler implicit ways to ensure that for visually small interactive components eg CheckBox and Radio you can actually ensure that the finger can actually hit it with comfort without affecting the visual size of the widget. From my own experience using margin for layout purposes should be kept as last resort as there always better or more readable alternatives for layout or to achieve spacing.

I disagree. The minimum touch target is super bad UX that only flutter does. You won't see in Android, iOS, web, macOS, anywhere.

On Sat, Jun 8, 2024, 08:47 Harry Sild @.***> wrote:

There is another aspect to this and it is ensuring minimal touch target for the UX. Playing with the margin is one of the simpler implicit ways to ensure that for visually small interactive components eg CheckBox and Radio you can actually ensure that the finger can actually hit it with comfort without affecting the visual size of the widget. From my own experience using margin for layout purposes should be kept as last resort as there always better or more readable alternatives for layout or to achieve spacing.

— Reply to this email directly, view it on GitHub https://github.com/conceptadev/mix/issues/208#issuecomment-2156002507, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACVXFMXXOHKEJPZIWNF5HTZGLVNXAVCNFSM6AAAAABDFAJAFCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJWGAYDENJQG4 . You are receiving this because you were mentioned.Message ID: @.***>

Eh? Every touch interface makes some sort of affordance to increase touch area for interactables. Otherwise you would be hard pressed to ever hit those 12x12 checkboxes and radios. Or any sort of close button with X icon. Android, iOS. The biggest issue imo with accounting for touch area is that it directly affects layout, so if you want to hit those UX accessibility goals your UI code can become seriously ugly.

What you mentioned uses either a fixed size or padding.

Android doesn't use the tap touch target for anything like flutter does. It is just a please use padding. Flutter adds unwanted space sometimes which causes layout bugs. But even then, in Flutter, that's 100% padding.

This shows layout bounds. That does not have to mean that is the extent of the touch area. The menu items on that screenshot function as one big touch area. The left arrow and the magnifying glass "buttons" are the real showcase of having to adjust components to meet the touch area target. Whether it's done by padding/margin, flex components with left or right alignment props or any other way is kind of beside the point, one way or other hoops are being jumped through to hit the minimal touch target.

If you are talking about Flutter making use of this crap in many components, then I agree with you. Yet one more example of Flutter team being very clueless or idealistic about scalable layouts.