Hello! Author here. I'm a fan of web components for widgets and embeddable third-party interfaces. I'm not as much a fan of them to wrap a site's primary content, for both accessibility and user styling reasons.
I'm not a fan of them for web apps that use excessive whitespace between repeating components[1]. Previously you could just edit the global stylesheet in dev tools but now that only changes the current component.
Edit: I get the widget / embedable use case but fear that it won't just be used for that.
[1] e.g. Chrome's new material design bookmarks manager that shows far less bookmarks per page than the old design.
Great write up. Can a web component author create one in such a way that the inner shadow dom styles ARE editable/styleable by the outer or person implementing the custom component?
Yeah, I have the similar need. I want to use <slot> mechanism, so I need shadow DOM, but I'd like to re-use styles, so that they don't need to be copied to each instance of the component. Aside from complicating things, it seems wasteful. It should be possible to use styles from the document's CSS to style the innards of a web component.
I'm still learning, and I'm still missing solution to this.
I know about var(--custom-prop), but that's limited, and still doesn't help with the waste of useless duplication of styles.
What I've done is kinda standardized the solution. I've made all my elements listen for a template tag in the html page that contains <link> tags to the stylesheets I use globally.
<template id="x-global-styles">
<link rel="stylesheet" href="some/sheet.css" />
</template>
Kinda like that.
You can use prefetch in the main header to get all your styles in one shot, before page load, if you want.
Then I make my element, if the template is found, pump the innards of the template into itself so all my styles are available.
I use it in conjuction with tailwind so I can write atomic classes and include my atomic css with every element I desire.
From what I can tell, for the most part, my styles don't get reloaded every time. I could be wrong. They seem to get prefetched, if I use a prefetch, or loaded once, then cached. It seems that no matter how many elements I have on the page there are no external calls to get the stylesheet every time. One and done.
Correct me if I'm wrong here. It's just something I fiddled around with.
Very interesting! Thank you. I didn't realize you can use <link> inside web component. But it makes sense!
I read some more, and I reaized that it's probably meant to be that every component has its own small piece of CSS independent of the rest, so that you can use :host, and all the other trickery and so that least amount of CSS per component needs to be parsed and processed.
So I ended up writing a small pre-processor, that converts sass files into a js file with a variables containing styles for each component (like BUTTON_CSS, DIALOG_CSS, SPLIT_LAYOUT_CSS). I just hope that there's some optimization in the browser, such that when the same <style> content is used in multiple instances of the component, it is parsed/processed only once and the results cached for the other instances.
JavaScript is pass-by-reference for all Objects and Arrays. Value types are pass-by-value.
let obj = {a: 1}
function foo(arg) {
return obj === arg;
}
foo(obj) // true
The === operator operates on object not by comparing their value, but by comparing their memory reference [1]. A function argument variable can be reassigned using = in the function body, but that changes which location in memory the reference points to and isn't somehow "proof" of pass-by-value.
Current openings are posted at https://careers.mozilla.org/. There should be a steady trickle of opportunities as 2018 budgeting wraps up and requests for headcount get approved over the coming weeks and months.
We do most of our work in the open, so there's a wealth of information you can gather before applying for a role or interviewing. Lurking on mailing lists, reading Bugzilla, following GitHub repos, etc. are all great ways to become familiar with how Mozilla works, the challenges we face, and where you'd best be able to have an impact.
Working at Moz is usually nice, until it's not anymore for reasons that have nothing to do with how well you perform.
Examples: working from the wrong office (go tell the 70 people fired in Taipei that there will be a steady trickle of opportunities) or under the wrong VP. MoCo is in many aspects a company like any other, with its fair share of Dilbert worthy moments.
Thanks! I was browsing a few days ago and applied to work on Telemetry in Firefox and ML Engineering at Pocket. A lot of the work being done with respect to the Quantam initiatives seems interesting, but I didn't really see anything related to the core browser. Anyway, thanks a lot for the info.
I came to it from the web development world, and after getting into speaking transferred internally onto our DevRel team. We're a small team- we encourage any Mozilla employee to speak about their own work if they want, so there's only a few of us for whom it's a full-time job.
Since we're a small team, it's pretty uncommon for a specifically devrel role to open up, but the sibling reply from my teammate callahad is spot-on for how to get involved with Mozilla and Firefox!
The new version we are working on (and briefly mentioned) is based on choo[0] with the editor provided code-mirror[1] and ot-delta[2] from quill with some custom (and soon to be open sourced) glue code to make them work together.
I've floated the idea of allowing various video formats in <source> for the <picture> element. Would allow for the right codec to be selected, and would easily allow for a <img src="foo.gif"> as the final fallback. Might be worth pushing on more.
Don't know if you need a spec change since this is technically now supported in Safari TP. (See the example) Really it's up to the browser to decide if it wants to use the media type or not.
Firefox is Mozilla's flagship, and the largest by far way in which we achieve our mission, but our goal is a healthy and open internet.
Additionally, this is a great way to determine whether something like this would work well as an in-browser feature, and we've built it in such a way that it works in more browsers than just Firefox on day one.
We didn't throw away Fira Sans, which is the typeface of Firefox. However, we wanted to update the Mozilla brand apart from the Firefox brand, and so Zilla Slab was commissioned.
Quick breakdown of what's going on here (I work at Mozilla, and have worked on the Add-ons site in the past):
The "Get Add-ons" view in Firefox is an iframe to a page hosted by addons.mozilla.org. AMO, as all Mozilla sites, use GA to collect aggregate visitor statistics. We negotiated a special contract with Google [1] to only collect a subset of data and that that data is only used for statistical purposes.
Google Analytics is only loaded when this view is loaded, and is not otherwise "inside" Firefox. I filed an issue [2] to make sure that our privacy policy is linked from the Get Add-ons view so users can be better informed.
Mozilla tries to walk a very thin wire to ensure that we have the data we need to make sure our products are working properly without being intrusive, and to let concerned users opt-out of even that baseline data collection.
Please don't hide behind technical details. If click something in the browser and it causes Google to be notified, then you have send data about me to Google. Without my consent.
privacy policy is linked from the Get Add-ons view
Nobody reads those and you know it. The reason people use Firefox is to not get tracked by Google.
Honestly, you hugely fucked up with this one. You lost a massive amount of trust with me that took years to grow.
> Nobody reads those and you know it. The reason people use Firefox is to not get tracked by Google.
If you care about privacy, blind trust is never something you should have.
This has all the trappings of a mistake to me. A group of developers responsible for developing one area (the add-ons page), was not considering the impact it might have on another (the browser developers). Perhaps they should find a different solution, but it rings hollow to argue that a privacy conscious user shouldn't be expected to have read the privacy policy.
The TOR devs are fixing this part in their browser, and their comment was:
> Disallow `about:addons` unless the extensions directory is volatile, because regardless of what Mozilla PR says about respecting privacy, loading Google Analytics in a page that gets loaded as an IFRAME as part of an `about:` internal page, is anything but.
Check that issue again. Before you posted this they agreed and pushed the issue to the add-ons team. Do not track should turn off Analytics.
But that's not my point. As I said, they could well be wrong, but it's over the top to argue that it's Mozilla's fault for disclosing this in the privacy policy (which apparently no one reads). If you are so privacy conscious that this bothers you that much, the privacy policy should be required reading.
> If you are so privacy conscious that this bothers you that much, the privacy policy should be required reading.
No, this is something that by law I have to be informed about. And Mozilla has a reputation of working for their users, so I actually trusted them.
I do agree with you after this, the trust was misplaced, Mozilla is not any better than Google, NSA, MfS/Stasi or GeStaPo, just not giving a single fuck about privacy, but I did trust them before this, and so did many others.
In fact, people only used Mozilla products because of this trust.
There goes yet another example of Goodwin's law in action, but I'm not so glad for the arguably rash, overly emotional, and definitely not balanced analogy.
May I suggest that Mozilla stops walking a "very thin line" between telemetry and user privacy and instead walks beside a very thick line, on the side of user privacy. This incident has proven how easy it is to step off a very thin line into territory that your users are disgusted by.
Choose to walk the thick line and even if you stumble, you will not fall.
That’s all fine and nice, but how did Mozilla Legal approve this in the first place?
It’s obvious this violates both the so-called "Cookie Law" and the Google Analytics ToS, as both require any page with tracking to specifically tell the user that they will track the user. And the so-called "Cookie Law" goes even further, and requires it to be directly done in a modal.
How did Mozilla, a company saying they fight for privacy, approve something that does not even meet the absolute minimum bar for privacy, the actual privacy laws?
It's not "obvious" that it violates either of those.
The general consensus is that normal GA tracking alone does not meet the standards to trigger either the EU or the stricter Dutch cookie notification requirements since they are using first-party cookies not tied to PII and don't follow you across sites. And that's assuming a standard GA snippet, not the smaller subset of data Mozilla is collecting here.
And the GA ToS require you to have a privacy policy and to make users aware of it. It doesn't require a link on every page. You already agreed to the Mozilla privacy policy as part of the Firefox install process, right?
The general consensus is that normal GA tracking alone does not meet the standards to trigger either the EU or the stricter Dutch cookie notification requirements since they are using first-party cookies not tied to PII and don't follow you across sites
Do you have a good reference for this? Especially the "don't follow you across sites" seems weird as Google will end up collecting hits from the same IP/browser/etc combo across sites, which trivially allows following.
Found a source for this opinion. Here [1] are instructions from the Dutch Government's "Personal Data Authority" on setting up GA in compliance with their laws in a way that does (did?) not require an explicit notice. See [2] for an explanation in english
Opt-in via an explicit dialog, and, most importantly, you have to give the user the ability to select "no" and still use your website (in which case you aren’t allowed to do any tracking).
I don't know what firefox addon pages does (and i see they have a special arrangement) and am not taking sides but for IP at least there is an option partially scrub it before it gets to disk at Google.
> The general consensus is that normal GA tracking alone does not meet the standards to trigger either the EU or the stricter Dutch cookie notification requirements since they are using first-party cookies not tied to PII and don't follow you across sites
I don't know about following you across sites, but "PII" is a US legal term, so I highly doubt it's a determiner in applying EU law. GA may not collect PII under US law, but it does fall into EU data protection compliance.
The problem in the EU is the system of enforcement. EU directives require member states to legislate individually, and to enforce their own legislation individually. If that enforcement is deficient, the case can be taken to the ECJ on an individual basis (at possibly significant cost). This doesn't work. Which has motivated the creation of GDPR[0], but unfortunately this doesn't come into play until 2018
I'm not sure what the "Mozilla Legal" process is, but this thread[0] from 2012 seems to be a recurring source of authority on decision-making around this, from my reading of Bugzilla.
This is what tofumatt was referring to when closing this Github thread.
