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

[CSSWG] Minutes Telecon 2013-08-28

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 28 Aug 2013 17:53:14 -0700
Message-ID: <521E9B7A.1030909@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - RESOLVED: Publish updated WD of Grid Layout
   - RESOLVED: Switch named lines syntax to (<ident>+)
   - RESOLVED: Accept 'grid' shorthand

   - RESOLVED: Drop 'auto' value of font-size-adjust
   - RESOLVED: Clarify in CSS3 Fonts that  font-size-adjust only
               affects used,  not computed, value of font-size
   - RESOLVED: Fix errors in note wrt using ems vs. numbers for
               line-height, effect of font-size-adjust on ex/ch
   - Discussed whether 'ordinals' should be on 'font-variant-numeric'
     or 'font-variant-position'. Summary of arguments:
       font-variant-numeric: ordinals
         - doesn't have fallback synthesis like superscripts/subscripts,
           so want to avoid associating with font-variant-position
         - related to typesetting numbers, so in font-variant-numeric
       font-variant-position: ordinals
         - affects letters, not numerals/digits, so weird to put in
         - affects visual position/size just like superscript/subscript,
           so makes sense in font-variant-position, despite lack of
           fallback synthesis

   - RESOLVED: object-fit stays at-risk (for now)

====== Full minutes =====

   Glenn Adams
   Rossen Atanassov
   Tab Atkins
   Shezan Baig
   David Baron
   Tantek «elik (via IRC)
   John Daggett
   Jason Erenkrantz
   Elika Etemad
   Simon Fraser
   Rebecca Hauck
   Dael Jackson
   Vladimir Levantovsky (Monotype)
   Peter Linss
   Edward O'Connor
   Chris Palmer
   Simon Sapin
   Dirk Schulze
   Leif Arne Storset
   Steve Zilles

Agenda: http://lists.w3.org/Archives/Public/www-style/2013Aug/0570.html
Scribe: fantasai

<SimonSapin> TabAtkins, whatís the next step for Syntax?
<TabAtkins> SimonSapin: Me to actually get it published by prepping and
             sending it today

CSS Fonts

   waiting for Tab to get back on the call (dropped off)
   * TabAtkins is curious why he's required for Fonts.
   <jdaggett> TabAtkins: font-size-adjust!
   <TabAtkins> jdaggett: Meh, I'm fine with your conclusions in the thread.
               I think auto is useful, but whatever.

Grid Layout

   plinss: Request for updated WD?
   fantasai: Is there anyone here that needs me to go through the changes
             to Grid Layout that we want to publish?
   fantasai: In that case, is everyone ok with us publishing an updated WD?
   RESOLVED: Publish updated WD of Grid Layout

   plinss: Any other things to go over?
   fantasai: Good to get WG resolutions on some changes
   fantasai: First is change to named lines syntax from <string>+ to (<ident>*)
   fantasai: 2 advantages -- using idents more consistent with CSS syntax
   fantasai: Also parens provide visual grouping, easier to see how many
             lines and how names are grouped
   Rossen: Would be good to get Steve Zilles' opinion
   SteveZ: Haven't reviewed new syntax yet
   SteveZ: main advantage of parens is disambiguation?
   fantasai: Also visual grouping, b/c can have multiple names to single line
   SteveZ: Parens certainly avoid conflict situations that you could get into
   TabAtkins: Using idents introduces slightly less bad conflict in
              grid-placement properties, but that's not as much of a problem
   SteveZ: sounds okay, if problem will reraise it
   plinss: Any objections?
   RESOLVED: Switch named lines syntax to (<ident>+)

   fantasai: Added 'grid' shorthand, using syntax from Bert's Template module,
             with slight modification to allow for named lines and for leaving
             out the template names
   plinss asks for comments
   RESOLVED: Accept 'grid' shorthand

CSS Fonts

   <jdaggett> http://dev.w3.org/csswg/css-fonts/doc-20130711-LCWD.html
   jdaggett: LC period finished last Thursday

   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2013Aug/0239.html
   jdaggett: first is 'auto' value for 'font-size-adjust'
   <jdaggett> http://dev.w3.org/csswg/css-fonts/#font-size-adjust-auto-value
   jdaggett: As currently specced, takes aspect value of UA's default font
   jdaggett: There was some confusion as to what the spec meant; people
             thought it meant you take the first font in the font-family list
   jdaggett: Regardless, there's still a certain amount of variation across
             platforms and UAs and whether they allows users to set the
             default font, which creates more variation
   jdaggett: The value was useful because it reflected what user would see
             on pages without any font settings
   jdaggett: but can see the point that there's a lot of variability in
             different environments, etc...

   Vlad: Main concern that I have about unpredictability of results
   Vlad: If you don't specify anything, and use default font is used, no
         adjustment needed
   Vlad: If you do specify fonts, and mistakenly assume that 'auto' would
         get adjustment to aspect ratio of the fonts you specified...
         that's not going to happen
   Vlad: So main objection is unpredictable results
   Vlad: goal is maintaining readability, this might actually act counter
         to that goal
   Vlad: Would like more deterministic properties
   Vlad: Specify a number, you get what you asked for
   Vlad: Otherwise, no adjustment.
   Vlad: Straightforward strategy

   jdaggett: There were several proposals from other people on the list
   jdaggett: e.g. Jonathan Kew had a proposal
   jdaggett: Those to me have other questions
   jdaggett: And since we're at last stage of CSS3 Fonts, I would propose
             that we just drop 'auto' from CSS3 Fonts
   jdaggett: And move it out into Level 4
   jdaggett: Any objections?
   fantasai: Sounds reasonable to me
   SteveZ: Existing implementations?
   jdaggett: Nobody implements 'auto' value, so no impact
   RESOLVED: Drop 'auto' value of font-size-adjust

   jdaggett: Other issue that was brought up was relationship of
             font-size-adjust and line height
   jdaggett: Line height is typically specified relative to the font size
   jdaggett: Vlad was concerned that there was nothing in the spec that
             talked about relationship of font-size-adjust and line-height
   <jdaggett> http://dev.w3.org/csswg/css-fonts/#font-size-adjust-auto-value
   jdaggett: 'em' unit is not affected by font-size-adjust
   [reads note]
   jdaggett: Does that cover what you're worried about, Vlad?
   Vlad: covers part of it
   Vlad: But not clear to implementers what's affected
   Vlad: Should be clear that line-height is always calculated wrt base
         font-size, not affected by font-size-adjust
   jdaggett: Think we're covered by css3-values
   fantasai: Not entirely. line-height takes lengths, but also takes numbers

   dbaron: You noted in the note that authors set line-height in em units,
           but that's really bad, should set in number units

   SteveZ: Question... specified, computed, used, which?
   fantasai: We decided on computed font-size for 'em', so probably
             line-height should be the same
   SteveZ: So font-size-adjust affects used font-size, but not computed
   SteveZ: Would be useful to say that.
   jdaggett: So we need to add a normative statement to paragraph above.
   Vlad: Say that font-size-adjust affects the used font-size (used to
         render text), not the computed font-size
   Vlad: That also addresses my concerns about describing precisely how
         this works.
   Vlad: Illustrated, but not specified.

   RESOLVED: Clarify in CSS3 Fonts that  font-size-adjust only affects used,
             not computed, value of font-size
   RESOLVED: Fix errors in note wrt using ems vs. numbers for line-height,
             effect of font-size-adjust on ex/ch

   fantasai: Other error in that note -- font-relative units, only 'em'
             is unaffected, 'ex', and 'ch' are affected
   plinss: So ex/ch are based on on used, not computed font-size
   fantasai: Yes. We should clarify that in CSS3 Fonts
   fantasai: Specified already in CSS3 Values
   SimonSapin: 'used' should probably link to CSS3 Cascade definition

   <fantasai> Missing http://lists.w3.org/Archives/Public/www-style/2013Jul/0170.html
              from DoC
   fantasai: 'ordinals' to be with superscript/subscript values?
   jdaggett: Difference is that it doesn't have fallback behavior
   jdaggett: Since used for numerics, put it with font-variant-numeric
   fantasai: I think that logic makes sense, but,
   fantasai: as you pointed out superscripts and ordinals are often confused
             with each other, so it would be helpful to authors to learn to
             distinguish them if they are in the same property
   fantasai: also, it's the only value of font-variant-numeric that doesn't
             actually affect digits
   jdaggett: Are you asking for the value to be moved?
   fantasai: Yes
   jdaggett: I disagree for reasons above
   fantasai: There are arguments on both sides here:
   fantasai: [summarizes arguments]
     font-variant-numeric over font-variant-position
       * doesn't have fallback behavior, so want to avoid font-variant-position
       * related to typesetting numbers, so in font-variant-numeric
     font-variant-position over font-variant-numeric
       * doesn't affect numerals/digits, so weird to put in font-variant-numeric
       * affects visual position/size just like superscript/subscript,
         so makes sense in font-variant-position, despite lack of fallback

   SteveZ: [...]
   SteveZ: Subtle distinctions typically get lost on ordinary people
   jdaggett: Behavior is much more like numerical forms [in that it doesn't
             have fallback]
   fantasai: [...]
   SteveZ: Let's continue on list / next week.

   plinss: And please add some examples of ordinals, esp since confusion
           of what they are and how used
   plinss: We'll come back to that next week, hopefully CR transition then

   Vlad: Thanks for all the consideration you gave to my comments
   fantasai: Thanks for reviewing the spec! We really appreciate that.

Status Checks

   plinss: Counter Styles LC period expired
   TabAtkins: Haven't addressed all comments
   plinss: Time frame?
   TabAtkins: Hopefully next week?

   fantasai: Same is true for Cascade; haven't pulled together DoC yet

   plinss: Selectors 4?
   fantasai: Don't have issues prepared

Image Values 3

   smfr: object-fit marked as at-risk. Blink has an implementation, have
         a patch for WebKit
   smfr: Have an implementation in old Opera code
   smfr: Would like object-fit to be marked as not at-risk
   TabAtkins: sounds reasonable to me
   fantasai: Don't think we need to; at-risk means we *can* drop it if
             we want to, doesn't mean we have to
   plinss: Right
   plinss: also, we can't count Blink/WebKit as two implementations
   plinss: but Opera counts
   * tantek prefers leaving it at risk unless you've got a test case that
            passes two shipping implementations.
   <tantek> and what plinss said
   leif: Opera's implementation isn't entirely conformant

   <dbaron> I'd also prefer leaving it at risk.  Unprefixed is great;
            it's in CR.
   <tantek> that's true

   hober: There's a PR angle to this; if marked as at-risk, authors think
          it can't be relied on
   TabAtkins: at-risk exists mainly for process reasons, given we have
              implementations, so I don't see a problem with taking it
              out of at-risk
   <tantek> disagree about "mainly for process reasons"
   <tantek> is there a URL to a test case that works in 2+ browsers (with
            different engines) ?
   <tantek> if so, then yes, remove from at-risk
   <tantek> if not, then leave it at risk
   <tantek> and if so, provide URL to said test case(s) to the minutes please
   plinss: Do we have tests?
   TabAtkins: No
   <tantek> then leave it at-risk :P
   RESOLVED: no change (for now)

   <TabAtkins> tantek: Um, that criteria would mean marking the entire
               spec at-risk.
   <tantek> let's stick with at least semi-objective criteria rather than
            debating things like that politically in a telcon :P
   <TabAtkins> At-risk is entirely for marking things that have a shaky
               future, such that we think it's a good idea but still *might*
               want to go back and kill/punt it.  Marking it means that,
               process-wise, we can do so (and republish a CR) without it
               being a "substantive change" that'll require an LC round.
   <tantek> at-risk is for better communicating about the status of a
            feature to authors
   <tantek> and yes - helps with reducing CR-LC-CR roundtrips


   <plinss> http://wiki.csswg.org/ideas/naming
   fantasai: If anyone has good ideas, we're looking for good ideas
   fantasai: Otherwise, close the call

Meeting closed.

<TabAtkins> tantek: Communicating status to authors is useful, but it's
             not what the At-Risk designation is used for.
<TabAtkins> tantek: And in particular, your attempt to say that we should
             tie it to the semi-objective criteria of "has tests in an
             official test suite" means that most features in most of our
             newer specs should all be marked at-risk.
<TabAtkins> Which they aren't, and we won't do.  So trying to apply that
             criterion to this feature specifically is inconsistent.
<TabAtkins> (Not to mention, I don't think "has tests in an official
             test-suite" maps well to the plain-English phrase "at-risk"
              anyway.  If you think we should have such an annotation,
              I agree, but it would be called "is tested" or something.)
<tantek> who ever said "official test-suite"?
<tantek> I asked for a test case with a URL
<tantek> that doesn't seem that much to ask for
<tantek> (especially for a feature that presumably someone thinks is
          solid enough to not be "at-risk")
<tantek> (heck, even a test in the spec itself would be great)
<TabAtkins> tantek: We certainly have test cases in browser test suites.
             Whether they have a url depends on how much you accept relying
             on github mirrors.
<TabAtkins> But, again, regardless of that, your criteria can't be applied
             consistently without marking a lot more stuff across lots of
             specs as "at-risk".
<TabAtkins> Which is silly.
<tantek> what's silly is claiming stuff isn't at risk when one cannot even
          produce a single public URL test case for it
<TabAtkins> I'm claiming you're not consistent in applying the criterion.
             I'm making no claims for or against the criterion itself at
             the moment.
<tantek> TabAtkins - likely true. trying to be better about that. writing
          down the proposed spec iteration steps was a step in that direction.
          also I like including little mini-tests in specs themselves. :)
Received on Thursday, 29 August 2013 00:53:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:33 UTC