Update docs/community/events/ambassadors_celebration_meeting_and_dinner.md, docs/community/events/images/ambass-celebration-2023-img-st-annes-coffee.png, docs/community/events/images/ambass-celebration-2023-img-amb-dinner.png

Hi there!

Thank you for the great theme! I am a happy user and was delighted to see that mermaid support has landed.

In some cases the usage of jsDelivr might not be possible for technical or compliance reasons.

This commit adds a second way to include the mermaid lib by specifying a path in the mermaid config. This way a local version of the lib can be used.

It should be fully backwards compatible, not requiring any action by users that already include the lib from the CDN.

I already added some documentation, but I am also happy to extend this, if this change is generally well-received.

Cheers,
Christian

In #1058, I noted:

> Tangentially related work:
> ...
> - better annotate new features (motivated by writing these docs)
>     - we should add "New" to new features :) 
>     - we should note when a feature was introduced (I think this is a core part of most software documentation)
>     - we should annotate things that are "Advanced" in so far as the average Just the Docs user will not use them / they require significant Jekyll knowledge
> 

This came up again in https://github.com/just-the-docs/just-the-docs/discussions/1136#discussioncomment-4716253, so I think it's best for us to resolve this sooner rather than later.

This PR is me doing that. I:

- have added a headings-level "New" label to every new heading introduced since `v0.3`
- added, when possible, inline YAML comments when new configuration options have been introduced

I did this by scanning through the CHANGELOG and selecting each feature that is either tagged with `Add` and has documentation.

I may have also missed any new features, so some double-checking would be helpful!

This is an alternative PR that resolves #1011. Unlike #1013, this PR defines a *new* SASS file, `_sass/custom/setup.scss`, specifically designed for new custom variables (and other SASS-only constructs). It's imported after our `support` SASS files are (functions, variables), but otherwise is imported before all other files (ex, when CSS is emitted).

So, custom callout colors can now be defined in this file. I also move the custom callout colors present in `custom.scss` to the right location.

I've added some docs that briefly explain how to use the feature. Feedback is welcome!

---

As an aside, I chose not to add a `_includes/css` file that imports this, and then import that file. I think that's only necessary if we're trying to render liquid somehow in the SASS file; since we're not trying to do that for `setup.scss`, I've opted to not include it. If we think this is relevant, I can re-add it.

Co-authored-by: Peter Mosses <18308236+pdmosses@users.noreply.github.com>

This is a prototype for review and discussion. My use and testing of this PR is on top of 6d9d4135. The changes are trival to rebase to `main` and I'm happy to do so if this prototype moves forward.


* Feature request details in linked issue, fixes just-the-docs/just-the-docs#1067
* I welcome feedback and all discussion
* A draft doc site of mine using this PR is at https://docs.hidale.com/

To use the prototype, the two include files need to be customized. Here are mine from the draft website https://github.com/diablodale/dp.docs/commit/9c0d836408af2e72dbce115a01ce6627137e66dd



Co-authored-by: Matt Wang <matt@matthewwang.me>

In touching up the migration guide, I noticed that many of our documentation site links are broken! For example, on the homepage, this link:

<img width="782" alt="screenshot of homepage; code snippet is in next block" src="https://user-images.githubusercontent.com/14893287/210462690-31aa7bf5-dd79-4e8f-a3c5-1213e73771c4.png">

which has the following href

```code
<a href="/just-the-docs/just-the-docs/CHANGELOG/">the CHANGELOG</a>
```

duplicates the `baseurl` twice. There are 14 such broken links across the site. Each link duplicates the `baseurl` and `link` tags, which has since been resolved with links being relative by default (there's a set of PRs that document this - I can't find the exact paper trail right now).

To resolve this, I:

- find and replace site-wide `{{ site.baseurl }}{% link` with `{% link`
- tested each link, which now works properly locally *and* on the deploy preview

I'm surprised we didn't catch this earlier! I also could be missing something else, in which case feedback on this PR is certainly welcome.

The typography utilities page has been moved sopme time ago, but the button URL was not updated. This commit fixes the broken link.

Hi everyone, this is a large refactoring PR that looks to **modularize site components** following the discussion in #959. At the top-level, it:

- moves icons, the sidebar, header (navbar, search, aux links), footer, and mermaid components of the `default` layout into their own `_includes`
- creates a new `minimal` layout that does not render the header or sidebar as a proof-of-concept for the composability of components
- documents all existing and new layouts (including vendor code) in the "Customization" section 

An important goal of this PR is for it to be **just code motion and flexibility**: there should be **zero impact** on the average end user that only consumes the `default` theme.

The next few sections go in-depth on each of the listed changes.

### new components

The `default` layout contains a "list" of all relevant components. Importantly, some of these components have sub-components:

- the header is split into the search bar, custom code, and aux links
- the icons include imports different icon components, some of which are conditionally imported by feature guards

There are also candidates for future splits and joins:

- the sidebar could be split into navigation, collections, external link, and header/footer code
- the "search footer" could be joined with other search code, which would make it easier to "include search" in one go; *however, this is a markup change*
- @kevinlin1 has pointed out that there is some leakage between the sidebar (which computes parents/grandparents) and the breadcrumbs (which needs them to render). He's graciously added a bandaid fix to `minimal` (which does not render the sidebar). However, in the long term, we should either:
    - calculate this in a parent and pass the information to both components
    - change how this works entirely (which may happen with multi-level navigation)

@pdmosses has done a great job outlining this and more in his [Modular Layouts test site](https://pdmosses.github.io/modular-layouts/docs/main/).

### minimal layout

Based on @kevinlin1's use-case in just-the-class (see: his [Winter 2023 CSE 373 site](https://courses.cs.washington.edu/courses/cse373/23wi/)), we've created a first-class `minimal` layout that does not render the sidebar or header.

In a [comment](https://github.com/just-the-docs/just-the-docs/pull/1058#discussion_r1057015039), Kevin has indicated that we can re-add the search bar in the minimal layout; however, it seems like this would be a code change. I think we should punt this to a future issue/PR.

@pdmosses has also discussed the confusion of `minimal` as a layout and its meaning in inheritance. I've added a note in documentation to clarify the (lack of) inheritance relationship.

### documentation

I've written documentation in the "Customization" page / [Custom layouts and includes](https://deploy-preview-1058--just-the-docs.netlify.app/docs/customization/#custom-layouts-and-includes) section explaining:

- generally, that we use includes/layouts (and pointing to docs)
- the `default` layout and its constituent components (with a warning about name collisions)
- creating alternative layouts with `minimal` as an example
- the inheritance chain of layouts and the vendor layouts that we consume

I've also created (and linked to) a [minimal layout test](https://deploy-preview-1058--just-the-docs.netlify.app/docs/minimal-test/) that is currently a copy of the markdown kitchen sink but with the minimal layout. I think there's room to improve this in the future.

### future work

I think there's a lot we can do. Let me break this into various sections.

Potential follow-ups before `v0.4.0`:

- re-including search in `minimal` (anticipating a minor code change)
- fixing the leakage of parent/grandparent information between the sidebar and breadcrumbs (anticipating no end-user code change, but good to evaluate separately and discuss)
- heavily document this in the migration guide (#1059) and in our RC4 release docs
- improve semantic markup for components (ex `main`, `nav`)

Related work in later minor versions:

- split up components into smaller components
- allow users to easily customize new layouts using frontmatter (see @kevinlin1's [comment in #959](https://github.com/just-the-docs/just-the-docs/issues/959#issuecomment-1249755249))

Related work for `v1.0` (i.e. a major breaking change):

- rename and better categorize existing includes
    - standardizing the "custom" includes
    - moving other components to the `components/` folder (ex `head`, `nav`)
    - potentially: less confusing naming for various components
- potentially separate the search and header as components, so that they are completely independent 

Tangentially related work:

- more flexible grid (see @JPrevost's [comment in this PR thread](https://github.com/just-the-docs/just-the-docs/pull/1058#issuecomment-1363314610))
- a formal [feature model](https://en.wikipedia.org/wiki/Feature_model) of JTD, documenting feature dependence (see @pdmosses's [comment in this PR thread](https://github.com/just-the-docs/just-the-docs/pull/1058#issuecomment-1365414023))
- better annotate new features (motivated by writing these docs)
    - we should add "New" to new features :) 
    - we should note when a feature was introduced (I think this is a core part of most software documentation)
    - we should annotate things that are "Advanced" in so far as the average Just the Docs user will not use them / they require significant Jekyll knowledge


--- 

Closes #959.

Avoid the need to add a link to favicon,ico when editing `_includes/head_custom.html`, and avoid creating an invalid favicon link

- Remove the content of `_includes/head_custom.html`
- Add code to `_includes/head.html` to create a link to an existing favicon,ico
- Add an explanation of favicon_ico to docs/configuration.md
- Remove the example of `includes/head_custom.html` and add an explanation of what the `<head>` element automatically includes

Fix two bugs in customization docs

- custom favicon docs were not wrapped in `{% raw %}` tags
- the "new" annotation for color schemes had an extra whitespace, and so the CSS class was not applied

* docs(collections): Add warning about mandatory `_`-prefix

* Apply recommended wording

Hello everyone, this is my implementation for the copy button on the snippet (requested in #924)

The implementation is made 100% javascript as with or without a jekyll template modification you still have to execute some javascript code, and I consider it the best choice.

the button only appears if the mouse is over it, to allow the entire line to be read

the important CSS changes were made to make the copy button work even in the long code situation:


![image](https://user-images.githubusercontent.com/26844016/187731472-d4bf7828-2356-4d94-9c2d-9db863228f5f.png)

to avoid this:

![image](https://user-images.githubusercontent.com/26844016/183292313-d7f73d7d-58c0-4c7b-b5ba-e08bd285514b.png

)

Co-authored-by: Matt Wang <matt@matthewwang.me>

* Issue #1023 - note that GA4 properties are supported

* Issue #1023 - parameterize Google Analytics property script

* Issue #1023 - support a list of multiple Google Analytics tracking IDs in config

* Issue #1023 - update Google Analytics configuration doc

* Fix configuration of multiple Google Analytics properties and simplify type checking

* simplify unnecessary code repetition

* tweak Google Analytics config documentation wording

* Add 'reversed' as the preferred keyword, with 'desc' as a deprecated alternate

* Doc updates

* Add the test for 'reversed' to the toc_list

Add also a comment about this.

Co-authored-by: Peter Mosses <18308236+pdmosses@users.noreply.github.com>

* Removes `favicon.html`, shifts content to `head_custom.html`
* explicit callout for custom favicon in customization docs
* Cleaner and more consistent documentation (review from @pdmosses)

Co-authored-by: Peter Mosses <18308236+pdmosses@users.noreply.github.com>