W3C home > Mailing lists > Public > www-style@w3.org > February 2014

[CSSWG] Minutes Telecon 2014-02-26

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 26 Feb 2014 20:37:29 -0500
Message-ID: <CADhPm3ukd7Z+jw+SSWguTxU-BdgAkggeXTKBM6jKVrkZ3QfjGg@mail.gmail.com>
To: www-style@w3.org

  - SimonSapin requested that CSS 2.1 be posted on a publicly
       available site. Though most of the group agreed with him that
       it should be public, there was much discussion on how to
       handle importing the log previously private comments.
  - RESOLVED: plh will handle the log over the
       next two weeks. If no objections to it becoming public,
       SimonSapin will move CVS to mercurial.

MQ3 errata

  - ChrisL will publish the errata document.

Font Loading LC

  - TabAtkins requested that Font Loading be brought to LC. The
       group requested another week in order for TabAtkins to
       finalize some edits and for everyone to have a chance to
       review the document further.

CSS Masking

  - krit reminded everyone to review CSS Masking and give comments
      before it goes back to LC.


  - TabAtkins reported that he had reviewed the implications of
       switching from combinators to pseudo elements that Fantasai
       suggested. Mostly he found no issue, but was concerned about
  - TabAtkins and Fantasai will meet in person later this week and
       report their conversation back to the mailing list.

Counter Styles

  - RESOLVED: Accept TabAtkins's proposal and reject the comment
       from Xidorn in the disposition of comments.


  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Elika Etemad
  Simon Fraser
  Sylvain Galineau
  Daniel Glazman
  Rebecca Hauck
  Koji Ishii
  Dael Jackson
  Brian Kardell
  Philippe Le Hégaret
  Peter Linss
  Edward O'Connor
  Anton Prowse
  Matt Rakow
  Florian Rivoal
  Simon Sapin
  Dirk Schulze
  Alan Stearns
  Lea Verou
  Greg Whitworth

  Bruno de Oliveira Abinader
  Leif Arne Storset

 ScribeNick: dael

  glazou: Let's start
  glazou: Any extra items?
  glazou: I noted one from Tab about shadow vs ::shadow.
  glazou: We have a light agenda so may have time for more.

CSS 2.1 ED

  <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2014JanMar/0139.html
  <SimonSapin> http://www.w3.org/Style/css2-updates/css2/

  SimonSapin: So when working on implementations for CSS2,
  SimonSapin: I would like it to be up to date including the errata
  SimonSapin: It seems we have a ED but I'm not sure if it's really
              up to date.
  SimonSapin: If it's not, can we make it so?

  plh: Bert?
  SimonSapin: Is this a snapshot or up to date?

  bert: This is a snapshot. The real version is at
  bert: That's the ED and has been for 50 years or so

  <SimonSapin> http://www.w3.org/Style/CSS/current-work
  SimonSapin: So that URL...I think it would be beneficial for a
              public WD just like other docs.
  SimonSapin: Listed on current work.
  bert: I don't think it's useful to have it be public.

  ChrisL: We're charted as a public group so we should have
          everything public. Please move it.
  glazou: CSS errata is part of charter.
  bert: I don't like moving doc because we'd lose 15 years of
        comment history. If we do, I don't want to move to mercurial
        because it's a pain.
  <sgalineau> We shouldn't keep documents non-public because of
             personal dislikes of the version control system.
  <ChrisL> Do we really have to argue about the desire to have a
           member-only draft for this thing?

  SimonSapin: It's possible to import the history. We don't have to
              lose it.
  plh: Why don't you move it to Github instead of mercurial?
  bert: I don't know if that's easier.
  plh: The community around it is much larger. The mercurial doesn't
        have as many cycles.
  plinss: Our mercurial is mirrored.
  plh: Ok. that could work.

  fantasai: I think all our drafts should be in same repository so
            it makes easier for editors to help each other with
            their drafts...I don't think we should have just this
            one in github.
  bert: I think github is easier, but I don't want to move
        everything there.

  florian: I prefer git as well, but also think having everything in
           one place is more important
  florian: To put CSS 2.1 on mercurial we have to import the history.
  florian: So the proposal is to import into mercurial, even though
           we don't love mercurial. And maybe we should later
           consider moving elsewhere.

  <SimonSapin> If it helps, I can do the work of importing the
               change history from the CSV repository (given access).

  glazou: So Bert is it okay with you if SimonSapin helps you?
  glazou: It seems like it's consensus from the WG.
  bert: If someone can make a repository on mercurial, I don't know
        how to do that.
  bert: I only get errors when I use that one, I have a different
        one for this draft.
  ???: I have no idea how that happens.
  glazou: I never get an error.

  glazou: Wait...switching isn't the discussion. The question is
          moving the CSS2.1 document to or from repo.
  florian: I was agreeing. Mercurial might not be everybody's
           favorite, but it's what we've got.
  glazou: Bert, I'm sorry, but it's mercurial and SimonSapin will
  glazou: So it's an action on SimonSapin to help with hints from

  bert: I don't like losing history...the link will be gone.
  bert: It's member only so we can't put the history in the public.
        We're not going to look through 15 years of history for
        confidential stuff.
  <SimonSapin> The plan is to import *only* CSS2.
  <SimonSapin> Not anything else that might be in the same repo.
  <SimonSapin> It's also possible to truncate the import at some date

  glazou: ChrisL is there problem making things in the CVS go public?
  ChrisL: Technically yes, but in practice the comment history...the
          only point that might be unknown is anything since CSS 2.1
          was published.
  ChrisL: So in practice I don't see anything member only. It will
          be why changes were made. I can't think of anything that
          might be hard.
  ChrisL: Bert thinks there might. We either copy with our without
          comments. Either way it's public so people can look.

  plh: We don't know what's in that history. Some companies might
       have something in the repository they don't want public. I
       know what developer comments can be like.
  plh: Maybe allow people to look that are on members only. Let them
       say if they have concerns. If we don't hear anything we
  plh: That would help.

  <krit_> 2 weeks for reviewing a 50 years history?
  <ChrisL> Sounds like a good plan.
  glazou: It's unfortunate to wait, but it's a good compromise. I
          don't want ACs to fall because this decision.
  plh: In two weeks people can speak up.
  glazou: I hope it can be 1 week.

  Rossen: Are you expecting something?
  glazou: In theory everyone should look for controversial or
          problematic that needs to hide. If everyone doesn't have a
          problem that's fine, but we have former members.
  glazou: I know it sounds stupid, but because the way we used to
          work we need to do this.
  glazou: If we want the whole history.
  <tantek> Is there an open format for change histories / commit
           logs? a little export/import action?
  * sgalineau tantek, that just seems contrived

  florian: I'd suggest 2 weeks. It's lots of history.
  glazou: I'd like to close this. Is everyone okay with plh's idea.
  [general agreement]

  glazou: Bert, can you download the comments and send it to the
          private mailing list for everyone to review?
  bert: You want me to download all the comments?
  glazou: In a CVS.
  plh: I'm willing to take an action item to do it.
  glazou: You may want to deal with the former members.
  plh: Let's do it properly.
  glazou: Let's do it in two weeks. If we don't hear anything in two
          weeks, we bring all the comments over.

  SimonSapin: As I understand, the form for CSS 2.1...all the
              previous iterations are a part of it. I don't know
              what we want to move here.
  bert: The build is profiles written by Arnold and ??? and me. I
        don't know what's in the history of those.
  SimonSapin: Do we need to understand how it works, or just copy
              over as is?
  <fantasai> Simon was saying that the build system for CSS2.1 is a
             different system than the ones we use for the CSS3
             drafts, and he's not sure what's involved for moving it.

  glazou: In short, is the source format compatible with the new
  bert: No. The way we did it back then was complex. Same things we
        do now, different ways.
  bert: It's in the same directories, everything is there.

  glazou: We have two weeks. SimonSapin will you take that time to
          look in the CVS directory and see what you can do?
  SimonSapin: Ok.

  glazou: So, proposed resolution. plh will handle the log over the
          next two weeks. If no objections to it becoming public,
          SimonSapin will move CVS to mercurial. Ok?
  RESOLVED: plh will handle the log over the
            next two weeks. If no objections to it becoming public,
            SimonSapin will move CVS to mercurial.

  glazou: One more thing. There's discussion on charter milestones.
          Charles proposed a change that wasn't in line with WG
  glazou: I rejected it because I didn't think it was right. I'll
          ask you to write something to replace his prose.
  ??: Do you have a link?
  glazou: I'll see. It may be private.

MQ3 errata

  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Feb/0517.html
  florian: We've discussed and resolved to make these changes, but
           no one has done it.
  florian: Can we action someone to make the changes? There's not
           much to discuss.
  <ChrisL> maybe editor of MQ4 can do it?
  florian: I'm the editor in MQ4, but I don't have access to MQ3

  bert: I think ChrisL has made some changes, I may have too.
  ChrisL: If it's just publishing, tell me where and I'll make sure
          it gets done.
  florian: That should be the link that was pasted above in IRC.
  florian: I can clarify any questions.
  glazou: Is that okay?
  ChrisL: Yes. I see the link from glazou? That one?
  glazou: Yes.
  florian: And if anything isn't clear, just tell me

Font Loading LC

  <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2014JanMar/0162.html
  TabAtkins: You'll remember from Paris it was nearly done. It got
             feedback from jdaggett.
  TabAtkins: I forgot to publish the FPWD until last week. Still I
             think it's mature and has been reviewed.

  TabAtkins: I think it's stable and ready, let's go to LC, gather
             remaining feedback and do the edits.
  <sgalineau> which other implementors have reviewed it?
  * fantasai wants sgalineau's question answered

  ChrisL: So this is a fairly brief period, but this was previously
          in CSS3 fonts, right?
  TabAtkins: I don't recall.
  dbaron: It was, yes, although it was brief.
  TabAtkins: That was the old form, but yes.
  ChrisL: If you think it's stable, put it forward, and people
          disagree they'll let you know.

  TabAtkins: We do LC when we're done with design and we're done
             with design for this.
  glazou: On the website there's two issues in the doc. Shouldn't
          they resolved before last call?
  ChrisL: Yes.
  TabAtkins: I can go resolve the issues today.

  glazou: One is technical so we need time to review the fix.
  TabAtkins: Let me pull them up quick.
  florian: Is it something we can discuss without prep?

  TabAtkins: 2 issues. One is what the font-face does for works.
             It's basically done and just needs text
  TabAtkins: Second issue is about local fonts. I think it's easy
             and can be resolved. I just need to ignore them. The
             issue is do we need a special feature and I think we
             don't and we just drop it.

  fantasai: Has John Daggett done a really complete review like typo
  TabAtkins: Yes.
  fantasai: Did other people? Did they find anything?
  TabAtkins: Yes.

  Rossen: We looked at it but not that much depth.
  Rossen: I'm passing it on for more.
  glazou: So do you need more time?
  Rossen_: Let's get a week.
  glazou: Let's defer for a week so there's a bit more review and
          TabAtkins can make his edits.

CSS Masking

  krit_: There was a new WD pub two weeks ago. That was for more
  krit_: I'd like to remind people to look before we go to LC so we
         find as many issues as possible.
  krit_: fantasai had some issues from the first LC and I think I
         resolved them, but it would be great if she could look at
         it again.
  fantasai: Thanks for the reminder.


  TabAtkins: I've been talking over fantasai suggestion from last
             week about switching to pseudo elements.
  TabAtkins: Mostly I'm okay. For shadow and content it works.
  TabAtkins: Only one issue is with shadow-deep because it doesn't
             correspond to anything real.
  TabAtkins: fantasai explained it as switching to a virtual tree,
             but that is weird.
  TabAtkins: It wouldn't match anything is CSS. Potentially queries
             could return the shadow roots.
  TabAtkins: We're uncomfortable with making that as pseudo. We want
             that as a combinator.
  TabAtkins: Then it seems odd for them to be sometimes pseudo,
             sometimes combinators.

  fantasai: I'm not convinced shadow-deep needs to be a combinator
            because there could be something in the DOM. It's a
            thing you can talk about and define as existing.
  fantasai: That our DOM isn't structured shouldn't change the CSS
  TabAtkins: But we'll never have a DOM thing for that.
  fantasai: But it exists as a concept. So our syntax shouldn't be
            restricted. We should chose from conceptual consistency.

  bkardell: The shadow root looks okay, but shadow-deep root doesn't
            make sense as a thing to talk about instead of nesting
  TabAtkins: We talk about the composed tree, not something rooted
             at a post. So shadow-deep doesn't exist.
  fantasai: What you're doing is a sub tree of the tree.
  bkardell: It's a tree, though, real or conceptual.
  fantasai: If you're talking about foo, it's great grandmother's
            niece may have a shadow, but you wouldn't reach it.

  TabAtkins: My problem is this may let us define everything as a
             pseudo instead of combinator.
  fantasai: I don't think so.
  TabAtkins: The reference combinator could be seen as something
             hanging off in an alternate tree.
  fantasai: No. There's a connection, but no one is making a
            different tree for the child.
  fantasai: There's no child/parent there. It's just a link.
  TabAtkins: But that's all parent/child is. It's just a link.
  fantasai: That's too abstract.
  TabAtkins: I think your example is too.

  bkardell: Pseudo is supposed to select the whole tree. A pseudo
            element, not the whole tree
  bkardell: So, we can define it as the root instead of the whole
            tree. I think the concept is a bit off.
  TabAtkins: You can map it to whatever element is hanging off.
  TabAtkins: The tree isn't exposed. It won't be in any way.
  fantasai: Neither is ::first-line.
  TabAtkins: We plan to expose it more.

  bkardell: Is there any reason you'd need to piece some? Or do you
            intend to piece everything?
  TabAtkins: If you only want to grab a foo-button that's a
             descendant of some thing.

  TabAtkins: I think we should be more judicious to what we expose
             as pseudo elements to things that could be returned as
  TabAtkins: That seems to be a reasonable rule.
  TabAtkins: Attributes have that. Some representation of the DoM.
             Shadow, roots, work that way.
  TabAtkins: I don't think an element in the tree can be exposed
  TabAtkins: I don't think it's an ultimate node in a tree. And
             that's a pseudo element.

  TabAtkins: So...what do we do now? Fantasai and I have a knife
             fight and the winner is right?
  TabAtkins: Before we have a knife fight, any other opinions?
  Rossen: Are you planning on getting together for this?
  fantasai: Yes.
  rossen: I think we'd be interested in being there too.

  florian: think the conceptual is a bit off.
  fantasai: I'm worried that things like regions would be off from
            shadow DOM for esoteric reasons we discuss here.
  TabAtkins: Well and who knows what pages will use.
  florian: I'd rather have actual consistency than theoretical
           explanations about what should be pseudo elements.
  glazou: Will you report to mailing list about the results of the
  TabAtkins: Yeah.
  TabAtkins: Was that the last thing?
  glazou: Yes.

Counter Styles

  <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Feb/0523.html
  TabAtkins: I have a question. There's been a lot action on counter
             styles in the mailing list.
  TabAtkins: Xidorn gave a lot of feedback and on one topic we've
             been unable to agree and I'm going to have to reject it
             in DoC. Do we need a resolution for that?
  fantasai: Yes. Anything resulting in a significant change or
            significant rejection should be discussed.
  TabAtkins: Ok.

  TabAtkins: The Counter Styles draft has a number of ways for one
             thing to refer to another. That means there's a
             possibility of loops.
  TabAtkins: The 3 places you can loop is counter style fallback,
             the speak-as value, and in the override.
  TabAtkins: The override is the one under question.
  TabAtkins: Having a cycle isn't an error. It's useful to have
             counter styles that fall to each other for different
  TabAtkins: Speak-as doesn't do that. If there's an error it
  TabAtkins: There aren't any use cases for a cycle to be useful and
             I think it should create an error.
  TabAtkins: Xidorn has said that there should be cycles and they
             could be needed. Only if a given descriptor goes into a
             loop should we create a default.
  TabAtkins: The only time that's useful is when creating a
            compression. It seems like a silly trick and not a
            reasonable use case.

  TabAtkins: Xidorn's main argument against my position is that it
             requires cycle checking which is an abstract issue, but
             we already require it for fallback loops.
  TabAtkins: So it doesn't seem an undo amount of work.
  glazou: I guess you've explained this well. So, TabAtkins
          recommends to reject comments.  I agree with him. Other
  * fantasai defers to dbaron on this one?
  <dbaron> I'm here; I don't really have an opinion since I don't
           have a good sense of what override is used for.
  <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Feb/0729.html

  florian: It's without a use case so we should pick the simpler
           to implement.
  TabAtkins: I think they're both equally complex. It's a matter of
             if you look at scriptor at use time or later. I think
             they're equivalent.
  florian: In that case, why do you prefer yours?
  TabAtkins: Generally we treat things known to be errors as
             something to kill instead of something to repair.

  glazou: dbaron you there? fantasai wanted your feedback
  dbaron: I don't have a good sense of what override is used for so
          no opinion.
  TabAtkins: It's for when a counter style is almost right and you
             just want to tweek a little.
  dbaron: Are you requiring cycle detection in one descriptor, or
  TabAtkins: Currently required in speak-as. The override is within
             themselves. If there's a cycle detected we switch to
             override decimal.
  dbaron: What if you want to know what it's spoken as. Say, b
          overrides a and a has a speak-as to b?
  TabAtkins: So B has a speak-as to a and a is overriding b?
             That should be fine. There's no odd cycle there. The
             missing descriptor takes on the default and it'll speak-
  dbaron: a overrides b
  TabAtkins: Oh. So A will say I'm missing the speak-as. It'll grab
             from B. So A will have speak-as A as well.
  TabAtkins: So you look at speak-as A as auto. So B looks at it and
             says I'm auto as well.
  dbaron: Okay.
  TabAtkins: I made sure the things that refer to each other are at
             different levels so you can process in order and have
             it work.

  <fantasai> Maybe override isn't a very good name? It's not
             actually overriding the named style, just creating a
             new one based off it as far as I can tell.......

  glazou: After that, what do people think? Should we reject the
  plinss: To clarify, what you're proposing to reject is the
  TabAtkins: Yes. His proposal is to let cycles happen. If a loop
             happens, default that one descriptor, but let the rest
             take the value from there.
  plinss: Your position makes sense.
  plinss: The proposal makes more sense, but I'd like to be
          consistent. If the author defines it and it works 99% of
          the time, the 1% seems a surprise.
  TabAtkins: If the counter styles create a problem, we take care of
             that. The other is if descriptors create a look you get
             odd results.

  dbaron: I think plinss is talking about fallback.
  TabAtkins: There's no problem with fallback cycles. It renders as
             decimals if you literally cannot render in another form.
  TabAtkins: I think it's reasonable to recover there so you don't
             negate the entire thing.
  plinss: I'd rather things only fail when they need to and have
          everything be consistent.
  plinss: But I don't want to complicate everything.
  Florian: The proposals don't change when, but how.
  Florian: The loop will be detected in both. Do we invalidate
           everything in the loop, or only some?
  Florian: Either way we detect the loop.
  TabAtkins: That's correct.
  florian: Do we keep the thing that could be resolved despite the
  TabAtkins: I recommend that because it's going to be an error,
             kill the overrides entirely.
  <florian> +1
  Rossen_: I support TabAtkins that sounds most sane.
  glazou: Me too.
  glazou: We have 1 minute left.

  glazou: A resolution would be useful. Can we live with TabAtkins
  fantasai: Works for me.
  <ChrisL> Works for me too
  florian: Ok.
  dbaron: I'm okay either way
  fantasai: TabAtkins said failing early makes the mistake more
            obvious which is another benefit
  * SimonSapin fail early, fail often.
  glazou: So, the proposal: Accept TabAtkins's proposal and reject
          the comment.

  RESOLVED: Accept TabAtkins's proposal and reject the comment from
            Xidorn in the disposition of comments.

  glazou: I think that's it. Thank you everyone.
Received on Thursday, 27 February 2014 01:37:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:40 UTC