W3C home > Mailing lists > Public > www-style@w3.org > July 2013

[CSSWG] Minutes Tokyo F2F 2013-06-06 PM I: Fonts Part I

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 02 Jul 2013 17:23:18 -0700
Message-ID: <51D36EF6.2090601@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Fonts
-----

  - RESOLVED: Leave synthesis of italics in vertical text undefined.

  - Discussed positioning of underlines and other text decoration
    across font-derived superscripts and subscripts (i.e. using
    font-variant-position).

  - RESOLVED: Tab's proposal for @font-feature-values OM, i.e.
              http://lists.w3.org/Archives/Public/www-style/2013May/0781.html
              with change from string to numbers

  - Discussed whether @font-feature-values is an at-rule.

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


Fonts Part I
============
Scribe: Bert
Present+ Taro Yamamoto (Adobe)

Synthesized Italics in Vertical Text
------------------------------------
Scribe: Bert

   * glazou invited expert for this item is Taro Yamamoto
   jdaggett: italic in vertical:
   jdaggett: I recommend that Koji come to the mic
   jdaggett: Background is that in Japanese there is no real tradition of italic.
   jdaggett: UAs just oblique synthetically.
   jdaggett: When 'font-style: italic' on vertical text, what should it do?
   jdaggett: If you have a normal italic font, you just use it.
   jdaggett: Should the slant be different in vertical?
   <jdaggett> http://koji.ec/wp-content/uploads/2013/05/italics-vertical2.png
   jdaggett: Example [see URL]
   jdaggett: This is the options.
   jdaggett: figure 2 is normal italics.
   jdaggett: Some in Japan have [lost phone]
   <fantasai> Murakami-san's take: http://lists.w3.org/Archives/Public/www-style/2013May/0405.html

   [example on screen]
   <jdaggett> http://lists.w3.org/Archives/Public/www-archive/2013May/att-0027/synthetic-italics-tategaki.png
   <jdaggett> http://koji.ec/wp-content/uploads/2013/05/italics-vertical2.png
   jdaggett: Koji and Elika propose figure 3
   <dbaron> current fonts spec has #2, Koji and Elika propose #3
   [new image on screen]
   <jdaggett> http://lists.w3.org/Archives/Public/www-archive/2013May/att-0027/synthetic-italics-tategaki.png
   <dbaron> (move jdaggett's last URL to here)
   jdaggett: Mixture of 2 with a real italics font.
   jdaggett: I don't say which is better.
   jdaggett: Slope down to the right in 3
   jdaggett: All kinds of arguments possible about what is better in different
             cases.
   jdaggett: But there is no tradition of italic in Japanese.
   jdaggett: But Koji brought up that there is tradition of obliquing
   <jdaggett> http://lists.w3.org/Archives/Public/www-archive/2013May/att-0032/harrypotter-7-193.png
   [example on screen]
   jdaggett: This is oblique to the left.
   jdaggett: Koji found this.
   jdaggett: There should not be a distinction between real italics and
             synthetic case.
   jdaggett: Bad inconsistency.
   jdaggett: If we want oblique in general then we need better control.
   jdaggett: We are still fighting around the edges.
   jdaggett: Comments? Koji, Taro?

   Koji: Not against your opinion
   koji: I want consistent for sideways characters, that's were most italic
         will be.
   Taro: Why you don't agree?
   Taro: Historically there haven't been any slanted Japanese
   Taro: Limited to display type, headlines etc. One line only.
   Taro: We have Times Roman and it has italic.
   Taro: It is possible to apply automatic transform, slanting.
   Taro: Not in Japanese context.
   Taro: Two notions.
   Taro: There is no [missed]
   Koji: Professionals say there is no italic, but authors still want it.

   jdaggett: Give them the option if they want something like Harry Potter
             example.
   jdaggett: It has down slant on the left.
   jdaggett: Authors cannot do that.
   jdaggett: Putting behavior in general behavior doesn't give authors
             the control.
   Koji: I discussed with authors.
   Koji: They understand.
   Koji: They still prefer synthetic italics.
   Koji: Too many points too discuss.
   Koji: Do them one by one.
   Koji: 1st is synthesize or not?
   Koji: 2nd is which direction.

   jdaggett: Spec now says synthesis happens based on whether there is italic
             or not.
   jdaggett: Whether synthesized italic is good or not is separate matter.
   jdaggett: If we have to have synthesized italic, and we do, then it has
             to be consistent with real italic.
   jdaggett: Not based on horiz or vertical or other factors.
   jdaggett: I don't agree with the way you're quoting me.
   jdaggett: We have font-style in CSS and it allows synthesize.
   jdaggett: We have to continue that.

   Taro: If proper true slanting operations for Japanese is not defined,
   Taro: I have to object allowing synthesizing italics by slanting
   Taro: It will make it easier for user to get accustomed to current
         deteriorated situation.
   Taro: People will continue current and that is not good thing.
   Taro: In Harry Potter case,
   Taro: Where slanting necessary, we should do that,
   Taro: But we have no correct definition yet.
   Taro: Once defined and documented,
   Taro: Yes allow some kind of algorithm,
   Taro: Slanting may be necessary.
   Taro: Without knowing what Japanese slanting should be it is very risky
         to link between existing and cjose slanting operation.
   Taro: Look at Roman and Japanese char
   Taro: Maybe metrics different.
   Taro: You have been accustomed to switching italic and roman.
   Taro: Always assumed that you will find an italic font.
   Taro: That doesn't exist in Japanese world.
   Taro: My recommendation is to do nothing.
   Taro: That is best because there is no italic in Japanese.
   Taro: Doing something is OK, but please define what the shearing operation
         should be,
   Taro: Otherwise people will just be happy with the current status and
         think is is fine.
   Taro: That will not guarantee good graphic and visual effect.

   r12a: Asking for clarification:
   r12a: In Harry Potter is is down to the left,
   r12a: What would happing in horizontal?
   Koji: No, it would be to the right.
   jdaggett: This is a published example.
   jdaggett: Koji and Elika proposed slanting down to the right.
   Koji: I'm proposing the number 3, jdaggett propose 2
   [Harry Potter is 1]
   Koji: Japanese authors want 1 if combined with Latin text, otherwise 3.
   Koji: I asked publishers what they want.
   Koji: After discussion they said 3 works best for now.
   Koji: Until we get more precise control.
   jdaggett: 3 introduces inconsistency when there are real italics.
   koji: Japanese font will not have real italics.
   jdaggett: But Western author mixing text will get 3, that does not look
             right.
   [Confusion over which number 3]
   [Looking at tategaki image]
   jdaggett That will look bad.

   <dbaron> in http://koji.ec/wp-content/uploads/2013/05/italics-vertical2.png ,
            #1 is skewY(-10deg) for Japanese,
            #2 is skewX(-10deg) for Japanese,
            #3 is skewY(+10deg) for Japanese
            (note +- and XY changes)
   <dbaron> in http://lists.w3.org/Archives/Public/www-archive/2013May/att-0027/synthetic-italics-tategaki.png ,
            #1 has skewX(-10deg) for ja and en,
            #2 has skewY(+10deg) for ja and en,
            #3 skewY(+10deg) for ja and skewX(-10deg) for en

   Koji: There is no single way to solve all issues.
   Koji: Not in level 3.
   Koji: Latin upright use case is less important.
   jdaggett: Japanese italic is difficult to find.
   fantasai: The examples are not real italics, they're some different feature.
   fantasai: Fundamental question is direction of shearing.
   fantasai: [drawing on whiteboard]

   liam: q for Koji:
   liam: We often say that during standards and it comes back to bite us.
   liam: "until we have more control"
   liam: We're often stuck with that.
   liam: Don't preclude anything in the future.
   Koji: Yes, with more control authors will be happy.
   Koji: But even now they are happy with 3.
   Taro: Do not agree.
   Taro: Hary Potter example is not italic. It is slanted, yes.
   Taro: I've done slanting myself.
   [fantasai tries to draw. Taro doesn't think the drawing is right]
   Taro: It is necessary to align line direction and angle.
   Taro: Japanese phototypesetting at slanted line.
   Taro: Possible, I know.
   Taro: Sometimes people want that, but it is not italic.

   Rossen: For Microsoft, I'm not an expert in this area.
   Rossen: From talking to Office team:
   Rossen: Feedback was that we had italics in word for 20 years.
   Rossen: Since MS Gothic.
   Rossen: Regardless of how good or bad, there is adoption of it.
   Rossen: People are using italic in vertical.
   Rossen: How many make it to the Web I'm not sure.
   Rossen: If needed I can find examples.
   Rossen: Expected that these document will become HTML.
   jdaggett: How many are using this feature?
   Rossen: I don't have data
   jdaggett: There were certain assumptions made a long time ago.
   jdaggett: The initial Word model was simple.
   jdaggett: Should not look at that backwards compt.
   Koji: Used for 20 years.
   jdaggett: How often?
   Rossen: As often as anybody wants to use italic in vertical.

   Taro: Adobe Indesign since 10 years ignores italic in Japanese script.
   Taro: It seems to be a script property.
   Taro: Adobe's Japanese fonts have italic glyphs for Latin.
   Taro: You can do true italic with Adobe fonts.
   Taro: But not to any Japanese font.
   Taro: Only if glyphs included in the font.
   Taro: Is this really a font property?
   Taro: Western context OK.
   Taro: OK with font property there.
   Taro: You can assume that Times Roman has italic.
   Taro: But no such assumption in Japanese context.
   Koji: So we're back to synthesize or not.

   Koji: Make a special rule for Japanese to not synthesize if font not available?
   r12a: Only Japanese or CJK?
   Taro: Any script that have no italic semantics.
   Koji: In Unicode often difficult to know script.
   Koji: Should not depend on codepoints for scripts.
   Koji: If we can resolve this, than we can decide how to synthesize
         (if we decide to synth).

   fantasai: What do Koreans do?

   jdaggett: Easy way is to use an italic font. But I'm interested in the
             fallback case.
   r12a: Russian also a problem.
   r12a: Shapes in italic very different from roman.
   r12a Slanting won't work.
   <stearns> +1 to less faux italic magic

   dbaron: Spec says *may* synth, isn't it?
   jdaggett: but all UA's do it, so users expect it
   Koji: Yes, spec says that. I want consistency *when* the UA synthesizes.
   glenn: Conditional mandatory spec text
   jdaggett: UAs do that, but users should have way to turn it off.

   glazou: I think we have to resolve and move on
   jdaggett: Strawpoll and move on.
   jdaggett: Let me get the example.
   [Tategaki figure now on screen]
   <jdaggett> proposals:
   [vertical2 now also on screen]
   <jdaggett> 1. synthetic italics follow actual italics (glyphs slanted to
                 the right independent of orientation/vertical/horizontal)
   <jdaggett> 2. synthetic italics in the vertical case are slanted down to
                 the right
   ["LETTERS 123" on the left, "Italics 123" on the right]
   * fantasai wishes we had consistent numbering system
   <dbaron> proposal 1 == tategaki example #1
   <dbaron> proposal 2 == tategaki example #2
   jdaggett: red #1 is prposal 1
   <jdaggett> red #2 is proposal 2
   dean: 1 and 2 talk about Latin text, rotated or upright?
   jdaggett: Proposal is to follow actual italic.
   [scribe confused]
   <glazou> [not only the scribe...]
   dbaron: So apply to all italic text, including Latin and ideographs?
   <Rossen> jdaggett, can we use Koji's example? it is so much easier
   jdaggett: I think we had no disagreement.
   Koji: Your prop is red 1 and sideways 2?
   Koji: My prop is red 2 and sideways 3
   jdaggett: Fine

   jdaggett: Synth italic and real italics are going to be different in
             Koji's propoosal.
   Koji: Depends on which consistency you want.
   Koji: Your picture shows more consistency with upright letters.
   Koji: Mine more against baseline.

   glazou: There are other vertical writing systems, such as Mongolian.
   glazou: Will this apply there?
   jdaggett: Yes, but those systems do not have tradition of italics.
   jdaggett: So less need for authors.
   glazou: I have a set of Mongolian fonts with italics in front of me.
   [People gathering around glazou]
   * Rossen notes that we've supported Mongolian since IE8
   <Rossen> italics was allowed
   r12a: Maybe because it is basically rtl system.

   <dbaron> #1 has skewX(-10deg), #2 has skewY(+10deg)
   Koji: [...] best behavior in CSS and acceptable.
   Koji: If one face is not available...
   * jdovey thinks this problem cannot be addressed with current CSS
            capabilities
   glazou: I want to make sure proposals are fit for other writing systems.
   jdaggett: Only the synthetic case.
   jdaggett: If user uses italic font, he gets it.
   dbaron: We shouldn't hold up LC over a fallback case.
   <jdovey> If anything, make a note on the spec (or a WG Note) describing
            the issue and asking for input to CSS Fonts 4

   fantasai: Mongolian glyphs are currently implemented as sideways,
             so will not break in either proposal.
   fantasai: But if Mongolian were to be defined in terms of upright glyphs,
             as jdaggett wants, than jdaggett's proposal would break the
             connections between characters because you skew across the
             baseline.
   fantasai: Whereas if you use Koji's style, because you skew along the
             baseline, you will not break connections in Mongolian.
   jdaggett: There is no use case for that.
   jdaggett: The examples you brought up. There is no [...] italic context.
   jdaggett: Thin air, no real use case.
   Koji: No, it exists.

   glazou: strawpoll
   Option 1 = red 1
   Option 2 = red 2
   TabL abstain
   koji 2
   ivan: ab
   glazou: abs
   SimonSapin: abs
   Jet red 1
   taro: 1
   Rossen: sen 2
   Alan 1
   Rebecca: abs
   dean 1
   dirk: abs
   rik: abs
   leif: abs
   <dbaron> (dirk and Taro would have voted for the third drawing for the
             whiteboard, which has no synthesis in vertical Japanese)
   Kazutaka: 2
   liam: 1
   justin: 2
   shane: abs
   jim: abs
   bert: abs
   r12a: abs in favor of further evidence, as westerner prefer 1
   plins: abs
   dbaron: abs
   glen: 1
   fantasai: 2, because technical problems not as often
   [6 to 5 in favor of 1]
   <Rossen> 13 abs
   jdaggett: 1
   <dbaron> [7 to 5 in favor of 1]
   [discussion about live with and object...]

   jdaggett: Weak consensus to do something because we do not have a real
             property to allow obliquing.
   jdaggett: Not do this as a substitute for doing something else.
   glazou: So leave it undef?
   jdaggett: No, go with 1, because 2 is really advocating for a new feature.
   Koji: No, then we have to define for Ruby, etc.
   Koji: Those conflict.
   jdaggett: [missed]
   glazou: We have 7 to 5, so option 1 or leave undef.
   jdaggett: Either is fine.
   jdaggett: But not option 2
   [hands up for undefined]
   [Some hands up]
   RESOLVED: Leave undefined.

   <fantasai> My concerns with 1 are that there are cases that break with it,
              even though it is typographically better. Since the correct
              solution is to use an italic font, this fallback case should
              just be the option that works adequately in the most cases.
              And #2 does that: it doesn't create overlapping problems, it
              doesn't break multi-glyph constructs, and it doesn't break
              cursive scripts or fonts.

Text Decoration of Font-based Superscripts/Subscripts
------------------------------------------------------

   jdaggett: Next issue.
   jdaggett: fantasai 's issue on sub/superscript
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2013May/0285.html
   jdaggett: What to do about text decorations in superscript variant glyphs.
   <jdaggett> http://lists.w3.org/Archives/Public/www-archive/2013May/att-0025/superscript-underline.png
   jdaggett Let me explain the example.
   [Looking at e-mail msg]
   [Looking at image]
   jdaggett: Different kinds of sub & super
   jdaggett: Using HTML, font shrink and vertical align
   jdaggett: Second uses Unicode codepoints for super and sub
   jdaggett: 3rd is suing feature in draft.
   jdaggett: What an underline looks like
   jdaggett: 2nd has underline just to super
   <fantasai> 
https://coreldraw.com/cfs-filesystemfile.ashx/__key/CommunityServer.Components.PostAttachments/00.00.17.55.90/workaround.jpg
   jdaggett: Difference in baseline
   jdaggett: Metrics same as surrounding text for Unicode superscript glyphs.
   jdaggett: Font has metrics for synthesis
   jdaggett: This problem exists with Unicode code points already.
   jdaggett: My point is that we don't need to do anything special.
   jdaggett: You get what you get in 2nd example.
   jdaggett: You don't get detailed control.

   fantasai: The one we want is what matches the HTML example.
   fantasai: That's what people want.
   fantasai: Take info from font, and use that to position underline.
   jdaggett: That doesn't match where the glyphs are.
   jdaggett: Cannot have magic.
   jdaggett: Fallback won't work.
   jdaggett: Metrics are different.
   fantasai: But it will match synthesized glyphs.
   jdaggett: No, not close enough.
   fantasai: The bottom examples don't look right at all.
   fantasai: We can get closer.
   jdaggett: Just wrong in a different way.
   jadggett: Adobe's font all have same metrics.
   jdaggett: Alignment will be different than actual glyphs.

   <jdaggett> http://dev.w3.org/csswg/css-fonts/#font-variant-position-prop
   [looking at figure 22]
   jdaggett: Shows difference between real superscript on left and synth
             version in middle.
   jdaggett: Baseline is not the same.
   jdaggett: Will have underline in middle. Not look right.
   jdaggett: We have been trying to come with magic for a year and a half.
   jdaggett: Text decoration same issue coming back all over again.
   jdaggett: We just don't have it, it is not available.

   Leif: Can the font provide metrics?
   fantasai: Yes, they could.
   jdaggett: Not the right answer. The metrics are meant for the synth case.
   jdaggett: Example 22 shows that synth superscript is larger.
   jdaggett: Designer made it so.
   jdaggett: Metrics work with synth.
   jdaggett: Not so well for the designed glyphs.
   jdaggett: Which is what you propose to use them for.
   <fantasai> I still think it's better to use those metrics than to use
              the base size metrics
   jdaggett: Complex content [..]
   jdaggett: It is not meant as complete replacement for HTML mark-up.
   jdaggett: There are limitations, noted in the spec.

   fantasai: I'd like to edit text deco spec to say we use font metrics
             in font.
   glenn: I agree
   jdaggett: What are doing?
   jdagget: The metrics don't match what you want to sue them for.
   glenn: If the font *does* have metrics, they should be used.
   glenn: Agreed?
   jdaggett: The metrics are used for synthesis.
   jdaggett: If you resize,
   jdaggett: The metrics don't match the actual glyphs.
   jdaggett: Sure, if you design a font with metrics, but that is a big "if."
   jdaggett: Not common practice.
   jdaggett: Other comments or questions?

   Leif: Seems fantasai's suggestion works in example 22, but maybe not
         for subscript.
   Leif Maybe not in general.
   fantasai: Metrics of base size is not any better, probably worse.
   Leif: I don't really know how fantasai's suggestion will turn out for
         subscripts.
   Leif: Better result more often than not?

   glenn: If font designed specs a sub or super feature, but without glyphs,
          you suggest we synthesize?
   jdaggett: Spec has wording about that.
   jdaggett: We do include wording for fallback, we will synthesize.
   jdaggett: If user adds elements or images, or sub-spans, then they should
             use the HTML way.
   jdaggett: We pretty much resolved on the feature not being a complete
             replacement for HTML mark-up, and it shouldn't be one.
   * fantasai notes that it's possible to use this feature for all these
              cases if you know what tags you're dealing with
   * fantasai so it would work fine for most HTML

   glenn: Is there consistency among UAs for fallback?
   jdaggett: Nobody implemented it, no comparison to make.
   jdaggett: Gecko has impl behind a flag, but without the fallback behavior.
   glenn: Mark fallback at risk?
   jdaggett: Why?
   glenn: Lack of implem experience.
   jdaggett: No strong case, spec is just not finished yet.
   glenn: No early implementers either.

   glazou: Can the people discussing now find a compromise?
   jdaggett: What do you want me to compromise on?
   jdaggett: There is nothing.
   fantasai: Cannot live with John's option.
   jdaggett: You're proposing magic, not a real proposal.
   plinss: If metrics available, use them, but seems there are none.
   jdaggett: Based on what research?
   plinss: Metrics are for something else, according to jdaggett
   plinss: So if the metrics don't exist, [...]
   fantasai: But if they exists it will be right, and otherwise they will
             be slightly off.
   plinss: Fine with a note in text decoration about if there are metrics.

   fantasai: We have to put the underline somewhere.
   fantasai: Which metrics do you use.
   fantasai: Just because Unicode glyphs have this problem, doesn't mean
             we have to copy the problem.

   liam: Proposal:
   liam: WebFonts WG has liaison with ISO Opentype
   liam: Chair of WG.
   liam: Ask them about a new metric.
   liam: Not invent something ourselves.
   jdaggett: Shors delay, are you joking?
   liam: If we have to wait for a new feature, that would be long. But not
         long to ask the question.
   jdaggett: We have been through this.
   Liam: In that case redraw suggestion.
   plinss: Still useful to talk to Opentype.

   glenn: Truetype has different tables.
   glenn: ... bsln (Truetype) vs BASE (OpenType)
   glenn: Are we too specific to OpenType.
   jdaggett: superscript metrics are in OS2 table
   glenn: Asking because you also mention baseline offsets.
   glenn: Just wondering...
   glenn: You and fantasai get together.

   glazou: strawpoll.
   fantasai: Proposal is for when superscripts or subscripts are decorated,
             use superscript/subscript metrics to position decoration
   fantasai: jdaggett's proposal is that instead, use the metrics of
             full-size glyphs
   plinss: Are you talking about synth *and* non-synth case?
   jdaggett: The text underline follows the surrounding glyphs (for both
             in the synthesized case and the actual glyphs case)
   jdaggett: Yes, behave same way, normal baseline, not shifted.
   TabAtkins: [pointing to figures]
   dbaron: we're talking about what happens with the new feature for using
           font features, not using vertical-align.
   fantasai: That means underline the whole thing as the full size chars,
   fantasai: in the example, jdaggett wants the OpenType version to match
             the Unicode version rather than the HTML version
   [...]
   fantasai: No, people do not underline the degree char, but they do underline
             superscripts.
   TabAtkins: jdaggett 's proposal is the lower half of the current
              projected screen.
   [8 hands for jdaggett proposal]
   [7 for fantasai's proposal]
   [rest abstain]
   jet: Does this hold up LC on fonts?
   fantasai: No, it is an issue for text decoration.
   jet: We should really resolve this, cannot keep on fighting.
   plinss: If is not on fonts, let's leave it open issue on text deco and
           move on with fonts.

   <jdaggett> followup on the subscript/superscript metric discussion,
              here's the example from hamburg:
   <jdaggett> http://people.mozilla.org/~jdaggett/tests/subsupermetrics.png

<br data-duration="900s">

   [glazou and fantasai discuss which issue to treat next]

@font-feature-values
--------------------

   <glazou> OM representation of @font-feature-values rule
   Topic: font feature at-rule in OM
   <jdaggett> http://dev.w3.org/csswg/css-fonts/#om-fontfeaturevalues
   jdaggett: [looking for URL]
   jdaggett: fantasai posted that it should be different, ensued a thread.
   <fantasai> Heres the comment http://lists.w3.org/Archives/Public/www-style/2013May/0580.html
   jdaggett: Tab proposed a subclass of grouping rule.
   jdaggett: And then make each feature block another subclass.
   jdaggett: I'd like to gauge group's opinion.
   jdaggett: Who's is interested in implementing?
   glazou: comments?

   dbaron: Mixed feelings
   dbaron: If it looks like an @rule it should behave like an @rule.
           On other hand an awful lot of pieces to make.
   fantasai: I know Tab has comments, wait for him to come back into the room.
   jdaggett: Let me look for Tab's stuff.
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2013May/0596.html
   jdaggett: Follow on from that is that grouping rule often [missed]
   <jdaggett> example
   <jdaggett> @font-feature-values Bongo {
   <jdaggett>   @swash {
   <jdaggett>     swishy : 1;
   <jdaggett>     wavvy-gravy: 2;
   <jdaggett>   }
   <jdaggett> }
   SimonSapin: Independent of whether descriptors or declarations are involved

   dbaron: Hesitant to reopen discussion, but makes me wonder if there is
           too many levels of nesting.
   <dbaron> @font-feature-values Bongo { @swash swishy 1; @swash wavvy-gravy 2; }
   dbaron: Why in that example, not like this [see above]
   jdaggett: That was original proposal, but we switched to more at-rule-like
             version.
   fantasai: Both are at-rules.

   plinss: Don't see why not a group rule.
   plinss: But don't want to separate i/f classes
   plinss: for each class.
   TabAtkins: I proposed to map them.
   TabAtkins: Should be on m-list.
   TabAtkins: Just expose the at-swatch as properties of feature-values
   TabAtkins: js-maps
   TabAtkins: Or maybe a string
   TabAtkins: they'll merge
   plinss: Makes sense.

   fantasai: Didn't you have a simplifying proposal, that we could expand later?
   jdaggett: My proposal is at-rule with nothing in it.
   TabAtkins: [explains proposal]
   fantasai: could go with that, and than make a css3 font OM extensions spec.
   fantasai: Seems to need more work than the rest of the spec.
   dbaron: We're not ready to conclude that yet.
   jdaggett: font load events is not the approriate place.
   dbaron: What Tab described sounds fine.
   [tab writes on wboard]

   dbaron: TAG is going to review APIs.
   dbaron: Tab's proposal fits what TAG expects.
   <TabAtkins> interface CSSFontFeatureValuesRule {
                 attribute Maplike<DOMString, DOMString> swash; ... }
   <TabAtkins> (Maplike is proposed for WebIDL.)
   <dbaron> Tab's proposal is in
             http://lists.w3.org/Archives/Public/www-style/2013May/0781.html

   glazou: example with Bongo, what would be value text?
   glazou: from @swatch to closing brace.
   glazou: That is painful for editor.

   [two people talking]
   jdaggett: When I asked you in Tucson you said it was no pb.
   <glazou> I said I could live with it, I did not say it is perfect

   jdaggett: Tab, is it writable?
   TabAtkins: Yes
   plinss: values are always potential list of numbers?
   jdaggett: Yes
   plinss: Then lets not make everything a string when it can be a primitive
           in JS.
   plinss: should be a map of string -> number or string -> array of number
   jdaggett: yeah
   tab: no pb
   tab: Any objections to my proposal?
   glazou: I like it better.
   dbaron: Is this ready in next month or so?
   TabAtkins: Cameron is going to add map-like thing.
   TabAtkins Proposed a few weeks ago.

   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2013May/0781.html
   <jdaggett> interface CSSFontFeatureValuesRule {
   <jdaggett>   attribute Arraylike<DOMString> familyList;
                /* An array of family name strings. */
   <jdaggett>   attribute Maplike<DOMString, DOMString> swash;
                /* A map of feature names -> feature values */
   <jdaggett>   attribute Maplike<DOMString, DOMString> styleset; /* Ditto */
   <jdaggett>   attribute Maplike<DOMString, DOMString> ornaments; /* Ditto */
   <jdaggett>   ...
   <jdaggett> }

   ... Cannot be string, ...
   plinss: [missed]
   <glazou> fine by me
   <glazou> better than just one large string
   tab: Yes, could just manually put it all in by hand, but ideally use IDL.
   glazou: Resolve on Tab proposal?
   jdaggett: Is that the one in IRC?
   plinss: without string.
   jdaggett: Others are interested in implementing it?
   dbaron: you, tab?
   TabAtkins: maybe, probably not, working on syntax...
   dbaron: fine with proposal, worried that nobody implements it.

   plinss: what is dbaron's q precisely?
   dbaron: New IDL concept, or add a lot of hand writing JS
   dbaron: Maybe 2 months of work.
   plinss: You have to do that soon anyway.
   jet: we don't write hand-written bindings nowadays.
   TabAtkins: More verbose.
   plinss: WebIDL is on its way up.
   dbaron: I think we can resolve.
   RESOLVED: Tab's proposal for @font-feature-values OM
   <plinss> FWIW: WebIDL replacement:  https://github.com/w3ctag/jsidl
   <jerenkrantz> is the resolved proposal the one from:
                  http://lists.w3.org/Archives/Public/www-style/2013May/0781.html ?
   <stearns> yes, with a change from string to numbers (as far as I understood)

   jdaggett: next issue is
   jdaggett: feature value blocks in spec,
   jdaggett: fantasai says they should just be called at-rules.
   jdaggett: But I think they are different.
   jdaggett: User defined identifiers.
   jdaggett: The way they compound is an issue.
   jdaggett: I think it is important to day this is different form other
             at-rules, with descriptors.
   Tab: That is just about terminology.
   Tab: It starts with an at-keyword, all at-rules are different already.
        So it is just an at-rule.
   <fantasai> http://www.w3.org/TR/CSS21/syndata.html#at-rules
   <fantasai> "At-rules start with an at-keyword, an '@' character followed
               immediately by an identifier (for example, '@import', '@page').
               An at-rule consists of everything up to and including the next
               semicolon (;) or the next block, whichever comes first."
   glenn: Confusing for users to try and distinguish them.
   fantasai: CSS 2 calls it an at-rule when it starts with an at-keyword.
   jdaggett: Yes, parses like an at-rule.
   <fantasai> if it looks like an at-rule, parses like an at-rule, it is an at-rule.
   jdaggett: Should we not call it something else?

   TabAtkins: Within the spec, call it what you want.
   TabAtkins: Whatever makes sense. But technically it is an at-rue.
   fantasai: Must be clear that it parses like one.
   TabAtkins: But "font feaure value block" or whatever is fine.
   TabAtkins: It expresses the concept.
   jdaggett: So I need to say somewhere that at-feature-value blocks are at-rules.

   jdaggett: issue on font load postpone to tomorrow?
   fantasai: Other issue is lang override.
   jdaggett: Tomorrow, too?
   fantasai: sure
   jdaggett: Then that is it for fonts for now.
Received on Wednesday, 3 July 2013 00:23:47 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 3 July 2013 00:23:47 UTC