-
Notifications
You must be signed in to change notification settings - Fork 7
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
EthicalAds: Default to fixedfooter for smaller screens #447
base: main
Are you sure you want to change the base?
Conversation
This is something I've wanted for a little while. I don't think we're quite ready to ship it, but I think it makes sense in a lot of cases. I'm generally becoming more excited about this placement, especially when the floating one is pretty intrusive.
b9e342e
to
a4ef3ab
Compare
433c4ef
to
0f36172
Compare
Marking this ready for review after our previous conversation. I'd like to see us doing the fixed footer by default more, since I think it's a much more user friendly ad format. We're hopefully gonna work on a nice fixed footer/header format with a small image, which I think will be even better, but I think this is a nicer UX for default. In general I really dislike how not integrated the ad feels on non-Sphinx themes, so I think this is a "gentler" approach to ads that isn't quite as impactful for users who want to move to RTD for non-Sphinx themes. NOTE: This is somewhere that it would be interesting to have a feature flag, so that we could test it a bit before rolling it out more widely. |
Looks like this hides the "sidebar" toggle on docify: https://test-builds.readthedocs.io/en/docsify/#/ -- and there wasn't an element I could find to add margin-bottom to, because I think they're fixed positioning.... The struggle of placement on arbitrary content :( |
Yeah, I think we should keep adding more frameworks to our heuristic detection and create better ad placement for specific documentation tools. Sphinx is well integrated because we did the work there. The same happens with all the other we have listed at: Lines 73 to 142 in 8ccaa33
We can do the same for Markdoc, mdbook and similars to have better integrations on those as well. It shouldn't be hard. We need to find the right CSS selector. I'm not opposed to have a better default for frameworks we don't know; but we for those we are aware they exist and people are using them, we should integrate them better by using custom positioning.
As I mentioned in the meeting, I would not use feature flags for this, but use a |
Show how simple is to add a better ad positioning for a documentation tool that we know. 1. Find the CSS selector that allows to detect the framework 2. Find the CSS selector for the ad position 3. Add small CSS for styling if required Related #447
I added an example of what I'm saying in #470. You can see it's pretty easy to create these custom positioning based on the framework. I think they will always work better (less intrusive, nicer look&feel) than a generic default. You can try to follow those steps and add a better positioning for Markdoc, for example. |
By they way, when performing visual changes, I would really appreciate having a screenshot of how it looks --that way is a lot easier to do a review; since it doesn't require me to clone the PR and testing it locally. |
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.
@humitos point on per-tool styling is probably better overall, but just noting a couple things with the approach here.
src/ethicalads.js
Outdated
// TODO: THIS IS A HACK. IS THERE A BETTER WAY? | ||
// Add margin to the bottom to avoid hiding bottom of content | ||
const root_node = document.querySelector(docTool.getRootSelector()); | ||
root_node.style.marginBottom = "2em"; |
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.
Just noting a couple issues here, I haven't tried playing around with the styling here.
Altering style rules through Element.style
ends up just adding a style="..."
attribute to the element, which has a couple issues:
- Inline
style
attributes can be blocked by CSP rules as unsafe. - Inline
style
attributes have the highest specificity in CSS, so the user loses control of this styling.
In both cases, it's better to use classes to apply rules to these elements.
src/ethicalads.js
Outdated
@@ -158,6 +158,20 @@ export class EthicalAdsAddon extends AddonBase { | |||
placement, | |||
elementInsertBefore.lastChild, | |||
); | |||
} else if (window.innerWidth <= 1300 && window.innerWidth > 768) { |
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 just noticed this logic and the same above. These conditionals are only evaluated once, so don't catch the window resizing or rotating. Users have to reload before the placement style would shift in this case. These widths might be better off as CSS media queries, which are reactive.
This is something I've wanted for a little while.
I don't think we're quite ready to ship it,
but I think it makes sense in a lot of cases.
I'm generally becoming more excited about this placement,
especially when the floating one is pretty intrusive.