[CSSWG] Minutes Telecon 2014-03-19


  - In general people preferred meeting on the Monday and Tuesday of
  - 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


  - Glazou brought his concern about the namespacerule being
         unnecessarily limiting for authors.
  - Some work arounds were discussed and feeling seemed to be a bit
  - Conversation will continue on the mailing list.


 - 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


  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

  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


  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?
  plinss: Everyone is highly participatory today.
  plinss: Run though the issues and we'll see if we can get them

  <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
  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 -

  TabAtkins: Flex originally added an auto min and you could turn it
  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
  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
  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
  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
  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
  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
  * 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

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
  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

  <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
  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
  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
  <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
  TabAtkins: Either is okay. I had removed it because the double-
             dash on var looks dumb, but I'm fine with either
  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
  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
  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.


  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
  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

  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
  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

  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
  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.


  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
  <astearns> I'm in favor of stripping subgrid in order to enable
             the grid layout cases that can be done properly without

  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

Received on Thursday, 20 March 2014 01:03:05 UTC