- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 28 Aug 2013 17:53:14 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- 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
font-variant-numeric
- 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 =====
Present:
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?
http://lists.w3.org/Archives/Public/www-style/2013Aug/0353.html
http://lists.w3.org/Archives/Public/www-style/2013Aug/0554.html
fantasai: Is there anyone here that needs me to go through the changes
to Grid Layout that we want to publish?
[silence]
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
conventions
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
font-size.
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
Naming
------
<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