RE: Personal stylesheet UI in 4.0 releases (was Re: CSS andpresen tational markup)
At 14:35 -0700 6.9.97, Chris Wilson (PSD) wrote:
> If you mean stylesheets and CSS have lost important in IE 4.0 with
> respect to implementation efforts, you're quite wrong - there's a lot
> more effort going in to implementing CSS in IE4 than there was in IE3.
I recognize and appreciate that. I spoke of marketing, and (I admit)
presumptuously. I wonder whether your hard work isn't getting short
shrift - why bother implementing all that messy cascading stuff if
there isn't a ready means to put it to test (i.e., a prominent
personal stylesheet UI)?
> In terms of marketing strategy, CSS is still a pretty hot item - now
> that Netscape finally supports them too - but obviously, it's not an
> IE-only thing, so the checkbox can't be emphasized in comparisons.
Checkbox comparisons, in software evaluation as in political
campaigns, are a regretably effective way to reduce rich data sets
into thin, deceptive veils. Yes, CSS is supported by the other guy.
So all you can compete on is quality and extent of implementation and
UI - that's a big difference so far!
> I'm not sure what you mean by "the appearance dialog." If you mean the
> font, color and size settings, then they're at the same level as the
> Accessibility dialog - and they are still simpler and easier to describe
> than a switch-between-CSS-user-stylesheets dialog.
The appearance dialog should BE the personal stylesheet
editor/selector mechanism, IMO. It's very confusing to offer them
side-by-side. They're clearly redundant - how do they interact?
> >That's why I chose intranets and special-interest groups as examples.
> >Such groups could develop shared sets of classes/elements and share
> >stylesheets that offer powerful custom viewing options - if only
> >there were a UI. Imagine being able to bookmark stylesheets from
> >various rocket science sites, then applying them across sites or in
> >different parts of a single one, so certain classes are highlighted,
> >for instance, and others obscured. Isn't that what XML will allow?
> Sure - but now you're talking about switching between stylesheets on the
> user end based on which DTD you're using, aren't you? Or do you mean
> you (the viewer) would associate the stylesheets with the documents by
> hand, because you know they're related? Either one I agree is valuable,
> but neither is trivial in terms of code development + testing + user
Sets of class markup on HTML are analogous to new DTDs, yes, and I
meant user/author selection, not engineering magic. I don't mean to
trivialize development efforts, but I think these are good things to
anticipate so as to avoid disruptive UI shifts down the road, when
you have real XML support.
> >Why wait 'til 5.0 to enable this sort of development?
> Heh. Because this is not a less-than-a-day item, and we have a full
> plate of both features and bugs.
I meant "enable users" more than "kill engineers." I don't see how
the stuff I've been talking about would involve extra work beyond UI
and documentation - it's more a matter of packaging and leveraging
plain old CSS1 than "souping it up" somehow. Haven't you done the
hard part already?
> >That sounds great. You know: couldn't you rig something up with
> >frames and this script to make a custom personal UI, to correct the
> >decision I've been criticizing?
> Absolutely, that was my intent. The only drawback is that if you used
> this to browse around, sooner or later you'll hit another frames page
> that will target the top and eradicate the stylesheet frame container...
Doh! who came up with frames anyway? :^)
The printed page transcends space and time. The printed page, the
infinitude of books, must be transcended. THE ELECTRO-LIBRARY.
--El Lissitzky, 1923