Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Create thumbprint-global-css package #36

Closed
danoc opened this issue Jan 26, 2019 · 2 comments
Closed

Create thumbprint-global-css package #36

danoc opened this issue Jan 26, 2019 · 2 comments

Comments

@danoc
Copy link
Member

danoc commented Jan 26, 2019 •
edited
Loading

It will contain:

  • Reset
  • <body> styles
  • <a> styles

One thing I'm unsure about is to distribute the font-face. Would be good to distribute here, but it requires setting the $thumbprint-font-url variable: https://github.com/thumbtack/thumbprint/blob/master/packages/tp-ui-core-font-face/_index.scss#L6

Is it better to distribute this as a CSS-only package that we can host on a CDN? Or should we ship it as a SCSS package that requires the variable as a config step?

We can additionally create this as a React component called <ThumbprintGlobal />. It would be used like this:

<ThumbprintGlobal fontUrl="https://example.com/">
  <header />
  <main>
    <Button />
  </main>
</ThumbprintGlobal>

fontUrl would be a required step to get Mark loaded. Button could even throw a console error if it is not used within a ThumbprintGlobal component.

Edit: An issue with this approach is that we need the reset to load first. I'm not sure that can be guaranteed if it's getting imported by ThumbprintGlobal.

cc: @tomgenoni
This was referenced Jan 26, 2019
Closed
Closed
@tomgenoni
Copy link
Contributor

My sense is that is that one CDN hosted CSS file would cover any implementation. Seems like if we're going to the trouble to require a variable (in our case, the root URL) we're not far off from requiring a full URL. And if that's the case a single CSS-only approach implementation seems preferable.

Would have to think through versioning and performance if we went this route.

@danoc
Copy link
Member Author

danoc commented Feb 1, 2019

@tomgenoni — Want to close this one and make follow up tasks?

The ones I can think of are to delete the old packages and document the new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@danoc @tomgenoni