Recommended Posts

I've got a little question, well two.

Is it possible to change the bookmarks font size and those separators ?.

And if it is possible to change the separators , is it also possible to use an img for them ?.

Thanks! :D

( Awesome thread btw, give me a lot of ideas to play with ).

Just curious because I'm rather new to all this css stuff

Is there any advantage of border-color: transparent over border: none?

Can't see any difference between our code snippets.

border:none completely removes the border while border-color:transparent maintains the border while making it transparent.

Basically you lose the width of the border if you remove it completely.

border is shorthand for border-style/width/color, so you're setting the style to "none" which removes the border completely.

border: none is the same as border-style: none

border:none completely removes the border while border-color:transparent maintains the border while making it transparent.

Basically you lose the width of the border if you remove it completely.

border is shorthand for border-style/width/color, so you're setting the style to "none" which removes the border completely.

border: none is the same as border-style: none

Thanks

Good explanation :)

I am trying to update this style for Firefox 4.0 RC but I have a problem.

http://userstyles.org/styles/40211/

Some AppMenu items without "iconic=true" attribute can't be styled as an iconic menu, such as appmenu_newTab (New Tab), #appmenu_customize (Options), #appmenu_help (Help).

I tried the usual

-moz-binding:url("chrome://global/content/bindings/menu.xml#menuitem-iconic-noaccel")

to add the icon, but it didn't work.

so I tried all possible bindings I could think of, nothing worked.

any ideas? please!

I am trying to update this style for Firefox 4.0 RC but I have a problem.

http://userstyles.org/styles/40211/

Some AppMenu items without "iconic=true" attribute can't be styled as an iconic menu, such as appmenu_newTab (New Tab), #appmenu_customize (Options), #appmenu_help (Help).

I tried the usual

-moz-binding:url("chrome://global/content/bindings/menu.xml#menuitem-iconic-noaccel")

to add the icon, but it didn't work.

so I tried all possible bindings I could think of, nothing worked.

any ideas? please!

adding .splitmenu-menuitem to

menuitem[label]:not(.searchbar-engine-menuitem)
{-moz-binding:url("chrome://global/content/bindings/menu.xml#menuitem-iconic-noaccel")!important}

will make those three icons show, but you'll still have to adjust margins/padding for alignment

Hi

I'm using this extension https://addons.mozilla.org/pl/firefox/addon/extended-statusbar/ to show load speed and other loading values, like You can see on screen, bar is quite long and infos are only in 1/3 parts of length:

post-375134-0-18344800-1300375843.jpg

So I was wonder if there is possibility to change this bar length to red line and make it bit flexible, so if there is more infos, bar will be bit longer or shorter.

lol, I hope it is clear?

Can some one help me fix this code so it's updated for Firefox 4? It was made way back in Firefox 2 I think when app tabs didn't exist. :laugh:

Right now it works just fine but it widens the app tabs as well and that sort of breaks things:

@-moz-document url("chrome://browser/content/browser.xul") {
tab[selected="true"] {
min-width: 250px !important;
}
tab:not([selected="true"]) {
max-width: 150px !important;
}
/* comment the following if you find the resize on hover bothersome */
tab:not([selected="true"]):hover {
min-width: 250px !important;
}
}

Also, does anyone know about using gdipp.dll with Firefox 4? I currently only have the 64-bit version installed but I read that only works with 64-bit programs (oddly enough..) and I would need to install the x86 version to make it work with non 64-bit programs like firefox. If it can eve work with firefox that is.

Can some one help me fix this code so it's updated for Firefox 4? It was made way back in Firefox 2 I think when app tabs didn't exist. :laugh:

Right now it works just fine but it widens the app tabs as well and that sort of breaks things:

@-moz-document url("chrome://browser/content/browser.xul") {
tab[selected="true"] {
min-width: 250px !important;
}
tab:not([selected="true"]) {
max-width: 150px !important;
}
/* comment the following if you find the resize on hover bothersome */
tab:not([selected="true"]):hover {
min-width: 250px !important;
}
}

Also, does anyone know about using gdipp.dll with Firefox 4? I currently only have the 64-bit version installed but I read that only works with 64-bit programs (oddly enough..) and I would need to install the x86 version to make it work with non 64-bit programs like firefox. If it can eve work with firefox that is.

So you want to avoid that this code is affecting app tabs right?

If that is what you mean try this:

tab:not([pinned])[selected="true"] {
min-width: 250px !important;
}
tab:not([pinned]):not([selected="true"]) {
max-width: 150px !important;
}
/* comment the following if you find the resize on hover bothersome */
tab:not([pinned]):not([selected="true"]):hover {
min-width: 250px !important;
}

So you don't want this code to work for app tabs right?

If this is what you mean try this:

tab:not([pinned])[selected="true"] {
min-width: 250px !important;
}
tab:not([pinned]):not([selected="true"]) {
max-width: 150px !important;
}
/* comment the following if you find the resize on hover bothersome */
tab:not([pinned]):not([selected="true"]):hover {
min-width: 250px !important;
}

That works but it seems to restrict tabs to the min-width until the tab is hovered.

Edit: fixed.. I just removed the min-width part. Thanks! And welcome to Neowin! :yes:

That works but it seems to restrict tabs to the min-width until the tab is hovered.

Edit: fixed.. I just removed the min-width part. Thanks! And welcome to Neowin! :yes:

Thank you :)

Isn't this code supposed to restrict the min-width?

Make sure to check tab overflow when you take that part out.

Looks weird when it gets 250px on hover and then jumps back to the overflow-width once you select it.

Or do you mean something else?

Edit: found a bug in that code. When you close a tab while its hovered but not selected it gets a "ghost tab" and just leaves an empty space. This works for me (still with the min-width part in it)

tab:not([pinned])[selected="true"] {
	min-width: 250px !important;
}

tab:not([pinned]):not([selected="true"]) {
	max-width: 150px !important;
}

tab:not([fadein]):not([pinned]):not([selected="true"]) {
 	max-width: 1px !important;
 	min-width: 1px !important;
}

/* comment the following if you find the resize on hover bothersome */
	tab:not([pinned]):not([selected="true"]):hover {
	min-width: 250px !important;
}

Edit 2: close animation is choppy for a reason i can't see at the moment

I was getting the ghost tabs and choppy close animation as well. Anyways, thanks again! I'll try that new code.

I have NO clue why this fixed it but this is working for me.

(Again with min-width because I'm not sure what you meant)

tab:not([pinned])[selected="true"] {
        min-width: 250px !important;
}

tab:not([pinned]):not([selected="true"]) {
        max-width: 150px !important;
}

tab:not([fadein]):not([selected="true"]) {
        max-width: 1px !important;
        min-width: 1px !important;
}

/* comment the following if you find the resize on hover bothersome */
        tab[fadein]:not([pinned]):not([selected="true"]):hover {
        min-width: 250px !important;
}

It's hard to describe exactly. :laugh:

I wanted the tab width to follow normal behavior but not shrink past the 150px width no matter what. Not be restricted to 150px until it's hovered. I hope that makes sense because I'm not sure exactly how to describe what I was trying to achieve.

So until the tab bar is filled up the tab width would stay at 250px and then shrink but not get smaller than 150px??? I don't know, again I hope it makes sense because I'm just confusing myself, now. :rofl:

It's hard to describe exactly. :laugh:

I wanted the tab width to follow normal behavior but not shrink past the 150px width no matter what. Not be restricted to 150px until it's hovered. I hope that makes sense because I'm not sure exactly how to describe what I was trying to achieve.

So until the tab bar is filled up the tab width would stay at 250px and then shrink but not get smaller than 150px??? I don't know, again I hope it makes sense because I'm just confusing myself, now. :rofl:

So ALL tabs are supposed to be 250px until overflow

With overflow only the selected tab is supposed to be 250px, all other tabs normal behavior but restricted to min 150px?

Again: I don't see why tab animation got fixed but its working for me

tab:not([pinned])[selected="true"] {
        min-width: 250px !important;
}

tab:not([pinned]):not([selected="true"]) {
        min-width: 150px !important;
}

tab:not([fadein]):not([selected="true"]) {
        max-width: 1px !important;
        min-width: 1px !important;
}

/* comment the following if you find the resize on hover bothersome */
        tab[fadein]:not([pinned]):not([selected="true"]):hover {
        min-width: 250px !important;
}

tab:not([pinned])[selected="true"] {
        min-width: 250px !important;
}

tab:not([pinned]):not([selected="true"]) {
        min-width: 150px !important;
}

tab:not([fadein]):not([selected="true"]) {
        max-width: 1px !important;
        min-width: 1px !important;
}

/* comment the following if you find the resize on hover bothersome */
        tab[fadein]:not([pinned]):not([selected="true"]):hover {
        min-width: 250px !important;
}

Can't edit my post so..yeah..new post. I found a flaw in this. It breaks the tabs in the stratiform addon. :wacko:

Can't edit my post so..yeah..new post. I found a flaw in this. It breaks the tabs in the stratiform addon. :wacko:

What exactly are you trying to do? Do you want the selected tab to be larger than the inactive ones?

What exactly are you trying to do? Do you want the selected tab to be larger than the inactive ones?

I was trying to make it so that when I had a lot of tabs open the selected tab (but not pinned tabs) would be the full 250px width, and also the hovered tab resizes to full width as well so I can see the name. Not a huge deal if it can't be made to work without breaking other addons.

I was trying to make it so that when I had a lot of tabs open the selected tab (but not pinned tabs) would be the full 250px width, and also the hovered tab resizes to full width as well so I can see the name. Not a huge deal if it can't be made to work without breaking other addons.

I see. Give this a try:

.tabbrowser-tab[fadein] {
  max-width: 150px !important;
}

.tabbrowser-tab[fadein]:not([pinned])[selected],
.tabbrowser-tab[fadein]:not([pinned]):hover {
  width: 250px !important;
  max-width: 250px !important;
}

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • It's amazing that anyone still uses this bloated trash.
    • @Sayan...I have defended you at various points as I hope you know. This headline however is utter trash...shame on you sir!
    • An actual cosmic "Eye of Sauron" had been looking straight at us all along by Sayan Sen Image by Kovin P. Vasquez via Pexels | Not representative An international team of researchers has solved a long-standing mystery surrounding a distant blazar known as PKS 1424+240, helping explain why it produces some of the brightest high-energy gamma rays and cosmic neutrinos ever observed despite appearing to have a relatively slow-moving jet. The findings were published on June 6 in Astronomy & Astrophysics Letters. The study addresses a broader challenge in astrophysics: understanding how extreme cosmic objects accelerate particles to very high energies and produce very high-energy (VHE) photons and neutrinos. PKS 1424+240 is located billions of light-years from Earth. It has attracted attention for years because it is both a powerful source of VHE gamma rays and the brightest known neutrino-emitting blazar in the sky, according to observations by the IceCube Neutrino Observatory. It is also associated with one of the strongest peaks in IceCube's nine-year neutrino sky map A blazar is a type of active galactic nucleus powered by a supermassive black hole that pulls in surrounding matter and launches jets of plasma moving close to the speed of light. What makes blazars unique is their orientation. One of their jets points almost directly toward Earth, making them appear exceptionally bright across the electromagnetic spectrum and allowing scientists to study some of the most extreme physical processes in the Universe. The scientists exclaimed it's like the 'Eye of Sauron' in deep space. Usually, the brightest gamma-ray-emitting blazars are expected to have jets that appear to move very quickly. However, radio observations of PKS 1424+240 suggested that its jet was moving much more slowly, creating a contradiction that became part of a long-running problem known as the "Doppler factor crisis." To investigate, researchers analyzed 15 years of observations from the Very Long Baseline Array (VLBA), a network of 10 radio antennas spread across the continental United States, Hawaii and St. Croix. Using a technique called Very Long Baseline Interferometry (VLBI), astronomers combine signals from widely separated radio telescopes to create a virtual Earth-sized telescope capable of revealing extremely fine details. The team combined 42 polarization-sensitive radio images collected between 2009 and 2025, creating a much deeper and more detailed view of the jet than had previously been possible. The observations were carried out as part of MOJAVE (Monitoring Of Jets in Active galactic nuclei with VLBA Experiments), a long-running program that studies the brightness, polarization and magnetic field structures of jets produced by active galaxies. The project aims to better understand how activity near supermassive black holes is linked to high-energy radiation and neutrino emission. “When we reconstructed the image, it looked absolutely stunning,” said Yuri Kovalev, lead author of the study and Principal Investigator of the European Research Council-funded MuSES project at the Max Planck Institute for Radio Astronomy. “We have never seen anything quite like it — a near-perfect toroidal magnetic field with a jet, pointing straight at us.” The image revealed an unusual geometry. The researchers found that Earth lies almost directly in line with the jet, with a viewing angle of less than 0.6 degrees. In simple terms, astronomers are looking almost straight down the jet. This turned out to be the key to the mystery. Because the jet is aimed almost directly at Earth, a relativistic effect called Doppler boosting dramatically increases its apparent brightness. The study found that this effect boosts the emission by a factor of about 30 while also making the jet appear slower than it actually is. “This alignment causes a boost in brightness by a factor of 30 or more,” said Jack Livingston, a co-author at the Max Planck Institute for Radio Astronomy. “At the same time, the jet appears to move slowly due to projection effects — a classic optical illusion.” The nearly head-on view also gave scientists a rare look at the jet's magnetic field. Using polarized radio signals, they detected a clear toroidal, or doughnut-shaped, magnetic field component. The observations suggest the jet carries an electric current and that its magnetic field helps launch, shape and stabilize the flow of plasma. Researchers believe this magnetic structure may also play a key role in accelerating particles to energies high enough to produce both gamma rays and neutrinos. “Solving this puzzle confirms that active galactic nuclei with supermassive black holes are not only powerful accelerators of electrons, but also of protons — the origin of the observed high-energy neutrinos,” Kovalev said. The research was conducted under the MuSES (Multi-messenger Studies of Energetic Sources) project, which investigates how active galactic nuclei accelerate particles and generate different cosmic signals, including light and neutrinos. Scientists say understanding how protons are accelerated and linked to neutrino production remains one of the major unanswered questions in astrophysics. The findings help explain why some blazars can appear to have slow jets while still producing extremely bright high-energy emissions. More broadly, the study strengthens the link between relativistic jets, magnetic fields, gamma rays and high-energy neutrinos. Researchers say the results provide new clues about how some of the Universe's most powerful natural particle accelerators work and offer important insights for multimessenger astronomy, which combines different types of cosmic signals to study extreme events in space. Source: European Research Council, EDP Sciences This article was generated with some help from AI and reviewed by an editor. Under Section 107 of the Copyright Act 1976, this material is used for the purpose of news reporting. Fair use is a use permitted by copyright statute that might otherwise be infringing.
    • Gotenks98 is right... Outlook (new) is absolute trash. Doesn't Mozilla have an Enterprise Version of Firebird?
  • Recent Achievements

    • One Month Later
      lamborghiniv10 earned a badge
      One Month Later
    • Week One Done
      lamborghiniv10 earned a badge
      Week One Done
    • Reacting Well
      X-No-file earned a badge
      Reacting Well
    • One Month Later
      pestcontrol46 earned a badge
      One Month Later
    • Week One Done
      pestcontrol46 earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      510
    2. 2
      PsYcHoKiLLa
      273
    3. 3
      Skyfrog
      75
    4. 4
      +Edouard
      72
    5. 5
      FloatingFatMan
      69
  • Tell a friend

    Love Neowin? Tell a friend!