HeinrichApfelmus / threepenny-gui

GUI framework that uses the web browser as a display.
https://heinrichapfelmus.github.io/threepenny-gui/
Other
439 stars 77 forks source link

Suggestion: (##) for setting element ID #93

Open int3 opened 10 years ago

int3 commented 10 years ago

I find it to be an operation at least as common as setting the CSS class. And (##) would be in obvious analogy to the CSS syntax plus the existing (#.) operator.

Suggestion 2, while I'm at it: Are you considering some sort of support for a templating system? Maybe heist, since threepenny already depends on snap...

int3 commented 10 years ago

I know it's good practice to split out bugs into different issues, but in the interests of not spamming... here's one more suggestion: Could you expose str/int/emptyAttr? They seem like useful convenience functions.

int3 commented 10 years ago

Suggestion 4: It should be possible to sink single CSS styles directly, rather than editing the entire CSS style list at once.

P.S. If you think any of these suggestions are good ideas I'd be happy to submit PRs for them once I'm done with my current project.

HeinrichApfelmus commented 10 years ago
  1. I'm not too keen on this. Due to issue #60, the id attribute is not as useful as it could be at the moment. For CSS, classes are probably preferred.
  2. I recognize the need to separate GUI layout from functionality, but I don't think that a simple template engine is the answer. In a sense, the Graphics.UI.Threepenny.Elements etc. modules form a template engine (with weird syntax, namely Haskell syntax). Concerning other solutions, I would very much prefer a WYSWIG program for building HTML GUIs.
  3. Not sure. Do you have a use case where they make your life more convenient? I think I prefer the full list of HTML attributes as given in the module, but I'm happy to be convinced otherwise. Note that attr is always available. (If these three functions are to be exported, I would give them other names, because I don't like the current ones.)
  4. If I remember correctly, the CSS style list behaves exactly the way you mention: it overwrites styles that are mentioned, but doesn't delete styles that occur in the list. Arguably, this behavior is weird, and I'm happy to see it fixed: a whole list that overrides everything and a facility to apply individual styles directly.

(Unfortunately, I won't have much time until October, so I may be very slow in accepting patches.)