Hi Bernhard, Ivo, *, On Fri, Dec 17, 2010 at 12:14 PM, Bernhard Dippold <bernh...@familie-dippold.at> wrote: > CC'ing the website list because this might be interesting for images on our > LibO website too.
It definitely is :-) > Ivan M. schrieb: >> On Fri, Dec 17, 2010 at 1:33 PM, Bernhard Dippold >> <bernh...@familie-dippold.at> wrote: >> >> Here is the demo: >> http://patentpending.co.nz/libreoffice/buttons/index.html Nice :-) >> You can see the HTML/CSS source to see how it works (but getting the >> image right in Inkscape was a huge pain). Of course, I can explain if >> anyone's interested. Yes, it would be interested to have a kind of howto for this, but only if you don't have other stuff to do right now. I would have used gimp probably, but I don't know it very well either. > Even if I'm not an expert in HTML/CSS I understand the advantages of this > approach: > > - just one image > http://patentpending.co.nz/libreoffice/buttons/images/button.png > (plus the document symbol image where it is necessary) Yes, definitely easier to maintain/update. > - images don't have to be replaced on hover, it's just a different > text/background decoration by quite a simple CSS: > http://patentpending.co.nz/libreoffice/buttons/style.css Yes, although when using spriting, a different image on hover wouldn't be much of a problem. The real improvement is to not having the text encoded within the image. For special buttons this can be done of course, but then the source should be available (xcf, whatever layered format), so that when the text needs to be changed you can just update the text-layer and resave) > I could imagine, that this might work for the navigation tabs on the LibO > website too, especially if a second horizontal navigation line (visible on > mouse over the first level nav) would be considered. Regarding this: I turned the tabs on pumbaa from using fixed-width buttons to sprited approach with dynamic width: http://pumbaa.ooodev.org:7780/ http://pumbaa.ooodev.org:7780/themes/tdf/images/nav_sprites.png (in this case a button background consits of two elements: main background and the corner part) > How do you avoid the text leaving the button because of line break or > different standard fonts (other height or width than the font you used)? The same technique could be applied to the button, i.e. have the buttons resize horizontally to fit the text. Scaling vertically is a little harder, you need to split it to top/bottom and have a middle area (possible with the buttons). > Does this needs a fixed not-to-be-replaced font in the page definition? No - it is a matter of efforts though. It took me quite a while until I got the css right for the hover buttons, esp for the ones on the sidenavbar, where I wanted the text to run into the cornerpart, and not have the corner part as void space. But it is doable. > Here at my system (SeaMonkey 2.0.11 on Ubuntu 10.10) the lower button's text > is too broad for the button - this should be avoided: > http://imagebin.org/128305 Easiest intermediate solution is to prevent line-wrap (using css) and just cut off the text horizontally (but add corresponding alt/title attribute so that one can read the full text on mouse-over) ciao Christian -- Unsubscribe instructions: E-mail to design+h...@libreoffice.org List archive: http://www.libreoffice.org/lists/design/ *** All posts to this list are publicly archived for eternity ***
