Shouldn't Modifiers respect semantic order (i.e. priority)?

[ivan-klass]

// not working example
def renderSelect(options: Seq[Int], selectedValue: String) = select(
  value := selectedValue, // ignored by the browser since proper option does not yet exist
  options.map(idx => option(value := idx.toString, s"- $idx -"))
)

// working example
def renderSelect(options: Seq[Int], selectedValue: String) = select(
  options.map(idx => option(idx)),
  value := selectedValue, // works as expected, executed after adding child
)

A possible "low-fruit" solution would be - add a def priority: Int = 0 to Modifier, and set it to higher in value property.

// @ class HtmlTag

  def apply(modifiers: Modifier[ReactiveHtmlElement[Ref]]*): ReactiveHtmlElement[Ref] = {
    val element = build()
    modifiers.orderBy(_.priority).foreach(modifier => modifier(element))
    element
  }

[raquo]

This particular problem with <select>'s value is a simpler version of #94. See that issue for a reliable workaround.

Currently Laminar follows the DOM spec on this, but as you discovered that's not very ergonomic. Theoretically we could do something smarter, or provide a custom API just for setting options+value, but I'm not yet sure what / how exactly.

Implicitly reordering modifiers will not be enough to solve the dynamic-data aspects of #94, and I suspect would have other side effects (that will only crop up in weirdly specific edge cases, making them hard to figure out).

[ivan-klass]

Ok, I agree that definition application order of modifiers seems much more clean and solid, while this is a specific case.
To keep options up-to-date with the value, one may keep selection with options in a pair like I mentioned here -
#94 (comment)