W3C home > Mailing lists > Public > www-style@w3.org > December 2017

[CSSWG] Minutes TPAC F2F 2017-11-07 Part I: .style append/replace, list marker layout, scroll-snap & scrolling APIs [cssom][css-lists][css-scroll-snap]

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sat, 23 Dec 2017 09:59:11 -0500
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <e23f7a04-f91e-a73c-7458-3d5bce5c7083@inkedblade.net>
[This continues the meeting minutes previously labelled “San Francisco”;
the meeting was actually at TPAC in Burlingame. Apologies for the delay.]

   These are the official CSSWG minutes.
   Unless you're correcting the minutes,
  Please respond by starting a new thread
    with an appropriate subject line.


   - RESOLVED: Make it so that setters to the .style api are appended
               rather than put in place

CSS Lists

   - There was interest in getting a better definition for list-item
       outside marker positioning into the spec.
   - RESOLVED: Add Francois as co-editor to the Lists spec.

CSS Scroll-Snap

   - RESOLVED: When using scrollIntoView you SHOULD take scroll snap
               margin into account.
   - RESOLVED: scrollIntoView MUST use the element position if it has
               one and snapping is on.
   - RESOLVED: Implementation MAY use the snap position if snapping is
   - RESOLVED: We will make the changes to specs as necessary to ack
               scroll snap when no arguments are provided to
   - RESOLVED: Keep scrollIntoView() options as they are.


Agenda: https://wiki.csswg.org/planning/tpac-2017#proposed-agenda

   Rachel Andrew, Invited Expert
   Rossen Atanassov, Microsoft
   L. David Baron, Mozilla
   Christian Biesinger, Google
   Tantek Çelik, Mozilla
   Dave Cramer, Hachette Livre
   Emil Eklund, Google
   Elika Etemad, Invited Expert
   Javier Fernandez, Igalia
   Rob Flack, Google
   Simon Fraser, Apple
   Chris Harrelson, Google
   Daniel Holbert, Mozilla
   Jihye Hong, LGE
   Koji Ishii, Google
   Brian Kardell, JS Foundation
   Brad Kemper, Invited Expert
   Ian Kilpatrick, Google
   Tomoya Kimura, VOYAGER Japan
   Vladimir Levantovsky, Monotype
   Chris Lilley, W3C
   Peter Linss, Invited Expert
   Myles Maxfield, Apple
   Xidorn Quan, Mozilla
   Simon Pieters, Invted Expert
   Naina Raisinghani, Google
   François Remy, Microsoft
   Melanie Richards, Microsoft
   Florian Rivoal, Vivliostyle
   Alan Stearns, Adobe
   Surma, Google
   Dave Tapuska, Google
   Lea Verou, Invited Expert
   Jet Villegas, Mozilla
   Greg Whitworth, Microsoft
   Eric Willigers, Google

Scribe: gregwhitworth


logical/physical property cascade and the .style API
   github: https://github.com/w3c/csswg-drafts/issues/1898

   TabAtkins: Someone pointed out that there are problems with the way
              logical properties are defined when trying to use the DOM
   TabAtkins: They get resolved in the normal order and then go through
              the cascade and we deal with the physical and logical
              based on ordering and writing mode.
   TabAtkins: When you set a property it gets appended to the list of
              properties in the style attribute
   TabAtkins: and if you set one that's already there it just replaces
   TabAtkins: so this can cause it to be out of sync with what would
              happen in the cascade.
   TabAtkins: The proposal is to amend the CSSOM that if something is
              there it is always appended.
   TabAtkins: Related to this
   TabAtkins: we had an issue with !important and we resolved to append
              to make this work.

   dbaron: I'm happy to make that change.
   dbaron: We had a long discussion and resolved the opposite way:
   dbaron: a setter should append.
   dbaron: At the time implementations were inconsistent due to
   dbaron: for existing properties in the fast path they would replace
           and others they would append.
   dbaron: One question, would having to do that mess up optimizations?
   TabAtkins: When we discussed it internally we were fine making the
   dbaron: I found the minutes from 2013 but I'm looking for the other
   <dbaron> Things I found were https://lists.w3.org/Archives/Public/www-style/2013Sep/0469.html
            and https://lists.w3.org/Archives/Public/www-style/2013Oct/0007.html
            but I think there was further followup after the latter

   astearns: So I'm clear, the suggestion to append or remove and then
   TabAtkins: Those are equivalent.
   dbaron: I think it may turn out that it's not equivalent in the
   TabAtkins: We should figure out which one we want, it will need to
              have a note to determine this.
   dholbert: You could inspect the style attr and determine that way.
   TabAtkins: The current model limits to only one.

   astearns: I'm hearing two engines happy to change.
   astearns: Any compat concerns?
   dbaron: Possibly.
   astearns: The compat issue would be limited to logical props
   TabAtkins: No.
   fantasai: It would only affect people looking at style attr value and
             expecting a particular order
   fantasai: which doesn't make much sense, so it's probably not very
   florian: I doubt it's common.
   Rossen: Tools and editors might be doing this.
   TabAtkins: I'd be surprised if the editor was reading the style attr
              and writing to .style.
   Rossen: They could.

   astearns: The proposed resolution is to change CSSOM to append
             values via the .style API and add a note.
   TabAtkins: Yeah, and try to figure that out in the future.
   astearns: Any other opinions? objections?

   RESOLVED: Make it so that setters to the .style api are appended
             rather than put in place

   <dbaron> some links to discussion: https://bugzilla.mozilla.org/show_bug.cgi?id=172073
   <dbaron> (and there's more that I haven't found yet)

CSS Lists

Interop on List-item outside marker
   github: https://github.com/w3c/csswg-drafts/issues/1934

   [fremy projects]
   [notes: https://1drv.ms/b/s!Av6HldQ1OB8gppU68lZS-mwqvguVcg ]
   fremy: More precisely the positioning of the marker.
   fremy: You can center things, but it's 2017 and we still don't know
          where to put the bullets.
   fremy: Got a bug to put the bullet in the right place.
   fremy: [shows bug in Edge]
   fantasai: Wait it is spec conformant?
   dbaron: Yes it is.
   fremy: [shows Chrome]

   fremy: Let's fix it.
   fremy: So I started to look at the spec and it's missing.
   fremy: Spec isn't ready to implement.
   fremy: Put the 2.1 spec text and technically Edge is matching but
          the spec is very vague.
   dbaron: I think I may have been responsible for that note.
   fremy: I get the impression that nothing is defined.
   dbaron: In Chrome it is inside the principal box so it violates the
           2.1 text.
   fremy: We want to fix this issue, but we want to spec it.
   fantasai: Yes.
   tantek: All of those sentences come from long discussions and not
   [References are to the 2.1 text, which defines things as mostly undefined]
   fremy: So I'll describe how Edge is implementing this.

   <leaverou> since we're talking about weird bullet positioning, I'll
              quietly drop this Chrome & Edge issue here, in case it's
              relevant… http://dabblet.com/gist/3731c920fa0ee56efe3ec24a33a88964

   [fremy shows slides and he will post them a bit later]

   fremy: There are two different steps, find out which line box do you
          need to affect with the bullet
   fremy: then horizontally position the bullet.
   fantasai: How we end up describing this, we'll need to really think
             about the markers - what they need to do and what they're
             trying to achieve typographically
   fantasai: we shouldn't need to switch the model.
   TabAtkins: Attaching it to the first <li>, and the first item may be
              overflow: hidden and the marker can disappear.
   dbaron: That doesn't happen in Gecko because we position it to the
           align but it's not actually contained in that.
   dbaron: Back when Gecko did what was in fremy feedback and when we
           fixed it we don't get bugs.

   iank: We're looking at re-implementing markers, our current list
         marker behavior is not nice.
   iank: We're doing something very similar to what you described.
   iank: I'll need to check with Koji, we're doing something very
         similar to what you described, so if you could specify it that
         sounds great.
   fremy: That's what we want.
   eae: Now is the right time for us to spec this.

   <TabAtkins> <li><div style="overflow:hidden">...</div> <= list
               marker is clipped in Chrome!
   fremy: To reply to Tab, to have overflow: hidden we can't put it
          inside of a non-bfc and this is would not happen.

   astearns: So what is the action?
   fremy: I wanted to know if there was interest, it seems like there
   fremy: Sure I'll be a co-editor but I care more about interop.

   RESOLVED: Add Francois to the Lists spec

   <leaverou> TabAtkins: A bit late but bullet is not clipped in Chrome
              in your example, it just inserts a line, see here:
   <Rossen> leaverou, there is a bullet, right?
   <leaverou> Rossen: yes. Tab said there wouldn't be.
   <Rossen> leaverou: good, we have interop then :)

CSS Scroll-Snap

Interaction of scroll-snap and JS scrolling APIs
   github: https://github.com/w3c/csswg-drafts/issues/1707

   TabAtkins: The scroll snap spec defines that if you do a fragment
              nav and it defines margin or something, you should pay
              attention to those.
   TabAtkins: It doesn't have any guidance on similar scrollIntoView
              APIs rather than just target scrolling.
   TabAtkins: We have the API opt into that
   TabAtkins: the API has other properties of its own.

   florian: When you say some properties what are those?
   fantasai: The things we were considering: the scroll snap margin
             that's the indication that there should be additional space
   fantasai: if it has a snap position that's an indication that you
             should snap that position.
   fantasai: The third thing, the UA could opt into using the snap
             position even if snapping is not turned on because the UA
             is trying to determine this and they may utilize this info
             from the author for the best end user behavior.
   astearns: It's a bit vague, but you're going for a must to consider
             the padding and positioning.

   smfr: If it's an element is in scrolled to it but look at it's
         container's scroll margin?
   fantasai: Usually you're looking at the border box for SIV and
             we're proposing to take scroll margin into account.
   florian: The other aspect about snap position, if snapping is not
            turned on but it has position you may use that to position.
   smfr: Would you only look at the targeted item or the ancestor chain?
   fantasai: Just the one that's being targeted.
   smfr: It seems weird that your taking a property that's meant solely
         for scroll snapping and you're adding it to the SIV.
   fantasai: This is adding author intent to the SIV.
   smfr: You could add props to SIV.
   fantasai: This makes it so that the author doesn't have to replicate
             that info into each JS call.
   smfr: Is the UA allowed to override scroll snap margins?

   florian: Is it implied that we should take scroll padding?
   fantasai: Yes.
   florian: I recall doing it in general, but wasn't aware we did it
            for this API.
   fantasai: That was intentional, you shouldn't be able to get in a
             state in JS that you can't get to as a user.

   astearns: The two of you - smfr and Rossen - showed some concern.
   myles: We have to make sure that websites that turn off scroll
          snapping, with this change the margin will now have effect.
   fantasai: Usually this will get you a better experience.
   myles: I'll be for implementing this and seeing if this has a web
          compat issue.
   fantasai: I don't think we should have a web compat issue.
   myles: I think we can resolve on this.
   astearns: I'm hearing some movement to resolving.
   astearns: Anyone object?

   RESOLVED: When using scroll-into-view you should take scroll snap
             margin into account
   RESOLVED: scroll-into-view must use the element position if it has
             one and snapping is on
   RESOLVED: Implementation may use the snap position if snapping is off

   florian: Should this change intersection observer?
   TabAtkins: I don't think we should bring this in?

Scroll Into View options
   github: https://github.com/w3c/csswg-drafts/issues/1708

   fantasai: There are several different options that target an
             element, such as scroll into view.
   fantasai: Then there is the focus api.
   fantasai: They take a bunch of args for smooth scrolling or not, and
             how that element should be aligned within the viewport.
   fantasai: The default behavior should be following the scroll
             snap if scroll snap specifies something; currently the
             API definition overrides scroll-snap.
   fantasai: The second question is, are those options even necessary
             if there are scroll snap options?

   TabAtkins: We discussed this internally, there may be areas where
              you want to do one off alignment.
   fantasai: Do you have a usecase?
   eae: One is up and down arrows, you may want to align to the top or
        the bottom.
   iank: If you have a news feed you may want to use one or the either
         based on direction.
   dbaron: We had a discussion about these options a few weeks ago.
   dbaron: In that discussion I pasted the link to our internal code
           and if we want use cases where we use it.
   <dbaron> The Gecko internal API is documented here:

   smfr: Is scrollIntoView default the same as SIV false?
   smfr: We may scroll it into the top or the bottom, just as long as
         it's in the view.
   TabAtkins: This became a weird api for legacy issues.
   eae: Our default is either true or false based on distance.
   <smfr> webkit has scrollIntoViewIfNotVisible(bool centerIfNotVisible)

   florian: Your usecase of the newsfeed I think we should solve that
            in CSS scroll snapping.
   myles: But that criteria of direction could be a bunch of different
          criteria, I don't think we should do that.
   dbaron: Some of the complicated ones come from the a11y code.
   iank: It looks like scrollIntoView args might be different than
         scrollIntoView with bool.
   iank: If it's bool we set the block to start.
   TabAtkins: That isn't per spec.
   iank: ok
   eae: Ours is completely broken.
   TabAtkins: I may open an issue on this.

   astearns: I'm hearing at least 4 threads of conversation.
   astearns: Do we need to have any more discussion about scrolling the
             least amount?
   TabAtkins: That's a separate thing to consider for scroll snap.
   astearns: 1. The argument at the end should be dropped - sounds like
                they should not be.
             2. Should scroll snap win when there are no args in SIV -
                that sounds like there are no arguments against that.
   <dbaron> there seem to be different behaviors for: various a11y
            things, going to named anchors, focus changes, caret
            position changes, dom apis to scroll element into view, and
            some other things (e.g., things related to form autofill
            popups or devtools)
   fantasai: The two specs conflict.
   fantasai: The OM spec doesn't ack scroll snap.
   astearns: Does anyone have any objection to making those changes?

   RESOLVED: We will make the changes to specs as necessary to ack
             scroll snap when no arguments are provided to
   fantasai: Anything that does scrolling needs to be evaluated to
             allow scroll-snap to specify default scroll positioning.

   astearns: Any objections with not mucking with the ScrollIntoView()

   RESOLVED: To keep scrollIntoView() options as they are
Received on Saturday, 23 December 2017 14:59:50 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:06 UTC