W3C home > Mailing lists > Public > www-style@w3.org > October 2012

[CSSWG] Minutes Telecon 2012-10-17

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 17 Oct 2012 15:50:26 -0700
Message-ID: <507F3632.70500@inkedblade.net>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:01 GMT