- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 02 Jul 2013 17:23:18 -0700
- 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