- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 09 Aug 2013 09:22:21 +0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: The precedence of font feature side-effects from other CSS properties
is in-between font-variant property and font-feature-settings property.
- Discussed interaction of text-combine-horizontal and font-variant: full-width
- Discussed various options for handling text-combine-horizontal: all; applied to
an element with child elements.
http://lists.w3.org/Archives/Public/www-style/2013Jul/0154.html
- Started CSSWG rechartering discussion, see also
http://wiki.csswg.org/planning/charter-2013
- Requesting reviews/issues for Selectors 4
====== Full minutes below =====
Present:
Glenn Adams
Rossen Atanassov
Tab Atkins (late)
Shezan Baig
David Baron
Bert Bos
John Daggett
Sylvain Galineau
Daniel Glazman
Jason Erenkrantz
Elika Etemad
Rebecca Hauck
Koji Ishii
Dael Jackson
Brian Kardell
Philippe Le Hégaret
Peter Linss
Edward O'Connor
Anton Prowse
Simon Sapin
Dirk Schulze
Alan Stearns
Lea Verou
Agenda: http://lists.w3.org/Archives/Public/www-style/2013Aug/0068.html
Scribe: SimonSapin
CSS3 Fonts: font feature interactions
-------------------------------------
Topic: letter-spacing and font-variant ligatures
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2013Jul/0686.html
<stearns> I prefer to demote precedence of font-variant
jdaggett: Font spec has different ways that OpenType features can be
specified
jdaggett: @font-face descriptors font-features-settings, font-variant,
and CSS properties font-feature-settings and font-variant
jdaggett: Other CSS properties that enable/disable font features
jdaggett: There is a precedence in the spec
http://www.w3.org/TR/2013/WD-css-fonts-3-20130711/#feature-precedence
jdaggett: font-variants and font-feature-settings override feature
settings implied by other CSS properties
jdaggett: example from fantasai: if an author sets ligatures with font-features,
this interacts with letter-spacing
dbaron: The font-variant setting overrides that letter-spacing normally
disables ligatures
jdaggett: proposal: move it to the bottom, so letter-spacing takes priority
jdaggett: other proposal is to allow font-feature-settings, which is lower
level, to take priority
Proposal 1:
1. font-variant descriptor
2. font-feature-settings descriptor
3. font-variant property
4. Special Cases
5. font-feature-settings property
Proposal 2:
1. font-variant descriptor
2. font-feature-settings descriptor
3. font-variant property
4. font-feature-settings property
5. Special Cases
<leaverou> I'm afraid this will be confusing to authors ("why aren't my
ligatures working?!"). If this behavior is undesired, can't
they manually disable ligatures?
dbaron: I’m uncomfortable putting things between font-variants and
font-feature-settings because font-feature-settings is lower level
fantasai: Authors want font-variant’s behavior in most cases
fantasai: Could consider adding higher-precedence controls in Level 4
if we want we could put font-feature-settings at the bottom
fantasai: I think, though, that wanting that level of override is going
to be pretty rare
jdaggett: Concerned about having things be overly complex for authors
jdaggett: CSS properties should not be setting font features as much
as possible
jdaggett: it’s confusing of other CSS properties have side effects on
what they’re setting
jdaggett: some crazy combinations are not good
jdaggett: I'm ok either way [ font-feature-settings last or next-to-last]
fantasai: I’m ok either way, too.
stearns: I prefer having font-feature-settings be that low-level hatch
that you don’t normally use
dbaron: I wouldn’t object. It’s weird that the override syntax is so
different from normal syntax, but I’d be ok with this
jdaggett: resolve? need other people?
RESOLVED: precedence of other CSS properties is in-between font-variant
property and font-feature-settings property
Topic: 'text-combine-horizontal' and font features (writing modes)
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2013Jul/0411.html
jdaggett: wording in spec that says when you enable text-combine-horizontal
to something other than the default, it causes the full-width
value of font-variant to be ignored
jdaggett: I think authors don’t want that
jdaggett: not clear when they want to set full-width on in this case
jdaggett: using full width glyphs is not what you want
fantasai: Not concerned that an author would set this together with TCY
on a single element
fantasai: but rather, request full-width glyphs for, say, all the
paragraph text
fantasai: and end up with full-width glyphs in a TCY run within that
paragraph
fantasai: It's the same situation as with text-transform, which we're
already overriding
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2013Aug/0042.html
jdaggett: text-transform and full-width value look the same but are
very different
jdaggett: full-width changes codepoints and thus orientation
jdaggett: that’s why authors would want to use it in the first place
jdaggett: some fonts don’t have the right glyphs, need to use the full
width codepoints
fantasai: You've demonstrated very clearly that there's no reason to use
full width glyphs in TCY, and argued that we should add an
implicit text transform from full-width to ASCII
jdaggett: other properties that affect what digit glyphs are selected
jdaggett: conflict with TCY where we pick glyphs to combine
jdaggett: specifying full-width glyphs on a paragraph is strange for
digits that are gonna be rotated
fantasai: Author can specify it together with text-orientation:upright
jdaggett: not a common pattern, shouldn’t add little exceptions for
poor authoring choices
fantasai: I don’t think it’s poor choices, might want to do that for
good reasons.
fantasai: might prefer to stay within the same font rather than have
fallback
dbaron: I think the burden of demonstrating use cases it on the person
asking for more complexity
dbaron: is this a use case we care about? Are ppl writing vertical text
without font support for fullwidth characters?
jdaggett: some fonts have the same glyphs for full-width and not, only
spacing around it changes. Same result in vertical text
jdaggett: japanese fonts always support full-width codepoints, but may
not support the feature
jdaggett: text-transform is what you want to use
jdaggett: mixing latin and japanese fonts gives no good result as latin
fonts don’t have vertical metrics
glazou: we have at least one objection
glazou: take this to the mailing list
<glazou> or withdraw objection
CSS3 Writing Modes
------------------
Topic: 'text-combine-horizontal: all' value and inheritance
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2013Jul/0154.html
fantasai: problem is that we have two different kinds of values for
text-combine-horizontal
fantasai: one scans for digits to put in a TCY run
<jdaggett> ex: <date>2013年１２月２１日</date>
<jdaggett> that will produce *two* tatechuyoko combinations
fantasai: other value takes the whole content of an element into TCY
fantasai: on an element that has lots of content,
fantasai: including sub elements
fantasai: the TCY won’t take effect because of the rule of not doing it
with element boundaries inside a TCY run
fantasai: That rule is because we don’t want impls to deal with the
complexity of handling, e.g. vertical-align, images, or
inline-blocks within TCY
fantasai: side effect is that in this case, the element will not become
a TCY run itself, but because text-combine-horizontal inherits,
descendants may or may not do TCY randomly
fantasai: So ideally, we want 'all' to be non-inheritable,
fantasai: but 'digits' needs to inherit.
fantasai: one way to handle that is to make it a shorthand for two
properties, one of which inherits
+TabAtkins
fantasai: other suggestion: keep it inheriting, but ignore 'all' if
the parent also has 'all'
Rossen: equivalent to not inheriting?
fantasai: kindda, except in CSSOM
<Bert> (Or: if both the child and the parent have 'all', apply it to the
child only?)
jdaggett: note, we are talking about 2~3 character spans
jdaggett: no need to design complex behavior for nesting
<dbaron> I prefer the second option.
dbaron: option 2 sounds fine for me
dbaron: the way to spec it is that 'all' does TCY when the parent does
not have 'all', otherwise like 'none'
<dbaron> option 2 is "keep it inheriting, but ignore 'all' if the
parent also has 'all'"
fantasai: it would break koji’s example
fantasai: text-combine-horizontal:all in an element, and inside that
element have a span with text
dbaron: if you want that case to work, should ignore the rule for ignoring
things that have elements in them
Bert: what about reversing parent/child? [see above]
Rossen: now you have to look forward, layout becomes more complex
Rossen: at any point, no idea whether something else is supposed to
handle this
Rossen: would prefer non-inherit by default […]
dbaron: that doesn’t work for the 'digits' value
jdaggett: which is the common case
fantasai: multiple properties is the only way to get different inheritance
behaviors
fantasai: or maybe hack something with 'auto'
jdaggett: keep focus on actual use cases
jdaggett: few examples of nested elements with TCY
jdaggett: keep exceptional cases as simple as possible
dbaron: what existing content would it break?
<koji> <span style="text-combine-horizontal:all"><span>12</span></span>
<Bert> (<x style="..:all:><y>AB</y><y>CD</y></x> could make *two* TCYs...)
fantasai: we avoid element boundaries so that implementations don’t
have to deal with the complexity
fantasai: If you're proposing to form TCY for such cases, what are
implementations expected to do when presented with such content?
Even if it's not a common use case, we have to define *something*.
jdaggett: Just scale it.
dbaron: I’m find with what jdaggett is proposing if we have example of
elements inside of TCY
glazou: take this to email?
Bert: text-decoration property sort of inherits, maybe do something similar?
CSSWG Charter
-------------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013JulSep/0109.html
Bert: charter runs out in september, we’re already too late
Bert: takes a few weeks to discuss the draft, I will be drafting
Bert: AC review takes 2~3 weeks plus same for objections
Bert: won’t be a problem, we’ll get an extension to bridge the gap
Bert: priorities? Which drafts can we finish, etc
Bert: what can we finish in the next two years
Bert: list of CRs in the email
glazou: setup a wiki page of all specs? with expected completion date
set by editors
* fantasai suggests http://wiki.csswg.org/planning/charter-2013 to parallel
http://wiki.csswg.org/planning/charter-2008
glazou: that’s one of the options
Rossen: let’s go with it
glazou: Bert’s list only contains current CRs, some drafts could move faster
Bert: I’ll add the drafts to the list
plh: Also good to get upcoming work items into the charter, for patent
policy.
plh: drafts that the group can foresee will start
plh: that are not yet started
glazou: Hard, since we rely on proposals for new work from the members.
SimonSapin: do we have proposals that are not drafts yet?
jdaggett: font load events
dbaron: that was split from another spec
Selectors 4
-----------
fantasai: issues still open
fantasai: do people have other issues, concerns, ?
fantasai: figure out how to move the draft forward
glazou: does :dir() rely on the direction property?
fantasai: it does not
fantasai: also some renaming issues still open
fantasai: also what to have in the fast vs. complete profile
glazou: issue a call for review? Give people 2 weeks
glazou: it’s a big spec, lots of changes from L3
<dbaron> I'm still uncertain about: the reference and column combinators,
:matches() syntax, and the subject indicators. (That's after a
quick skim; might have missed something.)
ACTION everyone: review Selectors 4 within the next two weeks
<dbaron> I'm also unsure about the priority being high enough that we
should give everyone a 2 week deadline.
Meeting closed.
Received on Friday, 9 August 2013 01:22:48 UTC