Christopher Slye | 1 Apr 01:15 2010
Picon

Re: [css3-fonts] various comments and typos


On Mar 31, 2010, at 1:04 PM, John Hudson wrote:

> Actually, I think this concept of 'Titling Capitals' needs to be 
> re-thought. The OpenType Layout feature <titl> does not specify capitals 
> at all, only 'Titling' forms. While a number of font implementations 
> provide only capitals in Titling form, there is nothing in the feature 
> description to limit glyph coverage to capitals.

Indeed. The 'titl' feature in Adobe Garamond Pro contains what was the (pre-OpenType) Titling font of that
family, which is essentially a complete MacRoman font, minus lowercase. In other words, it has a full set
of titling forms for punctuation, numerals, currency, etc., in addition to uppercase letters.

> Not if implemented in OpenType Layout. A font can support arbitrary 
> fractions, using contextual substitutions of numerator and denominator, 
> without reliance on Unicode predefined fractions or, indeed, even the 
> presence of precomposed glyphs for such fractions.

Correct -- but note also that in most Adobe fonts with arbitrary fractions, the feature does produce
precomposed fraction "ligatures" when available (typically one-half, fourths, thirds, and eighths)
and arbitrary fractions for anything else. (In the latter cases, this would probably include a
substitution from a default slash character to a stylistic alternate that looks like a fraction-slash.)

Anyhow, the current description implies that feature 'frac' would be applied to a run of text, so from an
OpenType perspective this seems correct.

-C

Christopher Slye | 1 Apr 01:35 2010
Picon

Re: font-variant-caps: all-small-caps

Getting back to this, vis-a-vis the discussion at yesterday's meeting...

I agree with Adam. Case transformation is not always a lossless process, so relying on a technique which
takes characters from uppercase to lowercase and back to uppercase (small caps) is clearly worse that
simply going from one style of uppercase to another (i.e. uppercase -> small caps).

And yes, the 'c2sc' feature often does contain stylistic alternates intended to harmonize with
all-small-caps settings. For example, some fonts will include a set of numbers, currency and
punctuation (e.g. parentheses, exclamation point) to be used in all-small-cap settings. These will not
appear as intended when text is first converted to all lowercase, then 'smcp' applied.

Adam, regarding this:

> Some fonts can have "smcp" lookups and then "c2sc" lookups that rely on the preceding "smcp" lookups, so an
intended result is produced when both features are applied.

Can you cite an example? Just curious.

-Christopher

On Mar 22, 2010, at 1:17 AM, Adam Twardoch (List) wrote:

> John,
> 
> On 10-03-01 09:54, John Daggett wrote:
>>> For example, the small-cap variants of certain uppercase Greek letters
>>> may be different than the small-cap variants of their lowercase
>>> counterparts.
>>> 
> Forget it, this is not a good example :)
(Continue reading)

Stephen Zilles | 1 Apr 03:36 2010
Picon

Another cut on the Character-Transform Property

John, 

  Per my action item from the CSS F2F meeting, I suggest the following change to  text of 6.2

The current description (March 26) is:

6.2 Positional character forms: the character-transform property

Name:

character-transform

Value:

normal | subscript | superscript | ordinal

Initial:

normal

Applies to:

all elements

Inherited:

yes

Percentages:

N/A

Media:

visual

Computed value:

as specified

The values ‘subscript’, ‘superscript’ and ‘ordinal’ imply the appropriate variant glyph is displayed when available in the font (OpenType features: subs, supr, ordn). When a variant glyph is not available, a simulated version is synthesized using a reduced form of the default glyph. Normal implies use of the default glyph at normal size. When the value is anything other than ‘normal’, the font-size and vertical-align properties are set to ‘inherit’.

Description I would change the semantic paragraph to read as follows:

The values ‘subscript’, ‘superscript’ and ‘ordinal’ imply the appropriate variant glyph is displayed when available in the font (OpenType features: subs, supr, ordn). These variant glyphs are displayed using the font-size and vertical-align properties of the parent of the element to which ‘character-transform’ applies. When a variant glyph is not available, the font-size and vertical-align properties on the affected element are used to scale and position the normal glyph for the given code point. The value ‘normal’ always displays the normal glyph for each code point at the content of that element. using the font-size and vertical-align properties on that element.

This approach does not require making character-transform into something like a shorthand, but not quite. It also allows the font-size and verticial-align values to be propogated to nested super-(or sub-)scripts so that they decrease in size and stack correctly. It also means that the behavior of current content (under the ‘normal’ value) does not change and that things like images in the content of the element affected by character-transform are made to appear as super-(or sub-)scripts although they may not line up with the other glyphs unless they are sized appropriately.

 

Finally, I am not entirely happy with the name “character-transform”. It is not the character that is transformed; if anything is transformed it is the glyph. How about names like, ‘use-font-feature’ or ‘use-font’ or ‘use-feature’?

 

Steve Zilles

 

Justin Poirier | 1 Apr 05:30 2010
Picon

Re: [CSS21] stack level definitions in 9.9.1

I'm convinced by Anton's assertion that "stack level" is used to mean two different things in 9.9.1, referring to both z-index value and the 7 painting layers.
I'd like to point out that the larger issues presented in Anton's paper[b] regarding stacking contexts vs. stacking context-like elements, while they may not be dealt with until a much later date (Maybe someone can update me. An Oct 21 08 msg from Ian Hickson said they'd be kept in mind for CSS3...), might make the present issue moot depending on how they're resolved. Anton has suggested introducing the term "painting context" to refer to contexts created for elements without an int z-index, and using the term "stacking context" only for elements with an int z-index. Alternatively, he suggests the respective terms "stacking context" and "strong stacking context". Whatever the solution, I would propose we rethink our introduction to painting order (9.9.1), starting with the complete removal of the list of 7 painting layers.
This list promotes a simplified and erroneous understanding of the topic. It implies that a general solution to determining a page's painting order will involve considering various-sized portions of the page (branches of the tree of elements) one at a time, and applying an algorithm to each; with the only overlap between portions being the fact that some are contained in others (since the alg is recursive). This is not the case. As I tried to point out in an article (http://classroom306.com/tutorials/z-index.html) that I wrote and mentioned on this list a year ago, the steps in the alg that recursively deal with descendants with int z-index are ONLY carried out in contexts that THEMSELVES have int z-indices. This is why Anton made the distinction in his paper between stacking contexts and stacking context-like elements. They are both types of "portions of the page" to which the alg will be applied, but they are different types and form different types of relationships in terms of which ancestors paint which descendants. For example, Figure 1 in my article shows 3 true stacking contexts which are painted as part of the root stacking context, despite being separated from it by multiple generations of stacking context-like elements. It should be clear that there is no general way of telling which elements will be dealt with together based on their proximity in the tree, as implied by having a "definitive" list of 7 painting layers. In reality page rendering can only be described as repeated applications of the complex alg described in Appendix E, each acting on SOME elements of the page. The only way of knowing which elements of the page will be dealt with together is by understanding the alg. I understand that it's a complex alg but I see no other way for a web designer to understand painting order and not be confused by its behaviour for certain document structures. Sugarcoating the concept with a list of painting layers doesn't help. Maybe someone can offer another option.

Thanks,
Justin Poirier
classroom306.com

On Sun, Mar 28, 2010 at 3:32 PM, Anton Prowse <prowse <at> moonhenge.net> wrote:
Sylvain Galineau wrote:
(The following aims to address issue 60 : http://wiki.csswg.org/spec/css2.1#issue-60)

I've rearranged your email for the purposes of replying.  I hope this
doesn't cause any confusion!



Due to the volume of input provided for this issue[a][b][c], I will
first summarize the *minimal*
set of changes I believe to be necessary to resolve it.

1. In section 9.9.1 [1], replace:
     # 4.a stacking level for non-positioned floats and their contents.
  with:
     # 4.a stacking level for non-positioned floats.

This resolves part of [b: 2.10].  The remaining part (the addition of
"non-positioned") has already been fixed, as you stated.



2. In section 9.9.1 [1], replace:
     # 2.the stacking contexts of descendants with negative stack
     # levels.
  with:
     # 2.the stacking contexts of positioned descendants with
     # non-zero negative z-index in
     # z-index order (most negative first).

3. In section 9.9.1 [1], replace:
     # 7.the stacking contexts of descendants with positive stack
     # levels.
  with
     # 7.the stacking contexts of positioned descendants with
     # non-zero positive z-index in
     # z-index order (1 first).

Changes in #2 and #3 are meant to precise and align 9.9.1 stacking
level descriptions with Appendix E's.

They succeed in that.  However, interestingly, you've distanced yourself
from the term "stack level".  In doing so, we've gone from "stack level"
being first defined as a façade for z-index yet later being used to
encompass painting layers (see my discussion of 2.8, below), to now
reducing its use as a façade for z-index.  This leaves us in the strange
position of going to great lengths to introduce a term which is then
barely used in the subsequent prose!  Aside from its definition, the
only paragraph in which it would appear is:

 # Each box belongs to one stacking context. Each box in a given
 # stacking context has an integer stack level, which is its position
 # on the z-axis relative to other boxes in the same stacking context.
 # Boxes with greater stack levels are always formatted in front of
 # boxes with lower stack levels. Boxes may have negative stack levels.
 # Boxes with the same stack level in a stacking context are stacked
 # back-to-front according to document tree order.

The second and fifth sentences are incorrect, as I discuss in detail
below in relation to [b: 2.8].  The third and fourth sentences could
easily have "stack level" replaced by an explicit reference to z-index
as you have done in your proposals (2) and (3) which we're currently
discussing.  Indeed, rewriting the third sentence would remove the need
for your changes to state "most negative first" and "1 first" which, to
my mind, don't quite do the job of expressing the fact that the stacking
occurs with strictly ascending z-index.

So assuming that my argument for 2.8 below convinces you and the second
and fifth sentences get corrected, there is no need whatsoever to
preserve the term "stack level" and it can be omitted altogether from
the spec.  (Note that in my proposed two rewordings, I was trying to
cause as little disruption as possible to the concepts already
introduced, and so I preserved the "stack level" concept and instead
fixed the surrounding text to be consistent with it.  I'm actually
happier to drop the "stack level" terminology altogether, and to go
along the lines of your proposals here, instead.)



4. In Appendix E, E.2 [2], replace:
     # The stacking context background and most negative positioned
     # stacking contexts are
     # at the bottom of the stack, while the most positive
     # positioned stacking contexts are
     # at the top of the stack.
  with:
     # The stacking context's background is at the bottom of the
     # stack, immediately below its
     # descendant stacking context with the most negative z-index.
     # The descendant stacking
     # context with the highest positive z-index is at the top of
     # the stack. The stacking level
     # of all the other elements in the stacking context is defined
     # by the painting order below.

Change #4 gets rid of 'positioned' as a way to describe stacking
level as it seems inappropriate here

Agreed.  (Superfluous, rather than inappropriate; every stacking context
arises from a positioned element (although the converse is false).)



and reintroduces stacking level as a synonym for 'layer in the
painting order'.

The original sentence isn't really needed at all, since the algorithm
which follows explicitly describes the stacking order.  (What's
/actually/ needed there is a clarification that the stacking algorithm
is recursive, which is implied but not currently explicit.)  I'm not
sure what the value is in bringing the term "stacking level" (once, and
only once) to Appendix E where it did not appear before.  Why is it
needed in Appendix E which until now cared nothing for "stack levels",
"stacking levels", "painting layers" etc?



5. In Appendix E, E.2 [2], replace:
     # The stacking order for an element generating a stacking
     # context...
   with:
     # The painting order for the descendants of an element
     # generating a stacking context...

Change #5 aims to be a more precise description of what follows.

I too prefer the use of the phrase "painting order" here.



Background
----------
Stacking contexts is currently described in 9.9.1 [1] and Appendix E
[2]. Both sections are normative and address the same topic with
a significantly different levels of details. To an extent, one could
see Appendix E as the implementor version of a more author-oriented
9.9.1.

That's my take on the situation, too.



As much of the feedback describes differences between these two
versions, the WG should discuss whether it would be appropriate to
have 9.9.1 refer to Appendix E for all painting order information.
My personal preference is to maintain the flow and readability of
this spec of the document by preserving an accurate higher-level
version of Appendix E.

I agree with this aim.


As for the issues originally raised by Ingo Chao [a] and myself [b]:


Both [a] and subsequent elaboration [aa] deal with terminology
confusion; in 9.9.1, the term 'stacking level' is used to describe
both discrete integer z-index values as well as painting layers:

     # This integer is the stack level of the generated box in the
     # current stacking context.
     ...
     # Each stacking context consists of the following stacking
     # levels (from back to front):
        # 1.the background and borders of the element forming the
        # stacking context.
        # 2.the stacking contexts of descendants with negative stack
        # levels.

So stacking level #2 is made of those elements with a negative stack
level that are....on top of stack level #1. What the prose is really
saying is the second stacking level is where positioned
descendants with negative z-index are painted in z-index order
starting from the most negative.

Indeed.  However, you haven't actually addressed the problem.  Even
with your proposed changes, there remain places in the prose which use
the term "stack level" to encompass the concept of "stacking
level"/"painting layer", which leads to inaccuracies in the current
wording of the spec.



Then in Appendix E, the 'stacking level' term disappears and becomes
'stacking order', under a paragraph heading of 'Painting order'.

"Stacking order" is a synonym for "painting order", and is not a
conceptual part of the model but merely another way of saying "the order
in which the elements are painted".  (The algorithm then describes that
order, without reference to the /concepts/ of "stacking level"/"painting
layer" and "stack level", both of which were introduced solely for the
purposes of the "friendly description" of the model in 9.9.1.)

I see no problem with these terms.



Regarding [b], most of the issues raised are editorial

I do not recommend resolving the issues deemed editorial [...] as

proposed. While the prose *can* be rewritten as suggested, the WG
needs evidence of the *need* to accept the extensive proposed
rewrites [4][5] together with new terminology ('strong stacking
contexts', 'painting context', 'containing painting context') in
this already relatively complex area.

I sympathize with those concerns.  However, I point out that all of the
issues could be resolved without the introduction of new terminology.  I
was careful to separate the analysis of the problems from the proposed
rewordings, and the two rewordings I presented are merely one approach
to patching up these editorial issues.  (Also, note that even if you
were to choose one of the rewordings, only one of the first two terms
you quoted is needed, depending on which proposal is chosen.)

Moreover, many are editorial in the sense that 9.9.1. is ambiguous or
even technically incorrect while they persist, rather than merely
containing typos or clumsy language.

I would like to see all these issues addressed, but it's certainly not a
requirement that one of my proposed rewordings is used to achieve that.



- Problem 2.1: the issue is editorial

Agreed.



- Problem 2.2: the issue is editorial
- Problem 2.3: the issue is editorial
- Problem 2.4: the issue is editorial

These go hand-in-hand, and they are editorial in the sense that the
reader is unlikely to make a wrong interpretation of what the spec
currently says.  However, there's no doubt that the current wording is
inaccurate.


- Problem 2.5: the issue is editorial
- Problem 2.6: the issue is editorial

Agreed.



- Problem 2.7: the issue is editorial

Agreed; however, the concept of "two stack levels" as currently exists
in the spec is clumsy, needless, and unnecessarily complex.  It also
itself introduces new terminology ("local stacking context") which is
superfluous since it is unused outside of the definition of z-index.



- Problem 2.8: the issue states that the painting order of
non-positioned/z-index:auto elements within a stacking context is
not defined in 9.9.1. It is addressed below.

My response is also below.



- Problem 2.9: this issue is editorial and essentially the same as
the original issue raised in [a] and addressed in changes 2-5  above.

It overlaps the original issue raised in [a] by Ingo Chao, but it's not
quite the same and I disagree that either is fully addressed by your
proposed changes.  Those changes help to reduce the intermingling of the
terms "stack level" and "stacking level" raised in [a] and [b: 2.8], but
they don't address the fact that these are still two different
concepts in your proposals, with confusingly similar names (which is the
subject of the current discussion, also raised in [a]).

I agree that this issue, [b: 2.9], is editorial.  As I have mentioned
above, we can  easily get rid of "stack level" altogether; and as I
mention below, doing so would be one way of resolving problem 2.8.


[ - Problem 2.10: addressed by change proposal (1) above. ]



- Problem 2.11: this issue is a typo in 9.5 also mentioned in [d]
that is fixed in the latest version of the specification [3]

Indeed, this is now fixed.



L. David Baron requested testcases thus [6] :
A testcase that one part of the spec says should be displayed in one
way and another part says should be displayed another way is
evidence of an error in the spec.  A testcase that the spec says
should be displayed one way but you believe should be displayed a
different way indicates a potential error in the spec (if your
belief is correct).

Without one of those types of testcases, you haven't demonstrated an
error in the spec in a way that we can understand.

Testcases were then offered in [c]:

- The issue raised  by the first testcase [c.1] is addressed by
recommended change #1 above.

[c.1] also brings up the following issue:

9.5 Floats currently states that the contents of floats are stacked as
if floats generated new stacking contexts, except that any positioned
elements and elements that actually create new stacking contexts take
part in the float's parent stacking context.

This information is not present in 9.9.1.  I suggest that this
information be moved to or repeated in 9.9.1.


- The issue raised by the second testcase [c.2] is also addressed by
 Change #1.

Agreed.



- The third testcase [c.3] is a testcase for problem 2.8 in [b].

(The citation [c.3] was incorrect; it should have been
http://dev.moonhenge.net/css21/spec/z-index/testcases/stack-level-of-non-positioned-elements.html
)


The testcase states that the prose in 9.9.1
does not allow the red inline to be on top of the green float. This
seems incorrect since the painting order
defined in 9.9.1 is back-to-front and non-positioned floats (#4)
precede in-flow inline-level non-positioned
descendants.

Not so.  The test case -- which attempts to be of the first kind
helpfully described by David: one that one part of the spec says should

be displayed in one way and another part says should be displayed
another way -- states that there is a *contradiction* in 9.9.1.

On the one hand, 9.9.1 does indeed say that the painting order, from
back to front, places non-positioned floats below non-positioned in-flow
inline-level descendants.  (Note that this is what I intended to say in
the final bullet-point in the description beneath the test case, but
looking at it now it appears to have come out garbled. The intention is
clear from the subsequent paragraph, however.)

On the other hand, 9.9.1 also says that boxes with the same stack level
in a stacking context are stacked back-to-front according to document
tree order.  Now, we all know that the spec is really talking about one
those seven listed painting layers in 9.9.1, and hence doesn't intend to
introduce a contradiction because non-positioned floats are on a
different layer than in-flow inlines and hence the statement about
document tree order doesn't apply.  But that's the problem: it *doesn't*
use the term "painting layer", or even the term "stacking level" that is
used when introducing the seven layers (and which is never heard of
again).  It uses the term "stack level" which is an imprecise concept
introduced earlier in 9.9.1 based on z-index and not based on the seven
listed layers.

I point out that the test case isn't particularly useful here, but it
was requested and I'm not sure what more one can do to attempt to
demonstrate a logical contradiction arising from inconsistent
definitions in the prose with a test case.  I suggest that the bullet
points in the description of the test case, which present the logical
steps to build up the contradiction, are rather more important than the
test case itself.

To summarize the issue: the definition of stack level is faulty.  The
spec states that "each box in a given stacking context has an integer
stack level", yet this is patently untrue.  A non-positioned in-flow
inline doesn't (as currently specified) have a stack level, and
certainly not one which is numeric, let alone integral.  What it *does*
lie on is a "painting layer"/"stacking level" within the containing
stacking context, and these layers are ordered according to the list.
The term "stack level" as currently employed tries to encompass,
unsuccessfully, both the concept of integer z-index and the concept of
the seven painting layers within a stacking context.  Yet these are
fundamentally different things.


Further, it is unclear why a computed numeric value needs to be
assigned to the z-index property
for these elements

I didn't say that it did.  The z-index property is fine.  It's the
"stack level" concept that's problematic.


since a) the property only applies to positioned elements and b)
neither the span or float
in the testcase establish a stacking context.

Precisely!  The trouble is that the the term "stack level" is introduced
as a friendly façade on the z-index concept, but which is then applied
to boxes to which z-index doesn't apply: "Each box in a given stacking
context has an integer stack level".  If we're going to insist on
muddying the waters by allowing the "stack level" concept to encompass
not only z-index but also the painting layers concept (which personally
I disagree with, but which I incorporated into in my proposed rewordings
to minimize the disruption to the existing prose) then we do at least
need to ensure that it's internally consistent.  I introduced the extra
computed numeric values *to "stack level"* because I was trying to
preserve the existing phrase "Boxes with greater stack levels are always
formatted in front of boxes with lower stack levels."  This only makes
sense if stack levels for non-positioned boxes are (a) defined, (b)
numeric and (c) different for the different painting layers in the list.

Note that I could have reworded the problematic phrase to only apply to
positioned elements (ie, only to elements to which the z-index property
applies), and then it wouldn't be necessary to introduce new numeric
values of "stack level".  But I was trying to be as faithful as possible
to the existing wording.

As I said above, to resolve this problem, I'd be equally if not more
happy to remove the "stack level" concept altogether, and talk about
either z-index/positioned elements or "stacking levels"/"painting
layers" where appropriate; that is, to more carefully separate the two
concepts.



The painting order stacks described in 9.9.1 and Appendix E agree
on their proper position. All major browsers render this testcase interoperably.

Indeed!  The test case states that the rendering shown is in accordance
with Appendix E, and the list in 9.9.1 matches the Appendix E.  Its
purpose is to describe the additional, contradictory rendering implied
by the current text, as described above.  Again, I don't really see the
value of a test case for analyzing this issue, but it was requested.


So, to summarize my response:

*) Your proposed changes partially solve test case [c.1] and fully solve
test case [c.2] / issue [b: 2.10].

*) The remainder of test case [c.1] can be solved by copying or moving a
paragraph from 9.5 Floats to 9.9.1. where it is equally if not more
relevant.  This partially solves editorial issue [b: 2.2].

*) Test case [c.3] (corresponding to problem [b: 2.8] is not solved.

*) Your proposed changes removes the dependency of the list of "stacking
levels"/"painting layers" on the problematic concept of "stack level".
In doing so, they help illustrate that there is little need for the
concept of "stack level" in the first place.  It could easily be
removed, and doing so would also solve problem [b: 2.8], fix the
editorial clumsiness in [b: 2.7], and remove the potential for confusion
described in [b: 2.9].

*) I'm unconvinced by your proposed change (4), and rather think that if
Appendix E needs modifying at all then it should be to clarify that the
process of laying out stacking contexts is recursive.

*) Regarding the remaining issues in [b] which you deem editorial, none
requires new terminology to fix (although I chose to go down that route
in my own suggested rewordings).  Also, several are more than merely
scruffy, in the sense that 9.9.1. is ambiguous or even technically
incorrect while they persist. Should read:
http://dev.moonhenge.net/css21/spec/z-index/testcases/stack-level-of-non-positioned-elements.html Cheers,
Anton Prowse
http://dev.moonhenge.net

























Patrick Garies | 1 Apr 05:47 2010
Picon

Re: CSS3 reference

On 2010-03-31 3:27 AM, Markus Ernst wrote:
> Trying to find the specification of the content() function I gave
> up...

I've never heard of a function. If you're looking for the |content|
/property/, that's in the CSS3 Generated and Replaced Content Module.

See <http://dev.w3.org/csswg/css3-content/#content>.

> I think a reference of the current state of CSS would be very
> helpful. I think of a list of properties and functions (and maybe a
> selectors section) with links to the drafts where they are
> specified.

Maybe the Current Work page would be helpful?

See <http://www.w3.org/Style/CSS/current-work>.

There are also the CSS Snapshot documents, but they don't seem that
useful and I can only find the one from 2007. I thought that the WG had
published a new one, but apparently not.

See <http://www.w3.org/TR/css-beijing/>.

Thomas Phinney | 1 Apr 06:20 2010
Picon

Re: Another cut on the Character-Transform Property

Steve's proposal seems sound. But I don't think his names are much better than the original: those names tell me even less about what the feature might do, and like the original name could apply to any feature. Maybe "glyph-position" or perhaps "text-position"?

On Wed, Mar 31, 2010 at 6:36 PM, Stephen Zilles <szilles <at> adobe.com> wrote:

John, 

  Per my action item from the CSS F2F meeting, I suggest the following change to  text of 6.2

The current description (March 26) is:

6.2 Positional character forms: the character-transform property

Name:

character-transform

Value:

normal | subscript | superscript | ordinal

Initial:

normal

Applies to:

all elements

Inherited:

yes

Percentages:

N/A

Media:

visual

Computed value:

as specified

The values ‘subscript’, ‘superscript’ and ‘ordinal’ imply the appropriate variant glyph is displayed when available in the font (OpenType features: subs, supr, ordn). When a variant glyph is not available, a simulated version is synthesized using a reduced form of the default glyph. Normal implies use of the default glyph at normal size. When the value is anything other than ‘normal’, the font-size and vertical-align properties are set to ‘inherit’.

Description I would change the semantic paragraph to read as follows:

The values ‘subscript’, ‘superscript’ and ‘ordinal’ imply the appropriate variant glyph is displayed when available in the font (OpenType features: subs, supr, ordn). These variant glyphs are displayed using the font-size and vertical-align properties of the parent of the element to which ‘character-transform’ applies. When a variant glyph is not available, the font-size and vertical-align properties on the affected element are used to scale and position the normal glyph for the given code point. The value ‘normal’ always displays the normal glyph for each code point at the content of that element. using the font-size and vertical-align properties on that element.

This approach does not require making character-transform into something like a shorthand, but not quite. It also allows the font-size and verticial-align values to be propogated to nested super-(or sub-)scripts so that they decrease in size and stack correctly. It also means that the behavior of current content (under the ‘normal’ value) does not change and that things like images in the content of the element affected by character-transform are made to appear as super-(or sub-)scripts although they may not line up with the other glyphs unless they are sized appropriately.

 

Finally, I am not entirely happy with the name “character-transform”. It is not the character that is transformed; if anything is transformed it is the glyph. How about names like, ‘use-font-feature’ or ‘use-font’ or ‘use-feature’?

 

Steve Zilles

 




--
"The rat's perturbed; it must sense nanobots! Code grey! We have a Helvetica scenario!" — http://xkcd.com/683/
Peter Linss | 1 Apr 07:30 2010
Picon

Re: CSS3 reference

On Mar 31, 2010, at 8:47 PM, Patrick Garies wrote:

> On 2010-03-31 3:27 AM, Markus Ernst wrote:
>> Trying to find the specification of the content() function I gave
>> up...
> 
> I've never heard of a function. If you're looking for the |content|
> /property/, that's in the CSS3 Generated and Replaced Content Module.
> 
> See <http://dev.w3.org/csswg/css3-content/#content>.

The content() function is defined here:
http://dev.w3.org/csswg/css3-gcpm/#string-set

Axel Dahmen | 1 Apr 12:52 2010
Picon

Re: CSS3: Suggestion for another list-style-type

"Tab Atkins Jr." <jackalmage <at> gmail.com> schrieb im Newsbeitrag 
news:dd0fbad1003300723s2df06d6btf4aa0d9834086c71 <at> mail.gmail.com...
> We had a brief discussion about it during a break in our meetings
> yesterday, though, and think that your original suggestion (allowing
> list-style-type to take a string) is a good idea.  We'll be reviving
> the Lists module in the near future, and there's a good chance we'll
> add that functionality.

That's great news.

>  Even though it's easy to just use the content
> property for this, allowing it in list-style-type means that it will
> cascade properly with other list-style-type declarations.

Exactly.

"Brad Kemper" <brad.kemper <at> gmail.com> schrieb im Newsbeitrag 
news:7e1f93761003301034j2ed9ecd2k89228c5a57c2e04a <at> mail.gmail.com...

> A few of us did, anyway (it wasn't part of the minuted meeting
> of everyone present). I also posed the idea of list-style-type
> being a sort of shorthand for ::marker { content: \ 2022; },
> but that causes problems with the cascade.

I understand. As far as I can see, ::marker is the only element with 
generated textual content, allowing two rules to contradict each other. 

Axel Dahmen | 1 Apr 12:59 2010
Picon

Re: Frameset/Frame Specification Amendment (HTML+CSS)

I see. But how about the lost abilities presented by a frameset?

CSS could provide means to re-gain the plus points gained by frames.

I particularly think of the ability to split two adjacent block-elements.

I suggest to create of a property allowing a group of two adjacent 
inline-block or block elements to be resizable without the need of 
JavaScript.

----------------------------
"Tab Atkins Jr." <jackalmage <at> gmail.com> schrieb im Newsbeitrag 
news:dd0fbad1003300719i579acaa2td8a91926701ee01f <at> mail.gmail.com...
> On Tue, Mar 30, 2010 at 3:42 AM, Axel Dahmen <brille1 <at> hotmail.com> wrote:
>> Hmm, it seems this discussion stalls now...
>>
>> HTML5 apparently has deprecated frames without providing or looking for 
>> the
>> existence of appropriate alternatives.
>>
>> So what is the CSS group going to do? Do we accept regression? Or do we 
>> want
>> to set up new rules to enlarge the richness of CSS/HTML?
>
> Personally?  We accept regression.  The HTML5 change isn't new.
> Framesets were discouraged as far back as HTML4 (which is why there
> was a special DOCTYPE just for it, so they could restrict them from
> the main Transitional and Strict DOCTYPEs).  There are very good
> reasons for them being disallowed, which we've talked about before,
> and very little reason to continue using them.  It is not worth the
> time or effort of this group to attempt to do anything further with
> them.
>
> ~TJ
>
> 

Brad Kemper | 1 Apr 16:52 2010
Picon

Re: CSS3: Suggestion for another list-style-type


On Apr 1, 2010, at 3:52 AM, Axel Dahmen wrote:

> "Brad Kemper" <brad.kemper <at> gmail.com> schrieb im Newsbeitrag news:7e1f93761003301034j2ed9ecd2k89228c5a57c2e04a <at> mail.gmail.com...
> 
>> A few of us did, anyway (it wasn't part of the minuted meeting
>> of everyone present). I also posed the idea of list-style-type
>> being a sort of shorthand for ::marker { content: \ 2022; },
>> but that causes problems with the cascade.
> 
> I understand. As far as I can see, ::marker is the only element with generated textual content, allowing
two rules to contradict each other. 

The don't contradict; the one with the higher specificity overrides. This is an integral behavior of CSS,
and this is certainly not the only place where one one property overrides another. Since marker is a
pseudo-element, it increases specificity when added to a selector. This is also not the only thing to use
the 'content' property to generate textual content. The 'content' property is not yet widely
implemented, except for '::before' and '::after' pseudo-elements, but it is expected to be.

When I mentioned problems with the cascade, the biggest one is that it is much easier to override
list-style-type with a ::marker, than to do the reverse.
Attachment (smime.p7s): application/pkcs7-signature, 3279 bytes

Gmane