[CSSWG] Minutes Telecon 2014-04-30

Charter Update
--------------

 - Plh plans to send the charter in by the end of the week.

CSS Masking LC/Rename mask-box to mask-border
---------------------------------------------

  - RESOLVED: Change mask-box to mask-border
  - Krit and fantasai brought the group's attention to the changes
        made to Masking and asked for review before a decision on
        going to LC.

Proposal to split CSS Text level 3
-----------------------------------

  - There was a lot of concern about splitting Text into smaller
        pieces since they are highly related.
  -A few potential smaller splits were discussed and a look into
        what pieces were holding the spec up most was advised.
  - The details of a potential split was declared to be perfect for
        a F2F conversation.

Calc() in MQ
------------

  -   RESOLVED: No change to calc() in MQ

Box model/Render tree
---------------------

  - Due to the lack of immediate concern, this was declared another
        great F2F topic.

inline-x auto-sizing
--------------------

  - There was some concern about it not being easy to standardize
        atomic inlines.
  - Fantasai will come up with some proposed text.

Changing MediaQueryList to use events
-------------------------------------

  - Defer to mailing list.

Scrollbar Stickiness
--------------------

  - Also staying on the mailing list.

Adding any-pointer and any-hover MQs
------------------------------------

  - There was a request for more time to read up about this proposal.
  - MaRakow and TabAtkins will discuss technical details about the
        proposal on the mailing list.

officially using the behavior of 'animation' wrt parsing
  <custom-ident>s in properties.
----------------------------------------------------------

  - TabAtkins stated that he needs to go back to this text and come
        up with another draft before consideration.

Seoul F2F
---------

  - WG members were reminded to add discussion topics to the wiki
  - Anyone that hasn't already reserved their hotel room show do so
        ASAP.

Variables
---------

 - RESOLVED: New LC for Variables

Revisiting calc() and whitespace
--------------------------------

  - Zcorpan drew attention to his e-mail with the same subject and
        requested review for discussion on next week's call.

====FULL MINUTES BELOW=======

Present:
  Glenn Adams
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Dave Cramer
  Elika Etemad
  Daniel Glazman
  Koji Ishii
  Dael Jackson
  Brian Kardell
  Philippe Le Hégaret
  Shinyu Murakami
  Edward O'Connor
  Simon Pieters
  Matt Rakow
  Florian Rivoal
  Simon Sapin
  Dirk Schulze
  Alan Stearns
  Greg Whitworth
  Steve Zilles

Regrets:
  Brad Kemper
  Peter Linss
  Michael Miller
  Anton Prowse
  Lea Verou (briefly in attendance, but had connection issues)

ScribeNick: dael

Charter Update
--------------

  glazou: Let's start
  glazou: We have a full agenda, but any extra items?
  glazou: Sorry for that
  glazou: Any extra items?

  plh: I can do a short charter update.
  plh: So I've got all the necessary stuff to send the charter to AC.
  plh: I expect to send by end of the week at the latest.
  glazou: Any questions?

CSS Masking LC/Rename mask-box to mask-border
---------------------------------------------

  <krit> http://dev.w3.org/fxtf/css-masking-1/#box-masks

  glazou: So the first issue is the rename.
  krit: This was a request from the last call. The reasoning was
        mask-box is similar to border image so it mostly affects
        ordering.
  krit: The request to was rename to mask-border since that
        describes what it does.
  krit: The cost for that is that boxes have a border. Also box is a
        rectangular shape so that might be good for SVG shapes.
  krit: But I don't have a preference. I like box or border. I'd
        like to hear concerns about renaming.

  fantasai: I'd like to note there's other things for masking. One
            related is there's a fill keyword in mask-slice which is
            similar to border image.
  fantasai: Like border image, mask doesn't affect the middle so it
            is like a border.
  krit: So that would be a vote for mask border.

  krit: Any other issues/concerns?
  rossen: Did any reasons to not rename get raised on the mailing
          list?
  krit: Just my pros and cons.
  rossen: So it sounds like no one else objects to border?
  krit: No.
  rossen: So it's fine than.
  glazou: So is there any objection?

  rossen: The only one is there's the mask-border...There's left,
          right, top, and bottom parts and for mask even though it
          can be just a single border?
  krit: There's a mask border property in the future that takes four
        arguments. It's an offset for tiles. There isn't longhand
        for each side.
  krit: Does that answer your question?
  rossen: Yes. It's going to be like borders in that respect?
  fantasai: Borders can't take image. It doesn't have per-side.
            There's one setting for the whole box.
  rossen: Ok.

  <dbaron> So this is the mask property that's analogous to border-
           image, and we're now calling it mask-border?

  krit: So can we get a resolution?
  rossen: One more. Do you want to change to mask-border to reserve
          the shorthand or is border-mask another option?
  rossen: As fantasai pointed out, I'd expect the border-mask so
          that way it would be clear.
  fantasai: If it was border-mask, I'd expect only border to be
            affected but this does the whole element.
  fantasai: So I think mask-border is correct. If we add border-mask
            that would just do border.
  rossen: That would be crazy.
  fantasai: Yes. My point this the effects the whole thing.
  rossen: Are we sure we'll never do that?
  fantasai: I don't think we can ever be sure.
  rossen: By choosing mask-border we prevent border-mask.
  fantasai: Well, if we choose that now we can't have border-mask.
  rossen: So you think that this won't prevent things in the future?
  fantasai: We can never know for sure about things in the future,
            but hopefully it'll be fine for now.

  glazou: dbaron asked in IRC if mask property is analogous to border
          -image and we're now calling it mask-border
  fantasai: Yes.
  glazou: So is there any objections?

  RESOLVED: Change mask-box to mask-border

  glazou: So back to item 1 on the agenda. LC for masking?
  fantasai: There's more issues I think we should discuss.
  glazou: That's the only one I was told about.
  fantasai: One was there's mask-type about using alpha or luminance
            to interpret image, but there wasn't an analog to mask-
            border so we added that type.

  krit: Biggest change was that I added layers to mask property
        similar to background and mask-composite to allow you to
        composite layers.
  <krit> http://dev.w3.org/fxtf/css-masking-1/#the-mask-composite
  krit: That's linked here (above)

  krit: What I want to do is ask for 1 or 2 weeks review so everyone
        can look at the changes and then go to LC if there's no
        objections.
  glazou: What do people think?
  fantasai: I'm in favor of review period.
  Several: yes
  glazou: Any objections against that?
  [silence]

  krit: Do we want to bring it up during the F2F?
  krit: Or do we just go to LC automatically?
  fantasai: I think we should talk again.
  glazou: I agree. I think 2 weeks review and all questions can be
          addressed in the week before the F2F since that's a bit
          more than 2 weeks.
  glazou: So that's a good time to discuss issues.
  krit: Okay.

  Action everyone review CSS Masking and send comments

  <fantasai> lea, can you help get feedback on the spread radius
             changes from the authoring community?
  <leaverou> fantasai: yes, but I will need some help on what to ask

Proposal to split CSS Text level 3
-----------------------------------

  <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2014AprJun/0036.html
  [Members only list]

  koji: The idea is the spec has been split several times. In the LC
        we have more than 70 issues and I think that means that it
        just keeps getting issues and therefore delayed.
  fantasai: My concern is with the fact that a lot of these features
            are interrelated so I'm hesitant to split the spec more
            than before.
  fantasai: Maybe if we have a solid base as 3 and do additions as
            partial modules, but I think I'd prefer to churn through
            the issues.
  fantasai: I think the problem is no one looked at the spec until
            we are in LC
  koji: Like textbox is interactive so there will be interaction
        between specs. I don't see...
  fantasai: The relation between justify and align and spacing is
            very tight. It's not just vocabulary. If you change the
            alignment, than justification changes.
  koji: I agree.

  <Bert> q+ to ask if we know what part is the slowest and if we can
         put some effort into solving it.

  koji: Perhaps it should have spacing in that one spec.
  koji: Maybe break out white space and text transformation.
  fantasai: We could, but that's too small.
  koji: Okay.
  koji: Um.

  Bert: I'm still undecided for what's best, but do we know what's
        the slowest part and can concentrate on that?
  Bert: If you don't know the slowest, maybe splitting is the only
        way, but I'd rather keep it together.
  rossen: Is it possible to focus on the hard problems first and
          after that reconsider a split?
  glazou: Unless there's a firm proposal, I suggest we go to e-mail.
  koji: What to e-mail?
  glazou: The discussion on how to split. Otherwise we'll spend a
          lot of telecon time
  rossen: Is the question how or if?

  krit: I think the biggest problem is that the spec can grow. In
        the last TPAC Kenny raised indentation questions and that
        added to the spec.
  krit: On the other hand line break and alignment do require
        discussion. The size and broadness is making progress slow.

  glazou: Okay.
  rossen: So back to the list?
  glazou: That or dedicate F2F time.
  glazou: We have to have a really complete discussion in the same
          room.
  glazou: It's too big for telecon time

Calc() in MQ
------------

  TabAtkins: This topic was raised by zcorpan.
  TabAtkins: He thinks calc() is low value in MQ so we should
             disallow it to simplify MQ.
  TabAtkins: I disagree and think language consistency is preferable
             since calc() is just a length and it should be allowed
             everywhere length is in CSS.
  TabAtkins: Making arbitrary wording due to implementor concerns
              makes the language harder to learn.

  glazou: I don't think he was arguing on implementor constraints,
          but on use cases.
  glazou: But I agree that consistency matters and I'm with you on
          that front.
  TabAtkins: He did also raise for implementor issues because we're
             using it in sizes and that does make it more complex.

  zcorpan: My main reason was lack of use cases, but it seems
           there's implementor interest so if browsers will
           implement it I don't object.
  florian: Implementor interest is there, no one has said it's a bad
           idea, but no one is rushing to it.
  zcorpan: I saw Mozilla had interest in implementing as well.
  zcorpan: I raised this because we're doing authors a disservice if
           it's not implemented but we pretend it exists.

  fantasai: To help on that front, maybe add a note on level 3
            saying calc() isn't there, and say on level 4 that we
            are including it, but it's at risk.
  fantasai: That way it's clear that anyone using MQ3 it doesn't
            have calc()
  florian: But why would MQ say anything about that?
  TabAtkins: It should be where lengths are allowed.

  hober: I'm fine with fantasai's suggestion, but I think it's
          easier for us to restrict it now then realize it's a
          mistake and restrict later.
  florian: MQ3 is already a rec and I'm not sure we should edit a
           rec to remove something we're planning to add later. It
           doesn't mention calc() in the first place and if we want
           this it feel better to talk about calc() than MQ

  TabAtkins: And some people are planning on implementing calc() in
             MQ now.
  TabAtkins: Since zcorpan drops his objection if there's
             implementors, I suggest no change.
  TabAtkins: Any objections to that?
  <SimonSapin> +1
  zcorpan: Works for me
  glazou: Other opinions?
  <glenn> +1
  SimonSapin: I agree
  several: I agree
  glazou: So any objections against no change?

  RESOLVED: No change to calc() in MQ

Box model/Render tree
---------------------

  TabAtkins: I think this is best addressed at F2F.
  TabAtkins: It's more blue sky. Something for the future.
  glazou: Bkardell, does that work for you?
  bkardell: I won't be at F2F, but it works.
  glazou: Can you join for one part?
  bkardell: I think so.
  TabAtkins: I can try and represent for him too.
  <SimonSapin> (I unfortunately won't be at the F2F either but I'm
               interested to call in for this)

inline-x auto-sizing
--------------------

  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Apr/0225.html

  glazou: fantasai, this is you.
  fantasai: What was it again?
  glazou: It was from last week's call, plinss had it on.

  SimonSapin: It talks about generalizing the width calculation with
              non replaced atomic inlines.
  TabAtkins: This is asking for 2.1 errata generalizing something
             that's for inline-block right now to apply to all
             atomic inlines

  glazou: Is there anything to discuss on telecon for now?
  fantasai: Well, does anyone object to the idea or should I come up
            with wording to propose an errata?
  bert: Nothing to object, for CSS2.1 it seems like you might say
        the same thing.
  fantasai: We have the flex so if this was changed to all atomic
            inline, other specs could just say it's atomic inline
            and than other specs won't have to duplicate and we
            reduce errors.
  bert: I'm not sure that helps. For example, baseline alignment
        various atomic doesn't work the same.
  fantasai: This is just margin and width
  bart: But the concept..
  fantasai: The concept exists in CSS2.1 already.

  <SimonSapin> q+ to say that inline-table is an atomic inline but
               is special sizing behavior, IIRC
 * florian sorry, got to leave. If we reach topic 10, I defer to Tab

  SimonSapin: I wanted to mention there are inline-tables that have
              special sizes so perhaps it won't be that easy to
              generalize.
  ??: What did he say?
  glazou: fantasai, can you repeat what SimonSapin said?
  fantasai: He said that inline tables have a special sizing so
            perhaps it won't be that easy to generalize
  <SimonSapin> I'm not sure, though

  glazou: It seems this requires more work or at least a text
          proposal so let's decide that approach and move on.

Changing MediaQueryList to use events
-------------------------------------

  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Mar/0603.html

  glazou: Do we need to continue the discussion on this?
  glazou: Anyone willing to continue, or do we move on?
  TabAtkins: I haven't picked this up on the list so I need to do
             that.

Scrollbar Stickiness
--------------------

  glazou: Same question here.
  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Apr/0112.html
  TabAtkins: This would also benefit from staying on list.

Adding any-pointer and any-hover MQs
------------------------------------

  TabAtkins: Currently the pointer and hover let you query aspect of
             the pointing device and is defined as whatever the
             primary pointing device is.
  TabAtkins: For example, a touchscreen laptop has the touch screen
             and the pointer. This becomes hard when you do
             something like plug in a mouse.
  TabAtkins: We wanted to know user's probable interaction and what
             they might be able to do.
  TabAtkins: We let it determine what's the most likely thing for
             users to use, on a touchscreen laptop it's the trackpad
             etc.
  TabAtkins: Hover does all the values that might be on the screen,
             it just tells you what the user might be capable of.
  TabAtkins: I think this addresses a larger issue rather elegantly
             and I want to add this to MQ, but I'm wondering about
             other thoughts

  glazou: Comments?
  rossen: I'm not caught up on this one, but I'd like to run this by
          others. Can we wait a week?
  glazou: Is that okay for you?

  MaRakow: I was looking at this and I think the challenge is along
           the lines of... it's look at this a course or fine.
  MaRakow: This is fine if there's just primary and secondary, but
           if you end up with more tiers it's limiting.
  TabAtkins: Do you have examples where primary might be hard?
  TabAtkins: On my chromebook the touchpad is primary, screen
             secondary. Every example I can think of one can be
             reasonably assumed as the primary and I think it's okay
             to play favorites.
  MaRakow: My main thought is what you're trying to do is negotiate
           between what's best for the device and what's best for
           the author. If I have 3 options you can rank those by
           what's best
  MaRakow: And then you can correspond precedence. But when you have
          multiple tiers and the author has things for 2 and 3, does
          it use 2 not 3?
  TabAtkins: So the thing is the pointer can smash all them together?
  MaRakow: Maybe this is best on the mailing list, but I think that
           picking an input is more complex here.
  TabAtkins: Okay.
  TabAtkins: We can get more detailed with technical details on the
             list, I'm happy with that.

  glazou: Anything else on this topic?
  TabAtkins: No.

officially using the behavior of 'animation' wrt parsing
  <custom-ident>s in properties.
----------------------------------------------------------

  glazou: We had a comment on this from Xidorn the public ML.
  TabAtkins: That comment confuses me because this is what I thought
             he was asking for which means I misread.
  TabAtkins: I need to go look into what he wants and withdraw this
             text.
  glazou: So nothing to discuss now.

Seoul F2F
---------

  glazou: We have time, anything else to discuss?
  glazou: One thing before anyone else adds items, I think plinss
          mentioned this, but we need F2F items. Please place it on
          the wiki.
  glazou: If you don't have a hotel room, please book soon.

Variables
---------

  fantasai: Variables hasn't had anything since LC last year.
  TabAtkins: I've been working on comments.
  TabAtkins: Last resolution is CR once I finish the DoC.
  TabAtkins: I've made significant changes so we should republish as
             LC.
  TabAtkins: So if we can get that with a 4 or 6 week waiting period
             I'd be happy.

  glazou: When were the last significant changes?
  TabAtkins: A month-ish ago.
  glazou: Did people review?
  TabAtkins: The implementor, Cameron, did.
  fantasai: The major changes were call discussed, right?
  TabAtkins: Yes.
  glazou: I wanted to make sure no one would object to LC without
          review here.

  glazou: So any support, objection, or whatever to the LC?
  TabAtkins: I support it
  glazou: I do to
  <astearns> support publishing
  <glenn> +1
  fantasai: We need it publish, so I support.
  glazou: Any objections to new LC of Variables?

  RESOLVED: New LC for Variables

  TabAtkins: I can prep today. Can we publish this Thursday or wait
             for Tuesday?
  bert: I have holiday tomorrow so won't be available and don't want
        to risk it tonight.
  glazou: Most of Europe is on holiday tomorrow.
  TabAtkins: I'll prep for Tuesday.
  Bert: Tuesday is fine.

  glazou: Anything else?
  fantasai: Anything else to publish?

Revisiting calc() and whitespace
--------------------------------

  <zcorpan> http://lists.w3.org/Archives/Public/www-style/2014Apr/0480.html
           [css-values] Revisiting calc() and whitespace

  zcorpan: I have another topic, I just sent an e-mail regarding
           calc() and whitespace.
  zcorpan: My proposal is don't be fussy with whitespace. We changed
           parsing to allow white space around + and - and it seems
           silly to not support it.
  dbaron: So just changing parsing means it's required in some place
          not others which is confusing.

  fantasai: I think the previous concern is still valid.

  glazou: In you're e-mail, the 4th calc() example, do you want that
          valid?
  fantasai: That's invalid.
  glazou: It is now, but zcorpan says it's hard to explain
  zcorpan: I want it valid to 1+ not 2+
  <TabAtkins> That is valid in JS: `1 + + 2` == 3
  <SimonSapin> calc(10px + -2px) ?

  fantasai: I'm leaning no change here.
  zcorpan: We can think over this and discuss in a week.
  TabAtkins: Yep.
  glazou: Okay. It'll get discussed on www-style since it was just
          posted.
  glazou: Anything else?
  glazou: Okay. It's a short call. Thanks everyone and we'll talk
          next week.

Received on Thursday, 1 May 2014 00:00:25 UTC