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 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;
|
|
|
|
}
|
|
|
|
|
|
|
|
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 {
|
|
|
|
width: 5rem;
|
|
|
|
height: 4.33rem;
|
|
|
|
background: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 98.72705 85.5'%3E%3Cpath d='m49.36377,0L0,85.5h98.72705L49.36377,0Zm18.61945,46.25l18.61945,32.25h-37.23914l18.61969-32.25Z' fill='%23303234'/%3E%3C/svg%3E") top left no-repeat;
|
|
|
|
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-09-05 02:40:48 +00:00
|
|
|
nav ul {
|
|
|
|
list-style: none;
|
|
|
|
padding-left: 0;
|
|
|
|
display: flex;
|
|
|
|
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 {
|
|
|
|
content: " ⌄";
|
|
|
|
position: absolute;
|
|
|
|
top: -.5rem;
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
#menuShowHide:checked ~ label[for="menuShowHide"]::before {
|
|
|
|
content: "✕";
|
|
|
|
}
|
|
|
|
|
|
|
|
nav ul {
|
|
|
|
flex-direction: column;
|
|
|
|
align-items: start;
|
|
|
|
}
|
|
|
|
|
|
|
|
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-09-11 02:20:21 +00:00
|
|
|
.nature div:first-child a span, .services a span, .surroundings .spiel a:hover span {
|
2023-09-05 02:40:48 +00:00
|
|
|
display: inline-block;
|
|
|
|
transition: transform 0.5s ease;
|
|
|
|
}
|
|
|
|
|
|
|
|
.nature div:first-child a:hover span, .services a:hover span, .spiel a:hover span {
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
2023-09-11 02:20:21 +00:00
|
|
|
.surroundings .spiel {
|
2023-09-05 02:40:48 +00:00
|
|
|
font-size: 2.4rem;
|
|
|
|
padding-right: 4rem;
|
|
|
|
}
|
|
|
|
|
2023-09-11 02:20:21 +00:00
|
|
|
.surroundings .spiel p {
|
2023-09-05 02:40:48 +00:00
|
|
|
margin-bottom: 2rem;
|
|
|
|
}
|
|
|
|
|
Make home page’s carousel manageable via the database
I debated with myself whether to create the home_carousel relation or
rather if it would be better to have a single carousel relation for all
pages. However, i thought that it would be actually harder to maintain
a single relation because i would need an additional column to tell one
carrousel from another, and what would that column be? An enum? A
foreign key to another relation? home_carousel carries no such issues.
I was starting to duplicate logic all over the packages, such as the
way to encode media paths or “localization” (l10n) input fields.
Therefore, i refactorized them.
In the case of media path, i added a function that accepts rows of
media, because always need the same columns from the row, and it was
yet another repetition if i needed to pass them all the time. Plus,
these kind of functions can be called as `table.function`, that make
them look like columns from the table; if PostgreSQL implemented virtual
generated columns, i would have used that instead.
I am not sure whether that media_path function can be immutable. An
immutable function is “guaranteed to return the same results given the
same arguments forever”, which would be true if the inputs where the
hash and the original_filename columns, instead of the whole rows, but
i left it as static because i did not know whether PostgreSQL interprets
the “same row but with different values” as a different input. That is,
whether PostgreSQL’s concept of row is the actual tuple or the space
that has a rowid, irrespective of contents; in the latter case, the
function can not be immutable. Just to be in the safe side, i left it
stable.
The home page was starting to grow a bit too much inside the app
package, new that it has its own admin handler, and moved it all to a
separate package.
2023-09-14 23:05:38 +00:00
|
|
|
.surroundings figure, .surroundings .slick-track > img {
|
2023-09-05 02:40:48 +00:00
|
|
|
margin-right: 5rem;
|
|
|
|
position: relative;
|
|
|
|
}
|
|
|
|
|
Make home page’s carousel manageable via the database
I debated with myself whether to create the home_carousel relation or
rather if it would be better to have a single carousel relation for all
pages. However, i thought that it would be actually harder to maintain
a single relation because i would need an additional column to tell one
carrousel from another, and what would that column be? An enum? A
foreign key to another relation? home_carousel carries no such issues.
I was starting to duplicate logic all over the packages, such as the
way to encode media paths or “localization” (l10n) input fields.
Therefore, i refactorized them.
In the case of media path, i added a function that accepts rows of
media, because always need the same columns from the row, and it was
yet another repetition if i needed to pass them all the time. Plus,
these kind of functions can be called as `table.function`, that make
them look like columns from the table; if PostgreSQL implemented virtual
generated columns, i would have used that instead.
I am not sure whether that media_path function can be immutable. An
immutable function is “guaranteed to return the same results given the
same arguments forever”, which would be true if the inputs where the
hash and the original_filename columns, instead of the whole rows, but
i left it as static because i did not know whether PostgreSQL interprets
the “same row but with different values” as a different input. That is,
whether PostgreSQL’s concept of row is the actual tuple or the space
that has a rowid, irrespective of contents; in the latter case, the
function can not be immutable. Just to be in the safe side, i left it
stable.
The home page was starting to grow a bit too much inside the app
package, new that it has its own admin handler, and moved it all to a
separate package.
2023-09-14 23:05:38 +00:00
|
|
|
.surroundings img {
|
2023-09-05 02:40:48 +00:00
|
|
|
height: 40rem;
|
|
|
|
width: 100%;
|
|
|
|
border-radius: 5px;
|
|
|
|
object-fit: cover;
|
|
|
|
}
|
|
|
|
|
2023-09-11 02:20:21 +00:00
|
|
|
.surroundings 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;
|
|
|
|
}
|
|
|
|
|
2023-09-11 02:20:21 +00:00
|
|
|
.surroundings .slick-list {
|
2023-09-05 02:40:48 +00:00
|
|
|
order: 1;
|
|
|
|
padding: 0 20% 0 0 !important;
|
|
|
|
}
|
|
|
|
|
2023-09-11 02:20:21 +00:00
|
|
|
.surroundings .slick-track {
|
2023-09-05 02:40:48 +00:00
|
|
|
display: flex;
|
|
|
|
align-items: start;
|
|
|
|
}
|
|
|
|
|
2023-09-11 02:20:21 +00:00
|
|
|
.surroundings .slick-slider {
|
2023-09-05 02:40:48 +00:00
|
|
|
display: flex;
|
|
|
|
flex-wrap: wrap;
|
|
|
|
justify-content: end;
|
|
|
|
}
|
|
|
|
|
2023-09-11 02:20:21 +00:00
|
|
|
.surroundings .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;
|
|
|
|
}
|
|
|
|
|
2023-09-11 02:20:21 +00:00
|
|
|
.surroundings .slick-prev.slick-arrow, .surroundings .slick-next.slick-arrow {
|
2023-09-05 02:40:48 +00:00
|
|
|
opacity: 1;
|
|
|
|
}
|
|
|
|
|
2023-09-11 02:20:21 +00:00
|
|
|
.surroundings .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
|
|
|
}
|
|
|
|
|
2023-09-11 02:20:21 +00:00
|
|
|
.surroundings .slick-prev:hover {
|
2023-09-05 02:40:48 +00:00
|
|
|
transform: translateX(-1.3rem);
|
|
|
|
}
|
|
|
|
|
2023-09-11 02:20:21 +00:00
|
|
|
.surroundings .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
|
|
|
}
|
|
|
|
|
2023-09-11 02:20:21 +00:00
|
|
|
.surroundings .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 {
|
|
|
|
flex: 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
.icon_bicycle {
|
|
|
|
background-image: url('data:image/svg+xml,%3Csvg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 256 256" fill="%23000000" height="32" width="32"%3E%3Cpath d="M208,116a43.66,43.66,0,0,0-18.62,4.15L159,68h33a12,12,0,0,1,12,12,4,4,0,0,0,8,0,20,20,0,0,0-20-20H152a4,4,0,0,0-3.46,6L163.7,92H97L79.46,62A4,4,0,0,0,76,60H48a4,4,0,0,0,0,8H73.7L89.89,95.76,70.57,122.25A44.21,44.21,0,1,0,77,127L94.29,103.3,128.54,162a4,4,0,0,0,3.46,2,4.11,4.11,0,0,0,2-.54,4,4,0,0,0,1.44-5.48l-33.83-58h66.74l14.11,24.19A44,44,0,1,0,208,116ZM84,160a36,36,0,1,1-18.16-31.25L44.77,157.64a4,4,0,0,0,6.46,4.72l21.07-28.9A35.92,35.92,0,0,1,84,160Zm124,36a36,36,0,0,1-21.47-64.88l18,30.9a4,4,0,0,0,3.46,2,4.11,4.11,0,0,0,2-.54,4,4,0,0,0,1.44-5.48l-18-30.89A36,36,0,1,1,208,196Z"/%3E%3C/svg%3E');
|
|
|
|
}
|
|
|
|
|
|
|
|
.icon_route {
|
|
|
|
background-image: url('data:image/svg+xml,%3Csvg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 256 256" fill="%23000000" height="32" width="32"%3E%3Cpath d="M226.46,52.85a4,4,0,0,0-3.43-.73L160.47,67.76,97.79,36.42a4,4,0,0,0-2.76-.3l-64,16A4,4,0,0,0,28,56V200a4,4,0,0,0,5,3.88l62.56-15.64,62.68,31.34a4,4,0,0,0,2.76.3l64-16a4,4,0,0,0,3-3.88V56A4,4,0,0,0,226.46,52.85ZM100,46.47l56,28V209.53l-56-28ZM36,59.12l56-14V180.88l-56,14ZM220,196.88l-56,14V75.12l56-14Z"/%3E%3C/svg%3E');
|
|
|
|
}
|
|
|
|
|
|
|
|
.icon_outing {
|
|
|
|
background-image: url('data:image/svg+xml,%3Csvg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 256 256" fill="%23000000" height="32" width="32"%3E%3Cpath d="M164,44.17V32a20,20,0,0,0-20-20H112A20,20,0,0,0,92,32V44.17A52.05,52.05,0,0,0,44,96V216a12,12,0,0,0,12,12H200a12,12,0,0,0,12-12V96A52.05,52.05,0,0,0,164,44.17ZM112,20h32a12,12,0,0,1,12,12V44H100V32A12,12,0,0,1,112,20Zm60,144H84V152a12,12,0,0,1,12-12h64a12,12,0,0,1,12,12Zm-88,8h56v12a4,4,0,0,0,8,0V172h24v48H84Zm120,44a4,4,0,0,1-4,4H180V152a20,20,0,0,0-20-20H96a20,20,0,0,0-20,20v68H56a4,4,0,0,1-4-4V96A44.05,44.05,0,0,1,96,52h64a44.05,44.05,0,0,1,44,44ZM148,88a4,4,0,0,1-4,4H112a4,4,0,0,1,0-8h32A4,4,0,0,1,148,88Z"/%3E%3C/svg%3E');
|
|
|
|
}
|
|
|
|
|
|
|
|
.icon_kayak {
|
|
|
|
background-image: url('data:image/svg+xml,%3Csvg viewBox="0 0 29.52905 28.08545" xmlns="http://www.w3.org/2000/svg" id="uuid-87ec619a-4896-40b8-8478-aa076dee3f7c"%3E%3Cpath stroke-width="0" d="m29.46728,11.26074l-.57617-2.15186c-.08398-.31299-.24609-.59229-.45801-.78613-.26758-.24658-.59863-.3418-.90625-.25879l-3.4834.93213c-.26953.07227-.48535.26807-.6084.54932l-.5752,1.30713c-.0719.16376-.10333.34686-.10742.53485l-3.05627.81787c-.23956-3.37067-1.03204-8.79126-2.35193-10.66425l-.22363-.31836C16.58057.45752,15.69971.00049,14.76318,0h-.00049c-.94873,0-1.80566.44434-2.35156,1.21875-1.71973,2.44043-2.65771,9.75146-2.65771,12.82422,0,.24457.00812.52399.0199.81769l-3.25604.87134c-.09741-.16071-.21613-.30347-.36005-.40924l-1.15088-.84424c-.24854-.18213-.53125-.24463-.80127-.17236l-3.48389.93164c-.56689.15234-.85693.84961-.65918,1.58691l.57617,2.15137c.0835.31348.24561.59277.45654.78613.20508.18848.4458.28809.68506.28809.07471,0,.14893-.00879.22168-.02832l3.48486-.93359c.26807-.07227.48389-.26758.60693-.54883l.57568-1.30664c.07172-.16357.10309-.3465.10718-.5343l3.05591-.81793c.25531,3.52673,1.14368,8.94983,2.5791,10.98602.5459.77441,1.40332,1.21875,2.35205,1.21875.93652,0,1.81738-.45703,2.35645-1.22266l.22461-.31738c1.60352-2.27637,2.43066-9.79492,2.43066-12.50244,0-.23499-.00854-.51709-.021-.81805l3.25732-.87183c.09747.16071.21625.30347.36035.40912l1.15039.84473c.18066.13281.38086.20166.5791.20166.07422,0,.14941-.00977.22168-.0293l3.48535-.93262c.56641-.15234.85645-.84863.65918-1.58594Zm-24.24072,6.86182l-3.41602.93262c-.03516-.01465-.14844-.12109-.20654-.33691l-.57617-2.15137c-.05713-.21484-.01318-.3623-.04688-.3623h-.00098l3.4165-.93164s.00586.00293.01709.01074c.00049,0,.00098.00098.00098.00098l1.00842.74017-1.90881.5108c-.2666.07227-.4248.3457-.35352.6123.05957.22363.26172.37109.48242.37109.04297,0,.08643-.00586.12988-.0166l1.91559-.5127-.46198,1.13281Zm5.52686-4.07959c0-3.07959.93994-10.06934,2.4751-12.24805.35596-.50488.91504-.79492,1.53418-.79492.62109.00049,1.18213.2915,1.54053.79932l.22266.31689c1.17902,1.67261,1.96533,7.08936,2.18457,10.35278l-1.50305.40228c-.19397-2.55505-1.02423-4.83514-2.44324-4.83514-1.63379,0-2.48828,3.02197-2.48828,6.00684,0,.04913.00214.09814.00262.14728l-1.51538.40552c-.00574-.19403-.0097-.38147-.0097-.5528Zm2.52692-.12079c.02441-2.93951.89984-4.88605,1.48383-4.88605.53003,0,1.29828,1.6062,1.45496,4.09961l-2.93878.78644Zm2.96765.24115c-.02441,2.93933-.89978,4.88599-1.48383,4.88599-.53003,0-1.29834-1.60632-1.45496-4.09937l2.93878-.78662Zm2.52692-.12036c0,2.66846-.84961,9.94092-2.24902,11.92725l-.22363.31641c-.71387,1.01367-2.36084,1.01562-3.07373.00391-1.31152-1.86127-2.18622-7.22681-2.414-10.67285l1.50641-.4032c.19397,2.55505,1.02417,4.83484,2.44324,4.83484,1.63379,0,2.48828-3.02148,2.48828-6.00635,0-.04926-.00214-.09845-.00262-.14777l1.51514-.40558c.00659.20087.00995.38617.00995.55334Zm6.35742-1.23047s-.00684-.00293-.01855-.01123l-1.00897-.74091,1.90936-.51105c.26758-.07129.42578-.34521.35449-.6123-.07227-.26562-.3418-.42725-.6123-.35352l-1.91577.5127.46069-1.13379,3.41699-.93164c.03516.01416.14844.12012.20605.33691l.57617,2.15186c.05957.21973.01953.36816.04883.36133l-3.41699.93164Z"/%3E%3C/svg%3E');
|
|
|
|
}
|
|
|
|
|
|
|
|
.outside_activities {
|
|
|
|
margin-top: 2rem;
|
|
|
|
}
|
|
|
|
|
|
|
|
.outside_activities h3 {
|
|
|
|
font-size: calc(2.2rem + 4vw);
|
|
|
|
font-weight: 600;
|
|
|
|
line-height: .9em;
|
|
|
|
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%;
|
|
|
|
}
|
|
|
|
|
|
|
|
.outside_activities > div:last-child p {
|
|
|
|
margin-bottom: 1.5em;
|
|
|
|
}
|
|
|
|
|
|
|
|
.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-09-05 02:40:48 +00:00
|
|
|
footer {
|
|
|
|
font-size: 1.5rem;
|
|
|
|
text-align: center;
|
|
|
|
padding: 2.5rem;
|
|
|
|
}
|