[CSSWG] Minutes and Resolutions Cupertino F2F Tuesday 2010-03-30

Transitions and Animations

   - Discussed approaches for animation of non-interpolatable properties.
     Two solutions are possibles: stepwise timing functions, and
     allowing transition-delay to apply to non-interpolatable properties.

   - RESOLVED: Make all properties animatable. (non-0 values round to 1)

   - RESOLVED: Accept stepwise timing functions, with modifications
               suggested in minutes (step-start and step-end keywords,
               plus steps(number,[start|end]) function)

   - Discussed combining Transitions and Animations somehow. No conclusions

   - Discussed reversing animations. This is clearly desired. Also discussed
     filling other holes in the draft, such as animation-fill-mode.

   - Some name changes were suggested, specifically animation-iteration-count
     to animation-play-count (typability, understandability, and consistency
     with marquee) and animation-duration to animation-period (avoid confusion
     with total duration of animation).


   - RESOLVED: accept jdaggett's proposal to use css3-fonts wording about
               font-weight hole-filling in css2.1 since css2.1 wording misses
               a few cases

   - Wrt font variant, discussed and marked as issues
       * whether 'all-small-caps' and 'all-petite-caps' were needed
       * whether all-small-caps/all-petite-caps feature should be triggered
         by 'text-transform: lowercase' + 'font-variant: small-caps/petite-caps'
       * whether petite-caps fallback should be
          a) lowercase
          b) synthesized petite-caps
          c) small-caps

   - Discussed superscripts and subscripts, the 'character-transform' proposal
     and how to handle stacked superscripts or subscripts. Steve Zilles outlined
     a proposal to address this by the parent's font size to substitute or
     synthesize the appropriate glyph.

   - Re-discussed issue of font-specific feature selection. No conlusion
     reached because John Daggett vehemently disagrees with requiring
     font-specific features to be scoped to a specific font.

   - dbaron introduced 'font-size-adjust: auto', which would give 'font-size-adjust'
     the value of the ex-height of the user's default font, providing an easy
     way to introduce ex-height calibration and a way to more accurately match
     the user's effective default font size for bicameral scripts.


   - Briefly reviewed the status of Ruby

CSS2.1 Issues

   - Reviewed test results for CSS2.1 Issue 114. Straw poll indicates preference
     for ident+ syntax for unquoted font-family names within the CSSWG, but SVGWG
     also needs to be consulted.

   - RESOLVED: Proposal accepted for CSS2.1 Issue 163

   - RESOLVED: No change for Issue 162 (position of bullet should follow containing
               block, not element, directionality). We already have strong interop
               on the existing behavior, and the behavior makes sense for some
               non-list use cases of display: list-item. We may consider more control
               over this for CSS3 Lists.

   - Reviewed proposal for CSS2.1 Issue 161. Tab to write updated proposal.

   - RESOLVED: Add non-normative for-example sentence explaining whether the
               first page of a document is :left or :right for CSS2.1 Issue 160.

   - Rediscussed pt vs. px issue proposal. Still no consensus. fantasai to write
     specific wording for proposal. http://wiki.csswg.org/spec/css2.1#issue-149


======= Full minutes below ======

Agenda: http://wiki.csswg.org/planning/cupertino-2010

   Tab Atkins
   David Baron
   Bert Bos
   John Daggett [afternoon-only, via phone]
   Beth Dakin
   Tantek Çelik
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Dean Jackson (Apple)
   Brad Kemper
   Jonathan Kew (Mozilla) [afternoon-only, via phone]
   Håkon Wium Lie
   Chris Lilley
   Peter Linss
   Chris Lye (Adobe)
   Alex Mogilevsky
   David Singer
   Anne van Kesteren
   Steve Zilles

Scribe: TabAtkins

Transitions and Animations

Transitions of non-animatable properties Part I

   <glazou> http://lists.w3.org/Archives/Public/www-style/2009Nov/0328.html
   dbaron: Transitions spec currently has a special case for visibility.
   dbaron: We may want to keep it despite this, but the idea for the special
           case is the if visibility has a transition from 'visible' to
           'hidden', it's considered to be a property that can transition,
           where all intermediate states are transitionable.
   dbaron: So if you're transition from visible to hidden, the transition
           happens when a timing function ends.
   dbaron: This makes sense if you're, say, shrinking something and then
           want it to disappear entirely.
   dbaron: Somebody wanted this to apply in other cases; in particular,
           they were trying to convert the controls Gecko uses for HTML5
           video, which has a number of animations.
   dbaron: He was trying to do them using Transitions, but one thing that
           happens is a display change.  He wants to be able to transition
           to display:none after an opacity transition happens.
   dbaron: He ended up using the transitionend event, but he'd like to do
           this just with the transition support.
   dbaron: So what we think we might do is that, for non-animatable
           properties, we don't have transition-duration support, but *do*
           have transition-delay support.
   smfr: So you'd take transition-delay into account, and just do an
         instantaneous transition after that.
   dbaron: If we did this, we might still want to keep this special rule
           for visibility, because it's a little bit harder to do things
           this way (you have to do delay for this one property rather
           than a duration).
   dbaron: With visibility, we know that people want visible in the middle,
           but for other properties we don't know what people want in the

   dean: The next topic is discrete timing functions, which would also
         solve this and give you control over when the non-animatable
         property transitions.
   dbaron: Yeah.
   dbaron: Are you saying you want to do it the delay way, or the stepwise
           way, or both...?
   dean: Your way.
   smfr: But if you have stepwise timing functions, you don't necessarily
         need a delay trick.
   <smfr> step-wise timing function proposal:
   dean: With a stepwise timing function, if you say something like "I only
         want a change at the end of the transition", you can control when,
         say, a display:none transitions.
   dean: Basically I think we can make this decision *without* having to
         worry about stepwise functions first.
   dsinger: Right.  We just need to decide if we fix the transition to
            happen at the beginning or the end.
   plinss: What about a transition from block to inline?  There's no easy
           answer for start or end.
   smfr: Right, stepwise timing functions have a start and end transition
         function, so you can decide which one to use.
   dsinger: So if you're not using a stepwise timing function, 0 is start
            and 1 end, and what do we do in the middle?
   dbaron: I think the rule that's most compatible is to have all non-0
           round to 1.

Reversing Transitions Part I

   dbaron: Now most of the time people will want to be able to reverse
           their transition, so that's a little hard.  They'll have to make
           two different declarations.
   smfr: We talked about the issue of not getting symmetry by default,
         and there's no easy solution I think.
   dbaron: One thing that just occurred to me is that we could add a
           property that says "reverse all the timing functions".
   dbaron: So when people transition to a hover state, they can put this
           property on the hover and make it work.
   smfr: That gets into a weird bit of statefulness.
   TabAtkins: Like what if you go to :hover and then click and activate an
              :active transition.
   smfr: How are you defining the states?
   dbaron: Well, any change.  :hover, :active, a class...
   smfr: Tracking states kind of scares me.
   dbaron: It requires the author to track states, not the implementation.
   smfr: All the transitions are reversible, right?
   TabAtkins: Yeah, but to do it right you have to set up, say, a :hover
              and then a :not(:hover) rule.

Transitions of non-animatable properties Part II

   smfr: So I think we have two non-exclusive proposals.
   smfr: One is to just let delay apply to all properties.  The other is
         to add stepwise timing functions.
   TabAtkins: The stepwise includes making all properties respond to delay,
              so I'm fine with just going all the way up and adding stepwise
              timing functions.
   TabAtkins: Is anyone opposed to adding the stepwise timing functions?
   anne: One question.  The use-case we were looking at this morning was
         transitioning a display:none as well other properties.  It can be
         solved with stepwise timings, but could we also do a
         transition-start event to activate it?
   anne: Another advantage of making them all animatable is that if we add
         the ability to interpolate one of the non-animatable ones later,
         we can just do it.
   <smfr> http://lists.w3.org/Archives/Public/www-style/2010Feb/0212.html
   RESOLVED: Make all properties animatable. (non-0 values round to 1)

Stepwise Timing Functions and Bezier Curves

   smfr: [explains full stepwise timing-function proposal]
   smfr: You may want to control where an *animatable* property precisely
         step, so you can have it step, say, halfway through, or control
         how many steps take place.
   smfr: A good example of this is the progress spinner on Mac OSX.  It
         doesn't smoothly rotate; it does 12 discrete steps, and we can't
         do that right now with Transitions.
   dean: We'd suggested a few things, like letting someone specify the
         timing function curve as an SVG Path, but I think this proposal
         hits the majority of cases very simply.
   howcome: I like this stepwise function, but I don't know if I accept
            the value of full control of a bezier curve.  I think a few
            keywords would just do it.
   dean: [shows some example of where animation programs allow complex
          control of a curve]
   dean: Writing a bezier function by hand is hard, but it's easy to
         understand when you see it.
   howcome: Can we just say that if you want more control, just use SVG?
            Keywords are the 90% function, right?
   dean: Well, we *also* have the 90% solution; we keep the keywords.
         But we also then add the bezier function.
   glazou: I think this is an excellent first example of something in
           CSS that can't be really hand-authored.
   howcome: I get worried when we say we don't care about complexity.
   dbaron: 99% of the implementation complexity is just implementing 'ease'.
           Doing any other bezier curve is just plugging in four more numbers.
   TabAtkins: This doesn't produce any long functions.  A bezier is just
              four numbers.
   szilles: Can't we just have a list of xy pairs?
   smfr: That allows too much possibility of getting things wrong,
         accidentally defining invalid steps.
   szilles: Sure, but you can do that with just the plain number in step-start().
   TabAtkins: Do you think we *need* that degree of control over the
              transition steps?
   dean: What I like about the simple form we have is that you can leave
         off the number entirely and it's very intuitive what happens.
   dean: [gives an example of using a step-start function to animate a
          second hand on a clock]
   [some confusion about difference between step-start and step-end]
   glazou: I would like it better with something like "steps(60) start"
           or "steps(60,start)".
   dean: Yeah, that's fine, but we also want an author to be able to do
         the simple case without having to write much, like just "steps"
         or "steps(start)".
   <Bert> (I don't believe you can animate a rotation: rotate(0) and
          rotate(360) look exactly the same, moving the box from one
          to the other is a no-op, isn't it? And 60 steps of no-op is
          still a no-op.)
   glazou: No, they end up looking the same, but it's still a different thing.
   Bert: Where is it specified that you transition the value of the
         rotate function?
   <smfr> http://www.w3.org/TR/2009/WD-css3-2d-transforms-20091201/#matrix-decomposition
   dean: In the Transitions spec, there's a big section defining how
         to animate Transforms.
   Bert: If you had a rotate and a translate both?
   dean: If the from state and the to state have the same transform
         functions in order, you pick them up in order and transition
         each one independently.
   glazou: no, 360deg and 0deg are not the same ; we all wrote our first
           draw-a-circle-on-screen program iterating from 0deg to 360deg
   dean: If they don't match, you do the matrix decomposition and animate
         that, which is defined in Transitions spec.
   Bert: Still a bit confused about transitions when the start and end
         state look the same.
   dean: I think you're confused because you haven't read the transition
         spec yet.
   Bert: Does this apply to color as well?  If you transition from an
         rgba color to an hsl color?
   smfr: Right now we define it as transitioning through rgb space.
   dean: The problem is defining exactly how to transition the hue.
   dean: But we may have control over this later.
   dean: SMIL and SVG don't give you these controls either.
   howcome: Some implementor told me there was some ambiguity.
   dean: I think the spec might just say it in a single sentence or something.
   dean: So, back to steps.
   smfr: I'm happy with what daniel proposed ("steps() function")
   dean: Maybe it should be step() instead, and we decide whether it
         goes at the start or end?
   glazou: Just do step-start and step-end, and then steps().
   dean: Okay.
   szilles: I think the usage of the words is inconsistent.
            [step "start" and "end" referring to different things]
   <anne> step() and step-delayed()
   howcome: Perhaps we can just write it down now, and come up with a
            better word later?
   <bradk> align-steps(start|end)?
   RESOLVED: Accept stepwise timing functions, with modifications
             suggested in minutes (step-start and step-end keywords,
             plus steps(number,[start|end]) function)
   <Bert> Why 2 functions, why not just step(n) where n >= 1, 1 by default?
   <Bert> (Actually, step(0) as the default is better, then n is the
           number of intermediate steps.)
   <Bert> (or stepS().)
   <Bert> (If you want the possibility of unequal steps, you could do
           steps(0%,0%,20%,50%,80%,85%,90%). But that may be unnecessary.)

Combining Transitions and Animations Part I

   <howcome> http://people.opera.com/howcome/2010/talks/03-csswg-cupertino-ta.html
   howcome: Maybe I'm stupid...
   howcome: In my mind, when I come to this [points to exmaple on screen]
            I see transitions and animations being the same.
   howcome: I think animations are *great* for CSS, but I think we need
            to have the model clear.  I don't think we've ever quite
            discussed if this is the right model.
   howcome: We should have *one* set of properties, *-duration,
            *-timing-function, *-delay.
   howcome: I wanted to do an animation and a transition, and I wanted
            them to do the same thing.  They're basically the same code,
            except in one I specify a transition and in one I name an
   howcome: There are some minor differences.
   glazou: They're not minor.  In transitions the start is defined from
           context, not explicitly in the animation.
   howcome: [shows Simon's example of combining transitions and animations]
   howcome: In my head, it's arbitrary whether you write transitions or
   dean: I will raise you a head and say "Well, margin and padding are
         the same thing, so let's make them the same."
   howcome: Good argument, but I could also say something about webfonts
            being completely different.  But we found a model where they
            work together with local fonts.
   dean: I think the major difference between transitions and animations
         is that transition is an effect you have happen whenever styles
         change, while animations are something you write specifically
         to happen when you change something.
   howcome: I don't grok that as being so different that you need separate
            properties for it.
   smfr: If you open that example in a legacy impl, the transition will
         make it still move, just instantaneous.  The animation one,
         though, won't do anything.
   smfr: I think it would be useful to add an iteration-count to the
         animation and see how it compares with transitions.
   dean: dbaron raised the point on the list that you run into a cascade
         clash.  In most cases you want to control transitions as a
         separate thing, separate from animations.
   dean: [dbaron's issue of additive cascade]
   dean: frex, for a transition you might want everything in a document
         to transition.  You can say "* { transition-duration: 1s; }"
         and everything does it, no further difficulty.
   dbaron: I wrote a strawman syntax proposal on the list that I didn't
           particular like.
   dbaron: I think I'm in the middle of you guys.  I think the cascade
           thing is something we need to solve a general.  We need a way
           to do additive cascading.
   dbaron: Combining them together makes it a little bit worse in this
           case, but it's already a problem.
   dbaron: My strawman idea for combining them is - all the transition
           properties have an animation sibling, except
           transition-property and animation-name.
   dbaron: Drop the individual properties, have a combined one that
           takes a function for either a transition property, or an
           animation name.
   dean: That doesn't solve anything, it just maintains the current
          separation with a functional syntax.
   TabAtkins: It does partially address howcome's issue, in that it
              would eliminate 3 nearly identical properties.
   smfr: Is that a problem, though?
   howcome: I think it is.
   smfr: I think there's a fundamental difference there.
   smfr: Transitions kick off when CSS properties change for any reason.
   TabAtkins: [puts up an example of how transitions work]
   plinss: I agree that there are enough similarities that it's *possible*
           to define animations as a type of transition, or vice versa,
           but I'm not sure it's worthwhile.
   howcome: I think that's the key question.  I want to raise awareness
            in the room about that possibility.
   szilles: One thing that struck me is that Transitions are parametrized
            with the old value and new value.  In the Animation, you've
            stuck in a specific value, but the transition has a "variable"
            of whatever the start and end values.
   smfr: I also think you're missing is that Animations can have multiple
   plinss: Right, so if you key it to Transitions, you could have an
           animation started by a transition that changes other properties,
           and then you're into circularity issues.

Reversing Transitions Part II

   [conversation shifts to hover/non-hover reversing]
   <smfr> http://smfr.org/misc/tab.html
   howcome: We agree that we want this sort of thing possible in CSS?
            [referring to example]
   everyone: yes
   TabAtkins: But I have a js hack to make that work properly.  Without
              it, the reverse transition happens on page load.
   bradk: :unhover!
   tantek: :was(:hover)!
   <glazou> in fact that's not what we need
   <glazou> we need :will-be(:hover) :-)
   <TabAtkins> :wants-to-be(:unicorn)
   <tantek> is true on an element if it the selector inside the parens
             was ever true  on the element since document load.

Combining Transitions and Animations Part II

   szilles: What seems implicit here is that, to combine them, you need
            an explicit way to refer to the implicit start and end values.
   szilles: Some things seem simpler than others.  Trigger an animation
            on a transition seems like a relatively simple thing to do.
   dean: It doesn't help our case, but internally we call them 'implicit'
         and 'explicit' animations.  We used a different name now because
         they really are quite different things.
   dean: [example of how the dock works with both transitions and animations,
         with the zoom and the bouncing]
   howcome: You could put them together, just have property names mean a
            transition and a keyframe name mean an animation.
   TabAtkins: That's a problem if we add a new property that matches a
              common author keyframe.
   <anne> to disambiguate you could use keyframe(<ident>)
   <ChrisL> well, a keyframe name could have some syntax to always identify
            it. $keyframe or something
   szilles: [talks about animations as a restricted subset of transitions,
            or viceversa]
   dean: A transition could be considered an animation that's created
         automatically at the moment of the property change.
   dean: That automatically fills in the start and end, and automatically
         removes itself at the end.
   dean: We're not just concerned about the impl difficulty here, but
         about authoring simplicity, and that's definitely why we did
         them differently.  But we'll try.
   glazou: If you take the animation example, and remove the "from",
           it's equivalent to a transition.
   dean: Not quite.  Even if you remove the "from" and the "end", you're
         still saying you want a pulse, and there's nothing left to say
         what is being transitioned.

   <Bert> q+ to suggest 'transition-PLAY-count' instead of -ITERATION-,
          to match 'marquee-play-count'

   howcome: [doesn't like the names "Transition" and "Transform" being so close]
   <bradk> trans(form|ition):
   trans(former): robots-in-disguise;
   [naming talk]
   <bradk> metamorphosis-timing-function:

   ChrisL: If you think of transitions as syntax sugar for an animation
           that is automatically created, it seems you can harmonize it.
   glazou: The discussion was not about naming.  It was about harmonizing
           transitions and animations.
   dean: Ultimately what dbaron proposed is easy to implement; just merge
         all the properties together and have some way of telling apart
         transitions and animations.
   dean: But I want to go back and look at content we have and see if this
         sort of change will make it easier or harder to write.
   tantek: How many people have authored this on the public web?  I found
           it confusing immediately, but as soon as I worked with it for
           a little bit it became very clear.
   howcome: I had the opposite.
   dbaron: I said I was in the middle before, now I'm leaning toward dean.
   plinss: It is possible to make a superset, the question is if it will help.
   dean: A weird thing if you combine them is that you can have a transition
         and an animation both controlling the same thing they'll fight.
   glazou: I think you can possibly combine them, but at the cost of more
           complex syntax.
   glazou: I gave a demo with transitions and everyone got it immediately.
   <tantek> transform makes sense from a mathematical functional sense
   <tantek> http://en.wikipedia.org/wiki/List_of_transforms
   <tantek> whereas transition makes sense like "state transition" in
   <tantek> http://en.wikipedia.org/wiki/Transition_state
   howcome: I think we need to try to *look* at the issue.
   glazou: Sure, if someone can pull out a new proposal, great, but don't
           block the existing draft on it.

Reversing Transitions Part III Combined With Combining Animations and Transitions Part III

   howcome: I think this problem [referring to the example with reversing
            an animation] needs to be solved.
   plinss: Everyone agrees that that's a problem to be solved, but it's
           separate from this issue.
   howcome: I'm happy to go away and see if I can come up with something
            smart, or if others can.
   howcome: But also I'd like an action on the spec editors to deal with
            the reversible animation.  This was the first simple thing I
            ran into that I thought I should be able to do.
   tantek: I think this should be logged as an apparent hole, and I'm
           interested in Dean's input on other apparent holes.
   <Bert> (One thing I don't understand about animations and transitions
          is how you can have both: an object can only be in one place at
          one time (Heisenberg notwithstanding).)

Holes in Animations Draft (Other Than Reversal)

   dean: [talk about fill modes being added in nightlies]
   ChrisL: Oh, you didn't have that?  Definitely, that's necessary.
   dean: Yeah, it prevents a lot of added complexity.
   dean: All the holes are trying to avoid writing script.
   dean: So another one is how to chain animations.
   <ChrisL> Having fill mode is crucial. smil has post-animation fill,
            only. pre-animation fill is a useful addition
   dean: So maybe say the end-time of one transition is the start of another.
   ChrisL: So you can have animations keyed by a transition?  Looks like
           that would solve the example problem.
   smfr: One thing I'd like to have is for the keyframes to apply with
         the same specificity as the selector, as if they're sucked into
         the declaration block and can be overriden.
   dean: We'd known about these things for a while, we just didn't put them
         in the proposal so we could have sometehing out in a reaonable time.
   dean: Another is, if you have multiple transitions together, the latest
         one wins.  We'd like to be able to combine animations without
         explicitly writing them together in a keyframe rule.
   ChrisL: That seems crucial; you often want to run two animations that are
           simple by themselves but are rather complex to specify together.

   glazou: we need to close this for now.
   ACTION: howcome to produce alternate proposal for handling animation and
           transition together

animation-iteration-count name

   Bert: Had a question about the name of one property - iteration-count.
   Bert: But when we discussed marquee, Molly argued forcefully for play-count.
         Perhaps we can use the same type of name.
   TabAtkins: I agree; I think it's shorter, easier to type, and jives with
              marquee's similar property.
   <dbaron> What about repeat-count rather than play-count or iteration-count?

   <Bert> (Also 'marquee-direction' and 'animation-direction' are subtly
          different, but I haven't understood what the difference is yet...)

   fantasai: What about tantek's suggestion to change animation-duration to

Plans for Progress on Animations and Transitions

   glazou: Steps to advance transitions
   smfr: We'll add stepwise functions, and publish a new draft.
   dbaron: I think we also need to handle the reversing business, and probably
           the details in the "animation of property types" section. I've been
           guilty of not sending comments about that.
   dean: Can we settle on a goal for progressing to Last Call?
   dbaron: I think it's doable to do LC in a few months.
   tantek: Is there an issues page for this draft?
   dbaron: I created an issues page, but didn't add anything to it for a while.
   fantasai: Editors should be tracking issues.
   ACTION: dean and smfr to produce issues list for Transitions and
           Animations, including comments from dbaron and howcome.
   <Bert> -> http://www.w3.org/Style/CSS/Tracker/products/22 issues list
             for transitions (only has one issue currently)

   [discussion of testing transitions/animations]

<glazou> transition-workin-group: lunch pulse 3mn


Scribe: fantasai
John Daggett and Jonathan Kew join via phone bridge

Font-weight Mappings

   jdaggett: I wanted to go over one thing that was discussed yesterday
   jdaggett: There was the question of CSS2.1 font-weight
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Mar/0510.html
   jdaggett: The wording of the 2.1 spec now, the 4 bullet points you guys
             were talking about
   jdaggett: The 4th bullet point is not clear about 400 and 500
   jdaggett: It's clear in case where 400 doesn't exist but 500 does, but
             not about other cases
   jdaggett: I've clarified this in css3-fonts
   Chris: In that case I suggest we adopt the CSS3 wording in CSS2.1 to
          keep these consistent
   jdaggett: basically 400 and 500 map to each other, and then they map down
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Feb/0279.html
   RESOLVED: accept proposal to use css3-fonts wording about font-weight
             hole-filling in css2.1

   jdaggett: Adam Twardoch (sp?) posted about having an all-small-caps setting
   jdaggett: It's very easy to add, I've added it to the current wording
   <jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-variant-caps-prop
   jdaggett: The one tricky part about this is because of the bheavior
             defined in 2.1 for small caps, where UAs fake small caps,
   jdaggett: to be compatible with 2.1 we need to continue to fake that behavior
   jdaggett: I don't think this would work for petite-caps, so I didn't add
             simulation there
   jdaggett: Because they are much smaller, and the size difference would be
   Chris: So what you're talking about is fallback. I think you're correct that
          leaving petite-caps as lowercase is better than faking small-caps
   jdaggett: So to summarize, we will fake small-caps and all-small-caps, but
             not petite-caps or all-petite-caps
   howcome: Isn't all-small-caps the same as text-transform + small-caps?
   jdaggett: It's very close, but since you're doing the casing in the font
             engine, the font can tweak things like parentheses because it
             knows there are no lowercase letters
   howcome: Wouldn't it make sense to do the higher-quality rendering for
            text-transform + small caps as well?
   jdaggett: You're not communicating to the opentype engine that it's all
             small caps
   howcome: You could, though. If you know tet-transform: lowercase is
            applied, then you know that it's the same as all-small caps
            and you can request that from the engine
   jdaggett: Adam posted an explanation explaining the rendering of text
             that has already been transforming
   jdaggett: ... something about not knowing when things get transformed
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Mar/0306.html
   cslye: I do think some font developers do put extra stuff in these layout
          features, like numbers and currency
   cslye: I don't know if it's good or bad, but some people use this as a
          way to pack more into a font. It's not just letters transforming,
          but an alternate look
   jdaggett: I think what howcome is saying is that instead of the author
             explicitly requesting all-small-caps, the feature would be
             implied by a combination of CSS properties
   Steve: howcome's saying that after you've done the transformation, you
          remember that fact, and then you pick up the c2sc
   jdaggett: I think the implementation would be tricky because you'd have
             to see if the font has this feature enabled. *If* not, then
             you do the transformation yourself
   cslye: Is it intuitive to split this? If you have an acronym, you usually
          want to transform to uppercase, then use all-small-caps to get a
          smaller version if that's available
   cslye: Not to use a lowercase version
   jdaggett: ... petite-caps is a different route than lowercasing and then
   howcome: I think that keyword is not necessary, so I would like to see
            this marked as an issue
   Steve: My question is what is easier for the user
   cslye: I think Adam addresses this in his email
   Steve: What's the computed value?
   ChrisL: What you get by copy-paste after transformation varies by UA
   Steve: If you want to use text-transform selectively, then all-small-caps
          is a better option
   ChrisL: If a user agent understands and sees this combination of properties,
           it could hand off the combination to the font engine and ask it
           to do it all
   Steve: The scope of the text-transform is different from the scope of the
   dsinger: If you have a way of asking the font engine to do something
            directly, and you use a circuitous route, you should get
            different results
   Bert: Shouldn't have two ways to do two things that are so closely related
   Bert: We already have one way to get there
   Bert: And the difference between the two is very subtle, most people won't
         notice but one way is definitely better
   cslye: Our concern is that text-transform + small-caps is unintuitive
   jdaggett: Sounds like we don't have a conclusion, but we should keep track
             of the issue
   SteveZ: you can put an issue in the draft
   jdaggett: I will mark this as an issue, and the maybe ping Adam again


   howcome: It's the same issue for all-petite-caps, too
   fantasai: The fallback for petite-caps doesn't involve synthesis, so you
             could wind up with all lower case instead
   fantasai: at least for small caps + text transform, you're guaranteed
             small caps even if they're not as pretty
   Bert: Maybe the fallback for petite-caps should be small-caps?
   cslye: It's a good question
   cslye: Maybe you're better off faking petite-caps
   jdaggett: I don't think we should have UAs fake the petite-caps
   SteveZ: Which is why I suggest falling back to small-caps
   jdaggett: I don't think it will work
   jdaggett: The feature becomes so subtle, that ...
   howcome: No this, is just to ensure that we can implement this in a non-OT
            environment as well
   howcome: so that UAs in those environments can do something there
   jdaggett: When you try to synthesize petite caps, the glyphs get so small
             that it's hard to read
   <bradk> faked petite caps would look too fake and too light. Small
           caps/fake small caps would be a better falback.
   jdaggett and dsinger think this is a slippery slope
   jdaggett: I think going in this direction is diminishing returns
   <jfkthame> using small-caps as the fallback for petite-caps makes sense
              .... like we use oblique as fallback for italic (or vice versa)
   jdaggett: I would like to avoid artificial ways of doing font feature effects
   cslye: That's fine, but then we can't implement the all-petite-caps feature
          with text-transform, because we'll wind up with unwanted lowercase
   jdaggett: Ok, I'm going to record this as there are two separate but
             possibly related issues
   SteveZ: Another point to record is that, it appears that some people
           believe petite-caps match the x-height of the font
   SteveZ: And in fact in one place, they were called ex-caps
   jdaggett: Petite-caps are below the x-height.
   cslye and stevez don't agree
   jdaggett: It's smaller than small-caps
   <bradk> 'text-transform:lowercase;' + small caps = all small caps seems
           ituitive to me.
   SteveZ: small-caps are typically above the x-height
   <howcome> http://people.opera.com/howcome/2010/tests/petite.html
   <bradk> 'text-transform:lowercase; + all-small-caps = all-small-caps seems
            like a waste of a property

Superscripts and Subscripts

   jdaggett: next issue
   jdaggett: Dealing with subscript and superscript
   jdaggett: OT has features that allow font designers to put sub / super
             glyphs in the font itself
   jdaggett: Issue is how to access it
   jdaggett: currently sub/super is done with a combination of properties
   jdaggett: the question is how to work things so that use the font feature
             if available, otherwise fall back to altering properties as before
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Feb/0245.html
   jdaggett: that's the original issue
   <jdaggett> http://dev.w3.org/csswg/css3-fonts/#character-transform-prop
   jdaggett: This is how the spec currently words it
   jdaggett: the idea here is that you use the subscript glyph if available,
   jdaggett: and fall back to a synthesized version of that if that's not
   jdaggett: and in this case I think it's better that the author see a
             simulated version
   ChrisL: Yes, this is good, because the fallback and the feature don't get
   ChrisL: It's a little weird that it resets the properties it simulates
           with, but I also think it's a good idea here.

   SteveZ: What happens if I stack superscripts or stack subscripts?
   SteveZ: This is common in mathematics
   <dbaron> We probably don't want to break 2<sup>2<sup>x</sup></sup>
   SteveZ: The reason I say super { font-size: 70% } is so that stacking
           superscripts works
   Bert: It seems to me that we're using a feature in OT that we already have
   SteveZ: We don't already have this. Simulated supserscripts are not nearly
           as correct typographically as real ones
   jdaggett asserts that stacked subscripts are unusual
   SteveZ and ChrisL disagree, it is a common case in mathematics
   <fantasai> you probably don't want character-transform to inherit...
   jdaggett: the subscript or superscript is tied to a base font size
   jdaggett: changing the font size changes the color of the glyph
   jdaggett argues against something
   Steve: Let me try another way
   Steve: What I'm trying to get at is, the user decreased the font size
   Steve: One way to deal with this is to reset the font size
   Steve: The other way is to not reset the font size, but to use the
          font-size of the parent when selecting the superscript glyph
   <Bert> (But then the author doesn't get what he asked for, does he?)

   fantasai: The tricky part is, if you have nested elements, you don't
             want the parent
   fantasai: you want the parent of the element on which character-transform
             was set
   Steve: That would allow us to get nice superscripts all the way down
   jdaggett: I think I understand what you're trying to say
   jdaggett: I can see these two things being used in conjunction. Whatever
             it is, though, it should be understandable in the simple case
   Steve: The simple case, they'll look exactly the same, so it didn't
          really matter which way you did it
   Steve: The result is you would use the subscript character in the size
          of the original font
   jdaggett: As long as that's there, that's the key thing
   Chris and Steve try to explain the use case for character-transform to Bert
   Bert: What if there's an image in there? Or fallback fonts?
   jdaggett: This is something that would make sense for the default behavior,
             but it doesn't make it impossible to use the old behavior
   fantasai: Bert has a good point. If you have fallback, or if you have
             images, you don't know where the effective baseline is
   fantasai: And you can't align things to it
   SteveZ: In that case, you could say, if there is anything in the element
           that can't be substituted through the font, then you fake the
           whole thing
   jdaggett: I don't think you can do that
   jdaggett: I don't think it's practical to make the fallback behavior
   jdaggett: You're either affecting vertical-align or you're not
   jdaggett: We have to know
   SteveZ: my approach is that you don't affect font-size or vertical-align
           when you do this
   SteveZ: You just don't use them when rendering
   ChrisL: I like that approach
   peter says something quietly
   <jfkthame> if you're applying an opentype superscript or subscript
              feature, and you need to know the baseline for some other
              alignment, you can ask the font for its superscript or
              subscript offset
   jdaggett: I'm not crystal clear on what is being proposed, so what
             I'd ask you to do is to look at 6.2 and suggest specific changes
   ACTION: SteveZ Propose changes to character-transform to address above concerns
   jfkthame, thanks!

Font-specific Feature Selection

   jdaggett: new topic
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Mar/0224.html
   jdaggett: Talking about font-specific font features
   <jdaggett> http://people.mozilla.org/~jdaggett/images/fallbackexamples.png
   jdaggett: In the first page you have, say, two fonts
   jdaggett: If you use the setting styleset(6), that's picking a specific
             font feature
   jdaggett: typically styleset numbers' effect is not consistent across fonts
   jdaggett: Last time we talked about this, there were a number of people
             were concerned that triggering a numbered styleset across font
             would not be good
   jdaggett: The key point here is that these are variations on the underlying
             font itself
   jdaggett: they're not .. look coherent with the text that surrounds it
   jdaggett: The concern about showing some crazy glyph.. that the resulting
             fallback will be ruinous
   jdaggett: I think that's really far-fetched scenario
   jdaggett: You'd have to have a pathological fallback situation for that
             to happen
   jdaggett: Most platform fonts don't have this feature, and they tend to
             be subtle
   jdaggett: Authors would have to not know about (?)
   <dsinger> is that (a) because fallback etc. is unlikely or (b) because
             styleset(6) (say) is likely to be there or not, but not very
             "different" between fonts?
   <jdaggett> http://people.mozilla.org/~jdaggett/tests/strangepresentationalligs.html
   <jdaggett> http://people.mozilla.org/~jdaggett/tests/strangeligatures.png
   jdaggett: on the left is safari, on the right is firefox
   <dsinger> isn't it possible that styleset(6) in one font gives me a
             variant designed for great legibility at small sizes and in
             another, designed for swishy presentation in titling and at
             large sizes?

   ChrisL: Could I interject an observation?
   ChrisL: I think there's not very many of these ligatures
   ChrisL: They're added mainly for codepage roundtripping between legacy
   ChrisL: They tend not to be supported in fonts
   ChrisL: And they mess up other things like searching
   ChrisL: As long as people have a more reliable method of getting the
           same effect
   ChrisL: I think the use of these presentation ligature codepoints will
           be decreasing
   jdaggett: My comment isn't about whether they should be used, but that
             their fallback is different
   jdaggett: My point is that when fallback occurs, strange things can occur

   dsinger projects his IRC comment into voice
   dsinger: Style sets should be only applied to the font for which they're
            expected to apply
   jdaggett: That's what you get with fallback.
   <jfkthame> it's possible, but a very unlikely scenario - font features
              are the wrong mechanism for a designer to be using there,
              that's optical sizing
   dsinger: Why do we wind up speciying a font-specific setting to a fallback
   dsinger: Why don't we design the syntax so you only apply the font-specific
            setting to the font it was intended for?
   jdaggett: styleset is the most extreme example
   jdaggett: but some other features may or may not be font specific
   jdaggett: e.g. the annotation forms feature
   <jfkthame> styleset may well behave consistently across a whole library
              of fonts, e.g., from a single designer/vendor
   jdaggett: There is more consistency there
   jdaggett: The author should be making the decision of whether it's a
             font-specific or font-generic feature.
   ChrisL: One way to get around this is to put the style set selection
           in the @font-face rule
   dsinger: Note also that the font that ends up being used might be
            something the author didn't select at all. It could be
            something specified by the user.
   <fantasai> or on a system with limited fonts and no downloading
   Steve: I may, with old eyes, want to use a high-contrast font
   <ChrisL> While it may be sometimes true, or indeed often true, that
            opentype font features only make sense when applied to a
            specific font or to a spacific family, it is not clear that
            it is *always* true
   <ChrisL> and thus, authors should be able to choose whether to make
            this general or font specific.

   jdaggett: You can't guarantee that the web page is readable with an
             alternate font
   <jfkthame> if you want to use a personal stylesheet to force a certain
              font, you can also use it to override the features
   jdaggett: The author could pick a set of CSS features in combination
             that would make the page unreadable with another font
   dsinger: I'm not saying that all font features should be restricted
   dsinger: But the ones where you're selecting by number, rather than
            by name for a generic feature, you're getting a random effect
            if you're getting one at all
   dsinger: That doesn't seem right to me
   jdaggett: You can already use @font-face if you really want
   jdaggett argues that this and that is not that font-specific
   peter: The problem is that the author may think that the feature is
          not font-specific, and they test it on their three fonts,
          but then some user 5 years down the line uses a font that the
          author never expected
   jdaggett: We're not changing the characters, we're changing the
   dsinger: styleset(6) doesn't say what the change in presentation is,
            and it might be very specific to the font
   <Arron> font-variant: styleset(gabriola, 6) styleset("poetica std", 3);
   howcome: Couldn't we just say that the styleset(6) applies only to
            the first font in the list
   howcome: and if you want to set it on other things, then you set it
            on @font-face
   jdaggett: If we come up with clever syntax to make it font-specific,
             we increase the burden of the author
   howcome: We increase the burden on the author to decrease the chance
           of something weird happening
   Peter: Authors aren't going to read the standard, and they're not
          going to know whether they should use it in the property or
          in the @font-face
   Peter: It's going to work fine on their machine, and then the reader
          gets screwed down the line
   jdaggett: It won't be unreadable
   dsinger: If it were designed for 30pts in titles and gets used in body
            text, then you might well get something unreadable
   cslye: ... throwing baby out with the bath water
   peter: We're not saying let's not have this feature
   fantasai: It's not that hard to tie the feature to the font. We have
             at least 3 proposed ways to do it
   <dsinger> I would prefer syntax that makes it unlikely, I would settle
             for a warning...
   jdaggett: I think whether something is font-specific or not is not
             determined by whether it's numerical or not
   dsinger: Yes, I accept a given foundry may use numbers consistently
            across fonts
   jdaggett: I think authors should have this flexibility
   We're not moving forward with this :(

font-size-adjust: auto

   jdaggett: The other issue was font-size-adjust
   jdaggett: I'm not sure I would be the best rep for that issue
   dbaron takes the floor
   dbaron: The idea of font-size-adjust is that it's a way of specifying
           the font size by specifying the x-height
   dbaron: it does it in backwards-compatible way so that old UAs get the
           font-size property
   dbaron: It does this by having font-size-adjust take a number
   <jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-size-adjust-prop
   dbaron: font-size: 20px; font-size-adjust: 0.45; gets you 9px x-height
   dbaron: this is useful for two things
   <jdaggett> example of how font-size-adjust works
   <jdaggett> http://dev.w3.org/csswg/css3-fonts/fontsizeadjust.png
   dbaron: Particularly at small font size [in bicameral scripts],
           legibility is related more to x-height than to font size
   <ChrisL> and this is primarily useful when fonts are substituted, or
            changed on sub elements
   dbaron: e.g. Verdana is readable at very small font sizes
   even though most fonts are not
   dbaron: One use case for font-size-adjust is when you have multiple fonts
   dbaron: E.g. in computer docs, you are mixing normal font with monospace font
   dbaron: and depending on the fonts, the x-heights might be very different
   dbaron: So to get a consistent effective size, you'd need to size them
           differently (e.g. much smaller monospace font)
   dbaron: I wanted to make font-size-adjust work better in cases where
           the author wants to use the user's default font size
   dbaron: but still equalize x-heights across fonts
   <bradk> example of tiny x-height:

   dbaron: The secondary use case is that browsers do really weird things
           to equalize proportional and monospace fonts
   dbaron: and this couldpotentially replace that
   dbaron: Suggesting font-size-adjust: auto to mean, use the x-height of
           the user's default font
   jdaggett: the tricky part is that the default font isn't always one font
   dbaron: I would love to get rid of this weird font pref setting thing
   dbaron: It might require a little bit more, but that bit can be

   dbaron: I would also like to allow authors to opt-into this world of
           consistent x-heights
   dbaron: by aligning to a reasonable default font
   dbaron: Authors can do something similar by font-size-adjust: 0.5
   dbaron: But that changes the user's default size, even if they don't
           want to, by the amount by which that factor is off
   szilles: I'm confused about what the "user's default font-size" is.
   dbaron: There's the issue that the default font size does vary by language
   dbaron: Some browsers have lang-specific font preferences
   dbaron: so we might use those
   szilles: If i set a font ...
   dbaron: If you set a font family, not use the user's default, you
           are likely to keep more closely to the effective font size
           of the user's default with font-size-adjust: auto
   dbaron: font-size-adjust: auto only depends on the default font-family,
           not on the default font-size
   <ChrisL> useful discussion at http://www.emdpi.com/css3xheight.html
   szilles: So.. 'auto' makes a bunch of assumptions about where to go
            look for things
   szilles: And those assumptions work in pages where people use the
            default font
   szilles: Seems it wouldn't work as well to change the default font
   dbaron: If they change the font, then they can also set a different
   ?: ...

   szilles: But the values are hard to figure out
   szilles: It would make more sense to say "match my parent's ex-height"
   fantasai: That's an interesting idea. Setting it on the root would
             hit up the initial font

   howcome: Are we proposing to change page layouts across the web?
   fantasai: no, we are just refining their typographical color
   Bert, howcome: maybe be more useful as we see more fonts used
   Alex: We have gotten requests for font-size-adjust
   dbaron: font-size-adjust was in CSS2.0
   jdaggett: I think it's a somewhat cumbersome feature
   jdaggett: But I see people saying "I want this!" and when I see what
             they describe, it's font-size-adjust
   dbaron: It's implemented in Gecko
   Alex: I'm not going to confirm or deny the plans for IE9
   ChrisL: I think the proposal has merit
   jdaggett: To me the big problem here is what you're calling the default font
   jdaggett: Because that's something that's not defined normatively
   jdaggett: And it's important for having this feature work consistently
   dbaron: I tried to leave a bit of latitude for determining what exactly
           the default font is
   <ChrisL> a font example with a fairly small x-height

   howcome: I think I like Steve's proposal to use the root element
   dbaron: I don't quite understand how that proposal would work.
   Steve: The value on the root element, unless one is specified, is going
          to be the default.
   Steve: I can explicitly set a value on the root element
   Steve: And have that used instead of the default font
   Steve: So that could be the default font, but it doesn't have to be
   dbaron explains something about overriding
   dbaron: let's distinguish between user's default font-family and size
   dbaron: This proposal gives a better way of matching the default font *size*
   dbaron: It also gives users a better way to deal with the
           monospace-proportional harmonization problem
   Steve: That case is handled either way
   dbaron: example
   dbaron: Suppose the author wants to preserve the user's size
   dbaron: But wants to use verdana
   dbaron: They'd need this feature to effectively preserve the size
   dbaron: because actually preserving the size, without this adjustment,
           would result in a much bigger-looking font
   howcome: initial value?
   dbaron: initial value is none
   dbaron: If we wanted to replace the current monospace hackery
   dbaron: We would have to make the initial value be a value that if an
           element or one of its ancestors had a font size in absolute
           units, this special value would behave like none
   dbaron: and otherwise the special value would be have like auto
   dbaron: at least, in the way Gecko implement monospace pref
   Steve: I'm confused why you think the default font size has anything
          to do with what I'm looking
   fantasai: So there are three use cases here, and dbaron's solves one,
             steve's solves another, and both solve the third
             1. Match the user's default size as well as possible, meaning
                ex-height matching
             2. Consistent ex-heights across font-switching throughout the
                document, esp. mononspace vs. proportional
             3. Steve Zilles' case
   <dbaron>  4. Move towards replacing separate browser monospace font
                size prefs.
   stevez: The third use case is to match the ex-heights locally
   stevez: handle the 2nd case when the author has changed the font-size
   dbaron: Just set font-size-adjust: auto (or some other value) on the root element
   fantasai and stevez try to work through stevez's case
   <fantasai> 3. Keeping ex-heights consistent throughout the document
                 (requiring use of font-size-adjust) but wanting to set
                 an exact size for the main document font without looking
                 up the ex-height
   <fantasai> e.g. Choose Palatino at 16pt, set font-size-adjust: foomatic
              on the root and foomatic looks up Palatino's ex-height and
              set's font-size-adjust to that so that Palatino's font size
              doesn't change from 16pt *and* font-size-adjust takes care
              of ex-height adjustment across the document
   <dbaron> The problem with foomatic is that font-size-adjust inherits.


   Anne: HTML5 only includes simple ruby, which was implemented by IE
   Anne: The module also has complex ruby
   fantasai: I think Richard Ishida was planning to take that out of the
             CSS3 Ruby module
   Anne: There was some discussion on www-international
   Anne: It seems in general that the Japanese people think the simple
         model is adequate, because you can nest it
   ChrisL: nesting was described as a hack
   Anne doesn't particularly care
   Proposal to defer entire discussion since Ishida is not here
   Steve: There's ruby that's attached to individual characters, and ruby
          attached to groups of characters.
   Steve: Different ways of attaching to characters, and that's where most
          of the trouble lies
   Steve: I think we should wait and see what Richard's draft says

   Anne summarizes HTML5's rendering rules for ruby, which mostly defer
        to CSS by giving display types
   Steve: So most of the complexity on the ruby side comes from how you
          group the pieces and how you format across them
   howcome: Can you write CSS rules on the rt elements?
   Anne: The implementations so far have dedicated frame types in the
         rendering model
   howcome is asking if you can simulate ruby with existing CSS
   Alex and Steve think not
   SteveZ notes that there's a 96-page document that explains all the details
   written by the JLTF in both English and Japanese
   Steve: I think Richard is going to produce a new draft that is consistent
          with HTML and the JLTF drafts
   Steve: The plan is to wait until he gives us a draft to look at
   Anne: Search for 'ruby' on www-international
   <anne> http://lists.w3.org/Archives/Public/www-international/2010JanMar/
   <anne> thread on ruby: http://lists.w3.org/Archives/Public/www-international/2010JanMar/thread.html#msg107

CSS2.1 Issues

   glazou: Arron told me we still have CSS2.1 issues to discuss
   glazou: Since there's nothing else we can move to this time in the day,
           I suggest we move to 2.1

   Arron: I put all the results for the testcases
   ChrisL: I'm slowly converting those to SVG
   Arron: Each one of these testcases are slightly different. Several are
          parens/bracket/braces/quotes matching
   Arron: The first one is the most interesting, using invalid characters
   Arron: Trying to see if they match correctly
   Arron: There are lots of interop issues, but at least 2 impl for most results
   fantasai: I think we wrote the tests under the assumption that only nmchars
             are allowed in unquoted font names
   fantasai: brackets tests are more complex because they also test that
             they're matched correctly
   <anne> 002.xht is fun
   dbaron: So, you're allowing idents, dimensions without + or decimal point,
           numbers without + or decimal point.
   Bert: you have to define in terms of tokens, not character sets
   Bert: Should allow periods
   dbaron: If we allow periods, we have the float round-tripping problem
   random discussion of various option
   Anne says we should just use ident+
   Bert says it's confusing not to allow numbers unquoted
   dsinger says it's reasonable to quote them
   <bradk> FYI, the third test (Invalid curly brackets and pair matching)
           passes in a recent nightly download of Webkit, even though it
           fails in Safari.

   general consensus that the discussion is going nowhere
   Options are:
   1. identifiers only
   2. nmchars tokens only
   3. try to come up with a grammar to make the current prose more clear
   ChrisL: I need to take this back to the SVGWG and get feedback from them, so
           we shouldn't make a final decision here.
   1. http://lists.w3.org/Archives/Public/www-style/2010Mar/0369.html
   2. http://lists.w3.org/Archives/Public/www-style/2010Mar/0395.html
   3. To Be Written
   FF and Safari are almost ident+
   or are ident+, but have bracket-matching bugs :)
   Opera is close to the current prose
   IE is somewhere in between, but closer to Opera
   Anne: 1
   Steve: 1
   Sylvain: 1
   Alex: 2, but live with 1
   Beth: 2
   Bert: 3
   Arron: 2 or 3
   Elika: 2, live with anything as long as clear
   dbaron: 1
   Brad: don't care
   Tab: 1
   Tantek: Abstain
   Glazou: 1, but can live with everything
   ChrisL: 3, 2, 1
   Peter: 2 is slightly better for authors in that it would be a little
          surprising to not start with a number
   Peter: I don't like the fact that 2 introduces a new token type, so 1
   Bert: I think it can be done without
   Howcome: 3
   Elika: Actually, I'm going to change my vote to 2, then 1
   dsinger: abstain
   Steve: I can live with 2 also
   Steve: I don't really see much difference between 1 and 2
   <smfr> smfr has joined #css
   Peter: My real preference is that people quote things more
   Steve: That's why I voted for 1
   glazou: Can't go further, Chris has to take this to SVGWG first
   glazou: 7 for 1, 4 for 2, 3 for 3, and almost everyone can live with
   glazou: which is cool
   ACTION: clilley Discuss font-family syntax with SVGWG
   <dbaron> http://test.csswg.org/source/contributors/microsoft/submitted/Chapter_15/font-family-invalid-characters-002.xht
            is buggy because it has ( { ) and expects the ) to match
            the ( while you need to find a } first
   <Bert> (Minor flashback to 1996: font-face was modeled in part on
          Netscape's FACE attribute.)
   dbaron notes that Mozilla has seen only one bug, that dbaron could
          find, on this issue
   <dbaron> I went through bugzilla.mozilla.org bugs with 'font-family'
            and 'quote'... there were 4 reported by users (also one
            internal code issue).
   <dbaron> One was about this issue, two were complaining that
            font-family: 'sans-serif' didn't work, and one was complaining
            about font-family: 'Arial, Helvetica'; not working
   <dbaron> The one that was about this issue was

   dbaron: Anne, I don't understand why getComputedStyle is relevant
   Anne: http://dump.testsuite.org/2010/width-computed-value.htm
   Anne: If you set width: 10em on an inline, and then inherit it to
         a block, you get 10em
   Anne: But the spec says the computed value, the inherited value,
         should be 'auto'
   RESOLVED: Proposal accepted for Issue 163

   http://wiki.csswg.org/spec/css2.1#issue-162 raised by i18nwg
   data:text/html;charset=utf-8,<!DOCTYPE HTML PUBLIC "-%2F%2FW3C%2F%2FDTD HTML 4.0%2F%2FEN">%0D%0A<html 
lang%3D"en">%0D%0A <head>%0D%0A  <title>Test<%2Ftitle>%0D%0A  <style type%3D"text%2Fcss">%0D%0A  <%2Fstyle>%0D%0A 
<%2Fhead>%0D%0A <body>%0D%0A   <ul dir%3Dltr>%0D%0A     <li dir%3Drtl>Bullet%0D%0A   <%2Ful>%0D%0A 
   FF renders the bullet on the right
   as does Chrome
   Opera renders on the right
   IE renders on the right
   dbaron: So this is a proposed change where every impl we've tested
           matches the current spec
   dbaron: Direction changes are a relatively rare case
   <dbaron> ... especially in the middle of a list
   Daniel: If you have a <body dir=ltr> with <div display:list-item dir=rtl>
           then you wouldn't see the right direction for the marker
   <dbaron> Yeah, I think this change seems wrong for the general
            display: list-item case.
   <dbaron> Even if it might make sense for the way HTML li elements.
   Steve: the most obvious example I can think of this giving a list
          of phrases in different languages
   Steve: I'd want the bullets lined up
   dbaron: You don't want to change the block direction in Steve's case anyway.
   dbaron: Because the alignment will change
   Steve: Why can't I set text-align?
   Steve: I can't think of a case where you'd want the bullet on the right
   dbaron: You can have list items that are not using HTML list markup
   Peter: so are we rejecting this then?
   TabAtkins: As a side point, markers clearly belong to the list-item, not
              the enclosing block.  The color of a list marker comes from
              the list-item.
   <dbaron> http://www.w3.org/TR/CSS21/visuren.html#dis-pos-flo
   <dbaron> ... says list items can float
   <dbaron> ... and keep their marker
   Steve: What I've heard is that we're already committed that the marker
          is part of the list-item
   fantasai also points out that it would create an inconsistency with
            'list-item-position: inside' items if we swapped the direction
            of the bullet based on the parent for 'outside'
   dsinger: So we should resolve this and offer to i18n that we can add a
            note explaining how to get their desired effect
   RESOLVED: No change for Issue 162 in normative behavior
   Bert and fantasai discuss ways to allow a switch in this behavior in
       CSS3, possibly using the bidi-isolate concept
   ACTION: fantasai move issue to css3-lists

   TabAtkins: [draws a picture with a containing block A, some number of
              descendants B, and a positioned descendant C.  Any overflow
              on B has no effect on C, because A is C's containing block.]
      | In certain cases, a box may overflow, meaning its content lies
      | partly or entirely outside of the box, e.g.:
      | ...
      | A descendent box is positioned <del>absolutely</de>, partly outside the box.
      | Such boxes are not always clipped by the overflow property on
      | their ancestors. <ins>Note that absolutely positioned descendant
      | elements are not always clipped by the overflow property on their ancestors.</ins>
   dbaron: I thought the proposal was the replace the Such ... ancestors sentence
   fantasai: I think that makes a lot more sense
   apparently this was the original proposal, fantasai just forgot
   Peter is concerned that "not always clipped" is unclear
   dbaron: I think the reason for the change from such to note is because
           we're removing absolutely from the first sentence
   <bradk> "a positioned item is not affected by the overflow property of
           ancestors inside its positioning block."
   <bradk> s/positioning block/containing block
   dbaron: And ambiguities in the second part of the sentence should be a new issue
   <fantasai> so s/are not always clipped by the overflow property/do not always cause overflow/ ?
   ACTION: Tab Rewrite proposal for Issue 161

   glazou: Melinda got it backwards
   ChrisL: Prefix the sentence with "For example", because Japanese top-to-bottom
           books start like rtl books do
   <dbaron> css3-page says it the right way around in
   RESOLVED: Add non-normative for-example change

   Proposal Fix 96px per inch. Whether inches fixed to reality or pixels
            fixed to screen res / viewing distance / something else may
            vary by UA. (Print would match real inches, screens tend to
            align with viewing distance and/or screen res.)
   Peter holds up his iphone.
   Peter: You are constantly zooming in and out on this device. There's
          no guarantee you'll ever get a physical inch for an 'in'
   SteveZ: You have the canvas, and the window onto the canvas.
   SteveZ: You have controls to change the window onto the canvas
   <Bert> (The problem is not zooming on the iPhone, the pb is that a very
          small percentage of people thinks that it is illegal to use px
          on font-size. We just need to tell them that is not so.)
   dbaron: Are any other browser vendors willing to change their implementation
           to match the 'pt' unit to match physical 'pt' using monitor detection
   dbaron: Everyone assumes 96dpi. So there's pressure on us to do that.
   Steve: It's all your fault Tantek.
   Peter: You and I had a discussion in an elevator where we agreed that
          Macs would use 96dpi instead of 72dpi
   Peter: And you showed me UI that would allow the user the ability to
          set an inch correctly by holding a ruler up to the screen,
          which was cool.
   Peter: I'm happy to give users that capability
   Peter: If the UA wants to have a zoom factor of Actual Size, then it
          can use the OS info to get the most accurate 1in == 1 inch
          rendering it can
   lots of conversations
   <bradk> If the UA decides on having an "actual size" mode, and the
           monitor is not really 96ppi, then GIF images and such would
           have their pixels interpolated.
   <ChrisL> "The suggested reference pixel is the visual angle of one
             pixel on a device with a pixel density of 90dpi and a
             distance from the reader of an arm's length. For a
             nominal arm's length of 28 inches, the visual angle is
             about 0.0227 degrees. "
   <ChrisL> http://www.w3.org/TR/REC-CSS1-961217#units

Meta-Viewport Interlude

   Tantek talks about a meta-viewport problem
   Alex: For Facebook, I found that in the virtual viewport the bar
         at the bottom was fixed-positioned, but you couldn't get to
         it unless you scrolled down
   Tantek: Shouldn't the meta viewport tag be a CSS thing, not a
           proprietary meta tag?
   Tantek: The exact problem that meta viewport solves, that should
           be in CSS
   glazou: What happens if you browse a meta-viewport page with Safari
           on the mac?
   smfr: It ignores it
   Anne, Sylvain: Meta-viewport is setting the size of the viewport
   and then the UA zooms in to that size
   Tantek: Most other mobile browsers display a page designed for mobile normally
   Tantek: But the iphone made it into this tiny box in the corner of the screen
   Tantek: Even if you do use a media query to select an appropriate styling,
           then it still doesn't behave appropriately
   Sylvain: It defines what a pixel is as a fraction of the viewport
   fantasai: So it's setting the size of the initial containing block
   fantasai: not the viewport
   smfr isn't sure
   Tantek: If I write a media query to serve appropriate style sheets
           for 350 pix, Safari scales the page down to a tiny thing
           in the corner
   smfr: That's a bug, and we have it filed
   fantasai: If we don't have a proposal on this, then I think we
             should close this topic

CSS2.1 Issues (cont.)

   dbaron: Did we have a resolution on the 2.1 issue we were talking about?
   howcome: I want to see the proposal before deciding
   howcome: I think the spec already says this
   peter points out that it doesn't
   and we go around in circles again
   I'm so not minuting this
   <anne> Bert, http://xkcd.com/386/ ;)
   Bert argues that we should evangelize the web
   Alex: In IE8 we tried matching px to in based on the resolution, and
         this broke lots of things so we changed back to pretending 96dpi

   <dbaron> For issue 148, I'd like to figure out why we changed it in
            the other direction.

Meeting closed.

   dbaron and fantasai investigate the CVS logs after hours and find that
   the change was made as part of a "lowercase html tags" change in 2002.
   No evidence of why the semantic change was made.

Received on Thursday, 8 April 2010 07:15:33 UTC