- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 18 Mar 2010 16:59:14 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- New alpha of CSS2.1 test suite is out, using new rewrite of build system.
http://lists.w3.org/Archives/Public/www-style/2010Mar/0152.html
- Discussion of jdaggett's new CSS3 Fonts draft. Reviewed some issues,
specifically:
* WG seems to agree with the level of granularity in the draft.
* Some concern over applying font-specific settings to a fallback list.
Extended discussion at:
http://lists.w3.org/Archives/Public/www-style/2010Mar/0185.html
* Ongoing discussion about how to handle sub/superscript support in a
failsafe way. See
http://lists.w3.org/Archives/Public/www-style/2010Feb/0247.html
- Discussed Tab's proposal for gradient finite/infinite--ness and an
'extend' value for 'background-repeat'. See email discussion at
http://lists.w3.org/Archives/Public/www-style/2010Mar/0169.html
- Briefly discussed Sylvain's concerns about background-clip. Further
discussion deferred to later.
http://lists.w3.org/Archives/Public/www-style/2010Mar/0021.html
====== Full minutes below ======
Present:
Tab Atkins
David Baron
Bert Bos
John Daggett
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Peter Linss
Christopher cslye (Adobe)
<RRSAgent> logging to http://www.w3.org/2010/03/17-CSS-irc
Scribe: Sylvain
CSS2.1 test suite
-----------------
fantasai: new alpha build is out. please review tests, identify build system
issues
<fantasai> http://lists.w3.org/Archives/Public/www-style/2010Mar/0152.html
fantasai: if you review a test, please make sure to communicate it by adding
yourself as a reviewer or mailing the list
fantasai: we had a request to submit i18n WG testcases
<fantasai> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Feb/0015.html
<fantasai> http://www.w3.org/International/tests/list-html-css
CSS3 Fonts
----------
http://lists.w3.org/Archives/Public/www-style/2010Feb/0244.html
jdaggett: I posted a draft update including opentype font feature support
following the f2f discussion last year
<jdaggett> http://www.microsoft.com/typography/otspec/featurelist.htm
<jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-variant-ligatures-prop
jdaggett: There are lot of opentype features
jdaggett: This proposal groups these features in compound properties;
there is a granularity trade-off in that you pick a set of features
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Mar/0098.html
jdaggett: Sergey Malkin preferred the features to be exposed as individual
properties
jdaggett: this would result in a lot of properties
fantasai: I think you've done a good job grouping related properties
fantasai: there is a lot of overhead in having a lot of properties, both for
browsers and authors.
fantasai: If needed, we can turn these into compound/shorthand properties
in the future
jdagett (answering Tab): for people who have Macs, this is easy to test
using TextEdit. The font panel shows you available font features
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Feb/0244.html
jdaggett: some font features are specific to a single font. this could
have side-effects in a fallback situation
jdaggett: this primarily affects those OT style settings that use a number
(e.g. styleset() )
jdaggett: the other properties do apply across fonts
jdaggett: cslye: it's not just that some features apply only to one font,
it's that styleset x in font B might look completely different
and unrelated to styleset x in font A
jdaggett: i think the spec could use more background on the rendering model.
<dbaron> Where is the wording in the spec about the precedence? (Or is
it not there yet?)
* sylvaing missed some of the discussion due to sound issues
<jdaggett> dbaron: section 7
<dbaron> jdaggett, section 7 doesn't seem clear whether the order it gives
is highest-to-lowest or lowest-to-highest precedence
fantasai: I think it's a good idea to have font-variant-alternates on the
@font-face, to allow -font-specific variant selection
fantasai: would we still have these numeric selections in the property?
jdaggett: yes
?: the odds of falling back to a font with a competing equivalent styleset
are lower. authors will go from most to least specific.
fantasai: I'm concerned that authors will use the numeric selections on the
property because it's easier
fantasai: instead of tying it to the font in @font-face
jdaggett: it's actually difficult to come up with a realistic scenario
where this would work
cslye: I understood stylesets to be a power user feature.
fantasai: this doesn't prevent breakage, it only limits its frequency
jdaggett: fallback will still happen
fantasai: I am still concerned in applying this to all fonts
plinss: I agree that this may not be a problem in the short term but it
may be in the future. we should address these issues now
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Feb/0245.html
jdaggett: one of the features that is not in the spec already relates to
sub/superscript support
jdaggett: OT can support a variant glyph suitable for sub/superscript
resizing. it's also designed to look and feel like the rest
of the text in that context
jdaggett: it's analogous to real smallcaps vs. synthesized smallcaps
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Feb/0247.html
<TabAtkins> character-transform: super|sub
* bradk is unable to see much in TextEdit that shows additional OpenType
font features. Found ligatures in Arial, but the checkbox doesn't
have any effect of fi or ffi.
jdaggett/fantasai/tab: we need to way to use this OT feature if the glyphs
are available, but simulate it with vertical-align:super when not.
<fantasai> that's what Tab's proposal is
<fantasai> my comment was that the property Tab proposed should also reset
vertical-align and font-size to their initial values at parsetime
<fantasai> the same way a shorthand does
jdaggett: also, it is hard for the spec to be format-agnostic i.e. not
have a dependency on OT at this point
dbaron: there is a difference between spec and the test suite. The spec
may apply to multiple formats but the test suite does not need
to cover them all.
fantasai: for other formats, testcases can be submitted for conformance
using that format by the vendor wanting to claim conformance
using that format
<fantasai> Can use examples to illustrate spec with OT-specific features
<fantasai> For example, the specs don't require support for HTML or XML.
You could use some other tree-based document format and style
it with CSS
<fantasai> But the test suite is written assuming support for XML or HTML
<fantasai> And all our examples in the specs use XML or HTML
jdaggett: I will do another edit in the next week
Extent of Gradients in Backgrounds
----------------------------------
Tab: I had imagined gradients to be infinite but it's not how Mozilla
implemented it
dbaron: we changed it based on what we thought the spec said
Tab: I would like to specify that the gradient be 'chopped' to the box
and the extend keyword would make the gradient infinite
fantasai: SVG could use 'extend' as well
<fantasai> Right now content in SVG is clipped to the SVG viewport
<fantasai> extend could mean don't clip
<fantasai> So anything painted outside the viewport box would show up
dbaron: I'd like to hear from Roc
Tab: Anybody else implemented gradients?
Simon: Webkit has the old syntax. I agree extend would be useful in
many cases, and should be the default
* sylvaing definitely leaves minutes to Elika. VoIP breaking down.
* fantasai has lost track of the conversation tho!
Brad says something about gradients being analogous to patterns
ScribeNick: TabAtkins
bradk: I think that the infinite-version of gradients is more useful,
and should be the default, and then have a keyword to change
it to the finite version.
TabAtkins: That's possible, but the SVG use-case for extend (popping
it out of the viewbox) is still potentially useful.
We can experiment with this.
<dbaron> TabAtkins, Is there a www-style message summarizing the
background-repeat: extend proposal?
<dbaron> TabAtkins, I see only http://lists.w3.org/Archives/Member/w3c-css-wg/2010JanMar/0101.html
<TabAtkins> dbaron: No, let me forward that mail to www-style.
background-clip and background shorthand
----------------------------------------
ScribeNick: fantasai
Sylvain explains his concern about background-clip
Sylvain: About how you can't specify origin and clip in the shorthand
Sylvain: And there is no content-box value on background-clip
http://lists.w3.org/Archives/Public/www-style/2010Mar/0021.html
Sylvain: I don't think we should exclude the people who want to set
background-clip to the content box
<fantasai> proposed syntax: Change <bg-origin> in shorthand to <bg-origin>{1,2}
Bert: I don't think clipping to the content box is very useful, but I
don't see it's harmful either
Sylvain: I don't see why it wouldn't be useful to have separate backgrounds
for the border, padding, and content areas
Brad: I agree
Tab: Would be more useful with multiple backgrounds
Brad: I don't like the proposed background shorthand syntax
fantasai: I'm strongly in favor of my proposal over Brad's
fantasai: I really don't want to use a slash unless it's absolutely
necessary, and it's not necessary here
Daniel: From a parsing point of view the slash is very ugly
some argument about syntax
dbaron: I would note that the initial values of the two properties
are different
fantasai: yeah, we know that. Imo it's a bug in the spec that it's
now too late to fix
Further discussion deferred to later
Meeting closed.
Received on Friday, 19 March 2010 00:00:02 UTC