W3C home > Mailing lists > Public > www-style@w3.org > July 2002

Things I wish CSS could do.

From: Adam van den Hoven <list@adamvandenhoven.com>
Date: Wed, 24 Jul 2002 16:26:14 -0400 (EDT)
Message-ID: <7CA253997923DF41945B8F177F1600F001625E40@c2kxch.cucbc.com>
To: <www-style@w3.org>
I've been using CSS for several years now and I find myself saying, "I
wish CSS did ...". Often this occurs when I'm using HTML for an
application interface and not as a rendering of some document. I like
the idea of doing all the look and feel type coding in CSS (or at least
being consistent about it) and then leaving application behavior to the
JavaScript.

I though I'd provide my list as a discussion point. Perhaps one of the
Powers-That-Be will decide to add these to a future version of CSS.

Use XPath-like syntax for selectors 


Being able to make more robust selectors would be very useful. Imagine
the following code:

<form action="#" method="get">

  <p>Tell us how we can contact you:</p>

  <fieldset>

    <legend><input type='checkbox' id='ContactEmail'><label
for='ContactEmail'>Email</label></legend> 

    <p>

      <label for="ContactEmailAddress">eMail Address</label>

      <input type="text" name="ContactEmailAddress"
id="ContactEmailAddress"/>

    </p>

  </fieldset>

  <fieldset>

    <legend><input type='checkbox' id='ContactPhone'><label
for='ContactPhone'>Phone</label></legend> 

    <p>

      <label for="ContactPhoneNumber">PhoneNumber</label>

      <input type="text" name="ContactPhoneNumber"
id="ContactPhoneNumber"/>

    </p>

  </fieldset>

  <fieldset>

    <legend><input type='checkbox' id='ContactMail'><label
for='ContactMail'>Mail</label></legend> 

    <p>

      <label for="ContactMailApt">Apartment Number</label>

      <input type="text" name="ContactMailApt" id="ContactMailApt"/>

    </p>

    <p>

      <label for="ContactMailStreet">Street Number</label>

      <input type="text" name="ContactMailStreet"
id="ContactMailStreet"/>

    </p>

    <p>

      <label for="ContactMailCity">City</label>

      <input type="text" name="ContactMailCity" id="ContactMailCity"/>

    </p>

    <p>

      <label for="ContactMailState">State</label>

      <input type="text" name="ContactMailState" id="ContactMailState"/>

    </p>

  </fieldset>
  <fieldset>
    <legend>Details</legend>
    <p>
      <label for="Details">Details of your problems</label>
      <textarea id="Details"></textarea>
    </p>

</form>

It would be nice if one could use the following cuss (I'm keeping to an
XPath syntax intentionally for illustration):

fieldset/p{

display:none;
clear:both;

}

fieldset[legend/input/@checked="checked"]/p{

  display:block;

}
p/label{
  float:left;
  width:100px;
}
p[textarea]/label{
  float:none;
}

A bit contrived but it would have taken many more lines of JavaScript to
accomplish the same effect. Being able to do show/hide blocks of fields
based on the currently selected option in a drop down would be similarly
useful.


The second example of making all the form fields offset 105 px with the
lable filing in the first 100px, unless the form field is a textarea
(which unlike other fields should take up more space) is possibly one of
the most compellig reasons (IMHO) for doing this. Its not something that
can be replicated with javascript. To do it you'd have to add class
information which is effectively redundant. 

Allow attr(x) to work with more than just content properties 


This could be used for graphical roll overs

<style>

  a:link {

	  background-image:url(attr(bgimage));

	}

  a:hover {

	  background-image:url(attr(bghoverimage));

	}

</style>
Similar to the @media type blocks, test to see if some feature is
implmented 


Often I'll have it where there are a couple of ways to do something in
CSS but a browser may not have implemented it yet, or what have you. For
instance, I have a series of links in block, and I want to show them in
a vertical list with a 1px border between the elements but not on the
top or bottom. The way to do this is to make my <a> tags display block
with a 1px border on the top of each except for the first-child which
should not have a top border. Since IE doesn't implement first-child, we
need to put IDs on all the anchors (probably a good idea anyway) and use
the ID of the first anchor instead of first-child. 

This works until we change the order of the anchors. If we could have
tested to see if the feature is specified (prehaps using @test
a:first-child{...} @else {...} or @test border-style:dotted{...} @else
{...} or @test quotes{...} @else {...}) one could use alternate
solutions. 

Beyond covering for incorrect or incomplete implementations, one could
handle situations where you want to use an optional feature but have an
alternate solution if a particular brower doesn't support it. This would
also work when you have to support browsers that may only implement CSS
4 and those that support CSS 5.

We already have various hacks to do some of the same things (box model
hack, high pass filter) so building a formal way to test would be
useful, although it wouldn't really be able to replace the existing
hacks. 

In a simlar way, it would be useful to have different CSS for when
Javascript, images and cookies are enabled (or not). 



Set an arbitrary element attribute 


A few months ago, I made this same suggestion and someone slapped me
down for it. I understand the reason but I never the less feel its a
valid request.

Consider the anchor. We can do all the nifty roll-over effects easily
for text anchors. That is what the :hover and :active psuedo classes are
for. However, if I want to do a graphical anchor, I have to include some
javascript. It seems to me that its unfortunate we need to do this. 

Now I'll admit that this opens up CSS to potential abuse (if you are a
CSS Fanatic) where you are doing things that should be javascript. But
that shouldn't be a sufficient reason not to implement it. It does make
it possible to do more sophisticated (especially with the other things
on my wishlist) to do things like accessible hierarchical menu systems. 



Access the content of an elmemnt separately from the element itself 


I have occasionally had it where I have an anchor that may either use an
image or simple text, depending on the requirements of a client. Since I
use the same codebase for all clients, I typically use <a><span
class='text'>Some text</span><img src='someimage.gif' /></a> and then
use css to show either the text or the image. I could throw some logic
into my server side code to only send text or the image, except that I
want to always send the text (for printing, non-visual browsers, etc).
The image is always subordinate. It would be nice to hide the text
without hiding the element itself. This might be most useful with
<button> tags. 

I've also had problems with tables where I want to use <colgroup> and
<col> element to set widths of columns but when I set a padding or
margin on the cell, the whole thing gets messed up (the css padding
seems to get applied after the columns are given their widths). To get
around it I had to wrap the contents of the cells with <span> tags which
was a bit cludgy. That may just be a matter of incorrect interpretation
of the specs. 

I realize that some of these things will ignite religous wars,
particularily the idea of changing the value of an arbitrary element
attribute. I also realize that my suggestions come from a specific point
of view, namely application developer (as opposed to content creator).
If all I was creating was prose documents for Joe and Fanny Average,
then some of these ideas would be pointless others would treasonous.

However, most of my work involves creating online applications where I
need to make my stuff work like a compiled application. IMHO, it is
desirable to make CSS responsible for the look and feel of the whole
application and use javascript only for the programmatic behaviour
(validation, ensuring the options in field x are consistent with the
value of field w, etc.). These suggestions would go a long way to
accomlishing that. 

Have a good day, 

Adam van den Hoven, 

 
Received on Thursday, 25 July 2002 09:58:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:15 GMT