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

[CSSWG] Minutes Telecon 2012-10-02

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 04 Oct 2012 08:11:39 -0700
Message-ID: <506DA72B.3000808@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Summary:

   - Test the Web Forward registration is now open for Paris (26-27 Oct 2012)
       http://testtwfparis.eventbrite.com/
   - RESOLVED: the three profiles (TV, Mobile, Print) will be moved to Notes
   - Discussed case-sensitivity of user identifiers
   - Discussed splitting transform-origin into x/y/z sub-properties
   - Discussed making fixedpos elements always form stacking contexts
   - Discussed position of text decoration over font size changes
   - Reminder: @supports going to LC next week unless ppl find blocking issues.
               So don't forget to review!!

====== Full minutes below ======

Present:
   César Acebal
   Rossen Atanassov
   Tab Atkins
   Ryan Betts
   Bert Bos
   Arron Eicholz
   Katie Ellison
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Koji Ishii
   John Jansen
   Edward O'Connor
   Anton Prowse
   Simon Sapin
   Dirk Schulze
   Alan Stearns
   Leif Arne Storset
   Steve Zilles

Regrets:
   David Baron
   Rebecca Hauck
   Peter Linss
   Lea Verou

<RRSAgent> Logging to http://www.w3.org/2012/10/03-css-irc
Agenda: http://lists.w3.org/Archives/Public/www-style/2012Oct/0052.html
Scribe: antonp


Test the Web Forward
--------------------

   <stearns> http://testtwfparis.eventbrite.com/#
   stearns: Registration of the event is now open; please evangelize!

TV/Mobile/Print Profiles
------------------------

   glazou: Bert raised this, but he's not on the call
   glazou: Bert suggests moving these specs to Note status, since they're
           going nowhere.  I think it's reasonable
   Tab: I agree
   fantasai: I strongly agree
   fantasai: We have to update all the references, though
   glazou: a Note is informational. It's not a Rec track document
   Rossen: What does it take to put a doc on the Rec track again?
   glazou: it can come back, but  with the usual administrative overhead
           of any other REC track doc
   glazou: we're not changing the contents of the doc
   sylvaing: will the URL change?
   glazou: I will discuss with Bert.  We still want the same URLs, but
           perhaps they could redirect elsewhere or else a notice
           describing the move
   fantasai: I don't think it'll be a problem. Switching the snapshots
             from REC-track to NOTE wasn't a problem.
   glazou: No objections?
   RESOLVED: the three docs (TV, Mobile, Print Profile) will be moved to Notes

Case sensitivity of user-defined identifiers
--------------------------------------------

   <glazou> http://lists.w3.org/Archives/Public/www-style/2012Sep/0535.html
   TabAtkins: a blocking issue remains on the drafts
   [Tab explains the issue]
   TabAtkins: At a minimum, Need to make User-Defined Identifiers (UDIs)
              ASCII case-insensitive, the same as Language-Defined
              Identifiers (LDIs)
   [Tab explains]
   fantasai: Unicode provides case-folding algorithms
   fantasai: Option 1: ASCII-only folding; confusing for users
   TabAtkins: but it's consistent with how HTML works
   TabAtkins: getElementById method, IDs are case-insensitive
   TabAtkins: in the ASCII range
   TabAtins: it's a legacy constraint
   TabAtkins: they do show up in UDIs
   TabAtkins: Option 2: Latin-based case insensitivity
   TabAtkins: Option 3: some hybrid
   glazou: When you refer to Latin, do you refer to the space or to the
           characters.  They're not the same
   fantasai: we could do the full set of Latin characters, but not any
             other script
   glazou: so the space; é is one single glyph
   glazou: we should be aware that é can be formed in several different ways
   fantasai: there's lots of discussion recently; not sure we can close
             the issue; I18N  needs to comment
   fantasai: would be a good F2F issue for joint groups
   glazou: needs more investigation than only CSSWG; touches many areas
   ACTION: TabAtkins to e-mail I18N
   glazou: would like dbaron and howcome to be involved
   ACTION: glazou to schedule a joint meeting with I18N
   <trackbot> Created ACTION-510

<Zakim> +Bert
<Zakim> +krit

Anti-aliasing on Mac
--------------------

   <glazou> http://lists.w3.org/Archives/Public/www-style/2012Oct/0014.html
   * fantasai thinks this is a topic that requires jdaggett
   TabAtkins: it's font-hinting, not anti-aliasing
   TabAtkins: native font engine makes the characters fatter than they
              appear elsewhere eg Win/ Linux
   * sylvaing has always been told Macs ignore font hinting instruction
   TabAtkins: in some situations we can't do proper hinting, eg in rotated
              text or 3D
   TabAtkins: Switching between the two causes a drastic visual change
   TabAtkins: I need to figure out what other folks are doing for the Mac
   TabAtkins: Should this be an issue for the WG?
   TabAtkins: Which solutions have others come up with?
   TabAtkins: I'd like to know
   Leif: I started looked into it, but haven't got feedback yet
   TabAtkins: OK, I'll take it up again next week
   Bert: I understand there's a problem, but are you looking for a solution
         from WG?
   TabAtkins: Don't know; would like to hear from other implementers to
              understand whether this is something our team can fix on
              our own with a proprietary extension, or whether it's a WG
              issue
   smfr: Apple is aware of the problem; not sure it's accurate to say that
         hinting is the difference.  Involves gamma correction amongst
         other causes.  We've experimented with some APIs but we haven't
         got improvements in all cases
   smfr: I don't think there's an implementation solution for this.
         Implies that maybe we need a CSS thing to fix this
   TabAtkins: I'll hold up on this topic for the moment

text-decoration
---------------

   <glazou> http://lists.w3.org/Archives/Public/www-style/2012Aug/0379.html
   <glazou> data:text/html,<!doctype html><s>foo<font size=7>bar</font>baz</s>
   glazou: raised by Aryeh Gregor
   fantasai: the strike-through will be skimming along the bottom of the
             glyphs instead of going through them; this is because we
             dictate only one position for the strike-through
   fantasai: Aryeh's solution is to put the underline wherever it's
             supposed to be... but that leads to jumping around.
             Can cause lots of jitter in cases where the font size
             change is small, or only the font face changes.
             I don't think it's a good solution
   fantasai: Best suggestion I could come up with: pick one position,
             and that position has to stay constant, unless an element's
             preferred position would be outside a 0.3em tolerance.
   fantasai: although if we only care about common cases, just small
             font size changes or immediate nesting like in Aryeh's
             case, the position-averaging recommendation in the spec
             would be enough. It's only large font-size mixes that
             need something like what I suggested.
   glazou asks about word processors
   fantasai: MS Word changes the position of the underline with every
             change in font styling and vertical align switches
   glazou: yep, I just tried in Word on Mac
   SteveZ: I support your position that the underline ought to be
           calculated for the whole stretch... but how much is the
           strikethrough problem an issue in reality
   fantasai: for people trying to use HTML as a word-processor format,
             it's a problem
   fantasai: because WYSWYG editing results in two nested elements, and
             it's a problem if the outer element is carrying the line
             and font size changes on the inner one
   glazou: the usual rendering for DEL is strike-through
   glazou: it's probably not too uncommon
   TabAtkins: Suggestion is reasonable
   SteveZ: It'll be hard to get interop, so bugs would be filed
   fantasai: I don't think the threshold would handle vertical alignment
             though.  I think you'd have to ignore vertical alignment
              when doing these things

   fantasai: One of the problems with an overline is that if the font-size
             increases then the overline looks like a strike-through
   fantasai: need intelligent averaging
   fantasai: the problematic case seems to be immediate nesting; that
             case is solved by averaging
   glazou: What about overline?  The original usecase?
   fantasai: the overline looks like a strike-through, which is a problem
   glazou: what do you want to overline? the whole element, or the
           characters inside?
   glazou: Is there one overline for the whole thing, above the highest
           thing?  Or one per sub-element?
   fantasai: neither.  If the elements don't change size much; you want a
             common line.  If there is, then the line should break
   glazou: I tend to agree with the proposal
   TabAtkins: yes
   fantasai: So, how do you implement and test the proposal?
   TabAtkins: I don't see the problem. [...]
   SteveZ: Must define it with an understanding that there can be hanging
           fonts
   TabAtkins: definition should be relative to the baseline, so that in a
              centred font the line would go through the centre
   SteveZ: this is a trigger that says that we'll break sequences of
           lines when the difference is bigger than a threshold
   <stearns> I think any automatic behavior is going to be inadequate.
             underline-offset and underline-weight, etc. would be the
             way to solve this
   <fantasai> stearns, a fixed offset won't help here
   smfr: I haven't looked into this much
   glazou: do folks want a week more to look into this
   <fantasai> ACTION fantasai: write this up, with examples
   glazou: topic deferred to next week.

stacking contexts for position:fixed
------------------------------------

   <glazou> http://lists.w3.org/Archives/Public/www-style/2012Oct/0000.html
   sylvaing: should position:fixed elements create a stacking context?
   sylvaing: Microsoft are unconvinced about compat; reluctant to make a
             change
   * fantasai notes that this is a request to change for CSS2.1

   TabAtkins: on mobile this happens, because fixpos is hard on mobile
              and this simplifies it
   Tabatkins: easier to optimize scrolling on our mobile browser, if
              stacking context formed.
   sylvaing: I'd like to see what makes you believe that.  And are the
             sites in question designed for mobile web or for *webkit*
             mobile web?
   sylvaing: fixpos is a mess, so people relying on it doesn't tell us
             too much
   TabAtkins: the scrolling people tell me this change would help
   smfr: I implemented it on iOS and on desktop Safari.  The proposed
         change makes implementation much easier
   sylvain: so because it helps Webkit, we should adopt this change for CSS?
   smfr: well, yes... we didn't find any big compat problem.  Google
         also did some research and didn't find compat problem either
   smfr: I think it's a reasonable change
   TabAtkins: It's bizarre to interleave into a fixpos element
   TabAtkins: we think it's a reasonable change
   <SimonSapin> +1 for this change, it makes implementation (and thus my
               job) much easier. But I don’t know about web compat.

   krit: is this change in current versions of chrome?
   smfr: no desktop Chrome or Safari has released this yet.
   TabAtkins: we've got Canary builds with this thing in
   smfr: the sites that were broken are mostly Google properties
   TabAtkins: and in those sites we didn't /need/ the behaviour which
              was breaking; it was accidental and we could work around
              the breakage
   glazou: I haven't heard general agreement about this change
   sylvaing: need more research
   TabAtkins: I'll provide examples

   Rossen: The overall intention doesn't seem crazy.  But I would like
           to know what the damage would be across both mobile /and/
           desktop
   <lstorset> +1
   Rossen: please provide examples
   Rossen: then we can make a group decision
   TabAtkins: this change would also affect stickypos

   antonp: Does the stacking context section of CSS2.1 explicitly
           distinguish between abspos and fixedpos?
   antonp: fixedpos is considered abspos in most parts of CSS2.1
   TabAtkins: issue is that abspos doesn't create a stacking context
              necessarily
   TabAtkins: The issue is fixpos with z-index:auto - we want /that/
              to form a stacking context
   * Bert : thanks for that q Anton, now the issue finally makes sense :-)

transform-origin-x/y
--------------------

   <glazou> http://lists.w3.org/Archives/Public/www-style/2012Sep/0549.html
   krit: Boris noted that apparently WebKit implements transform-origin-x
         and transform-origin-y  properties.  Should these be in the spec,
         perhaps?
   TabAtkins: I think it's a reasonable set of properties
   smfr: we should be consistent with properties which reference points
         and offsets, which don't have separate x/y properties
   fantasai: in the case of background-position, where we have keywords,
             it's hard to split it out
   fantasai: especially if we accept to add logical keywords, which i18n
             has been requesting for a long time and which we deferred
             to level 4
   fantasai: transform-origin properties don't accept keywords so don't
             suffer from the awkward issues
   <sylvaing> x/y/z longhands is kind of natural for animations
   TabAtkins: We don't want to do logical coordinates for transform-origin.
              Unlikely.
   TabAtkins: so, webkit already does this

   Bert: What is the use case?  Yet more properties.. are they useful?
   ?: Easier to animate when split up
   fantasai: I can see wanting to animate axes separately for transforms
   fantasai: Definitely would want that to be easier
   fantasai: but for transform-origin, seems unlikely to be popular
   Sylvain: Could be fun to transform the origin, but yeah, not as common

   sylvaing: Are there other places where we'd want to split this
   smfr: perspective-origin
   glazou: is there any objection from vendors?
   sylvaing: do we do this only for origin?  Why not other properties?
   TabAtkins: it's definitely the only place in /transforms/
   smfr: no, there's perspective origin
   <smfr> http://www.webkit.org/blog-files/3d-transforms/perspective-by-example.html
   Bert: what's that for
   TabAtkins: If you want to spin around the DOM structure:
                a) move the perspective origin (camera) or
                b) move everything else.
   TabAtkins: (a) is easy
   * fantasai defers to dbaron on this issue
   * fantasai is not qualified to comment on behalf of Mozilla
   * sylvaing is not qualified to comment on behalf of Mozilla either
   glazou: the possibilities opened seem to be cool, but I need more than
           that to make a resolution
   fantasai: I'd like to defer until dbaron has commented
   fantasai: Wrt animations, seems more important to make transform itself
             easier to animate, rather than split up transform-origin
   glazou: OK, perhaps defer to F2F

Reminders
---------

   glazou: 5 mins left. Anything else?
   fantasai: Prioritization of specs
   glazou: I started aggregating the data. Today I got the answer from W3C.
           I didn't finish (I was sick for a while)
   glazou: I'm still missing a few people
   glazou: you know who you are ;-)

   fantasai: Reminder that we're planning to take css3-conditional to LC
             next week

Meeting closed.
Received on Thursday, 4 October 2012 15:12:20 GMT

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