- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 13 Nov 2012 22:58:08 -0800
- 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
Transitions
-----------
- 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:
before/after
previous/next
lead/trail
ahead/behind
head/foot
above/below
fore/aft
ante/post
prior/next
front/rear
pre/post
early/late
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
objects?
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]
Transitions
-----------
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