By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,966 Members | 1,463 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,966 IT Pros & Developers. It's quick & easy.

Is writing CSS a worthwhile use of time?

P: n/a
Is learning to write CSS a better use of time than finding and using a
package that produces complete web pages?

I've moved to a new platform (Macintosh), taking with me about 400
personal web pages, some dating back so far I probably wrote them in vi.
About 4 years ago (thanks in part to hints found in this group) I
converted about 80 pages to CSS, and was fairly happy with the result,
plain though they are. Since then I've forgotten most of what little I
learnt about CSS, since I didn't revise the CSS. Skimming various Eric
Meyer books has only helped a little so far in bringing me up to date on
CSS.

I am wondering whether writing CSS (and HTML) is still a reasonable
approach to updating old web pages, and writing new ones? Perhaps it is
time to change to a program that does everything for the web site
creator? That is, if anything like that exists in the price range I
would consider. My tests so far have eliminated a dozen or so HTML
editors from the 30 I've downloaded so far. Also, I am rapidly coming
to the conclusion that looking at HTML editors is entirely the wrong
approach to making web sites.

CSS now seems to me even more confusing than it was four years ago, in
terms of making decisions about what to use. I have a very simple valid
HTML test page with my test CSS in the document up at
http://www.ericlindsay/sheltersrus/index.html Even that raises many
questions I can't answer (entirely apart from whether it will work in
anything except Safari and Opera).

Is it reasonable to use HTML 4.01 Strict, or should I look at XHTML? I
seem to be seeing posts here and elsewhere implying more browser support
problems if I go XHTML. I did find a page that gave support for
sticking with HTML on http://www.spartanicus.utvinternet.ie/

Is charset=ISO-8859-1 still reasonable, or should something Unicodey be
used?

Should you really put link rel="icon" href="favicon.ico"
type="image/x-icon" in your header, or leave it out entirely? Don't all
browsers pick up a favicon in your web base directory anyway? I guess
that isn't a stylesheet question.

I used to use <base target="_top"> in the head to jump non-Javascript
browsers out of external framesets imposed on your site, but a validator
will complain about that. Do you ignore the validators, or is there
some other way?

Is * { etc } a reasonable way to include your main CSS styles, or is it
better to have a div id=document around your entire page and style that
instead? Or should you maybe style the html tag with your main CSS
styles? I found a discussion that seemed to indicate the * { approach
was a problem.

text-shadow: 5px 5px 10px #11aaaa; works just fine in Safari, and
doesn't show in Opera (either result is fine by me), but is that sort of
thing likely to break some other browser entirely?

float: right; makes my heading keep out of the way of my logo image
(unless someone makes the page very narrow in their browser), but is
using float for positioning likely to break things in lots of browsers?
And if float isn't a good idea, what is?

color: red; background-color: transparent; If I put in a color the
validator warns about not having a background-color, but it won't accept
transparent. I thought transparent was both allowed, and the default.
http://www.w3.org/TR/REC-CSS2/colors.html I eventually found a thread
on validation about a week ago (my newsgroup reading started from mid
July, the oldest posts available to me via my usual reader). That at
least explained how using transparent could leave problems with some
combinations of colours, so I can see a warning is justified. I guess I
might as well leave out the transparent, since it is the default.

..image { border: none; margin-top: 20px; padding-top: 20px; }
img { border: none; float: right; padding-left: 15px; }
This seems very messy. I wanted each picture to stay to the right of
each associated paragraph, which would be easy if I used a table.
Instead I've added a div class="image" to each paragraph, so I am headed
back to tag soup. If you make the browser window sufficiently wide the
pictures will align away from the right margin anyhow. I have the
border: none; (probably only needed in img) because I am pretty sure IE
will try to put a border around both the picture and the padding. I
thought the default was not to show a border?

In the past I've avoided using images (modem bandwidth and lack of host
site space), but I now I would like to add lots of images. However it
seems that instead of IMG I should use OBJECT. Except browser support
may not be there. Luckily this topic was covered in
http://www.spartanicus.utvinternet.ie/embed.htm

#logo { border: none; position: absolute; top: 0px; left: 10px; width:
100px; }
I wanted the logo (when I get time to draw it) to be displayed in the
traditional top left corner. But I wanted the first stuff in the
document body to be the h1 and first paragraph, to make things work
better with search engines. I will always place material for search
engines ahead of graphics or html or scripts or anything else in my page.
But position absolute means I have to make other things like the
sidebar1 start lower on the page. If someone makes their browser
magnification high enough that will break. Plus so far I'm not sure I
am not headed for more problems by doing an absolute position.

This bit of stuff styling the footer is just a total disaster, and so
far I have no idea where I am going with it.
#footer p {margin-top: 0; margin-bottom: 0; }
#footer h3 {margin-top: 0; margin-bottom: 0; }
#footer {width: 75%; float: right; }
..business { color: #dddddd; background-color: transparent; }
h3.business {font-size: 1.5em; }
p.business {font-size: .8em; }

Shouldn't I be able to do #footer h3 p
So far I don't understand why that isn't operating on h3 and p
Obviously something I've missed entirely, but I don't even know what to
search for. Probably it operates only on the p that is a child of h3,
but so far I have absolutely no mental image of inheritance. I keep
hoping to find a diagram like the box model ones that explained the
content inside padding inside border inside margin stuff.

Then there is the h3.business and p.business which both work, but
contrast that to these from the #sidebar1
..sb ul {margin-top: 0; padding-top: 0px; }
where I could only get the sidebar looking reasonable by adding that .sb
class, which seems to me like another piece of tag soup.

I don't want to even think how messy CSS might get when I finally get at
IE on a Windows PC to check what breaks. Plus so far I haven't even
looked at menus and link styling.

So, anyone feel like commenting on whether I should persist with CSS, or
put the same effort into trying to find a program that will make web
pages for me (probably not in CSS).

--
http://www.ericlindsay.com
Oct 17 '05 #1
Share this Question
Share on Google+
17 Replies


P: n/a
Eric Lindsay wrote:
Is learning to write CSS a better use of time than finding and using a
package that produces complete web pages?


Best option is not to write CSS, but to use CSS that's already written
by someone else who really knows what they're doing. For a "typical"
site (and I know there are no typical sites) then the "hard work"
problems are all much the same - nav menus, two or three columns, that
sort of thing. If you possibly can, get a good existing CSS and use
that.

Editing packages are bad. There still just aren't any notably good
ones. Dreamweaver writes doggy code, FP is unmentionable. As you
clearly have a good grasp of HTML with vi, then neither would offer
anything that were really going to benefit from.

A CSS-based design is still worth the trouble. Blag it if you can,
learn it from scratch if you must.
For an easy CSS design, design around the standards and see that it
works well with Safari and Firefox. Ignore Mac IE, for it's well
obsolete. You will probably care about Windows/IE and that's the only
browser that still matters, yet doesn't play ball.

If you can avoid horizontal padding and borders entirely, then IE
compatibility is easier. Otherwise you're into the well-known box-width
bugs.

Use consistent size units throughout. Use ems for anything vertical (or
maybe % for relative font sizes) and use either ems or pixels for
horizontal measurements. Either "go fluid" and use ems (probably best),
but be aware that you'll need to be carefully structured to make sure
that you really are fluid for different window and text sizes.
Otherwise if you're heavily involved with fixed-size assets like
images, then go with pixels for horizontal measures and stick with
them. Trying to mix pixels and ems on the horizontal axis is hard work
if they're in close proximity.

Be wary of float. It's not easy to understand the more than trivial
cases and it's a real bug-mine around IE.

Don't be too quick to dismiss tables. If they're justifiable then
they're currently still more cross-browser stable than the alternatives
for "close in" work. Just avoid using them for "page level" design
work.

Do the right usability things, set your size units right, avoid
Verdana, read Joe Clark's usability book.

Oct 17 '05 #2

P: n/a
Do the right usability things, set your size units right, avoid
Verdana, read Joe Clark's usability book.


Just out of interest, why avoid Verdana?


Oct 17 '05 #3

P: n/a
Robin Tucker wrote:
Do the right usability things, set your size units right, avoid
Verdana, read Joe Clark's usability book.


Just out of interest, why avoid Verdana?


<http://www.google.com/search?hl=en&q=why+avoid+Verdana&btnG=Google+Searc h>

--
-bts
-When motorcycling, never follow a pig truck
Oct 17 '05 #4

P: n/a
--
On Mon, 17 Oct 2005 22:48:03 +1000, Eric Lindsay
<NO**********@ericlindsay.com> wrote:
Is learning to write CSS a better use of time than
finding and using a package that produces complete web
pages?
I have not found a package that actually works, and
therefore, reluctantly, write in source code. Handmade
CSS pages are simply better than any alternative I have
found.
I've moved to a new platform (Macintosh), taking with
me about 400 personal web pages, some dating back so
far I probably wrote them in vi. About 4 years ago
(thanks in part to hints found in this group) I
converted about 80 pages to CSS, and was fairly happy
with the result, plain though they are. Since then
I've forgotten most of what little I learnt about CSS,
since I didn't revise the CSS. Skimming various Eric
Meyer books has only helped a little so far in
bringing me up to date on CSS.
I still find CSS largely incomprehensible. I find some
CSS incantations that produce the desired effect, then
use them. If Perl is a write only language, CSS is a
read only language. When one has something that
produces the desired effect, then one can comprehend it,
but to produce something that will result in the desired
effect is hard.
Is it reasonable to use HTML 4.01 Strict,
This produces the most predictable and controllable
display.
Is charset=ISO-8859-1 still reasonable, or should
something Unicodey be used?


Go with utf-8
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
mowhtnaqV6gPbNE2uGxqyenU7LD+yyEd4JhXfU5T
4ONZXpYNo3mzGRpxN3KCGawYxSvH1W0/QjSSsihtd
--
http://www.jim.com
Oct 17 '05 #5

P: n/a
On Mon, 17 Oct 2005, Eric Lindsay wrote:
Is learning to write CSS a better use of time than finding and using
a package that produces complete web pages?
Even if I could find a package that I trusted to produce HTML and CSS
for me, I'd still want to understand HTML and CSS, at least far enough
to be able to be confident that the package was behaving halfways
sensibly. Wouldn't you?

[...] Is it reasonable to use HTML 4.01 Strict, or should I look at XHTML?
Isn't this a stylesheets group, not an HTML one? That question has
been exercised numerous times, even recently, in its proper place: I
doubt that exercising it yet again is going to produce any fresh
insights.
Is charset=ISO-8859-1 still reasonable,
For CSS? I'd recommend us-ascii, though you aren't asked to declare
it as such.

For HTML, I have some recommendations which maximise compatibility
with older browsers, depending on what you want/need to achieve in
the way of character repertoire:
http://ppewww.ph.gla.ac.uk/~flavell/charset/checklist

Work your way down until you hit the repertoire etc. that you need,
and there you are.

If, on the other hand, you want to maximise the character repertoire
which you can use, and you don't care for old browsers much, except
perhaps NN4: then, if you are competent to use utf-8, then use it (#s7
in the above checklist), otherwise use #s6 .

[...] float: right; makes my heading keep out of the way of my logo image
(unless someone makes the page very narrow in their browser), but is
using float for positioning likely to break things in lots of
browsers?
Floating is useful, and less likely to break horribly than any kind of
explicit positioning; but the results aren't always quite as
predictable as some might wish, and then they worry about the
potential untidiness of the result. It's up to you, really.
color: red; background-color: transparent;
Been discussed several times recently. Feel free to read the group -
write-only postings aren't so productive.
That at least explained how using transparent could leave problems
with some combinations of colours, so I can see a warning is
justified.
Indeed. I'm not certain whether this effect is intentional, or, as
some have suggested, a bug in the W3C CSS checker; but, either way, I
reckon a warning is justified for that reason.
I guess I might as well leave out the transparent, since
it is the default.
Unless you're worried about getting a bg. image to show through from
the underlying element, I'd say re-specify the underlying colour.

If it -is- about an underlying background image, then, IMHO, just live
with the warning. But an unlucky clash with a hostile stylesheet
could make parts of the page unreadable (it could be the user's own
stylesheet, or an unexpected change in your company's mandatory
corporate stylesheet if you're in such a situation), in a way that
conforming to the rule - which says basically you should only set text
colour *with* background colour, or neither of them, but never just
the one, at any given specificity) could protect against. Of course
the other cascaded stylesheets are supposed to be following that same
rule, or the bets are off.
In the past I've avoided using images (modem bandwidth and lack of host
site space), but I now I would like to add lots of images. However it
seems that instead of IMG I should use OBJECT.
In theory, yes, but a certain browser vendor contrived to make it far
too iffy. I still reluctantly stay with IMG for normal web use, even
though I've considered it obsolete ever since the draft HTML/3.0 <fig>
markup.
Except browser support may not be there. Luckily this topic was
covered in http://www.spartanicus.utvinternet.ie/embed.htm
A reliable informant in many regards, indeed, especially about
practicalities.
So, anyone feel like commenting on whether I should persist with
CSS,
Without question.
or put the same effort into trying to find a program that will make
web pages for me
Possibly, but only if it uses current best practice, i.e strict or
strict-ish (X)HTML, whichever you choose, for structure, and CSS for
presentation proposal(s).
(probably not in CSS).


That would be a big mistake! But by asking here, I guess you
guaranteed that answer.
Oct 17 '05 #6

P: n/a
In article <11**********************@g44g2000cwa.googlegroups .com>,
di*****@codesmiths.com wrote:
Eric Lindsay wrote:
Is learning to write CSS a better use of time than finding and using a
package that produces complete web pages?
Best option is not to write CSS, but to use CSS that's already written
by someone else who really knows what they're doing.


Excellent advice. Actually before reaching your reply I found myself
making a Template directory and downloading sample CSS pages from
Stephen Poley's interesting site.
http://www.xs4all.nl/~sbpoley/webmatters/ One problem with using
existing CSS is that I found some sites offering CSS examples for free
download that didn't seem significantly better than the mess I am
currently producing myself.
Editing packages are bad. There still just aren't any notably good
ones.
I don't think I would do enough pages to justify the cost of
Dreamweaver, even if it produced perfect results. I mainly viewed it of
interest for the site template facilities rather than for the code it
produced. However my only experience of it was back with DW3. I'm on a
Mac, so FP probably isn't an option anyhow, but its old reputation
doesn't encourage me to check.

I do wonder whether instead of a HTML editor, I shouldn't consider
instead a CSS editor. I've had a quick look at two, and both turned out
to be cross platform.

http://www.hostm.com/css/ Simple CSS is freeware. Create cascading
style sheets from scratch, modify existing ones. CSS2. For Linux, Mac,
Windows. If you already know CSS this may be pretty handy for avoiding
typos, although all the selecting from menus would get tiresome quickly.
I thought it difficult if you didn't know CSS.

http://www.westciv.com Stylemaster CSS v4, Mac and Windows. Shareware
US$60 30 day demo. Wizards, 30 templates, CSS tutorial, excellent
website support, validation, preview any document. Written by CSS
specialist John Allsopp. The embedded lessons took a couple of hours to
lead me through using lots of the editor functions to create a more
elaborate style sheet than I could have done. I was impressed by the
CSS courses that are available from the same source, one of which comes
with the package. I think I'd have to go through several lessons before
I got any great speed with Stylemaster. But having a live preview of
the results, the code you are creating, and the structure of the
document seems a good way of learning more. You can edit either at the
structure or in the CSS.
Ignore Mac IE, for it's well obsolete. You will probably care about Windows/IE

I was planning to ignore Mac IE, however my site logs show I have to
work with Windows IE, and possible relatively old versions of it even.
I wish I could ignore earlier versions. Guess I'll do some careful
looking at the stats as soon as I get a chance. Or maybe there are some
web wide stats on browser use. I'll Google that.
If you can avoid horizontal padding and borders entirely, then IE
compatibility is easier.
I used padding to the left of my photos, just to keep the text clear of
them. That sounds like I may have to rethink. Or can I get away with
using margins?
Use consistent size units throughout. Use ems for anything vertical (or
maybe % for relative font sizes) and use either ems or pixels for
horizontal measurements. Either "go fluid" and use ems (probably best),
but be aware that you'll need to be carefully structured to make sure
that you really are fluid for different window and text sizes.
I used ems for text, and % for div widths. I recall some discussion of
possible problems with ems, so I guess I should go with % for text sizes
also.
Otherwise if you're heavily involved with fixed-size assets like
images, then go with pixels for horizontal measures and stick with
them.
Depending on how many thumbnails I use, I'll probably eventually want to
provide pixel sizes on img just to make display calculations easier for
browsers. I left thumbnail sizes out for my test page. I want the
layout to be fluid, but obviously I break things if someone does 400%
magnification of the page while in a narrow browser window. However I
will mostly just want images to end up lined up on one side or the other
of a page. I'm not going to try to stitch images together from other
images.
Be wary of float. It's not easy to understand the more than trivial
cases and it's a real bug-mine around IE.
I'm not sure how you manage columns without float left and float right,
unless I use tables
Don't be too quick to dismiss tables.
I'm not going to discard tables if I have column data. I even wrote a
little shell script that makes a html table, to make it easier for me to
enter collections of figures I didn't already have in electronic form.
But I would like to avoid them in general layout, if I can.
Do the right usability things, set your size units right, avoid
Verdana, read Joe Clark's usability book.


Oh yes, Verdana. Now I remember the problem of it looking so big
relative to other fonts. Plus Stephen Poley mentioned above had an
article everyone is quoting. I'll put Verdana as third choice in my
font suggestions. I don't think I want to avoid suggesting a sans-serif
font in many of my pages, but I will change things to avoid suggesting
anything except relative font sizes (in %).

Thanks for your suggestions.

--
http://www.ericlindsay.com
Oct 18 '05 #7

P: n/a
In article <Pi******************************@ppepc56.ph.gla.a c.uk>,
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:
Even if I could find a package that I trusted to produce HTML and CSS
for me, I'd still want to understand HTML and CSS
Well, yes I'd prefer to understand HTML and CSS, but it all comes down
to lacking the time (and ability) to handle a TOE. I think I'm going to
have to go with a partial understanding of CSS, and simply decide to
ignore all the bits I don't think I'm likely to use. In HTML, I don't
use frames for anything, and don't understand how to use them, so I
guess I will decide to ignore great slabs of CSS where it seems I'm
unlikely to use those capabilities.
Is it reasonable to use HTML 4.01 Strict, or should I look at XHTML?

Isn't this a stylesheets group, not an HTML one?

Sorry about that. The whole topic of handling web sites is such a mixed
up mess in my head at the moment that it was just as likely that I would
have put in a question about calibrating CMYK profiles vs sRGB profiles
and think I was in the right group. I'll try to be more careful about
sticking only to the CSS side.
Is charset=ISO-8859-1 still reasonable,
For HTML, I have some recommendations which maximise compatibility
with older browsers, depending on what you want/need to achieve in
the way of character repertoire:
http://ppewww.ph.gla.ac.uk/~flavell/charset/checklist
Thank you. That is a wonderful checklist. Told me exactly what I
needed to know. With so much of the Macintosh now using UTF-8 by
default, I'll wait until I have committed to an editor before deciding
whether to change from ISO-8859-1. With many of the editors calling the
system wide text handling, I'll probably decide on UTF-8 as per your #s7
if I end up using such an editor.
Floating is useful, and less likely to break horribly than any kind of
explicit positioning; but the results aren't always quite as
predictable as some might wish, and then they worry about the
potential untidiness of the result. It's up to you, really.
I want the design to be fluid, so I can accept untidy. I think I might
get some balloons printed with text, and suggest to anyone who objects
to the page being mutable that they try to confine a balloon to the same
precise appearance no matter what size it is.
Unless you're worried about getting a bg. image to show through from
the underlying element, I'd say re-specify the underlying colour.
Well, OK. I guess I'd have to leave specifying the background-color
until most of the other design colors, and the general background is
stable are stable. Otherwise I can see repeated changes to a number of
spots in the CSS, especially if a design gets elaborate.
If it -is- about an underlying background image, then, IMHO, just live
with the warning.


I've used an underlying background image on a few pages, and have found
it a handy technique for getting some results. Don't think I'll ever be
a heavy user.
or put the same effort into trying to find a program that will make
web pages for me


Possibly, but only if it uses current best practice, i.e strict or
strict-ish (X)HTML, whichever you choose, for structure, and CSS for
presentation proposal(s).
(probably not in CSS).


That would be a big mistake! But by asking here, I guess you
guaranteed that answer.


I guess I did guarantee that answer. There are still a few We Do
Everything web page generators for the Macintosh that I want to check
out. http://www.realmacsoftware.com/rapidweaver/ Rapid Weaver v3.2,
Cocoa Shareware US$35. Valid XHTML and CSS, themes based visual editor,
smart publishing, iPhoto integration. In October I saw a little web
site that looked very clean, so I opened up the source (as you do).
That was very clean, all valid code, and tidier than I do by hand (which
is generally pretty clean). It was made by Rapid Weaver. I think I'll
need to take another look at it to work out why I rejected Rapid Weaver
initially. Maybe their template are too limited, but since you can make
your own templates ...

--
http://www.ericlindsay.com
Oct 18 '05 #8

P: n/a
Eric Lindsay wrote:
Valid XHTML and CSS


"Valid (X)HTML and CSS" is of course a basic essential requirement for
an "automated" editing tool, even though few achieve it. It's hardly
something to crow about!

Mainly though, mere validity just isn't enough. Validity is
monkey-work, I want quality too. There needs to be _intelligence_
behind competent CSS work and there are no current tools providing it.

The failing of Dreamweaver (NB SpaceGirl) is that its notion of "CSS"
is pathetically fragmented. Like all of these tools that I've seen it
does no more than use the same old <font> markup shoved into a style
attribute. It's a syntactic translation, not any real shift in
structure or likely benefit. There's no inherent concept of class or
_organisation_ of styles into coherent groups. A major benefit of CSS
is this decoupling of selection rule and applied styles (although OO
programmers will recognise how this fails to work in CSS, but that's a
separate problem). If CSS (as generated by DW) is reduced to little
more than applying individual rules to individual elements, then that's
no better a quality of markup than <table>s and <font>s were.

I'd also be wary of XHTML tools in general. Although there's nothing
_wrong_ with choosing it, it would immediately make me suspicious of
clueless bandwagon jumping in an attempt to get a feature tick in
magazine reviews.

Oct 18 '05 #9

P: n/a
Eric Lindsay wrote:

"Valid (X)HTML and CSS" is of course a basic essential requirement for
an "automated" editing tool, even though few achieve it. It's hardly
something to crow about!
...
I'd also be wary of XHTML tools in general. Although there's nothing
_wrong_ with choosing it, it would immediately make me suspicious of
clueless bandwagon jumping in an attempt to get a feature tick in
magazine reviews.

You are all correct of course, there is no perfect editing tool. However,
the templating ability (for example) is extremely useful in Dreamweaver, at
least for the medium sized site I maintain. You can't do everything with
CSS. I think pragmatic web maintainers know this. However, I do hand code
my CSS and I make as many mistakes with it as the editor does :-/.
Oct 18 '05 #10

P: n/a
On Tue, 18 Oct 2005 11:34:43 +1000, Eric Lindsay
<NO**********@ericlindsay.com> wrote:
If you can avoid horizontal padding and borders entirely, then IE
compatibility is easier.
I used padding to the left of my photos, just to keep the text clear of
them. That sounds like I may have to rethink. Or can I get away with
using margins?


You need padding if you want visible coloured backgrounds on this
padding, or visible borders. Apart from this, you will probably find
using margins alone to be simpler and more easily ported.

Use consistent size units throughout. Use ems for anything vertical (or
maybe % for relative font sizes) and use either ems or pixels for
horizontal measurements. Either "go fluid" and use ems (probably best),
but be aware that you'll need to be carefully structured to make sure
that you really are fluid for different window and text sizes.


I used ems for text, and % for div widths.


% is an oddball in that again you really need to use "no %" or "all %"
(at least for all siblings of the same parent). There's no problem in
mixing % for a couple of divs to make adjacent columns, then using
pixels inside one of those divs to arrange some images and ems to put a
margin around text in the other div. The problems arise when you mix
units between siblings - the ratio between well-balanced design of em
and pixel units goes awry when you change text size, or % goes adrift if
you resize the parent.

Be wary of float. It's not easy to understand the more than trivial
cases and it's a real bug-mine around IE.


I'm not sure how you manage columns without float left and float right,
unless I use tables


If you want adjacency and block-level control, you must use either float
or tables.

To really understand float (and in particular, why floated items can
poke out the bottom of the text flow) then you should read this
excellent explanation
http://www.brainjar.com/css/positioning/
But I would like to avoid [tables] in general layout, if I can.
If you want to fuss over pixel-sizing of adjacent items, tables get the
job done quickly and reliably cross browser in a way that floated divs
can't deliver to IE without enormous effort.

I'll put Verdana as third choice in my font suggestions.
Either use it first and hope they all have it, or not at all.
I don't think I want to avoid suggesting a sans-serif font


So use the generic family name sans-serif (without any quotes) as the
last (or only) choice. Chances are that this will automatically select
the most appropriate sans font for any platform.

There's a reasonable argument that the only useful (and certainly
reliable) values for font-family are serif, sans-serif and monospace --
without useful downloadable fonts, all the family-specific names are
best avoided.

Oct 18 '05 #11

P: n/a
In article <74********************************@4ax.com>,
Andy Dingley <di*****@codesmiths.com> wrote:
On Tue, 18 Oct 2005 11:34:43 +1000, Eric Lindsay
<NO**********@ericlindsay.com> wrote:
I used padding to the left of my photos, just to keep the text clear of
them. That sounds like I may have to rethink. Or can I get away with
using margins?
You need padding if you want visible coloured backgrounds on this
padding, or visible borders. Apart from this, you will probably find
using margins alone to be simpler and more easily ported.


Thanks you for that suggestion. I hadn't managed to get into my mind
the idea that padding out to a border could be most usefully associated
with a coloured background going to the border. For my photos I don't
need a border, nor do I need a coloured background. The visual
formatting model at
http://www.w3.org/TR/1998/REC-CSS2-1...2/visuren.html is helping, but
I still haven't got my head around just how everything interrelates.

I have dropped my original tag soup of an <p class images> tag on each
paragraph and changed to
#main_text {width: 75%; float: right; }
#main_text p { clear: right; }
This seems to keep my photos from shuffling to the left when viewed in a
very wide window (or with Opera set for 50% zoom).

As a result of your suggestion changed the img line from padding to
img { border: none; float: right; margin-left: 15px; margin-bottom: 5px;
}

The reason for the margin-left: 15px is just to stop the text from
running just about into the photos. The margin-bottom: 5px; is to keep
the photos from touching when they are taller than the paragraphs. I'm
not actually concerned with pixel perfect placement, just with ensuring
things don't look silly with photos bumping into each other.
Use consistent size units throughout. Use ems for anything vertical (or
maybe % for relative font sizes) and use either ems or pixels for
horizontal measurements. Either "go fluid" and use ems (probably best),
but be aware that you'll need to be carefully structured to make sure
that you really are fluid for different window and text sizes.


I used ems for text, and % for div widths.


% is an oddball in that again you really need to use "no %" or "all %"
(at least for all siblings of the same parent). There's no problem in
mixing % for a couple of divs to make adjacent columns, then using
pixels inside one of those divs to arrange some images and ems to put a
margin around text in the other div. The problems arise when you mix
units between siblings - the ratio between well-balanced design of em
and pixel units goes awry when you change text size, or % goes adrift if
you resize the parent.


Thank you for that advice. I've now changed most things (including font
sizes) over to %. It hasn't broken in Opera or Safari, but I understand
these are not the problem. I have a few px left mostly in margins of
photos. I may try % there also.
If you want adjacency and block-level control, you must use either float
or tables.

To really understand float (and in particular, why floated items can
poke out the bottom of the text flow) then you should read this
excellent explanation
http://www.brainjar.com/css/positioning/


Thank you for that. Maybe I just needed to see some of the details
written a little different to the W3C version. I seem to be getting a
better idea of what I should be doing now.
But I would like to avoid [tables] in general layout, if I can.


If you want to fuss over pixel-sizing of adjacent items, tables get the
job done quickly and reliably cross browser in a way that floated divs
can't deliver to IE without enormous effort.


I don't care about pixel precise positioning. However I can't see any
easy way to deal with the problems with IE so far, if it is likely that
everything I do will run afoul of some IE bug. Not having a Windows PC
makes testing more difficult. So far I haven't found an equivalent of
Browser Photo.
I'll put Verdana as third choice in my font suggestions.


Either use it first and hope they all have it, or not at all.


OK, I am willing to go with that, at least until I get a bunch of
complaints. I've changed to sans-serif and not listed other fonts.

--
http://www.ericlindsay.com
Oct 19 '05 #12

P: n/a
In article <11********************@f14g2000cwb.googlegroups.c om>,
di*****@codesmiths.com wrote:
Eric Lindsay wrote:
Valid XHTML and CSS
"Valid (X)HTML and CSS" is of course a basic essential requirement for
an "automated" editing tool, even though few achieve it. It's hardly
something to crow about!


However lack of valid code seems to me to be a very reasonable test for
eliminating programs from consideration. I think I'll use that as the
first elimination round.
Mainly though, mere validity just isn't enough. Validity is
monkey-work, I want quality too. There needs to be _intelligence_
behind competent CSS work and there are no current tools providing it.
It is very disappointing to see you say there are no tools providing
competent CSS work. We (mostly) gave up writing page layouts direct in
Postscript long ago, so why is it taking so long to produce reasonable
tools for web pages? It just doesn't seem to make sense.
The failing of Dreamweaver (NB SpaceGirl) is that its notion of "CSS"
is pathetically fragmented. Like all of these tools that I've seen it
does no more than use the same old <font> markup shoved into a style
attribute. It's a syntactic translation, not any real shift in
structure or likely benefit. There's no inherent concept of class or
_organisation_ of styles into coherent groups. A major benefit of CSS
is this decoupling of selection rule and applied styles (although OO
programmers will recognise how this fails to work in CSS, but that's a
separate problem). If CSS (as generated by DW) is reduced to little
more than applying individual rules to individual elements, then that's
no better a quality of markup than <table>s and <font>s were.
Thank you for that description. It covers almost exactly what is
bugging me about trying to find a program for doing web pages. It seems
as if none of the programs I've looked at have any idea about making a
structured documents, to which CSS is applied. Yes, some can handle
every tag, element and attribute in the known universe, but it just ends
up looking like tag soup anyhow. I wanted to end up with really clean
markup. I wanted it clean enough that it was obvious which bits of
content you could change. Plus I wanted my most important search term
laden headings and paragraphs to be at the top of the page, right after
the body tag, with virtually nothing in front of them, just like I would
have written them myself, and not shuffled around and surrounded by vast
numbers of tags.
I'd also be wary of XHTML tools in general. Although there's nothing
_wrong_ with choosing it, it would immediately make me suspicious of
clueless bandwagon jumping in an attempt to get a feature tick in
magazine reviews.


I keep seeing warnings about the XHTML bandwagon. I have decided that
I'm going to stick with HTML 4.01 Strict.

--
http://www.ericlindsay.com
Oct 19 '05 #13

P: n/a
--
On Wed, 19 Oct 2005 13:10:41 +1000, Eric Lindsay
It is very disappointing to see you say there are no
tools providing competent CSS work. We (mostly) gave
up writing page layouts direct in Postscript long ago,
so why is it taking so long to produce reasonable
tools for web pages? It just doesn't seem to make
sense.


Every rendition of a pdf file should look exactly like
any other rendition, but a web page should look "right"
when the size and shape of the browser window varies, or
the ratio between pixels and font size changes, or the
font varies.

A tool that outputs CSS must have taste and judgment,
must produce not just an image, but an image that
behaves sensibly under variation of font size and window
size. That is a difficult task to automate - CSS tools
produce crap for the same reason that html tools produce
crap.

--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
+JaidB0itmt1S4vELtWOg2wePQZdB3oLFogAlFLm
47vhFDOB0vfq0ZxggLya2cEZ4ilLLkZ+aNDWB//h8
--
http://www.jim.com
Oct 19 '05 #14

P: n/a
In <11**********************@g44g2000cwa.googlegroups .com>, on
10/17/2005
at 06:33 AM, di*****@codesmiths.com said:
Best option is not to write CSS, but to use CSS that's already
written by someone else who really knows what they're doing.


I've seen the results of that in other arenas; not a pretty sight, I
might add. What inevitably happens is that someone takes code that is
well suited to its original purpose and uses it in a context where the
results are ghastly. The first rule of borrowing code is to understand
it before you adopt it.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to sp******@library.lspace.org

Oct 20 '05 #15

P: n/a
On Thu, 20 Oct 2005 13:29:33 -0300, "Shmuel (Seymour J.) Metz"
<sp******@library.lspace.org.invalid> wrote:
The first rule of borrowing code is to understand
it before you adopt it.


You don't need to understand CSS before you borrow it. However it will
help if it's intended for such re-use.

If it was necessary to understand code before re-using it, then we'd
have no shared code libraries. It's certainly common for such knowledge
to be necessary, but that's indicative of a badly written library, not a
necessary state of affairs.

--
Die Gotterspammerung - Junkmail of the Gods
Oct 20 '05 #16

P: n/a

please delete my last post. sorry.
--
psico
------------------------------------------------------------------------
psico's Profile: http://www.highdots.com/forums/m1159
View this thread: http://www.highdots.com/forums/t3032950

Oct 21 '05 #17

P: n/a

great! good thread!
--
psico
------------------------------------------------------------------------
psico's Profile: http://www.highdots.com/forums/m1159
View this thread: http://www.highdots.com/forums/t3032950

Oct 21 '05 #18

This discussion thread is closed

Replies have been disabled for this discussion.