- From: Wingnut <wingnut@winternet.com>
- Date: Wed, 15 Jan 2003 12:15:36 -0600
- To: www-html@w3.org
A recent post contained... > > Everyone defending style attribute just repeats how that's needed in > real world problems but nobody is seems to be able to show even one > reasonable example. > Ok, as low-impact as this may turn out to be... MOOzilla, a MUD/MOO client appliction based upon Mozilla... requires that moo output headed for its gecko screen, in order to have styling, use an embeded style param in the element. MOOzilla probably COULD maintain a 'style state' by assigning one at logon to a MOO/MUD, but currently it doesn't. That's because, in a way, MOOzilla is a NODE VIEWER and not really a classic browser or telnet client. When you deal with node viewing (rendered), you may or may not have a style state active, and/or a set of references to ID's or classes. When one physically inserts the style into the element itself... there are no outside dependencies and a HTML-based node viewer app would/could render it nicely. The node, can stand alone, or with its rulestring... and even then, it stands alone, without dependency. A node that stands alone, with its style in its pocket... does have some handy uses for transcluders. In the MOO, server side... I have a styling system for MOOzilla that, although the styles are derived from 122-property css rule objects... they compile into rule-strings, and are handed around and inserted into elements in that form. They are each bound for a 'style=[rulestring]' that gets stuck inside of some element. Granted, there are likely only 10-20 MOOzilla users running around so far, and even less know about styling practices for it... but someone seemed desparate for a real world example. ID, CLASS, STYLE ELEMENTS, HEAD, BODY, LINK... all do nothing for MOOzilla... but likely someday could. All in all, currently, style params embeded in *ml elements are essential to that app and system. Best! Wingnut MOO pig
Received on Wednesday, 15 January 2003 13:19:50 UTC