- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 24 Jul 2013 15:19:00 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Discussed botched LC publication of Variables, plan to republish
soon, probably with additional issues resolved.
- Discussed use of 'var' as shorthand to reset all custom properties.
- Discussed plan for updating CSS2.1. Basically, need
* reviews of errata, to make sure they're correct
* testcases for each erratum
* implementation report proving we have impl passes for each erratum
- RESOLVED: Republish CSS3 Values and Units as CR to update for minor fixes
- RESOLVED: Drop 'default', introduce 'unset' as "initial-or-inherit"
- RESOLVED: 'all' shorthand does not reset 'direction', 'unicode-bidi',
or 'var-*'.
- Reviewed open Flexbox issues
http://dev.w3.org/csswg/css-flexbox/issues-cr-2012
- Hoping to close off last two issues in CSS3 Text (text-align-last
shorthanding, letter-spacing + justification) next week if possible.
====== Full minutes below ======
Present:
Glenn Adams
Rossen Atanassov (late)
Tab Atkins (late)
Shezan Baig
David Baron (left early)
Bert Bos
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Rebecca Hauck
John Jansen
Dael Jackson
Brian Kardell
Brad Kemper
Philippe Le Hégaret
Chris Lilley
Peter Linss
Chris Palmer
Anton Prowse
Matt Rakow
Florian Rivoal
Simon Sapin
Dirk Schulze
Nick Van den Bleeken (late)
Lea Verou
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2013/07/24-css-irc
Agenda: http://lists.w3.org/Archives/Public/www-style/2013Jul/0518.html
Scribe: fantasai
CSS Variables
-------------
glazou: Where are we wrt variables?
fantasai: LC wasn't published
florian: It sort-of was. if you add -1 to the end of the url, it's
published there
fantasai: Was an announcement posted to www-style?
<glazou> http://www.w3.org/TR/css-variables-1/
<florian> not LC: http://www.w3.org/TR/css-variables/
<florian> LC: http://www.w3.org/TR/css-variables-1/
fantasai: If it wasn't announced and didn't show up at the old URL,
I don't think we can consider it published.
glazou: Was it announced to chairs@?
plh would have to look into it
<SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013Mar/0701.html
fantasai: I would be uncomfortable closing the LC period if no announcement
was posted in CSSWG channels
fantasai: and it didn't even show up to replace the old draft
florian: There's also 3 open issues in the ED
glazou: Not announced on www-style. This is painful
plh: My bad
fantasai: No, it's the editor's responsibility to announce the draft
dbaron: But nobody tells the editor that the draft has been published
plh: I would concur with fantasai. If it wasn't announced, redo LC period
florian: Need to get the links in synch
ACTION plh: have /TR/css-variables/ alias to /TR/css-variables-1/
<trackbot> Created ACTION-569
chrisL: I would just extend the deadline
fantasai: There were also some significant changes we wanted to make,
so maybe we should make those changes and republish LC
...
fantasai: There's an issue for example on interaction with the 'all'
property, and we decided it doesn't reset variables, but
an 'var' shorthand will reset all variables, so that needs
to be added to the draft.
chrisL: Doesn't sound like too much work, could publish on Tues probably
dbaron: What values does 'var' take?
SimonSapin: Same as 'all'?
fantasai: I think Tab proposed <'all'>
dbaron: Initial/inherit, do they have special behavior in variables then?
* fantasai doesn't know
glazou: This seems really hacky.
<SimonSapin> Does <'all'> makes Variables refer normatively to Cascade?
<fantasai> yes
dbaron: If 'initial', 'inherit', and 'default' aren't interpreted,
then it's special?
TabAtkins: Yeah, well, we haven't decided on that anyway
...
TabAtkins: The 'var' property isn't a custom property, it's a CSS thing.
Assuming that we need that.
glazou: Thought we were going to LC
glazou: ...
glazou: I would like the use case for this
TabAtkins: Want to block variables inheriting into your little subtree
<dbaron> I'm inclined to think a 'var' shorthand should take only 'initial'.
<glazou> dbaron, +1
florian: So, either we decide this is minor enough to handle as an LC comment
florian: Or we take advantage of having screwed up LC, make the change,
and then publish LC
fantasai: If we want to make this change, would suggest we resolve this
and republish LC. It's a fairly significant change.
[argument over publication process]
<Zakim> -dbaron
<dbaron> I've had enough of the chair yelling at the WG.
glazou: Let's prep the document for a new publication.
glazou: Enough on this topic for today
* plh doesn't understand why we're pushing a doc to LC that still have
uncertainties around
<glazou> plh, +1
Conditional Rules
-----------------
glazou: dbaron lost, because can't stand ppl being unhappy. Next topic
CSS2.1
------
Bert: What do we want to do, before republishing 2.1
Bert: Thought the errata were up-to-date, but some weeks of minutes
I haven't checked yet.
Bert: Then there's all the issues in Bugzilla. How many do we want to
solve? Do we want to set a deadline for solving them?
Bert: How much effort do we want for those issues
Bert: Also about testing
Bert: The changes we made, I've seen 1-2 that have testcases
Bert: Don't know if others do. Doubt it.
Bert: We need to make sure the changes we make are supported by testcases
Bert: Someone needs to do that
Bert: and also need implementations for those testcases
Bert: Any idea of how much effort we need, when we could finish,
schedule updated publication?
fantasai: Maybe make a schedule where we deal with 1 issue per
[time period, e.g. week or fortnight]
fantasai: Wrt testcases, dunno, ask rhauck?
florian: What about publication? How often do we want to publish?
fantasai: Need to have tests + impl reports for PER publication
florian: But how many issues do we want to solve before publishing?
antonp: Depends on how WG perceives last publish date.
antonp: If you want to send signal that it's improving, republish
every 6 months
antonp^: Not sure makes sense to republish with only 1 erratum, though
antonp: Sorry for being out of action on this
<Ms2ger> Six months is ~25 telcons, so if you decide on one issue
every telcon...
fantasai: I think the main thing is to make sure the existing errata
are correct, have testcases, impl report
fantasai: Once we're there, can publish any time we want
fantasai: Some of them, might be waiting on implementations to catch up,
so would incorporate more issue updates while we wait for that
before publishing. That might set the rhythm.
JohnJansen: There's also testcases added to the test suite since we
publish REC. Would need to make sure we have impl passes
for all of those as well
florian: Is there a rule for handling such things?
JohnJansen: Raises question of what REC means if we publish a new testsuite
florian: It wouldn't make sense to me to block republication of REC on that.
It's not like we regressed
Bert: Most concrete thing I heard was to go over the errata that we
decided on, make sure correct and have tests.
Bert: Maybe we can assign action items for that?
Bert: Since I made the errata, I should not check them :)
Bert: Errata have links to minutes, so should be easy
florian: Not a lot of work, but can be pretty subtle
florian: Sometimes wording in errata slightly off from decisions in a
way that creates a problem
antonp: Yeah, we have an existing case of that
ACTION fantasai: Review CSS2.1 errata
<trackbot> Created ACTION-570
ACTION antonp: Review CSS2.1 errata
fantasai: Rebecca, can you and gtalbot look into tests?
ACTION rhauck: Look into tests for CSS2.1 errata
<trackbot> Created ACTION-571
dirk's topic deferred to next week
Republishing Values
-------------------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013JulSep/0051.html
TabAtkins: Handful of changes, very minor, not worth LC, but good to correct on /TR
TabAtkins: Changes in changes section of spec
glazou: What do ppl think?
SimonSapin: Yes, let's republish
RESOLVED: Republish Values as CR
Cascade
-------
Scribe: TabAtkins
http://lists.w3.org/Archives/Public/www-style/2013Jul/0478.html
fantasai: Two issues that needed final resolution.
fantasai: First was dropping "default". Second was adding "unset" for
"initial or inherit".
fantasai: Any comments? Do we want to accept the changes?
<SimonSapin> sounds good
<florian> given my understanding, I am fine with it.
RESOLVED: Accept the default/unset changes.
<fantasai> next issue -> http://lists.w3.org/Archives/Public/www-style/2013Jul/0508.html
fantasai: Next issue is somewhat tricky.
fantasai: The problem with 'all' is that it kills *everything*.
fantasai: We were like, are there certain rules we really don't want
people to reset without having explicitly decided to do so?
fantasai: We went through Firefox's UA stylesheet.
fantasai: Resetting most things are fine.
fantasai: But there are two properties which we realized nobody should
be touching unless they're explicitly going against our
recommendation not to touch it, for some reason.
fantasai: Those two are 'direction' and 'unicode-bidi'.
<ChrisL> almost-all ?
fantasai: Right now, 'all' will reset those.
fantasai: Which might be okay on an LTR page, but on RTL it'll break
things by resetting explicit values.
ChrisL: Are 'direction' and 'unicode-bidi' the only properties we'll
do this with? Should those not have been properties at all?
fantasai: Yes, those two should not have ever been CSS properties.
fantasai: They were added because people thought that was the right way
to handle non-HTML bidi requirements.
fantasai: Personally I think it would have been smarter to add an xml:dir
attribute, but we have 'direction' now.
fantasai: CSS2.1 and CSS3 both say "don't use these properties, use the
markup instead".
fantasai: It's *possible* we might add new things, but unlikely.
antonp: I don't like a property called 'all' that's not actually all.
[something about other proposed properties to add]
fantasai: Yeah, that's why I'm less certain we should tie it to other
cases.
antonp: The reason the bidi ones are being excluded is because they
shouldn't have been properties in the first place, but I don't
think that set should grow.
* antonp is fine with 'all' that excludes these mistake-properties,
but doesn't like 'all' that does more
SteveZ: One thing you said is that direction isn't really part of styling,
but rather a content quality.
SteveZ: Perhaps that should be indicated as the reason for the exclusion
in the spec.
fantasai: That's already in the spec. ^_^
http://dev.w3.org/csswg/css-cascade/#all-shorthand
Bert: Aren't the custom properties also an exception to the 'all' rule?
fantasai: Yes, because they're not CSS properties.
TabAtkins: Yeah, Variables already has an issue for this.
SimonSapin: David Baron just sent an email to the list with roughly the
same consensus (not liking exceptions, but maybe being okay
with the two properties).
TabAtkins: I'm okay with just limiting it to the two properties, and
not doing [lang] stuff.
[jokey discussion about changing it to 'most']
RESOLVED: 'all' does not reset 'direction' or 'unicode-bidi' (or custom
properties)
* florian thinks "all" is short enough to not specify all the *what*,
so I'll just interpret it as meaning "all the properties that
are reasonable to reset"
<BradK> Can I set 'all:red' and have it affect everything that takes a
color as a value?
<SimonSapin> not per the current spec
<BradK> Maybe it should. Do you know if this has been discussed on the list?
<SimonSapin> I think it hasn’t been discussed, but I don’t like it :)
<BradK> Yeah, there's probably no real value in doing that. Never mind.
Flexbox LC
----------
http://dev.w3.org/csswg/css-flexbox/issues-cr-2012
fantasai: There's the DoC, and there's a handful of open issues we're
still trying to resolve.
fantasai: People who are interested in flexbox should probably hang out
in the list and help us out.
fantasai: I'll summarize the issues...
http://dev.w3.org/csswg/css-flexbox/issues-cr-2012#issue-3
fantasai: Issue #3 - why doesn't height:100% on the child of a stretched
flex item take effect?
fantasai: We thought there wasn't a good reason that it doesn't work
for a single-line flexbox with a definite size.
fantasai: Relatedly, I think MS will honor %ages even if the flexbox
isn't a definite size - one pass treating the percentages as
auto, resolve the size of the flexbox, then do another layout
pass with that as the definite size.
http://dev.w3.org/csswg/css-flexbox/issues-cr-2012#issue-19
fantasai: Issue 19 is about the implied minimum size of flex items.
We resolved to revert it to zero, but there's a thread about
that maybe not being a good idea. There's an ongoing discussion.
http://dev.w3.org/csswg/css-flexbox/issues-cr-2012#issue-21
fantasai: Finally, if you have two flexbox children that are table-cell,
should they be converted directly to block (and be independent
flex items), or first wrapped in an anonymous table and then
made into a flex item?
fantasai: There is different impl behavior between FF and webkit/blink,
at least.
http://dev.w3.org/csswg/css-flexbox/issues-cr-2012#issue-22
fantasai: Last is about the static position of flex and grid items.
We can probably leave that open during the LC, as it doesn't
necessarily imply a change to Flexbox.
fantasai: That's an overview of the issues, so it would be good to get
the opinions of interested people.
SteveZ: Can you provide pro/cons for the table-cell case?
fantasai: Right now, if you ever have two adjacent table-cells,
we'll wrap them in a table.
fantasai: Flexbox says the same thing at the moment.
fantasai: If you have a few table-cells mixed with other boxes,
and you're expecting the anonymous box behavior, that's what
you want.
fantasai: On the other hand, you might want to be using table layout
as a fallback for flexbox, in which case you want the cells
to be independent.
TabAtkins: Another arg in favor of anon-box behavior is that for other
box model things, like run-in and ruby, we will want to do
box-fixup first.
fantasai: I totally agree with TabAtkins on run-in and ruby and other
things
fantasai: Just for tables, seems like we have good use case for recomputing
'display' instead, and since anon table box generation is somewhat
complicated, less likely to be used.
TabAtkins: I've relied on it in the past. :/
SteveZ: Is there a way of getting the non-fixup behavior by some other means?
TabAtkins: You can set display:table instead, if you want.
Rossen: There's also an expectation of what the fixup is going to be.
Rossen: In flow layout, if you have two adjacent table-cells, you'll
get a single wrapper around them.
Rossen: I think we should make a deliberate decision over whether to
have same behavior in both layout systems or not.
Rossen: I'm not saying there's a ton of interop in block layout, but at
least in these simple cases, there's interop.
[discusses how to detect the behavior, so we know IE's treatment]
<fantasai>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22display%3A%20flex%3B%20flex-flow%3A%20column%22%3E%0Atest%0A%3Cdiv%20style%3D%22display%3A%20table-cell%22%3EA%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22display%3A%20table-cell%22%3EB%3C%2Fdiv%3E%0Atest%0A%3C%2Fdiv%3E
fantasai: In the above, if A and B are next to each other, you do table
fixup (they're in a single table). If they're vertical, you
don't do fixup (they're separate flex items).
Rossen: IE does the fixup.
fantasai: Mozilla too.
TabAtkins: Chrome does not.
fantasai: So unless anyone else has comments, maybe we just stay with
what we have, and do the fixup?
SteveZ: Can we delay the decision a week?
fantasai: Sure.
CSS3 Text
---------
fantasai: One more thing for next week - I'd like to have Steve and Alan
and Jdaggett to help solve the last two issues with CSS3 Text:
text-align shorthanding and letter-spacing. AFAIK, these are
the last ones holding up LC.
SteveZ: Do you have suggested text for the letter-spacing justification?
fantasai: No, but I can write some up.
Received on Wednesday, 24 July 2013 22:19:32 UTC