[thelist] Form CSS styles

[Andrew Clover]

.jeff <jeff at members.evolt.org> wrote:

> i think your account of ie and microsoft's adding of features is quite
> exaggerated -- especially the idea that some features that are added have
> "questionable usefulness".

Really? Take a look at the maze at MSDN Library DHTML reference. There is
such an incredible quantity of Stuff here now that no one person could
gain a comprehensive knowledge of it. 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.
  - 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). Instead we
    get UserData (great, it's just like cookies only most people don't
    know it exists) and HTTP requests with yet more security holes 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.
  - dynamic expressions - another way of hiding active content in a
    stylesheet. 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.
  - ActiveX, providing web pages access to tons of functionality they
    were never supposed to get. And its 'software channel', seemingly
    deliberately designed to sneak executable code onto unsuspecting
    user's machine.
  - yet more unsafe URL types
  - pretty much everything in window.external

and these are just the things I've bumped into myself. I certainly don't
have time to search through all of MSDN looking for holes.

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.

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

Anyway, enough ranting. Microsoft aren't the only culprit of course - it's
being going wrong ever since Netscape dreamed up putting javascript in
URLs - but they're the most pathologically obsessed with adding new
features.

> it's quite frustrating with the number of functional
> elements (namely events) that aren't scriptable with a file input -- like
> the onchange event handler.  sucks that that event doesn't exist for this
> element.

Yeah, I found that one odd too, given that it doesn't prevent scripts from
finding out about changes anyway.

>> 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. And it involves scrolling, which Opera won't
like. And scrolling to a set position isn't possible in standard DOM
(eg. to show first selected item). It can be done in IE and later Mozillae
though. And how should <optgroup> work in select-multiple?

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

> ew, yuck.  i don't like that approach at all.

I admit it does sound dodgy, but it actually works reasonably well (the
current shortness of the timeout notwithstanding).

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

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

> or drive icons.  or folder icons.  or file type icons. or .... you get the
> idea.

Indeed, but how best to implement it? The more flexible solution would be -

  <option value="de">
    <img src="/img/flags/de.gif" alt="">
    Germany
  </option>

which would allow one to put anything in an option. But is, of course,
utterly invalid HTML. (And confuses Netscape, to boot.) The only 'spare'
attribute in <option> to store an image name in would be 'label', but
that would be a bit of an abuse given what it's supposed to do. (No
browsers currently support it, but still...)

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?

-- 
Andrew Clover
mailto:and at doxdesk.com
http://and.doxdesk.com/