Add support for CSS-based theming on the canvas #13828
Conversation
e05ba19 to
5c6614a
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## branch-3.5 #13828 +/- ##
==============================================
+ Coverage 91.57% 92.62% +1.04%
==============================================
Files 326 326
Lines 20737 20767 +30
==============================================
+ Hits 18990 19235 +245
+ Misses 1747 1532 -215 |
b0f9a3a to
9bcbdfb
Compare
|
This is tentatively ready for review. There is a class of failures (resulting in multiple integration test errors) that I'm fighting with, which a side effect of bad design around |
|
Approved with some minor inline comments. Some other general comments:
Does the generated DOM hierarchy include the model names, so that those could be used as selectors in some way? A purely type based option is a bit limiting if users want to style different axes on different plots, say. Lastly, I guess the specificity of e.g. |
That specificity is there by design, because those classes are added for ease of identification of DOM components and thus ease of debugging. They are not meant for user consumption and they really can't be used for styling, because shadow DOM would prevent users from attaching any global or global-ish styling using those classes (this is why we are migrating to using CSS variables). |
9bcbdfb to
e228941
Compare
* rendering is for constructing DOM nodes * painting is for drawing to the canvas
e228941 to
960557d
Compare
960557d to
6e709ed
Compare
6e709ed to
cf8dc3e
Compare
* Separate rendering from painting * rendering is for constructing DOM nodes * painting is for drawing to the canvas * Make RendererView inherit from DOMComponentView * Don't use append(), remove() and replaceWith() * Move RendererGroup to a separate module * Introduce StyledElement base class * Attach renderers' elements to the canvas * Use CSS variables in canvas visuals * Add styling/visuals/css_variables.py * Restore functionality of HTML label annotation * Update bokehjs' unit tests * Use stylesheet based styling in HTML labels * Update cross tests baselines * Correctly render the Toolbar in ToolbarPanel * Add CSS support to Text and Hatch visuals * Style text in css_variables example * Migrate styling/visuals/css_variables.py to bokehjs * Allow to specific rendering target for canvas renderers * Reposition menu after toolbar resize if open * Correctly update canvas renderers' elements * Allow to recover from invalid gesture state * Safeguard against disconnected elements * Use render_to() to render toolbar's tool buttons * Add integration tests for HTMLLabel * Add docstrings to models/ui/ui_element.py * Remove deprecated APIs from core/dom.ts * Compute CSS prefix of visual properties once * Robustify render() and after_render() logic * Call r_after_render() after updating children * Use computed_renderer_views to avoid race conditions * Display duration in devtools' progress bar * Robustify is_paused and hold_render logic * Recompute toolbar buttons after layout * Update integration baseline images * Robustify ready state in TileRenderer * Mark _was_build in after_render() * Correctly render contents in Dialog * Add a regression test for issue bokeh#13787 * Update *.blf baseline files * Update bokeh's examples * Add release notes
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
This PR:
An example showing CSS styling of plot background and axis background, ticks, labels and line (see
examples/styling/visuals/css_variables.py):Having an associated DOM hierarchy will aid debugging on the canvas, as well as set up ground work for accessibility/ARIA support and perhaps fully CSS-based layout in the future:
Performance implications of the DOM hierarchy should be negligible.
HTMLLabelto supportstylesheetsandcss_classes#13652