A home for those extra kwargs, at least in Webview

[Nick Schwaderer]

Say a widget gets an extra kwarg it doesn't need

Normally it'd just get cast into the fire of irrelevance in ruby-land. But I think it would be cool to secretly pop it on as an extra HTML attribute, like what currently happens with para (e.g. para 'fish', class: 'flop')

Now, this would allow us to do things that are definitely outside the Shoes-spec scope. Which is against our values. But I interject that for this particular case it's just hanging on to custom things that currently are meaningless anyway.

The main thing I'm thinking about is.... class. But it could be something else. then, if somebody injects WV-specific CSS styling in a widget they wrote themselves they would have an out-of-the-box-ready-to-go system to slap classes and other attributes onto things.

And to be honest, I think it's a small accommodation to make for what I think could be a really nice styling potential in the future.

Though of course, if folks want to go really hog-wild with this, they can write even more of their own widgets. But I find this area quite interesting.

[Noah Gibbs]

Right now we don't have a ton of consistency in how we do it. The arc widget won't accept any kwargs at all (which is wrong, and will change.) Stack puts them into an "options" display property and sends them across, so the display widgets can see them if they want. You mention para, which does something similar but calls it "html_attributes" instead of "options".

But we could, of course, allow unrecognised kwargs to do this more consistently.

Shoes Classic does a thing where you can pass some args positionally, or any acceptable style as a hash arg (since that was before real kwargs.)

I'd be fine with declaring additional styles in Scarpe that aren't in Shoes. That's one of the more harmless extensions we can make, though we may want to mark the files somehow (add a scarpe_mode method to Shoes::App that turns them all on?).

We probably don't want to accept absolutely any unknown style, because then typos don't get caught.

[Noah Gibbs]

By the way, the big reason not to just allow them without a custom mode is that if people write Scarpe-only Shoes apps that supply those styles, other Shoes implementations are likely to choke and die on them. We don't want Shoes in general to let you make typos without telling you so, so it's not a good idea to just have all Shoes implementations ignore all unknown styles.

So to some extent, the extension mode would be allowing for future Shoes implementation efforts. Scarpe would have a harder time if there were four or five different distinct Shoes-like sublangs, right? We don't want Scarpe to be one of those.

[Nick Schwaderer]

Yeah definitely! So I guess, instead of just saying "anything you type like a symbol is now an accepted kwarg passed to a widget go have fun!"

we could have a constant saying

Scarpe::ScarpeMode::ACCEPTED_HTML_ATTRS = [
  :class,
  ???
]

...

module Scarpe
  class App
    include ScarpeMode if ENV["SCARPE_MODE"]
  end
end

I'm basically designing this backwards first but then we could explicitly allowlist somethings as scarpe mode. Which is where we allow clean, uncontroversial things like supplying a class method.

Then we could potentially include our own very simplistic widgets like:

// /path/to/my/style

// obviously this is completely contrived and makes no sense
// you should just use the shoes raw dsl
// but bear with me for this example
.fish-flop {
  color: "pink"
}

# this would be a new custom widget?
style "/path/to/my/style"

para "Fish", class: "fish-flop"

[Noah Gibbs]

I think we're roughly on the same page, yeah. So with what I was suggesting, it'd look something like:

Shoes.app(scarpe: :extensions) do
  style "schwad/custom/style.css"
  para "Fish", class: "fish-flop"
end

Or you could use a method rather than a Shoes.app kwarg. Either will fail in non-Scarpe Shoes implementations, but do so in a clear way.

I think we're pretty rapidly going to wind up with three sets of styles in each widget:

• Shoes 'standard' styles, like passing margin: to stack
• Shoes positional styles - e.g. for Rect this list goes "top, left, width, height, corners", which lets us turn non-kwargs into Shoes styles
• Shoes extension styles - like class, or html_attributes; these will never be positional, always kwargs

We're pretty close already. A Lacci display_property is nearly a Shoes style. The big difference is how we handle positional args, and -- with your suggestions -- extensions.

[Nick Schwaderer]

Or you could use a method rather than a Shoes.app kwarg.

Ooh, I like it as an app-level kwarg

[Nick Schwaderer]

I think we're pretty rapidly going to wind up with three sets of styles in each widget

++ I think we're on the same page about this. And I think I've been able to articulate why I believe there's long term value into supporting an extension style system, as long as we're mindful.

Since it's a narrow ingress (iteration one: let me please specify my stylesheet, please let me insert classes as kwargs), that will even stay narrow at its widest point (other ways to style?).

But then if I release and construct these apps it's very clear that I'm not reinventing shoes, traditional widgets or even adding my own widgets. (Though I could see an interesting exploration with my own widgets... but that's strictly shoes-allowed to write your own)

[Noah Gibbs]

Between them, PR #472 and #473 should fix this, once they're both merged.

[Noah Gibbs]

Fixed.