- From: Adam van den Hoven <list@adamvandenhoven.com>
- Date: Wed, 24 Jul 2002 16:26:14 -0400 (EDT)
- To: <www-style@w3.org>
- Message-ID: <7CA253997923DF41945B8F177F1600F001625E40@c2kxch.cucbc.com>
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 UTC