It is not a problem in desktop, because there is no scroll bar, but in
mobile you can scroll with touch, and i need the months to snap to the
start for the next and previous buttons to work.
I can use overflow for that in most sizes, but on mobile the buttons
are outside the overflow and are not visible, thus have to revert it
and then remove the right margin to avoid the extra space. Since on
mobile we only show a single slide at a time, the lack of margin is not
noticeable.
Had to change the link to the current language version of the page by a
button, to prevent following a link when trying to expand the submenu.
At first i did this with an `onclick="return false"` bullshit, but the
link was the wrong thing to do here, and it was there only to satisfy
Google et al. They will have to with the links in head.
Also made the link and buttons larger to make it easier to hit them with
finger.
The change to column was from when the button and the text were both on the slide,
but now it only made the text stick to the top, which is the reverse of what we
wanted, but had to increase the space between the text and the booking button.
Customer told us that the minimum number of nights is per campsite type,
not per season. And he wants this, along with the maximum number of
nights, in order to limit the range of departure dates that guests can
choose when booking.
It seems that we have to highlight the map zones too. On the previous
website, they had a mouseover effect that displayed a tooltip, but here
we can not do that because we use the mouse to select accommodations.
This is just a test to see whether Oriol likes how it is shown, thus the
red is likely to change to something else more pleasant to look at.
This does nothing but bring useless work to the browser, that has to
move the SVG group to the top for nothing, as the accommodations do not
overlap anything else.
There are many installations on the map that are drawn with rect
instead of path. I could transform them with Inkscape, but i finally
found out about DOMMatrix, that helps me a lot to convert points, as
it can parse the values of the `transform` attribute.
I also saw that SVGGraphicElements has getCTM() and getScreenCTM(), but
neither of them worked for me: the resulting transformation was “shrunk”
on the map (i.e., like it was scaled down).
This is more or less the same as the campsites, as public information
goes, but for buildings and other amenities that the camping provides
that are not campsites.
A small page with a brief description, carousel, and feature list of
each individual accommodation.
Most of the relations and functions for carousel and features are like
the ones for campsite types, but i had to use the accommodation’s label
to find them, because they do not have slugs; i did not even though
these would be public, and they already have a label, although not
unique for all companies, like UUID slugs are.
I can not use <a> in that map because Leaflet handles the mouse over
before the anchors sees it, thus it is impossible to click on them; i
have to use a Leaflet layer.
Fortunately, i can just use the <path>’s coordinates as
the polygon points, because with CRS.Simple the coordinates map to
pixel, except for the reversed Y/latitude coordinate. Unfortunately,
<path> coordinates are not straightforward to get: I have to follow the
drawing coordinates, taking into account the current transformation
(CTM), and keeping the last point around for relative coordinates.
Bézier curves are simplified to a straight line from start to end.
There is one single accommodation that started with a relative move
command (m), which apparently have to be treated as an absolute
move (M), but subsequent pairs are treated as relative coordinates[0].
It was easier for me to convert that relative move to absolute and add
a relative lineto command (l) to the next pair.
For now, all i do is highlight the accommodation and zoom it on click,
because i do not know how i should the accommodation’s information.
[0]: https://www.w3.org/TR/SVG11/paths.html#PathDataMovetoCommands
In the map i added in e3503187d, paths around each accommodation
inherited the fill and stroke from the group, thus i could just override
that fill at the anchor level, but the current map sets the fill to each
accommodation’s path, party because the text is not a path too, partly
because Affinity is a visual tool only and does not give a shit about
mark up.
If we keep the text in a group, however, we can set the fill of the area
using CSS too, although it is not nice due to `!important`, but still.
There was a plot, however, #93, that had the area in a group too, and
i had to remove that group manually.
It seems that the prefix got removed in one of the edits.
Also, Affinity does not give a fuck to what classes we give to the
elements, and just removes them, thus .guest-only no longer matches, and
had to hide the layers by id. Hope they hold this time.
There is no kayaking, canoe, or raft icon in Font Awesome[0], so i redid
the kayak icon in more or less the same style, but shittier, of course.
Oriol also asked me to add the sailboat, that may replace the use of
kayak.
[0]: https://github.com/FortAwesome/Font-Awesome/issues/10772
We were using what was very clearly a campfire as the icon for the
barbecue service, when we first replaced it with a Font Awesome icon
we chose an icon that was neither campfire nor barbecue (flame-curved),
but now Oriol wanted one that left no doubt it was a barbecue.
Instead of replacing the campfire SVG with that of the barbecue, i have
chosen a campfire image from Font Awesome for our icon, and added a
separate icon for that service.
Previously, the only type with options was plots, that was always the
third fieldset, which was the wrong thing to hardcode, but it was done
in a hurry. Now there are more types with options, so we have to do it
properly.
jordi fita mas
oriol carbonell pujolàs