Closed Bug 1010142 Opened 10 years ago Closed 9 years ago

Sort out themes / css / image locations on desktop

Categories

(Hello (Loop) :: Client, defect, P5)

defect

Tracking

(Not tracked)

RESOLVED WONTFIX
backlog tech-debt

People

(Reporter: standard8, Unassigned)

References

Details

(Whiteboard: [needs investigation][browser][tech-debt])

User Story

- Review current styles in browser/components/loop
- Figure out which need to stay there and which go into browser/themes
- Figure out strategy for css that is shared between the standalone code and the desktop browser.
Currently pretty much all of Loop's css is in browser/components/loop. Some/all of this should be in browser/themes and styled appropriately for each platform.

We'll probably be able to develop some of this over time, but we should get the basic structure and rules in place fairly soon, to aid development going forward.
looks like a duplicate of Bug 624647 - [css3-images] Implement object-fit and object-position CSS properties. please close if it is.
Whiteboard: check if dupe Bug 624647
Blocks: 1014571
No longer blocks: 972014
Definitely not a duplicate. This is about getting our css files in the right places and appropriate styling for images.
Priority: -- → P3
Whiteboard: check if dupe Bug 624647 → [needs investigation]
Target Milestone: --- → mozilla33
User Story: (updated)
Whiteboard: [needs investigation] → [needs investigation][browser]
Priority: P3 → P2
Target Milestone: mozilla33 → mozilla34
Niko -- Can we use this bug to cover the work you're doing right now with the css changes?  If so, I'll assign this to you and raise the priority of this to a P1.  If this bug is different from the work you're doing, can you explain how it is different?  Thanks!
Flags: needinfo?(nperriault)
(In reply to Maire Reavy [:mreavy] (Plz needinfo me) from comment #3)
> Niko -- Can we use this bug to cover the work you're doing right now with
> the css changes?  If so, I'll assign this to you and raise the priority of
> this to a P1.  If this bug is different from the work you're doing, can you
> explain how it is different?  Thanks!

From what I understand, here Mark is suggesting to move some styles to browser themes, which I know pretty much nothing about… While I'm currently working on creating an design integration reference for our React components (bug 1042799).

I suspect someone with more platform knowledge in this very area would be a better fit than me here, though I could probably adapt and learn if needed.
Flags: needinfo?(nperriault)
Ah, sorry, Niko.  I read the bug too quickly.  Please keep doing what you're doing.  I'll talk to Mark about this one when he gets back.

Mark - For when you're back, I'm trying to figure out who much doing the work on this bug during Fx34 helps us versus deferring it until the Fx 35 time frame.  Thanks.
Flags: needinfo?(standard8)
Moving this to a P3 pending Mark's feedback.
Priority: P2 → P3
Reading this bug more carefully, I think this is one we could move out to Fx 35, and I'll talk with Mark when he gets back from holiday.
Priority: P3 → P5
(In reply to Maire Reavy [:mreavy] (Plz needinfo me) from comment #5)
> Mark - For when you're back, I'm trying to figure out who much doing the
> work on this bug during Fx34 helps us versus deferring it until the Fx 35
> time frame.  Thanks.

I suspect this can be deferred, though really we should talk to someone from the fx-team. So maybe Mike can help here.

My main concern is whether or not it is felt that this is needed for themes customise-ability, or if we're fine just keeping everything in our own content land.
Flags: needinfo?(standard8) → needinfo?(mdeboer)
I too think this can be deferred.

I think we best do this once we move the standalone client out of the browser codebase; it's semantically incorrect to have it in browser/ when it doesn't have anything to do with Firefox. It might share a few styles and JS libs, but that's not a real reason to have it in-tree like this. Additionally, it needlessly adds complexity the structure of the in-browser client and makes it use code to make it cross-browser compatible, which is quite unique for a browser feature.

Once the standalone client is moved to Github (or some other more appropriate place), we can move the Loop panel styles to `browser/themes/shared/loop`.
Flags: needinfo?(mdeboer)
(In reply to Mike de Boer [:mikedeboer] from comment #9)
> I think we best do this once we move the standalone client out of the
> browser codebase; it's semantically incorrect to have it in browser/ when it
> doesn't have anything to do with Firefox. It might share a few styles and JS
> libs, but that's not a real reason to have it in-tree like this.
> Additionally, it needlessly adds complexity the structure of the in-browser
> client and makes it use code to make it cross-browser compatible, which is
> quite unique for a browser feature.

We've put this in m-c for a variety of reasons, and we're not planning on moving it out. If there's an issue with it, then we need to have a discussion with at least Dan, Nicolas and myself (and obviously not in this bug).
(In reply to Mark Banner (:standard8) from comment #10)
> We've put this in m-c for a variety of reasons, and we're not planning on
> moving it out. If there's an issue with it, then we need to have a
> discussion with at least Dan, Nicolas and myself (and obviously not in this
> bug).

Alright. Well, let's not do that now; would be quite inefficient. I'd recommend to leave the styles as-is and revisit later after MVP.
(In reply to Mike de Boer [:mikedeboer] from comment #9)

> I think we best do this once we move the standalone client out of the
> browser codebase; it's semantically incorrect to have it in browser/ when it
> doesn't have anything to do with Firefox.

I initially suggested the following: most of development of shared content code + standalone should happen outside of m-c, then we could expose some "loop-shared" and "loop-client" npm packages. 

So we'd just release major versions of loop-shared along with FF, a bit like how we're shipping react, backbone and jquery (we could bump minors and patches as well for nightlies). Hint: that wouldn't require to use npm at all in FF, just to build & release dist files and adding them to the FF tree.

+1 to have this discussion again, but agreed that this is post MVP stuff.
Target Milestone: mozilla34 → mozilla35
Whiteboard: [needs investigation][browser] → [needs investigation][browser][tech-debt]
backlog: --- → Fx36+
backlog: Fx36+ → Fx37+
Target Milestone: mozilla35 → ---
backlog: Fx37+ → tech-debt
this is partially happening with visual refresh in Fx43.  likely will just close bug next time we look at it.
Rank: 59
We've now moved to an add-on. Additionally there's long term futures of "heavyweight" theme add-ons under debate. I've not heard any complaints for customising our stuff, so I'm going to mark this as wontfix for now.

If we find a real issue later, then we can reconsider.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.