A problem for "fluid design" experts.

D

David Segall

In said:
More for you to think about: CSS class names of .grey, .white, .yellow
are poor choices of names. What if you want to change the color from
grey to, say, light blue?
.grey {
color: #add8e6; ...
So: <p class="grey"> means "light blue" ...

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:
My background is computer programming and it is accepted practice to
define constants.

I'll certainly agree with that, except that HTML and CSS aren't
programming." said:
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.

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.)
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 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.)
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.

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:
....

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.

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

I get the feeling that you have missed or under noticed rf's points
contained in:

"I only saw the "effect" because you pointed it out and then I had to
look carefully at the actors to determine where they are looking."

and

"Didn't pick that at all, except as per the comment above. Just a bunch
of people I have seen in movies.

"Are you sure you are not trying to inject something into your viewers
experience that you personally experience because that is what you were
thinking when you produced the collage?"

I mention this because I was thinking rather the same thing.
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.
(btw David, I saw Grand Torino and Revolution Road" recently, both good,
the latter quite simply brilliant (an absolute credit to the director
and cast))
Thanks dorayme. I believe your view of Happy-Go-Lucky was a temporary
lapse so I take your advice seriously :)
(btw2. Never mind the reviewers you mention, I think it is time to have
dorayme listed on your site for each film. You only have to ask. And
please start by giving Poppy an extra star.)
Your every wish is my command!
 
D

David Segall

Beauregard T. Shagnasty said:
I'll certainly agree with that, except that HTML and CSS aren't
"programming."

No, but both programmers and HTML authors aim to produce material that
can be easily understood and maintained by their successor.
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.)

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.
Not sure what you mean about "white" being an HTML constant. I didn't
know that HTML even had constants.

<http://www.w3.org/TR/html4/types.html#h-6.5>
 
B

Beauregard T. Shagnasty

David said:
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.

True. I just extended the example using the word you supplied.
On the other hand, I think meaningful names make the markup more
readable

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?
and warn someone who has to maintain my site that changing the
properties is likely to break the site.

If that someone knows that "menu" is, well, the menu, there should be no
problem.
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.

"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".
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.

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

dorayme said:
Ideally, yes, the HTML should be as pure as the driven snow. But
realities dictate the use of divs with presentation firmly in mind.
I wonder if anyone apart from you and a few other contributors to this
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:
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.

Don't forget about inheritance. And don't go overboard. You don't want
to be placing a style= said:
.. Why stop at defining the colours in .cfunkey? The client might want
to change only some of the funkey coloured elements.

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:
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. ;-)

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.
Oh. I don't see "#FFFFFF" or "white" as a constant, no more than I
would see "Helvetica" as a constant.
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:
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.)".

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:
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 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).
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.

...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.
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.

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.
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?

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

No, but both programmers and HTML authors aim to produce material that
can be easily understood and maintained by their successor.  

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top