RE: Personal stylesheet UI in 4.0 releases (was Re: CSS andpresen tational markup)
> Todd Fahrner [SMTP:firstname.lastname@example.org] wrote:
>Right. Hence the need for a quick toggle mechanism to make personal
>stylesheets meaningful. The only thing more annoying than watching
>pages disintegrate when viewed with personal stylesheets will be
>having to click half-a-dozen times to disable the sheet or select
I agree with you there. But, like I said, the UI is not really my
>I'm sure such decisions are difficult and complex - I'm not expecting
>you to justify it personally. My suspicion (admittedly cynical), is
>that after 3.0's partial implementation and lukewarm reception, CSS
>lost rank in the 4.0 marketing strategy, and consequently in the UI.
>I can't help pointing out that the web is unique among media in that
>"average end users" stand a very good chance of being authors as
>well, and I can't think of a better way to build share than to cater
>to _common_ user/author interests.
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.
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.
>> At this
>> point, it's relatively easy to explain what the "use this stylesheet"
>> option does - but a selection mechanism for multiple user-side
>> stylesheets would be confusing to the majority of our users.
>But the "appearance" dialog is not? Multiple stylesheets could be
>like appearance dialog states, but much more powerful. BTW, where do
>the appearance dialogue settings fall in the cascade?
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.
>> I fail to see, however, how XML will increase the need for
>> stylesheet options. Obviously, without good, solid document-side
>> stylesheet support, XML would be dead in the water with respect to
>> delivering presentation - but it would seem that user stylesheets
>> have a hard time hooking in to XML. If you don't know what elements
>> (gids) are going to occur in the XML content you download, you can't
>> really write a stylesheet for them, can you?
>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
>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'm sure I've expressed this already,
but in case I haven't - I'd love to implement all kind of UI and
controllability for stylesheets in IE. I'd love to put alternate
stylesheet buttons on the toolbars when appropriate. Unfortunately,
this isn't really a major priority for IE4 when compared to many of the
other features we've been working on, and the bugs we need to fix (and
those we have fixed). No matter how many people you throw at a project,
there's a limit to what you can accomplish. We've made some hard
choices in other areas about what we're going to ship, too - but we
really would like to ship a good, solid product _this_ summer. :^)
>> I didn't realize that CSS was
>> positioned as 'an "accessibility" enhancement.'
>So why's it in "View...Options...Advanced...Accessibility"?
_C_S_S_ *ISN'T*. "User Stylesheet" is. CSS is a much larger concept
than just the user side stylesheet. The only document-side stylesheet
UI is the "apply stylesheets" checkbox - which is not in the
>> Incidentally, I can see a way to use our CSS Object Model to write a
>> document stylesheet tester - that is, a way to load documents and
>> through several different stylesheets applied to that document to
>> sure the document still looks okay, without having to mess with the
>> document itself. If someone wants to remind me of this in about a
>> and a half, I can write this up in script and send it out - but I'm
>> afraid I'm far too busy to work on it this week.
>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,
so it is not a perfect solution.
That was, actually, one of the design goals and motivations behind our
development of the Cascading Style Sheet Object Model - to allow, for
example, someone to use Trident as a stylesheet authoring and preview
system, without having to write yet another CSS parser/generator. Since
Trident is an editing component as well as a browser, this was an
important goal for us.