- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 15 May 2013 17:42:17 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: publish LC of css3-fonts (next Thursday)
- RESOLVED: split Exclusions and Shapes into separate modules
- Republication of Multicol deferred until more issues can be resolved.
- RESOLVED: publish new WD of CSS Filters
- RESOLVED: @counter-style width descriptor renamed to pad (counter styles)
- RESOLVED: decoration color is reflected in text-shadow
- Discussed dbaron's issues wrt text-decoration positioning
- RESOLVED: calc() can be used inside media queries
- Discussed return value of getComputedStyle() for grid layout properties
- Discussed an+b syntax redefinition in css3-syntax
====== Full minutes ======
Present:
Glenn Adams
Rossen Atanassov
Shezan Baig (Bloomberg)
David Baron
Tantek Çelik
John Daggett
Justin Erenkrantz (Bloomberg)
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Koji Ishii
Dael Jackson
John Jansen
Brad Kemper
Peter Linss
Anton Prowse
Matt Rakow
Dirk Schulze
Alan Stearns
Leif Arne Storset
Nick Van den Bleeken
<RRSAgent> logging to http://www.w3.org/2013/05/15-css-irc
Scribe: sgalineau
CSS3 Fonts
----------
Topic: css3-fonts publication
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013AprJun/0161.html
jdaggett: I'd like to move to LC. I think we can resolve the italics
issue at the f2f
jdaggett: I'd rather discuss LC issues at the f2f a few weeks from now
jdaggett: I responded to text-decoration issues; I am not sure whether
Elika wants to resolve this first
fantasai: I am ok to go to LC based on John Hudson's response
fantasai: I think there is an interaction we need to resolve; LC is fine
if the italics issue is noted
jdaggett: it is noted
fantasai: Would suggest waiting until next week to publish; still have
to finish review comments, would be good to incorporate such
minor fixes before publishing LC.
RESOLVED: publish LC of css3-fonts (next Thursday)
<stearns> +1 from me
Exclusions and Shapes
---------------------
Topic: Splitting Exclusions and Shapes
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013AprJun/0171.html
astearns: we discussed this a number of times in the past. they are
separate features with separate use-cases; they should advance
more quickly if they are not tied to each other
Rossen: +1
glazou: +1
fantasai: no objection
glenn: does this involve new editors?
astearns: no change expected at the moment
RESOLVED: split Exclusions and Shapes in separate modules
astearns: I will come back next week and ask for WD publications for both
CSS Regions WD
--------------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013AprJun/0177.html
astearns: this is just a WD update; the current one is 9 months old
glazou: I support this; there have been quite a few changes
bradk: I did not like the move from @region to a pseudo-element
bradk: I think this is a big change
rossen: I would like another week to review this
astearns: ok, let's do this next week.
dbaron: would prefer 2 weeks
glazou: action on everyone to review Syntax two weeks from now
* fantasai notes that Gecko Layout team has a work week next week
<glazou> http://lists.w3.org/Archives/Public/www-style/2013May/0232.html
Multi-col
---------
<glazou> http://www.w3.org/mid/20876.36468.730367.345119@gargle.gargle.HOWL
glazou: should we go back to LC given the latest changes?
fantasai: it would be good to review these changes in detail, specifically
the painting order update; someone posted that it was wrong.
rossen: I also have a couple of updates; one is the drawing order of
rules resolved in Tucson
rossen: also multicolumn columns creating their own BFC, which we
discussed last week
rossen: so going back to LC seems reasonable
antonp: I think other issues need addressing; I support LC as well
fantasai: we should try resolving these before publishing LC
CSS Filters WD
--------------
krit: I added feedback to the security section indicating there is
pending work; I would like to publish a new WD
glazou: do not forget to add a change section to your documents
RESOLVED: publish new WD of CSS Filters
Counter Styles
--------------
fantasai: there was a discussion to rename the width descriptor to 'pad'
fantasai: this is the only issue raised thus far; we would like to
resolve this and move to LC
<stearns> http://lists.w3.org/Archives/Public/www-style/2013May/0037.html
<fantasai> http://dev.w3.org/csswg/css-counter-styles/#counter-style-width
jdaggett: can we hold this one more week for additional review?
fantasai: ok
glazou: objections to the proposed renaming?
RESOLVED: width descriptor renamed to pad (counter styles)
Text Decoration
---------------
fantasai: some of these might be better dealt with face-to-face
<fantasai> http://dev.w3.org/csswg/css-text-decor-3/issues-lc-2013#issue-15
fantasai: we discussed this one last week and did not resolve it
fantasai: I have no opinion
glazou: what do browsers do?
fantasai: they do not interop
glazou: I do not have an opinion
dbaron: I have a slight preference for repeating the color of the
decoration in the shadow
RESOLVED: decoration color is reflected in text-shadow
jdaggett: I think we can defer the super/subscript discussion to next
week or the f2f.
jdaggett: I have no opinion on the other issues on the agenda
<fantasai> http://dev.w3.org/csswg/css-text-decor-3/issues-lc-2013#issue-11
fantasai: issue 11 is about whether line position should be per-line
or across lines
<fantasai> http://www.w3.org/TR/CSS21/text.html#lining-striking-props
<fantasai> "In determining the position of and thickness of text decoration
lines, user agents may consider the font sizes of and dominant
baselines of descendants, but must use the same baseline and
thickness on each line."
fantasai: what does it mean 'on each line'? does it mean that the position
is the same for all lines, or does one evaluate the position
for each line individually?
fantasai: I think the original intent was to deal with cases where the
same line included subscript, superscript, large text etc and
we wanted to avoid ransom-style underlining
dbaron: I think the intent was also to avoid position and thickness to
change between lines
fantasai: if you want a constant position across lines, you ignore all
descendants; or you consider them and account for them
fantasai: if you do the latter then for each decorating box you need to
layout all your lines to figure out the consistent position/
thickness which could be a perf concern
fantasai: if there is a perf concern we could scope the averaging to
each linebox
fantasai: or we ignore descendants
fantasai: but without considering the descendants strikethrough may break
jdaggett, dbaron: varying underline/decorations between lines does not
sound like a good idea for authors
dbaron: I think considering descendants is a bad idea. it's not compatible
with what browsers do today.
dbaron: we should leave it as it is
rossen: I am in favor of keeping this as it is
fantasai: keeping the spec as it is?
rossen, dbaron: keep the runtime behavior and update the spec
fantasai: browsers do different things though
fantasai: I have a test case where Opera appears to consider descendants...
<fantasai> <p style="text-decoration: underline;"><big style="font-size: 64px">BIG TEXT</big> text <small style="font-size:
4px">small text</small>
<Rossen> http://jsfiddle.net/4sC2T/
<glazou> or data:text/html,<p style="text-decoration: underline;"><big style="font-size: 64px">BIG TEXT</big> text <small
style="font-size: 4px">small text</small>
<fantasai> http://www.w3.org/mid/CAKA+Axm4o1r_LN0Q7v_XM8WQsMNEsdsES2r6K1Lp6rzH=vHC9A@mail.gmail.com
fantasai: link above is the issue Aryeh raised
fantasai:
about strikethrough. we discussed this before,
fantasai: and resolved on the text describing averaging
rossen: our underline behavior follows Word's closely
fantasai: does this mean you have multiple decoration positions across line?
rossen: there is averaging in more recent versions
glazou: should we defer to f2f?
fantasai: yes
fantasai: most of the other issues relate to this so let's move on
<Rossen> use case to consider for the underline issue above
http://jsfiddle.net/4sC2T/1/
Flexbox
-------
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Apr/0538.html
fantasai: also better to push more flexbox issues to f2f; nothing easy
calc()
------
<glazou> https://www.w3.org/Style/CSS/Tracker/issues/327
glazou: where is calc() allowed?
glazou: in particular, whether it can be used in a MQ?
glenn: wouldn't be easier to define where it can't be used?
fantasai: we should think about all the places where it can be used and
consider examples
glazou: who will do this review? when?
fantasai: we can talk about media queries now
dbaron: media queries can't take percentages for width so this limits
its value
dbaron: but I do not object allowing calc with different units
glazou: are there use-cases for this? do authors ask for it?
fantasai: yes I think some people asked for it
glazou: I never needed it when I used MQ; I can't think of a use-case...
<stearns> @media screen and (min-width: calc(20em + 6px))
<stearns> from http://lists.w3.org/Archives/Public/www-style/2007Nov/0227.html
glazou: objection to allow calc?
RESOLVED: calc() can be used inside media queries
Grid layout
-----------
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Aug/0309.html
fantasai: we have prose about grid properties getComputedStyle; some of
them return the used value
<fantasai> http://lists.w3.org/Archives/Public/www-style/2012Aug/0309.html
fantasai: so do we want to allow getComputedStyle() to return these used
values, or should it return the computed value?
dbaron: isn't there work around CSSOM in this area? we should look at
how this interacts
fantasai: how does that change our decision?
glenn: the CSSOM uses the term resolved values for getComputedStyle();
in some cases you will get used value, in others computed value
e.g. left, top, bottom return used values
dbaron: I'm fine with the proposed resolution of returning computed values
<glenn> https://dvcs.w3.org/hg/csswg/raw-file/tip/cssom/Overview.html#resolved-values
<glenn> e.g., getComputedStyle().lineHeight always returns used value
fantasai: essentially getComputedStyle() returns used value in some
cases for legacy reasons; the issue is whether new grid
properties could require used value or should be consistent
and return computed values for all of them
* fantasai has no opinion on these things, and hopes someone else figures
out this issue
rossen: how does this work for tooling? This is the reason we returned
used values.
rossen: currently some MSFT tools use this, for instance
dbaron: I think we need to understand what your general strategy should
be, especially in light of new APIs. But I agree we do not have
a clear resolution for this specific issue
glazou: so this remains an open issue
<glenn> one resolution is to define resolved value line for each property
<sgalineau> glenn, yes but what should it be in this case?
<glenn> sgalineau: no opinion in this specific case
an+b grammar
------------
fantasai: we should not be making changes from the grammar of selectors3
glazou: I think the current discussion is extending the set of allowed
values
fantasai: right, I want to know why it can't be the same as in 3?
glazou: everyone should review this item for next week
glazou: we need to discuss this before it goes in a WD
glazou: anything else?
glazou: please add things we deferred for the f2f to the wiki
Meeting closed.
Received on Thursday, 16 May 2013 00:42:54 UTC