-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
blog: add the v0.13.0 release post #488
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #488 +/- ##
=======================================
Coverage 87.86% 87.86%
=======================================
Files 42 42
Lines 4852 4852
=======================================
Hits 4263 4263
Misses 589 589 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's looking really great! One more quick nit, if it's okay. I noticed leading into a few examples, that what people should see in the output is not explained.
For example...
- "you can do this:" (what is this?)
- "let's style" (what style should I look for?)
- "add an assortment of styles to it." (what styles? what should I look for?)
- "let's use tab_options() here" (to do what? what should I look for?)
Could we tell people specifically what will change (so they know what to look for)? E.g.
- "You can manually indent STABLE using a CSS string:"
- "Let's set a grey background fill on the column header, stubhead, and footnotes:" (no need to say you are using
tab_style()
people will see it, and they have seentab_style()
used several times at this point.) - Set an aliceblue background fill on the title, with some font and border adjustments.
- Set a default honeydew background fill on body values.
(Definitely tweak as needed! I think the key is that people should be able to quickly identify what in the table will change; it's okay to just say the easiest to spot piece.)
Screenshots
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yo, this looks great! I left a small note on a paragraph that's duplicated above and below an example now. It looks like the top piece just needs to be cut out
For task #1, a simple `loc.stub()` call in `tab_style()`'s `locations=` argument will be enough to target the entire stub. | ||
|
||
Task #2 is more interesting. Like `loc.body()`, `loc.stub()` has a `rows=` argument. Because of that, we can use the same Polars expression to target those rows that belong to the stable isotopes (they are identifiable by having `None` values in the `half_life` column). Once we know about the power of Polars expressions in `rows=`, we realize just how much power we have in targeting our table stylings. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the last piece might just be removing this, since it's down below the example now!
This adds the blog post for the v0.13.0 release of the package.