[thelist] Form CSS styles

Andrew Clover and at doxdesk.com
Tue Jan 22 15:11:57 CST 2002


Warning! excessively long and probably quite uninteresting to anyone
other than myself and Jeff <jeff at members.evolt.org>, who wrote:

> Go find another vendor (software, hardware, whatever) that
> has the breadth of product offerings that microsoft has
> that is better organized. ;p

I don't mean the whole of MSDN Library! Just the DHTML
reference. Lumme!

I don't even think it's especially badly organised (though
the frames 'n' ActiveX navigation is a pain in the bum)
- there's just too much of it in the first place!

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

However, when you integrate everything into the web browser
so that everything is available from everything else, a
comprehensive knowledge is exactly what you need, otherwise
you get security holes. The developer of a feature that
accepts URLs has to know which URLs might be dangerous and
disallow them. If he's 'specialising' in his own field and
just sees URLs as pointing to a web document somewhere (as
URLs were originally designed to do, after all), he'll leave
a hole waiting for a 'javascript:...' hack. A developer of
the ActiveX control for playing Windows Media files now has
to worry about his unique ID being stealable from JavaScript.
And so on.

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

Well great, except that any decent language can already do this
without a web browser's help. It's only JavaScript's weak object
model that prevents encapsulation - a proper fix would be to
improve JavaScript or use another language, not add random new
features to the web browser.

The web browser is complicated enough as it is. Adding
complicated new functionality, resulting in a bulkier, slower,
possibly-less-secure browser just to make the web programmer's
life a little easier does not seem like a good compromise to me.
(And I *am* a web programmer...)

> they can also greatly improve the maintenance of an application.

Maybe, but not a normal web site. Your idea of having this extra
functionality turned off by default and enabled by the user when
necessary (eg. the company Intranet) is a good one. This stuff
does not belong on the web.

> additionally, the idea of behaviors is a standard proposed
> by the w3c.

It's still in WD and shows no sign of ever becoming a
Recommendation, thank goodness.

> there's something similar being proposed by mozilla in the
> continuing work on the behavioral css spec called xbl or
> xml binding language

Yes, I personally think that's a waste of time too. (And
it's slightly more annoying than HTCs as being XML-based
you have to keep using CDATA sections if you want to use
'<' or '&' in your code.)

But it's only the idea of hiding scripting in styles through
their use of a 'binding:' CSS property that I find truly
idiotic. Behaviour has simply nothing to do with style.
They're leveraging stylesheets to get themselves Selectors
for free, but nothing else about CSS fits:

 - CSS has no 'additive' properties, so you can't have
   two behaviours on one object in separate rules, one
   will override the other;
 - CSS's basic concepts of cascading and inheritance have
   no sensible meaning for behaviours;
 - Author/user style negotiation makes no sense for
   behaviours (apart from using it to turn behaviours
   completely off !importantly, which is probably a good
   idea <g>);
 - putting executable content in stylesheets means more
   possibilities for cross-site scripting problems; sites cannot
   allow style to be submitted without implicitly (and probably
   accidentally) allowing scripting.

> [behaviour examples]

Yes, I agree a colour picker could be useful. I've made my
own out of DHTML more than once. But if you're going to
build it into the browser, it would seem to be that -

  <input type="color" value="#FF0000">

(or similar) would be a much simpler solution, requiring
no active scripting, and being more-or-less backwards
compatible (since other browsers would revert to type="text"
and allow the user to edit the colour value manually).
Similarly for sliders, something like -

  <input type="range" value="50" size="0-100">

would be handy.

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

What difference does that make? They're a way of storing
information on the client with exactly the same potential for
abuse as cookies. Only we all know about cookies, we can
see them, block them at HTTP level, and manage/delete
them; hardly anyone knows UserData even exists. IE6's
useful Privacy controls don't apply to them either.

It would have been easier for everyone just to allow more
storage space for cookies and give them a "don't submit
this cookie automatically with every HTTP request" flag
than invent a new feature with a whole new set of
possible problems.

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

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

Gahhh!

That's terrible, on both counts. Really, really poor.

Does the same apply to any other objects that are persisted
across documents?

> maybe i should submit a security notice and become famous
> too.

Heh. Yes, I really think you should, you know. I'd rather
like to see that fixed.

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

Yeah, ISTR for/in only works for plain Arrays in Opera, not
objects.

Not that I ever really understood the difference in JavaScript.
Something seems terribly wrong to me if mapping['length'] is
treated differently from mapping['anyOtherString']. But then
I probably already mentioned I don't think much of JavaScript
as a language...

(I don't seem to like anything much really, do I? :-)
Except prawn cocktail flavour crisps. They're very good.)

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

I only meant the simplest type -

  <div style="opacity: 0.5">hello</div>

not any of the wacky advanced SVG stuff. (Mozilla seems to
have implemented this, under '-moz-opacity'.) No more difficult
to implement than it would be with 'alpha', and a considerably
easier syntax.

> there are some amazing effects you can produce with simple
> images and css using some of the transitions and filters
> available in ie.

Well, maybe. I've never seen a non-crap-looking effect but I
suppose it may be possible. :-) I just don't think it's appropriate
for a web browser to have to include image processing
visual effects.

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

Mm. It would have made life easier for everyone, though,
don't you think, if IE had just implemented PNG transparency
properly in the first place? AlphaImageLoader is an acceptable
temporary workaround, but not to have fixed it even in IE6
is poor indeed.

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

Yes. This could have been achieved with simple extensions to
CSS, however, without bringing in all the security worries of
JavaScript.

It also doesn't currently work properly in all situations,
because the browser can't work out which properties changing
would cause expressions to need to be re-evaluated. This is
a direct consequence of using JavaScript: it's a general
imperative (ie. Turing-complete) language, so you can't work
out what it will do without executing it.

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

Indeed not. Microsoft have leveraged your JScript knowledge.
MS love "leveraging" everything. But leveraging does not
usually beget good design.

>> [ActiveX]

> same could be said for javascript, applets, or plug-ins.

Yes, except that JavaScript is limited to what it can do
(or was, until it was allowed to access ActiveX objects),
applets have a security framework built-in, and plug-ins are
bound to filetypes by the user. ActiveX allows you to pick
out and instantiate any object you like, so they had better
all be completely secure or everyone's vulnerable. Of course
they can never all be 100% secure because there's so
blummin' many of them.

> maybe not useful on the web (with the exception of the
> "add to favorites" method)

Well, yes, window.external.addFavorite() is a pretty good
example of what I mean:

 - it's of minimal usefulness, since there's a perfectly
   good 'Add favorite' function in the browser which almost
   everyone knows how to use;
 - it can be used to bookmark a different URL than the
   current page, a feature of little legitimate use
   but handy for fooling people into bookmarking goatse.cx;
 - the add-favorite dialogue box doesn't show the URL
   being added, so users don't even know they're bookmarking
   a page other than the current one;
 - it allows javascript: and other dangerous URLs to be
   bookmarked, thus giving an attacker access to the
   document/cookies/etc. being used at the time the
   bookmark is activated.

MS fixed the last bit of the problem in IE 5.01 Service
Pack 2 by adding a somewhat woolly warning, but only
javascript: and vbscript: are specifically detected - are
all the other URL types safe? There's an awful lot of them
to check now. It would have been simpler not to have
added the 'bookmark an arbitrary page' feature - but
Microsoft just love adding features.

> the last two guninski reported occurred in october of
> last year and december of last year.

People *like* Guninski, said I. ;-) All right, not everything
posted to bugtraq is a proper issue, but the stream of
IE bugs there seems utterly endless. This method doesn't
properly check input, that method gives access to things
it should, on and on forever. I get quite bored of it
really.

> 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

Is that the putting-borderless-windows-above-IE's browser
features issue? If this is what you're talking about I have
to disagree. It may not be a security hole as we know it,
but it's a real problem.

How do we know that the site we're putting our credit
details into is really who they claim? The Location bar
and the padlock icon. How do we know whether to run or
save a file? The text on the confirmation window. And so
on. If a site can fake such browser furniture, all the
clever cryptographic security measures going on in the
background are moot.

Why on earth was the ability to open furnitureless windows
above the browser considered useful, for goodness sake?
It's not a new issue - Java applet windows are clearly
labelled as such for precisely this reason. Any competent
programmer could see it would cause problems, and it's
of minimal legitimate use to a web site. Why was this
capability added?

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

Because it can *only* be misused. For example, the last one
I submitted was to do with URLs in the form
"about:<script>...</script>". There is no possible
legitimate use for this - everything you could do like
that you could just as well do with a plain HTML page. It's
undocumented. It doesn't even work on IE/Mac. It means
yet more filtering work for user-submitted content sites.
But Microsoft *still* won't remove it, only fix a
security hole that it makes visible, and wait until it
interacts with some other feature to cause another hole.

> heck, a screwdriver could be misused (and often is) but
> you don't see them being pulled from the shelves do you?

True, however most manufacturers don't integrate an
electrified spike and a foot-shooting-gun into their
screwdrivers. ;-)

Anyway, back to the less ranty part of the discussion...

> yes, quite true.  i've often wondered why [select-one,
> select-many] were implemented as the same tag.

Yeah. A lot of HTML forms suffers from legacy oddness
really. Wonder how the XForms lot are getting along?

> who cares anyway.  it's not like all three opera users
> on the net are likely to make much difference.  ;p

You're a bad man! :-)

Actually I really like Opera, in theory. They're adding
interesting new gadgets to the UI, which is refreshing as
IE and Netscape's interfaces had been stagnating a bit
recently. The page-zoom control is fantastic, and gestures are
quite nice too. Now they've made a proper SDI interface
available alongside the nasty MDI thing they always had,
I find it quite pleasant.

It's just a pity there's so little DOM support. With that
and the aforementioned 'overflow' support, it'd be a
pretty good browser IMO.

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

Yes, indeed. This side of things has been pretty much
ignored since DOM 2 Views stopped going anywhere. It's
a shame because there really should be standard way
of doing it. The offsetY/scrollY/etc. properties of IE and
Mozilla are okay, I suppose, and I'm damned glad we
have them, but it would be nice if they fitted into the
DOM way of doing things a bit better.

> hmmm, how is [optgroup] supposed to work now?

I think the original idea was to produce hierarchical menus.
However W3C have never followed through on their
threats to make <optgroup> nestable, so it's only
hierarchical to one sublevel.

Mozilla uses it as a 'heading' above a group of
<option>s. Other browsers ignore it (I haven't tried
it on Mac browsers though).

> What browsers support <optgroup> anyway?

Few - all the more reason to implement it in a funky
<select>-replacement script!

> every other works this way?  try again.
> [examples]

D'oh... yes: all menus, it seems, work *both* ways.
Well, that was another pointless argument then. :-)

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

Possibly. W98SE seems to have the same dual behaviour.
I don't suppose anyone's got an old 3.1 installation around to
try?!

> i've made some changes to my example to do the same.
> [...] 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.

Sounds good.

hmm... if we're aiming for exact reproduction of the Windows
behaviour... pressing 'a' if you're on an 'a' entry already takes
you to the next 'a' even if the current 'a' you're on is an 'aa'.
And stuff. It's a bit weird.

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

Yes, I would be replacing the <option> with a <div> from
script to allow it to be more stylable. Not sure whether the
'id' should be moved from the <option> to the new <div>
or whether a new ID should be generated for styling purposes
(eg. <option id="foo" value="Foo!">FOOOOO</option> would
transform to:

  <div id="foo-option">
    <span id="foo-icon"> </span>
    <span id="foo-text">
      FOOOOO
    </span>
  </div>

.) I don't know what I was talking about with Opera and scrolling
- this'll all have to DOM Core stuff, which would never work in
Opera anyway! ah well.

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

Interesting, I'd not seen this before. Looks quite nice.
The fade-effect is interesting.

Doesn't work if JS is disabled though, naughty WebFX!

argh. my fingers ache. good night. :-)

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




More information about the thelist mailing list