[CSSWG] Minutes Sydney F2F 2016-02-02 Part IV: Snap Points, bookmark-level: auto, Sizing [css-snappoints] [css-break] [css-sizing]

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


Snap Points
-----------

  - RESOLVED: The only pseudo elements that snap points apply to are
              ::before/::after but add a note that suggest there
              "might" be a future pseudos that can support snap
              points.
  - There needs to be more use cases before deciding how to behave
      with snapping to unreachable elements.
  - Still no decision on renaming proximity and mandatory. Current
      suggestions are near|always, force|allow, force|proximity,
      force|near or keep the original names.
  - RESOLVED: Defer 2D snap to the next module level of snap points

bookmark-level: auto
--------------------

  - bookmark-level will stay the same in CSS Break.

Sizing
------

  - gregwhitworth will investigate if min-width on tables is possible.

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

Agenda: https://wiki.csswg.org/planning/sydney-2016

Scribe: gregwhitworth

Snap Points
===========

Applicability to pseudo-elements
--------------------------------

  florian: Not sure how much we can do without Matt R. and Tab
  <astearns> https://lists.w3.org/Archives/Public/www-style/2016Jan/0193.html
  florian: The snap points spec does not say whether pseudo elements
           can have snap points or not.
  florian: The pseudo spec implies that everything should work
           unless there is an exception.
  florain: Snap points not having an exception they should apply.
  florian: There are many specs that say it one way, others another
           and some don't at all - so assumptions are made and at
           times are incorrect.

  rossen: This is in context of snap points why?
  florian: Because I wasn't sure.

  dbaron: The way to solve this is to find a spec that should have a
          definition for this and assign the all elements and
          hyperlink to a definition to that.
  <dbaron> i.e., there should be a hyperlink in Applies to: <a>all
           elements</a> with the anchor linking to something that
           says "all elements" includes ::before and ::after.
  fantasai: Any spec that states specifically applying to ::before
            ::after should be removed unless it's stating that it's
            excluded.

  ACTION TabAtkins to change bikeshed to: there should be a
         hyperlink in Applies to: <a>all elements</a> with the
         anchor linking to something that says "all elements"
         includes ::before and ::after
  <trackbot> Created ACTION-753

  <tantek> question, what do implementations do with snappoints on
          :before and :after?

  florian: The second part of the question is can you have snap
           points on other pseudo elements other than
           ::before/::after - TabAtkins said no
  astearns: Usecase is to snap to spelling errors.
  rossen: There's scrollTo for that type of thing,
  tantek: ::first-line you wouldn't.
  tantek: It's not cut and dry.
  fantasai: There has to be a clear use case as it's significant
            implementation cost to achieve this.
  fantasai: I'm not convinced to add this to the spec unless there
            is author demand.
  fantasai: You might want to have it snap into the viewport, but
            that's an edge value.
  florian: I think ::before/::after are compelling.
  fantasai: For consistency sake.
  rossen: Even they're on the border.

  plinss: I'm confused about future things, and I don't like
          constricting it pointlessly.
  florian: It's due to implementation complexity.
  plinss: Think about pseudos for columns, paged etc - we shouldn't
          set a precedent.
  fantasai: I would happily introduce a ::column pseudo that takes
            only the scroll-snap properties.
  rossen: It's most useful on structural elements.
  plinss: If it's a big barrier I'm ok with a should.
  rossen: For us it is.
  fantasai: I would prefer not to add it now, because of the
            additional testing.
  fantasai: The pseudo draft says whether it applies or not, and
            when we add more we can add them in.
  astearns: That means in the future if we have compelling use cases
            for this we can bring them back in to have support.
  astearns: In general closing them off now, does this close them
            off forever.
  rossen: No - just for this version of the spec.
  esprehn: I don't think you're ever stuck, we can just add more
           properties if necessary.
  esprehn: As an implementor, anything other than ::before/::after
           is really hard.
  tantek: There has to be a way to spec an opening for more pseudos.
  plinss: I'm open to a note that says we may apply this to new
          pseudos in the future.
  tantek: I'm ok with an informative note, I don't want to mislead
          people.

  RESOLVED: The only pseudo elements that snap points apply to are
            ::before/::after but add a note that suggest there
            "might" be a future pseudos that can support snap points.

Snappability of unreachable elements
------------------------------------
Scribe: ewilligers

  florian: If a snap point has always been beyond reach, and you
           scroll beyond,
  Florian: (draws on board)
  [Florian draws a scroller, with snap-padding on the top and bottom.]
  [There's a large element, fills the size of the viewport]
  [There's also a tiny element, at the bottom of the scrollable area]
  [Both request center snapping]
  <alancutter> Photo of Florian's diagram: http://imgur.com/27CdHCU
  Florian: It has a somewhat large snap-padding area.
  Florian: We have a large element with a center snappoint, some
           margin,
  Florian: a small element with a center snappoint,
  Florian: the snappadding is larger than the small element.
  Florian: There is no way that you can scroll the small element
           into the center.
  Florian: The spec is vague / contradicting itself - two parts of
           the spec.
  fantasai: That is a valid snap point.
  Florian: One: things that are unreachable would be the most
           appropriate to snap to, you must snap to them.
  Florian: Spec does not clarify "most appropriate"
  Florian: Second part of spec: if an element is entirely outside
          the scrollsnap area, it is not considered.
  Florian: Suspect was intended for 1d scrolling.
  Florian: Lots of things should be up to UA, but not this.
  Florian: Making things reachable should not be UA dependent.
  Florian: Spec is ambiguous. "Must" part relies on ambiguous term.
  fantasai: We should reorder the paragraph. Expected snap position
            is bottom of screen.
  Florian: The part of spec that says you must snap to it use
           ambiguous words. Other part of spec contradicts: part
           that speaks about corridor,
  Florian: accidentally contradicts "if you never enter the scroll
           area, not considered."

  esprehn: As a user, what do you want to have happen?
  Florian: I think it is a wording issue.
  fantasai: We need a specific wording proposal.
  astearns: The next step is for Florian to propose a wording
            change, send to the list.
  Florian: Based on tab's answer, I thought there was actual
           disagreement.
  Florian: Spec describes 3 types of scrolling, ... semantic
           scrolling, inertial scrolling, 4th type: indirect
           scrolling: move focus, or change carat. no wording in spec.
  fantasai: Explicit scrolling is scroll to specific position.
  Florian: You are not scrolling to specific position. On focus,
           scroll is a side effect. Do we have invisible carat /
           focus button. It is not clear.
  fantasai: There is a section in spec that Tab and I added, dealt
            with target case.
  <fantasai> "If a page is navigated to a fragment that defines a
             target element (one that would be matched by :target),
             and that element defines some snap positions, the user
             agent should snap to one of that element’s snap
             positions. The user agent may do this even when the
             scroll container has scroll-snap-type: none."
  fantasai: The user agent should snap... So should we apply this to
            more cases like :focus?

  Florian: What happens if container has mandatory snapping and
           element does not have a snappoint?
  fantasai: You need to be careful with mandatory snap position.
            Authors need to be careful.
  Florian: Other option: things that match the target pseudo class
           and focusable things and editable things in a mandatory
           scroll container if they are not within things that have
           a mandatory snappoint, have a snappoint.
  hober: I prefer first option.
  Florian: In that case, the magic is not that hard, but if we want
           to go without, make clear to authors.
Scribe: ewilligers, alancutter
  esprehn: I want to talk to accessibility people.
  Florian: As currently defined it will not.
  Florian: I think the magic is something we can work and and will
           be useful.

  zcorpan: Web authors will hate this.
  zcorpan: It gives behavior they didn't ask for.
  zcorpan: In general we should avoid magic stuff.

  gregwhitworth: While I sympathize with authors, end users will
                 expect endpoints when they hit tab.
  gregwhitworth: I would prefer accessible users to see input that
                 is selected over the preferred behavior of web
                 authors.
  esprehn: People make their browser different sizes that produces
           bad situations.
  zcorpan: You are talking about keyboard navigation.
  zcorpan: When navigate by keyboard, user tabs between form controls.
  zcorpan: I would expect snapping to not happen.
  gregwhitworth: I think that's what we're saying, we should put
                 together a bunch of test cases.
  gregwhitworth: We could potentially fake it in some cases.
  gregwhitworth: I don't know if we can resolve but it's worth
                 testing.
  Florian: We need to eventually resolve this,
  gregwhitworth: Sure.

Indirect scrolling
------------------

  Florian: I have a related other topic, also about indirect
           scrolling.
  Florian: Focus on something, moving the carat, proximity snapping.
           We have a button with no snappoint.
  Florian: There's nothing to prevent scrolling into visible area.
  astearns: If this is the email that you sent on the mailing list
            we should wait for editors to respond.
  Florian: If this in not a good time to talk let's talk later.

Naming of proximity/manditory
-----------------------------
  Scribe: ewilligers, alancutter, esprehn

  fantasai: There was a bikeshedding discussion to have, about the
            naming of proximity/mandatory
  astearns: What are the proposed names?
  fantasai: The proposal was "near" and "always". Any other ideas?
  esprehn: Sounds great.
  Florian: I prefer the current one.
  astearns: The benefit to near and always is shortness and we use
            it in other CSS things.
  Florian: We removed them.
  Rossen: I prefer proximity and mandatory.
  <zcorpan> have these shipped?
  <fantasai> yes, but we removed everything that shipped
  <zcorpan> ok
  astearns: Sometimes it's good to have bikeshedding face to face
            but it seems like it's not working right now.
  fantasai: force / allow?
  <fantasai> scroll-snap-type: none | force | allow

2-d snapping keep or push out
-----------------------------

  esprehn: We support shipping a minimal subset.
  dbaron: Not sure what we currently implement.
  ojan: Our people working on snapshots are not here.
  esprehn: They're interested in shipping an interoperable
           implementation.
  Rossen: Is there an official resolution to this in Sapporo?
  Rossen: Can we put this for resolution?
  hober: We didn't have an exact resolution in Sapporo.
  Florian: If this is something we all agree on at-risk is fine. At
           risk is the wrong tool and we should remove it.
  dino: We don't want to be the trail blazers and implement it and
        find it's not useful.
  Florian: At Risk allows you to do that.
  dino: If the other implementors don't want to do it what's the
        point?
  rossen: This is a really awesome feature, when we ship it would be
          great if we can without prefix/holding back.
  Florian: We don't want to drop it and end up with a spec we can't
           add it back to.
  hober: We have version control.
  <zcorpan> hober++
  fantasai: We already accounted for this in the text.

  dino: We appreciate the great work from TabAtkins and fantasai,
  dino: but we want the spec to be merged soon so we can implement
        soon,
  dino: not saying keep it out forever.
  fantasai: Florian is saying we don't want to make changes in the
            merge that make it impossible to go back to the 2d
            design later.
  fantasai: I don't think that'll be a problem.
  fantasai: That's not what we resolved on, but I don't think
            that'll be a problem.
  astearns: I think we have consensus?

  RESOLVED: Defer 2D snap to the next module level of snap points

Naming of proximity/manditory
-----------------------------

  astearns: Force and allow snapping, much shorter words.
  SteveZ: Doesn't say the same thing.
  Florian: Permit is a good synonym for allow.
  SteveZ: Force is a verb, it needs to be a verb...
  esprehn: What's the default value?
  Florian: None.
  esprehn: Why not auto?
  <zcorpan> none | force | auto
  Florian: Proximity is auto?
  Rossen: Auto is the default word for magic.
  Florian: It's hard to guess what it does from the name, proximity
           is more clear.
  <zcorpan> none | force | proximity
  dbaron: Near and exact?
  Rossen: Force and proximity sounds good.
  Florian: Force and proximity makes force sound like a noun when it
           is a verb.
  shans: What about exact?
  Florian: Exact is bad, it sounds like you have to go exactly to
           that point.
  dbaron: We seem to be happier with nouns and adjectives than verbs.
  <Rossen> none | force | near

bookmark-level: auto
=====================

  astearns: Next thing, bookmark level auto.
  <astearns> https://lists.w3.org/Archives/Public/www-style/2015Nov/0310.html
  Florian: I want to talk about bookmark-level.
  Florian: There is a set of properties, bookmark-level. When you
           generate PDF,
  Florian: The bookmark you get in PDFs that take you to certain
           parts of the document.
  Florian: The nesting of your sections seem like something derive
           from the structure of the document instead of
  Florian: requiring authors to define it.
  Florian:  "auto" could derive this structure for the author.
  esprehn: Which thing does not exist?
  Florian: Bookmark-level: auto, this should be something you can
           figure out from the structure of the document.
  Florian: Instead of manually specifying it.
  Florian: Things could get out of sync.
  esprehn: Does any one implement bookmark-level?
  Florian: Print formatters do.
  Florian: This will lower the work required to take a document for
           the screen to a PDF with bookmarks.
  Florian: I don't think we can do this with selectors.
  Florian: I tried existing selectors including non-implemented ones
           and failed.
  esprehn: auto doesn't seem very hard to implement this (as an
           implementer that doesn't implement bookmark-level)
  esprehn: As long as it's not like counters in CSS I support this.

  plinss: I kind of have a fundamental issue of why are we
          reinventing hyperlinks?
  esprehn: I don't want reset, skip, increment, etc. again.
  Florian: I don't mean we should mandate how a sidebar works.
  plinss: This whole feature smells like something very specific to
          PDF and has nothing to do with the web platform.
  astearns: dpub folks have been talking about an explicit <nav>
            element with links.
  astearns: I don't think it's adding a random feature it's
            streamlining a process.

  fantasai: There are multiple implementations of bookmark-level.
  Florian: Viviostyle has it in their roadmap to implement this for
           screens.
  esprehn: I think this is part of CSS and shouldn't be treated as a
           separate focus group.
  esprehn: Thinking of Houdini this is not the way we want to go
           with CSS.
  esprehn: We want to add extensibility points instead of magic.
  Florian: What is magic about it?
  SteveZ: It's a table of contents.
  plinss: If you want an element that generates a table of contents
          that should be part of the document not CSS.
  Florian: Our engine needs to implement this to be compatible with
           existing content.
  plinss: Table of contents is content, not styling.
  SteveZ: A table of contents is a relabeling of content. It's
          presentational.
  plinss: I disagree.
  SteveZ: It's taking existing content and putting it elsewhere in
          the display.
  skk: The bookmark sounds like a data structure and not like styling.
  esprehn: With custom properties you can define the bookmark level
           property to do whatever you want and we don't have to
           talk about this.

  Florian: It has three interoperable implementations, it's not a
           new feature.
  tantek: Let's see the usage numbers, if it's like 10...
  Florian: Should I go to WHATWG for this, is the CSSWG not allowing
           this?
  Florian: I can't do this with houdini with current browsers.
  esprehn: I don't think this fight is productive, there's an out
           now for this.
  Florian: This is a request for a new keyword for an existing
           property.
  Florian: Not about removing this property from CSS.
  astearns: We are not going to resolve modifying or removing this
            property today.

  <zcorpan> in httparchive 470k pages i see one page matching
            bookmark-level in css (actually prince-bookmark-level:1)
            http://www.wowrean.es/ http://eu.wowrean.es/public/print-default.css

Fragmentation and Transforms
----------------------------

  <Florian> http://jsbin.com/fuloge/edit?output
  Florian: If you open this, it appears that Chrome and Webkit do
           one thing.
  Florian: Other browsers, and print formatters, do something else.
  Florian: Chrome and WebKit are the only ones that get this right.
  Florian: It's a list of numbers positioned relative down.
  dbaron: You have to use frame source. It doesn't work in jsbin.

  dbaron: The question is "does position relative work across
          pagination?"
  Florian: I think the spec says...
  <Florian> https://drafts.csswg.org/css-break/#transforms
  dbaron: Is this CSS break? This is a new spec, newer than the
          implementations.
  Florian: Am I correctly understanding that the spec is asking for
           Chrome's behavior?
  astearns: The spec is a bit older than David represented.
  <dbaron> OK, the spec is 4 years old
  <dbaron> still newer than all implementations
  astearns: It ended up this way so we would not lose content when
            paginating with relatively positioned content.
  dbaron: Does Chrome get this right because it gets all the other
          parts of this section wrong and it gets this right?
  Florian: We're wondering what our implementation should match.
  esprehn: Firefox looks like it's moving all the content down in
           each column.
  astearns: Both behaviors have their uses.
  astearns: Either in printing or in scrollable situations.
  astearns: I think Firefox's behavior looks nicer in this case.
  esprehn: We implement this section of the spec wrong.
  Florian: So after fixing you're likely to match Firefox?

  fantasai: This rule is only about pagination, not about columns.
  fantasai: The reason for that is if you don't do that you lose
            content.
  fantasai: We recommend that for printing we do this slicing after
            having transforming stuff.
  esprehn: I suspect our response is we will not implement this,
           multicol implementors have said this seems very
           complicated.
  <gregwhitworth> In addition, I opened a bug on Chrome that deals
                  with multicol that got duped to this one, and it's
                  assigned - they may be able to address this while
                  they're in this code:
https://code.google.com/p/chromium/issues/detail?id=223068
  <gregwhitworth> not be there should not be an option IMO

  Florian: I'm not happy about the "should", some browsers will
           behave different.
  fantasai: I would rather a should than nothing at all.
  dbaron: I'm skeptical about "should" because it takes a lot of
          energy to implement this and browsers are probably going
          to implement something else.
  dbaron: I'd rather not add complicated things to specs for things
          no one implements.
  <fantasai> "3. SHOULD This word, or the adjective "RECOMMENDED",
             mean that there may exist valid reasons in particular
             circumstances to ignore a particular item, but the full
             implications must be understood and carefully weighed
             before choosing a different course."
  <fantasai> RFC2119
  esprehn: We are interested in an interoperable version of
           multicol, we're not interested in anything fancy.
  Florian: Once that happens all browsers and print formatters will
           do the same thing.
  hober: We don't want to regress with regards to the epub corpus;
         too much there.
  Florian: I have my answer regardless of what the spec ends up
           saying.
  astearns: Sounds like a good place to leave this.
  fantasai: If Hyatt has a *better* solution, be happy to consider
            that for the spec.

  astearns: Shane wants to have a talk about scroll linked animations.
  astearns: The second thing is koji had an additional topic if
            you're ready.
  astearns: We have <30min left.

[Discussion of word-break: break-word; moved to CSS3 Text section of
    minutes.]

Sizing
======

  fantasai: Do we know whether we can switch table cells to honor
            the min-width property?
  gregwhitworth: I don't have data but I'm shocked that you can't
                 use it.
  gregwhitworth: We can gather data.
  fantasai: Proposal if it's possible: min-width applies to table
            cells.
  dbaron: We could add properties that set the intrinsic widths,
          unlike the min/max-width properties that set constraints
          on the width ... useful outside of tables.
  ACTION gregwhitworth: look into allowing min-width on tables to
         work, and auto to work like it currently does - will
         require test cases for L2 of tables and possibly sizing as
         dbaron said it's helpful for intrinsic sizing beyond tables.
  <trackbot> Created ACTION-754

  fantasai: Let's switch to sizing.
  fantasai: Was talking to Tab about sizing module.
  fantasai: Our proposal: Taking keywords that we have and define
            them in terms of CSS2.1 (which makes them mostly
            undefined) instead of trying to define thme fully.
  fantasai: ... This would let us trim down the spec a lot.
  astearns: Sounds like a fine plan, make the edits, send to working
            group and see what feedback you get.

  <fantasai> https://drafts.csswg.org/css-sizing/
  fantasai: Dropping chapter 4 and 5, and fill-available keyword
  astearns: Anyone object to this idea?
  Florian: Does this limit us to refer to these concepts?
  fantasai: No you can still refer to them in Sizing 4.
  astearns: I'm not comfortable with resolving on this strategy just
            yet as we've only had 5 minutes to think about it.

  fantasai: I have an issue with alignment but I'll talk to dbaron
            first.

  astearns: Adjourned.

Received on Wednesday, 23 March 2016 21:32:59 UTC