Re: CSS3: font-style

It seems like several people who are commenting on the "toggle" attribute
do not understand the utility of such a feature.  The examples people have
proposed really draw atention to this to me; the alternative CSS2
rules people have suggested and the alternative extensions, such as every
toggling every third instance, both fail solve the problem the "toggle"
attribute does.

So let me take a moment to draw attention to the problem:
  Because CSS is by definition a >>cascading<< stylesheet language, style
designers are required to make assumptions about default style for every
user, as well as the inherited style attributes for every instance of a
style.  In some of these cases, such as "font-style:italics;", there is no
way around the assumption (the assumption for italics is that the
surrounding text is not in italics).  In other words, not every CSS2
attribute has an option to define itself relative to it's parent.

Example Problem #1:

If an end-user sets their local stylesheet to:
  blockquote { font-style:italics; }
then the standard
  em { font-style:italics; }
fails to serve it purpose (to draw attention by being typed differently)
in the following example:
  <blockquote>This is an example of <em>emphasized</em> text.</blockquote>

Example Problem #2:

Designers don't always have control of the content, so it is not always
possible to predict every rule necessary.  If I am the designer for a
web-based discussion board that allows simple HTML commands (such as
<em>), and I want to italicize replied (blockquoted) material, I fail to
convey the original meaning by not toggling italics:
My stylesheet:
  blockquote { font-style:italics; }
The original post:
  I <em>love</em> italics.
rendered as:
  <P>I <i>love</i> italics.</p>

A reply to the original post:
  <blockquote>I <em>love</em> italics.</blockquote>
  I <em>hate</em> italics.
rendered as:
  <blockquote><i>I <i>love</i> italics.</i></blockquote>
  <!-- Note the double italics -->
  <p>I <i>hate</i> italics</p>
So, in the above example, redefining <em> to "font-style:normal;" would
break the intent of "<em>hate</em>".  I don't think a designer should be
required to foresee all possible combinations that lead to such problems.

For all the above reasons, I strongly recommend an attribute such as
"font-style: toggle-italics;", as well as a thorough evaluation of all
other CSS attributes to insure we always prived a means for relative
defintions.


Andrew n marshall
 student - artist - programmer
  "Everyone a mentor,  Everyone a pupil"




On Wed, 26 May 1999, Jean-Michel Leon wrote:

> 
> 
> This is a bunch of comments that this proposal triggered in my mind. It
> is not specifically related to that particular proposal, but are some
> thoughts I have about design in general.
> 
> Ian Hickson wrote:
> > 
> > On Tue, 25 May 1999, Nicolas Lesbats wrote:
> > 
> > > Some months ago, I proposed a new value for the 'font-style' property,
> > > named 'toggle' by Daniel Glazman, to get the following behaviour:
> > >
> > > When the inherited value corresponds to 'normal', then apply the
> > > value 'italic'.
> > >  When the inherited value corresponds to 'italic', apply the value
> > > 'normal'.
> > >
> > > So, who is for and who is against ?
> > 
> > Seems like a reasonable suggestion to me.
> > 
> 
> 
> 
> I don't know, but it doesn't seem reasonable to me, because where does
> it stop ? Unless I am missing something (I know I missed the original
> proposal - but again, I am not arguing on that particular topic), why so
> you want to have a special case for 'italic' and 'normal' (I understand
> that the proposals from Ian & David are a potential interesting
> generalization of this). what about 'bold' and 'normal' ? Then you might
> wanna do that for colors, as well ??? Then why not have another that
> skips 1 on 3 levels ???? Then ....
> 
> You should not focus too much on the potential capabilities of CSS,
> without thinking about how people going to use it: most of them are
> going to use tools. and what they do with CSS will be limited by the
> tools. As mentioned by someone else, you can already achieve this result
> by writing more CSS rules. Do you really think a tool is going to
> provide you with a UI that lets you specify this toggle mechanism ? Do
> you really think that the people using these tools have a sense that
> their word processor is working on a tree of objects, and what the
> result of this thing could  be ? Certainly tools (databases) generating
> XML/CSS content would have a better sense of that. But in their case,
> they can just generate perfectly and without effort the right set of
> rules to get the same effect.
> 
> You should think only about the result you wanna have when you render
> the page. If you can achieve this result with what's already existing,
> then you should reject the idea of making the system more complex to
> achieve the same result more easily (in this case, with less lines).
> 
> I know that a lot of us are now writing CSS using emacs & notepad, and
> that this situation is not about to stop, but that's not a good reason
> for making the system more complex. Having ASCII based file formats is
> enough, because it lets people bootstrap and prototype way before the
> tools come out.
> 
> So it's never all black or white, and this particular case is tricky,
> because the proposal would allow to get that toggle effect for any depth
> of nesting, when by writing explicit rules you'd have to stop at some
> point. but isn't that enough for 99% of the cases ? 
> Making your system more complex for solving the last 1% is often a bad
> idea. That's often when you loose simplicity & ubiquity. That's often
> when you loose performance. It is often a better idea to live with that
> missing 1% than to try to cope with it.
> 
> IMO, it'd be more valuable to wrap up CSS and be done with it, so that
> everyone can build on top of that, than spending too much time trying to
> make sure that CSS can do *everything* (even though 90% of everything
> will never be used).
> 
> 
> jm.
> 
>

Received on Wednesday, 26 May 1999 19:32:11 UTC