...
```
when it could have been half the size, if developers werent in the routine of returning and wrapping `div`s.:
```auto
...
```
Those sorts of super dom stacks inevitably lead to persistent problems with scroll bars being on the wrong element and areas of the page rendering either too short or beyond the page limits. Its just very difficult to manage the relationship between all those nodes. Its very difficult for developers to even conceptualize what the different layers are meant to do, which I think is reflected in the challenge of giving distinct names to several arbitrary layers (“main”, “root”, “container”, “page”, etc).
---
**Author:**  [@Janiczek](https://discourse.elm-lang.org/u/Janiczek)\
**Post date:** [February 25, 2021, 5:14pm UTC](https://discourse.elm-lang.org/t/html-fragment-list-html-msg-html-msg/6992/15 "2021-02-25T17:14:29Z")
I think I understand the gist but the examples don’t typecheck in my head. What’s the type annotation of buttonView - does it also return a List? Then we’re missing some List.concats somewhere?
Could you please make an Ellie so that I’m sure I’m not misunderstanding the idea? 🙂
---
**Author:**  [@Chadtech](https://discourse.elm-lang.org/u/Chadtech)\
**Post date:** [February 25, 2021, 5:35pm UTC](https://discourse.elm-lang.org/t/html-fragment-list-html-msg-html-msg/6992/16 "2021-02-25T17:35:56Z")
Oh shoot. I made some type errors in my example.
Heres what I was aiming for, in this type-checked ellie: [https://ellie-app.com/ctgbXkwCcp2a1](https://ellie-app.com/ctgbXkwCcp2a1)
---
**Author:**  [@allanderek](https://discourse.elm-lang.org/u/allanderek)\
**Post date:** [February 25, 2021, 7:59pm UTC](https://discourse.elm-lang.org/t/html-fragment-list-html-msg-html-msg/6992/17 "2021-02-25T19:59:13Z")
It’s great to hear from someone with an opposing view. Proposal threads often turn into something like an echo chamber, where everyone agrees the proposed feature is great/not-useful.
> [@Chadtech](#):
>
> In more concrete terms, heres an example of an unfortunate situation I have been stuck with many times, where there are like 10 levels of html between the `` and the _first_ part of what the UI is meant to render:
I think this is the sort of state that @Janiczek is attempting to help **prevent**. I think the point is that these can occur _because_ there is no `Html.fragment`. So people are in a situation where their current function returns an `Html Msg`, but they have to add an element to it. Maybe they are returning a checkbox and realise that they should also return an associated `Html.label` element. Now perhaps what they **should** do is change the return type of the function to be `List (Html Msg)`, and then refactor at all the places that call it, but what they do instead is wrap it in a `Html.div [Html.Attributes.class "checkbox-container"]` and move on. What you end up with if you do that a few times is the kind of situation you describe where you have a bunch of divs with nothing in between the levels (like Chapter, sub-section, sub-sub-section headers with no text before inner most ‘sub-\*section’) If `Html.fragment` were a thing, then what they could do instead is just wrap the checkbox and label inside a `Html.fragment` and then they would still appear at the outer level with no "checkbox-container’ `div`.
I cannot quite shake the feeling that there is some hidden gotcha here, like maybe this means that basically **all** (view) functions return an `Html Msg` and we end up losing some important typing distinctions.
---
**Author:**  [@Chadtech](https://discourse.elm-lang.org/u/Chadtech)\
**Post date:** [February 25, 2021, 8:40pm UTC](https://discourse.elm-lang.org/t/html-fragment-list-html-msg-html-msg/6992/18 "2021-02-25T20:40:24Z")
Okay I see. I think maybe I rushed into this topic too fast talking about the problems of overly layered html. We are all more or less aligned against that.
We’ve brought up `batch` functions in this thread. `Sub.batch`, `Cmd.batch`, and `Css.batch` seem to work pretty well in practice, so, maybe it wouldnt be so bad if there was an `Html.batch`. On the other hand, if Elm didnt have `Sub.batch` or `Cmd.batch` built in, then I think our next best alternative would be `update` functions returning `List (Cmd msg)` and `subscriptions : List (Sub msg)`; and we would have to use `++` and `List.concat` to merge groups of different `Cmd` or `Sub`. Which in my opinion is only slightly worse than what we have today with `batch`.
---
**Author:**  [@aguzubiaga](https://discourse.elm-lang.org/u/aguzubiaga)\
**Post date:** [February 25, 2021, 9:33pm UTC](https://discourse.elm-lang.org/t/html-fragment-list-html-msg-html-msg/6992/19 "2021-02-25T21:33:24Z")
I think `display: contents` is supposed to eliminate the CSS side-effects of wrapping things in a `div`. From [the spec](https://www.w3.org/TR/css-display-3/#box-generation):
> For the purposes of box generation and layout, the element must be treated as if it had been replaced in the element tree by its contents
That said, it looks like not all browsers support it entirely: [CSS display: contents | Can I use... Support tables for HTML5, CSS3, etc](https://caniuse.com/css-display-contents)
---
**Author:**  [@joakin](https://discourse.elm-lang.org/u/joakin)\
**Post date:** [February 26, 2021, 6:50pm UTC](https://discourse.elm-lang.org/t/html-fragment-list-html-msg-html-msg/6992/20 "2021-02-26T18:50:48Z")
> [@allanderek](#):
>
> Now perhaps what they **should** do is change the return type of the function to be `List (Html Msg)` , and then refactor at all the places that call it, but what they do instead is wrap it in a `Html.div [Html.Attributes.class "checkbox-container"]` and move on.
Rather than “perhaps” I’d say “often”, and use the friendly compiler and fearlessly refactor the code to fit the problem.
This seems like a social problem, and even if you have `Html.fragment`, why wouldn’t people keep doing what you just mentioned?
Good coding practices come from working with others, reviewing code, and healthy discussion. Linters like elm-review can help with these things some times too. There is no way around it.
I think Chad brings a great point, it is all functions and changing the return type helps with this.
* * *
I don’t have anything against the proposal, the impact in the virtual dom library is probably the most important thing to assess.
It would definitely be handy to have `fragment` because if you have functions that return `List (Html msg)` you can’t `map` over them like you can with a `Html msg`, which is very useful.
In the previous example you’d have to `saveButtons isSaved |> List.map (Html.map fn)` which is not the end of the world but not very ergonomic if you have to do it in many places with the `List.concat`s or `++`s.
[Next page](https://discourse.elm-lang.org/t/html-fragment-list-html-msg-html-msg/6992.md?page=2)