- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 02 Jul 2013 22:57:14 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Parens and Escapes
------------------
- RESOLVED: MQ requires white-space on both sides of a parenthesis
- RESOLVED: Idents followed by open parenthesis must have white space
between the two unless it's a function.
- RESOLVED: String and URL types for attr() literally takes the
attribute's value without parsing; CSS escapes are not
interpreted
Alignment
---------
Tab and fantasai presented the new Alignment spec
http://www.w3.org/TR/2013/WD-css3-align-20130514/
explaining changes in design and details.
RESOLVED: Need more work on baseline section, define first-line and
last-line baseline for all things.
Transitions
-----------
RESOLVED: dbaron's proposal for reversing interrupted transitions is accepted.
====== Full minutes below ======
Reversing Interrupted Transitions
---------------------------------
dbaron: Haven't quite finished my test case
dbaron: one algorithm and one proposal implemented, still need to impl
the other one.
dbaron: in javascript
dbaron: Don't leave the page open in a tab after using it!
plinss: Let's get back to that.
White Space in Media Queries
----------------------------
SimonSapin: We had an issue in both MQ and @supports
SimonSapin describes the issue
SimonSapin: The grammar had optional white space, meaning that if you
used a comment to separate the tokens, it would be correct
SimonSapin: reader may not know this detail
SimonSapin: We changed the grammar to allow whitespace, like calc()
SimonSapin: Issue is resoled in @supports, but still exists in MQ.
We should make the same change, but we have to wonder
about compat.
dbaron: I don't worry about compat.
TabAtkins explains on whiteboard
TabAtkins: @media screen and/**/(color) — is that correct?
SimonSapin: With the current spec, and(color) looks correct, and it is not
TabAtkins: This problem applies to every ident in a parenthesis that can
be next to each other without being a function
dbaron: This is the problem with the function token
SimonSapin: Can use the function token in the grammar, but that is more
complicated. Don't want to do that.
TabAtkins: Agreed.
SimonSapin: decided not to do function tokens in @supports
glazou: Shall we adopt SimonSapin's proposal?
glazou: require white-space in MQs
TabAtkins: This will come up every time we have parentheses
plinss: As long as you have some token between, should be valid.
plinss: But want it to be consistent.
glazou: People expect it to work, because it's * in the grammar.
Bert: Can just add a comment in the grammar.
plinss: But have to do it everywhere. But I don't feel strongly about
and(color). Just want it consistent.
glazou: Why is white-space required in @supports?
TabAtkins: To avoid that removing a comment changes the meaning.
SimonSapin: @supports now requires white-space on both sides.
plinss: Need to adopt this anywhere we have parens.
glazou: Not everywhere, just when it's not a function.
plinss: Don't want white-space in nested parens.
TabAtkins: Any time an IDENT is next to a parenthesis, we require white-space.
plinss: on the outside of either parenthesis.
RESOLVED: MQ requires white-space on both sides of a parenthesis
Bert: Don't require it in the font shorthand
Bert: basically the same case.
Bert: If you have the font shorthand. "font: Times/**/10pt" is fine,
but omit comment is not.
plinss: Times10pt becomes one item
SimonSapin: If you aren't familiar with the tokenizer, it's much more
understandable than with parentheses.
Bert: But we're talking about consistency
plinss: Really only an issue with parentheses.
Bert: An issue with all tokens with more than one character. Also with
the ~= or the ||.
plinss: That's an interesting change, going back to syntax.
plinss: if the attribute matcher becomes one token if they had a comment
between before
plinss: that's a functional change.
TabAtkins: A precedent of ignoring comments in weird places.
plinss: They kind of deserve it.
Bert: I guess I'm not sure which is better, but doesn't seem like a big
problem at the moment. Can't see the big story yet.
TabAtkins: Where would we define this?
TabAtkins: Values and Units?
TabAtkins: because it changes the prop grammar.
plinss: Syntax?
plinss: it's a fundamental thing.
TabAtkins: Don't want a resolution that requires us to re-ask about it.
RESOLVED: white-space between any IDENT an the outside of a parenthesis.
SimonSapin: The proposal was to require white-space on both sides.
plinss: Yes, do that everywhere
TabAtkins: That's what we require in @supports.
<SimonSapin> plinss: yes, both )<ident> and <ident>(
Bert: Just came to mind: can make 'and' a keyword, so it can be followed
by paren.
TabAtkins: The issue is not related to 'and' specifically.
TabAtkins: Anytime you have keywords next to parens.
TabAtkins: Anytime a paren is valid by itself and an ident is valid next
to it.
TabAtkins: One example is in grid syntax, if we switch to named line syntax
TabAtkins: (x y)auto needs white space.
TabAtkins: so no tightly-bounded set of keywords.
TabAtkins: All parentheses, or just naked parentheses? what about an ident
following a function?
TabAtkins: function, the concept, not the token.
plinss: could it be a compat risk?
plinss: ident after function.
fantasai: Yeah, gradient followed by length in background shorthand.
A likely typo.
plinss: So we can't require it everywhere.
TabAtkins: So only naked parenthesis groups.
plinss: We don't have naked parentheses anywhere else, so not a problem
dbaron: We have it inside calc()
TabAtkins: But you never have an ident.
TabAtkins: Need a delim, no implied multiplication.
fantasai: One reason why we feel it's awkard and want symmetry in MQ
and @supports is that they are conjunctions.
fantasai: I'm happy if we just require it for conjunctions.
TabAtkins: If we did that, and didn't care about end parens, we could
just make the parser recognize and( as a function token.
Tabatkins: dropping the comment.
TabAtkins: and be invalid.
plinss: I guess that's fine
TabAtkins: Can handle it either way
plinss: No, I don't think that's fine.
plinss: url/**/( is not a URL token
plinss: That would turn it into a function.
plinss: making it valid.
TabAtkins: Handle it as grammar then.
plinss: idents followed by open parenthesis must have white space between
the two unless it's a function.
RESOLVED: (replaces previous resolution) Idents followed by open parenthesis
must have white space between the two unless it's a function.
CSS escapes in attr() values
----------------------------
SimonSapin: attr() defined in the values spec
SimonSapin:This function now takes a parameter with expected type
SimonSapin: can pass integer etc.
SimonSapin: In the defining for string and url, we say that the absolute
value is passed
SimonSapin: should clarify whether CSS escapes are interpreted, and I
think they should not be.
SimonSapin: If they need to be serialized, we may need to add escapes,
but that's a separate concern.
TabAtkins: att="foo\33", content: attr(att) displays "foo33" or "foo\33"?
plinss: Don't want to move escapes from one context to another.
plinss: it should be resolved before.
glazou: Entities should not leave their context.
RESOLVED: String and URL types for attribute literally takes the attribute's
value without parsing.
<SimonSapin> In particular: clarify that no CSS escaping is involved.
Probably remove wording like "parsed as the contents of a
CSS <string>".
Alignment
---------
TabAtkins explains concepts, but not the basic properties
TabAtkins: This applies flexbox alignment props to rest of CSS
fantasai: Most keywords are axis agnostic, so put them in a separate section
TabAtkins: Only non-obvious are self-start and -end
TabAtkins: start/end are defined based on the mode and directionality
of the parent element
TabAtkins: self-start/end are defined based on the element itself.
TabAtkins: flex-start and -end are based on the flex directionality instead of the writing ode
dbaron: Do flex-start and -end fall back?
fantasai: to start and end.
fantasai: if not flexbox
fantasai: we have left and right, because sometimes you want that, but
we can't always fulfill that if it's in the wrong axis.
TabAtkins: Helps explain <div align="...">
fantasai: stretch depends on the layout mode, defined further down
fantasai: We pulled the baseline definition from 2.1 and put it here.
fantasai: Flexbox also has it
dbaron: doesn't distinguish between inline-block and [...]
fantasai: defined to use last-line baseline in 2.1
fantasai: Need to spec first-line baseline and last-line baseline
fantasai: and which are used for different things.
fantasai: first-line and last-line baseline interaction is complicated,
so need to define based on context, and research it.
fantasai: Don't expect impls to be sensible.
RESOLVED: Need more work on baseline section, define first-line and
last-line baseline for all things.
fantasai: Block-axis of table is undefined.
fantasai: Table with a block of text inside, with a vertical text context,
then the block axis will align with the inline axis
fantasai: Need a concept of baseline for each box
fantasai: Is it based on the baseline of the first column, or does it
not have a baseline?
TabAtkins: No testing yet
fantasai: Basing on first column makes sense
Bert: Why not center?
fantasai: if you want that, then you would center it.
TabAtkins: There is a keyword for that.
fantasai: We'll do another pass, but needs review eventually.
fantasai explains distributed alignment
TabAtkins: space-evenly is new, based on requests to flexbox
fantasai: Useful for two-column layout with different layout models in each
TabAtkins: 'stretch' came from Grid Layout.
fantasai: Needed for flex lines.
fantasai explains overflow alignment
fantasai explains justify-content and align-content
dbaron: not handled the same way as the 'align' attributes?
TabAtkins: We have special keyword.
dbaron: People have trouble following, not really working as an introduction.
TabAtkins explains justify-items
TabAtkins: can choose legacy behavior
dbaron: My issue was with how you mapped HTML alignment attributes that
don't have a BFC.
fantasai: Vertical alignment in the vertical axis forces a BFC.
fantasai: but might need thinking about
fantasai: might also need horizontal axis.
TabAtkins: Can only use the block-axis one on blocks
TabAtkins: Get <center> behavior by using legacy keyword
TabAtkins: The property that does that does not have the BFC behavior
Bert: 'safe' and 'true' centering…
Bert: I want to reintroduce true centering in text-align, even where
there's overflow.
Bert: and margin: auto, where I want centering without clamping
fantasai: This spec takes those props and applies them to all box models
TabAtkins: Don't use margins to center. Use align property to choose true
center.
fantasai draws case with shrink-wrapped table with margins and centering.
fantasai: Want at least a certain margin, but also want centering.
This is a better model for that, using justify-self.
fantasai: have cake and eat it, too
fantasai: justify/align applies to block/inline.
SimonSapin: block-align and inline-align?
TabAtkins: Flexbox doesn't care about your writing direction
TabAtkins: prop names are not renameable.
TabAtkins: Need to discuss abspos
Bert: Can I use other props in the normal flow?
TabAtkins: Can align the entire block's contents
TabAtkins: It's defined in the spec.
fantasai: Vertical centering: use align-content on an element
TabAtkins: Spec is split into two axes and three alignments applied to them
Bert: last column "Applies to" answers my questions.
Bert: Have to rewrite Box Model
Rossen: These apply to border box or margin box?
fantasai: Margin boxes.
TabAtkins: In case of vertical-aligned paragraphs, the outermost bounding
box of the contents.
Rossen: justify-self: true center on box with 25% width and 50% left margin,
will be centered with the margin box?
TabAtkins draws on board
Rossen is satisfied
TabAtkins: Let's talk about abspos
fantasai: The plan of this draft is to make it easy to center things,
including abspos
fantasai: The containing block for your asbspos item has offsets specified
fantasai: That creates a modified containing block.
fantasai: by default, you do as in 2.1
fantasai: If you specify center, then you'll shrink-wrap.
dbaron: 2.1 isn't quite that simple. Function of whether width and height
are specified
TabAtkins: If neither is auto, then we do these things.
TabAtkins: was confusing to write!
TabAtkins: If you have explicit margins and left and right props, then
when calculating auto width, shrink to fit.
dbaron: Also, when no auto width, also align.
Rossen: change of behavior?
fantasai: No, compatible with 2.1
TabAtkins: stretch is default. Absposes behave as in 2.1
TabAtkins: Possible that there are some deep details that we missed,
so needs review at some point.
fantasai: Get true alignment in grid and flexbox, but safe alignment
in doc-centric layout, i.e. tables and blocks.
fantasai: Can't make them all safe, because flexbox has true.
TabAtkins: Could define whatever for blocks
Rossen: Should keep doc-centric ones safe and app-centric true.
fantasai describes property index
TabAtkins: Please someone look at legacy left/right/center, is there a
better way to do it?
fantasai: Want to express that we're inheriting alignment.
fantasai Right now only with left/right/center, but if it's useful,
can allow 'legacy' with start/end as well
fantasai: Think about: do we want to allow it for other keywords?
fantasai describes auto/legacy
Reversing Interrupted Transitions
---------------------------------
<dbaron> http://dbaron.org/css/test/2013/transition-reversing-demo
dbaron: only tested in gecko
dbaron: relies on mouseenter/mouseover, but those are even worse than
a decade ago
dbaron and TabAtkins discuss JS implementation
dbaron explains various proposals in testcase
dbaron: There were other proposals, but I didn't implement
TabAtkins: Your proposal is better than the current spec, at least.
dino: Reversing is only when in a transition and you set the value to
where you came from? If it has ended, run a normal transition?
dbaron: yes
SimonSapin: What if enter a transition and go to another one?
dbaron: No special treatment. Hard to implement sensibly.
fantasai: if we have transition-in but not -out?
dbaron: Then will not have transition-out.
dino: What if a different timing function or duration? should break
reversal.
dbaron: Disagree.
dbaron: in many cases people will want different timing functions,
because they want that behavior.
dbaron: With my approach, they'll still get the specified timing function
for each direction.
dbaron gives example with timing function on hover state
dino: People that care about this will want to tweak everything. Can't
address that without adding props.
dino: Just make it work for the majority of cases
fantasai: If timing-in was 4s and -out was linear 4s…
dbaron: My proposal looks only at value, not timing.
dbaron: Sometimes 50 % through value space in 12 % of the time
dbaron: I say 50 % in 50 %
dino: If linear in both directions, 4s one way 2s in the other…
[not minuting clarifying discussion]
fantasai: What if the timing function is slow for 15% and then fast?
dbaron: That's ease-in
dbaron: If you mouse out at 50%, the time going back is close to the
time going forward
dbaron: Time going back was shortened quite a bit
krit: ease-in is better with the current spec, ease-out is better with
your proposal
dino: Depends on when you interrupt it
rik: goes too fast back when shortening the time
dbaron: Don't like discontinuity between 99% and 100%
dino: Some people might want an interrupted transition at 99%, pretend
it finished.
dbaron: Mine: it gives 99% of the duration, so almost undetectable.
dino: Should just pick one, yours is fine. Let's implement it and see.
dbaron: Has always been like this in Gecko
krit: Safari just unprefixed transitions
dino: Concern is that people have content where they instead of transitionEnd
event assumed that something happened.
dino: we're effectively changing t-duration on them.
TabAtkins: Adding a delay between the real end and the …
dbaron: Probably need some real events for interruption
dbaron: no transitionend event.
dino: There's interrupted and there's paused.
dino: suspended, e.g. if animations are paused on scroll
dino: duration is possibly longer
dino: People have requested that if prop is set to same value, then no
transition.
dino: Adopt your proposal.
cabanier: Apple's spec is better, actually.
dino: I don't care much. Want to stop hover complaints.
dino: Safari has no reversing, so need to implement to see.
cabanier: Don't we already have a demo for side-by-side?
dino: Need a complete implementation.
krit: Can also be decided in CR.
plinss: Do we want to change?
TabAtkins: Spec behavior is bad.
krit, cabanier: no, not bad.
dino: We don't know, because we haven't implemented it.
dbino: propose dbaron's suggestion. Firefox already shipped, looks good
enough.
RESOLVED: dbaron's proposal for reversing interrupted transitions is accepted.
Meeting adjourned.
<RRSAgent>http://www.w3.org/2013/06/07-css-minutes.html
Received on Wednesday, 3 July 2013 05:57:42 UTC