[CSSWG] Minutes and Resolutions Hamburg F2F 2012-05-10 Part III: Alignment, Grid Layout, Fonts

Box Alignment

   fantasai presented a proposal to converge all layout models on a single
   set of alignment properties:

   - RESOLVED: fantasai to continue working on this proposal
   - RESOLVED: flexbox alignment properties to be replaced by css3-align

Grid Layout

   - RESOLVED: rename the values of grid-flow so that row adds rows, column
               adds columns, and layer just stacks grid items on top of each
   - RESOLVED: add row-gap and column-gap to the specification such that they
               provide uniform gutters
   - Also discussed scoping of Grid Layout vs. Template, ways to remove
     overlap, and scoping things for Level 1 vs. higher. No conclusions.

CSS3 Fonts

   - RESOLVED: fallback for font-variant-position occurs per run rather
               than per-glyph
   - RESOLVED: the 'font-variant-position' property is defined independent
               of the existing use of the font-size/vertical-align properties
               to synthesize subscripts/superscripts
   - discussed small-caps fallback per-script rather than per-font,
     and using text-transform rules for synthesizing small-caps
   - noted proposed updates to prose for font-family syntax to match 2.1

Spec Editing

   - vhardy showed off a tool to help editors synchronize specs with Bugzilla
   - plinss explained plans to host test-annotated /TR specs

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

Box Alignment
Scribe: sylvaing

   <dbaron> http://fantasai.inkedblade.net/style/specs/css3-align/02
   * Bert, seeing that we have failed to solve it in the past 12 years,
           wonders if 30 minutes really will be enough. :-)
   fantasai: the idea is to "align" all the CSS alignment properties and
             resolve issues that have been put off for a long time
   fantasai: CSS1 and 2 supported text-align, vertical align, auto margins
   fantasai: new modules had many more alignment methods such as flexbox,
             which has five alignment properties
   fantasai: grid adds two properties
   fantasai: this doesn't even cover vertical alignment in block layout
   fantasai: and in order to support the alignment attributes in html,
             more properties will be needed
   fantasai: so the challenge is to come up with a set of common properties
             that can be shared across modules
   fantasai brings up the proposal

   fantasai: there two axes of alignment
   fantasai: the dimension affected: primary (inline/main) or secondary
   fantasai: and what is aligned: you'll either want to align the box within
             its parent or align the content of the box within itself
   fantasai: i tried to come up with a logical system to organize both axes
   fantasai: the first part of the name defines what is getting aligned:
             "box-", when the box aligns itself,
             "content-" when its content is being aligned
   fantasai: then "-justify" is in the inline axis and "-align" is in the
             stacking axis e.g. box-align, box-justify
   howcome: are these meant to be aliases?
   fantasai: they would replace flexbox and grid properties, and add new
             functionality to block and table alignment
   howcome: if people use text-align?
   fantasai: this is separate, none of these affect text-align
   howcome: so text-align and content-justify do not overlap ?
   dbaron, fantasai: content-justify align children
   (discussing axis and checks in the overview table in the spec)
   fantasi: box-align does not apply to blocks because a block can't control
            its vertical position within its parent, it can only control its
            horizontal position
   (fantasai draws diagram on board; properties are set on red box)
   fantasai: a grid item inside its grid cell can do both dimensions
   fantasai: I map box-justify to grid-column-align and box-align to
   fantasai: if the inner element is a block, it can't control its own
             alignment within its parent but it can control its box-justify
   dbaron: so in inline layout justify controls the horizontal layout.
           shouldn't -justify control vertical alignment for blocks?
   fantasai: no, -justify controls the inline direction alignment
   fantasai: justify is horizontal alignment, align is vertical (modulo
             writing modes)
   dbaron: I thought we should have only 4 properties out of these 6
   dbaron: I think we could do without box-justify and items-justify
   fantasai: no, because grid needs box-justify
   fantasai: box-justify works in a manner similar to margins but adds
             to margins
   fantasai: the use-case for box-justify in blocks is wanting margins
             in addition to alignment
   fantasai: for example if I have a shrink-wrapped table, I want a 1em
             margin around it but I also want the table centered
   fantasai: but if the table fills its containing block I still want
             1em between the table and its containing block
   <Bert> (TeX-way to center: 'margin: 1em + 1fill')
   dbaron: I thought this is what box-align did
   fantasai: content-justify applies to the children of a block. it has
             an auto value which, only on a block element, computes to
             the value of its parent. this supports the HTML align
             attribute which inherits
   fantasai: content-align allows the children of a block to be centered
   fantasai: it's like vertical-align for tables but applies across other
             box types
   fantasai: any value of content-align other than auto creates a BFC
   vhardy: any value to automatically distribute space using content-align?
   fantasai: we could add a distribute value

   florian: since flexbox would depend on this, how do we move forward?
   fantasai: we would rename all the relevant flex properties using these
             names. we would define how they work for flexbox. for other
             elements, they have no effect unless defined by another module
   florian: we could keep the flexbox properties as they are. later we can
            introduce the new ones and they would work as shorthand
            expanding into the block align longhands. not sure whether
            that would make them aliases on the OM side.
   szilles: is it just a name change or is it a semantic change ?
   fantasai: it's a name change for flexbox
   szilles: I'm trying to distinguish their impact on flexbox vs. other
   szilles: if it's only a name change for flexbox this is very scoped.
            whether we propagate this to other modules can be done at a
            later time
   florian: except these properties can be applied to other things today
            and do nothing, then someday they'll do something
   dbaron: I agree with both of you. the timeframe of this evolution
           would have to be contained.
   (fantasai draws pretty blue and red boxes on paper)
   (multi-line flexbox with a number of items)
   fantasai: the alignment of flexboxes is controlled by 5 properties
   <sylvaing> if content-* applies inside and box-* applies outside,
              should future display-inside/display-outside align their
              name too?
   fantasai: alignment of text to bottom inside red boxes is controlled
             by content-align on red boxes
   fantasai: alignment of red boxes within line is controlled by
             box-align/flex-item-align on red box, whose auto value means
             to default to item-align/flex-align on green box
   fantasai: alignment/distribution of red boxes within line is controlled
             by content-justify/flex-pack
   szilles: there is an analogy between lines in flexbox and lines in text.
            this model scales up the text behavior higher up.
   dbaron: I think the axis make sense in this flexbox example. I'm not
           sure I agree with the block example.
   alexd: I think we should rename *-align with *-stack e.g. box-stack,
   fantasai: I'm not sure content-stack: baseline sounds right

   <Bert> q+ to ask about mixture of 'box-align: bottom' and 'box-align: top'
          on siblings.
   howcome: I don't really understand how this applies to blocks. don't
            you have to take it out of flow?
   fantasai: no. you would make your content center vertically
   fantasai: the entire content of a box has a particular height; if you
             have leftover space you can align within that
   bert: content-align aligns all the content. how do I align one child?
   fantasai: how would you align only one child?
   <dbaron> Bert's case is the reason I don't think we should have box-justify
            and items-justify
   bert explains his example: a 4-column layout, each column has some
        images, text and color information at the bottom....
   <Bert> http://www.w3.org/Talks/2012/0509-CSS-ftf/scan-12-small.jpg
   fantasai: I think this is a case that should be handled using flexible

   florian: what are we resolving on?
   fantasai: 1) whether we want to move towards a common alignment model
             2) whether we want flexbox to be based on this proposal
   szilles: I think we should move flexbox to this. this will also help
            upcoming modules.
   fantasai: I think you want both content-* and text-* properties since
             you might want to align the blocks children and inline
             children of a block differently
   howcome: how does this interact with floats?
   fantasai: I don't think it applies to floats
   howcome: don't we want to look into this before moving this beyond flexbox?
   szilles: we're no worse off with this names vs. the flex-* ones
   szilles: these might generalize
   florian: there is a risk that these properties will be applied using
            'blanket' selectors and content will break in the future.
   fantasai: I can work on this at a high priority
   florian: we do not have content dependency for flexbox at least
   vhardy: I think this is a great proposal. I agree it's high priority.
   howcome: I think the start/before value names will confuse people
   bert: most people don't need start/end/before/after
   howcome: we should keep using top/right/bottom/left, this is what users
   plinss: can we resolve to keep working on this?
   dbaron: I agree we should resolve to work on this
   RESOLVED: fantasai to continue working on this proposal
   fantasai: see Issue 2 about the naming model
   RESOLVED: flexbox alignment properties to be replaced by css3-align
   <Bert> (Where I think "this proposal" means: an attempt to generalize
          alignment across different box types, not necessarily with six
   florian: I'm happy with box and content
   vhardy: I find the verb-what convention easier
   vhardy: we got feedback on Regions/Exclusions that vert-object structure
           was awkward in CSS

Grid Layout
Scribe: Shane Stephens
   +Phil Cupp
   +Daniel Holbert
   +Markus Mielke

   <fantasai> my issues list -
   fantasai: I compiled a list after discussing with Microsoft

   Scoping =
      1. Scoping of Grid Layout and Template Layout specs
      2. Drop named lines from this level of Grid Layout
      3. Adopting column-gap etc., adding row equivalents, to handle gutters

   fantasai: scoping principles we tried to apply were minimum set that
             is useful for this level of grid
   fantasai: to just reduce to as small a set as possible
   fantasai: other principle was to just have coordinate based system and
             leave others to a higher level
   fantasai: more sophisticated addressing handled by template or level 2
             of grid
   fantasai: from those principles came suggestion: move template out of
             grid and have bert keep in template spec
   fantasai: drop named lines from this level of grid layout
   fantasai: other issues on positioning things with negative indexes or
             indexing from last line - push out as next level feature
   fantasai: just focus on layout and positioning needed for layout
   markus: didn't make sense to have template in both specs
   markus: 2nd reason wanted to get more implementations faster
   markus: got feedback from firefox about core aspects and want to reduce
           to those aspects
   markus: tried to reduce complexity for first version
   phil: questioned whether or not the grid is suited to thinking about
         content in tracks and position content by defining rectangular
         area using start track and span length
   phil: or instead talk about lines.
   phil: conclusion was that you needed to talk about tracks in the spec
         because all the styling functions are creating space for tracks
   phil: but only need to talk about lines if lines are part of a
         positioning scheme
   phil: so it's easier to eliminate the concept of lines and just talk
         about tracks
   phil: think we can simplify all the language in the spec
   tabatkins: and then later on name the tracks
   plinss: I want to avoid that. The real power in grid is having the lines
   phil: real power in grid is dividing the space afforded to the grid by
         its parent
   phil: whether you make use of the space by referring to four lines or
         some tracks that intersect is a difference of perspective
   phil: doesn't change functionality
   plinss: I think it's a mental model shift. The way grids have been used
           traditionally in page layout, designers don't think in terms of
           tracks but in terms of lines.
   plinss: page layout with grid - classic example: multiple columns, one
           with sidebars and no text. The column next to that one - the
           headings span out into the sidebar column.
   plinss: the headings should be part of one flow in the middle track,
           but certain elements snap to different grid lines so they
           don't really live within a track.
   phil: I totally agree they don't live within a track, but think of the
         model - track has content structure. You define tracks and cells
         with additional properties. In grid you can have overlapping cells
         because the rectangular region is defined on the items. Free to
         say you have a heading that spans into some center track and then
         something else that intersects but doesn't occupy the same space.
   phil: not in same container but share reference to same tracks (??)
   phil: so I agree that tracks aren't containers, just spaces, and some
         of the intersections of rows and columns can define a region for
         positioning an item
   phil: so the concepts are equivalent.
   phil: Argument is that it'll be easier to read the spec if the mental
         model is around tracks.
   plinss: I agree that the shift in terminology isn't changing the features
   plinss: my concern is the mental model. CSS is about cells and boxes,
           grids gives you a different model. I don't want to lose that.
   phil: Are you a fan of the spec as it reads now?
   plinss: I haven't had a chance to look
   markus: Feedback we got is that spec is confusing. Reading through it
           introduces lots of models that do the same thing.
   markus: Confusion: which should be used?
   markus: We agree with your point. Lots of possible positioning models
           that can live on grid. Absolute positioning. Templating.
   markus: which is the fundamental concept and which can build on that?
   phil: 4 positioning schemes in current spec: template, named line, using
         numbers to denote start/end lines, using numbers to define starting
         track and span length
   phil: we want to boil that down to just 1
   phil: because simpler is better
   plinss: let's move on. I'll provide feedback over email.
   stevez: 2 other things that lines give that change functionality:
           (a) by using lines instead of numbers can add a line in the
               middle of the grid and don't have to redo positioning.
               Named lines give you more editing generality.
   stevez: (b) using media queries can come up with different grids using
               same named lines for different media - e.g. branch headings
               out if there's enough space.
   phil: One distinction - we're talking about the concept of lines as
         numbers vs. tracks as numbers, not concept of named lines
   phil: There's no difference between numbering systems. Doesn't apply
         to named lines.
   stevez: we are talking about named lines.
   phil: your point: do we need some kind of indirection? Argument is one
         of leveling - does it need to be in the first version of the grid
   phil: not minimum level of functionality that provides usability
   stevez: if you want to give users a good model for using grid, not
           having naming schemes leads them down the wrong path.
   plinss: if you want to avoid complexity, drop indexed system before
           name-based system.
   markus: we are seeing that it's easier for people to think in terms of
           numbers right now, because of history. Wouldn't go against that
           right now.
   phil: also defer because the concepts need time to mature. Discussion
         with fantasai indicated named lines got verbose because you're
         naming all 4 edges.
   phil: but with template syntax only need to assign one value.
   phil: When using named lines, theory is you want something that says
         this is my header start line, header end line. Need pairs for
         both row and column dimensions. Now if you want to change
         definition of grid, relocate those four names. With that model
         you're going to have 4 names x number of grid items that you
         want to make maintainable. That's lots to type - haven't created
         ease of maintenance tool.
   phil: not convinced that named lines actually solve the problem we set
         out to solve. Not positive that templates are better.
   phil: but shorter to type, and talking about regions instead of items -
         can't type 2 letters in same spot.
   phil: argument against template system is it doesn't give full power
         of grid.
   phil: both of these areas could use some bake time.
   * sylvaing notes we have now spent 25mn on the same issue
   plinss: let's move on

   <Bert> names require you to think of names, where there actually is no
          semantics, and it is not extensible for auto-placement
          (a-priori unknown # of rows)
   bert: need numbers anyway
   bert: so that's enough to have in the core. Can add other notations later.

   fantasai: next issue: discussion on mailing list about adding ability
             to do gutters on grid lines so you don't need to create an
             extra set.
   fantasai: we said we could reuse the column-gap property
   fantasai: so also add row-gap for other dimension
   bert: not necessary, very limited - can only have one type of gap for
         all columns. If you have something that spans multiple columns
         where does the gap end?
   fantasai: would span over the gap.
   tabatkins: one of the reasons you need this kind of gap - if you want
              to do flex box in a grid you can kind of do it <draws on board>
   tabatkins: but you can't specify gutters. If you do them as empty rows
              and columns the content will try to expand into them
   tabatkins: really want a declarative mechanism
   stevez: why isn't that a property of a track?
   phil: tracks don't have properties because there's no track element to
   tabatkins: could put into grid rows, but is unclear which track the
              gutter would belong to
   phil: they're the spaces between the tracks
   tabatkins: probably almost always want uniform gutters
   stevez: not objecting to simple mechanism, but bert's point was that it
           doesn't provide arbitrary gutters. So a separate mechanism for
           specifying a col or row that is intentionally blank seems to be
           a useful feature.
   stevez: was in original proposal
   tabatkins: +1
   fantasai: in the cases where you want non-uniform gutters, usually you
             have small number of elements that you're styling individually
             anyway. Easier to use margins for that.
   phil: so uniform gutters mean we could just adopt column-gap and define
         row-gap. If we want a non-uniform mechanism we'd need to provide
         a list of gutters or something
   markus: sounds like a great feature for next level
   stevez: actually I was saying you could declare a column or row as being
           a gap
   phil: like a gap() function or something
   bert: can leave that to templates. That's what they do
   markus: sounds like agreement for a basic mechanism in spec

   fantasai: next, some naming things. Grid spec has grid-flow, want to
             align with syntax of flex-flow
   fantasai: row means add more rows as you add content, column means add
             columns, layer means create stack in the current cell
   fantasai: previously row and column were flipped. Very confusing.
             None becomes layer to be more clear.
   markus: feedback from tooling people - really liked layer approach.
           But others might want to do things other ways.
   bert: alternative I had was to use grid-row property for that - have a
         keyword that says this goes into next row, and one on column that
         says this goes into the same column
   fantasai: doesn't handle a lot of auto-placement situations because you
             can't wrap onto the next line. If you have 100 items and just
             want them to flow into a grid, can't do that without nth-child.
   * sylvaing are we resolving anything?
   fantasai: if you throw in different spans, definitely can't do that.
   bert: can do that with normal selectors
   tabatkins: yeah need to explicitly do it. More complex than it should
              be for the use case.
   bert: normal case is that you don't fill lines but that certain elements
         need to be in particular places.
   tabatkins: still really easy to do in this syntax
   fantasai: both use cases useful, each set of syntaxes can do things the
             other one can't. So we should have both approaches.
   bert: e.g. I want to have a table, transposed. That's easy to do by
         saying every td:first-child goes into the next column
   howcome: are you saying this is possible with grid flow?
   bert: yes
   phil: grid flow would be property of grid. Not targeting individual items.
   bert: but if you want every <tr> to start a new column, then (??)
   markus: so we all agree basic functionality should be there but are now
           talking about finer points. Move to email? Both approaches have
           value, different ways of achieving same thing
   <Bert> tr {grid-flow: column} td {grid-flow: row}  or
          td:first-child {grid-column: next; grid-row: 1}
   discussion about repeat patterns and whether row means row
   * sylvaing feels sorry he suggested resolving something
   RESOLVED: rename the values of grid-flow so that row adds rows, column
             adds columns, and layer just stacks grid items on top of each
   <Bert> (So if 'grid-flow' doesn't influence the autoplacement, how do
           you say where the next child goes?)

   phil: let's go back and see if there are resolutions on the other ones
         too. Gutters:
   plinss: we only had a dissuasion, no conclusion.
   bert: we don't need them. We can use margins.
   tabatkins: margins don't collapse. So you get double-wide gaps in the middle.
   tabatkins: you want 0 on the edges and 10 on other lines. Can't do it without using nth-child
   <Bert> div::slot(a) {margin-left: 10px}
   phil: also can't center the margin on the line
   phil: are there any objections to adding these?
   bert: certainly not in the core, they might hurt us later
   stevez: same as multicol?
   bert: I think we're doing the wrong thing but won't give an objection
   <BradK> I'm in favor of gutter gaps
   bert: I've never needed it. Why add it?
   phil: I didn't hear your solution to putting the gutter down the center
         of the line rather than on one side.
   RESOLVED: add row-gap and column-gap to the specification such that they
             provide uniform gutters

   phil: lines versus tracks as numbering. I don't think we'll get a
         resolution on that but we have an action.
   ACTION plinss to read new version of spec and provide feedback to phil
   <trackbot> Created ACTION-461

   phil: alternative addressing schemes. grid template syntax with lettering
         of cells and named lines - proposing that they are deferred
   <Bert> I think Elika's split means:
          Core = 'grid-rows', 'grid-columns',
                 'grid-position-{x,y}' (incl. same/next/auto-placement),
                 'vertical-align' (or equiv.),
                 and the constraint system to calculate sizes, pagination.
          Rest = 'grid-template', 'grid' shorthand, ::slot(), 'flow',
                 (and then in level 4: 'chains', page-based grid templates)
   phil: do we have a resolution or action?
   stevez: not in favour
   stevez: worried we won't ever specify these modes
   dbaron: I think that if you think the feature is important you should
           keep it in
   dbaron: not familiar enough with specification to have strong opinion,
           but reasoning is dangerous because you can take a long time to
           get back to things
   plinss: I share steve's concern that by not having it in level 1 you
           won't teach people to use it the right way
   fantasai: would prefer to keep template rather than named lines, agree
             that named lines syntax is really awkward.
   plinss: I propose we revisit this when I have had a chance to provide
   <BradK> I hope we can at least keep templates.
   stevez: I'm concerned that moving templates out of this spec and into
           bert's changes behavior. It's a non-trivial change.
   phil: I think there needs to be clear scope separating these two specs.
         Right now there's significant overlap, with some conflicts.
   <BradK> Templates and grid go together very well. Like chocolate and
           peanut butter.
   phil: beyond that, there's additional functionality in the templates
         spec that we don't want to see come into the grid spec.
   fantasai: declaring grid, positioning, templating and layout algorithm
             are in both specs and incompatible.
   fantasai: need to move them into one place
   bert: more compatible than they used to be.
   sylvaing: but still in 2 places
   stevez: I'm concerned that if templates are to provide a named interface
           to grids, having them in a different spec is a bad idea.
   fantasai: well that's fine, they still need to be in just one spec
   phil: have had 2 specifications because of disagreement on some
   phil: needs to be a resolution about which model to support, and which
         specification to put it in.
   plinss: don't have enough time to solve this right now.
   ACTION Markus, Phil and Bert to get together and work out how to resolve
          the templating specifications to remove overlap
   <trackbot> Created ACTION-462
   <PhilCupp> thanks for great grid discussion... dropping off call

   -Phil Cupp
   -Daniel Holbert
   -Markus Mielke

CSS3 Fonts
Scribe: dbaron

   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2012May/0369.html
   jdaggett: I just dropped in url for post I sent a few days ago
   jdaggett: CSS3 Fonts defines support for font features.  Designed to
             enable features if they exist in the font, but we don't provide
             a fallback.
   jdaggett: But there are a couple of exceptions where we do provide fallback:
   jdaggett: For small-caps, if a font doesn't have small-caps glyphs,
             user-agent will synthesize
   jdaggett: Other case where we do fallback is superscript and subscript,
             which is semantic, so requires fallback
   jdaggett: [Shows demo]
   jdaggett: I have a bunch of fonts with subscript and superscript variant
   jdaggett: this shows what you see with browsers today and with variants
   jdaggett: first is the subscript variant designed by the type designer --
             the weight is designed to match the weight of what it's in
   jdaggett: the third shows what happens when you shrink it down -- it
             looks lighter
   jdaggett: these special subscript/superscript glyphs are designed in the
             same design space as the font -- there's no resizing/offsetting
             for the subscript/superscript when using the glyphs designed
             for it
   jdaggett: the way we do subscript/superscript today we modify the baseline
             (vertical-align: sub/super) and reduce the font size
   jdaggett: To use the sub/super glyphs, you have to not do that
   jdaggett: The font also has metrics that say the suggestions of the font
             designer for where the subscript should go (position & size)
   jdaggett: the middle (red) item is a super/sub sized and positioned based
             on these metrics
   jdaggett: they're not matched to the variant glyphs (e.g., less offset
             in Minion)
   jdaggett: or, e.g., in Whitney, the metrics are bigger and less offset
             to compensate for the weight
   jdaggett: problem with this:  in a situation where some characters are
             supported and others are not, it's difficult to synthesize a
             matching combination
   (clarifying question from vhardy about diff betw 2nd and 3rd)
   jdaggett: so, if we just use variant glyphs, we'll have problems:
   jdaggett shows Minion Pro having variants for "(", "2", and ")", but
            not for "[" and "]"
   jdaggett: in the first link, one of my first points is that when we do
             fallback, we need to do it across the entire text span
   jdaggett: so we synthesize even when part of the text span supports
             part of the variant glyphs
   jdaggett: So with Minion pro you'd synthesize all of "[2]" but would
             use variant glyphs for all of "(2)"
   jdaggett: The metrics aren't there in the font to let us synthesize on
             a per-character basis
   SteveZ: So this is unusual since we're doing glyph substitution on a
           per-span basis rather than per-char basis

   jdaggett: The other problem we have here is that we have this existing
             mechanism for superscripts and subscripts that does it in a
             structural way
   jdaggett: coming up with a backwards-compatibile way of doing this is hard
   jdaggett: since if you use the designed glyphs, you need vertical-align:
             baseline and inherited font size, i.e., need to turn off
             existing mechanism
   jdaggett: see testcase in bottom of post
   jdaggett: you can see that for this case we're turning on font-variant
             position superscript and turning off vertical-align and
             font size reduction from default style sheet
   <BradK> How do you define text span? All the text in an element?
           Including text that is inserted later?
   SteveZ: One side effect is that I no longer sure how to compute the
           vertical extent of the subscripts and how they affect line
           height according to css
   jdaggett: in my mind, this should have no impact on the line box
   jdaggett: when the designer put the metrics in, they're designed so
             they're just like any other character
   SteveZ: so there's no actual baseline shift
   fantasai: there's a visual shift, but no actual shift
   jdaggett: So whether it has subscripts or not, this will produce a page
             that doesn't have varying line heights
   jdaggett: there was a proposal (see post) from fantasai and dbaron to
             come up with something that would shoehorn magic behind the
             scenes so when this matched vertical-align, you'd undo the
             vertical-align and font size changes
   jdaggett: what this won't do is cover the case where you have nested
             subscripts or superscripts
   jdaggett: (replying to Florian) fonts never have glyphs for nested
   jdaggett: And this won't line up with images (since you're not getting
             the baseline shift)
   jdaggett: So this can only do a subscript of the super/subscript stuff
             you can do today.
   Florian: So if you have an image and glyphs, you can't use the special
   jdaggett: So what I'm arguing for is that we have less magic, and authors
             have to be aware that this is only typographic sub/super and
             not structural
   fantasai: So if authors try to use this for sub/super, the
             sub/superscripting will fail for nesting or non-text
   jdaggett: Details of original post by fantasai/dbaron rely on metrics
             which doesn't work since these metrics aren't right
   jdaggett: I think you could still come up with magic that ... .
   jdaggett: There's existing content that's out there, so it's safer to
             say that: here's how you do this, cover the 90% use case
             (just text, short runs).
   jdaggett: Do we need to talk more about alternate proposal, wanting magic?

   fantasai: How do you determine bounds of text run that needs to be
             considered together?
   jdaggett: No wording for that yet.
   jdaggett: Wanted general agreement for it first before getting to actual
   jdaggett: Thinking roughly: across spans of contiguous text (but can
             span sub-elements)

   SteveZ: If I've got a span, and turned on typographic sub/super, and
           do a baseline shift inside that, what happens?
   jdaggett: You get a baseline shift -- probably not going to look right.
   peterl: I'm not seeing in the email how you turn on this type of superscript
   jdaggett: just turn on font-variant-position
   jdaggett: There's an example in the spec that includes the turning off
             of v-a and font-size
   TabAtkins: and for fallback, @supports queries
   Bert: That example tests whether the user-agent is able to do this, but
         doesn't check whether the font has a suitable glyph
   jdaggett: Supporting the property means the UA will do fallback if the
             font doesn't support it
   SteveZ: That's the new piece added this time around
   fantasai: I'm not totally convinced we shouldn't be doing something
             smarter where people are putting elements inside it
   fantasai: I like the idea of doing the idea of fallback at a span level
   Liam: Isn't the answer that if you're already deciding not to use the
         native glyphs, then if you find an element inside, fall back to
         synthetic mechanism for the whole thing?
   fantasai: The way it's defined right now, super inside super wouldn't nest
   jdaggett: It's bad if you think it has to support that -- but I don't
             think we need to support that.
   jdaggett: There's already a default mechanism that allows that.
   peterl: If the designer specifies font-variant-position: sub, they'll
           get scaled down glyphs as fallback, right?
   jdaggett: yes
   Bert: ...
   jdaggett: ...
   Bert: ok, but I can see examples here... in general, do fonts scale down well?
   fantasai: It's better if you don't scale and use the appropriate glyphs
   jdaggett: the point here is to use the glyphs in the font
   <Bert> (I was thinking of the TeX fonts, which actually use slightly
          different glyphs for 8pt and for 10pt, so that you can use
          them together.)

   dbaron: How does this handle underlining?
   dbaron: That's sort of a common case
   dbaron: e.g. used in Wikipedia
   szilles: underline isn't affected generally
   dbaron: no, if you draw the underline just for the superscript
   dbaron: how do you get that position correctly
   jdaggett: so the answer here is that the underline will be drawn at the
             main baseline
   fantasai: you might wind up doing fallbacks in the case of text-decoration
   plinss: in Wikipedia, the decoration appears only on :hover -- that's
           not going to work
   peterl: Well, on wikipedia the underline only shows up on :hover, which
           would mean doing fallback when there's decoration wouldn't be
           so great
   dbaron: you'd switch into fallback on :hover
   ACTION jdaggett: figure out text-decoration interaction with
   <trackbot> Created ACTION-463
   ACTION jdaggett: define what scopes the run of things falling back
   <trackbot> Created ACTION-464

   proposed resolution: accept two points in
     pending actual wording from jdaggett
   fantasai: I'm less comfortable with second one since if you're styling
             content and didn't account for some of the stuff that's in
             there you'll get weird behavior
   jdaggett: I think we can resolve on this and then we can have caveats
   fantasai: Ideally, I'd like this to work in the general case
   jdaggett: I think that's a good ideal, but that ends up not serving
             the 90% case very well
   fantasai: I want to solve both and I think it's possible
   jdaggett: I disagree... but if you have another proposal we can talk
             about that

   SteveZ: informational question:  if in the middle examples, I wanted
           to make "2" black, so I put a span <sup>(<span>2</span>)</sup>...
   jdaggett: my action item to figure that out...
   jdaggett: My intention is that it's a contiguous text run; need not be
             one single element, so it would work
   jdaggett: if you say <p>f<span>i</span> in Firefox today, you'll see a
             ligature that's half black and half red

   peterl: fantasai, ok with resolving now, and you can maybe come back
           with improved proposal?
   fantasai: ok
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2012May/0375.html
   fantasai: I agree 100% with the first point
   RESOLVED: accept two points in
             jdaggett to provide actual wording

   jdaggett: relatively minor point about small caps
   jdaggett: with a font that has either small-caps variant or doesn't,
             we have the fallback be determined by whether the font itself
             supports small-cap glyphs
   jdaggett: i.e., that we don't do per-glyph checking
   jdaggett: That's different from the super/sub case.
   jdaggett: Good reason for this:  fonts typically support all or nothing,
             unlike for sub/super where they typically support only a few
   peterl: Typically, or universally?
   jdaggett: Close to universal
   jdaggett: A font like Arial is not actually designed by one person,
             designed by several people.
   jdaggett: Can get cases where Latin, Cyrillic work, Greek doesn't
   jdaggett: so I want cases that this can be done on a per-script basis
   jdaggett: which would allow user-agents to do this check on a per-script
   jdaggett: per-glyph checking is a much higher implementation cost
   jdaggett: there's a difference in the way the model works, but warranted
             by the nature of the font
   jdaggett: there's always the potential that what a browser would synth
             is not precisely what a font would do
   jdaggett: because of casing rules, e.g., for Greek
   jdaggett: so there's potential font won't match browser casing rules
   jdaggett: So, e.g., if you were to take a font that supported small-caps
             and strip out the information that enables it and have the
             browser synthesize it, those two results may not necessarily
             match the same set of characters, because the browsers upper/
             lowercase may not be what the font designer used when he set up
             the small-caps feature.
   fantasai: Does Greek keep diacritics in small-caps (rather than all-caps)?
   jdaggett: I'm saying there's room for differences
   jdaggett: I wanted to directly tie uppercase and lowercase function to
   jdaggett: I want the handling of synthetic small-caps to match the casing
             used in the text-transform feature, which means the check for
             "do I need to small-cap this glyph" uses the same case
              transformations that are used for text-transform
   fantasai: There are 2 casing things you need to do:
             (1) check "is this glyph lowercase?" and if so synthesize a
                 small-cap and
             (2) convert from lowercase to uppercase and shrink the glyph
   fantasai: (2) is where you need the case transform table
   jdaggett: And I'm saying that should match text-transform
   fantasai: the wording here is really vague:
   fantasai: capital letters are not affected by small-caps
   jdaggett: but are by all-caps
   fantasai: so you want to say only bicameral scripts are affected
   jdaggett: I want to say it's exactly like text-transform
   jdaggett: i think these 2 features should be consistent
   * fantasai just thinks the wording proposed is confusing
   SteveZ: implied text-transform...?
   jdaggett: I'm just saying the case transformations used for small-caps
             are the same that are used for text-transform
   SteveZ: ...
   jdaggett: The reason for that is that if text-transform puts in special
             rules for special casing, we don't want to have to go back
             and modify two specs
   fantasai: I Think you have a good point but the wording is confusing
   jdaggett: I'll rework the wording
   ACTION fantasai: propose less confusing wording
   <trackbot> Created ACTION-465

   jdaggett: only other thing about css3-fonts is that I published today
             revised wording of font-family syntax from the last telecon
   Håkon: formal grammar?
   jdaggett:  Yes.  Deal with inclusion of 'inherit' within font family
              name, e.g., 'font-family: foo inherit' is invalid
   jdaggett: saying you need quotes in that case
   Bert: you said you put in some text
   jdaggett: on the mailing list
   jdaggett: I'm piggybacking on changes I proposed for css3-values,
             issues with case sensitivity.
   Bert: It's a change from CSS 2.1
   jdaggett: Fixing ambiguity, I don't think it's a change.
   Tab: We already resolved on this last week or the week before
   Bert: The resolution I recorded was ...
   Tab: That wasn't the resolution we were trying to get
   Tab: If you want to reopen, please do it on the mailing list
   Bert: we should not change 2.1
   Bert: 2.1 is very clear except for the case where there is a font name
         called inherit, unquoted
   tab: anything else?
   ACTION fantasai: review css3-fonts wording on font-family syntax
   <trackbot> Created ACTION-466

   jdaggett: I'm done.  Just from a spec level I'm trying to go through
             the spec, publish another WD in the next couple weeks.
   jdaggett: Last sticky issue is font matching for clusters (base characters
             with combining diacritics, variation selectors).  Once that's
             ironed out I think will want to consider moving to last call.
   jdaggett: fantasai has some comments about @feature-values to post to
             the mailing list
   jdaggett: past that I'll start asking people to take a look at the spec,
             look for things ambiguous, unclear, could be better explained

Spec Editing Tools

   vhardy: last time I showed a tool to help editors with issue tracking
   vhardy: if you want to use bugzilla to track your issues and make sure
           they're in your spec
   vhardy: a tool for editors, not meant to be published
   vhardy: checks for issue markers and checks bugzilla
   vhardy: Will tell you if you have issues that are resolved that should
           be removed, or new ones that should be mentioned in the spec
   vhardy: I put this in the shared repository under root of spec directory
   Florian: only bugzilla, not tracker?
   vhardy: right
   Bert: way to put this in postprocessor rather than only insert when
         you're online?
   vhardy: you need to insert issues at a particular point in your spec
   Bert: but I put the issue number in the spec
   Bert: because it's not done by the postprocessor I have to make a link
   Bert: I'd like to just put ISSUE -dash- 217 and have the postprocessor
         just make it a link
   vhardy: I don't have access to the postprocessor
   Bert: wondering if this code is readable enough...
   vhardy: I didn't write it... but his code is very legible

   plinss: on this topic, we were talking about test annotation script
   plinss: Tim doesn't allow us to have it on /TR/
   plinss: But he will allow us to add to /TR/ specs a link to an annotated
   plinss: so thinking of putting /TR/ specs mirrored on csswg.org
   plinss: because it makes specs in /TR/ mutable based on something off
           of w3.org servers
   plinss: can do annotations and anything else we want there

Meeting closed.

Received on Tuesday, 15 May 2012 20:51:36 UTC