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

[CSSWG] Minutes TPAC Tue 2012-10-30 AM I: Abstract Directions, Transforms, Transitions

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 13 Nov 2012 22:58:08 -0800
Message-ID: <50A34100.1070707@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Abstract Directional Terminology

   - RESOLVED: Revert block-axis directions head/foot back to before/after
               (revert earlier decision); WG may however consider other terms.
   - RESOLVED: Use over/under terms instead of above/below for
               text-underline-position, text-emphasis-position,
               consistent with text-decoration (overline vs. underline)

Transforms (cont.)

   - More discussion of 2D interpolation
   - Brief discussion of stereo vision


   - RESOLVED: Clarify that none, inherit, and initial are not allowed at
               any position within the list for 'transition-property';
               such a declaration is syntactically invalid
   - RESOLVED: Animations of colors are in pre-multiplied space.

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

(general discussion about agenda and I18N people unpingable)

Abstract Directional Terminology
Scribe: Bert

   <dbaron> http://dev.w3.org/csswg/css3-writing-modes/#abstract-box
   fantasai: We have issue in writing mode spec about terminology.
   fantasai: Two sets of abstract terms: flow-relative and line-relative.
   fantasai: Flow-relative: start/end is in inline axis
   fantasai: Line relative (line-left, over, etc. ...)

   fantasai: longstanding issue about confusion figuring out which of
             start/before end/after were which.
   fantasai: Sylvain also raised issue about confusion with :before and :after.
   fantasai: :before and :after pseudo-elements are along document order axis.
   fantasai: Could be any axis, depending on display model.
             E.g. flex layout can choose any axis for document order
   fantasai: break-before/break-after properties also use before/after
             along DOM axis. Corresponds to block axis for blocks, but
             if we extend to inlines will operate on inlines.
   fantasai: Speech uses before/after. too. It only has one axis, though.

   howcome: We also need inside/outside for paged media.
   SteveZ: relative to spine of 2-page spread.

   fantasai: We tried to come up with better terms than before/after
   fantasai: thead/tfoot similar to head/foot terms.
   fantasai: But feedback on list was that it was confusing.
   fantasai: E.g., Japanese uses "line head" for start of line.
   howcome: N E S W ?
   fantasai: In bidi, E/W would switch. even more confusing.
   Rossen: prefix with box-?
   fantasai: Avoid too long words.

   fantasai: Some places where these terms could be used:
   fantasai: grid-start, margin-start, border-start-?-radius...

   fantasai: Arron and I went through the thesaurus last night:

   SteveZ: When I first asked if head/foot fit Japanese, I was told yes.
           Now it turns out it doesn't
   fantasai: Japanese is somewhat inconsistent on this point.
   SteveZ: That is the audience we target. has to be logical for them.

   fantasai: Grid is logical, so these terms will be used by everyone.
   bert: No, for me grid is physical.
   TabAtkins, glazou: no grid is logical

   SteveZ: [something about DOM order]
   SteveZ: People learn the terms after a while.
   SteveZ: Unless the terms are significantly better, there is not much
           reason to change.
   SteveZ: Head&foot seem not optimal for the intended audience.
   howcome: I keep mixing them up.
   howcome: Just arbitrary.

   SteveZ: It *is* arbtrary.
   howcome: Pre/post?
   SteveZ: : Still unclear it is block or inline.
   TabAtkins: I was convinced by before/after at first.
   glazou: It is not confusing for avg web designer
   howcome: I think it is.
   glazou: Pre/post means nothing.
   peter: :before could be in line *or* block direction.
   glenn: I had to memorize, but then had no more problems.
   howcome: 'block-start'/'block-end'
   arron: Gets long for border radius
   howcome: don't need it there
   SteveZ: I'm not convinced. All neutral words have the pb that they
           don't say block/line.
   SteveZ: It probably doesn't matter. As Glenn said. you memorize it.
   SteveZ: Add extra words is not worth it.
   Bert: In the Box model I proposed using A, B, C, and D sides.
   fantasai: That doens't work well witht he grid.
   SteveZ: I'd just reverse to with before/after
   TabAtkins: I'd prefer head/foot.
   SteveZ: All uses of before/after are in DOM order.
   glazou: We do this for i18n

   glazou: No consensus.
   glazou: So stick with before (for top) and after for (bottom), is that it?
   SteveZ: Go back to before/after.
   koji: Proposal last May.
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2012May/1149.html
            has a resolution to change to head/foot
   koji: It was resolved and raised again.

   arronei: webkit uses before/after
   TabAtkins: with prefixes
   TabAtkins: There is next to no usage of it, in our surveys.
   peter: No real user feedback

   koji: Talked to r12a and he said like stevez, if terms improved over
         before/after then OK, but head/foot didn't seem to improve.
   TabAtkins: If before/after are half acceptable, then why not pre/post
   fantasai: before and after confuses with DOM order.
   [Tab and fantasai talk about ease of wording spec prose]
   TabAtkins: I think pre/post is reasonable, in my attempts.
   glenn: If you use both XSL and CSS,
   glenn: new terms will be confusing.
   dbaron: XSL FO won't be in Mozilla...
   TabAtkins: On the web almost no uses of the terms.
   SteveZ: Audience is not just web authors.
   peter: That argument isn't solving any pb.

   SteveZ: I propose we agree to drop head/foot and leave open what the
           terms are going to be.
   glazou: Steve's seems acceptable for now.
   RESOLVED: head/foot are not the terms (revert earlier decision),
             that doens't say anything about other terms.

   fantasai: Some properties use line-relative direction.
   fantasai: 'text-underline-position', 'text-emphasis-position', and 'ruby-position'
   fantasai: Should I use over/under there?
   fantasai: currently using above/below
   SteveZ: In vertical, those terms don't make much sense.
   Tab: over/under seems fine to me.
   Peter: We alrady have over/under in text-deco, good to not add more terms.
   RESOLVED: Use over/under terms instead of above/below for
             text-underline-position, text-emphasis-position

   SteveZ: ascender/descender go "up" and "down"
   SteveZ: but what about for upright orientations? which is which?
   Peter: Text rotation, what is over/under?
   fantasai: Stays on same side
   SteveZ: Probably needs some clarification.

CSS Transforms (continued from yesterday)

   <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17433
   Dirk: Issue about how do 3D transforms in 2D context.
   Dirk: Do we need to specify it or is it obvious, mathematically?
   Dirk: Can we ask the implementers?
   dino: Looking at last comment in the bug.
   dino: You're asking if we need to define what flatten means?
   dirk: Yes, is it not obvious enough?
   dino: No, I think it is not.
   dino: Rendering into 2D texture and that is composited.
   dino: Perspective property sets up the coord system.
   dino: I think you should take an action to define it.
   dbaron: Roc or mattwordrow would know, I'm not the best person.
   dino: Probably we all do the same thing, but still worth defining.
   Dirk: It seems an implementation detail, but I'd like some doc that
         describes how it works.
   dino: I can also take an action to try and write it up.
   ACTION dino: propose wording how you flatten 3D subtree into
          normal CSS 2D rendering.
   <trackbot> Created ACTION-515

   dirk: Other issues are editorial and we already have actions.

   dirk: Remaining is unmatrix stuff.
   dino: We can do it offline.
   dino: We all want it to look correct and the same.
   dino: We just need to know why Mozilla did it differently.
   dirk: I'd like to ask for LC in about 4 weeks, depending on whether
         these last issues are solved.

   Dong-yong lee: we're looking in to stereo display.
   Dong-yong lee: Has anybody in the group thought about that?
   dino: Would you make 2D objects appear in 3D, or only the existing 3D
   Dong-yong: The latter.
   dino: Should be possible for most content, just slightly different
         transform for the two views.
   dino: the 3D isn't a realistic 3D, strange perspective distances, etc.
   Dong-yong: We tried, and we can render many interesting 3D transforms
              quite nicely.
   Dong-yong: E.g., on 3D TV.
   Dong-yong: But we want some correct or nice way or some specification
              for doing it.
   Dong-yong: We are not sure if it is a good idea how/whether to display
              in 3D.
   dino: Some extra properties in CSS?
   dong-yong: Maybe
   dirk: I'd like to read the proposals on the m-list. Don't want to
         add complexity right now.
   dirk: Maybe next version.
   glazou: We need to publish this version as soon as possible.
   glazou: But interesting for next version.
   dino: Can Dong-Yong send a proposal/idea to m-list?
   Dong-yong: Yes, I can write it. We don't necessarily propose a solution.
   glazou: We need your input, with or without proposal.
   dino: Yes, the background info is as important as the proposal.
   dong-yong: The extension should be minimal. And all 3D content should
              also display on a 2D display.

   glazou: So a few edits base done today/yesterday, and then ask for LC?
   dino: Dirk said within 4 weeks we'll ask.
   [Discussion about agenda]


   Topic: Reversing Interrupted Transitions
   dbaron: Does IE implement something for that?
   dbaron: E.g., on hover, and then the hover ends, do you moves back
           at same speed or in same duration?
   dbaron: There were 2 proposals.
   dbaron: Dino's proposal and my impl in Gecko.
   dbaron: I prefer mine.
   dbaron: Is it a good idea to discuss it now? Or just figure out a way
           to move forward on the issue?
   Tab: I wanted to write up examples, but I never did.
   dbaron: Wait for tab's stuff?
   dbaron: The issue was knowing what it looks like in practice.
   <florianr> On transition reversal, I believe that we had concluded
              in a previous f2f (paris or hamburg) that next level could
              introduce a new property to switch between the various
              possible alternatives, and that it made the choice less
              critical one. Whatever we pick has to be reasonable, but
              doesn't have to solve all usecases

   dbaron: Other issue:
   dbaron: We don't allow inherit and initial to be keywords in list in
           some properties.
   dbaron: Also none
   dbaron: Transition property list should never allow those keywords in
           a list, only isolated.
   RESOLVED: none, inherit, and initial are not allowed at any position
             within the list for 'transition-property'; such a declaration
             is syntactically invalid

   <dbaron> http://dev.w3.org/csswg/css3-transitions/#animatable-types
   dbaron: In section on animation of property types:
   dbaron: colors in pre-multiplied space?
   tab: I think we wanted to use pre-multiplied in all cases.
   tab Need to be consistent with gradients, etc.
   dirk: And with SVG
   dbaron: But SVG 1.1 had opacity and color on separate properties
   dino: Still has the same problem of interpolating in 4 channels.
   dbaron: Gradient says pre-multiplied.
   dbaron: Some OS's don't give you that.
   dbaron: I'd be happy with pre-multiplied.
   Rik: Prefer non-pre-multiplied.
   Rik: Better for SVG and Canvas.
   Tab: (How did Canvas end up different, I wonder...)
   Tab: Because CSS gradient has been pre-multiplied for a while.
   Dino: benefit of pre-mul is you don't gray when animating to
         transparent. And can solve it by going to rgb(...)
   <oyvind> I believe we encountered issues on the web when we did
            non-pre-multiplied transitions
   <oyvind> hovering comments on youtube looked weird, for instance

   Tab: Can add some color stops.
   Tab: But SVG is adding mesh gradients and you cannot do the same trick.
   dbaron: I feel more strongly about animations being pre-multiplied than
           about gradients.
   dbaron:. If an animation from/to transparent is ugly, that is a problem
   Rik: Transparent is black, that is the problem
   sylvaing: That's why we ended up with pre-multiplied, isn't it?
   dbaron: If you animate from green 20% opaque to 100% opaque red.
   dbaron: not the same issue as going through gray, but in
           non-premultiplied space, the green will first get deeper
           before fading.
   <leaverou> dbaron’s example http://dabblet.com/gist/3979232
   dbaron: Our SMIL anim code is using pre-mul, I'm pretty sure.
   dino: One old proposal was to transition in hsl.
   * sylvaing doesn't think author expect transparent in a transition to
              always imply going through black shades, whatever the
              normative definition of the keyword says. Makes the keyword
              somewhat useless in this context.

   dbaron: I have a test case:
   <dbaron> http://dbaron.org/css/test/2009/transitions/transitions-alpha
   tab: webkit is non-pre-multiplied.
   dbaron: FF is pre-multiplied.
   dbaron: So actually everybody is doing pre-multiplied after all.
   tab: [checking]
   lea: Did FF change?
   dbaron: No, we always did.
   dino: So we all do the same. Let's specify it.
   tab: Yes, chrome does pre-multiplied, too.
   [dbaron adding a test]
   RESOLVED: Animations of colors are in pre-multiplied space.
Received on Wednesday, 14 November 2012 07:05:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:23 UTC