[thelist] Form CSS styles

.jeff jeff at members.evolt.org
Mon Jan 21 01:19:50 CST 2002


> From: Andrew Clover
> Really? Take a look at the maze at MSDN Library DHTML
> reference.

maze?  go find another vendor (software, hardware, whatever) that has the
breadth of product offerings that microsoft has that is better organized.

> There is such an incredible quantity of Stuff here now
> that no one person could gain a comprehensive knowledge
> of it.

welcome to the wonderful world of computers.  you're not supposed to have a
comprehensive knowledge of it.  it's all about specialization.

> Are all the features useful? What about - ?
>   - behaviours. What is the point of this? DOM events
>     (and IE's slightly differently-named implementation
>     attachEvent and co.) already provide a clean and
>     elegant way to bind onto objects. Behaviours just
>     provide a way of hiding active content inside a
>     stylesheet.

behaviors are more than just a way to bind functionality to objects.  they
also keep all the logic for that functionality hidden away from the rest of
the script on the page for code integrity.  they keep certain elements of
the functionality private while making certain objects and properties public
for interaction from other sources (functions, events, etc).  behaviors can
be *very* useful when designing a user interface.  they can also greatly
improve the maintenance of an application.

additionally, the idea of behaviors is a standard proposed by the w3c.
apparently there are people outside of microsoft that think the idea has


there's something similar being proposed by mozilla in the continuing work
on the behavioral css spec called xbl or xml binding language (or extensible
binding language as you'll see the version at mozilla.org call it).


see a demo of xbl here:

>   - the default behaviours, which are comical since they
>     provide extra-browser functionality which is nothing
>     to do with scripting document objects (what
>     behaviours were supposed to do).

agreed on most counts.

there are a few that could prove quite useful to someone building a
web-based intranet application -- calendar, colorpicker, masks, sliders,

calendar - in-page dhtml calendar widget

color picker - behavior for selecting a color

masks - to provide for restricted and/or formatted input of data

sliders - custom form widget

whether or not you find the ability to include this sort of functionality
within your applications simply by referencing a behavior is up to you.
however, for those that this works for, it's there to use.

for those interested in behaviors --

overview and tutorials:

using dhtml behaviors (probably the most common way you'll use them):

see a listing of the built-in behaviors here:

reference for default behaviors here:

behaviors reference here:

>     Instead we get UserData (great, it's just like
>     cookies only most people don't know it exists)

userdata is *not* just like cookies.  they're not sent with the http request
so there's no way a site would know they exist unless they request them
directly by name.  the only similarity they share is they're text files
stored on the user's computer.  userdata can be extremely useful when
building a web-based application that requires more user-specific data
storage than a cookie will permit.

for those curious, here's the documentation on userdata:

ok, here's one from nn4.  investigate the navigator object.  you can create
any property of the navigator object you like.  the information in that is
*not* domain specific and can be interrogated by another domain with a
simple for/in loop.

you can find a working example, complete with a test in a different domain,

unfortunately, it appears that ie6 has followed suit and also stores the
info in the navigator object with no regard for the domain that created it.
maybe i should submit a security notice and become famous too.  (don't
nobody go getting *any* ideas.  i've got dibs on this one if it's not
already reported)  ;p

fwiw, ie5 doesn't seem to support the page to page storage of data in the
navigator object.  i'm not sure about ie4 or ie5.5 (james aylard, you and i
talked about this at some length some time ago.  do you recall what ie5.5's
support for this was?).

opera 5 doesn't appear to let you interrogate the navigator object with a
for/in loop (or it doesn't support for/in loops at all -- too lazy/busy to
test that right now).   although it does let you create your own properties
and property values, they don't appear to persist beyond the page they're
set in.

nn6 appears to support creating your own properties and property values, but
they don't persist beyond the page they're created in.

>   - filters/transitions. Presumably this is already
>     built-in to Windows/ActiveX so it's easy for MS to
>     add, but the syntax is alien to existing CSS and all
>     the effects look so weak you're better off using
>     images anyway. With the exception of 'alpha', which
>     isn't really a filter and has a much more sensible
>     syntax already in SVG-CSS.

maybe more sensible to you, but far more difficult to implement.  there are
some amazing effects you can produce with simple images and css using some
of the transitions and filters available in ie.  i agree that some of them
may be weak, but others when used properly can produce some astounding

for example, the alpha filter can be used to make a png's transparency work
properly (in combination with a behavior, no less):


>   - dynamic expressions - another way of hiding active
>     content in a stylesheet.

expressions have their use.  how about never having to write a routine to
watch the resize event and manipulate the size and positioning of elements
on the page ever again?

for those interested in how expressions work, check this out:

and, here's a treat, if you don't like having that stuff in your css, then
don't put it there.  instead, use the setExpression(), getExpression(), and
removeExpression() methods.

>     Anyone else would think a solution to the 'CSS makes
>     mixed-unit layouts tricky' problem would be to add
>     limited CSS-based expressions, but no, MS just
>     charges in with the JScript.

i think javascript in the expressions makes far more sense than some
"limited css-based expressions".  i already know javascript and how to
interrogate and interact with elements in the document.  i don't really want
to have to learn more css.

btw, for a handy list of css attributes supported by internet explorer 5+,
which version, and whether or not it's a part of a proposed standard, keep
the following url bookmarked:


>   - ActiveX, providing web pages access to tons of
>     functionality they were never supposed to get. [...]

same could be said for javascript, applets, or plug-ins.  or, if you're
really of the old school mentality you could say the same for css or even
images.  after all, the web is all about the content, right?  seriously
though, we all have our opinions about what the web is supposed to be, how
browsers should work, etc.

>   - pretty much everything in window.external

maybe not useful on the web (with the exception of the "add to favorites"
method), but extremely useful when building applications.

> Even if MS never added another feature to IE, people
> like Guninski could carry on discovering new holes every
> other week for a long time.

every other week?  hardly.

the last two guninski reported occurred in october of last year and december
of last year.  i wouldn't even count the one in october as it's not even a
security issue, but more of a user interface annoyance issue (must have been
short on actual security related things to post that month).

> > remember that that's only the pr side of the attack on
> > reported security holes.
> Yes, but when I report a bug I don't want the PR side of
> the attack.  I already understand the problem and would
> like them to fix it properly, not waffle, dissemble and
> stall until a few months later someone discovers a more
> dangerous way to exploit the same bug.

you sound like you're talking about a specific happening.

> (Even then, they only fix as much as they need to to
> prevent the exploit - god forbid we should ever
> actually *remove* dangerous undocumented features.)

if the feature has a purpose, whether that feature is useful to you or not,
why should it be removed just because it could potentially be misused?
heck, a screwdriver could be misused (and often is) but you don't see them
being pulled from the shelves do you?  ;p

> Anyway, enough ranting. Microsoft aren't the only
> culprit of course [...]

thanks, now you're making some sense.

> >> Argh! <select multiple>! What do you want, blood! :-)
> > if you're going to do it, do it right eh?  ;)
> I suppose. The real problem is probably more with
> <select size="more than 1"> (which select-multiple
> is by default).  It's a completely different type of
> control to pop-up-select.

yes, quite true.  i've often wondered why they were implemented as the same

> And it involves scrolling, which Opera won't like.

i suspect there's more than just the scrolling which opera won't like.  who
cares anyway.  it's not like all three opera users on the net are likely to
make much difference.  ;p

> And scrolling to a set position isn't possible in
> standard DOM (eg. to show first selected item).

uh, that's silly.  scrolling to a set position can be quite necessary.

> And how should <optgroup> work in select-multiple?

hmmm, how is supposed to work now?  i've never had need to use it so don't
know.  What browsers support <optgroup> anyway?

> Ah well, I'll probably never get around to doing it
> anyway. ;-)


> > [it's nothing to do with whether you like it, it's
> > what the user expects]
> Well that's the odd thing: every other select-box in
> Windows behaves the other way (ie. GE -> Germany).

every other works this way?  try again.

 - months in the "adjust date/time" dialog behaves
   like the browser does.
 - the background sized selector in the display
   properties dialog.
 - the screensaver selector in the display
   properties dialog.
 - the scheme selector in the display properties
 - the colors selector on the "settings" tab of the
   display properties dialog
 - etc.

the only ones that don't work the way you describe are ones that actually
indicate to the user what they've typed in so far like the various dropdowns
that allow font-family selection.  what's interesting is that even those
dropdowns that behave the way you prefer, also allow you to interact with
them the other way -- ie, by typing the first letter over and over again to
move down the list of options (as opposed to creating a string and trying to
match against an option).  this would suggest to me that the way a <select>
works in the browser is how they've worked pretty much from the beginning
and that the behavior you prefer is simply an add-on to cater to the
usability preferences of people like you.

fwiw, noticing that even the more complicated dropdowns work with either
method, i've made some changes to my example to do the same.  now both users
should be fine.  press "a", "a", "a" will take you to the third option that
starts with "a" provided there isn't an entry that has "aaa" as the first
three characters of it's label.

> IE's select-box behaviour is a bit of a wart in this
> regard.  What behaviour the 'average user' would expect
> would probably need a proper usability study to observe,
> but it certainly confuses the hell out of me.

well, in this case it's not an ie-only convention.  this is pretty much the
way a <select> works on all platforms since the dawn of keyboard behaviors
being attached to it.  go check out how the <select> works in nn2, for
example.  ie is actually just following the common convention.

> > i think i'll stick with the escape key to start from
> > scratch or the backspace key to back up in your
> > search.
> And starting from scratch on de-/re-focus would be
> sensible too.

good idea.  i've added that bit of functionality to my example right now.

> > probably the only thing i'd add would be some sort of
> > tooltip that'd popup telling you what you'd typed in
> > so far.
> Like an emacs-style interactive search box?

hmmm, not being familiar with emacs, i couldn't say for sure.  i'll also try
to implement the floating tooltip sometime today.

> About the only thing I can think of is to have the
> script put an unused <span class="icon"> in each
> pseudo-<option> and then have them styled with CSS to
> get the image, eg.
>   <option value="de" id="de">Germany</option>
>   #de .icon {
>     float: left;
>     width: 16px; height: 16px;
>     background-image: url(/img/flags/de.gif);
>     background-repeat: no-repeat;
>   }
> unless you can think some other cunning strategy?

played around with that a bit, but wasn't able to get anything to work.  the
only "background" style property you can apply to an <option> appears to be

oh well, it was worth a try.

maybe i can work off some of webfx's work in this area:


the difference with webfx's example is that it only currently works with ie,
probably due in part to some of the issues you noted above.


jeff at members.evolt.org

More information about the thelist mailing list