- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 17 May 2018 03:33:26 -0400
- 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.
=========================================
Fonts
-----
- RESOLVED: Parse the value of src throwing out invalid parts like
media queries and not like selectors. aka You split on
the commas and throw out the pieces you don't understand
not the whole thing. (Issue #633)
- RESOLVED: Use this: format(<string> [supports <feature-name>#]?)
where <feature-name> is a CSS-defined identifier.
(Issue #633)
- An issue will be opened to determine if @supports for color fonts
is necessary.
- RESOLVED: Add an auto keyword to the appropriate font descriptors
that has the effect of the following: 1) for font
selection purposes the font is selected as if the
appropriate initial value is chosen. 2) for variation
axis clamping, clamping does not occur. (Issue #2485)
- RESOLVED: Leave font-style computed values as-is; change
font-style animation behavior so that 'normal' can
animate with 'oblique <num>' (Issue #2505)
- RESOLVED: Use 14 degrees as the angle for undefined oblique.
(Issue #2295)
- RESOLVED: Defer font-variant descriptor to L4. (Issue #2531)
CSS Text / Text Decoration
--------------------------
- RESOLVED: Use from-font [for text decoration metrics] (Issue #2376)
- RESOLVED: Add this value [text-spacing:space-first], suggest it's
the default in epubs and add a open issue wondering if
should be in the web in general. (Issue #2462)
- There was general consensus that the property for paragraph-level
line breaking should be a modifier on wrap not a separate
keyword, but the name still needs to be bikesheded. (Issue #672)
Ruby
----
- Florian gave a brief introduction to the document of Ruby
recommendations from Kobayashi-sensei. The document is available
here: https://florian.rivoal.net/ruby/ and would be a good guide
to Ruby editors.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/berlin-2018#schedule
Scribe: dael
Fonts
=====
Fonts L4 super-format()
-----------------------
github: https://github.com/w3c/csswg-drafts/issues/633
myles: There has been much movement in typography industry in the
last several years. There are many features fonts can opt
into now. One of the tenets of this new world where fonts
can have technology inside is browsers that don't support a
technology should not trigger downloading a font with that
inside.
myles: In @font-face rules in the past this was done with the
format() function in the src descriptor.
myles: Inside the format() function it accepts a string. Now that we
have 3 optional technology we probably shouldn't generate a
bunch of strings with tokens. There should be a way for an
@font-face to associate a URL with a set of requirements
where only if browser fits requirements they should use this.
myles: That's the issue. We don't have an opinion as to which
proposal to do this should be picked. There's one we seem to
be zeroing in on in the issue
ChrisL: We have the format specifier and we don't want the
combinatorial thing where we add more things and it
explodes. So we expand the format specifier to that it has a
string of what it requires. So existing browser can reject
that font. That seems to be where the thread is ending.
myles: Proposal is do we extend format to extend this.
<ChrisL> so for example `format("opentype", requires variations,
requires color)`
Vlad: Hypothetical. Open type font that supports regular + color
glyphs + variations. If you can't use color the font provides
you the downgrade.
myles: Yes. All of these technologies are created such that they are
opt in and the browser can still use the font file. That's
great for backwards compat but these new tech can add
significant space in the font file.
myles: In the case of color glyphs it's a lot. It would be great if
browsers didn't have to download more data then needed.
florian: Is this also avoid the case of a browser choosing to
download a variable font when they don't support that
instead of downloading other fonts.
astearns: I thought that was correct. Browsers that don't support
variable fonts will not download a font with that tag.
Doesn't matter if the font in the declaration supports
variables, but it's a tag for only if the browser supports
variables.
florian: So fold variable into the rest.
myles: yes.
fremy: We shipped variables and color fonts so if we add this our
existing impl will not recognize the new required flags
because it doesn't think we know the font. Would have better
to think of this before.
ChrisL: That is why the thread started in 2016.
myles: We've got the same problem.
myles: There is a proposal. Is there feedback on it?
fantasai: Which proposal?
ChrisL: It's in IRC.
ChrisL: So for that example: `format("opentype", requires
variations, requires color)` you have to support both.
fantasai: ameliaBR suggested using the names of the tables of the
font
myles: One feature can have many tables so you need one
representative table
fantasai: We do that for @supports already: you have to pick a
representative value when checking support for a property.
ChrisL: For variable fonts there's one table for every table that
exists so you have to list a ton
fantasai: You use one as a proxy for the rest. You use @supports
(display:grid) and assume the rest of L1 is supported.
jpamental: Font tables aren't something that users commonly know.
jpamental: I think the concern would be that people who know about
font format technology might know the tables exist but
most font users don't. If we're going to pick a table we
might as well pick a keyword as the thing which is more
understandable to users of fonts.
ChrisL: Think so, yes.
myles: There are 4 popular color font formats and they're all
competing. Some browsers support some. Edge does all. It
kinda matters.
myles: That's a situation where the table matters. Variations is
different. I think keywords is a good pick so you can say I
support variations.
eae: You don't want to download the font 4 times that has the same
variation.
ChrisL: It's all openType.
fantasai: There's a few situations where you need more then does it
support.
Vlad: Can you describe an example where this functionality is needed?
myles: I don't want to download font files....
Vlad: You're a user and you want color glyphs or nothing at all. Is
that the case?
astearns: Author intent is I want to display color glyphs in this
font if I'm in a browser that supports it. If I'm in a
browser that doesn't support it I want to download only
the smaller font so I get it faster.
ChrisL: These are subsetted fonts. You've got one that does svg, one
that does spix.
myles: It's up the the author but yes.
Rick: Same thing happens with variable fonts. I could have a bold
weight and a light weight and I want to sort them out.
astearns: I prefer the keywords. Since there are 4 color font
flavors do we need four keywords
many: yes.
myles: And there will be variations and features
TabAtkins: If a color wins we'll add 'color' as an alias to it.
fantasai: You might want references to open type tables for the
future. Let's say there's an open type table where support
is necessary to use this crazy script.
fantasai: We can have keywords for the most common things, but might
also want to support the more specific cases.
<TabAtkins> `requires variations, requires table "YOLO"
<TabAtkins> `requires variations, requires table "YOLO"
<astearns> `supports`: keyword | "XXXX"
<TabAtkins> `requires variations, requires table "YOLO"`
astearns: You mean ^?
astearns: Arbitrary 4 letter strings which you can put for supports
and you check if browser does anything?
myles: We can have a feature keyed off a specific table but we
shouldn't have that many variations. We can have both.
ChrisL: Should use it for open type features?
fantasai: Interesting point.
astearns: Since this issue has been open for years can we do
keywords for now and extend later as we find use cases?
Particularly if there's a language thing with shaping
tables where if a table to load a font in some browsers is
the useful thing.
fantasai: One of the reasons you don't want to defer is if you add
it later the browsers will throw out the entire
declaration. So you either define a subset and say we may
extend in the future.
ChrisL: It's important to not throw out the whole declaration.
fremy: Can't we use string and say we split by slash?
myles: A micro syntax? It's not good for OMs.
ChrisL: You said it was backwards compat if you use slash?
myles: Browsers would look at the format string and parse.
fantasai: Micro syntax is more complicated if we extend.
fremy: If we do this it still works in previous browsers. They'll
still parse it. If we require something we'll remove all the
fonts in src because if you do something inside the string we
don't know.
TabAtkins: Download source twice. Source for simplest and second for
requires.
fantasai: Shouldn't we use "supports" insead of "requires" to be
consistent with @supports?
myles: browser-support font-files
fremy: Can't you check if the browser supports font variants?
myles: It doesn't work for color fonts because the css support for
palettes is across types of formats
TabAtkins: Should we be careful with how we define to add more
features. If we say it supports custom ident.
myles: Syntax isn't a | b | c it's just custom ident?
TabAtkins: We'll say these are defined custom idents and if you see
one you don't know you don't support it.
fantasai: I think more general and the values are comma separater
but if you don't understand any part of it it throws that
part out. It's a change to parsing that opens the whole
realm of possibilities in the future.
TabAtkins: Yeah. Only possible backwards compat is if people add
nonsense in their source and expect it not to download
this will just throw away the nonsense.
astearns: Does that exist?
TabAtkins: No.
fantasai: I'd say we resolve on that.
fantasai: Prop: Parsing values of the src descriptor, the entire
declaration is not thrown out if any comma separated
section is invalid
myles: Parsing is chop it into commas, run parse on each piece, and
if that piece doesn't parse throw it out.
fantasai: Still have to match brackets and stuff.
fantasai: Parse like MQ not like selectors.
TabAtkins: The grammar would have to be like custom properties,
that's less good.
astearns: Objections to not throwing out a source descriptor if a
comma separated piece does not parse
fremy: Inside a function we can extend, right?
fantasai: This is broader.
TabAtkins: So I'll need to put together some prose to handle that in
the grammar.
RESOLVED: Parse the value of src throwing out invalid parts like
media queries and not like selectors. aka You split on the
commas and throw out the pieces you don't understand not
the whole thing.
<fantasai> Like Media Queries, not like Selectors
<TabAtkins> (unfortunately) not like Selectors
<astearns> (fortunately) not like (unfortunate) Selectors
fantasai: Now people can impl that while we figure out the rest.
myles: Now we have that we don't need the string thing. We can just
use keywords.
fantasai: That's a different problem. If you just have keywords that
are predefined, then you can only query predefined things.
myles: got it
<myles> format("opentype", [requires custom-ident]#)
myles: Proposal #2 is ^
<myles> format(DOMString, [requires custom-ident]#)
<fantasai> format(<string>, [requires <custom-ident>#)
<ChrisL> almost
myles: You missed the square bracket
<fantasai> format(<string>, [requires <custom-ident>]#)
astearns: Extending source descriptor to a comma separated list
requires custom ident
TabAtkins: not requires
ChrisL: When I type that out I'll have commas?
myles: Yes.
TabAtkins: No requires is no commas.
TabAtkins: With the resolution we don't need the custom-ident
business.
ChrisL: So I can put inherit and stuff in there?
myles: It's all inside the one format string...I guess that's okay.
TabAtkins: With the resolution if we mint a brand new requires
keyword tomorrow and someone uses it for browsers that
don't know it that chunk of the source will be thrown out.
astearns: If you put in "requires color-something"...oh!
myles: It goes on to the next source.
astearns: You break up things between commas which reduces to the
things you know.
<ChrisL> so there is an implicit AND, on the requires
TabAtkins: Source splits on commas and only checks individual pieces
astearns: Got it.
myles: I think we're okay.
fantasai: Do you need requires word?
astearns: I like an indication of what this is about. I liked
supports better.
TabAtkins: Open type is written as a string. We can't restrict it
because it's an external source. That's why tables as a
string. If we define it, it's an ident.
myles: Authors won't understand.
myles: I think I'm with astearns that having a keyword would be
helpful.
fantasai: Put with many things you have to write it many times.
astearns: Ties in the supports.
fantasai: Prefer if you don't have to repeat it.
myles: Can you write the grammar so that we don't have to repeat?
<fantasai> format(<string> supports <custom-ident>#)
fantasai: There ^
myles: Looks like supports is required, though.
<fantasai> format(<string> [supports <custom-ident>#]?)
fantasai: there ^
myles: And a comma.
fantasai: Getting rid of the comma.
TabAtkins: If we're removing supports no commas.
myles: Okay.
[everyone argues about commas]
<astearns> (which is a recurring theme)
ChrisL: The longest github thread ever was about using commas in the
color function.
[This is only because we recently switched to github, though;
much longer threads exist on www-style.]
<myles> astearns: proposal: format(<string> [supports
<custom-ident>#]?)
astearns: We have a proposed syntax. Anything more to change/fix or
shall we resolve?
<TabAtkins> (It's not gonna be <custom-ident> now.)
TabAtkins: Custom-ident can be a normal grammar thing.
ChrisL: So we give an explicit list and if we extend in the future
that's fine.
fantasai: Yes.
astearns: Objections to format(<string> [supports (list from
spec)#]?)
RESOLVED: Use this: format(<string> [supports (list from spec)#]?)
<fantasai> format(<string> [supports <feature-name>#]?)
<fantasai> where <feature-name> is a keyword
<Joel> Btw we think a @supports for color fonts will be needed,
especially at the beginning. ie: If you want to use a color
font only if it's supported and style it differently.
<astearns> Joel: that's what we just resolved on
<Joel> Great!
astearns: Someone on irc mentioned @support for color fonts will be
needed. Do we have an @support?
myles: No. I think that should be an issue and we should discuss it.
<astearns> Joel: sorry, I was wrong. we'll still need to figure it
out
<Joel> Ok :)
<astearns> we'll file an issue
fantasai: For @supports you can re-use the same function as is here.
myles: We should do use case research
<Joel> myles: About opening the issue for @supports, should I create
it on https://github.com/w3c/csswg-drafts? (I'm not familiar
with this repo and guidelines though)
<astearns> Joel yes, and please put [css-fonts] in the title
font property descriptors for variable fonts
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2485
dbaron: The way @font-face works is what you're doing is you're
adding a font face to library of fonts browser can consider.
Has descriptors, one is src, and the rest describe the
thing at the end of the src. Many cases they have default
values. Better to spec a font-family. If you don't do either
it's 400, style defaults to normal etc.
dbaron: Useful because means the UA can decide if to download based
on these things. Then we introduced variable fonts which
have maybe more then one font-weight. The interesting part
is that they can have variation axes that correspond to
these descriptors.
dbaron: Spec says you're defining variable font with @font-face rule
and you don't spec a weight your font is only used for 400
according to the spec.
florian: Other fonts for other weights?
dbaron: I don't want to get into that part.
dbaron: You can write 4 @font-face rule and now your variation font
is limited to 4 weights.
myles: Context: key problematic pieces is descriptors are defined to
take on initial value. You covered that. Other pieces is that
whatever is inside those descriptors clamps the effective
range and in the initial value says you clamp to a range of
size 0 which is not what you want.
<ChrisL> @font-face {
font-family: MyVariableFont;
src: url(fonts/MyVar.ttf);
font-weight: 65 490;
}
myles: When I impl this in webkit I discovered this is a problem
because if it was selected and doesn't have a descriptor
you're forced to default value. I impl that if there's no
descriptor the clamping would not occur.
myles: Spec doesn't say to do that and we're the only browser that
does.
dbaron: FF doesn't ship, would like to soon, and recognizes this
isn't good. But from Jonathan's understanding of webkit is
that it makes it hard to figure out what to download. His
impression is it interferes with the decision on what to
download.
ChrisL: In Fonts 4 this is changed and you can give a range. But we
don't want to force 1-999 because there's a weight axis.
That's why I proposed an auto value which gives you range
for variable and single for traditional.
myles: If the goal is I have multiple fonts and want to download the
right one, they're distinguished between by descriptors. If
they both have the descriptors then they'll know it as the
right font. So I think the problem you described isn't.
dbaron: Are there cases where font-fallback says this weight isn't
close enough I'll fallback?
TabAtkins: No. You might synthesize off of it but you'll stay. If
you have the bold variation use that first regardless of
the weight it was declared for.
myles: Distinction webkit drawn between not present and taking
initial is only relevant for when there's 1 rule that shares
a family. If there's 2 rules the descriptors will be there.
TabAtkins: You put 2 font faces to construct a family. One is weight
400, the other 700. You tell it to use 500 and it'll
select 400 font. Will variations happen at that point?
myles: In your case bad things would happen, we'd select one of them
and then we'd clamp to a 500:500 range.
myles: But if author writes a font-face rule they wouldn't write
that.
dbaron: You can use fontface rules to provide part of what a font
provides. E.g. you can restrict to only use a certain
unicode range.
myles: That's reason for clamping
ChrisL: You can say I only want to use a restricted range of what it
can do. But if you don't put one in, it can do what it can
do.
florian: Question. When you're doing this clamping etc. can you also
have within the variability I was to use 200-400 but map to
400-600
myles: Different discussion. There's a different open issue.
TabAtkins: On the situation I described, a variant font with not
@font-face declaration and another with a weight. You say
select the 450 does selection occur there?
myles: Yes.
dbaron: Other meta point is this is a feature we've done a good job
on coordinating on shipping at the same time, which is good.
But that makes this high priority.
florian: Variable fonts don't have a descriptor and you have another
on 700 and you say 450. Instead you say 699 and you still
get the first one.
TabAtkins: We should switch to auto where it means the same as the
initial values but it does not cause any clamping.
florian: When you ask for 699 it's not a range. The variable would
not be matched because it's default to 400. If you drop the
400 you do the same thing. But if you're close to 400 that
you would get the font you get it and draw it at the
requested weight.
fantasai: If you wanted 699 off this font?
florian: You draw the range.
myles: The descriptor that covers everything is a better match.
dbaron: What TabAtkins said made sense. Does myles agree?
myles: I think that's acceptable.
dbaron: Is it what safari does?
myles: Almost. Close. With TabAtkins proposal an @font-face block
could say font-weight: auto. In my impl that's a parse error.
fantasai: I still think it's a little weird that you say font range
is auto which means everything and it's able to do weight
699 and we use the 700 font.
TabAtkins: We don't know it can do 699 so we don't download it and
and won't know it can do 699 until we download.
myles: Most fonts on the web don't have variations.
ChrisL: If you say auto you should know that it's variable since
nothing is tagged as auto.
myles: Maybe they should write 0-999.
ChrisL: I'd rather an opt in keyword and not have to write the whole
range.
dbaron: It's better to write 0-999 because you know it's a
variation. I think auto where it means 400 but don't clamp
is a good way to transition to the world with variable fonts.
myles: Should authors be able to write font-weight:auto
dbaron: It'll be possible but we shouldn't suggest it.
fantasai: I agree with ChrisL it's not nice to make authors write
0-999. Give an all keyword.
myles: Most variable fonts don't support 0-999.
fantasai: But if authors don't want to think about it and just write
0-999 it's awkward.
ChrisL: It's like for unicode where they don't write the range.
Rick: As a font user it's hard to determine range.
jpamental: The fonts as they're developing have quite different
ranges. We're only dealing with weight because it's the
only variable range that maps to CSS. Maybe with
font-weight we want people to put in the effort to put in
the low and high because it also supports wanting to
subset the range.
fantasai: But the browser gets a request for 100 and the range is
200-800 I'm still going to get the font. Unless there's
another font that supports 100 I'm still going to get that
font and I'll use the lowest number. In terms of which
file will I download it doesn't matter. Only time it
matters is if there's another font that covers the range.
myles: Let's say there's an auto and you can say font-weight:auto
and it has the same value if the descriptor is missing
without the clamp
TabAtkins: For matching it acts like the values we spec.
majidvp: And no clamping.
myles: prop: Add an auto keyword to the appropriate font descriptors
that has the effect of the following: 1) for font selection
purposes the font is selected as if the appropriate initial
value is chosen. 2) for variation axis clamping, clamping
does not occur
astearns: Obj?
RESOLVED: Add an auto keyword to the appropriate font descriptors
that has the effect of the following: 1) for font
selection purposes the font is selected as if the
appropriate initial value is chosen. 2) for variation axis
clamping, clamping does not occur.
<ChrisL> apropriate means weight, style, stretch
'oblique 0deg' vs 'normal' for font-style
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2505
dbaron: The spec for font styles says normal represents an oblique
value of 0.
dbaron: Jonathan writes it's not clear to him what this means [reads
from issue "Does normal count as oblique 0deg for this
purpose, such that font-style could be animated as an
<angle> from normal to oblique 15deg or not?"]. His test
shows chrome and edge disagrees.
jpamental: There's two variations.
ChrisL: It's the slant one. His point is valid is if it's the same
as 0 you have the endpoints of the animation. I think
oblique:0 should match.
myles: ChrisL is right. We impl that it's just a number because we
treat italic and oblique the same. So normal = oblique 0deg.
fantasai: Computed value?
myles: Probably the keyword? Don't know.
fantasai: Matters for animations.
myles: Sure then we make computed values always the oblique.
Question is what is the computed value of the font style
property. If computed value is normal for ital you can't
animate.
TabAtkins: You can animate from oblique 0.
myles: Computed value of normal should be oblique 0. Computed value
of oblique with nothing...
fantasai: I don't think it's backwards compat.
fantasai: Computed value should stay the same.
TabAtkins: We can also make the animation value handle that.
myles: Is there precedent for that?
TabAtkins: Sure we can make it work. We have special behavior for
transforms from none.
myles: This is the same.
myles: So we'll punt.
TabAtkins: Change animation so that normal can animate with oblique
as if normal is 0.
fremy: And if you put 0 in your style sheet computed value is 0.
TabAtkins: Some UA map italic to oblique and if they do so they
should be able to animate between italic and oblique.
fantasai: Suppose a variable font with both italic and oblique axis
and I specify font-style: italic
myles: We keep a float for the oblique angle and we keep a bit to
know if that came from oblique or italic axis.
fantasai: Isn't it 2d space?
myles: It's just not a variable thing.
fantasai: Can variable fonts have variable italic?
ChrisL: No.
jpamental: Intent was italic to be on or off.
florian: If you want a font to have steps between you have a custom
axis?
ChrisL: Yes.
fantasai: So you have parallel tracks.
ChrisL: You can have a custom axis and then it doesn't intersect
with CSS properties.
myles: Mechanically it's possible to have fonts that do that but
many experts have not seen a variable angle of italic.
jpamental: Italic is either italic or not, it's not a degree of
italic.
fantasai: All writing systems?
ChrisL: Most don't have ital.
<TabAtkins> Proposed Resolution: leave font-style computed values
as-is; change font-style animation behavior so that
'normal' can animate with 'oblique <num>'; if the UA
treats 'italic' as an oblique value, also allow it to
animate with 'oblique <num>'.
dbaron: Trying to understand in font matching algorithm of 5.2
bullet 4 sub bullet 2.
<dbaron> If the value of font-style is oblique and the requested
angle is greater than or equal to 0deg and less than 20deg,
dbaron: It's about font style. The 3rd unnumbered sub clause.
Sentence starts with ^
dbaron: This includes an oblique font 0deg. This is separate from
normal clause and it's not clear to me if sub point 2
includes normal fonts.
dbaron: It says if it's oblique and the angle is >=0 and <20 if you
have an exact match use that but if you have smaller look
down to 0. It doesn't say if it include 0 and, if it does,
if it's normal 0.
myles: Do we need a resolution to make it more clear?
dbaron: I think it's fine if you just clear the spec up.
astearns: We've got the proposed resolution that TabAtkins put:
leave font-style computed values as-is; change font-style
animation behavior so that 'normal' can animate with
'oblique <num>'; if the UA treats 'italic' as an oblique
value, also allow it to animate with 'oblique <num>'.
astearns: Objections or issues with it?
ChrisL: sgtm
myles: cool.
fantasai: We have UA defined behavior in the resolution and I don't
like it.
astearns: It's reiterating behavior we have
fantasai: Changes to be detectable if you can animate it.
fantasai: I'm not sure what's going on with the ones that can
animate and not.
myles: I think it's if you are a browser that treats oblique and
italic as the same you should be able to animate between. If
not you can't.
florian: I'm not sure about that. The author chooses italic, why
animate?
TabAtkins: Some browsers don't distinguish.
fantasai: But then they can't tell which they should download. Seems
like a problem. If I said italic I should get italic first.
many: not how it works.
fantasai: As an author I'll never get italic?
florian: In some browsers, yes.
myles: There's one signal.
myles: You'll get something consistent if they're both there.
fantasai: I load a font with an ital variant and an oblique variant
and I can only get one. Why is this good?
myles: It's how it's always been.
fremy: This was in css 2.
astearns: We can choose not to extend.
ChrisL: Do browsers do this? Treat them as identical?
myles: The bit doesn't effect font selection, it's only to have the
right axis.
<fantasai> https://www.w3.org/TR/CSS2/fonts.html#font-styling
<fantasai> “A value of 'italic' selects a font that is labeled
'italic', or, ****if that is not available****, one
labeled 'oblique'.”
astearns: I suggest we take the proposal and strike the UA part
Prop: leave font-style computed values as-is; change font-style
animation behavior so that 'normal' can animate with 'oblique
<num>'
astearns: Objections?
RESOLVED: Leave font-style computed values as-is; change font-style
animation behavior so that 'normal' can animate with
'oblique <num>'
default angle for font-style: oblique
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2295
myles: When css content says font-style:oblique in a non variation
world a font is oblique or not. In a variations world that
need to be mapped to an angle. Variation axis can go between
0 and 90 degrees. When you say font-style:oblique and you
don't have an angle where should it go.
myles: When I wrote the spec I printed paper with representative
fonts and I measure the angle and it looked like 20 deg.
ChrisL: Based on Jonathan's data the mid-point is 14deg and that's
what OSX uses I think that's reasonable.
florian: Issue had more details about it being platform dependent.
myles: Spec says it's not and impl made it dependent.
florian: FF made it dependent because it is outside the browser.
myles: So options are 1) 20deg, 2)14deg 3) make impl pick something.
ChrisL: The algorithm has a whole set of if it's below this pick this
fantasai: I think that algorithm should change to lower than 14. It
should be a lower end to what's considered typical.
florian: That would go against leaving it up to UA because we can't
do one that's always lower.
ChrisL: Yes.
myles: There's 2 pieces. This issue is what should we pick with no
angle and it should be 14.
astearns: Objections to using 14 as the oblique angle?
dbaron: 14 or 14.036? I mention it because Gecko was storing the tan
of the angle so we stored 0.25 and the arctan is 14.036
<dbaron> 14.036deg is atan(0.25)
astearns: Objections to 14 degrees?
RESOLVED: Use 14 degrees as the angle for undefined oblique.
myles: fantasai should open an issue as to where to put the
boundaries.
fantasai: I suggest 10 for now and then we investigate.
myles: We should figure out the answer
myles: Can we pick 14?
fantasai: We want it less.
astearns: I suggest as a part of the resolution edits you say
there's an issue and then we can edit in the appropriate
thing.
font-variant @font-face descriptor
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2531
myles: Is the commenter in the room?
ChrisL: It's Mike Gramford (sp?) and I don't know whose
implementation it refers to. They did contribute some tests
so there's a test and that's where it was discovered the
font-variant descriptor was under impl.
myles: It's mostly in the issue. Similar to the @font-face
descriptors there's one that lets you turn on/off features.
Nothing to do with font selection. I thought webkit was only
impl, but there's some other behind a flag.
<ChrisL> test case for font-variant descriptor
https://www.w3.org/People/chris/fwf/font-variant-descriptor-01.html
myles: Webkit is only shipping and our impl has architectural
problems and there's bifurcation of text code paths and we
make that before we inspect @font-face. we need to know if
there are features to turn on before we decide. If you're on
the wrong path it might or might not work.
myles: I'd like to remove it.
astearns: Does anyone claim Mike?
TabAtkins: I think it's a pdf renderer
astearns: We could defer.
ChrisL: I posted this on www-style. This is one of the non-passing
tests. Do we defer? Do we delete? It's holding us from rec
astearns: This ability seems useful.
ChrisL: I thought so too but myles talked about how it can conflict
with cascade and if you put this in @font-face you have
fixed positions.
fantasai: Property overrides descriptor so no cascade problem.
myles: Philosophically features should be applied to everything in
the cascade.
fantasai: There are fonts out there that are always small caps
myles: But turning it on on small case will be fine.
fantasai: But there are other features where e.g. if I have this font
I want historical ligatures but not on this one because
it's ugly in that font. It's an even bigger issue for
stylistic alternates.
astearns: We have a spec we want to push and a feature we don't have
2 impl. I think we should defer and not remove until we
talk.
astearns: Objections to defer font variant descriptor to L4?
RESOLVED: Defer font-variant descriptor to L4.
CSS Text Decoration
===================
Bikeshed font underline value names
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2376
myles: There's 2 properties to describe the geometry of text
decoration. Move up and move down. Increase size. Fonts also
include information about where font designer thinks
decorations should be. We resolved to add keywords to say use
what's in the font file. We have not found names.
myles: One is from-font and one is use-font
fantasai: Also match-font.
TabAtkins: We have a from-image keyword.
fantasai: Anyone impl?
TabAtkins: Dunno.
fantasai: I like your point that they should be consistent.
astearns: Objections to from-font?
RESOLVED: Use from-font
Ruby
====
Rules for Simple Placement of Ruby
----------------------------------
link: https://lists.w3.org/Archives/Public/www-style/2018Apr/0006.html
document: https://florian.rivoal.net/ruby/
florian: I don't want to spend too much time to introduce that it
exists.
florian: Kobayashi-sensei from JLReq fame wrote a new recommendation
about ruby that I translated to English. JLReq describes
what they are but doesn't try to address when you might
want to choose something. This doc takes a recommendation.
florian: If you want to handle ruby well do these things. It doesn't
handle all possible variants, but here's a set of rules you
can follow.
florian: I will not read this live, but there's a bunch of figures
and it handles mono, group, overhand, longer ruby base,
line breaking. I think people editing and reviewing ruby or
are impl ruby spec should review this with ruby spec in
parallel to find places where maybe we got it wrong or
where we said let's leave this to UA defined because most
impl don't know what they should do.
florian: If we can recommend a good base default from this. Maybe we
have in ruby spec all desirable variants but we might lack
some smartness about picking the right one. I know we have
some logic for handling ruby with Latin and ruby with
Japanese. This document exists on my personal repo.
Probably submitted by i18n.
astearns: Can you send it to www-style archive?
florian: It's a link that won't expire.
astearns: Thanks for doing this translation.
astearns: It might be good to have a time where ruby editors can go
through spec and look line by line against this.
fantasai: Sound great, but I have other things to wrap up first.
florian: Addendum is similar documents will come from
Kobayashi-sensei and the WG in Japan where JLReq lists and
these documents recommend.
CSS Text L4
===========
text-spacing: space-first
-------------------------
github: https://github.com/w3c/csswg-drafts/issues/2462
florian: Kindle does this (shows image from github). Interesting
thing to note is the opening corner bracket. These glyphs
have whitespace in them and it's been trimmed. We have a
property that allows this to be one or odd. But Kindle
decided to just trim.
florian: Some amount of trimming is typically wanted by Japanese
typographers and publishers which is likely why the
default. But what it doesn't isn't want Japanese people
want.
florian: Kinoppy does much closer. Inline in the middle of a
paragraph trim, but at the beginning set full-width.
florian: This is what people in Japan mostly want.
Rossen: What's the significance?
fantasai: Indentation.
florian: Way we spec things if you want this effect you need to a
1em text intent and you want to hang opening punctuation.
That would give you this but that's not how they do it.
florian: The brackets are a quotation mark.
myles: Not just a full width character?
florian: They're not using text indent, they're putting a space
character at the beginning of the line. Brackets at the end
are not trim but the one in the middle is trim. How they do
it is dirty but the effect is what they want.
florian: Murakami-san suggests we add a value to text-space, I think
called space-first. We have trim-start and space-start and
he suggests a value that's space on the first line trim on
the rest.
florian: It would allow being compat on this type of content. It's
regrettable they do it this way but it might as well be
compat. Even if you don't consider hacky-layouts this is
probably a good default for Japanese in general.
florian: Because trimming at the start of lines except the first is
really a good thing.
astearns: Otherwise you assume it's a paragraph.
florian: Trimming at the start of lines is good, but at the first
line content...some paragraphs are visible because the
first line has an indent.
astearns: Why not solve this by having you use trim-start and
text-indent and hanging punctuation correct for
Japanese...ah, because then the mid paragraph would hang.
fantasai: It wouldn't.
astearns: Why not use text-indent and trim-start?
fantasai: We can't by default.
florian: Right, he's suggesting this exist and be on by default.
florian: This ideal cannot be on by default because it's not
backwards compat. That's kind of redundant, but it can be
on by default which is nice.
astearns: And he goes through why my suggestion is wrong in the
issue. He says you can't apply this to current Japanese
ebooks because the epub guidelines.
florian: It's a combination of defaults and legacy and having this
value would work okay for all of these.
fantasai: Reasonable to me. Big issue is we have a standard for how
ebooks are written which is incompat with... This would
make them look good and not doing this would not.
florian: epubs would look better and the web as it is would start
looking better as well. We can do this by default.
astearns: And the current default is bad.
florian: Right.
koji: No strong opinion. This is about...the paragraph starts with
one ideographic space?
florian: If you look at the example with an ideographic space
instead of an indent or an opening punct. If there's one
that happens to wrap in the middle of the line that should
be trimmed. That's what epub authors assume. If we don't do
it epub looks bad. It will help the web too. Only slightly
for the web at the first punct but given that trim-start
isn't done currently it's bad.
koji: space-first has nothing to do with space?
florian: Name is strange it means trim on non-first-lines. Why it's
called space-first we have trim-start and space-start and
space-start means don't trim. This is "space first trim the
rest". That's a bit long so it's called space-first
fantasai: I'm not convinced this is the right thing for the Web in
general. For flush paragraphs why would you have a space
only if it begins with a bracket. But epub needs this so
we should add.
florian: In general you want trimming on the web. Not trimming the
first isn't desirable, it's just safer.
fantasai: If you're not using indentation of any form...?
florian: Maybe you're not.
florian: You only do this on your block quotes. The argument is that
it isn't always desired it's the removing the space is
always bad.
fantasai: I think we should add the value. I think the correct
default is trim everything but is there content that would
break.
astearns: Murakami-san says it would. Many will improve visually but
some will break.
koji: Apart from the default I understand the desire. But that makes
me think maybe we can use first-line and we're done.
florian: It's only interesting if it's the default. If it's not
default we have other opt-in ways.
fantasai: It needs to be the default in epubs. If it's the initial
or it's in their default stylesheet I'm not sure of the
answer. It seems clear it's needed
astearns: Prop: Add this value, suggest it's the default in epubs
and add a open issue wondering if should be in the web in
general
RESOLVED: Add this value, suggest it's the default in epubs and add
a open issue wondering if should be in the web in general.
fantasai: Does guide tell people to lang tag?
florian: We can check. So you apply based on lang tag.
Allow for paragraph-level line breaking
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/672#issuecomment-379723234
fantasai: astearns added a new feature and there was limited
discussion. I feel we should have more check in with the
group.
astearns: Issue is pretty long.
<astearns> https://drafts.csswg.org/css-text-4/#text-wrap
fantasai: Discussion was from myles asking to opt into more
expensive line breaking algo with better results.
Discussion landing on adding a switch. text-wrap property
in L4 is a longhand of white space that only controls
wrapping. Has values to say wrap, don't wrap, try to
balance lines for same length. Proposal was add a value
called multi-line that does one of these more expensive
algos.
fantasai: We've talked about fancy wrapping algorithms before.
eae: It's not that we don't want to impl, it's not a priority.
astearns: I added it to the spec as a this would be nice to have.
fantasai: Alternative is you do it anyways and you don't need an opt
in.
eae: Opt in is nice since it's quite a bit more costly.
myles: You can't have this on by default.
myles: This will be way slower.
fantasai: If concern is about performance we might want a note to
say if someone impl and discovers no performance issues.
florian: If you want to do it and have made it fast you can apply to
both.
astearns: When I added the value the default says you may consider
multi lines and the UA may optimize for speed. And for
multiline algo should consider multiple lines and should
bias for layout over speed.
Rick: UA could decide this is giant and we won't do it anyway?
myles: Yes. There's 100 criteria for a beautiful paragraph and it's
impossible to do all. Browsers should be free to pick and
choose.
fantasai: Sounds like what you want is text-wrap:expensive
fantasai: If that's what it's conveying let's convey that. There are
lots of other things to consider.
myles: But balance is also expensive. Different algo for different
reasons.
fantasai: Wrap and multiline are trying for the same effect.
florian: You're not asking for slow. You're asking for pretty even
if it's slow.
<dbaron> high-quality-wrap?
myles: It isn't one spectrum, there are different algo with
different purpose.
jpamental: As a designer there's many things to optimize on. I'd
like the pretty to have everything laid out, but I also
recognize that's hard. Maybe target which things you want
to prioritize but that's a different solution. Assigning
priority to the thing you want to address.
myles: We could make it more complicated but there's 0 impl so
simple would be good.
astearns: Concerns with leaving this prospective value in?
fantasai: If it's not clear what we're aiming at I don't know if it
makes sense to have a keyword. If someone wants to impl a
fancy line wrapping algo they can come back and ask for a
switch and what they optimize for and then we can discuss
what switch we want.
astearns: I think it's a case that a shared characteristic is that
it considers more then one line at a time. A multiline
value that can encompass a range of strategies is
appropriate. I feel that deciding on this is the pretty
strategy for the web and getting everyone to agree on a
algo won't happen. I wanted to leave it a little open so
people can experiment with what they'd trade.
fantasai: I think multiline isn't clear.
myles: Let's call it pretty
fantasai: Sure.
florian: We started with paragraph and we shifted to multiline
because it doesn't always consider the whole paragraph.
myles: Maybe not pretty because titles don't want this.
astearns: I'm happy to bikeshed on name. multiline is pretty well
known by the breed of people that use indesign.
florian: There was a thing for a switch...for editing purposes you
don't want an unstable algo.
astearns: Separate issue for that.
fantasai: In that case you want stable and something else.
astearns: And there's a note at the end of the section on that
problem.
myles: If we were to impl we prob would make multiline same as wrap.
florian: We're pretty much repeating this issue and the issue says
we don't want a separate property from wrap but wrap-stable
and wrap-pretty.
fantasai: I like it as a modifier.
dbaron: Agree wrap should be in the same.
myles: Should balance also have wrap?
Rick: multi-line line breaks would be just fine
florian: If you say wrap UA must not consider multiple lines. If you
call for stable and you don't want re-jiggle you shouldn't
consider. If you turn of the editing you want stable.
astearns: We're at time. I've got some of this discussed. Do you
want a resolution fantasai?
fantasai: I think we agree it's a modifier on wrap not a separate
keyword.
astearns: I believe there is a separate issue on editing and
multiline
astearns: Resolution that we should change value to wrap-nice,
wrap-better...something?
astearns: Issue is open we can bikeshed there.
fantasai: We can make it a modified on wrap.
koji: If multiline is modifier balance should be one too.
astearns: We're at time. I don't hear consensus and I would object
to putting wrap as a modifier on all of the values.
astearns: We're done for the day.
Received on Thursday, 17 May 2018 07:34:23 UTC