W3C home > Mailing lists > Public > www-style@w3.org > November 2016

[CSSWG] Minutes Lisbon F2F 2016-09-20 Part II: Variation fonts in OpenType, Motion Path [css3-fonts] [motion]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 15 Nov 2016 21:27:34 -0500
Message-ID: <CADhPm3vmvnhg0uNuQsCx8EX1Krh8eRtKP82ik8qgGDNO6iq7gA@mail.gmail.com>
To: www-style@w3.org
=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


Variation fonts in OpenType
---------------------------

  - behdad showed a demo of variation fonts in OpenType 1.8.
  - There is a desire to map the variation axes to CSS controls.
    To do this, there are three types of mapping that need to be done:
      1) Add an extra value to font selection that would allow the
          point values associated with weight, width, slant
      2) Add axises that aren't associated with font selection
      3) Create the ability to set arbitrary axises
  - These should be able to animate in order to avoid flickering.
  - There were concerns that the APIs for this weren't complete
      enough to add this to Fonts 4 - it could slow down other parts
      of the spec.
      - Suggestions to alleviate this concern were:
          - Move it to WICG
          - Put this into Fonts 5 and add the more unstable parts of
              Font 4 there as well so that the new Fonts 4 moves
              quickly.
      - Lots of people wanted to keep it in the CSSWG instead of
          moving it to WICG.
  - RESOLVED: We will work on font variations.
  - RESOLVED: Font variance is part of Fonts Level 4

Motion Path
-----------

  - A ray() function in offset-path was introduced to cancel the
      <angle> ambiguity.
  - jihye will change offset shorthand to use || instead of &&
  - RESOLVED: Switch the polar-positioning part of offset-path to be
              a ray() function.
  - RESOLVED: Position before path before distance and anchor

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/tpac-2016#agenda

Scribe: TabAtkins

CSS Fonts: OpenType Variations
==============================

Overview of technology
----------------------

  <behdad> astearns: jdaggett:
https://twitter.com/abrax5/status/776708619043762176
  <behdad> jdaggett: plus the other two things I demoed at atypi
  <behdad> jdaggett: full video here:
https://www.youtube.com/watch?v=6kizDePhcFU
  <behdad> Demos start at about 1:11:00
  <jdaggett> github issue for font variations support
  <jdaggett> https://github.com/w3c/csswg-drafts/issues/498
  <jdaggett> John Hudson blog post on variable fonts
  <jdaggett> https://medium.com/@tiro/https-medium-com-tiro-introducing-opentype-variable-fonts-12ba6cd2369#.u93slo7n5

  behdad: Last week at atypi we announced, with Apple, Google,
          Microsoft, Adobe, we announced opentype 1.8, the biggest
          change since it first happened.
  behdad: Biggest addition is variation fonts. I'll show a demo,
          then Myles and John will discuss the implications for CSS.

  behdad: Our current fonts are scalable in size. Variation fonts
          bring that same scaling to other aspects.
  [shows a width variation, then a weight]
  behdad: Look at dollar sign, it changes to a difference design
          based on the weight.
  (applause)
  behdad: Similar demo of Arabic script. The ligature and combining
          marks just work.

  behdad: This isn't new, it's based on Apple tech from the 90s.
          Adobe multiple masters is very similar as well.
  <ChrisL> (Apple TrueType GX)
  behdad: But for the first time it's in OpenType, and extended to
          handle OT layout.
  behdad: Designers have already been designing with interpolation,
          they just export to flat/individual instances. We're
          bringing it to runtime.

  behdad: While we bless the most common interpolation axises,
          the tech supports arbitrary axises as well.
  behdad: Here's a western font with axises that change several
          aspects of the font.
  [behdad shows example of font with circular holes, the extra axis
          changes the holes from round circles to squares]
  [changes the buttons, the joints, the way the serifs look]
  <jdaggett> Example of a family using different axes
  <jdaggett> weight and contrast
  <jdaggett> http://typeproject.com/fonts/tpmincho
  behdad: So in CSS we need to hook up weight, width, and other
          "standard" axises. Then arbitrary axises.
  behdad: And really interesting applications is responsive design.
          Like adjusting the params to fit text into a space.
  (applause)

  <behdad> Side comment I forgot to mention: variation fonts have
           significant size saving for webfonts.

Integration into CSS
--------------------

  myles: Two reasons this is valuable to add to CSS.
  myles: First is you get super-great typography.
  myles: Likely the axises will affect weight and stretch. Currently
         very common for websites to have the same font in multiple
         weights/stretches. Now they can just have one font.

  myles: Current thinking for how to plug this into font selection
         breaks down into three pieces.
  myles: These variations are not OT features - that's something
         different. They interact, but reusing font-feature-settings
         would be a mistake.
  myles: These sliders are called axises.
  myles: The current thinking of how to map these to CSS is to break
         down the sliders into three pieces.

  myles: First is axises that affect font selection - weight, width,
         slant.
  myles: These are important because we already have properties that
         affect font selection.
  myles: So all three of them don't have a concept of floating point
         values.
  myles: So presumably some value would be assigned, so if you say
         "give me a bold font", a variation font could be selected,
         and then made bold.
  myles: So an extra stage in font selection.
  myles: Those three are expected to be the most common axises.

  myles: Set 2 is common axises that don't affect font selection.
  myles: One example is optical sizing.
  myles: No existing properties, we'll likely add new ones with
         associated syntax.

  myles: Set 3 is low-level arbitrary axises.
  myles: Where author can specify whatever name.
  myles: This is important, because in OT, if you make a font you
         can respond to any axis, even if it's not registered in a
         spec.
  myles: So conceptually this is similar to font-feature-settings,
         but this is meant for variations, and will take a
         floating-point rather than an int.
  myles: So that's basic thinking for mapping.

  myles: I've written a draft spec which isn't in the repo yet.
  myles: Rather than merging draft text into Fonts 4, there are a
         fair number of high-level issues to resolve (like how to
         make @font-face respond to this)
  myles: We'd discuss this in github in issue trackers, and when it
         dies down then I'd write some text and start adding it to
         level 4.

  myles: There's one piece I forgot to mention
  myles: With the font selection I mentioned - if you're on an old
         browser that doesn't support variations, and you tell it to
         use this variation font,
  myles: You'll say "apply bold", the browser doesn't know how to,
         so you'll get a normal version.
  myles: So maybe need an addition to the format specifier so an older
         browser doesn't even download them if it doesn't know how
         to use them.
  <ChrisL> https://github.com/w3c/csswg-drafts/issues/498
  <ChrisL> draft spec (fork of css fonts 3, but intended for
           fonts 4)
https://github.com/litherum/csswg-drafts/commits/variationfonts

  glazou: First, congrats.
  glazou: As I understand, this is going to be useful for responsive
          design.
  glazou: One of the thing I'd like to avoid is flickering when the
          font changes at a boundary in your responsive design.
  glazou: One way of doing that is to do transitions on the font
          axises.
  glazou: If you can make that property animatable in CSS, that
          would be really awesome.
  myles: Being able to animate is a stated design goal in this.
  glazou: Good. I wanted to mention because it has deep implications.
  <dbaron> It doesn't seem to me that responsive design would be a
           use case for animation. While people like demoing how
           responsive designs respond to resizing, the point is that
           it is a good design at any particular static size.
  <gsnedders> dbaron: and indeed things frequently get confusing
              when resizing due to movement of content
  <dbaron> certainly may be other use cases, though
  <glazou> dbaron: imagine a emoji font where the smile/grin mouth
           is set by a font axis ; transitioning that would be
           awesome

  Florian: Also this is great.
  Florian: I wanted to clarify - how would font selection work?
  Florian: Would you be able to declare a range of weights to use
           this font, like 100-600, but for 800 use this
           old-fashioned one?
  myles: There are at least 2 models for how this would work.
  myles: Many different parties with different ideas.
  myles: Web authors that are font designers, and like TypeKit
         serving fonts.
  myles: We have not reached consensus, in short.

  Vlad: Variation fonts would likely have named instances.
  Vlad: In the scale, there will be certain points in the axis with
        a name assigned. You say "bold", the browser may not know
        the variation scale, but there will be a value known as
        "bold".
  Vlad: But I'm not sure there's a mechanism to query a font for
        that.
  myles: Axis discovery is related but somewhat distinct.
  myles: Font features are similar. And there's no mechanism for
         discovering those features.
  myles: It might be possible to go down that road. I'd like to
         consider them as related but separate topics.
  Vlad: I think variation is a little bit trickier.
  behdad: The CSS shorthand routes into the font, and there is
          @font-face for the name instances, same as for
          @font-feature-settings.
  <eae> I think he meant the font provider's CSS generator
        generating @font-face rules rather than the CSS shorthand
        parser.

  Vlad: Question: related to responsive typography.
  Vlad: You have a font with width variation, and idea is that when
        you resize the window or column, you apply a smooth width
        variation.
  Vlad: Reflows can be very objectionable when text jumps.
  Vlad: But what I didn't see in the spec is the mechanism that
        connects window information back to font variations.

  ChrisL: I'd like to reiterate that animations/transition will be
          great for this.
  ChrisL: One thing not mentioned yet is that system fonts will have
          variations.
  ChrisL: So you'll set a fallback font and set its width/weight/
          etc, so less of a "jump" when your downloaded font loads
          in.
  astearns: Doesn't that depend on the system fonts being quite
            similar?
  ChrisL: Right, it's the same problem as having Arial vs Helvetica.
  astearns: Right, wondering if we need a way of setting up system
            fonts *per system*, so it's known to match.
  myles: There's a GH issue for that.
  ChrisL: There's a detailed proposal in the GH for that.
  <eae> myles: do you have a link to that issue handy?
  <myles> eae: let me see
  <jdaggett> https://github.com/w3c/csswg-drafts/issues/498
  <myles> eae: https://github.com/w3c/csswg-drafts/issues/126
  <eae> myles: thanks!
  ChrisL: This is just gonna change things so much.
  ChrisL: Instead of downloading 4 fonts and wishing there were more
          weights, you just do one and get 7 weights, etc.

Process & Schedule Considerations
---------------------------------

  ChrisL: What we really want is to get approval from the group to
          move into Fonts 4.
  astearns: Proposed resolution is to take what's written and move
            into CSS4 Fonts.
  dbaron: Are there other substantial features in Fonts 4?
  fantasai: Yes.
  dbaron: How likely is this to progress relative to those?
  ChrisL: Similar. Chromatic fonts there right now. Gonna run on
          similar timescale.
  fantasai: Small set of simple features that have been added, then
            palette colors and whatnot.
  astearns: And when we find that things progress slower, we'll move
            them around.

  jdaggett: I think the underlying tech here hasn't been implemented
            on platforms yet.
  jdaggett: I think it's complex enough that issues will come up in
            the spec itself. Relative to other Fonts 4 features,
            this...
  ChrisL: I agree it hasn't quite shipped, but at the announcement
          last week there were OS companies and font foundries
          saying they were adding it. Adobe added a rasterizer to
          FreeType.
  ChrisL: Much more ready than one would expect.
  behdad: OS 10.12 shipped San Francisco as a variation font.
  astearns: Things will shift, but do you think we should keep it
            out of Fonts 4?
  jdaggett: My concern is that the APIs for supporting them haven't
            been laid out completely.
  jdaggett: I think there are issues of how impls will be able to
            support this.
  jdaggett: I think it's fine for Fonts 4, but there could be, it
            could take longer than other features.
  ChrisL: We have things where we want to freeze a particular spec
          where a delta is hard to read, and this is effectively
          that.
  ChrisL: Like, Fonts 3 needs to have been shipped yesterday.
  ChrisL: Only definition of @font-face, and way past due.
  astearns: I don't think it slows down Fonts 4?
  ChrisL: But then you need to track changes.
  myles: I'm willing to do that.

scribe: fantasai
  TabAtkins: Given this is a brand new feature under heavy changes,
             this seems like a great thing to work out in the WICG.
  TabAtkins: Prefer to move new ideas into WICG instead of putting
             them into a spec with their features
  TabAtkins: Want to talk it out on a lower-volume list.
  astearns: Lower volume list, but also a different list that needs
            for people to subscribe to it.
  ChrisL: What's the benefit here? We have the font people here, and
          CSS people here.
  TabAtkins: Didn't want to mix up this feature with unrelated
             features like font palettes.
  TabAtkins: The point here is to have smaller groups that are more
             focused.
  leaverou: If everyone in the CSSWG joins WICG group, how is that
            smaller?
  TabAtkins: Not everybody would join.
  Rossen: WICG is a separate topic.
  Rossen: Discussion is on Fonts 4.
  <jdaggett> I think this feature will affect some fairly
             fundamental CSS features
  <jdaggett> font properties and @font-face rule
  <ChrisL> I mentioned the size savings earlier

  Bert: I think good idea to put this into the draft.
  Bert: But should make the draft official draft for the WG.
  fantasai: I thought we had an outstanding resolution to publish?

  Vlad: I'm not concerned about people in this room, concerned about
        people who are not in this room but are subscribed to the
        list.
  <jdaggett> list? www-style?
  Vlad: I would be concerned that people would not be following.
  Vlad: Concerned about independent font designers, who have a lot
        of work on their main job to do.
  <jdaggett> agree with vlad
  Vlad: We have a lot of good participation on www-style from John
        Hudson, etc.
  <jdaggett> how to include type designers is critical
  <ChrisL> agree with vlad too
  astearns: We would notify the list, obviously.

  fantasai: In regards to whether Fonts 4 or WICG, something we can
            do for shorter-term features is just... rename the
            current draft to Fonts 5, merge in the small features to
            the current Fonts 3, make that Fonts 4.
  fantasai: Then we can just take like min-font-size, and system-ui
            font. They can go to CR as soon as editing is done.

  ChrisL: I feel that one of the benefits of having WOFF going, is
          having type experts like John Hudson contribute to this.
  ChrisL: I don't want to dilute things by moving off to another
          group.
  TabAtkins: If they want to follow all of CSS--fonts plus
             non-fonts-- then they should be okay to follow fonts
             plus non-fonts in split groups.
  astearns: It's not a new module. It's just adding stuff to a
            module we already have, and it's pretty well integrated
            with the text we have in Fonts L3.

  astearns: So keeping it in our module system seems easier for the
            editors.
  astearns: And everyone working on it has expressed an interest in
            keeping it in github.
  astearns: Tab, you're free to object, but in this case I think we
            should keep it in house.
  astearns: As a different argument, we were talking about koji's
            proposal for step-sizing, and taking that to incubation.
  astearns: I think it would be appropriate there.
  astearns: I would like to decide now to keep it in the group, will
            you object?
  TabAtkins: I object.

  ChrisL: Then we have to recharter.
  ChrisL: The charter says, that for each new deliverable we have to
          have consensus to add it. If there is a sustained
          objection, we're required to recharter.
  TabAtkins: I'm not saying it doesn't go into fonts, I'm saying it
             goes to WICG first, and then we put it into fonts.
  TabAtkins: I'm not objecting to a new deliverable.

  Florian: Current practice of the WG hasn't been to use the WICG.
  Florian: If we want to...
  Florian: If we want to do this, we should have a discussion about
           this topic, not about Fonts specifically.
  <leaverou> +100 to Florian
  Florian: Until we have that discussion, then we should follow the
           usual process that we have in this group.
  Florian: If we need to pause everything and have that discussion
           now, fine.
  <tantek> I'm going to point to this related proposed break out
           session for tomorrow:
https://www.w3.org/wiki/TPAC2016/SessionIdeas#Incubation_as_the_New_Normal
  TabAtkins: I don't think we should take up time during the F2F for
             this discussion.

  astearns: We have no more time to this. We had a proposal. We had
            an objection. We are going to do nothing.
  myles: Nobody likes this. Nobody in the whole world thinks this is
         a good idea.
  leaverou: So Google is stalling progress until we change the
            process to be the way Google wants.
  Florian: And moving to a process where consensus doesn't apply.
  Vlad: So we have a procedural objection, but no substantive
        objection.

  RESOLVED: We will work on font variations.

  <dbaron> I believe Vlad (or someone else) also said something like
           "there's consensus to work on it, but not consensus on
           where to work on it"

Font Variations Revisited (Excerpted from Afternoon Session)
------------------------------------------------------------

  Rossen: Wanted to revisit the font variations discussion
  Rossen: My proposal is to continue this work in Fonts Level 4. Any
          objections?
  Rossen: I really don't want this to be the precedent for the chair
          override feature...
  hober: I support this proposal.
  * fantasai too
  TabAtkins: I'll tell you later, for now proceed

  RESOLVED: Font variance is part of Fonts Level 4

Motion Path
===========
  scribe: TabAtkins

Offset Shorthand
----------------

  <ericwilligers> https://drafts.fxtf.org/motion-1/
  jihye: [missed some intro]
  jihye: There are two new properties - offset-position and
         offset-anchor.
  jihye: offset-position defines where the path starts in the
         container.
  jihye: offset-anchor defines where on the element starts on the
         path.
  <astearns> (shane draws)
  <shane> https://usercontent.irccloud-cdn.com/file/NnZEDgV4/IMG_20160920_114516.jpg
  jihye: There's a problem when we put these into the shorthand.
  <jihye> https://drafts.fxtf.org/motion-1/#offset-shorthand
  jihye: The shorthand is now ambiguous.
  jihye: Both offset-rotation and offset-path have an <angle>, and
         offset-position and offset-anchor have <position>.
  jihye: So they're ambiguous.
  jihye: Shane proposed to use a ray() function in offset-path.
  TabAtkins: ray(<angle> && <size>? && contain? )
  jihye: With this, it cancels the <angle> ambiguity.

  ACTION jihye change offset shorthand to use || instead of &&
  <trackbot> Created ACTION-793

  RESOLVED: Switch the polar-positioning part of offset-path to be a
            ray() function.

  <dbaron> offset-distance also has conflicts with the position
           values, no?

<position> ambiguity
--------------------

  jihye: Next is <position> ambiguity.
  jihye: One solution is getting rid of offset-position/anchor in
         the shorthand (it resets, but can't be set).
  jihye: Another is use to slashes to separate.
  TabAtkins: 1st option is drop -position and -anchor from
             shorthand, so get reset but can't get set.
  TabAtkins: Other option is to use slashes.

  fantasai: There's another issue - the offset property should be
            resetting top/left/bottom/right.
  TabAtkins: This is a name collisions, they're not actually
             interacting.
  shane: offset-path feeds into Transforms.
  fantasai: Okay, we might need to rethink the naming of one or both.
  shane: We had shipped when it was named motion-path.
  <dbaron> https://drafts.csswg.org/css-logical-props/#propdef-offset-block-start
           is a bit of a naming collision
  shane: We just put thru a rename, as early as we thought we could.
  shane: We'd be increasingly concerned about changes to the names.
  TabAtkins: While the logical t/r/b/l isn't implemented by anyone.
  TabAtkins: I'm in favor of just taking out of the shorthand; most
             of the time defaults work just fine.

  shane: I got some impl feedback from Eric Willigers, Chrome
         implementor.
  shane: He did some demos. He said most of them, he has to
         manipulate top/left (because we don't have offset-position
         implemented yet).
  shane: So that suggests offset-position is frequently used.
  shane: And it suggests the ordering - offset-position first, then
         offset-anchor?
  TabAtkins: Makes sense to me.
  astearns: If we're introducing a slash for position, might as well
            do it for anchor.
  TabAtkins: Oh yeah, once we've paid the cost, we should go all the
             way.
  astearns: Any objections?

  <tantek> is there a GH issue on this? with history?
  <tantek> I'm having trouble following :/
  <tantek> I'd like to see a proposal in a GH issue if possible
  <ericwilligers> https://github.com/w3c/fxtf-drafts/issues/24
  <tantek> thanks ericwilligers
  <shane> tantek: also https://github.com/w3c/fxtf-drafts/issues/42
  * tantek reads GH threads
  <tantek> I'm a little concerned about a mixture of spaces and '/'s
           for separation
  <tantek> sounds confusing, like the 'font' shorthand (which I
           still can't remember reliably enough to use :p)
  <TabAtkins> tantek, this is most similar to the border-image
              shorthand. But yeah, font and transition/animation all
              use it too.
  <tantek> thanks TabAtkins. Commented on
https://github.com/w3c/fxtf-drafts/issues/24

  dbaron: This is getting to be a complicated microsyntax.
  <TabAtkins> offset: <offset-path> || <offset-rotation> ||
              <offset-distance> [ / <offset-position> [ /
              <offset-anchor> ]? ]?
  <TabAtkins> offset: [ <offset-path> || <offset-rotation> ||
              <offset-distance> ] [ / <offset-position> [ /
              <offset-anchor> ]? ]?
  fantasai: What if you just want to do an offset-position?
  TabAtkins: That's the same as just doing a translate.
  fantasai: Hmm, that doesn't match my recollection.
  <jihye> https://drafts.csswg.org/css-fonts-3/#propdef-font

  <dbaron> shans, you haven't shipped the shorthand, have you?
  <dbaron> I'm not convinced the syntax that Tab wrote above is even
           unambiguous
  <dbaron> since offset-path has bits that conflict with the other
           two (or at least one of them)

  fantasai: From what I recall discussing, if everything else was
            set to its initial value, offset-position would be
            setting the absolute position of the box with respect to
            the containing block.
  fantasai: This makes it a useful positioning system, independent
            of the other values
  fantasai: And so the shorthand should be able to accept only a
            position, to allow for it to be used as such.
  TabAtkins: You can't just use translate for that?
  fantasai: Translate can't reference the size and position of the
            containing block.
  fantasai: It's not the same thing at all.
  fantasai: We integrated a proposal that could do many things.
  fantasai: We were expecting to use certain parts together.
  fantasai: It would be less common that using just path, etc.
  fantasai: So what we need for the shorthand is look at what people
            actually want to specify, and make those easy.
  fantasai: So setting just position looks common.
  fantasai: And setting a path with distance + rotation.
  shane: That will usually require a position, too.
  shane: If the path is an SVG path, you can get similar effect by
         using a M command. But the other path types can't do that.
  shane: And using the keywords for positioning, you can't be
         relative to the containing block.
  <jihye> https://drafts.fxtf.org/motion-1/#propdef-offset-path
  <jihye> offset-path changes to => <url> | ray(<angle> <size>?
          && contain?) | [ <basic-shape> | <path()> ] ||
          <geometry-box> | none
  fantasai: So we can use positioning information rather than
            slashes everywhere.
  fantasai: So like start with offset-position first. Then path/
            rotation. Then distance.
  fantasai: Then after you can have the anchor.
  shane: You still have anchor, so we can leave it out or use a
         slash.
  fantasai: I guess you'd put a slash before anchor.

  shane: jihye could speak to common polar positioning uses.
  fantasai: location, direction, distance along the ray.
  shane: jihye, how common is it to set anchor in polar positioning
         cases?
  jihye: I think center is the common thing.
  jihye: Default value for anchor is "auto". When I described some
         use-cases, I found center is more useful than "auto".
  fantasai: We made it auto so the position would function the same
            way as for backgrounds.
  jihye: That's useful when path is specified with angle; but when
         you're using the other value types, like circle(), you have
         to adjust every element which is on the circle path.

  <dbaron> incorrectly thought that ray() discussion was about
           changing something just for the shorthand, rather than
           for the offset-path longhand-
  <dbaron> Am I understanding correctly that 'offset-position: auto'
           is like relative positioning and 'offset-position:
           <position>' is like absolute positioning?
  <fantasai> yes, exactly dbaron
  <dbaron> I think that section of the spec could be a bit clearer,
           then.
  <dbaron> I still don't understand what offset-anchor: auto
           combined with offset-position: auto does

  astearns: So this sounds like we do still need anchor with a slash.
  astearns: So it sounds like we can put position first, use ray(),
            then the rest, then / with anchor.
  TabAtkins: I might say leave anchor out entirely - it's like
             transform-origin, and that's a separate property.
  fantasai: Yes, but it seems that switching between auto and center
            would be reasonably common.
  TabAtkins: That suggests that "auto" can just do the
             background-position thing when path is "none", and
             otherwise be center. Then you rarely need to touch it
             at all.
  shane: Almost all examples use offset-anchor:center. It's by far
         the most common thing to do when you position on a path,
         sounds most common when it's polar as well.
  shane: It's okay to make this work okay for positioning as well,
         but all the rest requires center as the default anchor.
  fantasai: So "center" as the initial value? That's fine.
  fantasai: I think switching it when path is none vs other is
            confusing.
  fantasai: We can do something like have it default to
            background-like when you don't have a path in the
            shorthand, center otherwise. But not base it on the
            actual value of path.
  TabAtkins: I think we generally dislike magic in the shorthands;
             we've used it before, but usually want to handle it at
             the value level.
  astearns: Running out of time. Let's fix up resolutions.

  TabAtkins: <offset-position>? [ <offset-path> [ <offset-rotation>
             || <offset-distance> ] [ / <offset-anchor> ]? ]

  RESOLVED: Position before path before distance and anchor

  <dbaron> I filed https://github.com/w3c/fxtf-drafts/issues/45 and
           https://github.com/w3c/fxtf-drafts/issues/46 on my issues.
Received on Wednesday, 16 November 2016 02:28:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 16 November 2016 02:28:39 UTC