todd fahrner wrote:
>
> On Tuesday, August 28, 2001, at 09:23 , Bojan Smojver wrote:
>
> > The CSS 1 and CSS 2 specifications talk about this:
> >
> > ----------------------------------------------------
> > <p style="font-size: 1.5em">This is important!</p>
> > ----------------------------------------------------
> >
> > What I'm getting at here is the fact that the floating point number is
> > being used to describe a purely presentation layer property. So, one can
> > expect from a web designer to do something like:
> >
> > ----------------------------------------------------
> > #set ($baseFontSize = 1.1)
>
> that wouldn't be very smart as a value for a "base" font size in em units,
> at least not if applied to elements that might find themselves in a
> parent-child relationship, such as TD in the case of nested tables.
> Because the font-size value of the nested TD would then work out to 1.21x
> of the first TD. Which itself might be nested in a div or in body or
> whatever. Applied to font-size, em units are relative to the font size of
> the parent element, not, as commonly asserted, to the size selected by the
> user in UA prefs. It's a special case that 1em = the user-selected size.
>
> > #set ($importantFactor = 1.5)
> > #set ($veryImportantFactor = 2.0)
> >
> > and then just use those numbers later:
> >
> > #set ($importantFontSize = $baseFontSize * $importantFactor)
> > #set ($veryImportantFontSize = $baseFontSize * $veryImportantFactor)
> > ----------------------------------------------------
> >
> > and then in HTML:
> >
> > ----------------------------------------------------
> > <p style="font-size: ${importantFontSize}em">This is important!</p>
> > <p style="font-size: ${veryImportantFontSize}em">This is very
> > important!</p>
>
> If you're going to embed the formatting inline like that, instead of in an
> external stylesheet, it would be less verbose and more portable just to
> use presentational HTML attrs/elements, like BIG, SMALL, FONT, etc, or,
> better yet, elements with semantics like EM or STRONG (for important and
> very important, respectively). You could use Velocity to do some
> non-redundant things in CSS per se, though, like symbolic constants. For
> instance, Scarab's stylesheet sets many background and foreground colors
> on various selections redundantly. These could become, e.g., $bgcolor_a,
> $color_a, $bgcolor_b, $color_b, etc., for easier maintenance. Not that
> manual maintenance of most CSS files is too hard.
>
> as for the warnings W3C's CSS Validator throws about Scarab's CSS, I paste
> part of a reply to Jon, who alerted me to this thread:
As I said, this can be done in many different ways, which is obvious.
Never claimed that it was good style, correct or anything like that. It
is presentation and it uses floating point numbers, that's all. This
could have been a CAD system that needed a zoom factor calculation,
which is presentation as well. Totally irrelevant.
> > 1. the "errors" below reflect the limitations of the QA software and the
> > highly debatable opinions of its designers. they are absolutely not
> > errors in any chapter-and-verse sense.
> >
>
> > <http://scarab.tigris.org/source/browse/scarab/www/ui/csi/style/>
> >
> > Line : 66 Level : 1 You have no color with your background-color : .docs
> > .toc
> >
> > The opinion reflected in this message is that you should never specify
> > background or foreground colors alone for any selected element, since
> > user or UA stylesheets might lead to contrast failures. For instance, you
> > shouldn't say that paragraph text should be black without also specifying
> > that paragraph backgrounds should be some color sufficiently lighter than
> > black. Nevermind that you are careful to set the parent elements of
> > paragraphs (like BODY) to have a suitably contrasting color - the QA
> > software author thinks you need to specify such things redundantly on
> > every single selected element! Why? because users or UAs might have
> > stylesheets that set paragraph text to white without specifying a
> > background color, and the merged result will be white on white. Phooey:
> > the 12 users in the world who use personal stylesheets know better, and
> > they will be careful to take care of all such dependencies. It is the
> > author-stylesheet designers' (our) responsibility to write lean,
> > accessible, maintainable, cool-looking sheets more than to defend
> > verbosely against such sloppy edge-case user-stylesheet authoring!
>
> --
> todd fahrner
Dunno what you talking about here, the failed stylesheets from Tigris
site produce this:
--------------------------------------------
Line: 8 Context : .Header
Property bottom-margin doesn't exist : 4px
Line: 9 Context : .ProjectNameHeader
Property bottom-margin doesn't exist : 4px
Line: 12 Context : .Download
Invalid number : color66666 is not a valid color 3 or 6 hexadecimals
numbers : #66666
Line: 24 Context : .NewsDateTable
Invalid number : colorParse Error - #
Line: 25 Context : .SiteHeader
Property bottom-margin doesn't exist : 4px
Line: 36 Context : .Warning
Property bottom-margin doesn't exist : 4px
--------------------------------------------
Mostly 'bottom-margin' (which doesn't exist in CSS) instead of
'margin-bottom'. But good for having fun... :-)
Bojan
