- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 22 Apr 2010 08:29:29 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Shinyu Murakami added as co-editor of css3-text and css3-text-layout
- RESOLVED: Provisionally accepted bz+fantasai's table anonymous box
proposal for CSS2.1 Issue 109:
http://lists.w3.org/Archives/Public/www-style/2010Mar/0551.html
http://wiki.csswg.org/spec/css2.1#issue-109
- Reviewed CSS3 Fonts issues in Bert's email:
http://lists.w3.org/Archives/Public/www-style/2010Mar/0553.html
http://lists.w3.org/Archives/Public/www-style/2010Apr/0069.html
a) 'font-stretch' was originally excluded from 'font' shorthand
because 'font' shorthand was very fragile and editors were
concerned about adding anything to it. jdaggett to look into
whether it's still a problem, and see if it can be added.
b) Agreed to remove note about font format name registry.
c) Wrt syntax of local() being underdefined, seem to have agreement
on copying quoting conventions of font-family property.
e) Wrt font-matching algorithm and synthetic bolding, it seems the
spec may need some clarification since there is no disagreement
in desired behavior, only in reading of the spec text.
g) font-kerning to have three values:
* 'auto', the default, which means the UA may turn it on or
off depending on perf or other concerns. Recommended to be
always on.
* 'normal', meaning always-on (OpenType's default)
* 'none', meaning always-off
====== Full minutes below ======
Present:
Tab Atkins
David Baron
Bert Bos
John Daggett
Beth Dakin
Elika Etemad
Simon Fraser
Sylvain Galineau
Brad Kemper
Shinyu Murakami (via IRC)
Chris Lilley
Peter Linss
David Singer
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2010/04/21-CSS-irc
Scribe: fantasai
Administrative
--------------
Peter: Any other agenda topics?
fantasai: Murakami-san would like to become co-editor of css3-text
and css3-text-layout
No objections
<murakami> Thanks
Topic: Test Suite Status
fantasai has not worked on the test suite since the F2F (was studying
for the FE exam last Saturday instead), so nothing to report
Table Anonymous Boxes
---------------------
Tab: AFAICT, it looks great
<plinss> http://lists.w3.org/Archives/Public/www-style/2010Mar/0551.html
dbaron: Was Boris happy with it?
fantasai: yes
fantasai: There's a related issue of handling abspos elements
fantasai: Boris's original proposal had abspos elements leave behind
a "placeholder", which would then affect the anonymous
table box generation
fantasai: From an implementator's perspective, I can see why. In Gecko
each out-of-flow has a placeholder left behind so that we
can calculate its static position
fantasai: But from an authoring perspective, it doesn't make any sense
for the abspos to leave anything behind
fantasai: The out-of-flow should just disappear from its original
position
Tab agrees that it should not affect layout where it used to be (but
is no longer)
<oyvind> does it break compat?
<table><colgroup><strong>test</strong></colgroup></table>
is shown here...
fantasai: it's easy to say that the abspos elements don't affect box
generation in their former location, but it's harder to
stay then what the static position is
ACTION: Tab write a proposal
Bert: There were some changes to the behavior in Boris's proposal,
are those still there?
Bert is concerned about changes to the spec
Tab asserts that the spec had a lot of errors, and this cleanup is
the right direction to go in
<TabAtkins> <style>div { display: table; }
span.tc { display: table-cell; }</style>
<div>
<span class=tc>foo</span>
<span>bar</span>
<span class=tc>baz</span>
</div>
Tab: Given this testcase, you see one row in Firefox and Chrome,
not one table with three rows
<sylvaing> same results in IE8 and Opera 10.51
fantasai: bz did a lot of testing of all the major browsers when
he was writing this
fantasai: and tried to write something that was as compatible as
possible with all of them
Tab: Looks like current 2.1 also specifies a single row
<TabAtkins> To be specific, I misread the proposed algorithm.
It does indeed mandate the behavior that we see in
browsers for that testcase.
+bradk
Peter: Any other issues? Everyone's ok with the proposal?
Bert: yes, I can't read it in such a short time
Bert: I'll complain later if I see problems with it
RESOLVED: Provisionally accept bz+fantasai's table anonymous
box proposal for CSS2.1
CSS3 Fonts Issues
-----------------
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Mar/0553.html
jdaggett: Bert posted a list of comments on the css3-fonts spec
jdaggett: There are both editorial and substantial comments.
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Apr/0069.html
jdaggett: I fixed most of the editorial comments
jdaggett: Here are my responses
jdaggett: The first issue is about font-stretch not being included
in the font shorthand
jdaggett: My reason to skip it out was that 'font' already has a ton
of stuff in it
ChrisL: When we were working on that we concluded that 'font'
shorthand was too fragile to alter
ChrisL: So we concluded to only include settings from 2.1 in the shorthand
ChrisL: If that's not a problem anymore, then, there's no reason not
to include it
jdaggett: I'm on the fence because I don't see font-stretch being used much
jdaggett: I'll experiment and see if including it into the shorthand works
jdaggett: Comment B), there was a note because Steve was concerned
about conflicts. We were talking about whether to have a
registry
Steve: Offhand I guess I agree with Bert's observation. At the time,
we had much more volatility going on.
Steve: If we can update the document to handle it...
<ChrisL> agree the volatility is manageable
Steve: Bert's comment is fine, I can live with that
jdaggett: Comment c) is about the syntax of local()
jdaggett: Bert is asking whether we should put in wording about the
syntax if it's not quoted
jdaggett: I think that sounds good, but I'm concerned about our
current discussions about unquoted font names
jdaggett: Some of the proposals don't correlate with an
easy-to-understand rule
jdaggett: And I'm waiting to see what happens there
ChrisL: We should have the same set of restrictions on both font-face
and font-familky
jdaggett: I agree with that, but also because of font shorthand,
there are some restrictions that you need to have in
font-family that you don't need in font-face
jdaggett: I think it's really confusing for people
jdaggett: e.g. a font name that starts with a number causes all kinds
of problems
jdaggett: Bert, did you have anything?
Bert: Trying to find where <font-face-name> is defined
<ChrisL> I sent in some responses to Bert's comments (before seeing
John's ones) -
http://lists.w3.org/Archives/Public/www-style/2010Apr/0451.html
jdaggett points to the definition
Bert: My issue is what does "optionally" mean? When do you need
quotes? When do you not need quotes? When are they optional?
jdaggett: It's always optional
fantasai: It can't always be optional. If the font name includes
brackets or backslashes, you have to quote it.
fantasai: The best thing to do would be to point to the font-family
definition. It might be slightly more restrictive than
necessary here, but I think that's less of a problem than
having an inconsistency there. You can recommend to quote
anything with numbers or symbols.
<szilles> +1 for what fantasai said
<dsinger> I would recommend always quoting font names. I would expect
to have to, in fact. They are not part of the CSS language
(keywords in their own right) but values supplied into it.
jd talks about the font-matching algorithm
jdaggett: The point here is to do font-matching without downloading
the font insofar as possible
jdaggett: because we dont' want to download the font if we don't need it
Bert: The problem I have is with specifying sythetic bolding / italics
jdaggett: If someone wants to never have synthetic bolding, they can
point the bold versions at the same font
Bert: Hm, I thought the text said something else
Bert: I thought it meant that, if the descriptor said the font is bold,
and the font is normal, the UA would have to synthesize the bold
Bert: I don't object to what you explained
jdaggett: g) is on whether font-kerning is needed as a property or not
jdaggett: It's right now specified as on by default
jdaggett: Authors have the ability to disable it
jdaggett: It's there for situations where authors don't want kerning.
These are uncommon, but I think it's important to allow
authors to turn it off.
Bert: I think there are so few cases where you'd want to turn it off
jdaggett: in some cases you might not have the right kerning data
Steve: What happens with kerning on monospace fonts?
jdaggett: It usually doesn't have any kerning data
Steve: I'm trying to think of a case where I'd want to turn off kerning
jdaggett: For complex script support, there might be cases where you
need to override that.
jdaggett: I think I need to come up with specific examples
fantasai suggests marking it at-risk
Steve: I hope that everyone agrees kerning should be on by default.
jdaggett: One of the objections to turning kerning on by default is
that people compain about performance implications
jdaggett: This way those people can turn it off.
jdaggett: I will add a note saying that there's some question of
whether this feature is needed.
dbaron: It seems like the perf concerns are less about authors who
particularly want perf than about things like perf benchmarks
and stuff
dbaron: It's going to be somebody testing perf characteristics, not
an author tweaking a page to make it faster.
dbaron: If it's measurable in that context, I'm not sure that it is,
I don't think having a property for turning it off is really
addressing the perf concern
jdaggett: Kerning usually requires going through a slower-path API
for font rendering that allows for more effects
jdaggett: you have to go through that API for most of the new
features here anyway
Simon: In terms of WebKit, we know that kerning has a serious impact
on pageload perf
Simon: I'm not sure what the impact of these complex text features
will be
Simon: If the expectation is that browsers will suddenly start doing
all this complex text layout, I don't really see a path to
getting there
jdaggett: You have to render a huge amount of text to get a pref lag
jdaggett: Firefox has had kerning on by default for 2 years now
dbaron: I thought that was only for large font sizes
jdaggett: On Windows.
jdaggett: You can do the measurements, and you can get numbers that
it's faster to turn it off
jdaggett: But when you look at documents and what it takes to lay
them out
jdaggett: the effect of kerning is a very small part of that
Sylvain: MS did some testing awhile back, and with kerning on the
text part of layout was almost twice as slow.
Sylvain: We haven't done that testing recently, and not sure what
the effect on total page layout is
<ChrisL> sounds like we could do with some recent benchmark numbers
on current platforms
jdaggett: The APIs were optimized for complex scripts, not for
additional font features on simple scripts
ChrisL: We need to get up-to-date measurements
ChrisL: If we're going to have this discussion, we need to have
measurements from current builds using current APIs
fantasai suggests having a default 'auto' value that lets UAs pick
a compromise between perf and prettiness
fantasai: If an author wants it on, they can pick the always-on option
dsinger, Bert: it makes sense to have the browsers compete on perf
vs prettiness
Steve: We should recommend that kerning be on by default
Steve: That's the default in OpenType
<ChrisL> sounds like a three way auto | on | off where auto mean
"should be on"
<fantasai> "but could be off if the UA decides the perf isn't worth
it in some cases"
Sylvain discusses sub-pixel positioning and that turning kerning
off can be helpful for debugging sites
Sylvain: and on certain sites, where the author isn't expecting it,
can alter the layout in ways the author does not want
jdaggett: So what I'm taking from this is that kerning is a property
with three values: 'auto', which means UA decides, but
recommended to be on, 'normal', which means on, and 'none'
which means off
CSSOM
-----
dbaron: I sent some comments on the CSSOM issue over email.
Tab too
Meeting closed
Received on Thursday, 22 April 2010 20:33:24 UTC