- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 19 Mar 2014 21:02:37 -0400
- To: www-style@w3.org
TPAC
----
- In general people preferred meeting on the Monday and Tuesday of
TPAC.
- Plinss will fill out the request for those days.
Flexbox CR Disposition of Comments
----------------------------------
- RESOLVED: Accept proposal for issue 19
- RESOLVED: Accept change for issue 3
- RESOLVED: No change, floats computes to specified value on flex
items. (Issue 32)
- RESOLVED: No change for issue 33
- RESOLVED: Accept decision of the editors for initial value of
align-items (Issue 25)
- RESOLVED: Take Flexbox to LC with a 4 week period
Variables Syntax
----------------
- RESOLVED: Use -- prefix to define var
CSSNamespaceRule
----------------
- Glazou brought his concern about the namespacerule being
unnecessarily limiting for authors.
- Some work arounds were discussed and feeling seemed to be a bit
mixed.
- Conversation will continue on the mailing list.
subgrid
-------
- Fantasai re-iterated her concerns about removing subgrid from
level 1 of Grid.
- TabAtkins stated he agreed in principal with her arguments, but
didn't think shipping could be delayed long enough to get
subgrid ready.
- Due to lack of time the conversation will continue on the mailing
list.
=====FULL MINUTES BELOW======
Present:
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Bruno de Oliveira Abinader
Elika Etemad
Sylvain Galineau
Daniel Glazman
Koji Ishii
Dael Jackson
Brian Kardell
Brad Kemper
Philippe Le Hégaret
Peter Linss
Edward O'Connor
Simon Pieters
Anton Prowse
Matt Rakow
Simon Sapin
Dirk Schulze
Alan Stearns
Greg Whitworth
Steve Zilles
Regrets:
Glenn Adams
Deblyn Prado
Florian Rivoal
Lea Verou
ScribeNick: dael
plinss: Let's get started
plinss: Any additions?
bert: TPAC maybe?
plinss: Okay. Anything else?
plinss: Okay TPAC
<SimonSapin> plinss, if we have time, agenda+ renaming
measure/extent
TPAC
----
plinss: Which days? Mon-Tues or Thurs-Fri? Do we need an extra
day? Who, Where?
plinss: Opinions?
plinss: Anyone?
dauwhe: Monday or Tuesday is good.
plinss: Do we want to meet the day before?
dbaron: I think it's worth noting we'll be meeting less then 2
months prior.
plinss: So maybe not bother with the extra day?
<sylvaing_> Given the proximity of the Sept. meeting + the length
of TPAC, OK with two days
plinss: Fine by me. Anyone want to have it?
plinss: We can try and add it later if we need to.
plinss: Monday and Tuesday okay for everyone?
<glazou> +1
plinss: Anything else?
* tantek is also +1 on MT for TPAC.
Bert: Who will fill out questionnaire?
plinss: I'll take care of it.
Flexbox CR Disposition of Comments
----------------------------------
fantasai: The question is are people familiar with this or should
I go over it or give people more time?
[silence]
plinss: Everyone is highly participatory today.
plinss: Run though the issues and we'll see if we can get them
resolved.
<fantasai> http://lists.w3.org/Archives/Public/www-style/2014Mar/0350.html
fantasai: Those are the things with a summary.
fantasai: 19 is the major issue, it's about the min size of flex
items.
fantasai: Does anyone but me, TabAtkins, or rossen have an opinion?
<dbaron> I believe dholbert had looked at it and sent comments on
the list.
<fantasai> dholbert's comments -
http://lists.w3.org/Archives/Public/www-style/2014Mar/0428.html
TabAtkins: Flex originally added an auto min and you could turn it
off.
TabAtkins: That made things confusing, so we reverted to min 0,
but that makes other things confusing.
TabAtkins: Slight tweak is to make a min content if there's a non-
visible overflow.
TabAtkins: You couldn't tell things were overflowing and it was
confusing.
TabAtkins: So if your default is non-zero there's a min-width.
TabAtkins: This gives us the benefit from before where flex
doesn't shrink too much, but avoids the biggest problem.
TabAtkins: IE already implements this behavior.
TabAtkins: The old way set min as 0 and you had to set it to be
something like .1 to get the real deal.
TabAtkins: So we think this would fix it.
TabAtkins: Unless anyone objects, I think we should resolve.
dbaron: I'm okay, but I find it odd since it is different than
overflow in other contexts.
dbaron: I think there are some where overflow suppresses
propagation of intrinsic size.
fantasai: That's what we're doing.
dbaron: It sounds the opposite.
fantasai: No, if overflow isn't visible, min size = 0
fantasai: If it is, min size is min content.
<bkardell_> What fantasai said makes sense.
dbaron: So TabAtkins said it backwards?
TabAtkins: Yes.
dbaron: Makes more sense to me.
TabAtkins: I can justify anything you ask.
plinss: The only thing that makes me cringe is 0 acting like not 0.
fantasai: We're not doing that.
TabAtkins: We'll switch to previous where min-width is auto and
auto computes to 0 or this behavior.
plinss: So if the author says 0 it's 0.
fantasai: Yes.
plinss: Works for me. Anything else?
plinss: Any obj?
* bkardell_ says +1
RESOLVED: Accept proposal for issue 19
TabAtkins: Next was raised by rossen because it was where
Microsoft diverged and they want to change it to match
their behavior.
TabAtkins: Where you have a child inside the flex and it has a %
height, if the flex has a defined height it's normal.
TabAtkins: If the flex item is auto height but stretched and flex
box...
fantasai: TabAtkins, wait, we resolved this.
fantasai: What Tab is describing in this case, it's the flex box's
auto height, not a fixed size,
fantasai: So % gets treated as auto basically.
fantasai: The behavior we're changing is that if you have an auto-
height and the cross size is auto and items are
stretched, you size based on contents as if children
with % were auto.
fantasai: Using that height you fix that height and resolve %
against the auto computed value.
fantasai: The disadvantage is it adds another step.
fantasai: The advantage is you can do a lot of things that
wouldn't work else wise.
fantasai: There's odd cases where it won't work out perfectly, so
you can get weird overflow, but most will work fine.
plinss: You said IE already implemented this?
fantasai: Yes, we got a message saying IE and Geicko have these
changes implemented.
fantasai: These changes for issue 3.
plinss: Any other opinions? Other implementors?
plinss: Given lack of other opinions, we should accept this
behavior.
plinss: Other objections?
RESOLVED: Accept change for issue 3
<gregwhitworth> These resolutions will updated in the spec correct?
fantasai: Next two issues are minor, just wanted to check in with
the working group.
fantasai: One is if float should compute to none on flex since
they can't float.
fantasai: We closed it no change.
fantasai: Any other opinions? dholbert liked how it was.
fantasai: It computes to how it is, but ignored.
TabAtkins: You'll still get changed however the float does, but
for your actual floating, nothing will happen because
flexbox doesn't know what floating is.
plinss: Any thoughts?
<bkardell_> seems good
SimonSapin: In general I'm in favor of not changing. You may have
to apply in cascade, so it's easier to implement if we
don't change.
plinss: Anyone else?
RESOLVED: No change, floats computes to specified value on flex
items. (Issue 32)
plinss: And issue 33?
fantasai: We had a question about if order affects counters. We
looked at the text and it seems clear it doesn't
fantasai: We think it shouldn't because order is purely visual and
counters isn't visual.
fantasai: We want to keep it away from purely visual. Any opinions?
<astearns> +1 to order not affecting counters
TabAtkins: This should be consistent with tab index when we talked
about it with A11Y WG.
??: I agree, it should be just visual
plinss: I have mixed feelings, but don't feel strongly.
bkardell: Can someone explain more?
plinss: Question is if counter values are affected by the
ordering, are they re-ordering the content?
bkardell: So is it they do or don't?
TabAtkins: Counters go by DOM order, not rearranged order. The
only affect is on layout itself.
<sylvaing_> Does the flexbox order property behave like the grid
order property?
plinss: There was IRC question about grid order. Same thing?
TabAtkins: Yes. They're identical.
plinss: So the behavior is the same.
TabAtkins: Right.
<sylvaing_> THEN SHIP IT
plinss: Other opinions?
<gregwhitworth> sounds great!
plinss: It does seem it could be surprising if I reorder and
counter numbers don't change, but we could add a property
later to control that.
plinss: Any objections?
RESOLVED: No change for issue 33
<fantasai> http://dev.w3.org/csswg/css-flexbox-1/issues-cr-2012
fantasai: This (above) is the DoC
fantasai: The two issues we just closed are 3 and 19 which are red.
The last two are orange we just resolved as well.
<fantasai> http://dev.w3.org/csswg/css-flexbox-1/issues-cr-2012#issue-9
fantasai: Other non-green things, we closed 2 issues, one from
Kenny Lu, issue 9.
<fantasai> http://dev.w3.org/csswg/css-flexbox-1/issues-cr-2012#issue-10
fantasai: There's also an issue on should negative margins
increase space, that's issue 10. We said no, if you have
too many negatives that's your fault.
<fantasai> http://dev.w3.org/csswg/css-flexbox-1/issues-cr-2012#issue-25
fantasai: There was another issue about changing align-items to
flex-start, we said no.
fantasai: That's because it's too late to change something that
significant.
fantasai: Anyone want to go over these with more detail?
plinss: Anyone?
plinss: Doesn't sound like it.
plinss: Do we want resolutions for those rejected comments?
fantasai: Maybe. We have 9 and 10, so we just need the initial
value of the align-items.
plinss: Any opinions? Or are we happy with editors discretion?
RESOLVED: Accept decision of the editors for initial value of align
-items (Issue 25)
fantasai: So I suggest we take Flexbox to LC
fantasai: There's significant changes.
<fantasai> http://dev.w3.org/csswg/css-flexbox-1/#changes
plinss: Any objections to LC?
TabAtkins: I don't think we mentioned it, but there's significant
details in changes if there's any questions.
plinss: How long a LC period?
TabAtkins: 3 weeks or maybe longer?
fantasai: I'd go with 4. There's complex changes and another week
shouldn't be a problem.
plinss: Everyone else okay with 4?
Bert: I'd prefer 4 weeks
RESOLVED: Take Flexbox to LC with a 4 week period
plinss: Where are we with the test suite?
plinss: Existing test will need to be changed with these changes?
TabAtkins: If there's ones around min-size they will need to be
fixed. I can check.
plinss: Thanks. Any sense on coverage of test suite?
plinss: We good or do we need more?
TabAtkins: I think we'll need more.
fantasai: I can almost promise we need more.
plinss: Anyone have tests that haven't been contributed?
plinss: According to existing documentation we have 2 passes for
everything.
TabAtkins: That's way not valid.
plinss: I know, but in theory we could go the rec.
* dbaron should check if there are other mozilla tests that could
be imported, although there are a decent number already
imported
* fantasai dbaron, will probably need to re-import after changes
from min-size issue.
SimonSapin: Has anyone looked at Opera tests?
<SimonSapin> https://github.com/operasoftware/presto-testo/tree/master/core/standards/css3/flexbox
<zcorpan> https://github.com/operasoftware/presto-testo/search?q=flexbox&ref=cmdform
plinss: Anyone have time to do that?
plinss: Anyone?
TabAtkins: I'll get around to it if no one else does.
gregwhitworth: I'm sure I can help too.
gregwhitworth: TabAtkins and I can coordinate where needed
plinss: Thanks. Anything else for flexbox?
fantasai: Can we publish next Tuesday?
bert: If you promise it's up to date.
fantasai: We can have it by tomorrow.
bert: Okay.
fantasai: We just need to deal with open issues where we just
resolved.
Variables Syntax
----------------
TabAtkins: Right now variables are declared...custom properties
are var- prefix,
TabAtkins: Other custom things, var- isn't appropriate, but I want
to be consistent.
TabAtkins: The previous draft I showed at the last F2F used _ to
indicate custom.
TabAtkins: That was a valid ident, but CSS wasn't likely to
invalidate by using it somewhere else.
TabAtkins: There was another suggestion of -- to indicate custom
because _ was ugly, but -- still distinguished from
vendor.
TabAtkins: I'm fine with either. -- is okay for all custom in the
future, but _ is okay too.
TabAtkins: We need to decide today because I promised heycam I
wouldn't delay past this week.
TabAtkins: Any other thoughts or suggestions?
* sylvaing_ likes --
* astearns likes --
* fantasai also likes -- over _
<SimonSapin> +1 for --
<dbaron> I prefer -- over _; don't care about -- vs var-
<bkardell_> Double dash requires a parser change, can we make sure
we're all agreed on that.
<astearns> For those who like symmetry, a convention could be
--namespace--prop-name
<zcorpan> There was a suggestion on the mailing list to use
"custom-" as prefix.
<zcorpan> Was custom- ruled out?
<tantek> ok with -- but some editors autocorrect that to --
<tantek> just FYI
* sylvaing_ my mail editor transformed -- to an em-dash so *that*
was not a suggestion.
* tantek sylvaing_ LOL - totally predicted that.
plinss: I think some people were suggesting mdash.
TabAtkins: Nothing outside ASCII
<tantek> nothing outside ASCII7?
glazou: I think -- is okay because - is a vendor prefix. It does
make sense since it's already an extension.
??: Does -- require parser change?
TabAtkins: It changes some for ident, but heycam said that was
okay for him.
TabAtkins: The only way there could be ambiguity in existing
syntax is if someone put a negative next to a vendor
prefix.
TabAtkins: That's the only way you could have an ambiguity and I
don't think that exists.
plinss: Real risk is people are using that to comment out.
TabAtkins: Worst case is they suddenly have defined an extra few
customs.
TabAtkins: Only negative ident is a -n syntax and that doesn't
come into play
* zcorpan has not got a reply
TabAtkins: So zcorpan wondered if custom- has been ruled out. No,
but I'd prefer short then longer.
TabAtkins: It would work, but I like 2 characters over 7.
zcorpan: Fine by me.
<astearns> For those wanting a custom- prefix, you could use
--custom--prop-name
<sylvaing_> astearns, do you need the second --?
<astearns> Don't need it.
<sylvaing_> --custom-something
<astearns> I just like symmetry :)
plinss: So the -- would be valid within ident?
TabAtkins: Yes, but now it marks it as custom. You could do --
inside a custom-ident today.
plinss: Any opinions? I'm hearing a lot of people like the --
* bkardell_ likes the double dash... I thought it was dead because
of parser changes
* bkardell_ votes <3
plinss: Any obj to --?
<tantek> ++ for --
MaRakow: Is there any issue between that and HTML?
TabAtkins: Only if you're ramming it against and then it's wrong.
bkardell: If -- inside var-, does it begin with double or have it
removed?
TabAtkins: Either is okay. I had removed it because the double-
dash on var looks dumb, but I'm fine with either
approach.
bkardell: It makes more sense to keep it.
* zcorpan --(foo)
<sylvaing_> --(--(--(foo)))
<TabAtkins> var(--foo)
hober: If what goes inside var, it suggests that anything could be
in var, but if it's there it suggests only custom can be in
var.
TabAtkins: We're not allowing arbitrary properties.
plinss: Sounds like current is -- as prefix, but not within the var
TabAtkins: I'm fine with that.
glazou: I think it makes sense
<tantek> TabAtkins could you type a quick example?
<TabAtkins> Sure: div { --foo: blue; color: var(foo); }
<tantek> that does look reasonable
<tantek> thank you TabAtkins - the example helps
plinss: Okay. That could have been worse.
RESOLVED: Use -- prefix to define var
plinss: We'll have to make the syntax change.
plinss: Who will do that?
TabAtkins: Me.
fantasai: We also talked having a about var shorthand to reset all
variables. Does that mean we have a -- shorthand?
TabAtkins: Good question. I'm not prepared for that.
bkardell_: Any reason not to leave that to version 2?
TabAtkins: This is in version 2.
glazou: Maybe we need to defer since heycam needs to know tonight.
TabAtkins: Yeah.
SimonSapin: Let's make sure -- is a valid identifier.
fantasai: We have all, let's do --all
TabAtkins: Or all--
TabAtkins: Anyway.
TabAtkins: From SimonSapin questions, is -- a valid ident. Maybe?
glazou: It means you can do --: something.
<sylvaing_> can you have transition: var(foo) 1s;
<sylvaing_> I guess
TabAtkins: I don't want it to define a valid property since you
need something in var
glazou: Speaking of ugly, _ is better then that.
TabAtkins: I think -- shouldn't be a valid custom prop, but maybe
a valid ident.
TabAtkins: The change we have now, where -- is a valid ident now,
it's a simple change.
* tantek agrees with TabAtkins and is ok with leaving such detail
to the editor's discretion.
<sylvaing_> so, is ---- the -- custom property?
<abinader> so "----foo: blue; color:var(--foo); } is valid?
<zcorpan> font-family: --, serif;
<TabAtkins> sylvaing_: Um, yes. Yes it is.
<SimonSapin> sylvaing_, abinader, yes
<sylvaing_> uh oh
TabAtkins: So I say let it be a valid ident, but not a custom prop
name.
plinss: I guess I'm okay with that.
plinss: Any objections?
plinss: So we'll leave -- as a valid ident.
plinss: So with Syntax in CR, will we need to take it back to LC?
TabAtkins: At some point, yeah.
<fantasai> I'm... not sure -- should be a valid ident
<TabAtkins> __ is a valid ident too.
<TabAtkins> Which would have meant that var(_) is valid.
CSSNamespaceRule
----------------
glazou: This is about namespace rules that are triggering an
exception. It's the same as attributes for namespace rule.
glazou: That's an editor issue, you create something because a
typo and you want to fix it and you can't.
glazou: I'm not sure if there's anything to discuss now, but I'd
like to affirm from implementors that haven't replied, is
there strong resistance?
glazou: If you can't create namespace rules, you're blocked from
creating documents and that's a major editor issue.
glazou: And the object model where you can't create or modify,
it's really not needed.
zcorpan: There were issues in the mailing list such as what
happens when namespace declaration is removed.
TabAtkins: CSS is declarative. If you add or remove something, the
fontfamily that uses it will be altered.
TabAtkins: It seems reasonable that removing a namespace alters
things.
glazou: And I think this is a different between what the affect is
and what the text is. If we insert a rule and say it's
valid, than the whole style sheet becomes valid, that's
right.
zcorpan: There's a difference between namespaces and fonts because
font name doesn't cause declaration to be dropped.
dbaron: I was about the say same as zcorpan. Namespace rules are
different because they affect syntactic validity of other
rules.
glazou: But you create a XHTML for epub and you want an SVG and
style it in embedded stylesheet, you cannot create a
namespace in the stylesheet.
TabAtkins: Unless you mess with the style sheet text.
glazou: So you have to do a major hack and reinterpret the whole
style sheet anyway so this is the same.
TabAtkins: You could do the same thing through text so changing
the OM is fine.
dbaron You can mod through text, but when you do it you know
you're invalidating pointers to the OM and you're requiring
style sheet to be re-parsed.
glazou: Yes. Exactly. That is an issue.
<zcorpan> We could change how CSS Namespaces work and let
selectors with undeclared prefixes not be dropped on the
floor during parsing?
glazou: We won't decide something here, but I want everyone to
know about this. I think we should continue the discussion
on the mailing list for a solution for at least online
interfaces needing this.
glazou: Layout engines know about this and since this isn't insert-
able or style-able, no one cares about how it is
represented.
TabAtkins: dbaron can you elaborate on the effects?
dbaron: I think it's positive from implementor's perspective. If
you're doing it through text, the implementor doesn't need
to re-parse while guaranteeing. internal structures are
same.
TabAtkins: I see what you're saying.
<zcorpan> i agree with dbaron
TabAtkins: I wonder if there's an alternative. For legacy
namesapce rules are the same, but create an alt rule
that when modified it kills the formatting and fills
with new values.
TabAtkins: Affectively the same, but a more convenient interface.
* dbaron can't follow that at 1am
plinss: I'm not so sure, but I accept this is a sticky wicket, so
let's go back to the mailing list.
glazou: Yes.
<TabAtkins> document.styleSheets.namespaceMap.set("foo",
"http://bar") <-- invalidates the entire stylesheet,
triggers a reparse.
* glazou won't work if it reparses. If it reparses, then you can't
insert a created namespace rule
<TabAtkins> glazou: On reparse, it would ignore all the @namespace
rules, since they're already taken into account. Or
maybe it automatically inserts/edits a @namespace rule
into the stylesheet as appropriate.
subgrid
-------
plinss: We have 4 minutes.
fantasai: I don't know if we can do this is 4 minutes, but I don't
think we should drop for accessibility reasons.
fantasai: I have examples explaining why:
<fantasai> http://fantasai.inkedblade.net/style/discuss/subgrid-markup/
<astearns> another way of casting this is that we're not yet
allowing grid usage for those cases
fantasai: Basically it's a grid without subgrid we're encouraging
people to strip stuff that gives the correct structure
and get things to align
fantasai: Forms, if you markup forms, you'd have to strip things
out in order to have things align. If you have section
markup you have to strip that.
fantasai: It isn't great accessibility and doesn't allow for
fallback styles or things you'd want.
fantasai: People will do this and strip out their markup. That's
my perspective.
fantasai: But there isn't time for exact examples.
plinss: Okay, how do folks feel?
<BradK> I often have control over CSS but it markup.
<BradK> So I am against things that require changing markup.
<BradK> Also, hard to change markup on hundreds of pages.
plinss: Are folks okay leaving subgrid in?
TabAtkins: I agree with what fantasai said, but no one has
implemented subgrid and we want to ship grid before we
implement for subgrid.
TabAtkins: I don't think it's useful to put in something that
won't be implemented before shipping
TabAtkins: We can put this in the spec later if the process takes
too long, but I think we should put it in level 2 and
move it if things happen in that direction.
* bkardell_ agrees
* fantasai with who?
* bkardell_ agrees with shipping without subgrid in v1
* sylvaing_ thinks there is much that can be done with Grid as it
is
<astearns> I'm in favor of stripping subgrid in order to enable
the grid layout cases that can be done properly without
subgrid
fantasai: That makes sense for shipping, but it also leads to
problems where they strip information. They'll keep
doing that even when you ship subgrid. If we ship
without subgrid, we'll get the problems.
<sylvaing_> if they don't stop doing the wrong thing then it's not
clear what subgrid is fixing/how it helps authors.
TabAtkins: I don't think anyone will hold shipping until we finish.
TabAtkins: Microsoft shipped, we can ship in a few months, people
won't delay in time for subgrid because the feature is
too valuable.
TabAtkins: I get it, but realistically I can't agree.
<sylvaing_> ++
<sylvaing_> likes subgrid but it just doesn't feel like a must-
have to complete the feature
plinss: Well, we're out of time.
plinss: I don't think we'll agree in 20 sec so let's loop back and
discuss over e-mail.
plinss: That's it for this week. Thanks everyone, we'll talk next
week.
Received on Thursday, 20 March 2014 01:03:05 UTC