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

[CSSWG] Minutes Telecon 2013-08-08

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 09 Aug 2013 09:22:21 +0800
Message-ID: <5204444D.8050300@inkedblade.net>
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年12月21日</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

This archive was generated by hypermail 2.3.1 : Friday, 9 August 2013 01:22:49 UTC