- From: Christoph Päper <christoph.paeper@crissov.de>
- Date: Thu, 23 Feb 2012 10:44:42 +0100
- To: www-style list <www-style@w3.org>
Christopher Slye: > On Feb 22, 2012, at 12:28 PM, Christoph Päper wrote: > > Laying-out the big matrix of variations doesn't make much of an impression on me. I wanted to be sure everybody knows exactly what we’re talking about here, not impress. > I don't see it as "more complexity," I see it as "better control." It may be finer control, but that doesn’t mean better, because … > More important to me is what meaning the settings convey, and how often they would be used by most developers, most of the time. … of that. >> I agree, but “font features” to be controlled in this context should be abstracted from Open Type, because OT features are all but perfect. They are neither designed in a coherent manner nor with authors in focus. CSS properties and values should be both. > > By "all but perfect" I think you mean "far from perfect," not "nearly perfect" (which is how I would normally read it). Yes, Germanism, sorry. > We can probably agree the OT features are not perfect, but I find them reasonably coherent in design. Given that most UIs (e.g. InDesign) present many features 1:1 with a familiar name, I'd say they are fairly author-friendly. CSS need not be abstracted for the sake of abstraction; many features (e.g. 'onum') are fairly straightforward. The digit styles in particular are a good example why we shouldn’t map OT features 1:1 to CSS. In a user-centric approach – where the user is a stylesheet author or web designer and not a font developer – detailed control often is a secondary requirement. First we have to make the most common usecases easy to deal with. table { /* make digits monospaced, casing is unimportant: */ font-variant: tabular; } h1 { /* make digits (and letters) uppercase, width is unimportant: */ font-variant: titling; text-transform: uppercase; /* implied? */ } A CSS author usually doesn’t care in these cases which combination(s) of ‘lnum’, ‘onum’, ‘pnum’ and ‘tnum’ would yield the desired result. The current keywords are 1:1 aliases and that’s bad user interface design, in my humble opinion. <http://lists.w3.org/Archives/Public/www-style/2011Mar/0183.html> >> the initial value ‘normal’ relies on the default settings inside the font. > > There is no such setting inside the font. Then the draft needs changing, because it currently reads: A value of ‘normal’ implies that the defaults set by the font are used. > Historical alternates are something quite separate IMO, and I can easily imagine historical ligatures conflicting with standard or discretionary ligatures. It seems better to keep them apart. I once suggested to combine ‘hlig’ and ‘hist’ within a keyword (for the shorthand property) like ‘historical’, ‘historic’ or ‘old-fashioned’. >> :root {font-variant-ligatures: common-ligatures;} >> span {font-variant-ligatures: discretionary-ligatures;} > > I could just as easily assert that: (…) is adequate for either proposal. Okay, but then your point that the new syntax was more verbose is moot. > Setting them all off explicitly as per the current WD seems unnecessarily verbose. I agree, but that’s what easily follows when you map binary font features 1:1 to CSS keywords. >> When or where would you want ‘dlig’ to be on, but not ‘liga’? >> >> Would you like ‘additional-ligatures’ or ‘optional-ligatures’ better? >> >> Which one of the above would you prefer? (‘i’ means inherit, ‘d’ is font default.) > > I suppose: ‘discretionary-ligatures’ ⇔ ‘liga’ := i, ‘dlig’ = 1, ‘hlig’ = i So I thought. As far as I understand implementation details, it’s complicated to inherit (“i”) properties partially. If we had properties ‘font-variant-ligatures-discretionary’ you could use that and have the shorthands ‘font-variant-ligatures’ and ‘font-variant’ reset non-specified sub properties (as this is common in CSS), but I think limiting the number of new (sub) properties to the bare minimum is a design choice the WG agreed upon. > I prefer that 'discretionary-ligatures' have no effect on the setting of standard or historical ligatures. Are your objections mostly about the name of the keyword then? > I agree that in most cases 'dlig' would be enabled along with 'liga', In this case, ‘foo-ligatures’ (‘liga’=1, ‘dlig’=1) would be a good companion to ‘bar-ligatures’ (‘liga’=1’). > but there's nothing stopping a font developer from making them mutually exclusive (…). If that’s a common scenario, we could add ‘baz-ligatures’ (‘dlig’=1). I don’t care that much about the actual names of the placeholders foo, bar and baz. In any case, we should spare ourselves of ‘no-…’ keyword variants. >> No, it wouldn’t, because the average (website) developer is not a font designer, too. > > … My opinion is based on the same reason, … The hostname of your email address triggers certain stereotypes.
Received on Thursday, 23 February 2012 09:45:03 UTC