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

[CSSWG] Minutes Telecon 2015-05-06

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 7 May 2015 13:27:04 -0400
Message-ID: <CADhPm3u=u4rnDbh07HhNBqY=EVBaQ99Ps2O_KLnoC_A2R41Ogw@mail.gmail.com>
To: www-style@w3.org
CSSOM View document.scrollingElement review

  - RESOLVED: Accept the behavior but add more definition

Publish/Review of CSS3 UI

  - RESOLVED: Publish an updated WD with the additional section from

justify-content: stretch on flex items

  - RESOLVED: justify-content: stretch computes to stretch but
              behaves like start
    - Note: This resolution might not have been recorded correctly.
            Please see member only discussion regarding potential
            clarification, available here:

Position 'center' and 'page' values

  - RESOLVED: remove position: center from Position
  - RESOLVED: Republish CSS positioning without position: page. Also
              update the short name.
  - Conversation will continue on the mailing list to put together a
      case for re-introducing position: page and it will likely
      become a F2F topic in NYC.

Proposal to *not* standardize user-modify

  - RESOLVED: no user-modify in CSS UI 4


  Rossen Atanassov
  Tab Atkins
  David Baron
  Bo Campbell
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Tony Graham
  Dael Jackson
  Brad Kemper
  Peter Linss
  Anton Prowse
  Florian Rivoal
  Andrey Rybka
  Simon Sapin
  Alan Stearns

  Sanja Bonic
  Adenilson Cavalcanti
  Hyojin Song
  Steve Zilles

  scribe: dael

  plinss: Let's get started.
  plinss: Any last minute additions to the agenda?
  plinss: andrey you wanted to do a F2F reminder?
  <andrey-bloomberg> sorry phone died
  plinss: He sent a note to anyone going the the NYC F2F to update
          the wiki so we can get a count.
  Florian: I'm about to get air bnb so if anyone wants to join
           please let me know today.
  <SimonSapin> Florian, did you get my email response?
  <Florian> simonSapin: yes, thanks

CSSOM View document.scrollingElement review

  <plinss> http://dev.w3.org/csswg/cssom-view/#dom-document-scrollingelement
  plinss: TAG was asked for input and there was discussion there,
          but I don't think we discussed this in the group. I wanted
          to make sure we took a look at this and gave comments or
  plinss: It's not widely implemented, but has different behaviors.
          I'm not sure if this section has been reviewed by many
          people and I want to make sure it's implementing what we
          want it to implement.
  plinss: So does anyone have feedback?

  <dbaron> Why is this being added? It seems like an odd definition.

  smfr: It's not clear if this is a stopgap until browsers have
        correct behavior or if it's a long term API that will stick
  plinss: Not to me either.
  Rossen: Which are you referring to?
  smfr: In standards mode it's always scrollingElement. I think this
        is a stopgap until webkit and blink use the documentElement
        in standards mode. With the intent this is used by polyfills
        to get correct behavior.
  smfr: It doesn't feel like a stopgap, it seems like it will stick
        around until the end of time. If it is a stopgap, I'd prefer
        it was designed more like one.
  Rossen: I don't think this is a stopgap. I think it has wide
          adoption. Backing out, I'm not sure if it would be easy
          even if you want to change.

  <dbaron> It would be nice if the spec actually contained the
  <smfr> dbaron: lots of motivation at
  <dbaron> Gecko doesn't implement it

  plinss: It's not clear how useful this API is. What does it do in
          iFrames? There's holes here.
  smfr: It's not intended to be scrolling. It's only for this issue
        with a historical behavior where in standards mode it
        scrolls the body, not the document. It sounds more general,
        but it's really specific.
  Rossen: We have implemented the same way as webkit and Chrome for
          mobile interop. This is a fairly used API at this point
          and I don't think we can back out unless we do it together.
  smfr: I don't think you impl this. I think you impl the body as a
        scrolling element.

  dbaron: If this is to be a transitional thing for until the quirky
          behavior can go away, shouldn't the definition be tied to
          if the behavior is there?
  <dbaron> (e.g., if Gecko were to implement it, and doesn't have
           the quirky behavior, should we be implementing something
           different from what the spec says?)
  smfr: That's a good suggestion for ric.

  TabAtkins: The major reason for this is the weird behavior of
             webkit and blink, but the same quirks mode effects it.
             So even if you impl properly you still need to detect
             if you're in quirks mode.
  plinss: I'm hearing from Microsoft they're not sure if it can be
          changed, hearing from others I'm not sure if that's the
          way we want it.
  TabAtkins: That's not what I said. It sounds like this is needed
             for quirks mode vs. standard mode documents as well as
             the webkit behaviors.

  Rossen: It sounds like this is something we ought to be working on.
  smfr: I don't object to this. I think the bug report was webkit
        would like it to be more clear on intent.
  plinss: Are we comfortable with the behavior as spec'ed?
  Rossen: Are you saying a little stronger and clearer definition
          would make you willing to put in efforts?
  smfr: If what TabAtkins says is correct and this will be longterm
        behavior it seems like it has legs and will stick around.
  <dbaron> I think (a) we should have a plan to have implementations
           doing the same thing and (b) if this is part of a plan to
           migrate to some end state, that migration sequence should
           be described in the spec

  Rossen: Okay. So who would want to work on that, spec wise?
  TabAtkins: The spec part seems trivial. You put it in CSSOM View
             and it's a paragraph of definition. That's all.
  plinss: dbaron made some comments in IRC.

  plinss: Anyone willing to take this work?
  TabAtkins: I can work with ric to get a definition and do a PR.
  plinss: Everyone happy with that?
  Rossen: Yep.

  RESOLVED: Accept the behavior but add more definition

Publish/Review of CSS3 UI

  <Florian> https://www.w3.org/wiki/CSS3-UI
  Florian: For the first time in a while we have 0 issues. This wiki
           (above) has the resolved issues. Some are by fixing, some
           postponing, but it's all documented.
  Florian: This looks like a good time to review and perhaps ask
           other WG to look at it at the end of which we go to CR.

  Florian: tantek mentioned he wanted to add an implementor's
  tantek: I've gone ahead and added it on my local copy. That should
          be done soon. This is a security and privacy questionnaire
          that the TAG is looking at and I believe is taking up.
          It's meant for self review by editors of their specs. I
          think it's good to include as an informative appendix.
  tantek: It's informative, not normative and pretty short.

  Florian: I suggest we put a WD out and get comments from others.
  Florian: After we decide if we're going to CR
  <Florian> I want to put a WD out, ask the group to review, maybe
            ping other WG
  <Florian> Effectively a LC
  tantek: I'd like this to go with the WD. Give me a few minutes to
          post and we're good.
  <tantek> I'm in favor of WD with these informative edits

  plinss: Here's the link to what tantek's document is based off of.
  <plinss> https://w3ctag.github.io/security-questionnaire/
  plinss: So publish an updated WD with this section. Do people want
          to review or are we good to publish?
  <andrey-bloomberg> +1 for working draft
  <fantasai> +1
  <fantasai> for resolution to publish

  Florian: Do we want to ping any other WG about this being
           effectively done?
  fantasai: Probably ping HTML and maybe webapps and a11y.
  Florian: Yes. Probably also SVG because they were interested in
           nav property.

  RESOLVED: Publish an updated WD with the additional section from

  plinss: If you could work on the additional comments in DoC form
          we can get queued up for CR.
  Florian: And everyone should review this.

  <tantek> FYI: CSS3-UI security & privacy questionnaire answers
           appendix committed

justify-content: stretch on flex items

  plinss: fantasai I think you raised this?
  fantasai: We wanted to know what the right way to change auto and
            stretch values of alignment. On flex they behave as
            start. Do we compute them through or do we say it stays
            the way it is. The reason to compute through is auto is
            a new value. If the initial value can make it disappear,
            for backwards compat we need to compute through.
  fantasai: So a) is compute to flex start or b) is the compute to
            themselves and behave as flex start.
  <dbaron> "stays the way it is and behaves the other way" ?
  * dbaron didn't follow that sentence

  Rossen: I'm inclined to go with the first option because there's
          less magic. I'm not convinced it would be the optimal
          behavior we can have. I haven't had too much chance to
          work on the issue and think about it so if anything I will
          update on the ML.
  dbaron: My one thought is we've been introducing a lot of
          computation dependencies and they all have cost an may
          prevent more in the future so we should be careful of
  <dbaron> fantasai, is "compute through" (a) or (b)?

  fantasai: Okay. Based on the feedback so far I'm inclined to have
            it compute through. If people disagree we can come back
            to it. We're not changing flexbox.
  fantasai: Compute through is (a). Compute to flex start
  <fantasai> (This is a Box Alignment issue; Flexbox doesn't have
             auto or stretch values)
  plinss: Option a was compute to stretch and behave as flex start.
          So you're saying it computes to flex start?
  fantasai: Yeah. It computes to flex start.
  <fantasai> A) compute to flex-start
  <fantasai> B) compute to self, behave as flex-start
  plinss: Objections?

  dbaron: What's the exact dependency here, in terms of properties?
  fantasai: It depends on value of position and the value of the
            parent's display
  * fantasai thinks dbaron has a good point, we should make a
             dependency graph on the wiki
  * dbaron fantasai, we have one on the wiki, I think
  * fantasai ok
  * fantasai goes looking
  * dbaron fantasai, but it's pretty out-of-date
  * Florian thinks the computed value dependency graph sound like a
            job for bikeshed
  * tantek indeed Florian
  <dbaron> fantasai, https://wiki.csswg.org/spec/property-dependencies
           is our wiki list of dependencies

  Rossen: Like fantasai pointed out I don't currently have an
          objection, but I'll try to get together with my flexbox
          dev and give it some additional thinking so if anything
          comes to mind as a better solution, we'll discuss it then.
  plinss: Okay.

  RESOLVED: justify-content: stretch computes to stretch but behaves
            like start

Position 'center' and 'page' values

  fantasai: We had a resolution to publish without the page value
            and the center value it it had those. Unless someone can
            make an compelling argument to keep page we should
            republish without it.
  fantasai: We should also remove the position: center because we
            have more powerful tools in Box Alignment. We should
            remove these two and have the position draft be the
            CSS2.1 positioning schemes plus sticky.

  Rossen: In term of position: center, I don't remember a resolution
          to not have it. We discussed as a part of the positioning
          spec. There was some excitement on that, I think, but
          that's just memory. I'm impartial. I don't think anyone
          has implemented currently or efforts toward it.
  Rossen: If that's what everybody wants.
  fantasai: We don't have a resolution one way or the other on

  <tantek> I would like to keep position: center
  <tantek> and if there are issues, note the issues inline
  <fantasai> tantek, we have centering in css-align
  <tantek> ok fantasai - I defer
  <tantek> if you're convinced it's just as easy for authors
  <tantek> since I'm not as up to date on it
  <tantek> I remember the excitement about position:center also
  <fantasai> tantek: Think so. If not, file issues against css-align
  <tantek> ok fantasai I'm trusting you :)

  Rossen: So does anyone care if we keep position: center? The
          proposed resolution is to remove position: center
  Rossen: So that's nobody. plinss can we record a resolution?
  plinss: tantek said in IRC he'd like to keep, but is willing to
  plinss: Anyone else want to keep it?

  RESOLVED: remove position: center from Position

  Rossen: For position: page I was going off a resolution we
          recorded in...[tries to find it]
  Rossen: The resolution from Aug 2011, that was the Seattle F2F
  Rossen: The last resolution was publish CSS3 Positioning. There's
          nothing about removing it.
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2011Nov/0709.html
  fantasai: Here's the resolution to remove it.

  Florian: But page is meant to address same issues as floats,
  fantasai: It's related. There was concerns about the way position:
            page works.
  Rossen: The way I remember that discussion was...A bit of content
          is a better name for position: page is position: fragment,
          but back then we hadn't worked on the fragment spec yet so
          the term was obscure. Essentially the features allow any
          fragmentation context on the way to become a positioning
          container. So if you have an element that needs to be
          positioned, that fragment will be positions.
  <fantasai> (fragmentation contexts = pages, columns, regions, etc.)
  Rossen: So if that's a page box, the positioning occurs on that
          level. That's what the feature was spec'ing. When the
          fragmentation, such as the top level scroller, everything
          is positioned off of that. That's the same as saying if I
          have no other positioning containers on the way to the
          root scroller the root scroller is the positioner.
  Rossen: We've seen a lot of usage in applications that use regions
          and the only way to target the current page for something
          like an annotation is to have a way to define the fragment
          as the current container. If there's another way to do
          that I'd be happy to explore that, but currently I don't
          believe we have any.
  <BradK> Sounds like a pretty great feature
  Rossen: I'm not married to the name, I believe position: fragment
          is a more accurate name. We have missing functionality
          there that we need to address.

  <fantasai> Arron presented a draft for CSS3 Positioning, which
             includes CSS2.1
  <fantasai> absolute, fixed, and relative positioning, containing
             blocks, and
  <fantasai> z-index; and that adds:
  <fantasai> - 'position: center', in which 'auto' offsets compute
             to center the element
  <fantasai> - 'position: page', in which the current page box is
             the containing block
  <fantasai> There were concerns raised that the page positioning
             scheme would result in
  <fantasai> layouts that broke very badly if the document were
             either rendered onto a
  <fantasai> continuous (scrolling) canvas, or if it were paginated
             differently than the
  <fantasai> author's original intent (due to differently-sized
             fonts, differently-sized
  <fantasai> pages, etc.). Thus:
  <fantasai> RESOLVED: Publish CSS3 Positioning as FPWD, without
             position: page
  <fantasai> (That was the resolution)

  Florian: I'm not an expert on this, but it seems like they're all
           addressing the same thing. Am I right about this? I know
           they don't work the same, but what you apply them to
           seems to be the same.
  Rossen: Page floats is a, basically 2 separate features combining
          to one. They're defining exclusion areas to some element
          and we have aspect that does that. The second feature is
          how do you position something on the page. This is beyond
          page floats, this is a feature that's meant for several
          types of fragments.
  Florian: But page floats uses page in the name, but it's really
           about fragmentainers and positioning.
  Rossen: As far as I remember last time I read page floats, it was
          all about pages, not about fragments.
  Florian: But it's also about deferring to the next column. So if
           you have columns and pages it's not a stretch to add
  Rossen: So what if I don't want something to be a float, but I
          want to position it. I don't want an element that creates
          an exclusion area. Page floats is combining two features,
          creating an exclusion area based on the shape you're
          defining. It has nothing to do with how you got to the
  Florian: I agree it's a difference, but I'm not sure it counts
           against page floats. It's agreed that one of the
           weaknesses of abspos is it doesn't deal with things
  Rossen: Which is what you'd want with annotations that are in the
          same area.
  * BradK thinks Rossen has a good point. Exclusions is already good
          as a separate thing. Fragmentainer positioning negates the
          need for page floats.

  fantasai: Back to the original issue. When the WG agreed to
            publish, it explicitly said it shouldn't include this
            feature. It was in the minutes and I pasted it above.
            There was no resolution later to include this. It should
            be removed and the draft republished.
  fantasai: If you want to add it, Rossen, you can make a case. The
            resolution as it stands and as it should have been
            executed is that it doesn't include the feature and it
            should not have that feature since that's the consensus.
            I want the draft to reflect where the WG stands on these
  Florian: I'm cool with that and continuing the discussion on if we
           have the use cases covered. fantasai's point seems valid
           to me.
  plinss: I agree with fantasai but I also agree it's a useful
          feature. It does seem like there's some overlap. The float
          reference property does seem similar. Let's have a common
          underlying approach, but that's more. Proposal is
          republish without this property. Objections?
  <Florian> +1 to plinss
  Rossen: I don't, no.

  RESOLVED: Republish CSS positioning without position: page. Also
            update the short name.

  <BradK> Editors draft will still have it for reference?
  <fantasai> old drafts will still have it for reference
  <fantasai> that's why W3C has dated drafts :)
  <dbaron> (presumably center should also be removed per previous

  plinss: Anyone will take an action to create a better definition
          of position: page?
  Rossen: I'll put this on the NYC F2F topics.
  Florian: That sounds like something worth talking about. If you
           could bring use cases it would be nice.
  Rossen: Yeah. I'll have use cases.
  Rossen: It would be good to have page float use cases as well.
  Florian: Yes.
  plinss: I'd like to see proposal to unify them.

Proposal to *not* standardize user-modify

  Florian: I've been looking at things that were in very early
           versions or things that were implemented a bit but
           currently missing. user-modify existed a long time ago,
           but webkit and blink implemented it. They currently only
           use it to invoke contentEditable and you can just use
  Florian: If we have it in CSS it start applying to non-HTML
           languages and we don't know how it applies.
           contentEditable is useful, but not on this.
  <tantek> agree that user-modify is now out of date per current
  <tantek> let contentEditable and Editing discussions handle this
  <tantek> we're agreed on this.

  plinss: Anyone with other opinions?
  Florian: It's not even removing it. It's deciding not to work on
  <tantek> like anything else - if the concept is interesting/useful
           in the future, people can make a proposal

  RESOLVED: no user-modify in CSS UI 4

Weaken upright rendering of horizontal-only scripts
  plinss: koji are you on the call?
  plinss: It doesn't seem so.
  plinss: Anyone else able to speak to this or should we defer until
          we have koji?
  plinss: We'll defer.

  plinss: I'm out of topics. I think we're done for the week.

  fantasai: Does anyone know where chrisL is?
  dbaron: I think I saw him at the AC meeting.
  <tantek> ChrisL is in Paris
  <tantek> yes he was around the AC meeting
  <tantek> dbaron is in the conference room, glazou and I are in the
  fantasai: okay. I was just wondering.

  plinss: Okay. We'll talk next week.

  Rossen: One quick question. The one behavior and proposal I was
          going to put on the F2F agenda was the zoom property we've
          been working on better interop for. I wanted to give a
          heads up that this is something we wanted to talk about.
          I'll have a spec describing the current behavior, but it
          would be great to decide if we want to keep that property
          or get rid of it.
  Florian: Is it the zoom that's a bit like transforms but effects
           layout things?
  Rossen: Yeah.
  plinss: Also a good reminder that it's a good time to add topics
          to the wiki.
  plinss: Now we're really done.
Received on Thursday, 7 May 2015 17:27:32 UTC

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