> For the complete documentation index, see [llms.txt](https://docs.wem.io/platform/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.wem.io/platform/tutorials/building-widgets/basics/11-global-scope.md).

# 11. Global Scope

There is one important aspect to address before concluding this chapter. When you use widgets in a WEM project, the WEM runtime will render these widgets within the page, and the styles and JavaScript associated with the widget will be added in a global context. Therefore, you must be careful when naming your CSS selectors and JavaScript identifiers, just as you would when building a standard website.

While there are modern solutions to this issue, WEM does not yet support all of them. In later chapters, we will explore these solutions in greater detail. For now, let's take a brief look at the potential issues.

### CSS

In CSS, naming collisions occur when two or more styles are defined with the same selector. This can lead to unexpected results, potentially overriding earlier styles. For example, consider the following:

```less
// Bob's button widget
.button {
	background-color: tomato;
}
```

```less
// Jane's button widget
.button {
	background-color: lightgoldenrodyellow;
}
```

Design systems like Bootstrap often use simple class names such as `.btn` or `.alert`. This is because you typically want to incorporate one design system per website. However, widgets are not design systems, and as demonstrated in the example above, it is easy to create conflicts when using generic names.

### JavaScript

When using JavaScript in your widget, you must be cautious when naming your functions, classes, and variables. If you are not careful, you may inadvertently override them, leading to undefined behavior in the widget's functionality. For instance:

```javascript
// Bob's button widget
function clickHandler() {
	console.log("My name is Bob.");
}
```

```javascript
// Jane's button widget
function clickHandler() {
	console.log("Jane here!");
}
```

In this example, clicking Bob's button will log "Jane here!" to the console. While this may seem like a harmless example, it is not the expected behavior. There are multiple ways to address this issue, but they are beyond the scope of this chapter.

### WEMscript

The `scriptreference` statement is also susceptible to naming collisions. Consider the following example:

```
<? 
	/* In Bob's button widget */
	scriptreference "button" FileUrl(@ButtonJs) 
?>
```

```
<? 
	/* In Jane's button widget */
	scriptreference "button" FileUrl(@ButtonJs) 
?>
```

It is important to note that it does not matter that both use `@ButtonJs` as the same reference name, as this is a local variable of the widget. However, using `"button"` as a namespace is too generic. In this case, it will not override other functionalities but will instead use the script that has already been registered under the name `"button"`. Another statement that has the same issue is called `scriptmodule`, which we will discuss in later chapters.

### How to Solve

There are various ways to address these issues, with some solutions being better than others. One simple approach is to avoid using generic names like `button`. Instead, use a format like `yourcompanyname-componentname` to make it less generic. In CSS, you would have something like:

```css
.janescompany-button {
	background-color: tomato;
}
```

In a `scriptreference`, you would write:

```
<? scriptreference "janescompany-button" FileUrl(@ButtonJs) ?>
```

This is just one of the possible solutions, and there are many more depending on the context. I have also omitted a solution for JavaScript, as that topic requires a dedicated section of its own, which we will explore in later chapters.

### Conclusion

For now, it is essential to remember that you should avoid using generic names unless you are absolutely certain of what you are doing.

Now that you have learned the basics of building a widget, we also need to discuss the risks and responsibilities involved in this process. The next chapter will be serious but very important!


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.wem.io/platform/tutorials/building-widgets/basics/11-global-scope.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.