W3C home > Mailing lists > Public > www-style@w3.org > October 2013

Telecon Minutes 2013-10-23

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 24 Oct 2013 14:01:23 -0400
Message-ID: <CADhPm3sJjUWwfE82jn8vbyb0eexFdtU8PiSzhPPN6Eicin9Rrw@mail.gmail.com>
To: www-style@w3.org
Scroll Snap Points
------------------

  - RESOLVED: Accept work on Scroll Snap Points as an Editor's Draft

TPAC
----

  - Plinss asked everyone to add discussion items to the wiki
  - Concern was again expressed that there was no answer on if there was
       a room for the group to meet in on Sunday. plh said he'd look
       into it.
  - Later in the meeting, plh confirmed that there was a room set aside
       for the Sunday meeting.

Daylight Savings Reminder
-------------------------

  - Everyone was reminded that next week Europe will end daylight
       savings time, but the US and therefore the telecon won't switch
       until the week after.

Style Attributes
----------------

  - Plinss requested that everyone remind their reps to vote positive.

Named Flows and Box Generation
------------------------------

  - Stearns requested responses on the mailing list.

Outline-style: auto
-------------------

  - The feedback from the web platform team will go through the normal
       spec comment process.

Fragmentation and Fullscreen Elements
--------------------------------------

  - Michou brought up his question on how fragments are handled in
       fullscreen.
  - The group felt that fragments should be ignored in fullscreen, but
       that this should be addressed in fullscreen, not in fragments.
       Therefore, Michou will provide his feedback on that mailing list.

setProperty and !important
--------------------------

  - Discussion was deferred until zcorpan was available, perhaps at
       TPAC.

device-pixel-ratio Zoom Behavior
------------------------------

  - How device-pixel-ratio should interact with zooming was discussed
       which included conversation about the different types of zoom.
  - Proposals included having device-pixel-ratio only respond to one
       type of zoom, creating a different property for different types
       of zoom, and differentiating between zoom that changes the width
       and zoom that doesn't.
  - No resolution was reached and discussion will continue on the
       mailing list and, if needed, at TPAC.

Writing Modes
-------------

  RESOLVED: Publish another working draft of Writing Modes

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

Present:
  Glenn Adams
  Paul Adenot
  Rossen Atanassov (Had to leave early)
  David Baron
  Bert Bos (Late)
  John Daggett
  Justin Erenkrantz
  Elika Etemad
  Simon Fraser
  Sylvain Galineau
  Daniel Glazman (Sometimes IRC only)
  Koji Ishii
  Dael Jackson
  Peter Linss
  Edward O'Connor
  Matt Rakow
  Florian Rivoal (Late)
  Simon Sapin
  Alan Stearns


Regrets:
  Tab Atkins
  Rebecca Hauck
  Simon Pieters
  Dirk Schulze
  Lea Verou


ScribeNick: Dael

  plinss: Any extra items?
  Rossen: I have one
  Rossen: I just wanted to make proposal for new module of snap points
  Rossen_: I sent out an e-mail and I'm unfortunately far away
  Rossen_: I was going to ask if we can discuss and I need to leave call
           quickly.
  plinss: Anything else?

Scroll Snap Points
------------------

  <Rossen_> http://lists.w3.org/Archives/Public/www-style/2013Oct/0595.html
  Rossen_: So this is a spec that we discussed a couple of times in
           past.
  Rossen_: Some of those discussions might have been in a hallway or off
           topic.
  Rossen_: They were basically were having to do with us proposing the
           behavior of snap point.
  Rossen_: We've been shipping it as part of our platform since IE10.

  Rossen_: The two editors are MaRakow and Jacob...I don't remember the
           last name.
  <sgalineau> Jacob Rossi
  Rossen_: They were working on other stuff and finally were able to
           draft a spec.
  <dbaron> http://dev.w3.org/csswg/css-snappoints/
  Rossen_: Which we uploaded as an unofficial draft to above link.

  Rossen_: As with any new proposal we wanted to get WG's buy-in.
  Rossen_: I know that there was some discussion on www-style from Tab
  Rossen_: This is something that we're just starting and want to start.
  Rossen_: It is very rough and there are definitely things missing and
           things to improve.

  Rossen_: In order to get rolling we want to see how WG feels.
  dbaron: I think it's great to have in draft; I would like to see more
          of...I'd like to see additional stuff.
  dbaron: In particular, along lines of what Roc proposed
  <sgalineau> +1 to snap to elements
  <sgalineau> or element edges

   * glazou is ok for an ED pending other members are ok, IP-wise ;
            question : in scope for next charter ?

  dbaron: Having to specify manually in separate property is hard.
  dbaron: Current it requires authors to specify edges when they're
          often created by element to point out edges.
  dbaron: It's great to see this draft, but I don't think we're set on
          the details of that proposal.
  dbaron: I'd like that addressed in draft
  <sgalineau> +1 to new draft + dbaron/roc's feedback
  <fantasai> +1 to dbaron's proposal

  Rossen_: Would you like us to start with that as an issue?
  fantasai: I'd like Roc's proposal before we do a first public working
            draft.

  <glazou> plinss, in scope for next charter?

  Rossen_: We just have this as a unofficial draft, we're sorry about
           originally putting in as and ED
  Rossen_: Once we're okayed to start as ED, we can work on all these
           issues before we do first public
  fantasai: I don't think this needs to be an issue, just put in the
            information.
  Rossen_: I guess my question was unclear.
  Rossen_: Is this issue something we should try and put in the
           unofficial draft, or should we put in before it's ready for
           first public?
  <sgalineau> thinks this can just be an issue in the ED
  fantasai: I don't think it matters, that's just the next step.
  dbaron: I don't think it matters either.

  Rossen_: I think we can work on that. No problem.
  plinss: Any objections to accepting it as ED?

  RESOLVED: Accept work on Scroll Snap Points as an Editor's Draft

  Rossen_: Thank you everyone, now I have to jump off

  <glazou> please, ask about charter scope
  plinss: Snap points should be in the next charter
  <glazou> thanks

TPAC
----

  plinss: We need more items on wiki

  plinss: So far we haven't heard about meeting at TPAC on Sunday.
  plinss: If we think folks are attending and available on sunday, we'll
          still try and find meeting space.
  jdaggett: Can we figure out from Adobe someone to set up a meeting
            room and not use W3C?
  jdaggett: Seems like someone has thrown this over the wall

  plinss: We've been trying, but TPAC needs to set up a space
  plinss: I can ping Adobe
  jdaggett: It seems like we need to corner someone
  jdaggett: We're trying to get a Sunday space, Adobe has been able to
            get a space on Saturday. Let's figure out their magic.
  Sylvaing: I don't think it was just Adobe, I think tancent helped.

  plh: We also have to deal with the hotel. It might be too late at this
       point, but it's worth a try.
  plh: I know ?? is super busy and might not be able to help.
  jdaggett: The request was 2 or 3 months ago; never answered.
  plinss: They just said they'd see what they can do.
  plh: I'll try and find out more.

  jdaggett: This is frustrating because people are spending money and
            time and AC meeting overlaps with us. I'm just a bit upset.
  plh: I understand. I apologize. I'll get as much info as possible in
       the next 24 hours.
  plh: If not, we might need another way to meet.

  jdaggett: What I find weird is we always meet Sunday and always have
            to wrangle that room.

  plh: To be honest, I was talking with Jeff and he said everyone in the
       WG thought three days was too long
  plh: I'll look into the matter.
  fantasai: Wait, who said 3 days was too long?
  plh: That was old feedback.
  dbaron: After last year glazou said he wouldn't meet Sunday, but
          he's not coming.
  <glazou> right
  plinss: I think that was from having so many things back to back, but
          he was the only one.
  plinss: That wasn't a group decision.
  <glazou> correct

  <plh> http://www.w3.org/2013/11/TPAC/#GroupSchedule
  plh: I see on schedule it's there, that we want to meet on Sunday.
  plh: So I'm going to check.
  plinss: Ok,
  plinss: Thank you.

Daylight Savings Reminder
-------------------------

  plinss: Another reminder, the daylight savings time change happens
          next week.
  plinss: Be careful about when to call in
  dbaron: In particular, next week call is an hour earlier for Europeans

Style Attributes
----------------

  plinss: People, remind your reps to vote positive on that.

Named Flows and Box Generation
------------------------------

  stearns: I'd like to encourage people to respond on the mailing list
           so we can discuss as much as possible before TPAC.
  stearns: I saw dbaron responded, thanks
  stearns: Anyone want to talk now?
  plinss: Anyone?

Outline-style: auto
-------------------

  plinss: Anyone that can talk about this?
  plinss: We got feedback from web platform folks?
  dbaron: I responded on the mailing list; they understood my
          explanation better than the spec.
  dbaron: I don't see what's different about them, though.

  plinss: Anything else we can do here?
  plinss: Or wait for feedback from them?
  dbaron: I don't...It was just one e-mail.
  dbaron: I think it can be normal issue process for spec

Fragmentation and fullscreen Elements
--------------------------------------

  stearns: Is michou on the call?
  michou: I'm here.

  michou: The main question is, right now the fullscreen spec that's
          being offered
  michou: Describes how things should be displayed when there is full
          screen.
  michou: However, there is no mention about how things that are
          fragmented should behave in fullscreen.
  michou: My question is, first, if this should be specified in the
          spec, and which spec should it be?
  michou: More general question is when there are these interactions
          between specs, how is it handled, not just in this work.
  michou: Which should take care of including the behavior?

  * sgalineau is it just fragmented content of even just the interaction
              of overflowing content with fullscreen?
  <dbaron> I think it might be useful to include at least some of the
           editors of fullscreen in a discussion about fullscreen.
  <sgalineau> if I make an overflow:scroll element fullscreen and it
              doesn't fit, what happens?

  fantasai: The spec takes care of 2 aspects of things.
  fantasai: New models should define fragments on their own.
  fantasai: This should describe different classes of layout and sizing
            constraints across pages.
  fantasai: fullscreen might be different.
  fantasai: If you're printing fullscreen, you should just print that
            part, not the full document.
  fantasai: This fullscreen doc is up front, so your intention in
            there, not the rest.
  fantasai: Makes sense you only print that, that's one possibility
  michou: That was my conclusion too.
  michou: When you're in fullscreen, you disregard the fragment.

  michou: The question remains, where should that be?
  fantasai: fullscreen spec.
  michou: Okay

  michou: stearns: anything else?
  stearns: I think we should provide feedback in mailing list.

  michou: I'll continue this on the fullscreen mailing list.
  plinss: Anything else?
  michou: Not from me.

setProperty and !important
--------------------------

  plinss: There was discussion on the mailing list about this. Anyone to
          talk about it?
  dbaron: I can give in if other implementations are willing to change
  plinss: Is there anyone familiar with the objection?

  dbaron: The issue was discussed at Paris F2F
  dbaron: The issue was how setProperty deals with existing declaration
          for that property for various settings and the setProperty
          having !important.

  plinss: So the question is, is IE or Webkit willing to change the
          behavior?
  plinss: Anyone?

  israelh: I'm curious, there was also in past discussion about if
           !important needs to change for animations.
  israelh: So is there a larger set that deals with !important that
           needs to be addressed?
  dbaron: I don't think they're related.
  israelh: I think it's self contained.

  Glenn: I think we should wait for Simon Peters (zcorpan)
  plinss: So defer?
  plinss: Maybe discuss at TPAC?
  Lief: I think Simon Peters is coming to TPAC
  Lief: Maybe not to CSS
  fantasai: If he's there, I think we can pull him in
  plinss: So defer?

device-pixel-ratio Zoom Behavior
------------------------------

  plinss: This is an old thread getting life on the list.
  plinss: It's about how it should behave when zoom is applied
  plinss: Anyone want to talk about it?

  smfr: We feel strongly in webkit it should only represent the
        properties of hardware display.
  smfr: It shouldn't change with zooming.
  smfr: Other browsers want one to change, but in that case it should
        have another name.
  fantasai: That makes sense to me

  dbaron: What is the use case? People are going to write media queries
          with assumptions that won't hold.
  smfr: One of our goals is to retain...to keep page zooming under user
        control.
  smfr: Not give authors too much control.
  smfr: We don't want pages to rearrange when the user zooms.
  hober: We also have when an author is trying to change things, when it
         is small, the user zoom makes it smaller.

  dbaron: There's a half dozen was for authors to do this
  dbaron: This doesn't seem like the thing people will use to rearrange
          content.
  dbaron: They will use for low-level quality issues.

  <Bert> I think there are at least three kinds of zooming: the
         magnifier metaphor (doesn't cause any re-layout, or it defeats
         the purpose); set medium font size (causes new layout);
         simulate bigger/smaller pixels (probably does new layout?)

  hober: That sounds like an argument for making it constant
  dbaron: We're only talking about desktop, not mobile.
  smfr: I think our position holds in that case. When we introduced
        retina, the reason was people could provide high resolution
        assets on those devices.

  dbaron: Problem is it's a general tool and people will use for other
          things.
  dbaron: I'm concerned because everyone else seemed to like the other
          direction and they're not on phone call.

  MaRakow: In IE what we're doing is searching ratio is setting. When
           users are doing higher res, we want to allow that, but we
           want to mask anything in zoom with websites.

  dbaron: Pinch zoom doesn't effect this.
  dbaron: It's a little funny to define.
  florian: When it comes to desktop zoom, the viewport changes etc. so
           this argument doesn't apply.

  smfr: In safari there's 3 zooms, including text size, make pixels
        bigger
  smfr: And apply a transform in retina view, when you use 2 fingers on
        the track pad.
  florian: I was referring to classic.
  florian: For this I wouldn't mind pixels changing.
  dbaron: I think we're talking about changing it for zoom where width
          is changing.

  dbaron: If you ctl+ and you zoom in a 1000 pixels wide
  dbaron: Then your width is 667 pixels.
  dbaron: In those cases, where the width changes when you zoom is when
          we change the device ratio.
  florian: If zooming changes the width it changes, if it doesn't change
           width it doesn't change ratio.
  <SimonSapin> +1 florian
  <SimonSapin> MQ 'width' times 'resolution' should be constant on a
               given device, IMO

  * fantasai would like to request WD for Writing Modes, given we can't
             publish LC until after TPAC at the earliest
  florian: Given the confusion and that authors can use other options to
           change
  florian: 'width' .... is not confusing. So why is device-pixel-ratio
           doing a similar thing confusing? Some zooms alter view port,
           some don't.
  florian: If it changes the view port, it should change.

  smfr: It should always reflect relationship between CSS picture rules.
  smfr: That means every type of zoom should change.

  florian: I can see an argument for that.
  florian: Pinch zoom is asking "please don't change the page, I just
           want to get closer".
  florian: There's no expectation of change
  * sgalineau doesn't like the idea of a *device* pixel ratio changing.
             That makes little sense. Do the device* MQ properties
             change?
  * sgalineau wonders if we're talking about a csspixelratio property

  plinss: I do want to see it at a higher resolution
  plinss: I think there's a media query that will accept that
  plinss: If I've zoomed to where one pixel is taking my screen, I want
          it to change.
  florian: That slows it down significantly.
  plinss: I understand. I'm saying it can be addressed.
  plinss: I can accept devicepixalratio doesn't change
    plinss: I want something that does

  sgalineau: My understanding is that it's a ratio between the two. When
             one of them changes the ratio changes.
  sgalineau: That's what i suggested on IRC

  florian: I wonder if a CSS pixel ratio property that's distinct would
           fix it.
  hober: I think that's fine. It should be named to avoid confusion.
  florian: They will most likely take the one that works in the case
           they thought of, but break in another case.

  MaRakow: I think we want a different property that separates device
           pixels and CSS pixels
  MaRakow: This is what I want for pinch and this is what I want for
           persistant.

  florian: To address the earlier point, I think users expect things
  MaRakow: I think where we want authors to distinguish is where users
           distinguish.
  florian: That's not what pinch zoom is for
  florian: If you have multi-res image and the browser switches, that's
           fine, but it doesn't allow author to change query.
  florian: That provides high end definition
  florian: Having a media query that triggers from pinch zoom allows
           authors to re-do layout arbitrarily.
  florian: That's no good.
  florian: Re-rendering is fine from rules,
  florian: Arbitrary is not fine.

  MaRakow: I can't think of many scenarios for temporary zoom,
  MaRakow: One thing I can think of is temporary assets.
  florian: And if we go through media query, arbitrary is what you get.
  MaRakow: I agree. You wouldn't want it to stack with zoom, it would be
           a separate multiplier.
  florian: Media query...is fine to change in type of zooming that
           changes viewport.

  Bert: I guess florian said it, I agree the magnification is in the
        browser.
  Bert: It doesn't expect the substitution.
  Bert: We don't have to specify in media queries,
  Bert: This type of zoom is outside CSS.

  hober: With all this interest in defining device-pixel-ratio
  hober: We should add device-pixel-ratio to media queries 4.
  hober: An actual definition would be nice.
  hober: In the past people have opposed change, but this is a cow path
        that needs to be addressed.
  <dbaron> I agree we should pave the cow path at this point.

  florian: How do you propose...these two things have different syntax
           and you can pick?
  hober: Personally, I'd drop resolution media query, but I'd lose.
  hober: We need to describe that they do different things.

  florian: I don't want to be diplomatic. Resolution was first, maybe we
           should syntasize that one.
  florian: That's a separate question.
  * fantasai thinks florian needs to correct the above

  florian: The behavior and the name should be described independently
  fantasai: How many implementers do we have of device-pixel-ratio?
  florian: It's in presto, webkit perhaps
  <dbaron> +Gecko
  florian: At the same time, all implementations we have are prefixed.
  dbaron: I believe it's un-prefixed in Gecko.

  plinss: I'm hearing agreement we should standardize
  florian: By this you mean?
  plinss: The name for one.

  florian: If we have one thing with a prefix, we should standardize. If
           not, I'm not sure we should if we're going to migrate
  fantasai: What about a webkit implemention?
  fantasai: Does WebKit implement 'resolution'?
  smfr: I think Apple turns it off.
  florian: I think it was also intentional to not that in media 3, we
           tested for existence, but not behavior.
  florian: It's possible many have it, but don't treat it the same.
  florian: So maybe we should go pave the cowpath

  plinss: Sounds like agreement to add it to media 4, but we're not sure
          on how to do it.
  florian: I'm not sure what to address because not everyone has same
           syntax.
  florian: I think several implementers accept a ratios as the value for
           media query.

  fantasai: I'm thinking both ways make sense
  florian: It's also in syntax.
  florian: We agree what syntax should be.
  dbaron: This is widely used enough, it will end up being
          webkit-device-pixel-ratio in all browsers if we fiddle too
          much.
  plinss: I think it's fine to add extra syntax and features, but not
          break existing.

  florian: I don't think anything has changed since we talked and
           decided the other way.
  florian: What do we do with resolutions?
  florian: Do we link properties together?
  plinss: That's fine if the behaviors are identical.

  florian: I'd like to see if people are using resolution in the wild.
  florian: If no one uses it, let's kill it.
  dbaron: It has value from accepting multiple units.
  florian: I'll add both it and its alias between too.
  florian: I'll find a blog post that describes syntax.

  plinss: Still a question about behavior under zoom.
  plinss: Fairly strong opinions that it should change.
  plinss: Does Webkit still oppose?
  hober: Yes

  plinss: Is that something you're willing to change?
  hober: I think it would confuse authors if we change.
  florian: If authors are swapping low and high res, it won't be awfully
           confusing.
  florian: If they break it, it's because they shouldn't be doing it.

  plinss: We're running out of time. How to this move forward?
  plinss: If we don't standardize behaviors, we can't standardize.

  <astearns> I think we need to hear from PLH before the call ends
  plinss: plh, you still on que?
  plh: yes, but on another point.

  * fantasai plinss, can we get a resolution to publish writing modes
             WD, since LC is not possible before TPAC?

  florian: I think using media queries here is wrong
  florian: I'm not sure how to convince anyone that's unconvinced.

  hober: You're forgetting border width
  hober: Media query is a natural way to do half width border-width

  plinss: Discuss this on the mailing and at TPAC?

TPAC
----

  plh: I can confirm that you can have a room on Sunday.
  * jdaggett yay!
  * dauwhe excellent!
  plh: Same number of attendees as on Monday/Tuesday?
  <SteveZ> I will not be there on Sunday due to a conflict
  * dbaron would guess that one or two people have travel plans that
            preclude Sunday by this point.
  plh: Confirmation just arrived yesterday, so sorry.

Writing Modes
-------------

  fantasai: I don't think we can get to LC in time for TPAC, so can I
            publish a WD?  The last one was a year ago.
  jdaggett: As long as as long as the Tr fallback issue is marked as an
            issue.

  RESOLVED: Publish another working draft of Writing Modes

  plinss: Thanks everyone
  [Meeting Ended]
Received on Thursday, 24 October 2013 18:01:52 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 24 October 2013 18:01:52 UTC