feat(weather): enable CSS ordering for forecast and hourly columns

[MannXo]

The daily forecast previously displayed its columns in a fixed order that did not match the order requested in the issue.

This PR makes the forecast column order configurable through CSS custom properties. The default order is now:

condition, min temp (low), max temp (high), UV Index, precipitation amount, precipitation probability

The hourly forecast is updated to use the same approach, with its own configurable column order.

• Moves min-temp before max-temp (low before high, per [Change Request] Weather forecast: Low before High Temperature #4116)
• Moves UV Index block before precipitation blocks
• Adds configurable CSS ordering for forecast and hourly columns
• Replaces an invalid <tr> in the current weather view with a <div>

Fixes #4117

forecast before

forecast after

hourly before

hourly after

---

Note: The PR was updated based on reviews, and the PR text was updated accordingly.

[KristjanESPERANTO]

Thanks for the PR! Can you attach a before and after screenshot?

[rejas]

I am not sure if changing the order is a good idea. Our users are used to how this is ordered now, changing it might confuse some...

But I am willing to see the change in screenshots, before making up my mind finally...

[KristjanESPERANTO]

@MannXo Did you noticed the request for screenshots? 🙂

[MannXo]

@KristjanESPERANTO thank you for the reminder.
the before after screenshots are attached.

[KristjanESPERANTO]

@MannXo Thanks for the screenshots 🙂 Please mark which is which. I think the first is the "after" one, right?

[MannXo]

@KristjanESPERANTO indeed.
First one is the "after" and second one is "before"

[KristjanESPERANTO]

@rejas What do you think?

[rejas]

Sorry for my late answer... Thanks fro your PR. I could see something like this merged, IF we could make the order configurable. So that people could arrange them to their likings. Maybe using a flex order css property would be the solution (so people could change that order via custom css)
@MannXo are you comfortable trying something like this out? Or how good are your css skills?

[KristjanESPERANTO]

@MannXo Did you noticed the last comment? 🙂

[MannXo]

@KristjanESPERANTO I feel I can do that. shall I create an issue for it first? or shall I just revert my commits on this branch and implement the flex?

[KristjanESPERANTO]

I think it would be best to do it in this PR here. When we merge, we'll squash all the commits into one, so you don't have to worry too much about keeping the Git history clean 🙂

[MannXo]

@rejas @KristjanESPERANTO
I updated this PR to make the forecast column order configurable via CSS.

The forecast table now has a weather-forecast class, and each forecast cell has a default order value backed by CSS variables, so users can override the visual order from custom.css without changing the module template.
I also added an e2e assertion for the CSS order hooks.

example:

.weather .weather-forecast {
  --weather-forecast-min-temp-order: 4;
  --weather-forecast-max-temp-order: 3;
}

[KristjanESPERANTO]

Thanks for the updated approach 👏

Two concerns though:

1. display: flex on <tr>
order is only defined for flex/grid items, so applying flex to a table row to make it work feels a bit hacky. Since the table has no <th> headers anyway, a <div>-based flex layout might be the cleaner path forward.

2. Order-dependent padding
   min-temp loses padding-left, max-temp gains it. That works for the new default, but breaks as soon as someone actually swaps the order via the CSS variables. Padding should be independent of position.

What do you think?

[KristjanESPERANTO]

@MannXo Did you noticed my comment? 🙂

[KristjanESPERANTO]

Okay, I decided to take this on myself since there hasn’t been any response from @MannXo so far.

Migrating the forecast layout to CSS Grid was a bit tricky, but I think the result is now clean and stable. For consistency, I adapted the hourly view as well.

I added screenshots into the PR text.

While checking the current view, I noticed that an incorrect <td> element was being used, so I replaced it with a proper <div>. That is a bit out of scope, but too small for a separate PR.