Ar 11/06/10 23:55, ysgrifennodd Andy B. :
Well, sort of... Guess css has me confused now. This is why I like having
sighted people taking a look since I don't know what always looks best.
Heh! Ask 10 sighted people what looks best from 10 different choices
and you'll get 10 different answers, more than likely. 12px text is not
unusual on the Web. The important point is to consider your users:
* Will your user population have visual problems?
* How easy will it be for your users to resize the text if they need to
(e.g. Ctrl-+/Ctrl--, resize buttons etc)
* Left should be margin-left ( all l.c.) - unless you're doing absolute
positioning, which would make no sense here
* Right should be margin-right (all l.c.) - unless you're doing
absolute positioning, which would make no sense here
What does right/left do then?
If you have a block element that is absolutely positioned, the left and
right rules determine the offset from the left or right hand side of the
positioning context (the first non-statically positioned ancestor of the
block; or the viewport if the block does not have a non-statically
positioned ancestor). This is also the case for relatively positioned
blocks, but much less common since relatively positioned blocks are
usually used just to provide a positioning context for absolutely
positioned blocks.
Normally, you would not expect to see both left and right specified:
rather you would expect to see, say, left and top.
* I don't know why you want to float the title container left.
I originally had from left to right a container icon, the title and the
minimize/maximize icon for public views. I decided that I didn't want an
icon in the title bar so took it out. I floated them all left to align them
side by side at the top of the container. In the admin views, I have an
actions menu, the title and the minimize/maximize icon.. Again, the title
bar icon was removed because the images ended up being too large (I think).
Most of the icon images I was going to use were no more than 100x100 in
size. I was just trying to follow most of the examples for container
creation that I saw out there. What would you recommend for positioning the
parts of the title bar?
If you float something left it will always float to the left of its
parent. So centering it won't make sense. If you want to center a div
you simply give it a width and auto margins (or you can specify two
equal margins without specifying a width, which can be advantageous in
getting IE6 to behave.
Assuming that centering is what you want, of course.
I see you're using DotNetNuke. This means there's a fair bit going on
behind the scenes which might interact with your styles. I'm afraid I
won't be able to help you there if that happens. However, I haven't
seen any evidence of that yet. Interesting choice, BTW. I like Jooma!
myself.
* I don't understand, either, why your divs have both ids and classes.
If there's only going to be one of each of them on the page, just use an
ids. If there's going to be more than one, use a class.
Ok. Would never find a use for div ids, so stick with classes?
Most people will use a mixture. For example, how many title containers
will you have on a page? My guess is just one. So it should be an id.
Looking at my own code I see that I usually use ids for the structural
elements that occur on every page: there is just one banner for example,
one footer, one main navigation bar, one page wrapper, one main content
area etc etc. I have all these as ids.
I have classes for things like styles for left floated images, styles
for right floated images, styles for different types of lists and so
on. These things could occur many times on a page. For example I have
a site that uses lists of internal links at the top and bottom of the
page. I use a class for styling those.
You can use some shortcuts as well:
.TITLECONTAINER {
text-align: center;
width: 80%;
margin: 0 auto;
}
Ok. not used to shorthand either. Visual Studio claimed that if I typed long
hand that it would convert it to shorthand but... guess not unless I use the
style builder window.
Visual Studio 2005 is not too bad - in contrast to anything before that
where the code editor was a hindrance rather than a help. It's still
not too great if you want to develop standards compliant, structural
markup and CSS. I've worked as a .NET (ASP.NET plus other more hardcore
computer programmer stuff) developer for many years and I just use the
VS editor as an editor. I don't use any of its so-called 'helpful'
features. So I'm always in code view, for example, and I add everything
by hand. It's type-ahead facilities are good, though, and its real-time
markup validation isn't bad, either, as long as you get to be aware of
what makes it re-validate and so either add or remove its squiggly red
and green lines.
My colleagues all do the same. And we always