-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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
LTR/RTL fixes #11905
LTR/RTL fixes #11905
Conversation
"common" i18n namespace will always be available. This forces using the locale text-direction for these components, to override any cascading LTR overrides from pages with English-only content
(patches illegible colors)
insetInlineStart/End Chakra-UI style props not being recognized; refactored to use `style` prop
✅ Deploy Preview for ethereumorg ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
(Initial Netlify build failed from unrelated reasons which caused the check to fail... re-ran and it passed. Preview link from passing build is above, but the check never reset) |
insetStart={{ xl: "8" }} | ||
style={{ insetInlineStart }} |
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.
This change was made throughout as the style props insetStart/End
or insetInlineStart/End
have not been working as expected with Chakra components. Using style
fixes this, but then we lose access to the Chakra tokens. As an alternative to using css var(--eth-type-token)
syntax, the useToken
hook was used.
@@ -149,7 +151,7 @@ export const getSearchModalStyles = (): SystemStyleObject => ({ | |||
}, | |||
|
|||
".DocSearch-Hit-Select-Icon:focus, .DocSearch-Hit-Select-Icon:hover": { | |||
color: "switchBackground", | |||
color: "switchBackground", // TODO: Remove? Causing low contrast in dark mode |
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.
@nloureiro When hovering directly over the arrow we get this low-contrast fill on dark mode:
It's not as bad in light mode but is there a color token you would recommend that looks good in both?
Or maybe we just consider removing this hover effect since it only triggers when hovering over the arrow itself, but the action doesn't change compared to the rest of the box. This would be my preference.
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.
p: 0, | ||
ps: 2, |
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.
p: 0
overrides existing padding-left
from @docsearch/css
, then reassigns with direction-responsive ps
position="fixed" | ||
zIndex="99" | ||
zIndex="banner" |
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.
Fixes bug where menu contents (ie. UseCases pages) were overlaying this banner.
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.
Nice!
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.
My thoughts regarding RTL support here 😄
@@ -65,7 +70,7 @@ const Breadcrumbs = ({ | |||
.slice(startDepth) | |||
|
|||
return ( | |||
<Breadcrumb {...props}> | |||
<Breadcrumb {...props} dir={dir}> |
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.
Most instances of the dir
prop should now be removed as this is redundant and is taken care of under the hood in the Chakra component structure/theme or by the use of an inset*
prop.
An exception is where flexbox is used for content positioning, where CSS is not smart enough to handle RTL automatically with flex props. (I will point out the exceptions)
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.
See other comment about specifically why I'm overriding these at the component level... same applied to this one.
@@ -67,6 +71,7 @@ const FeedbackCard = ({ prompt, isArticle, ...props }: FeedbackCardProps) => { | |||
mt="8" | |||
w="full" | |||
{...props} | |||
dir={dir} |
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.
This is an exception where the dir
prop should be kept, as flexbox is controlling the content positioning here.
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.
Honestly I'm not having any problems with flex boxes here...
I'll double check all of your comments, but the reason for these was not just to use the dir
for the chosen locale, but to specifically do so at the component level for components that:
- Exclusively use the "common" namespace for translations (which every language has before even being listed
- Are (or potentially) nested inside page content which may end up NOT being translated.
In this case (ie. /ar/developers/docs/blocks) html
could be set to dir="rtl"
, the main content div could be set with dir="ltr"
(overriden because contentNotTranslated=true
), but then some components (ie. FeedbackCard
) are fully translated, which should again run rtl.
The change here addressed this by independently setting the dir
based on locale, without relying on html[dir]
since the content it's nested in may flip it back.
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.
Got it. Agreed, I think we need this for these "global" components.
fixes direction of pointer emoji for RTL pages, taking into account if contentNotTranslated. updates component with latest TS conventions; removes passing relativePath prop, instead loading locally using useRouter. rm redundant isNext, using only isPrev bool to simplify and avoid conflicts
use useTranslation hook over Translation component
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.
@wackerow amazing job!!!! thanks for the work done here. Looks really nice the RTL version!
==========
Few minor things that don't block this PR.
Small detail in the slider arrows, we shouldn't use rtl props here.
https://deploy-preview-11905--ethereumorg.netlify.app/fa/what-is-ethereum
The results from the search are not translated, right? if so, I think we shouldn't change the direction
Nice, thanks @wackerow |
Description
Preview URL
Screenshots:
https://deploy-preview-11905--ethereumorg.netlify.app/ar/developers/docs
ex. RTL locale, but content not translated:
https://deploy-preview-11905--ethereumorg.netlify.app/fa/developers/docs
ex. RTL locale where content is translated (unchanged, but for comparison))
RTL search modal: