Add option to warn when missing semicolons

[NduatiK]

Addresses #182

When calling the parser you can now specify that warnings be emitted on the console if semicolons are missing. When parsing using the expect_semicolons? option:

RulesParser.parse(input, expect_semicolons?: true, ...opts)

The value would be false (or not set) in most places, but set to true when parsing the style attribute on elements.

[bcardarella]

what would be the use case for false in the expect_semicolons ?

[NduatiK]

From my understanding we only wanted the warning on the style attribute but not on the ~SHEET sigil. Is this incorrect?

[bcardarella]

As we want to keep our implementation similar to CSS:

Semicolons are not strictly required at the end of each line in a CSS file. However, they are necessary to separate declarations within a CSS rule. For example:

h1 {
  color: blue;
  font-size: 20px;
}

In this example, the semicolons are needed to separate the color and font-size declarations. If there is only one declaration, the semicolon is optional:

h1 {
  color: blue
}

Despite this, it's considered good practice to always include semicolons, even for the last declaration in a rule, to avoid potential errors and maintain consistency in the code.

Also shouldn't this be in live_view_native_stylesheet instead?

[carson-katri]

Isn’t the code inside a rule supposed to match the target platform? In Swift you don’t need a semicolon at the end of each statement, as long as they are separated by a newline.

[bcardarella]

I'm not super tied to the implementation and I think there is time for us to debate on this.

If we were to lean in the direction of the upstream UI framework then we should go all-in and rather than newline use . and that could also extend to the style attr too.

On the other side, separating the top line modifiers/rules by ; gives us a single API syntax for stylesheets that is a common-lingua.

[NduatiK]

Also shouldn't this be in live_view_native_stylesheet instead?

The semicolons are delimiters between modifiers, the stylesheet lib doesn't know about modifiers and so this functionality has to be in the client libraries. Once Jetpack arrives and we consolidate functionality into live_view_native_stylesheet, it will live there.

---

I'm not super tied to the implementation and I think there is time for us to debate on this.

I'll leave it as configurable for now.

[bcardarella]

@NduatiK thank you, let me dig in after v0.3 is released. I want us to come to a consensus if we will go the route of leaning into the native UI framework's own deliminator or semicolons.

[bcardarella]

I need to look into what Jetpack and possibly WinUI3 (Maui?) need for this as I want to make sure this doesn't paint us in a corner with a single framework