[css-d] Fwd: Re: Making sure my container turned out

2010-06-12 Thread Peter Bradley
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 

[css-d] Fonts

2010-06-12 Thread Victor Subervi
Hi;
Googled for a tutorial and/or examples (so I can see in action) what happens
when one plays around with the values for panose-1, stemh, stemw, slope,
cap-height, etc. Got any ideas?
TIA,
Victor
__
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] Fonts

2010-06-12 Thread Philippe Wittenbergh

On Jun 13, 2010, at 3:43 AM, Victor Subervi wrote:

 Googled for a tutorial and/or examples (so I can see in action) what happens
 when one plays around with the values for panose-1, stemh, stemw, slope,
 cap-height, etc. Got any ideas?

I don't really understand your question here. Care to clarify ?

---
Currently CSS is somewhat limited in the possibilities to access all kind of 
alternates in OTF fonts. There are some proposals to change that, though, see 
Chapter 6 of the CSS3 fonts working draft:
http://dev.w3.org/csswg/css3-fonts/#font-rend-props
(and note, that is currently only in the editor's draft, which means very very 
subject to change).

Jonathan Kew has started working on experimentally implementing this in Gecko
http://hacks.mozilla.org/2009/10/font-control-for-designers/

Philippe
---
Philippe Wittenbergh
http://l-c-n.com/





__
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] Fonts

2010-06-12 Thread David Laakso
Victor Subervi wrote:
 Hi;
 Googled for a tutorial and/or examples (so I can see in action) what happens
 when one plays around with the values for panose-1, stemh, stemw, slope,
 cap-height, etc. Got any ideas?
 TIA,
 Victor

   






The obvious happens. Sometimes. All else takes longer.

http://en.wikipedia.org/wiki/PANOSE
http://www.w3.org/TR/2002/WD-css3-webfonts-20020802/

Best,
~d





-- 
desktop
http://chelseacreekstudio.com/

__
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] Fwd: Re: Making sure my container turned out

2010-06-12 Thread Thierry Koblentz
   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.

I believe the offset of relatively positioned elements is done in regard to
their position in the normal flow, *not* in relation to a ancestor. They are
*very* different from absolutely positioned elements. They can overlap
surrounding boxes but do not disturb the flow, 
 
 Normally, you would not expect to see both left and right specified:
 rather you would expect to see, say, left and top.

It is possible to size absolutely positioned boxes via these values. For
example left:10px;right:10px; will make the box stretch 10px from the left
edge to 10px from the right edge of the parent that creates a positioning
context.

--
Regards,
Thierry
www.tjkdesign.com | www.ez-css.org | @thierrykoblentz


__
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] Fonts

2010-06-12 Thread Philippe Wittenbergh

On Jun 13, 2010, at 10:34 AM, David Laakso wrote:

 http://www.w3.org/TR/2002/WD-css3-webfonts-20020802/
Note that is a very old draft. The current draft is:
http://www.w3.org/TR/css3-webfonts/

And I linked to what the editor is working on in my previous message

Philippe
---
Philippe Wittenbergh
http://l-c-n.com/





__
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/