-
Notifications
You must be signed in to change notification settings - Fork 17
More CSS Types/Styles #107
Comments
Thanks for the feedback @nathanhack - it's still very early days for
This is actually one area of But as you can see from the Line 23 in ffe10c5
For now I've essentially fallen back to a code generated equivalent of Line 13 in ffe10c5
The goal is ultimately to code generate the React elements from the HTML N spec. Similarly, the goal is to code generate the CSS types from the CSS N spec. Quite how code would interoperate between HTML versions is, I admit, an unknown. But it strikes me that problem is an easier one to solve than the cost of not having typed fields for HTML elements or CSS properties. So what would this look like?
There's plenty to work out here of course. But once complete we would effectively have a Go type-based encoding of HTML elements and CSS properties. For now I'd prefer to stick to my halfway-house of having code generated properties but all of the Please feel free to ping back here with any specific properties, or if you're feeling generous you can submit a PR. If you need any guidance on what's required to submit a PR (because that's not documented) please also ping back here. |
I believe your position is more than reasonable. Something is frequently better than nothing. However, doing some of the CSS in a css file and other parts in code isn't really the best design for my projects. However, I REALLY REALLY like where the CSS implementation is heading. I also would like to contribute to its success. Partly, because I'm using it in my projects; and because I believe this project has the better approach than others. Given what your ultimate goal is, I personal wouldn't put any more effort into any of the CSS properties as they are currently. (And thanks for even entertaining the idea. :-) But let's not.) I have only about 8-10 unique CSS types/properties that I need for my current project and I would like to add them to your repo. Could you provide a few more concrete details? Maybe outline, a few more of the details as you see it implemented for the FontSize case. So that I could start working on it. Also, have you given much thought how to handle the case where the CSS is independent of HTML elements such as @media? |
This is a good point. I haven't (yet) given much thought to ways in which we could unify writing CSS in Go itself, or indeed whether that would even be a sensible goal. If we're going to the effort of generating types from the spec though, it wouldn't be so far fetched. We'd then need to come up with some sort of mechanism by which classes could be declared etc... definitely one to think about another day.
Great!
Sure, I'll pull something together when I get a moment.
Nope. Very much falls into the same category as the class definitions etc - i.e. not thought much about it yet. |
Apologies @nathanhack I haven't gotten round to looking at this yet. |
First off, kudos on this library. When considering this library over vecty ... it was an easy decision. Vecty has created a fat layer making it hard to understand and brittle. Your lib feels like a much better amount abstraction and OMG you have examples and documentation (worth it's weight in gold)!
On to the feature request:
The CSS bit is great. However, there many more CSS types/styles out there. Since this library isn't about removing the need to understand how CSS is done, would you consider using a map[string]string instead of explicitly coding for each CSS type/style and value?
Thus the prop for the css would be a map like:
The text was updated successfully, but these errors were encountered: