Re: [CSS21]-relevant: Opera-bug 122147 (font-sizes)

On Sunday, Aug 3, 2003, at 05:59 US/Pacific, Jörg Hartmann wrote:

>> I happen to agree with you that it is hardly useful to have 3 steps
>> below the most common or body size in documents.
>
> I know you would. This is why actually you propose _simply not to use_ 
> (in
> the h1-h6 hierarchy) one of these steps (x-small). But why have it 
> then? Or
> more precise: why not kill it simply?

I use x-small as an author, along with xx-small and small as well. The 
mapping to the old HTML font sizes and (ill-conceived IMO) heading 
sizes in Mosaic-based browsers is given only to orient the proposal in 
familiar constructs, for clarity, not to canonize legacy usage.

>> But then why not
>> simply, as either an author or user (in user stylesheet) set the root
>> size to "small" or even x-small, and go from there?
>
> As a user? How do I set classes to my own preferences if the author 
> did set
> them to medium, small, ...?

I shouldn't have stepped in that direction. It's a long thorny path 
that I think takes us away from the matter at hand.

>> Jörg, as I opined in a private reply to your concerns
>> earlier, I think
>> the problems you describe would best be addressed in browser
>> prefs UI,
>
> Well, but this is opposite to your proposal. You do _not_ propose that 
> the
> browser's UI should enable the user to set reasonable steps and 
> intervals of
> visual font-size differences, to the contrary you propose a new 
> (strict)
> spec for those steps and intervals which hardens confusion by letting 
> there
> be "different steps within the interval, too small ones --and too 
> many--
> ..." (read above).

Point by point:
- There's nothing in 
<http://www.w3.org/TR/CSS21/fonts.html#font-size-props> that would 
prevent the UI development suggested here. There is no "opposite." I do 
not think the CSS spec is the place to suggest, much less dictate, 
browser UI. WAI UA guidelines are better for that I think, and they 
already exhort developers to assure that users maintain control of font 
sizes.
- "Strict"? The ratios given are suggestions. Guidelines. They were 
developed in amendment of the equally non-normative scaling factors 
given in CSS1 and 2 (1.5 and 1.2, respectively), which were 
demonstrably more problematic than the legacy interval systems they 
would ostensibly retire.
- As for hardening confusion, I don't see how offering hints in a 
non-normative area can do that. Your proposal - to substantially alter 
either the initial value or number of steps above or below - that would 
harden confusion. I think it's far too late to retract normative parts 
of all previous CSS versions, especially now that all major UAs are 
finally getting it right. This goes for many of the more detailed 
suggestions you make as well, IMO.

>> Perhaps show a live preview of the
>> entire keyword range, too, to communicate the reality that this is a
>> system, not an isolated value.
>
> You mean I should create a sample sheet and document?

No, I meant right within the browser prefs UI, so users stop thinking 
of the font size setting(s) as pertaining to something less than an 
entire range of sizes.

> Todd, you see: you _got_ your proposal into the Working Draft. Which 
> means
> it's possible to change things. And believe, it's also possible to 
> really
> change (and cure) the whole system, not only to patchwork around ist 
> most
> visible wrongdoings. Instead of a workaround for the misunderstandable,
> misimplemented CSS1/CSS2 absolute font-size property values, we should 
> ask
> for a real solution. And if this means that medium is no longer 
> initial (or
> maybe there's no medium anymore _at all_), then be it. If you got a
> workaround into the spec's working draft, you'll get a real solution 
> into
> it, too. Don't you think?

For the record, I didn't know that "my proposal" was even under 
consideration until it landed in the working draft. An implementor 
(Tantek?) saw to that, presumably because it solves more problems than 
it creates, such as really rewriting the system would.

Received on Tuesday, 5 August 2003 15:03:22 UTC