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 build style sheets by
hand. Entirely by hand.
One thing VS does is to add non-breaking spaces all over the place.
It's an improvement on the pile of excrement that was FrontPage, but it
still does it. Your page shows this. If you want to create space
between elements on your page, never use non-breaking spaces. Use
margin or padding instead. The use of non-breaking spaces is deadly for
accessibility, for one thing. They should be used for what they were
intended, i.e. to prevent line breaks at particular points in the text
where a space would occur. For example, you would not want to see a
line wrap in the middle of a name, so you would markup
'Peter Bradley', instead of 'Peter Bradley'.
> I wouldn't style the title in the way you have, either. It's a level
> one heading in my book, so I'd use<h1> and style that. Since that
> gives you 150% font size by default as well as a bold font you can also
> save on some rules:
>
> .TITLECONTAINER h1 {
> color: blue;
> font-family: georgia, serif; /* note the generic font for computers
> without georgia */
> text-align: center;
> }
>
>
> Similarly the content pane. The content pane header is a header so you
> should use a header tag. For instance:
>
> dnn_ctr380_ContentPane h1 {
> /* styles for content pane level one header... */
> }
>
> How did the contentpane end up being a heading? strange, because it doesn't
> say that in the asp.net code... *boggle*
>
Nope. the content pane *header*: not the content pane itself. What I'm
saying is that if something is a header, it should be marked up using
one of the<hn> tags. As you know better than me, if you use a screen
reader it tells you if you are reading a header (something between<hn>
tags). So if you just mark it up as ordinary text (albeit styled
differently), people using screen readers (or text only browsers for
that matter) don't know there's anything special about it. And if
there's nothing special about it, then why are you styling it as if
there was? :-)
> There are also a couple of validation errors that you ought to attend
> to. They're easy enough to fix.
>
> What would they be?
>
>
>
http://validator.w3.org/
Better still, do all your testing in Firefox and install the Developer
toolbar. Then you can use the toolbar menu to call the validator. Most
professional Web developers, in my experience, use Firefox in the first
instance and then check in IE afterwards to see what they have to do to
work around IE's bugs.
As it happens, the errors on your page are just empty<ul> elements.
<ul> elements must have at least one<li> child.
HTH
Cheers
Peter
--
http://www.peredur.net
--
http://www.peredur.net
______________________________________________________________________
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/
