Re: [css-d] General question

[Dave Sherohman]

Do note that this is an often-debated philosophical point.  I won't go
into the reasons, since I don't want to start an off-topic argument, but
perhaps the reason it hasn't been "fixed" is because the list admins
don't consider the current behavior to be broken.

(If you *really* care about the reasons, google "reply-to munging" and
the first few results should be "considered harmful" and "considered
useful" articles which lay out the major points on each side.)

On Sat, Aug 21, 2010 at 08:04:23PM -0700, Jay Tanna wrote:
> Yes that is exactly what I normally do.  This means the OP gets two messages 
> but we can't help it unless you remove the individual's email from To: item.  
> This should be fixed but nobody seems to have complained about it up to now.
> 
> 
> --- On Sun, 22/8/10, Cheryl Smith  wrote:
> 
> 
> > When I reply to an email, I get the
> > individual's name instead of the list. Do I need to select
> > reply all in which case the individual and the list will be
> > sent a message?
> >  
> 
> 
> 
>   
> __
> css-discuss [cs...@lists.css-discuss.org]
> http://www.css-discuss.org/mailman/listinfo/css-d
> List wiki/FAQ -- http://css-discuss.incutio.com/
> List policies -- http://css-discuss.org/policies.html
> Supported by evolt.org -- http://www.evolt.org/help_support_evolt/


-- 
Dave Sherohman
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] Changes how (some) browsers handle the a:visited pseudo-class

[Dave Sherohman]

On Sun, Apr 11, 2010 at 05:13:44PM -0400, Bob Rosenberg wrote:
> Also IMO the feature should be OFF unless the user SPECIFICALLY 
> activates it (not set to ON requiring the user to turn it off to 
> cripple it).
> 
> IOW: If you want to have the Browser play Net Nanny then require the 
> user to give permission not do it behind the user's back until the 
> browser is told to stop messing with the page/code and display it as 
> supplied.

And I disagree entirely.  Especially for something so minor as the
ability to make visited links look nothing at all like unvisited
links[1], software should be secure by default and require users to
deliberately choose to enable less secure modes of operation, not the
other way around.


[1] The changes described still allow you to visually distinguish
visited vs. unvisited links, provided that they still look basically the
same.  I don't see losing the ability to shrink visited links to a
microscopic font or replace their backgrounds with biohazard warnings to
be any big loss.  Certainly not a big enough loss to warrant knowingly
choosing a default behavior which is known to put users' privacy at
risk.

-- 
Dave Sherohman
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] Password Protection

[Dave Sherohman]

On Wed, Aug 26, 2009 at 06:19:10AM -0700, Cristiano Diniz da Silva wrote:
> Don't count on it. You will need a server-side scripting language and
> if you really want some security you will need also a SSL certificate.

Not necessarily.  You can use HTTP-level authentication by just dropping
the right directives into .htaccess and creating a .htpasswd (or
similar) containing the valid user credentials.  This does not require
any server-side programming, but will completely block unauthenticated
users from any access to your page(s).

Application-level authentication, multiple authorization levels (even
just "guest" vs. "logged in"), or simply having an application in the
first place does require server-side programming, though, like you said.

Good point on the SSL also.  Sending passwords across the net in
plaintext isn't exactly the height of security.

-- 
Dave Sherohman
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] Screen resolution?

[Dave Sherohman]

On Thu, Aug 13, 2009 at 10:59:18AM +1200, Richard Mason wrote:
> >> >My question to you is why  a box of 100px equals a inch
> >> measured by a
> >> >ruler and not what I expected 96px?
> >> >
> >> Don't understand the statement.

> I didn't make clear what I meant when I said "I don't understand the 
> statement". I was querying why he would expect a 100px box to be 96px.

You misunderstood what the questioner was expecting.  He didn't mean
that he expected 100px to be 96px.  His question was "My computer is set
to 96DPI, so I expected a 96px line to be one inch when measured by a
ruler, but, instead, 100px is an inch.  Why is that?"

You and I (and a couple others) have already answered that question
quite thoroughly, so there should be no need to answer it again; I just
wanted to clarify that he didn't mean that he expected 100px to be 96px.

Overall, though, I have to agree with one of your later posts:
> but why, generally, would anyone want to do that? A monitor is not a
> sheet of paper and the distance and orientation one reads text on
> paper is quite different to that at which one reads text a screen.

I've never really understood graphics software's obsession with DPI.  As
already noted by someone else in this thread, a 100x100px image saved at
300DPI and a 100x100px image saved at 72DPI are *exactly the same
image*.  There is no difference other than the value of a header field
whose sole purpose is to store the creator's declared DPI-by-fiat and
has no actual effect on how the image is displayed.

But, then, my background is in software development, not print design,
so I think about on-screen image sizing purely in terms of pixels and
find the idea of trying to size things on-screen based on inches or any
other physical measurement to be silly, at best.  For someone coming
from a background in print design, I can certainly understand why there
would be a tendency to think in terms of physical units (even if it is
nonsensical when talking about on-screen display by the general public).

-- 
Dave Sherohman
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] Screen resolution?

[Dave Sherohman]

On Tue, Aug 11, 2009 at 11:11:04AM +0200, Michal Suchanek wrote:
> Even if points are not precise unit in CSS because of browser and OS
> problems most users can set their DPI in their preferences if it is
> not automatically determined from screen size (unless they are running
> a particularly abhorrent browser + OS combination).
> 
> Once you set the DPI properly sites designed in points, mm or em
> should be reasonably readable for you.

Not really, at least as far as points/mm are concerned[1], assuming that
by "properly" you mean "determined from screen size".

Setting your browser/OS DPI setting to match the physical DPI of your
display means that 12pt text on the screen will be the same size as 12pt
text on a printed page.  However, this does not mean that the text will
be readable if, say, the screen is an HDTV and you're sitting on the far
side of the room.

I would argue that display DPI should be based on what the user finds
most usable in their particular environment and physical screen DPI
should be completely ignored except in a handful of special cases, such
as computers being used for print design, where it's actually important
to be able to clearly relate the screen display to the size of a
physical object.  But, then, I would also argue that, aside from those
few special cases, DPI should be abandoned when dealing with computer
displays, as trying to relate on-screen display sizes to physical sizes
is fundamentally misguided, since you have no way of knowing whether the
user wants ultra-dense display to fit on their iPhone or five-inch-high
text for their gigantic HD rig.


[1] As already mentioned in this thread, modern browsers base em on the
user's default font size, not an actual physical unit, so em-sizing
should work regardless of whether the DPI setting is accurate or not.

-- 
Dave Sherohman
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] Screen resolution?

[Dave Sherohman]

On Tue, Aug 11, 2009 at 04:10:45PM +1000, Alan Gresley wrote:
> 2. The 100px and 75pt boxes are the same size with a 96 DPI setting on a 
>   monitor but also they are exactly 1 inch (using a ruler) in height and 
> width.

...which means that, within the limits of the accuracy of your ruler,
your monitor is actually displaying at 100DPI, regardless of your
operating system's DPI setting.

> 3. When the DPI setting is changed to 120 DPI, the boxes using pts 
> become 125% of their size at 96 DPI.

Correct.  Always remember that monitors operate purely in pixels and
cannot display based on any other unit or size.

The monitor's physical DPI is purely a function of the screen's physical
size and the active display resolution (e.g., 1024x786, 800x600, etc.).
The DPI setting in your operating system is a pretend value, as in "the
operating system will pretend your monitor is 96DPI or 120DPI, since it
doesn't know the actual physical DPI", which is used to convert physical
measurements (such as inches or points) into pixels so that the monitor
can display them.  When you change the DPI setting, the ratio used for
that conversion changes, so 75pt or 1" will be translated into a
different number of pixels.

> 4. The boxes using pixels are the same size and the box of 100px at 
> either 96 or 120 DPI still equals exactly 1 inch (using a ruler) in 
> height and width.

Yep.  100px is already in pixels, so it can be displayed directly
without having to use the DPI setting to convert its size into pixels
first.

> My question to you is why  a box of 100px equals a inch measured by a 
> ruler and not what I expected 96px?

Because your monitor isn't actually 96DPI.

> BTW, I thought the higher DPI setting would make the text smaller. I now 
> discover the reverse is true where the text and chrome of the browser is 
> larger.

At 96DPI, the operating system converts a 1" line into 96 pixels.

At 120DPI, the operating system converts a 1" line into 120 pixels.

The actual pixels on the screen are the same size regardless - remember
that their size is purely a factor of the physical screen size and the
active display resolution, not of the DPI setting - so the (supposedly)
1" line becomes 24 pixels longer when you change from 96DPI to 120DPI.
(And note that 24 is 25% of 96, matching the 25% size increase that you
noted in your 3rd observation.)

-- 
Dave Sherohman
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] Screen resolution?

[Dave Sherohman]

On Mon, Aug 10, 2009 at 11:24:40AM -0700, Theresa Mesa wrote:
> Interestingly enough, as a learning exercise, I opened an image in  
> Photoshop, set the image size to 300px x 454px. File size was 399.3K,  
> regardless of what PPI it was. You were correct, Mike.
> 
> Then I saved the image in Photoshop's "Save for Web and Devices."  
> Image quality, jpeg, maximum (100). Image size, 300x454. File size,  
> 93.25K. When I open that image that I saved from "Web and Devices" to  
> my desktop, it's 399K. But "Save for Web and Devices" just told me the  
> image was 93K.
> 
> Now we're getting out of the realm of CSS, so I'll take this  
> interesting question to Adobe's forums.

That's an easy one...  300px x 454px x 3 bytes/px = 408,600px, or
399.0234k of actual, uncompressed image data.  Add some headers and
metadata, and 399.3k sounds about right as a final uncompressed file
size.

"Save for Web and Devices" applied jpeg compression to the image,
producing a file size smaller than the actual uncompressed image size,
but it still has to be decompressed in memory back up to its full 399k
to be displayed.

-- 
Dave Sherohman
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] Percentage width for input type=file

[Dave Sherohman]

On Tue, Jun 30, 2009 at 05:57:19PM +0100, Nick Fitzsimons wrote:
> Bear in mind that some browsers, especially on non-Windows platforms,
> have file inputs that don't look anything like you're probably
> expecting - i.e. they aren't a text input field with a button next to
> it.

The examples on the pages you linked were pretty much what I was
expecting.  The Safari example you pointed out didn't really differ in
any substantial way, it just doesn't draw a recessed box around the area
where the selected filename is displayed.

> That's the way it was implemented in the earliest browsers to
> support forms (early '90s), but there's no reason why it has to be
> that way.

Indeed.  All the more reason to make use of the browser's default
behaviour rather than forcing a non-standard appearance onto it and
violating the user's expectations for that OS/browser combination.

> I think it's probably going to
> have a lot of white space around its two components...

Much better, IMO, to have a lot of whitespace around the two components
than a 750px wide column containing:

input type=text at 100% width making it 725px or so wide___
input type=file*
input type=text at 100% width making it 725px or so wide___

* Also 100% width, but displayed as if it were the default size,
scrunched up against the margin despite this.

(And, yes, I realize that arguments could be made that perhaps making
the type=text inputs 100% width and letting them be 725px wide is a bad
idea in the first place, but that's a design discussion and I asked a
technical question, not a design question.)

-- 
Dave Sherohman
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

[css-d] Percentage width for input type=file

[Dave Sherohman]

Hey, all!

I've got a file upload control that I'd like to see fill available space
and google's not finding anything for me that looks terribly useful
other than lots of people saying that file input controls and CSS don't
get along very well.

The one thing I've found that comes close is a reminder that you can set
size=50 to make it 50 characters wide, but (at least in FF) the
control's size parameter only recognizes character counts - size=100,
size=100px, and size=100% all produce exactly the same appearance.  This
is not, therefore, suitable for use in layouts which don't rely on a
fixed width.

Pretty much everything else I've found is focused on replacing the
default "browse" button with a different button, which is not what I'm
trying to do.  (On the contrary, I'm quite happy with the default browse
button.  Adhering to the host operating system's general look and feel
in that type of UI element is, IMO, a good thing.)  Most such solutions
also require a bit of javascript to copy the file path from an invisible
file select control into their visible pseudo-file-control, which feels
to me like a bad javascript dependency - if the user has javascript
disabled and selects a file, it will look like nothing happened, which
is not my idea of graceful degradation.

Are there any other options for creating the equivalent of ""?

-- 
Dave Sherohman
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] What's your preference -- fluid, elastic, or fixed?

[Dave Sherohman]

On Fri, Jun 05, 2009 at 07:21:27AM -0700, Glow wrote:
> one thing I wonder
> about long-term with fluid layouts and increasing screen size is how
> to scale content when you've got someone using a gigantic monitor (can
> you visualize one-line articles stretching across three feet of screen
> real estate?)

That is, IMO, an issue for the user to decide.  If the user chooses to
have a three-foot-wide browser open, then he's also choosing to have
three feet of content.  Given that you or I don't know how far away from
that display he'll be sitting, we're in no position to second-guess
whether that's an appropriate choice for him to have made or not.

If this user is sitting close to his screen and doesn't want to be
turning his head back and forth to take in three feet of horizontal
space, then he also has the option of using a smaller browser window to
constrain the content to a more usable width.

-- 
Dave Sherohman
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] What's your preference -- fluid, elastic, or fixed?

[Dave Sherohman]

On Fri, Jun 05, 2009 at 12:05:35AM -0700, Glow wrote:
> I normally work with fixed layouts because I find that I have more
> control over the ultimate appearance of the design.  But lately I'm
> becoming more interested in fluid or elastic layouts because of their
> greater accessibility.
> 
> So, just out of curiosity -- what's your particular preference and why?

I'm not sure what distinction you make between "fluid" and "elastic", so
I'll just answer "anything but fixed".  Screens are getting both larger
and smaller these days, so any fixed width you may choose will either be
a narrow strip down a widescreen HD display, a morass of horizontal
scrolling on a handheld device, or (more likely) both.

Also keep in mind that HTML/CSS presentation is ultimately decided by
the browser - the user can disable CSS, apply cusom stylesheets to
override your CSS, use a screen reader, etc. - so any "control over the
ultimate appearance" that a fixed width may provide is little more than
an illusion anyhow.

-- 
Dave Sherohman
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] Flowing block elements around floated elements

[Dave Sherohman]

On Fri, May 01, 2009 at 08:50:32PM +0900, Philippe Wittenbergh wrote:
> What is wrong ? The code/style at that url behaves correctly.
> Or is it that you don't want to darker background greys of the  div.bb- 
> quote to be covered by the image ?

It looks like what was wrong was my assumptions.  I assumed that, since
the greys continued all the way to the right, that a longer section of
quoted text would also do so.  Putting in some additional text so that
it was long enough to wrap showed that it wrapped before hitting the
image.

> in that case:
> div.bb-quote {overflow:hidden; }
> would probably 'fix' the issue.

Indeed it did.  Thanks!

-- 
Dave Sherohman
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] Flowing block elements around floated elements

[Dave Sherohman]

On Thu, Apr 30, 2009 at 12:07:50PM +, Bobby Jack wrote:
> Hmm ... that markup and CSS should not behave in the way you describe,
> and doesn't for me (at least, the way I've recreated what I think
> you're describing). Can you post an example? Does this happen for you
> in all browsers?

On closer inspection, the markup turned out to be a bit more complex
than I'd originally expected.  The specific use case is a user avatar
and the rendering of a [quote] block by the drupal BBCode module.

The relevant section of the HTML is:

--- cut here ---

  

  http://www.gravatar.com/avatar/4459bb44e0db5b57cc5e358a71519679?d=identicon&s=85&r=R";
 alt="Dave Sherohman's picture" title="Dave Sherohman's picture"  />

  


Submitted by Dave Sherohman on April 29, 2009 - 22:10


  

  Unknown wrote:
  (quoted text)

  
--- cut here ---

(HTML reformatted manually to make the structure more clear.  I have no
idea why it has two nested div.pictures; I suppose that could be a bug
in the gravatar integration module, but it seems harmless in any case.)

The associated CSS for div.picture and div.bb-quote.* is:

--- cut here ---
.front .picture {
  margin-top:-0.75em;
}
.picture {
  float:right;
}
.bb-quote {
  padding:0.25em 1em;
}
.bb-quote b {
  background-color:#66;
  color:white;
  display:block;
  padding:0 0.25em;
}
.bb-quote blockquote {
  background-color:#EFEFEF;
  border:1px solid #88;
  padding:0 0.25em;
}
--- cut here ---

The link to see it live (for the moment, at least) is
http://sherohman.org/temporal-perspective

So far, I've only looked at this in Firefox 3.0.10 and not verified how
it behaves with other browsers, on the assumption that, if Firefox
doesn't get it right, nothing else will, either.

-- 
Dave Sherohman
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] Flowing block elements around floated elements

[Dave Sherohman]

On Wed, Apr 29, 2009 at 02:27:21PM -0600, Brian Hazelton wrote:
> You can solve this quite easily. Figure out the right margin you need to
> have it end to the left of the image... For example, if the image is
> 200px and is flush with the right side of the content area, and you want
> 10 px of whitespace between the image and the blockquote then add
> margin-right:210px to the blockquote.

This does not meet my definition of "flow around".

When inline elements "flow around" another element, they leave space for
it when it is present and fill that space when the other element is
absent.  I'm trying to get block elements to "flow around" in the same
manner (modulo the detail that block elements must have the same width
over their entire height).

Using the numbers from your example, the blockquote should have a right
margin of 210px if and only if any portion of it is beside the image and
a right margin of 10px if it is not beside the image.

e.g. (b = blockquote, t = non-blockquote text, i = image):

tt  iii
    iii
  
  

ttt
tt
  bbbb
  

-- 
Dave Sherohman
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

[css-d] Flowing block elements around floated elements

[Dave Sherohman]

Is there any way to get block elements to not overlap nearby floated
elements?

In my specific case, I've got a { float: right } image with text beside
it.  Normally, the text flows around the image just fine, but the
inclusion of a  (or, presumably, any other block element)
within the section of text adjacent to the image results in the
 extending right for the full width of the container, going
behind the image.

What can be done to get the  to size itself such that it
does not overlap the image?

-- 
Dave Sherohman
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] Pixel-perfect vertical alignment of horizontal

[Dave Sherohman]

On Wed, Sep 24, 2008 at 06:50:38PM +0200, Gunlaug Sørtun wrote:
> May be a bit difficult to comprehend, but 'background-position : 0 50%;'
> will "automagically" place the image's vertical center exactly at the
> link's vertical center, and that will show.

Interesting...  I was sure that it set the upper left corner, so used
0,0 because that's where I want the image's upper left to start, rather
than halfway down the left side.

However, 0, 50% didn't cause any change either, which leads back to the
conclusion that the background image is fine and it's the /
that's not sitting in quite the right place.

> To exemplify: I use 'background-position : 0 50%;' on nav-links on this
> page...
> 

Thanks for the example.  It looks like I may be able to work out answers
to a couple of other questions (which I haven't asked about yet) by
examining what you've done there.

> Pixels are absolute values that breaks "relative and inherited". Once
> you throw in pixels you "fix" dimensions, and browsers can no longer
> recalculate - even if there's a need for it - as they are locked to
> those pixel-values.
> 
> In most cases we don't declare 'height' on elements at all, and simply
> leave it to the browsers to figure out how high an element must be to
> hold its content - whatever it is. Declaring an element's width is
> usually more than enough.

It seems that I'm going about this all wrong, then, or at least in a
very unusual manner...

The original design which I'm trying to clean up and mostly-duplicate
can be seen at http://nomadnetinc.com/  Aside from the exclusive use of
nested tables for formatting, I also want to get away from the use of
images for the navigation buttons, so that it'll be a little quicker and
easier to add new pages to the menu.

In the original design, the menu is a 30-pixel-high table row with a
30px-high background image, filled with 30px-high images for the nav
links.  In order to maintain (most of) its appearance, the obvious
solution was to stretch the background vertically to fit, but the
results of searching for "css stretch background image" can be largely
summed up with a quote from the first hit, "AFAIK there is no way to
stretch or control the size of a background image using CSS." Trying to
force a fixed height was the only other option I could come up with,
given the color scheme and background images in question.

I actually messed around quite a bit with trying to avoid fixed heights
for everything, but I wasn't able to find a combination which would
cause the 'hover' background to use the full height of the /
rather than clinging tightly around the text and/or sitting at the top
or bottom of the available space.  If I could get it so that div.nav was
the only thing with a fixed height in px, I suspect that would probably
be the best possible solution.

> Font-size and line-height are treated a bit different. Most browsers
> recompute pixel-sized fonts by default - scale the font-size, and IE/win
> can be set to simply ignore font-sizes.
> Not all browsers will recompute line-height though, so serious
> text-overlapping and other "disasters" may occur in IE/win and Opera if
> line-height is declared in pixels.

Nasty...  So then how do you get things to match up with a fixed-height
background image if you can't reliably use fixed height elements?

> > It does make sense to me that the pixel-specified heights may be the
> >  culprit, though, because I've never been able to figure out why a 
> > 14px font + 9px top padding + 9px bottom padding = 30px total (the 
> > height of the ul) instead of 32px...
> 
> Case please - and I would like to know the line-height at play. Numerous
> ways to intentionally or unintentionally "mess up" an element's actual
> dimensions. I do it intentionally all the time.

I was referring to the page under discussion,
http://kuno.sherohman.org/~esper/nomadnetinc.com/ , on which (in Firefox
3/Windows, at least) an  (padding: 9px; line-height: 28px;) in
an  (font-size: 14px; padding: 9px) comes out to the same
height as the owning  (height: 30px).  By my math, the  should be
28px high, the  should be 32, and the  should be 30 instead of
all coming out the same.  (The relevant styles being div.nav a, div.nav
li, and div.nav ul.  div.nav itself is also set to a height of 30px.)

> > There are a ton of articles out there on doing rounded corners, each
> >  apparently using a completely different technique, but a) none of 
> > those which I've looked at directly address arbitrary custom corners 
> > and b) if I need to adapt one of the rounded corner examples to 
> > produce a straight diagnonal division rather than a curve, I would 
> > prefer to start from the accepted 'best' technique if one exists.
> 
> There isn't any "best". We tend to invent, or rather reinvent, methods
> as we go, as we all try to create something a bit "different".

OK, fair enough.  Thanks for the references!

-- 
News aggregation me

Re: [css-d] Pixel-perfect vertical alignment of horizontal

[Dave Sherohman]

On Tue, Sep 23, 2008 at 10:33:11PM +0200, Gunlaug Sørtun wrote:
> Dave Sherohman wrote:
> 
> > http://kuno.sherohman.org/~esper/nomadnetinc.com/
> 
> > The navigation menu is, however, proving problematic.
> 
> > Is it possible to get that to line up properly in all major browsers/
> >  versions/operating systems and, if so, how?

> You can try adding something like...
> 
> div.nav a:hover {background-position : 0 50%;}

I changed the style from

div.nav a:hover { 
  color: #e4923f; 
  background-image: url(imgs/nav_over.gif); 
}

to

div.nav a:hover { 
  color: #e4923f; 
  background-image: url(imgs/nav_over.gif); 
  background-position : 0 0;
}

and saw no apparent effect, even after a browser restart.

I suspect that the issue is with the vertical positioning and/or height
of the list items themselves rather than an image-related issue, as I tried
using

div.nav a:hover { 
  color: #e4923f; 
  background-color: red;
}

and still continue to see the same variation in vertical alignment.  For
the sake of introducing as few irrelevant factors as possible while
troubleshooting, I've left this version in place.

The list itself is styled as:

div.nav ul {
  margin: 0 20px;
  list-style-type: none;
  height: 30px;
}
div.nav li {
  display: inline;
  background-image: none;
  background-position: 0 0;
  font-size: 14px;
  font-variant: small-caps;
  color: #e4923f;
  padding: 9px;
}


> Also, many factors change when such constructions are subjected to some
> form/degree of font-resizing - in all browsers, so it isn't only the
> background on hover that needs improved alignment in your page.
> FWIW: pixel-sized fonts don't impress any of my browsers.

Any better suggestions for getting the height of the menu row and the
items to match up instead of specifying the heights of everything in
pixels?  I'm a programmer, not a graphic designer, so when I want things
to line up cleanly, my first instinct is to specify everything using
(what should be) an invariant unit: the pixel.  You seem to be saying
that this isn't the best choice, but haven't said what the better option
would be.

It does make sense to me that the pixel-specified heights may be the
culprit, though, because I've never been able to figure out why a 14px
font + 9px top padding + 9px bottom padding = 30px total (the height of
the ul) instead of 32px...

> > Also, side question...  Where can I find a good explanation of doing 
> > 'clipped' corners (as on the right sidebar) in css?
> 
> Don't understand what you're trying to achieve.

   | <- page edge
 __|
/  |
|  |
|  |
|  |
   non-square corner -> \__|
   |

There are a ton of articles out there on doing rounded corners, each
apparently using a completely different technique, but a) none of those
which I've looked at directly address arbitrary custom corners and b) if
I need to adapt one of the rounded corner examples to produce a straight
diagnonal division rather than a curve, I would prefer to start from the
accepted 'best' technique if one exists.

-- 
News aggregation meets world domination.  Can you see the fnews?
http://seethefnews.com/
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

[css-d] Pixel-perfect vertical alignment of horizontal

[Dave Sherohman]

I am in the process of converting
http://kuno.sherohman.org/~esper/nomadnetinc.com/ from its original
nested-table-hell formatting so something css-based and a bit cleaner.

The navigation menu is, however, proving problematic.  I have
successfully managed to get the background to highlight with an image on
hover and to get that image to properly align vertically on Firefox
3/Windows, but it appears slightly too high in Firefox 1/OSX, slightly
too high in Safari 3/OSX, and slightly too low in IE6/Windows.

Is it possible to get that to line up properly in all major browsers/
versions/operating systems and, if so, how?

Also, side question...  Where can I find a good explanation of doing
'clipped' corners (as on the right sidebar) in css?

-- 
News aggregation meets world domination.  Can you see the fnews?
http://seethefnews.com/
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] Sizing backgrounds to page width rather than viewport width

[Dave Sherohman]

On Sat, Aug 30, 2008 at 10:53:11AM +0900, Philippe Wittenbergh wrote:
> Step 1: wrap all the content of the page in a div
> Step 2: style that div as follows
> div {float:left;}
> 
> don't specify a width on that div.

OK, that worked.  Thanks!

Now for the bonus question...  *Why* did that work?  Was the original
problem due to requirements of the relevant spec or is it just a (IMO
bad) decision by the major browser vendors that "full width", by
default, means only the width of the viewport even if the page is wider?

And, most importantly, how would I have figured this answer out for
myself without either being told "here's the fix for your specific
situation" or doing a lot of random futzing with it until I stumbled
across something that worked?

-- 
News aggregation meets world domination.  Can you see the fnews?
http://seethefnews.com/
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] Sizing backgrounds to page width rather than viewport width

[Dave Sherohman]

On Fri, Aug 29, 2008 at 01:41:15PM -0400, Larry Tait wrote:
> I would sugguest getting rid of tables and using proper css styling,

Tables are proper when used to display tabular data, such as game
schedules or team standings.  When there are 20 columns (say, if you're
showing the game times on 20 baseball fields) then forcing them all to
fit into a 1024x768 window is not feasible, regardless of whether the
table is created using  tags or with pure-CSS positioning.

> however, if you want to use
> tables, you need to take out the width:5000px and change it to width:100%

The width:5000px is there to force the problem to be evident without
loading the page up with a ton of extraneous data which isn't relevant
to the issue at hand.  Removing it would mask the problem by
constraining the page to be the width of the screen, but the problem
which results when the page width exceeds the screen width would remain.

-- 
News aggregation meets world domination.  Can you see the fnews?
http://seethefnews.com/
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

[css-d] Sizing backgrounds to page width rather than viewport width

[Dave Sherohman]

I am working on a (partial) CSS conversion of an existing site and have
run into an issue with pages where the content is wider than the window
in which it is viewed.

The page is set up with a banner graphic, which is defined as a div
background (so it will cut itself off based on page width), and a
colored background for the actual content area.  This works wonderfully
on those pages which can size themselves to fit the window.

However, there are a few tables which don't compress so well and force
the page to scroll horizontally.  On these pages, the banner and the
colored background cut off at the width of the window rather than
extending the full width of the page.  This can be seen at

http://chaskaareayouthbaseball.com/widetest.html

(unless your browser window is over 5200 pixels wide).

What can be done to fix this?

-- 
News aggregation meets world domination.  Can you see the fnews?
http://seethefnews.com/
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] Getting past the IE6 z-index bug

[Dave Sherohman]

On Tue, Jun 17, 2008 at 06:03:57PM -0400, David Laakso wrote:
> Dave Sherohman wrote:
> > The test page I've been using to work this out is at
> > http://kuno.sherohman.org/~esper/linktree/menutest.html
> >
> > What do I need to do to get this to render properly in IE6?
> 
> A different menu-- one that is known to work cross-browser?
> Don't know if this will meet your need[1],  but I've had success with it 
> for my simple needs:
> <http://sperling.com/examples/menuv/>

Thanks for the suggestion.  It looks like it will get the job done and
pretty much does Just Work, although I really had been hoping to come up
with something self-contained and that I understood from front to back,
which is why I was rolling my own in the first place.

-- 
News aggregation meets world domination.  Can you see the fnews?
http://seethefnews.com/
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] Getting past the IE6 z-index bug

[Dave Sherohman]

On Tue, Jun 17, 2008 at 11:26:37PM +0200, Ingo Chao wrote:
> >> The generic approach to fix that problem is to set position:relative on 
> >> li:hover only. By doing this, the subsequent  will not be placed 
> >> above the hovered  in question, because only this li is positioined 
> >> and gets a higher rank in the painting order.
> >>
> >> Did you try that?
> > 
> > Not until you suggested it, as all I've read has stated that IE6 only
> > supports :hover on a tags, implying that anything on li:hover would be
> > completely ignored.
> > 
> > While this has resolved the z-order issue, it caused a new set of
> > problems: ...
> 
> Sure. But as long as your li keep beeing positioned relatively, the bug
> occurs. They /need/ to be positioned relatively when hovered, so your
> inline-scripting cannot solve for the problem.

At this point, the only javascript I'm using is to toggle the submenu
visibility:

  

It does not attempt to address z-ordering.

> You may have to use suckerfish scripts or alike to have a class .sfhover
> to declare li.sfhover {position:relative} for IE.

That sucks (no pun intended)...  I was hoping to be able to do this with
no javascript at all, just CSS.  I didn't much like needing to do inline
js visibility toggles to make up for IE6's lack of li:hover, but external
libraries?  So much for being simple and self-contained.

> I did not tell you to remove the relative positioning. I've tried to
> explain the mechanism of the bug, and the general workaround.

Based on my understanding of the general workaround, I went from

li
 {
   white-space: nowrap;
   text-align: left;
   list-style-type: none;
 }
ul.top li
  {
position: relative;
background-color: #c0c0c0;
  }

to

ul.top li
  {
list-style-type: none;
white-space: nowrap;
text-align: left;
background-color: #c0c0c0;
  }
ul.top ul li:hover
  {
position: relative;
  }

I did not remove the relative positioning, I just moved it from li to
li:hover, but this seems to have been sufficient to cause IE to make it
absolute, even when hovering on the li.

-- 
News aggregation meets world domination.  Can you see the fnews?
http://seethefnews.com/
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] Getting past the IE6 z-index bug

[Dave Sherohman]

(Sorry about the double copy, Ingo.  I accidentally replied to sender
the first time instead of to list.)

On Tue, Jun 17, 2008 at 10:07:57PM +0200, Ingo Chao wrote:
> All subsequent  will be placed above the submenu, since these  
> are coming later in the source.

Indeed.

> The generic approach to fix that problem is to set position:relative on 
> li:hover only. By doing this, the subsequent  will not be placed 
> above the hovered  in question, because only this li is positioined 
> and gets a higher rank in the painting order.
> 
> Did you try that?

Not until you suggested it, as all I've read has stated that IE6 only
supports :hover on a tags, implying that anything on li:hover would be
completely ignored.

While this has resolved the z-order issue, it caused a new set of
problems:

- In IE, the submenus are now positioned absolutely rather than relative
  to their parent items.  Additional spacing (blank lines) has also
  appeared after submenu items containing a tags.[1]
- In Firefox, submenu items now jump to the right when moused over.

These changes are currently viewable at the previously-mentioned URL,
http://kuno.sherohman.org/~esper/linktree/menutest.html

[1] I've determined that the additional spacing is due to my having set
display:block on a tags so that the entire line will highlight on
mouseover rather than just the text portion.  Based on your initial
suggestion, I tried moving the background-color change from a:hover to
li:hover, but, while IE6 may recognize position:relative in li:hover,
changing background-color in li:hover has no apparent effect.

Setting display:block only in a:hover was also unsatisfactory, as it led
to the gaps appearing on mouseover, causing subsequent menu items to
jump around.  Setting a's margin, padding, and border to 0 along with
display:block produced no discernable change in the undesired spacing.

-- 
News aggregation meets world domination.  Can you see the fnews?
http://seethefnews.com/
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

[css-d] Getting past the IE6 z-index bug

[Dave Sherohman]

I'm currently in the midst of reinventing the CSS cascading popup menu
(with just a hint of javascript to do the show/hide, thanks to IE6's
lack of li:hover) and have got it pretty well worked out in Firefox and
Safari, but IE6 is killing me with its insistence on hiding bits of the
popup behind the subsequent menu items.  I've found lots of discussion
about this bug via google, but no solutions (or at least none that I've
been able to get to work).

The test page I've been using to work this out is at
http://kuno.sherohman.org/~esper/linktree/menutest.html

What do I need to do to get this to render properly in IE6?

-- 
News aggregation meets world domination.  Can you see the fnews?
http://seethefnews.com/
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] 2 more 2 columnish questions

[Dave Sherohman]

On Fri, Feb 29, 2008 at 08:52:27AM -0500, David Laakso wrote:
> Dave Sherohman wrote:
> >Both questions relate to my site at http://seethefnews.com/ and can be
> >seen on the page http://seethefnews.com/index.cgi?action=topwords
> >
> >1)  Is there a way to get column sizing in pixels and percents to play
> >nice together?  My base layout is set up with two columns in divs .main
> >and .nav, defined as:
> >
> >div.main { float: right; width: 84%; }
> >div.nav { float: left; width: 15%; margin-right: 5px; }
> 
> With regard to only your first question, a negative margin layout using 
> pixel width for the sidebar and percent for the content may do better 
> for you. This one [1] has the same source order as yours-- content 
> first, nav second...
> 
> [1] <http://blog.html.it/layoutgala/LayoutGala31.html>

Thanks!  Got it working with the style definitions changed to:

div.wrapper { float: left; width: 100%; }
div.main { margin-left: 140px; }
div.nav { float: left; width: 135px; margin-left: -100% }

and adding the "wrapper" div starting immediately before and ending
immediately after "main" in each of my templates.

Is there, by any chance, an annotated version of this (or a similar)
example available anywhere?  Although it works, I prefer to know how and
why it works rather than cargo-culting existing code.

The main thing bothering me is that I have no idea why the wrapper is
necessary (beyond "it don't work if it ain't there").  It seems like
simply placing the "float: left; width: 100%;" on div.main (my
page)/div#content (the example) instead of using the wrapper should have
the same effect, but it doesn't.

-- 
News aggregation meets world domination.  Can you see the fnews?
http://seethefnews.com/
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

[css-d] 2 more 2 columnish questions

[Dave Sherohman]

Both questions relate to my site at http://seethefnews.com/ and can be
seen on the page http://seethefnews.com/index.cgi?action=topwords

1)  Is there a way to get column sizing in pixels and percents to play
nice together?  My base layout is set up with two columns in divs .main
and .nav, defined as:

div.main { float: right; width: 84%; }
div.nav { float: left; width: 15%; margin-right: 5px; }

This initially worked great, until I stuck some google ads into the nav
column.  The ads have fixed widths (120 or 125 pixels), forcing that div
to be at least wide enough to accomodate them.  This is no issue when
viewed in a maximized browser on a 1024x768 or larger desktop, but when
I bring it up on my N800 (800-pixel-wide screen), the columns overlap
each other.

This is fixable for all-text pages by simply removing the 84% width from
div.main, but most pages are based around a table[1] in .main and I
haven't been able to find a solution which prevents the overlap on small
screens without also either causing .main to appear below .nav or
causing horizontal scrolling.

The obvious ideal solution would be a way to set div.main's width to
"100% - 130px", but I'm pretty sure it can't be done quite that way.


2)  On the page mentioned, note the "Influence" column, which is split
into 2 subcolumns for the current value and the change over the last 24
hours.  This was basically done in an attempt to be able to
independently align each of the two sets of numbers.  e.g.,

391.41  +66.40
 10.000.00
560.59 +101.37

How would I go about producing this formatting without needing to split
the data into two separate s?



[1]  Before you go all "tables are EVIL!" on me, note that
I'm using them in div.main to display actual tabular data, not as a
misguided formatting gimmick destined to turn into a nested-five-deep
Quagmire of Doom.

-- 
News aggregation meets world domination.  Can you see the fnews?
http://seethefnews.com/
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/