W3C home > Mailing lists > Public > www-style@w3.org > March 2015

[CSSWG] Minutes Telecon 2015-03-25

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 26 Mar 2015 06:22:20 -0400
Message-ID: <CADhPm3uAtzqwrefPL+3DQZAi36NP_PMKQy4w6xVFNjitwkze9A@mail.gmail.com>
To: www-style@w3.org
TPAC 2015

  - Everyone in the group was asked to respond to the e-mail from
      Bert regarding TPAC.

Review and Publication Requests

  - There is a two week review period for the Rounded Displays
  - RESOLVED: Publish Values and Units as CR
  - RESOLVED: Variables to CR
  - The proposed cuts to what items are in Lists (available here:
      seemed sound, so the editors will make them and request
      publication once they're done.
  - RESOLVED: Cascade Level 3 publish CR
  - RESOLVED: FPWD for Cascade 4
  - RESOLVED: Publish CR of will-change
  - The box-sizing review period was extended for another week.

Constructable Stylesheets

  - RESOLVED: Create an ED for TabAtkins' constructable stylesheets
  - Short name for now is cssom-construct

Intrinsic Sizes for multicol Elements

  - Defer for a week until dbaron is available.

'Font-rendering' property

  - Defer for two weeks to give time for mailing list review and for
      TabAtkins to be available on the call.

Media Queries

  - Microsoft requested a week to review the proposal of changing
      'should' to 'must' in the following sentence: "User agents
      should re-evaluate media queries in response to changes in the
      user environment"

Page-Specific Properties Outside of @page Context

  - There were several different viewpoints on this, so discussion
      will continue on the mailing list.


  Rossen Atanassov
  Tab Atkins
  Sanja Bonic
  Bert Bos
  Bo Campbell
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Brian Kardell
  Toru Kawakubo
  Brad Kemper
  Chris Lilley
  Simon Pieters
  Anton Prowse
  Florian Rivoal
  Andrey Rybka
  Simon Sapin
  Alan Stearns
  Ian Vollick
  Greg Whitworth
  Steve Zilles

  David Baron
  Adenilson Cavalcanti
  Tantek Çelik
  Simon Fraser
  Peter Linss
  Michael Miller
  Edward O'Connor
  Lea Verou

  glazou: Let's start.
  glazou: Any extra items?
  Florian: Maybe a quick one on Media Queries
  glazou: Let's try to do that after item 3 or something like that.
  glazou: Anything else?

TPAC 2015

  glazou: Please take a look at the message from Bert about TPAC
          2015. It will happen in Japan.
  glazou: We need to pick meeting dates and if we need a big room,
          etc. We usually take the first part of the week so let us
          know if there's a problem with that.

Review and Publication Requests

Rounded Displays

  glazou: Let's do the first one from LG. They proposed rounded
  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0358.html
  glazou: The document is under dev.w3.org and they asked us to
  Florian: I've been meaning to review.
  TabAtkins: Same here.
  glazou: I think they did things pretty well. They came with
          questions, then a proposal, then a document and an
          implementation. I suggest we review the document ASAP.
  glazou: For a first contribution it's a big one.
  glazou: Let's take two weeks for review. It's not a small doc.

Values and Units

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0352.html
  glazou: We have a request on Values and Units CR
  glazou: fantasai are you there?
  fantasai: We finished the custom-ident edits and the changes
            section is up to date. We would like to publish as a new
            process CR.
  glazou: So publish a new CR?
  <Bert> +1 to new CR
  <Florian> +1 to new CR
  <TabAtkins> +1
  <SimonSapin> +1. I reviewed the changes, looks good.

  ChrisL: There's a DoC or something to indicate adequate review?
  <fantasai> http://dev.w3.org/csswg/css-values-3/issues-cr-2013
  <fantasai> Disposition of comments ^
  <ChrisL> ok great
  TabAtkins: Yes, we do have a DoC put together
  <Bert> -> http://dev.w3.org/csswg/css-values/issues-cr-2013 DoC
  ChrisL: The DoC looks good. +1
  <astearns> +1

  glazou: Objections?

  RESOLVED: Publish Values and Units as CR

  glazou: Who will deal with publication?
  ChrisL: I can.
  glazou: Thank you.


  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0356.html
  glazou: Next is from TabAtkins. A request for another CR for
  TabAtkins: Its never been CR. I've prepared the DoC so everything
             should be good to go.
  <bkardell> +1
  <astearns> +1
  glazou: Objections?
  <Bert> +1 to CR

  RESOLVED: Variables to CR

  glazou: ChrisL will you do that too?
  ChrisL: I can. Can I get a link for DoC?
  ChrisL: And the changes list if up to date?
  <Bert> http://dev.w3.org/csswg/css-variables/issues-lc-20140506.html
  TabAtkins: Should be.


  glazou: Next is Lists.
  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0363.html
  glazou: That's from fantasai.
  <TabAtkins> display: inline-list-item
  <TabAtkins> defining list numbering in terms of the implied 'list-
              item' counter
  <TabAtkins> list-style-image: <image> | none
  <TabAtkins> (instead of list-style-image: <url> | none)
  <TabAtkins> list-style-type: <counter-style> | <string> | none
  <TabAtkins> (instead of list-style-image: <css21-defined-counters>
              | none)
  <TabAtkins> font/color marker styling by reference to ::marker in
              Pseudo Elements L4
  <TabAtkins> counter-set property
  fantasai: That's not just a publication request. It's a we should
            do this and discuss if these are what we should keep.
            Then TabAtkins and I will make edits.
  Florian: I was generally okay with the proposal. I was wondering
           if we want font color styling.
  fantasai: That's in pseudo-elements. The ability to style is in
            the level 4 draft. We'll include it by reference.

  glazou: So we'll revisit this.
  glazou: Let's move to the next one.
  Florian: Why move on? There's a question to answer.
  glazou: Okay. Go ahead.
  Florian: So do we try and trim the spec and go to CR?

  fantasai: The proposal I have there, which was inline-list-item as
            a display type.
  fantasai: Let me find the message.
  TabAtkins: I pasted it as text above.
  fantasai: The proposal is to trim it to the things in 2.1.
  fantasai: [Reads what is in IRC above]
  <Florian> I agree with the proposal.
  fantasai: Those were the things that we stable for the design.

  fantasai: Basically there's still going to be details to work out,
            but I think no one has concerns on design for these. So
            is there anything the WG thinks shouldn't be one this
            list? We can then trim to this list or some subset of
            this list so we can get something that's stable. That's
            why we cut the marker pieces because that's tricky.
  Florian: Even for reference, the link to the part of markers is
           tricky. We might have to cut that if it gets pulled. I
           don't think that will happen, though.
  fantasai: It's not going to happen.
  <fantasai> Colors and fonts are fairly harmless
  Florian: Then I'm good with that bit.
  <Florian> To the extend that ::marker continues to exist (which it
            probably will), fonts and colors are harmless.
  glazou: If that's done, let's move on.

Cascade 3

  <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015JanMar/0200.html
  glazou: Next is Cascade.
  fantasai: TabAtkins and I did cleanup. There wasn't much; mostly
            editorial. We also decided since we wanted the default
            keyword and @import rule we should start a level 4 draft.
  <fantasai> http://dev.w3.org/csswg/css-cascade-3/#changes
  fantasai: Basically it's trivial changes on level 3 and we'd like
            to republish that. We'd like the also do FPWD for 4.
  glazou: We'll do level 4 second.

  glazou: Your e-mail link was broken for DoC.
  fantasai: Add -3 to the url and it works.
  glazou: OK
  <glazou> http://dev.w3.org/csswg/css-cascade-3/issues-cr-2013

  glazou: No objections. Any comments?
  Florian: I have a few minor comments, but I agree we should update
           the spec. So yes to level 3 and 4.
  glazou: One thing at a time. First level 3. Any other comments?
  <Florian> the minor comments applied to level 4.
  <Bert> (I'm in favor, as I said in mail.)
  <ChrisL> +1
  glazou: Objections? I only heard 2 okays.
  TabAtkins: Okay.

  RESOLVED: Cascade Level 3 publish CR

  <ChrisL> DoC and changes ok for cascade 3 CR?

Cascade 4

  <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015JanMar/0207.html
  glazou: And then the request to publish level 4 of cascade.
  glazou: That's a FPWD request.
  Florian: I'm in favor of getting it out. If it's ED or if we get
           both at the same time, I don't care.
  fantasai: It's very trivial changes. I don't think there's a need
            for ED.
  Florian: Maybe only if we want to add more things and have them
           covered by the legal review. I don't strongly care.
  glazou: I have no opinion.
  glazou: What do others think?
  <ChrisL> seems good to publish it
  <bkardell> +1 what Florian said, no strong opinion tho
  <TabAtkins> FPWD plz
  glazou: No one cares?

  RESOLVED: FPWD for Cascade 4

  <fantasai> Bert, I just added the missing supports() change to the
             Changes list in Cascade 4
  <Bert> thanks fantasai


  <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015JanMar/0202.html
  glazou: Next is TabAtkins...will-change
  TabAtkins: The will-change spec has had no change in the last year.
  <TabAtkins> http://dev.w3.org/csswg/css-will-change/issues-20140429-wd.html
  TabAtkins: I have two comments. There's a DoC and they're both
             addressed, so lets take it to CR.
  <ChrisL> any tests?
  glazou: How many implementations?
  TabAtkins: Chrome and FF. I'm not sure on Safari or IE.
  glazou: Any tests?
  TabAtkins: I haven't written any tests.

  glazou: I'm in favor of publication.
  fantasai: I'm in favor
  <ChrisL> +1
  <Florian> +1
  <bkardell> +1
  <andreyr> +1 to publish
  <sanja> also +1
  glazou: Any objections?

  RESOLVED: Publish CR of will-change

  glazou: There were so many publication requests. Did I miss a
  Florian: For publication I don't know, but for review, yes.
  glazou: Any other publication requests?


  glazou: Okay, review
  Florian: The 3 week review for box sizing is over today. I got
           feedback only from fantasai some of which I agreed and
           included. No one else has replied.
  <Florian> https://lists.w3.org/Archives/Public/www-style/2015Feb/0445.html
  Florian: The URL is here ^

  glazou: What are you going to do? Close the feedback period?
  Florian: I need more feedback. This is something we don't want to
           break so implementors need to review. It doesn't make
           sense to make an unreviewed change when we're not sure if
           the change is correct. That's highlighted by the fantasai
           comments. There's two parts to this: first is this change
           correct and second if it is phrased well.
  Florian: Those both need to be addressed, mostly I need to be sure
           it's correct.
  glazou: We gave three weeks and it wasn't enough. How much more
          time should we give?
  Florian: I don't think it's a matter of time, it's a matter of
           doing it.
  glazou: Let's give an extra week?
  Florian: I don't have editor rights on the spec anyway.
  glazou: Okay, let's do an extra week and action everyone.
  Florian: If someone could ping Boris Z. Specifically that would
           help since he had this issue.
  glazou: I'm not sure if we have anyone from Mozilla...There's
  Florian: I copied Boris on the mail, but not directly.
  glazou: You should send him an e-mail.
  Florian: Okay.
  <SimonSapin> I can email Boris if it helps

Constructable Stylesheets

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0320.html
  glazou: This is an old problem of the CSSOM and I thought it was
          worth and explanation
  <bkardell> It seems like 2 things, I'm interested in both
             construction and "issue 3"
  TabAtkins: Right now you can't construct a stylesheet directly.
             This works generally, but if you want to share one
             across several things, you have to duplicate them and
             hope you can dedup in the engine.
  TabAtkins: That's the basic reason for my proposal so we can share
             the same object. There's another bit I'd like to tack
             on from the drawbacks of the authors using the deep
  <bkardell> I think what TabAtkins just said was one problem apple
             had with it, right?
  TabAtkins: They're using deep as a rule and it's killing
             performance. If we could set up some new origin for
             stylesheets that might work or if we have more API on
             the stylesheet objects. So that's not strictly tied,
             but I'd like to discuss that.

  TabAtkins: So stylesheet as a constructor, how do we feel about
  <bkardell> +1 to stylesheet that is constructable.

  TabAtkins: I have two API ideas. One is another stylesheet list
             that's author mutable.
  TabAtkins: I don't have strong opinions on how you put it on a
             document, just that this should be possible.
  glazou: Questions?
  <astearns> +1
  glazou: Okay. Thank you TabAtkins
  <bkardell> (This would be good to review at the Extensible Web
             Summit in April)

  TabAtkins: So, within that construct, should I get a publish
             agreement for this?
  glazou: Do you think you have enough feedback? You should probably
          continue aggregating feedback. I'm sure you'll have
          questions about the assignment of a stylesheet. So when
          you have one constructed stylesheet and you put it on two
  TabAtkins: Yeah. And I'm thinking this will merge into CSSOM.
             We'll get further feedback.
  fantasai: You could put it in the repo as an editor's draft or
            unofficial draft.
  TabAtkins: I'm fine with putting it as a unofficial draft in the
  TabAtkins: So objections to me putting this is a repo as a
             unofficial draft?
  <bkardell> +1
  glazou: So objections?

  fantasai: If we agree we should work on this, an ED should make
  glazou: I agree on ED. This is an important topic.
  glazou: Objections on an ED?
  Florian: I'm not close enough to have solutions, but it makes

  RESOLVED: Create an ED for TabAtkins' constructable stylesheets

  glazou: Shortname?
  TabAtkins: I'm not happy with mine.
  fantasai: cssom-construct?
  glazou: That's fine.
  <ChrisL> You don't need to finalize on a shortname until FPWD
  glazou: That's true ChrisL but if we get ti right the first time
          it's simpler.
  <ChrisL> True.

Intrinsic Sizes for multicol Elements

  glazou: Next is intrinsic sizes for multicol elements
  fantasai: We should wait for dbaron.
  glazou: And the same thing with the next topic?
  fantasai: Yeah. Is MS on the call?
  Rossen: Yes.
  fantasai: If you guys can look those over it would be great.
  Rossen: Okay.

'Font-rendering' property

  glazou: I added TabAtkins font-rendering, but jdaggett asked us to
          defer that to next week so it can continue on the ML.
  TabAtkins: I won't be on the call next week, so we should defer
             for two weeks.
  glazou: Okay. Two weeks.

Media Queries

  <Florian> https://lists.w3.org/Archives/Public/www-style/2015Mar/0469.html
  Florian: MQ4 has this statement: "User agents should re-evaluate
           media queries in response to changes in the user
  Florian: It's reasonable, but it should be a must. I remember
           there might have been a reason for should.
  fantasai: I think it was an implementor issue.
  Florian: So if we had switched to a must if it would have delayed
           MQ3, but that's no longer relevant, so we can switch. The
           other plausible reason is so that we can allow a special
           class of user agents to layout once and then never update.
           If we're interested in that, fine, but then we should
           make a specific exception rather than relaxing the
           requirement for everyone.
  Florian: So can we just do must or make an exception for
           render-once-and-forget UAs?
  fantasai: They also care about the size of the containing block,
            so that would be a whole different thing for them. I
            think we can just do a must.
  glazou: Everyone agrees?
  <andreyr> +1

  Rossen: On exactly what?
  Florian: The change from should to must.
  <Florian> "User agents should re-evaluate media queries in
            response to changes in the user environment" should ->
  Rossen: And what were the original reasons for should? Which
          implementations were considered and what were the reasons?
  fantasai: I think it was Opera. Some early implementors of MQ in
            any case.
  fantasai: I don't remember clearly.
  <zcorpan> maybe background tabs?

  <ChrisL> are there any tests for immediate re-evaluation?

  Rossen: What do current implementations do?
  fantasai: They update.
  Florian: In a vast majority they update. There's a few exceptions
           that I believe are bugs. For example I've heard some
           browsers that impl hover don't update if you plug in a
           mouse. Having it as a must will make it more clearly
  Rossen: Okay. Any test cases?
  Florian: No. I just heard of this today.
  Rossen: Okay. I'd push back until we know current state.
  <bkardell> why isn't it must already though?
  fantasai: You can use...I can put up a test case.
  Rossen: So we'll test, observe what implementors do, and discuss
          next week.
  <fantasai> Testcase for width:

  Florian: I'm unsure what tests you want. If the question is does
           every implementation of every MQ do, it's hard to test.
           If there's a good reason for not must that's interesting.
           But fishing for every bug everywhere, what will the test
           tell us?
  Rossen: There were certain reasons considered when it was first
          agreed as a should. If we're changing to must we should
          have a fairly good confidence that those reasons are no
          longer valid. I don't know the history, but I want to know
          what this means for us and I currently don't.
  Rossen: Right now, I won't vote for this.
  Florian: If you want an extra week to look on your side, that's
           okay. But taking time to go fishing to see if someone is
           breaking without a specific reason in mind, that's less
  Rossen: What do you mean about reason in mind
  Florian: If we find someone doesn't, but don't know why, we don't
           know if that's a bug.

  Rossen: So do we remember why it was a should?
  <bkardell> it would help to review the reasons for should initially
  <fantasai> http://dev.w3.org/csswg/mediaqueries3/
  <ChrisL> presto did not update, I suspect
  fantasai: Implementations that don't update. If we look at MQ3
            there's no reason not to update unless there's an
            implementations that thought it was hard. There's a test
            case I pasted above that shows that they all update.
  fantasai: You might be able to argue on the newer stuff, but none
            of the logic that applies to the item in level 4...
            anything in level 3 there's no reason not to update it.

  <zcorpan> You might not want to evaluate MQ for background tabs.

  glazou: We're at a block here. Microsoft is requesting a week of
  Florian: I'm comfortable with a week of review. I don't want to
           spend a week checking to see if someone isn't complaint.
  Rossen: I didn't suggest that.
  glazou: Let's give Microsoft another week. Defer to next week.

  <gregwhitworth> tabatkins: how would this affect sizes?
  <TabAtkins> gregwhitworth How would what affect sizes? The
              sizes='' attribute for respimg?
  <zcorpan> gregwhitworth sizes='' gets evaluated as part of "img
            environment changed" algorithm, which itself is
            currently a "may" (but there's an open bug on making it
            more like must, except not for background tabs)
  <gregwhitworth> zcorpan: that's what I was curious of, just didn't
                  want this to force a must, but we'll end up at
                  some point making it trigger as a must

Nested Fragmentainers and Break Types

  glazou: Do we want to discuss that now?
  fantasai: I'd rather do that on the list. I haven't reviewed all
            the issues yet.

Page-Specific Properties Outside of @page Context

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0387.html
  <ChrisL> do they get thrown out during parsing if outside @page?
  glazou: In the property box we have a line saying this is for
          @page, but we didn't say what that means. Is it restricted
          to page or do we have the property outside?
  TabAtkins: We don't have them outside. They're not valid
             descriptors for other rules.
  Florian: They're descriptors that behave like other properties.
  <SimonSapin> TabAtkins, they are properties

  ChrisL: Do they get thrown out during parsing outside an @rule?
  TabAtkins: They're not a valid property.
  ChrisL: Then they won't show outside OM.
  SimonSapin: In same context we accept other properties that aren't
              part of rules.
  TabAtkins: @page is weird. They have so many descriptors that look
             like properties.
  Florian: But we can't apply properties in the same spot.

  TabAtkins: Just like how @fontface that has descriptors that are
             named the same as properties.
  TabAtkins: They're a different construct entirely. They're not
             interpreted outside.
  <ChrisL> it seemed easier at the time to name the descriptors the
           same as the corresponding properties

  glazou: Can someone post on IRC a link to where this is?
  <SimonSapin> http://dev.w3.org/csswg/css-page/#page-properties
               6. Page Properties
  <SimonSapin> "Appendix A defines the normative list of CSS 2.1
               [CSS21] properties that apply to page boxes."
  glazou: So paged media 3 we have a block of declarations that's a
          list of properties and values.
  glazou: It says page properties, not page descriptors.
  <ChrisL> daniel seems to be asking that we fix the spec so it says
           what we know it means.

  Florian: I agree on TabAtkins logic, but I'm not sure the spec is
           written properly.
  TabAtkins: Sure.

  SimonSapin: You gave the example of @fontface, but it defines them
              as proxies. For page they have the same meaning and
  TabAtkins: So if they're the same you can defer to the same...
  glazou: They're not closely related. The first are about a font
          selection mechanism, but this isn't a page selection
  <SimonSapin> http://dev.w3.org/csswg/css2/page.html#page-margins
               In CSS 2.1, only the margin properties ('margin-top',
               'margin-right', 'margin-bottom', 'margin-left', and
               'margin') apply within the page context.
  <Bert> (@page is a kind of box, @font-face is not, so you expect
         different things for its properties/descriptors./)
  fantasai: SimonSapin is right, they're property and apply to
            boxes, that it's using @rule syntax is odd for
            historical reasons. It probably should have been a
            pseudo element and that's how it works for the most part.
  fantasai: I think that @page is a ::page and everything behaves
            like that. But it was originally designed as an @rule so
            there will be funniness. But there are properties that
            only apply to @page and make no sense outside the

  fantasai: I think it would be more simple if they're thrown out
            instead of hanging out in the OM.
  TabAtkins: That would be new. Properties are properties and they
             can hang out. So it's either a property or a descriptor.
  TabAtkins: And charting a new ground to keep them from linking,
             let's just call them descriptors.
  fantasai: Because they're properties and inherit and cascade.
  Florian: And will this be influenced by the new ability to nest?
  TabAtkins: If we redefine the styling, they will be pseudo
  Florian: But @page can reasonably apply to anything.
  TabAtkins: I don't think we can do it syntactically.
  fantasai: We have the property for the syntax to style those thing.
            If you drop the second half of the selector that comes
            after the page.
  * BradK agrees with Elika generally, but the 'size' property
          should be like 'content' outside of a pseudo-element.

  glazou: I think we're diverging. So should a property like size be
          exposed outside...
  fantasai: I think it should be no, it should not show up. But you
            can check for support in the @support.
  glazou: I'm not sure about your two proposals because some
          implementors may depend the second on the first. So if
          it's parse-able in the first case, it's parse-able when
          implemented so I'm not sure you can't relate the two of
  TabAtkins: I agree. It would be new syntactic way of doing an
  Florian: I think we need to say @page is a pseudo element that's
           just odd so that it is treated like a pseudo.
  glazou: It behaves like a pseudo element.
  SimonSapin: It also inherits from the root element.
  glazou: It's like properties.
  TabAtkins: Inheritance is in counter styles. It's not just
             something only properties can have.
  fantasai: We inherit between elements too.

  glazou: So there's two positions here. I suggest you contribute
          your views to the thread on www-style. We'll revisit when
          there's consensus on the ML.
  glazou: But it's an issue we have to solve.

  glazou: That's the hour. Thank you very much and talk to you next
Received on Thursday, 26 March 2015 10:22:51 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:49 UTC