Split templates and handlers into admin and public
I need to check that the user is an employee (or admin) in
administration handlers, but i do not want to do it for each handler,
because i am bound to forget it. Thus, i added the /admin sub-path for
these resources.
The public-facing web is the rest of the resources outside /admin, but
for now there is only home, to test whether it works as expected or not.
The public-facing web can not relay on the user’s language settings, as
the guest user has no way to set that. I would be happy to just use the
Accept-Language header for that, but apparently Google does not use that
header[0], and they give four alternatives: a country-specific domain,
a subdomain with a generic top-level domain (gTLD), subdirectories with
a gTLD, or URL parameters (e.g., site.com?loc=de).
Of the four, Google does not recommend URL parameters, and the customer
is already using subdirectories with the current site, therefor that’s
what i have chosen.
Google also tells me that it is a very good idea to have links between
localized version of the same resources, either with <link> elements,
Link HTTP response headers, or a sitemap file[1]; they are all
equivalent in the eyes of Google.
I have choosen the Link response headers way, because for that i can
simply “augment” ResponseHeader to automatically add these headers when
the response status is 2xx, otherwise i would need to pass down the
original URL path until it reaches the template.
Even though Camper is supposed to be a “generic”, multi-company
application, i think i will stick to the easiest route and write the
templates for just the “first” customer.
[0]: https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites
[1]: https://developers.google.com/search/docs/specialty/international/localized-versions
2023-08-05 01:42:37 +00:00
|
|
|
/**
|
|
|
|
|
* SPDX-FileCopyrightText: 2023 jordi fita mas <jordi@tandem.blog>
|
|
|
|
|
* SPDX-License-Identifier: AGPL-3.0-only
|
|
|
|
|
*/
|
2023-09-05 02:40:48 +00:00
|
|
|
@font-face {
|
|
|
|
|
font-family: 'Mabry Pro';
|
|
|
|
|
src: local('Mabry Pro Bold'), local('MabryPro-Bold'), url('fonts/MabryPro-Bold.woff2') format('woff2');
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
font-style: normal;
|
|
|
|
|
font-display: swap;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@font-face {
|
|
|
|
|
font-family: 'Mabry Pro';
|
|
|
|
|
src: local('Mabry Pro Medium'), local('MabryPro-Medium'), url('fonts/MabryPro-Medium.woff2') format('woff2');
|
|
|
|
|
font-weight: 500;
|
|
|
|
|
font-style: normal;
|
|
|
|
|
font-display: swap;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@font-face {
|
|
|
|
|
font-family: 'Mabry Pro';
|
|
|
|
|
src: local('Mabry Pro Black'), local('MabryPro-Black'), url('fonts/MabryPro-Black.woff2') format('woff2');
|
|
|
|
|
font-weight: 900;
|
|
|
|
|
font-style: normal;
|
|
|
|
|
font-display: swap;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@font-face {
|
|
|
|
|
font-family: 'Mabry Pro';
|
|
|
|
|
src: local('Mabry Pro Light Italic'), local('MabryPro-LightItalic'), url('fonts/MabryPro-LightItalic.woff2') format('woff2');
|
|
|
|
|
font-weight: 300;
|
|
|
|
|
font-style: italic;
|
|
|
|
|
font-display: swap;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@font-face {
|
|
|
|
|
font-family: 'Mabry Pro';
|
|
|
|
|
src: local('Mabry Pro Bold Italic'), local('MabryPro-BoldItalic'), url('fonts/MabryPro-BoldItalic.woff2') format('woff2');
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
font-style: italic;
|
|
|
|
|
font-display: swap;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@font-face {
|
|
|
|
|
font-family: 'Mabry Pro';
|
|
|
|
|
src: local('Mabry Pro Light'), local('MabryPro-Light'), url('fonts/MabryPro-Light.woff2') format('woff2');
|
|
|
|
|
font-weight: 300;
|
|
|
|
|
font-style: normal;
|
|
|
|
|
font-display: swap;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@font-face {
|
|
|
|
|
font-family: 'Mabry Pro';
|
|
|
|
|
src: local('Mabry Pro Black Italic'), local('MabryPro-BlackItalic'), url('fonts/MabryPro-BlackItalic.woff2') format('woff2');
|
|
|
|
|
font-weight: 900;
|
|
|
|
|
font-style: italic;
|
|
|
|
|
font-display: swap;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@font-face {
|
|
|
|
|
font-family: 'Mabry Pro';
|
|
|
|
|
src: local('Mabry Pro Medium Italic'), local('MabryPro-MediumItalic'), url('fonts/MabryPro-MediumItalic.woff2') format('woff2');
|
|
|
|
|
font-weight: 500;
|
|
|
|
|
font-style: italic;
|
|
|
|
|
font-display: swap;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@font-face {
|
|
|
|
|
font-family: 'Mabry Pro';
|
|
|
|
|
src: local('Mabry Pro Italic'), local('MabryPro-Italic'), url('fonts/MabryPro-Italic.woff2') format('woff2');
|
|
|
|
|
font-weight: normal;
|
|
|
|
|
font-style: italic;
|
|
|
|
|
font-display: swap;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@font-face {
|
|
|
|
|
font-family: 'Mabry Pro';
|
|
|
|
|
src: local('Mabry Pro'), local('MabryPro-Regular'), url('fonts/MabryPro-Regular.woff2') format('woff2');
|
|
|
|
|
font-weight: normal;
|
|
|
|
|
font-style: normal;
|
|
|
|
|
font-display: swap;
|
|
|
|
|
}
|
Split templates and handlers into admin and public
I need to check that the user is an employee (or admin) in
administration handlers, but i do not want to do it for each handler,
because i am bound to forget it. Thus, i added the /admin sub-path for
these resources.
The public-facing web is the rest of the resources outside /admin, but
for now there is only home, to test whether it works as expected or not.
The public-facing web can not relay on the user’s language settings, as
the guest user has no way to set that. I would be happy to just use the
Accept-Language header for that, but apparently Google does not use that
header[0], and they give four alternatives: a country-specific domain,
a subdomain with a generic top-level domain (gTLD), subdirectories with
a gTLD, or URL parameters (e.g., site.com?loc=de).
Of the four, Google does not recommend URL parameters, and the customer
is already using subdirectories with the current site, therefor that’s
what i have chosen.
Google also tells me that it is a very good idea to have links between
localized version of the same resources, either with <link> elements,
Link HTTP response headers, or a sitemap file[1]; they are all
equivalent in the eyes of Google.
I have choosen the Link response headers way, because for that i can
simply “augment” ResponseHeader to automatically add these headers when
the response status is 2xx, otherwise i would need to pass down the
original URL path until it reaches the template.
Even though Camper is supposed to be a “generic”, multi-company
application, i think i will stick to the easiest route and write the
templates for just the “first” customer.
[0]: https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites
[1]: https://developers.google.com/search/docs/specialty/international/localized-versions
2023-08-05 01:42:37 +00:00
|
|
|
|
|
|
|
|
*, *::before, *::after {
|
2023-09-05 02:40:48 +00:00
|
|
|
box-sizing: inherit;
|
Split templates and handlers into admin and public
I need to check that the user is an employee (or admin) in
administration handlers, but i do not want to do it for each handler,
because i am bound to forget it. Thus, i added the /admin sub-path for
these resources.
The public-facing web is the rest of the resources outside /admin, but
for now there is only home, to test whether it works as expected or not.
The public-facing web can not relay on the user’s language settings, as
the guest user has no way to set that. I would be happy to just use the
Accept-Language header for that, but apparently Google does not use that
header[0], and they give four alternatives: a country-specific domain,
a subdomain with a generic top-level domain (gTLD), subdirectories with
a gTLD, or URL parameters (e.g., site.com?loc=de).
Of the four, Google does not recommend URL parameters, and the customer
is already using subdirectories with the current site, therefor that’s
what i have chosen.
Google also tells me that it is a very good idea to have links between
localized version of the same resources, either with <link> elements,
Link HTTP response headers, or a sitemap file[1]; they are all
equivalent in the eyes of Google.
I have choosen the Link response headers way, because for that i can
simply “augment” ResponseHeader to automatically add these headers when
the response status is 2xx, otherwise i would need to pass down the
original URL path until it reaches the template.
Even though Camper is supposed to be a “generic”, multi-company
application, i think i will stick to the easiest route and write the
templates for just the “first” customer.
[0]: https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites
[1]: https://developers.google.com/search/docs/specialty/international/localized-versions
2023-08-05 01:42:37 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
* {
|
|
|
|
|
margin: 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
html {
|
2023-09-05 02:40:48 +00:00
|
|
|
box-sizing: border-box;
|
Split templates and handlers into admin and public
I need to check that the user is an employee (or admin) in
administration handlers, but i do not want to do it for each handler,
because i am bound to forget it. Thus, i added the /admin sub-path for
these resources.
The public-facing web is the rest of the resources outside /admin, but
for now there is only home, to test whether it works as expected or not.
The public-facing web can not relay on the user’s language settings, as
the guest user has no way to set that. I would be happy to just use the
Accept-Language header for that, but apparently Google does not use that
header[0], and they give four alternatives: a country-specific domain,
a subdomain with a generic top-level domain (gTLD), subdirectories with
a gTLD, or URL parameters (e.g., site.com?loc=de).
Of the four, Google does not recommend URL parameters, and the customer
is already using subdirectories with the current site, therefor that’s
what i have chosen.
Google also tells me that it is a very good idea to have links between
localized version of the same resources, either with <link> elements,
Link HTTP response headers, or a sitemap file[1]; they are all
equivalent in the eyes of Google.
I have choosen the Link response headers way, because for that i can
simply “augment” ResponseHeader to automatically add these headers when
the response status is 2xx, otherwise i would need to pass down the
original URL path until it reaches the template.
Even though Camper is supposed to be a “generic”, multi-company
application, i think i will stick to the easiest route and write the
templates for just the “first” customer.
[0]: https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites
[1]: https://developers.google.com/search/docs/specialty/international/localized-versions
2023-08-05 01:42:37 +00:00
|
|
|
font-size: 62.5%;
|
2023-09-05 02:40:48 +00:00
|
|
|
--contrast: #303334;
|
|
|
|
|
--contrast-2: #5f6158;
|
|
|
|
|
--contrast-3: #b2b2be;
|
|
|
|
|
--base: #f0f0f0;
|
|
|
|
|
--base-2: #f7f8f9;
|
|
|
|
|
--base-3: #ffffff;
|
|
|
|
|
--accent: #00aa7d;
|
|
|
|
|
--accent-2: #FFE37F;
|
|
|
|
|
--accent-3: #9adff4;
|
|
|
|
|
--clar-rgb: 239, 237, 236;
|
|
|
|
|
--clar: rgb(var(--clar-rgb));
|
Split templates and handlers into admin and public
I need to check that the user is an employee (or admin) in
administration handlers, but i do not want to do it for each handler,
because i am bound to forget it. Thus, i added the /admin sub-path for
these resources.
The public-facing web is the rest of the resources outside /admin, but
for now there is only home, to test whether it works as expected or not.
The public-facing web can not relay on the user’s language settings, as
the guest user has no way to set that. I would be happy to just use the
Accept-Language header for that, but apparently Google does not use that
header[0], and they give four alternatives: a country-specific domain,
a subdomain with a generic top-level domain (gTLD), subdirectories with
a gTLD, or URL parameters (e.g., site.com?loc=de).
Of the four, Google does not recommend URL parameters, and the customer
is already using subdirectories with the current site, therefor that’s
what i have chosen.
Google also tells me that it is a very good idea to have links between
localized version of the same resources, either with <link> elements,
Link HTTP response headers, or a sitemap file[1]; they are all
equivalent in the eyes of Google.
I have choosen the Link response headers way, because for that i can
simply “augment” ResponseHeader to automatically add these headers when
the response status is 2xx, otherwise i would need to pass down the
original URL path until it reaches the template.
Even though Camper is supposed to be a “generic”, multi-company
application, i think i will stick to the easiest route and write the
templates for just the “first” customer.
[0]: https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites
[1]: https://developers.google.com/search/docs/specialty/international/localized-versions
2023-08-05 01:42:37 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
body {
|
2023-09-05 02:40:48 +00:00
|
|
|
font-family: 'Mabry Pro', sans-serif;
|
Split templates and handlers into admin and public
I need to check that the user is an employee (or admin) in
administration handlers, but i do not want to do it for each handler,
because i am bound to forget it. Thus, i added the /admin sub-path for
these resources.
The public-facing web is the rest of the resources outside /admin, but
for now there is only home, to test whether it works as expected or not.
The public-facing web can not relay on the user’s language settings, as
the guest user has no way to set that. I would be happy to just use the
Accept-Language header for that, but apparently Google does not use that
header[0], and they give four alternatives: a country-specific domain,
a subdomain with a generic top-level domain (gTLD), subdirectories with
a gTLD, or URL parameters (e.g., site.com?loc=de).
Of the four, Google does not recommend URL parameters, and the customer
is already using subdirectories with the current site, therefor that’s
what i have chosen.
Google also tells me that it is a very good idea to have links between
localized version of the same resources, either with <link> elements,
Link HTTP response headers, or a sitemap file[1]; they are all
equivalent in the eyes of Google.
I have choosen the Link response headers way, because for that i can
simply “augment” ResponseHeader to automatically add these headers when
the response status is 2xx, otherwise i would need to pass down the
original URL path until it reaches the template.
Even though Camper is supposed to be a “generic”, multi-company
application, i think i will stick to the easiest route and write the
templates for just the “first” customer.
[0]: https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites
[1]: https://developers.google.com/search/docs/specialty/international/localized-versions
2023-08-05 01:42:37 +00:00
|
|
|
font-size: 1.6rem;
|
|
|
|
|
line-height: 1.5;
|
|
|
|
|
-webkit-font-smoothing: antialiased;
|
2023-09-05 02:40:48 +00:00
|
|
|
background-color: var(--clar);
|
|
|
|
|
color: var(--contrast);
|
|
|
|
|
max-width: 200rem;
|
|
|
|
|
margin-left: auto;
|
|
|
|
|
margin-right: auto;
|
Split templates and handlers into admin and public
I need to check that the user is an employee (or admin) in
administration handlers, but i do not want to do it for each handler,
because i am bound to forget it. Thus, i added the /admin sub-path for
these resources.
The public-facing web is the rest of the resources outside /admin, but
for now there is only home, to test whether it works as expected or not.
The public-facing web can not relay on the user’s language settings, as
the guest user has no way to set that. I would be happy to just use the
Accept-Language header for that, but apparently Google does not use that
header[0], and they give four alternatives: a country-specific domain,
a subdomain with a generic top-level domain (gTLD), subdirectories with
a gTLD, or URL parameters (e.g., site.com?loc=de).
Of the four, Google does not recommend URL parameters, and the customer
is already using subdirectories with the current site, therefor that’s
what i have chosen.
Google also tells me that it is a very good idea to have links between
localized version of the same resources, either with <link> elements,
Link HTTP response headers, or a sitemap file[1]; they are all
equivalent in the eyes of Google.
I have choosen the Link response headers way, because for that i can
simply “augment” ResponseHeader to automatically add these headers when
the response status is 2xx, otherwise i would need to pass down the
original URL path until it reaches the template.
Even though Camper is supposed to be a “generic”, multi-company
application, i think i will stick to the easiest route and write the
templates for just the “first” customer.
[0]: https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites
[1]: https://developers.google.com/search/docs/specialty/international/localized-versions
2023-08-05 01:42:37 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
img, picture, video, canvas, svg {
|
|
|
|
|
display: block;
|
|
|
|
|
max-width: 100%;
|
|
|
|
|
}
|
|
|
|
|
|
Add the surroundings static page
This page is “highly stylized”, with a masonry-like grid, that i did not
know how to generate automatically from data defined in PostgreSQL,
therefore with Oriol we agreed to have this one as a static page and
we will see what we can do if the customer asks to be able to change
it.
I was a bit undecided on whether the icons in the bottom part of the
page should be defined in the CSS or with style="" and CSS variables,
like i do for the campsite type in the home page.
At first i thought that it should use CSS variables, mostly for
coherence: if another section of the web does it for its background
image, why no this one. The difference is that the home page is
dynamically created from the database, while this page is static and we
know what icons we need, thus it makes more sense to move it to the
stylesheet file, because then it will be downloaded by user agents that
actually want to use it (e.g., browsers, but not Braille terminals).
2023-09-16 22:11:39 +00:00
|
|
|
img {
|
|
|
|
|
height: auto;
|
|
|
|
|
}
|
|
|
|
|
|
Split templates and handlers into admin and public
I need to check that the user is an employee (or admin) in
administration handlers, but i do not want to do it for each handler,
because i am bound to forget it. Thus, i added the /admin sub-path for
these resources.
The public-facing web is the rest of the resources outside /admin, but
for now there is only home, to test whether it works as expected or not.
The public-facing web can not relay on the user’s language settings, as
the guest user has no way to set that. I would be happy to just use the
Accept-Language header for that, but apparently Google does not use that
header[0], and they give four alternatives: a country-specific domain,
a subdomain with a generic top-level domain (gTLD), subdirectories with
a gTLD, or URL parameters (e.g., site.com?loc=de).
Of the four, Google does not recommend URL parameters, and the customer
is already using subdirectories with the current site, therefor that’s
what i have chosen.
Google also tells me that it is a very good idea to have links between
localized version of the same resources, either with <link> elements,
Link HTTP response headers, or a sitemap file[1]; they are all
equivalent in the eyes of Google.
I have choosen the Link response headers way, because for that i can
simply “augment” ResponseHeader to automatically add these headers when
the response status is 2xx, otherwise i would need to pass down the
original URL path until it reaches the template.
Even though Camper is supposed to be a “generic”, multi-company
application, i think i will stick to the easiest route and write the
templates for just the “first” customer.
[0]: https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites
[1]: https://developers.google.com/search/docs/specialty/international/localized-versions
2023-08-05 01:42:37 +00:00
|
|
|
input, button, textarea, select {
|
|
|
|
|
font: inherit;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
p, h1, h2, h3, h4, h5, h6 {
|
|
|
|
|
overflow-wrap: break-word;
|
|
|
|
|
}
|
2023-09-05 02:40:48 +00:00
|
|
|
|
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
|
|
|
p + p {
|
|
|
|
|
margin-top: 1.5em;
|
|
|
|
|
}
|
|
|
|
|
|
Add the surroundings static page
This page is “highly stylized”, with a masonry-like grid, that i did not
know how to generate automatically from data defined in PostgreSQL,
therefore with Oriol we agreed to have this one as a static page and
we will see what we can do if the customer asks to be able to change
it.
I was a bit undecided on whether the icons in the bottom part of the
page should be defined in the CSS or with style="" and CSS variables,
like i do for the campsite type in the home page.
At first i thought that it should use CSS variables, mostly for
coherence: if another section of the web does it for its background
image, why no this one. The difference is that the home page is
dynamically created from the database, while this page is static and we
know what icons we need, thus it makes more sense to move it to the
stylesheet file, because then it will be downloaded by user agents that
actually want to use it (e.g., browsers, but not Braille terminals).
2023-09-16 22:11:39 +00:00
|
|
|
h2 {
|
|
|
|
|
font-size: 4.2rem;
|
|
|
|
|
font-weight: 400;
|
|
|
|
|
}
|
|
|
|
|
|
2023-09-05 02:40:48 +00:00
|
|
|
a {
|
|
|
|
|
color: var(--contrast);
|
|
|
|
|
text-decoration: none;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-06 20:02:59 +00:00
|
|
|
address {
|
|
|
|
|
font-style: normal;
|
|
|
|
|
}
|
|
|
|
|
|
2023-09-05 02:40:48 +00:00
|
|
|
body > a[href="#content"], .sr-only {
|
|
|
|
|
border: 0;
|
|
|
|
|
clip: rect(1px, 1px, 1px, 1px);
|
|
|
|
|
clip-path: inset(50%);
|
|
|
|
|
height: 1px;
|
|
|
|
|
margin: -1px;
|
|
|
|
|
overflow: hidden;
|
|
|
|
|
padding: 0;
|
|
|
|
|
position: absolute !important;
|
|
|
|
|
width: 1px;
|
|
|
|
|
word-wrap: normal !important;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
body > a[href="#content"]:focus {
|
|
|
|
|
background-color: #f1f1f1;
|
|
|
|
|
border-radius: 3px;
|
|
|
|
|
box-shadow: 0 0 2px 2px rgba(0, 0, 0, .6);
|
|
|
|
|
clip: auto !important;
|
|
|
|
|
clip-path: none;
|
|
|
|
|
color: #21759b;
|
|
|
|
|
display: block;
|
|
|
|
|
font-size: 1.4rem;
|
|
|
|
|
font-weight: 700;
|
|
|
|
|
height: auto;
|
|
|
|
|
left: 5px;
|
|
|
|
|
line-height: normal;
|
|
|
|
|
padding: 15px 23px 14px;
|
|
|
|
|
text-decoration: none;
|
|
|
|
|
top: 5px;
|
|
|
|
|
width: auto;
|
|
|
|
|
z-index: 100000;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
body > header {
|
|
|
|
|
position: sticky;
|
|
|
|
|
top: 0;
|
|
|
|
|
z-index: 999;
|
|
|
|
|
padding: 1rem 2.5rem;
|
|
|
|
|
display: flex;
|
|
|
|
|
align-items: center;
|
|
|
|
|
justify-content: space-between;
|
|
|
|
|
}
|
|
|
|
|
|
2023-09-11 03:13:57 +00:00
|
|
|
body > header, nav .has-submenu ul {
|
|
|
|
|
background-color: rgba(var(--clar-rgb), 0.7);
|
|
|
|
|
backdrop-filter: blur(10px);
|
|
|
|
|
}
|
|
|
|
|
|
2023-09-12 10:49:46 +00:00
|
|
|
h1 a {
|
|
|
|
|
display: flex;
|
|
|
|
|
align-items: center;
|
|
|
|
|
}
|
|
|
|
|
|
2023-09-05 02:40:48 +00:00
|
|
|
h1 a span {
|
|
|
|
|
display: inline-block;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
h1 a .logo {
|
2023-10-14 19:28:24 +00:00
|
|
|
width: 9rem;
|
|
|
|
|
height: 5.1633rem;
|
|
|
|
|
background: url('data:image/svg+xml,%3Csvg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 209.62463 120.27728"%3E%3Cpath d="m102.10584,21.36518s15.78382,27.66469,51.74793,31.08194l-1.43503,10.41504s-7.02735,3.85898-7.51532,4.45149c-.48786.5924-17.41148,7.42712-20.34098,7.59008-2.92939.16307-13.72109.10905-14.04701-.62769-.32603-.73675-16.96005-28.72295-16.95779-32.16343,0-.18506,3.01532-26.44336,8.54819-20.74742Z" fill="%23a4c480" stroke-width="0"/%3E%3Cpath d="m154.60698,63.26961l11.07138.63548s5.45032-48.4924-22.5546-52.25112l-.18608,1.29294,10.33565,13.93141,1.24885,16.53929-.4229,16.65601.5077,3.19599Z" fill="%23969189" stroke-width="0"/%3E%3Cpath d="m59.98896,13.07467s26.34299,16.24631,33.85829,32.03453h2.18499v-9.02184l2.23121-6.99542,5.14967-9.73333,3.96251-2.62987s8.53287-9.22889,29.83861-5.08471c21.30463,4.14418,22.90476,11.23106,26.57542,23.12839,3.67064,11.8962,1.89537,28.65032,1.89537,28.65032l11.17265,3.52303s-.09146-9.67818,2.9162-17.32566c3.00766-7.64736,5.56715-24.27484,19.32456-37.32302l1.35125-1.72351L132.62842,1.12773,59.72236,10.71343l.2666,2.36124Z" fill="%23d1c7b8" stroke-width="0"/%3E%3Cpath d="m175.91826,101.64108s11.48323-14.95787,10.31478-21.95104c-1.16855-6.99328-8.30382-14.01521-16.6462-15.6803-8.34227-1.66521-11.83564,0-11.83564,0l-3.14422-.74013-.92508-5.81706-2.4041-.75986s-7.30826-1.80944-9.24761.75986c-1.93936,2.56829-10.35775,5.34352-10.35775,5.34352l-6.4734,2.03409s-6.74439,3.44048-9.43154,2.48349c-2.68716-.9571-10.13413,6.76413-10.13413,6.76413l-6.14083,7.02734-1.08375,4.51092,4.27421.72581s31.57746,3.08581,33.05873,3.08581c1.48015,0,9.98774,1.85027,9.98774,1.85027l17.20003,5.9172,12.98874,4.44596Z" fill="%23b0dbea" stroke-width="0"/%3E%3Cpath d="m96.47827,44.56732c-.00067-.0108-.00549-.10791-.00989-.27209v.49615c.00708-.07379.01459-.14758.00989-.22406Z" fill="none" stroke-width="0"/%3E%3Cpath d="m154.30634,65.09119c.3075-.00421.61816-.00604.92975-.00702h-1.00415c.0238.00128.05182.00665.0744.00702Z" fill="none" stroke-width="0"/%3E%3Cpath d="m115.49664,65.26294c3.7135-.74225,6.41833-.75543,7.27844-.73346.75879-.15302,3.80713-1.50214,4.39526-1.90857.36786-.25543.96246-.47028,2.38763-.97681,2.26318-.80286,6.04944-2.14532,8.03943-3.67395,3.02869-2.32764,11.24426-2.55499,14.82135-2.39087v-2.58807c-30.22626,0-46.91541-23.68726-50.24347-28.9433-5.68298,8.39807-5.75269,18.2829-5.70831,20.19055.00012.00391.00012.00598.00024.01001l.00116-.00195v.04871c.00439.16418.00922.26129.00989.27209.0047.07648-.00281.15027-.00989.22406v1.46252c6.60834,10.5589,10.33264,19.86877,11.60651,23.32941,2.42841-1.9151,5.34241-3.90509,7.42175-4.32037Z" fill="none" stroke-width="0"/%3E%3Cpath d="m132.65265,8.35669c10.40503.30835,18.67029,3.9845,24.56561,10.92816,13.32343,15.69019,9.93256,42.32843,9.78168,43.45618-.01428.10895-.06281.20264-.09912.30164,3.02527.51666,5.72345,1.26544,8.10999,2.22583,2.9295-30.71533,13.64392-45.85205,22.27155-53.17957L132.03918,3.1828,62.6452,12.43805c8.8457,4.99109,16.0592,11.3692,21.73309,17.66266,3.46472,3.84235,6.51636,7.82147,9.19141,11.72217.24237-5.02301,1.72693-15.47211,9.44702-23.44989,6.79944-7.02747,16.76282-10.38971,29.63593-10.0163Z" fill="none" stroke-width="0"/%3E%3Cpath d="m133.47638,11.40063c-.08368-.01318-.14539-.05841-.22137-.08423-.23016-.0105-.45697-.02808-.68939-.03473-11.99207-.35455-21.22534,2.70929-27.42676,9.10553-.39752.40967-.76978.8299-1.13098,1.25439.17615.31549,16.2937,28.53033,48.41089,28.53033v-14.09778c0-.94934,1.03522-21.547-18.94238-24.67352Z" fill="none" stroke-width="0"/%3E%3Cpath d="m154.98254,21.17133c-1.96252-2.30884-4.22461-4.21466-6.77295-5.72064,8.00757,8.26025,7.52295,20.52759,7.51306,20.69946l.01544,26.00714c2.99548.00995,5.78503.17841,8.38086.48676-.00665-.09686-.03308-.19049-.0199-.29187.03534-.26318,3.36334-26.4939-9.11652-41.18085Z" fill="none" stroke-width="0"/%3E%3Cpath d="m183.75952,77.11957c-3.5838-9.8241-17.01001-12.02271-28.15991-12.0354h-.36353c-.31158.00098-.62225.00281-.92975.00702-.02258-.00037-.0506-.00574-.0744-.00702h-1.80408v-1.41315c-.00098-.01465-.00909-.02875-.00909-.04346v-5.13818c-2.9162-.14581-10.83899.11072-13.0
|
2023-09-05 02:40:48 +00:00
|
|
|
background-size: 100%;
|
|
|
|
|
text-indent: 100%;
|
|
|
|
|
white-space: nowrap;
|
|
|
|
|
overflow: hidden;
|
|
|
|
|
margin-right: 1.7rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
h1 a .name {
|
|
|
|
|
font-size: 2.5rem;
|
|
|
|
|
line-height: 1em;
|
|
|
|
|
text-indent: -.4em;
|
|
|
|
|
word-wrap: break-word;
|
|
|
|
|
font-weight: 700;
|
|
|
|
|
width: 50%;
|
|
|
|
|
}
|
|
|
|
|
|
2023-09-11 03:43:36 +00:00
|
|
|
#menuShowHide, label[for="menuShowHide"] {
|
|
|
|
|
position: absolute;
|
|
|
|
|
left: -9999em;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-13 18:30:31 +00:00
|
|
|
nav ul, .campsite_type_features ul {
|
2023-09-05 02:40:48 +00:00
|
|
|
list-style: none;
|
|
|
|
|
padding-left: 0;
|
|
|
|
|
display: flex;
|
2023-10-13 18:30:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
nav ul {
|
2023-09-05 02:40:48 +00:00
|
|
|
flex-wrap: wrap;
|
|
|
|
|
align-items: center;
|
|
|
|
|
}
|
|
|
|
|
|
2023-09-11 03:43:36 +00:00
|
|
|
nav a, nav button, label[for="menuShowHide"] {
|
2023-09-05 02:40:48 +00:00
|
|
|
font-size: 1.8rem;
|
|
|
|
|
font-weight: 500;
|
|
|
|
|
text-transform: uppercase;
|
|
|
|
|
padding: 0 2rem;
|
|
|
|
|
line-height: 6rem;
|
|
|
|
|
}
|
|
|
|
|
|
2023-09-11 03:13:57 +00:00
|
|
|
nav button {
|
|
|
|
|
cursor: pointer;
|
|
|
|
|
background: none;
|
|
|
|
|
border: none;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
nav .has-submenu {
|
|
|
|
|
position: relative;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
nav .has-submenu > a::after, nav .has-submenu > button::after {
|
2023-09-26 06:04:43 +00:00
|
|
|
content: "↓";
|
2023-09-11 03:13:57 +00:00
|
|
|
position: absolute;
|
|
|
|
|
right: -0.05rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
nav .has-submenu ul {
|
|
|
|
|
flex-direction: column;
|
|
|
|
|
align-items: start;
|
|
|
|
|
display: none;
|
|
|
|
|
position: absolute;
|
|
|
|
|
top: 5rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
nav .has-submenu ul a {
|
|
|
|
|
line-height: 4rem;
|
|
|
|
|
white-space: nowrap;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
nav .has-submenu:hover ul, nav .has-submenu:focus-within ul {
|
|
|
|
|
display: flex;
|
|
|
|
|
}
|
|
|
|
|
|
2023-09-11 03:43:36 +00:00
|
|
|
@media (max-width: 48rem) {
|
|
|
|
|
body > header {
|
|
|
|
|
display: grid;
|
|
|
|
|
grid-template-columns: 1fr 1fr;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
label[for="menuShowHide"] {
|
|
|
|
|
position: static;
|
|
|
|
|
cursor: pointer;
|
|
|
|
|
justify-self: end;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
label[for="menuShowHide"]::before {
|
|
|
|
|
content: "\2630";
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
nav {
|
|
|
|
|
display: none;
|
|
|
|
|
grid-column: 1 / span 2;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#menuShowHide:checked ~ nav {
|
|
|
|
|
display: block;
|
|
|
|
|
}
|
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
|
|
|
|
2023-09-11 03:43:36 +00:00
|
|
|
#menuShowHide:checked ~ label[for="menuShowHide"]::before {
|
|
|
|
|
content: "✕";
|
|
|
|
|
}
|
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
|
|
|
|
2023-09-11 03:43:36 +00:00
|
|
|
nav ul {
|
|
|
|
|
flex-direction: column;
|
|
|
|
|
align-items: start;
|
|
|
|
|
}
|
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
|
|
|
|
2023-09-11 03:43:36 +00:00
|
|
|
nav .has-submenu ul {
|
|
|
|
|
display: flex;
|
|
|
|
|
position: static;
|
|
|
|
|
padding-left: 2rem;
|
|
|
|
|
margin-top: -1rem;
|
|
|
|
|
background: none;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-09-05 02:40:48 +00:00
|
|
|
#content {
|
|
|
|
|
padding: 2.5rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.nature div, .nature section a {
|
|
|
|
|
background: var(--background-image) center center no-repeat;
|
|
|
|
|
background-size: cover;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.nature div, .services {
|
|
|
|
|
margin-bottom: 5rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.nature div:first-child, .nature section, .services {
|
|
|
|
|
border-radius: 5px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.nature div:first-child, .services {
|
|
|
|
|
min-height: 6rem;
|
|
|
|
|
display: flex;
|
|
|
|
|
align-items: flex-end;
|
2023-09-07 09:47:18 +00:00
|
|
|
gap: 5rem;
|
2023-09-05 02:40:48 +00:00
|
|
|
padding: 5rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.nature div:first-child {
|
|
|
|
|
justify-content: space-between;
|
|
|
|
|
}
|
|
|
|
|
|
Add the surroundings static page
This page is “highly stylized”, with a masonry-like grid, that i did not
know how to generate automatically from data defined in PostgreSQL,
therefore with Oriol we agreed to have this one as a static page and
we will see what we can do if the customer asks to be able to change
it.
I was a bit undecided on whether the icons in the bottom part of the
page should be defined in the CSS or with style="" and CSS variables,
like i do for the campsite type in the home page.
At first i thought that it should use CSS variables, mostly for
coherence: if another section of the web does it for its background
image, why no this one. The difference is that the home page is
dynamically created from the database, while this page is static and we
know what icons we need, thus it makes more sense to move it to the
stylesheet file, because then it will be downloaded by user agents that
actually want to use it (e.g., browsers, but not Braille terminals).
2023-09-16 22:11:39 +00:00
|
|
|
.nature h2, .nature div:first-child a, .services h2, .surroundings .spiel a {
|
2023-09-05 02:40:48 +00:00
|
|
|
font-weight: bold;
|
|
|
|
|
line-height: .9em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.nature h2, .nature div:first-child a {
|
|
|
|
|
border-radius: 5px;
|
|
|
|
|
background-color: var(--clar);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.nature h2 {
|
|
|
|
|
width: 50%;
|
|
|
|
|
min-height: 100%;
|
|
|
|
|
margin-bottom: 0;
|
|
|
|
|
font-size: calc(2rem + 4vw);
|
|
|
|
|
display: block;
|
|
|
|
|
padding: 3rem;
|
|
|
|
|
}
|
|
|
|
|
|
Add the surroundings static page
This page is “highly stylized”, with a masonry-like grid, that i did not
know how to generate automatically from data defined in PostgreSQL,
therefore with Oriol we agreed to have this one as a static page and
we will see what we can do if the customer asks to be able to change
it.
I was a bit undecided on whether the icons in the bottom part of the
page should be defined in the CSS or with style="" and CSS variables,
like i do for the campsite type in the home page.
At first i thought that it should use CSS variables, mostly for
coherence: if another section of the web does it for its background
image, why no this one. The difference is that the home page is
dynamically created from the database, while this page is static and we
know what icons we need, thus it makes more sense to move it to the
stylesheet file, because then it will be downloaded by user agents that
actually want to use it (e.g., browsers, but not Braille terminals).
2023-09-16 22:11:39 +00:00
|
|
|
.nature div:first-child a, .services h2, .surroundings .spiel a {
|
2023-09-05 02:40:48 +00:00
|
|
|
font-size: calc(1.8rem + 1.7vw);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.nature div:first-child a, .services a {
|
|
|
|
|
padding: 1.5rem 2rem;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-13 19:59:45 +00:00
|
|
|
.nature div:first-child a span, .services a span, .surroundings .spiel a:hover span, .campsite_type_booking form button span {
|
2023-09-05 02:40:48 +00:00
|
|
|
display: inline-block;
|
|
|
|
|
transition: transform 0.5s ease;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-13 19:59:45 +00:00
|
|
|
.nature div:first-child a:hover span, .services a:hover span, .spiel a:hover span, .campsite_type_booking form button:hover span {
|
2023-09-05 02:40:48 +00:00
|
|
|
transform: translateX(1.3rem);
|
|
|
|
|
}
|
|
|
|
|
|
Add the surroundings static page
This page is “highly stylized”, with a masonry-like grid, that i did not
know how to generate automatically from data defined in PostgreSQL,
therefore with Oriol we agreed to have this one as a static page and
we will see what we can do if the customer asks to be able to change
it.
I was a bit undecided on whether the icons in the bottom part of the
page should be defined in the CSS or with style="" and CSS variables,
like i do for the campsite type in the home page.
At first i thought that it should use CSS variables, mostly for
coherence: if another section of the web does it for its background
image, why no this one. The difference is that the home page is
dynamically created from the database, while this page is static and we
know what icons we need, thus it makes more sense to move it to the
stylesheet file, because then it will be downloaded by user agents that
actually want to use it (e.g., browsers, but not Braille terminals).
2023-09-16 22:11:39 +00:00
|
|
|
dl, .nature div + div, .outside_activities > div {
|
2023-09-05 02:40:48 +00:00
|
|
|
display: flex;
|
2023-09-07 09:47:18 +00:00
|
|
|
gap: 5rem;
|
2023-09-05 02:40:48 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.nature section {
|
|
|
|
|
flex: 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.nature section h3 {
|
|
|
|
|
font-size: 2.4rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.nature section a {
|
|
|
|
|
display: block;
|
|
|
|
|
width: 100%;
|
|
|
|
|
height: 20rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.nature section a span {
|
|
|
|
|
z-index: 2;
|
|
|
|
|
padding: 1rem 1.5rem;
|
|
|
|
|
background-color: var(--clar);
|
|
|
|
|
border-bottom-right-radius: 5px;
|
|
|
|
|
}
|
|
|
|
|
|
2023-09-12 10:47:50 +00:00
|
|
|
@media (max-width: 64rem) {
|
|
|
|
|
.nature div + div {
|
|
|
|
|
flex-direction: column;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@media (max-width: 48rem) {
|
|
|
|
|
.nature div:first-child {
|
|
|
|
|
flex-direction: column;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.nature h2 {
|
|
|
|
|
width: 100%;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-09-05 02:40:48 +00:00
|
|
|
.services {
|
|
|
|
|
justify-content: end;
|
|
|
|
|
background-color: var(--accent);
|
|
|
|
|
}
|
|
|
|
|
|
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
|
|
|
.carousel {
|
|
|
|
|
display: none;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.carousel .spiel {
|
2023-09-05 02:40:48 +00:00
|
|
|
font-size: 2.4rem;
|
|
|
|
|
padding-right: 4rem;
|
|
|
|
|
}
|
|
|
|
|
|
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
|
|
|
.carousel .spiel p {
|
|
|
|
|
margin-top: 0;
|
2023-09-05 02:40:48 +00:00
|
|
|
margin-bottom: 2rem;
|
|
|
|
|
}
|
|
|
|
|
|
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
|
|
|
.carousel figure, .carousel .slick-track > img {
|
2023-09-05 02:40:48 +00:00
|
|
|
margin-right: 5rem;
|
|
|
|
|
position: relative;
|
|
|
|
|
}
|
|
|
|
|
|
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
|
|
|
.carousel img {
|
2023-09-05 02:40:48 +00:00
|
|
|
height: 40rem;
|
|
|
|
|
width: 100%;
|
|
|
|
|
border-radius: 5px;
|
|
|
|
|
object-fit: cover;
|
|
|
|
|
}
|
|
|
|
|
|
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
|
|
|
.carousel figcaption {
|
2023-09-05 02:40:48 +00:00
|
|
|
padding: 10px 15px;
|
|
|
|
|
background: var(--clar);
|
|
|
|
|
width: fit-content;
|
|
|
|
|
float: right;
|
|
|
|
|
position: absolute;
|
|
|
|
|
bottom: 0;
|
|
|
|
|
right: 0;
|
|
|
|
|
border-top-left-radius: 5px;
|
|
|
|
|
font-size: 1.7rem;
|
|
|
|
|
}
|
|
|
|
|
|
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
|
|
|
.carousel .slick-list {
|
2023-09-05 02:40:48 +00:00
|
|
|
order: 1;
|
|
|
|
|
padding: 0 20% 0 0 !important;
|
|
|
|
|
}
|
|
|
|
|
|
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
|
|
|
.carousel .slick-track {
|
2023-09-05 02:40:48 +00:00
|
|
|
display: flex;
|
|
|
|
|
align-items: start;
|
|
|
|
|
}
|
|
|
|
|
|
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
|
|
|
.carousel.slick-slider {
|
2023-09-05 02:40:48 +00:00
|
|
|
display: flex;
|
|
|
|
|
flex-wrap: wrap;
|
|
|
|
|
justify-content: end;
|
|
|
|
|
}
|
|
|
|
|
|
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
|
|
|
.carousel .slick-arrow {
|
2023-09-05 02:40:48 +00:00
|
|
|
font-size: 6rem;
|
2023-09-07 09:47:18 +00:00
|
|
|
line-height: 1;
|
2023-09-05 02:40:48 +00:00
|
|
|
width: 5rem;
|
|
|
|
|
height: 5rem;
|
|
|
|
|
border: none !important;
|
|
|
|
|
background: none;
|
|
|
|
|
cursor: pointer;
|
|
|
|
|
transition: transform 0.5s ease;
|
|
|
|
|
}
|
|
|
|
|
|
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
|
|
|
.carousel .slick-prev.slick-arrow, .carousel .slick-next.slick-arrow {
|
2023-09-05 02:40:48 +00:00
|
|
|
opacity: 1;
|
|
|
|
|
}
|
|
|
|
|
|
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
|
|
|
.carousel .slick-prev {
|
2023-09-05 02:40:48 +00:00
|
|
|
order: 2;
|
2023-09-07 09:47:18 +00:00
|
|
|
margin: 2.5rem 4rem 0 0;
|
2023-09-05 02:40:48 +00:00
|
|
|
}
|
|
|
|
|
|
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
|
|
|
.carousel .slick-prev:hover {
|
2023-09-05 02:40:48 +00:00
|
|
|
transform: translateX(-1.3rem);
|
|
|
|
|
}
|
|
|
|
|
|
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
|
|
|
.carousel .slick-next {
|
2023-09-05 02:40:48 +00:00
|
|
|
order: 3;
|
2023-09-07 09:47:18 +00:00
|
|
|
margin: 2.5rem 7rem 0 0;
|
2023-09-05 02:40:48 +00:00
|
|
|
}
|
|
|
|
|
|
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
|
|
|
.carousel .slick-next:hover {
|
2023-09-05 02:40:48 +00:00
|
|
|
transform: translateX(1.3rem);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.enjoy {
|
|
|
|
|
font-weight: 900;
|
|
|
|
|
font-size: calc(1.8rem + 8vw);
|
|
|
|
|
line-height: 1.2em;
|
2023-09-07 09:47:18 +00:00
|
|
|
margin: 10rem 0;
|
2023-09-05 02:40:48 +00:00
|
|
|
}
|
|
|
|
|
|
Add the surroundings static page
This page is “highly stylized”, with a masonry-like grid, that i did not
know how to generate automatically from data defined in PostgreSQL,
therefore with Oriol we agreed to have this one as a static page and
we will see what we can do if the customer asks to be able to change
it.
I was a bit undecided on whether the icons in the bottom part of the
page should be defined in the CSS or with style="" and CSS variables,
like i do for the campsite type in the home page.
At first i thought that it should use CSS variables, mostly for
coherence: if another section of the web does it for its background
image, why no this one. The difference is that the home page is
dynamically created from the database, while this page is static and we
know what icons we need, thus it makes more sense to move it to the
stylesheet file, because then it will be downloaded by user agents that
actually want to use it (e.g., browsers, but not Braille terminals).
2023-09-16 22:11:39 +00:00
|
|
|
dl {
|
|
|
|
|
flex-wrap: wrap;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
dl div {
|
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
|
|
|
flex-basis: calc(25% - 5rem + 5rem / 4);
|
Add the surroundings static page
This page is “highly stylized”, with a masonry-like grid, that i did not
know how to generate automatically from data defined in PostgreSQL,
therefore with Oriol we agreed to have this one as a static page and
we will see what we can do if the customer asks to be able to change
it.
I was a bit undecided on whether the icons in the bottom part of the
page should be defined in the CSS or with style="" and CSS variables,
like i do for the campsite type in the home page.
At first i thought that it should use CSS variables, mostly for
coherence: if another section of the web does it for its background
image, why no this one. The difference is that the home page is
dynamically created from the database, while this page is static and we
know what icons we need, thus it makes more sense to move it to the
stylesheet file, because then it will be downloaded by user agents that
actually want to use it (e.g., browsers, but not Braille terminals).
2023-09-16 22:11:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
dt {
|
|
|
|
|
font-size: 2rem;
|
|
|
|
|
font-weight: 600;
|
|
|
|
|
padding: 5rem 0 .5rem;
|
|
|
|
|
margin-bottom: 2rem;
|
|
|
|
|
border-bottom: 1px solid black;
|
|
|
|
|
background-size: 2em 2em;
|
|
|
|
|
background-repeat: no-repeat;
|
|
|
|
|
background-position: top left;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@media (max-width: 48rem) {
|
|
|
|
|
dl {
|
|
|
|
|
flex-direction: column;
|
|
|
|
|
}
|
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
|
|
|
|
|
|
|
|
del div {
|
|
|
|
|
flex-basis: 100%;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Add the surroundings static page
This page is “highly stylized”, with a masonry-like grid, that i did not
know how to generate automatically from data defined in PostgreSQL,
therefore with Oriol we agreed to have this one as a static page and
we will see what we can do if the customer asks to be able to change
it.
I was a bit undecided on whether the icons in the bottom part of the
page should be defined in the CSS or with style="" and CSS variables,
like i do for the campsite type in the home page.
At first i thought that it should use CSS variables, mostly for
coherence: if another section of the web does it for its background
image, why no this one. The difference is that the home page is
dynamically created from the database, while this page is static and we
know what icons we need, thus it makes more sense to move it to the
stylesheet file, because then it will be downloaded by user agents that
actually want to use it (e.g., browsers, but not Braille terminals).
2023-09-16 22:11:39 +00:00
|
|
|
.outside_activities {
|
|
|
|
|
margin-top: 2rem;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-12 16:47:08 +00:00
|
|
|
.outside_activities h3, .campsite_services .spiel {
|
Add the surroundings static page
This page is “highly stylized”, with a masonry-like grid, that i did not
know how to generate automatically from data defined in PostgreSQL,
therefore with Oriol we agreed to have this one as a static page and
we will see what we can do if the customer asks to be able to change
it.
I was a bit undecided on whether the icons in the bottom part of the
page should be defined in the CSS or with style="" and CSS variables,
like i do for the campsite type in the home page.
At first i thought that it should use CSS variables, mostly for
coherence: if another section of the web does it for its background
image, why no this one. The difference is that the home page is
dynamically created from the database, while this page is static and we
know what icons we need, thus it makes more sense to move it to the
stylesheet file, because then it will be downloaded by user agents that
actually want to use it (e.g., browsers, but not Braille terminals).
2023-09-16 22:11:39 +00:00
|
|
|
font-size: calc(2.2rem + 4vw);
|
|
|
|
|
font-weight: 600;
|
|
|
|
|
line-height: .9em;
|
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.outside_activities h3 {
|
Add the surroundings static page
This page is “highly stylized”, with a masonry-like grid, that i did not
know how to generate automatically from data defined in PostgreSQL,
therefore with Oriol we agreed to have this one as a static page and
we will see what we can do if the customer asks to be able to change
it.
I was a bit undecided on whether the icons in the bottom part of the
page should be defined in the CSS or with style="" and CSS variables,
like i do for the campsite type in the home page.
At first i thought that it should use CSS variables, mostly for
coherence: if another section of the web does it for its background
image, why no this one. The difference is that the home page is
dynamically created from the database, while this page is static and we
know what icons we need, thus it makes more sense to move it to the
stylesheet file, because then it will be downloaded by user agents that
actually want to use it (e.g., browsers, but not Braille terminals).
2023-09-16 22:11:39 +00:00
|
|
|
margin-bottom: 10rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.outside_activities > div {
|
|
|
|
|
align-items: start;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.outside_activities > div:first-of-type {
|
|
|
|
|
margin-bottom: 5rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.outside_activities > div:first-of-type p {
|
|
|
|
|
width: 25%;
|
|
|
|
|
padding-top: 12rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.outside_activities > div:first-of-type img {
|
|
|
|
|
width: 40%;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.outside_activities > div:first-of-type img:last-child {
|
|
|
|
|
width: 35%;
|
|
|
|
|
padding-top: 22rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.outside_activities > div:nth-of-type(2) > img {
|
|
|
|
|
width: 35%;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.outside_activities > div:nth-of-type(2) > div {
|
|
|
|
|
width: 30%;
|
|
|
|
|
padding-top: 10rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.outside_activities > div:nth-of-type(2) > div img {
|
|
|
|
|
margin-top: 20rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.outside_activities > div:nth-of-type(2) > img:last-child {
|
|
|
|
|
padding-top: 22rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.outside_activities > div:last-child img {
|
|
|
|
|
width: 40%;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.outside_activities > div:last-child img:first-child {
|
|
|
|
|
margin-top: 10rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.outside_activities > div:last-child img:nth-child(2) {
|
|
|
|
|
margin-top: 22rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.outside_activities > div:last-child div {
|
|
|
|
|
width: 20%;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.campsite_activities {
|
|
|
|
|
margin-top: 10rem;
|
|
|
|
|
padding-top: 10rem;
|
|
|
|
|
border-top: 1px solid black;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.campsite_activities h3 {
|
|
|
|
|
font-size: 2.9rem;
|
|
|
|
|
font-weight: 400;
|
|
|
|
|
line-height: 1.2;
|
|
|
|
|
margin-bottom: 5rem;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-12 16:47:08 +00:00
|
|
|
.campsite_services.carousel .slick-track {
|
Add the services page
This page is more or less similar to home, in terms of database: it
has a carousel and a list of items; in this case, the definition of
campsite services.
As i said early, when adding the home carousel, this carousel has its
own relation and set of functions to manage slides. They are also
duplicated in Go code, but i think i will need to refactor it later to
a carousel package or something like that, because both relations have
the exact same fields and types, so it makes no sense to have twice the
same code.
I already did it with the CSS and JavaScript code, mostly because it was
easier to replace the `.surroundings div` selector with `.carousel`, and
because that way i can have a single template that loads and initializes
Slick.
There is no UI to create or edit service definitions, although there are
the SQL functions, because i have no more time now, and Oriol needs to
check that the style is correct for that page.
2023-09-17 01:42:16 +00:00
|
|
|
align-items: center;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-13 19:59:45 +00:00
|
|
|
.campsite_type.carousel .spiel {
|
|
|
|
|
min-width: calc((100vw - 5rem/* main margin */ - 5rem/* booking gap */) * .40111/* flex: .4 of form */ + 5rem /* booking gap again */);
|
|
|
|
|
flex-shrink: 0;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-13 20:10:44 +00:00
|
|
|
.campsite_type.carousel .spiel h3 {
|
|
|
|
|
font-size: calc(1.8rem + 1.7vw);
|
|
|
|
|
font-weight: 700;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.campsite_type_title {
|
|
|
|
|
font-size: 3.6rem;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-13 19:59:45 +00:00
|
|
|
.campsite_type_booking {
|
|
|
|
|
margin-top: 2.5rem;
|
|
|
|
|
display: flex;
|
|
|
|
|
gap: 5rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@media (max-width: 48rem) {
|
|
|
|
|
.campsite_type_booking {
|
|
|
|
|
flex-direction: column;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.campsite_type_booking form {
|
|
|
|
|
flex: .4;
|
|
|
|
|
background-color: var(--accent);
|
|
|
|
|
padding: 2rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.campsite_type_booking form fieldset {
|
|
|
|
|
display: flex;
|
|
|
|
|
gap: 2.5rem;
|
|
|
|
|
padding: 0;
|
|
|
|
|
border: none;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.campsite_type_booking form label {
|
|
|
|
|
flex: 1;
|
|
|
|
|
font-size: 2rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.campsite_type_booking form input {
|
|
|
|
|
padding: 1.5rem .5rem;
|
|
|
|
|
width: 100%;
|
|
|
|
|
background-color: var(--base);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.campsite_type_booking form footer {
|
|
|
|
|
margin-top: 2rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.campsite_type_booking form button {
|
|
|
|
|
width: 100%;
|
|
|
|
|
text-align: left;
|
|
|
|
|
background-color: var(--clar);
|
|
|
|
|
padding: 1.5rem 2rem;
|
|
|
|
|
cursor: pointer;
|
|
|
|
|
font-size: calc(1.8rem + .8vw);
|
|
|
|
|
font-weight: 600;
|
|
|
|
|
line-height: 0.9em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.campsite_type_booking form,
|
|
|
|
|
.campsite_type_booking form button,
|
|
|
|
|
.campsite_type_booking form input {
|
|
|
|
|
border: none;
|
|
|
|
|
border-radius: 5px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.campsite_type_prices {
|
|
|
|
|
flex: .6;
|
|
|
|
|
padding: 2.5rem;
|
|
|
|
|
border-radius: 5px;
|
|
|
|
|
border: 3px solid black;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.campsite_type_prices dl {
|
|
|
|
|
display: flex;
|
|
|
|
|
justify-content: space-between;
|
|
|
|
|
gap: 2.5rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.campsite_type_prices div {
|
|
|
|
|
flex-basis: unset;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.campsite_type_prices dt {
|
|
|
|
|
display: flex;
|
|
|
|
|
align-items: center;
|
|
|
|
|
gap: .5rem;
|
|
|
|
|
border: none;
|
|
|
|
|
padding: 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.campsite_type_calendar {
|
|
|
|
|
padding: 5rem 0 2.5rem;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-13 18:30:31 +00:00
|
|
|
.campsite_type_features li {
|
|
|
|
|
flex: 1;
|
|
|
|
|
font-size: 2.4rem;
|
|
|
|
|
text-align: center;
|
|
|
|
|
justify-content: space-between;
|
|
|
|
|
background-repeat: no-repeat;
|
|
|
|
|
background-position: top center;
|
|
|
|
|
background-size: 7.2rem 7.2rem;
|
|
|
|
|
padding-top: 7.2rem;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-13 19:59:45 +00:00
|
|
|
.campsite_type_features ul {
|
|
|
|
|
gap: 2.5rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.campsite_type_detail {
|
|
|
|
|
display: flex;
|
|
|
|
|
gap: 5rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.campsite_type_detail section {
|
|
|
|
|
flex: 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.campsite_type_detail section:last-child {
|
|
|
|
|
flex: 2;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.campsite_type_detail h4 {
|
|
|
|
|
font-size: 2.4rem;
|
|
|
|
|
font-weight: 400;
|
|
|
|
|
margin-bottom: 1.5rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.campsite_type_detail ul + h4 {
|
|
|
|
|
margin-top: 2.5rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@media (max-width: 64rem) {
|
|
|
|
|
.campsite_type_features ul, .campsite_type_detail {
|
|
|
|
|
flex-wrap: wrap;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.campsite_type_features li {
|
|
|
|
|
flex: unset;
|
|
|
|
|
width: calc((100% - 2.5rem * 2) / 3);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.campsite_type_detail section {
|
|
|
|
|
flex: unset;
|
|
|
|
|
width: calc((100% - 5rem) / 2);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.campsite_type_detail section:last-child {
|
|
|
|
|
width: 100%;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@media (max-width: 48rem) {
|
|
|
|
|
.campsite_type_features ul, .campsite_type_detail {
|
|
|
|
|
flex-wrap: nowrap;
|
|
|
|
|
flex-direction: column;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.campsite_type_features li, .campsite_type_detail section {
|
|
|
|
|
width: 100%;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
body > footer {
|
2023-10-06 20:02:59 +00:00
|
|
|
display: flex;
|
|
|
|
|
flex-direction: column;
|
|
|
|
|
gap: 1rem;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-13 19:59:45 +00:00
|
|
|
body > footer div, .campsite_type_features, .campsite_type_detail {
|
2023-10-13 18:30:31 +00:00
|
|
|
padding: 5rem 0;
|
|
|
|
|
border-top: 3px solid black;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-13 19:59:45 +00:00
|
|
|
.campsite_type_detail {
|
|
|
|
|
padding-bottom: 2.5rem;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
body > footer div {
|
2023-10-06 20:02:59 +00:00
|
|
|
display: flex;
|
|
|
|
|
justify-content: space-between;
|
|
|
|
|
margin: 0 2.5rem;
|
|
|
|
|
border-bottom: 3px solid black;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-13 19:59:45 +00:00
|
|
|
body > footer section {
|
2023-10-06 20:02:59 +00:00
|
|
|
width: 25%;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-13 19:59:45 +00:00
|
|
|
body > footer h2 {
|
2023-10-06 20:02:59 +00:00
|
|
|
font-size: 2.4rem;
|
|
|
|
|
margin-bottom: 2rem;
|
|
|
|
|
border-bottom: 1px solid black;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-13 19:59:45 +00:00
|
|
|
body > footer ul {
|
2023-10-06 20:02:59 +00:00
|
|
|
list-style: none;
|
|
|
|
|
padding: 0;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-13 19:59:45 +00:00
|
|
|
body > footer li a::before {
|
2023-10-06 20:02:59 +00:00
|
|
|
font-size: 1.25em;
|
|
|
|
|
content: "→";
|
|
|
|
|
display: inline-block;
|
|
|
|
|
margin-right: .5em;
|
|
|
|
|
transition: transform .5s ease;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-13 19:59:45 +00:00
|
|
|
body > footer li a:hover::before {
|
2023-10-06 20:02:59 +00:00
|
|
|
transform: translateX(.6rem);
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-13 19:59:45 +00:00
|
|
|
body > footer span {
|
2023-09-05 02:40:48 +00:00
|
|
|
font-size: 1.5rem;
|
|
|
|
|
text-align: center;
|
|
|
|
|
padding: 2.5rem;
|
2023-10-06 20:02:59 +00:00
|
|
|
display: block;
|
2023-09-05 02:40:48 +00:00
|
|
|
}
|
