Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > HTML > A problem for "fluid design" experts.

Reply
Thread Tools

A problem for "fluid design" experts.

 
 
Beauregard T. Shagnasty
Guest
Posts: n/a
 
      02-07-2009
David Segall wrote:

> "Beauregard T. Shagnasty" <(E-Mail Removed)> wrote:
> <snippage>
>>>> It is much more meaningful to use: menu, content, ads
>>>> as the section names, don't you think?

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


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

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

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


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>

--
-bts
-Friends don't let friends drive Windows
 
Reply With Quote
 
 
 
 
Andy Dingley
Guest
Posts: n/a
 
      02-07-2009
On 7 Feb, 07:03, David Segall <(E-Mail Removed)> wrote:

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

>
> 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Problem problem problem :( Need Help Mike ASP General 2 05-11-2004 08:36 AM



Advertisments