T
Travis Newbury
et-tu dorayme?
et-tu dorayme?
D
David Segall
In said:
My background is computer programming and it is accepted practice to
define constants. I might define Pi or Monday, not because I may
decide to change the ratio of a circle's circumference to its diameter
or Monday's position in the week, but because the name makes my code
easier to read than the corresponding number.
By convention, some computer languages demand a different
capitalisation for named constants so, for example, the constant
"grey" should be "GREY". Is there a similar convention for CSS/HTML or
are you arguing that named constants should not be used?
For the purpose of this discussion please ignore the fact that "white"
is already a named constant in HTML so, for that reason alone, it was
a bad choice for the name of my constant.
B
Beauregard T. Shagnasty
David said:
I'll certainly agree with that, except that HTML and CSS aren't
programming." said:
div.pi { width: 3.14in; |
<div class="pi"><img ...></div>
and then next week the client says "make this part wider"...
(Yeah, I know that's just an example.)
For defining color classes, I use names like:
/* Specific colors */
..ccool {background-color: transparent; color: #0000ff; }
..cverycool { background-color: transparent; color: #191970; }
..chot { background-color: transparent; color: #8b0000; }
..cveryhot { background-color: transparent; color: #ff0000; }
..cfunny { background-color: #dcdcdc; color: #9932cc; }
..chighlight { background-color: #fdf5ca; color: #000; }
..creturn { background-color: transparent; color: #006400; }
then if the client says he wants the 'cool' of blue to be purple
instead, I only need to change that one color code, and don't have to
search dozens/hundreds of pages changing <span class="blue"> to <span
class="purple">.
(I also never use real English words for classes/variables, etc.)
Not sure what you mean about "white" being an HTML constant. I didn't
know that HTML even had constants.
D
dorayme
David Segall said:
You will have got the point, probably, from Sherm. Here is another
example often used, suppose you want a column that is leftmost and you
class or id it as "left". You might float it or otherwise position it
left.
Subsequently, you decide you want this column to be on the right. A
simple change in the CSS would be to float div.left to the right. One
change and the whole site is fixed in this respect. Except that now you
have a slightly confusing naming of the class or id. To fix this anomaly
would involve you changing the class or id name and this means changing
all the references in the html pages.
Simpler, it would seem, to provide, in advance, a name that describes
the function of the element.
However, sometimes too much is made of this point. It is sometimes
*worth it* to name an element presentationally because it is less
confusing to the author (and others) in working with it. If a change is
made subsequently, it is sometimes *worth it* to change the class or id
name. One can do this with Search and Replace techniques and/or
'includes' (the latter here nullyifying the advantage that so called
semantic names have because they *can* be changed once only and the
propagation to all pages is automatic).
I would think that it is a risky idea to use colour names but positional
names like "left" and "right" and "middle" are more an open question. An
author can want a two col presentation but be unsure what the content of
those cols will be, "left" and "right" are not too bad a way to go in
this circumstance.
Ideally, yes, the HTML should be as pure as the driven snow. But
realities dictate the use of divs with presentation firmly in mind. Some
of these matters are open questions and you will make up your own mind,
David.
(btw, I saw Eastwood's Changeling last night and as I always suspect
with a film that goes for more than about 90 mins, it cried out to be
pruned more and I know pretty well where...)
D
David Segall
My reply to rf was "I wanted to fix a problem that _I_ have with the
image. Both our visitor sample sizes are too small to judge whether
the problem is significant". I think I can remain concerned despite
the fact that your post has doubled his sample size. After all, this
concern of mine is harmless unlike some of my other sins that have
been pointed out in this thread. I think I have corrected the major
errors and I have even eliminated one of my shades of gray.
Thanks dorayme. I believe your view of Happy-Go-Lucky was a temporary
lapse so I take your advice seriously
Your every wish is my command!
D
David Segall
Beauregard T. Shagnasty said:
No, but both programmers and HTML authors aim to produce material that
can be easily understood and maintained by their successor.
All that is perfectly valid for naming things that may change. It
would be foolish, and very confusing, to name something pi simply
because it had a value close to pi on the day you wrote the HTML.
On the other hand, I think meaningful names make the markup more
readable and warn someone who has to maintain my site that changing
the properties is likely to break the site. For example, I have three
classes called leftImage, centeredImage and rightImage. They have the
properties, and only the properties, that achieve the desired
alignment and that I believe should not be changed without reviewing
the entire site. It has the consequence that if you decide to change
my site so that the posters on the film page are aligned to the left
you will have to change the class name. I think the advantages of
meaningful names associated with site-wide property definitions far
outweigh that disadvantage.
<http://www.w3.org/TR/html4/types.html#h-6.5>
B
Beauregard T. Shagnasty
David said:
True. I just extended the example using the word you supplied.
That is exactly what I meant. We see a lot of samples in these groups
where authors use class or id names such as: left, middle, right. Those
may work .. until the client says, "I'd like the menu on the other
side."
It is much more meaningful to use: menu, content, ads
as the section names, don't you think?
If that someone knows that "menu" is, well, the menu, there should be no
problem.
"leftImage" etc is fine. If you are going to move an image to the other
side of the page, you'd change the class name to "rightImage".
Well, yes. I believe that is what I am saying. ;-)
Oh. I don't see "#FFFFFF" or "white" as a constant, no more than I
would see "Helvetica" as a constant.
D
David Segall
I wonder if anyone apart from you and a few other contributors to thisdorayme said:
group would define "pure as the driven snow" to mean instantly
responsive to the whims of a customer!
I believe that a major goal, possibly _the_ major goal apart from the
aesthetics, should be maintainability. To me, that means minimising
the number of times a property is specified. It also means meaningful
names and some comments if you are doing something tricky.
Of course you should make some educated guesses about which attributes
might change. By specifying the style properties of every element
in-line you can change almost anything instantly. Why stop at defining
the colours in .cfunkey? The client might want to change only some of
the funkey coloured elements.
B
Beauregard T. Shagnasty
David said:
Don't forget about inheritance. And don't go overboard. You don't want
to be placing a style= said:
That was .cfunny. If the client wants only some of those bits changed,
create a new class for something different using a word that makes
sense, and retain the ones you already have.
That wasn't difficult! ;-)
D
David Segall
Beauregard T. Shagnasty said:
We now seem to be in total agreement. I only disagreed when you said
"(I also never use real English words for classes/variables, etc.)".
If you can produce a class .menu that can be horizontal, vertical,
left, right, top or bottom by changing some properties I regard that
as an ideal class name. I also regard it as a significant achievement
and urge you to publish it here. I name mine .leftMenu to caution the
maintainer that it is likely to fall apart if they change its position
or orientation. I would avoid the name .mfunny mainly because it does
not give any useful information about the menu but, deep down, because
I hate any prefix notation.
Well, maybe not total agreement. If "#FFFFFF", "white" and "Helvetica"
as the understood value of the appropriate properties are not
constants how would you describe them?
B
Beauregard T. Shagnasty
David said:
It is only to avoid problems where your chosen word may be (or in a
future version) a reserved word. Perhaps in a future version of HTML,
there is an actual element said:
I normally name mine (as an id, not a class, since there is normally
only one per page) the id of #nav (for navigation, of course).
...until your client says, "Move the menu to the right side." Are you
going to go through all your hundreds of pages, changing .leftMenu to
..rightMenu ?
If your maintainer is changing the overall design of the site, they need
to pay a lot more attention than just to a classname or two.
It was "cfunny" - the leading c for colour. I use them in <span>s. It is
every bit as descriptive as "grey", maybe more so, because it defines a
particular purpose for its use. Same with "ccool" as normally a blue,
and "chot", normally red. But if the client wants orange instead, I
only need to change the colour code in the .chot stylesheet, not dozens
of class="red" to class="orange".
If you don't like Hungarian notation, you don't need to use it.
I would describe them as choices of attribute values, not constants. The
word 'constant' has quite a different meaning to anyone who ever wrote
programming code.
I would never have a style
.helvetica { font-family: Georgia, serif; }
<p class="helvetica">Now is the time...</p>
A
Andy Dingley
Read Hakon Lie's PhD Thesis. There's a big explanation in there of
why CSS isn't a programming language, and why it damn well isn't going
to become one. It could easily have done so - DSSSL was an influence
on it, mainly as a thing to avoid! The problem is that "feature rich"
styling languages have shown a tendency to alienate users and to be
horribly complex. CSS was deliberately pitched to be _simple_. Only
those who've actually experienced DSSSL are likely to believe that
though!
The upshot of this is that you don't get macros. Speaking as someone
who spends far too long inserting "color: corporate-blue;" and
"corporate-red" all day, I wouldn't mind a slice of that. However in
Lie's view (and on balance, I think rightly so), the cost of the extra
complexity isn't worth it. The assumption is that this stuff will be
_generated_ by machine, not authored by hand. So if you want pre-
processor or macro facilities, add them with some external wrapper
process - there are plenty available.