- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 17 Oct 2012 15:50:26 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Discussed forwards-compatible parsing rules for @supports
- RESOLVED: Accept the proposed rules (below) for line decoration
averaging, but change line-throughs to recalculate
whenever computed 'font-size' changes.
- Status update on UTR50
- RESOLVED: Publish Grid Layout WD
- Discussed agenda for TPAC
====== Full minutes below ======
Present:
Tab Atkins
David Baron
Ryan Betts
Bert Bos (late)
Tantek Çelik
Kenneth Christiansen (Intel)
Arron Eicholz
Elika Etemad
Simon Fraser
Sylvain Galineau
Koji Ishii
John Jansen (late)
Peter Linss
Alexis Menard (Intel)
Edward O'Connor (late)
Anton Prowse
Simon Sapin
Dirk Schulze
Alan Stearns
Leif Arne Storset
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2012/10/17-css-irc
<SimonSapin> the conf call changes timezones next week, right?
<kenneth> oh?
<Zakim> +SimonSapin; got it
<SimonSapin> I think it’s noon Boston time, but there is a DST change
Agenda: http://lists.w3.org/Archives/Public/www-style/2012Oct/0459.html
Scribe: fantasai
plinss: Additions to agenda?
CSS3 Conditional Rules
----------------------
...
fantasai: If we're treating unknown things as false, we should treat
more things that are unknown as false
fantasai: e.g. right now anything that doesn't parse as a declaration
inside parens will make the whole rule invalid
fantasai: Would be more consistent to make that false also.
dbaron: I think that's fine, why would we want anything else in there
dbaron: We are making functional notation the way for future extensibility
fantasai: Are we sure that's how we want to do it? Did we have that
discussion.
dbaron: Yes, that was why we're doing it this way.
[...]
fantasai: So, the bare parentheses is in effect a functional notation
(without a name) that accepts property declarations
fantasai: If the contents are not a property declaration, the entire
rule is invalid
fantasai: Whereas for other functions right now, regardless of what
they contain, they're as false, and do not make the entire
thing invalid
fantasai: However, suppose we introduced a function in the future that
took xyz production.
fantasai: If a stylesheet contained that function with invalid contents
fantasai: If we followed the same pattern of making the entire rule
invalid because the contents don't parse correctly
fantasai: That would mean that old UAs would treat it as false, but
new UAs would make the entire rule invalid.
<SimonSapin> fantasai: good point
TabAtkins: Functional notation is false no matter what it contains
fantasai: My point is, either you are getting the different behavior
between old/new UAs that I explained OR you are treating the
invalidation rules of bare parens different from functional
notations, which is inconsistent.
dbaron: It's a bit complicated, because the contents of a parentheses
could either be property declaration or be a logical clause
dbaron: I'm okay either way
TabAtkins: I'd like to think about this a bit
dbaron: But it would require redoing a bit of our implementation.
But if we decide it's the right thing, we'll do it.
Text Decoration
---------------
<stearns> http://lists.w3.org/Archives/Public/www-style/2012Aug/0379.html
http://dev.w3.org/csswg/css-text-decor-3/#text-decoration-line-property
| In determining the position and thickness of text decoration lines,
| user agents should first determine an "ideal" size and position for
| every decorated fragment on the line, then position the decoration
| as follows:
|
| overlines (and over-positioned underlines)
| Position the line with respect to the highest over content edge
| of the decorated boxes.
| alphabetic underlines
| Position the line to an average of the ideal underlines of the
| decorated boxes, ignoring any boxes with non-initial ‘vertical-align’,
| but below the lowest alphabetic baseline considered.
| non-alphabetic underlines (and under-positioned overlines)
| Position the line with respect to the lowest under content edge of
| the decorated boxes.
| line-throughs
| Position the line to an average of the ideal line-throughs of the
| decorated boxes, ignoring any boxes with non-initial ‘vertical-align’.
| However, if this would place a line-through outside the middle third
| of a decorated box's content box, break the line-through, treating
| the line-through of that box and its descendants as an independent
| decoration for the purpose of determining the line's position and
| thickness.
fantasai explains the proposal
fantasai: We're looking for feedback
smfr: Our engineer prefers the behavior to be the same as the system
text in OSX
smfr: It's less complicated than this.
smfr: Takes the thickest underline, and [position]
smfr: An underline with a superscript or subscript span inside of it,
the underline remains at the baseline, doesn't jump up
smfr: That means subscript can draw on top of underline, and that's
okay I think
smfr: No way for strike-through to be consistent on MacOSX -- it
jump around with the font size
smfr: Didn't test overline. Don't think we have it
fantasai: One option I was considered was for strike-through to shift
when the font-size changed, but not when the font changed.
fantasai: When you have different fonts in the same size, you can get
very different metrics because relationship of baseline to
embox is different in different fonts
smfr: The strike-through shifts around with the font, even if the size
is constant
dbaron: How do you combine that with the features in CSS3 Text that
allow underlining various things that aren't text?
smfr: No idea
<dbaron> (actually, I think to answer my own question: just use the
element's font metrics, even if it's not text)
dbaron: Assume the first font you have is the one you're using, and
use its metrics
szilles: My concern is mixing Chinese and English text, will the
strike-through be reasonable
szilles: e.g. Latin-only font for English, CJK font I only use for the
Chinese
<arronei> Example case: http://test.csswg.org/source/contributors/microsoft/incoming/text-decoration.htm
fantasai: I think it's important that we not shift the line as the
font changes. That's been a principle we've adhered to
in all our text-decoration discussions in CSS
fantasai: The reason why we've always insisted on one line
smfr: Think overline should shift with the font sizes
smfr: ...
fantasai: The problems you have with overlining would apply to underlines
if the dominant baseline were not alphabetic, e.g. using
central baseline
TabAtkins: Mac's system text underline already does averaging stuff
TabAtkins: line-through is jumpier than we'd like, should be made not
jumpy across font changes
TabAtkins: can't use it for overlines anyway
szilles: Say I'm typing this stuff in. If I put a strike-through in it,
would it move?
TabAtkins: [...]
fantasai: So, we're going to go with this, except line-throughs will
recalculate whenever 'font-size' changes, but not when
font face changes
fantasai: One thing to be careful of -- the font-size-adjust property
effectively changes the font size, but its intention is to
equalize the visual font sizes across various font faces
fantasai: We should only key off computed 'font-size'
smfr asks about alphabetic underlines not responding to subscripts
fantasai points out we're skipping any boxes that have different
vertical-align
smfr: If a line of text has two separate inline boxes, separated by
some non-underlined text, would the lines have to be consistent?
TabAtkins: No, it's only consistent if the underline originates from
the same decorating box
smfr: ...
smfr: you want to avoid the underline jumping around through editing
operations
TabAtkins: I think we should say it's up to the editing tool, to merge
underlining elements
TabAtkins: underlining from different elements can be different colors
[...]
TabAtkins: Could do averaging across line box, rather than just within
fragment
szilles: why would you necessarily want that?
szilles: if I do make a font size change, and want the underlines to
be different
szilles: fact that they land on the same line shouldn't make them be
the same
szilles: Also, this way if someone really wants ransom-note effect,
can get it by making different elements
szilles: whether two elements are on the same line or not shouldn't
matter
<dbaron> (agreement with szilles)
TabAtkins: Ok, so we need to to revisit text to clarify it
fantasai: and change the line-through behavior
koji asks about why overline would be under / underline would be over
fantasai: If we have text-underline-position: above;
fantasai: This puts the underline on the over side
TabAtkins: in vertical text
fantasai: That would put the underline and overline on the same side,
so we made overline also switch sides
koji: I thought we weren't doing that
"If this causes the underline to be drawn on the "over" side of the
text, then an overline also switches sides and is drawn on the
"under" side."
fantasai: This way if you say 'text-decoration: underline overline',
you will get lines on either side of the text regardless
RESOLVED: Accept the proposed rules for line decoration averaging,
but change line-throughs to recalculate whenever computed
'font-size' changes.
UTR50
-----
koji: Status is UTR#50v6 is supposed to be published
koji: In the UTC rules, file is there, but it's not official
koji: I'm requesting Eric to make it published, but not getting a response
koji: I am preparing v7, it's still in review
koji: For v7, I own the text part, but the data is co-owned with Laurentiu
from MSFT
koji: data part is late, b/c he was off for a bit
koji: ... text part, data part later
koji: That's the status
Grid Layout
-----------
<PhilCupp> http://dev.w3.org/csswg/css3-grid-layout/#changes-from-previous-version
plinss: Request to publish updated WD
PhilCupp: We haven't published in a while
* glazou agrees with that
PhilCupp: There were 3 batches of changes, don't change anything
conceptually, but syntactic things that we agreed to
PhilCupp: Want to get a WD out before starting to work on integrating
plinss's approach
plinss: I'm fine with that
<SteveZ> I am fine with that also
RESOLVED: Publish
plinss: Plans for moving forward?
PhilCupp: Will be in touch with Tab and fantasai to figure out what
changes we want to make
TabAtkins: I'll be working on it
plinss: Will you be at TPAC?
PhilCupp: No, can call in though
TPAC
----
plinss: BTW, our agenda looks light. Please add things to the wiki
plinss: If have more notice ahead of time, can plan schedule better
<Bert> (pointer to wiki page?)
plinss: Also there's a W3C developer meetup on Monday night
<plinss> http://www.w3.org/2012/10/TPAC/meetup-Lyon.html
plinss: If you want to go, register soon
http://wiki.csswg.org/planning/tpac-2012
Topic: SVG Property review
<smfr> http://lists.w3.org/Archives/Public/www-style/2012Sep/0225.html
dbaron: Has anyone else looked at them?
TabAtkins: I have
TabAtkins: Just had some small comments
dbaron: I wanted to look at something specific, but forgot what it was
sylvaing: Was it painting order naming?
sylvaing: I thought it was awkward too, but had no proposal to revise it
dbaron: Maybe say we're not quite comfortable with that naming, but
don't have a new proposal
<SteveZ> +1 for WG position
fantasai: seems like the WG as a whole has this opinion, so maybe send
that as a WG opinion
plinss: Ok, I'll send that feedback on behalf of the WG
Logical Directions
------------------
koji: before/after vs. head/foot
koji: Problem is i18nwg will discuss at TPAC on this topic, and hope to
come up with a resolution as a WG
koji: Since CSSWG is before i18nwg conference, I recommended individuals
in the i18nwg to send comments earlier
plinss: Daniel requested a joint meeting with i18n at TPAC
plinss: Don't know if that will happen
koji: Not sure if Addison wants to make this a joint topic
Meeting closed.
Received on Wednesday, 17 October 2012 22:50:54 UTC