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

[CSSWG] Minutes New York F2F 2015-05-18 Part I: CSS Break, Communicating the State of CSS

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 26 May 2015 19:17:22 -0400
Message-ID: <CADhPm3ukRTRmYaP69qoZEZaH3dWmk_A02-N2PTg7XWJDrCimJA@mail.gmail.com>
To: www-style@w3.org
CSS Break
---------

  - RESOLVED: Don't make the break-inside changes for level 3; in
              level 4 look into the "allow" keyword and defining
              "auto" behavior to represent the default behavior.
  - RESOLVED: Close issue 10 (allow keyword combinations in break-*)
              as no change, punt to next level. (Generic 'avoid' will
              solve most use cases.)
  - RESOLVED: If the cloned border is larger than the fragment, drop
              it. Drop bottom first; then drop top if still no space.
  - RESOLVED: box-decoration-break clones margins (note this only
              affects inlines)

Communicating the State of CSS
------------------------------

  - glazou brought the feedback of from the AC group that people
      would like a more up to date "What is the status of CSS"
      method than the current snapshot.
  - There will be a few changes that show help the issue including
      some pending changes to bikeshed, and a script will be written
      to add an out of date watermark for /TR.
  - Once the changes are completed, they will be taken back to the
      AC group for feedback and further improvement.

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

Present:
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Bo Campbell
  Dave Cramer
  Elika Etemad
  Daniel Glazman
  Ian Kilpatrick
  Chris Lilley
  Peter Linss
  Simon Fraser
  Florian Rivoal
  Andrey Rybka
  Simon Sapin
  Shane Stephens
  Lea Verou
  Jet Villegas
  Johannes Wilm
  Greg Whitworth
  Steve Zilles

Regrets:
  John Daggett
  Dael Jackson
  Simon Pieters
  Anton Prowse
  Hyojin Song
  Alan Stearns

Agenda: https://wiki.csswg.org/planning/new-york-2015#agenda
Scribe: dbaron

Agenda
======

  [glazou edits agenda to schedule things]
  glazou: At AC meeting I got feedback that we need a document
          describing the current state of CSS
  various: not the snapshot?
  SteveZ: One thing people want with tools is to automate some
          things so you can have a crawler that updates page.  When
          editor or chair updates it it always gets out of date.
  glazou: It's not the topic right now; that's the agenda.

Scribe: TabAtkins

CSS Break
=========

  <fantasai> http://dev.w3.org/csswg/css-break-3/issues-lc-2015
  fantasai: There's a few issues for the WG.

Replaced Content
----------------

  fantasai: First is replaced content.
  fantasai: We have an issue from howcome. We currently say you can
            slice an image if it doesn't fit, but you should try to
            move it first.
  fantasai: He suggested we should be able to control it, to make it
            slice immediately.
  fantasai: One way to do it is to say that replaced content has
            "break-inside:avoid" in the UA stylesheet.
  fantasai: So the author can change that.
  fantasai: On <img>, <iframe>, etc.
  Florian: This gives the same current behavior, and easily controls
           if you want different behavior, so looks nice.

  fantasai: Yes, however you wouldn't get the avoidance behavior by
            default if you were using some other type method of
embedding, content, like from the 'content' property.
  dbaron: There's also a slight difference with <object> fallback
          by default getting the break-avoid behavior,
          though I'm not sure how much that matters.
  dbaron: We should probably have a pseudo to select when it's doing
          fallback, so we can deal with those cases.
  dbaron: I think Gecko actually does have a pseudo.
  TabAtkins: I think the change sounds good.

  RESOLVED: Allow break-inside to work on replaced content, put
            "break-inside:avoid" in the UA stylesheet for replaced
            elements.

  SteveZ: Should we put it in create pseudos to select fallback?
  [wait, something about 'content' instead]
  fantasai: We can't have a selector based on a property.

  fantasai: For example, if we have 'content' image, it would get
            sliced in the middle by paginating.
  dbaron: Does this property apply for things like inlines?
  fantasai: Yes, it'll forbid a page break within the inline. (But
            we don't allow page breaks there anyway.)
  Florian: Maybe explicitly add an "allow" value, and have "auto"
           give the right behavior to replaced content?
  fantasai: Yeah, I think I like that better.
  fantasai: I'll propose that to howcome and see what he thinks.

  RESOLVED: Never mind the previous resolution, instead try to
            redefine "break-inside:auto" to work correctly for
            replaced elements.

  fantasai: So in this level, or next? I'm leaning for next level.
  fantasai: Want to wrap up this level.
  fantasai: And there's still some questions about what "auto"
            should do in some cases.
  SteveZ: Agreed, it's too many unanswered questions for CR.
  fantasai: So let's have auto do what it says right now, and next
            level we add the new behavior.

  RESOLVED: Don't make the break-inside changes for level 3; in
            level 4 look into the "allow" keyword and changing
            "auto" behavior to automagically work correctly.

"Any" Confusion
---------------

  fantasai: Next issue: "any" is confusing.
  fantasai: What it does is find the nearest ancestor fragmentainer,
            and fragment that.
  fantasai: If you have a multicol which is in a region chain, and
            we're printing. "any" will cause a column break.
  Florian: Suggest "closest" as a name? Better than "deepest", which
           suggests starting at top rather than going down.
  dbaron: "closest" might suggest lateral movement
  TabAtkins: DOM has .closest(), from jQuery, which has this exact
             semantic.

  fantasai: I'm not even sure "any" has a use-case.
  fantasai: I'd like to hear from SteveZ, plinss, alan, etc for if
            there's even a use-case for "any" or if we should just
            drop it.
  johannes: Why did we even add it?
  fantasai: I think it was because we had an "always" value, and it
            wasn't clear what it meant. We decided it meant "break
            through everything", and we'd add "any" to have the
            other semantic.
  Florian: There's definitely cases to break the closest thing, but
           you probably know what type of break it is.
  Florian: When you ask for a "column" break, does it break the
           nearest column or all?
  Rossen: Nearest.
  Rossen: I think that's the right use-case, yeah.  Content that
          might be in a multicol *or* a region, isn't aware of how
          it's fragmented, but wants a break.
  Rossen: Like if you have content with sections, and you want
          sections to always start at the next fragment, regardless
          of whether it's in columns or pages.
  SteveZ: Like if you have a template you're filling.
  Florian: Using overflow:fragment, you might start in multicol and
           then overflow into a region chain.  You can't tell ahead
           of time what kind of break you need to trigger.

  fantasai: Can we check if AH or Prince implements it?  If they do,
            and we can't come up with a *much* better name, we
            should maybe keep it.
  Florian: Prince has the *-break-before props, but not the combined
           break-before, so no compat impact.
  fantasai: [reviews the spec]
  fantasai: Hm, "always" is defined as a page break here.  Looks
            badly specified.
  ACTION fantasai to clarify 'always'.
  Florian: According to AH docs, they don't support "any".

  fantasai: For regions, I can see a use-case for a "column and/or
            page" break.
  fantasai: Regions are trickier.
  fantasai: You can use them for paginating, but they might be for
            other weird things.
  fantasai: So I can see a value that breaks columns/pages, but not
            regions.
  TabAtkins: I'd prefer we wait till we have more fragmentation
             types, so we can generalize properly.
  fantasai: We'll discuss over break, do more thinking.

Combining Keywords
------------------

  fantasai: Next topic: what if I want to avoid breaks in columns
            *and* pages.
  fantasai: I said to use "avoid". It also avoids region breaks, but
            for most cases it's probably good enough.
  fantasai: We could let the property have multiple values.
  fantasai: So you can say "avoid-column avoid-break" and leave
            regions alone.
  fantasai: I don't think that's too necessary. I suggest we wait
            for the next level, especially since I'm not sure of
            all the side-effects of making this change.
  plinss: I think it's less unusual to *force* breaks on
          column/page, but not regions.
  plinss: So maybe worth doing all the combinations.

  dbaron: I guess I'm starting to feel like this is a very weird API.
  dbaron: It kinda made sense when it was just page breaks, but now
          that things can be nested, this doesn't feel like a
          sensible way to force a break.
  dbaron: I don't have any ideas to fix it.
  dbaron: But I think anyone who actually hits these cases will find
          the properties unsatisfying.
  Florian: For advanced cases wouldn't you need to be able to name a
           fragmentainer, and say to break up to that name?
  dbaron: Maybe.
  fantasai: For regions especially, yeah.
  fantasai: I can't imagine a case of nested multicol.
  Florian: Multicol text, and in that, small bulleted list that is
           multicol.

  fantasai: My proposal is no change, and deal with it next level.
  TabAtkins: Sounds reasonable to me.
  dbaron: How stable is the break-before/after naming?
  fantasai: Pretty stable. It's been in the multicol spec since that
            hit CR.
  fantasai: We have impls in at least AH and (old) Opera.

  dbaron: This discussion is making me skeptical that this is what
           we want.
  SteveZ: Skeptical that it's hard to get what you want, or that
          there will be weird effects, or...?
  dbaron: I think all of the above.
  dbaron: It seems like we extended the old thing into the new
          thing, and it's not the right shape for the new thing.
  fantasai: I think having a generic "region" name is awkward; you
            generally want to name the region you're breaking to.
  fantasai: Pages/columns are less awkward. They don't nest often.
  SteveZ: It seems to me there's a difference between "avoid", which
          you want to apply in any context, and breaks, which needs
          some information about context. Maybe sticking those
          together is the problem.
  fantasai: Yeah, maybe. But you can't both force and avoid a break.

  dauwhe: We had a user request for prioritizing breaks. TeX does
          that.
  fantasai: We do have some priority - break-inside:avoid does some
            priority of what to do with breaks in descendants, based
            on number of avoids in effect at that breakpoint.
  fantasai: Without using numbers. Uses the nested structure.
  fantasai: Would like to avoid the z-index number escalation
            problem.
  [Authors set crazy high z-index numbers to "win" the top position]
  fantasai: There might still be cases where an arbitrary number is
            necessary, but much smaller set.

  Bert: WRT named regions, we also had a proposal for naming page
        templates, so you could break to a particular type of page.
  Florian: For InDesign, it has region/column/page/even-page/
           odd-page.
  fantasai: We have left/right/recto/verso in the break spec.
  <Florian> So this means that InDesign has neither always nor any
  <astearns> you want to name your fragmentation context, not really
             a specific region

  fantasai: My proposal is to close issue 10 as no change,
            investigate syntax for next level.
  RESOLVED: Close issue 10 no change, punt to next level.

box-decoration-break & margins
------------------------------

  fantasai: Last is about box-decoration-break and margins, and
            whether "clone" clones margins.
  fantasai: If I have a box with a border, and it breaks, there's
            two ways to handle it.
  fantasai: First is to just slice the box, so no border at slice.
  fantasai: Other is to wrap the border around fully for each piece.
  fantasai: So question is whether to clone margins too.
  fantasai: So if you had margin-top, does that show up at the top
            of the next fragment?
  Florian: Margin-collapsing?
  fantasai: Interesting.
  [Florian was pointing out that margins at unforced fragmentation
  breaks collapse to nothing.]

  dbaron: And what if multiple collapsing elements have differing
          values for box-decoration-break?
  [This doesn't seem to be an actual problem, each box does what it
      does.]

  fantasai: Current behavior is to restart the next page at the
            border box; no cloning of margins.
  Rossen: Yeah, anything else can get weird, especially with
          negative margins.

Cloned borders vs. Sufficient space
-----------------------------------

  Rossen: Another case is the border itself being bigger than the
          next fragment; will infinite-loop currently.
  fantasai: We said you have to make at least 1px of progress in
            each fragment.
  Rossen: So you'd just print part of the borders on each page, with
          1px of content overflowing off the page.
  Rossen: Sounds "useful".
  Rossen: I propose that if there's not enough space to clone, we
          drop the borders.

  SteveZ: There's some govt stuff about mandatory borders on
          warnings.
  Florian: Just don't print your govt warnings on 10px tall pages.
  TabAtkins: This isn't something we're doing wrong on our part.
             It's badly-authored pages. It's the author's fault if
             they're violating some govt standard.
  fantasai: So you drop the bottom border in each fragment.
  Rossen: No, both borders. The top border can also be too tall.
  Rossen: [draws example in MSPaint]
  Rossen: In this example, the top border *itself* is too tall to go
          in the fragment.
  TabAtkins: If we're willing to drop the bottom border to avoid the
             "1px of progress per page" case, why wouldn't we be
             willing to drop the top too? We can prioritize dropping
             bottom first.
  Rossen: Yes.
  SteveZ: What about left border?
  Rossen: Not relevant; you don't fragment in 2d. You just overflow
          if your side borders are too big.

  RESOLVED: If the cloned border is larger than the fragment, drop
            it. Drop bottom first; then drop top if still no space.

box-decoration-break & margins (cont.)
--------------------------------------

  fantasai: And I think issue 13 is that it doesn't matter; margins
            get collapsed into the pagination break.
  Rossen: Yeah.
  dbaron: Margins don't disappear for inlines, right?
  fantasai: Right.
  dbaron: Presumably box-decoration-break applies to inlines, too.
  fantasai: Yes.
  fantasai: So yeah, inlines are still a problem. No strong opinion,
            but since inline margins don't normally collapse into
            the line edge, I think we should keep it (clone inline
            margins)

  RESOLVED: box-decoration-break clones margins (note this only
            affects inlines)

  [Snack break]
  <dbaron> FWIW, Gecko's implementation of
           box-decoration-break:clone on inlines does agree with
           what we just resolved
  <dbaron> i.e., we do clone the margins

Communicating the State of CSS
==============================
Scribe: fantasai

  glazou: During AC meeting, two weeks ago, there were extensive
          discussions about future of HTML and organization of all
          activities of the consortium;
  glazou: One of the proposed plans is to drastically reshuffle the
          working groups.
  glazou: HTML, WebApps, etc.
  glazou: The good thing is that the CSSWG would be untouched.
  glazou: "It is an example of a WG that works well, and we don't
          touch things that work well."
  glazou: I think we should be glad about it :)

  glazou: One remark I got, there are more and more questions about
          "what is the current state of CSS?" and "what is CSS as of
          today?"
  glazou: People are aware of the snapshots, and current-work, and
          our work on the /TR page.
  glazou: They would like us to maintain it better, automatically or
          not, don't care, but better.
  glazou: If you are a newcomer, where do you find out
          standards-wise the state of CSS or implementation-wise the
          state of CSS?
  glazou: I asked plh, do you really want us to handle
          implementation status ourselves? There is caniuse, etc.
  glazou: He replied, yes, I'd love to have workforce within W3C to
          handle these kind of things.
  Florian: I would guess the goal would be different than caniuse
  glazou: Question is, can I rely on it or not?
  glazou: I think it would be important wrt outreach for us to
          handle these concerns.

  glazou: Question wrt "what is CSS3?", answer is "no such thing"
  glazou: What can we do on this front?

  Chris_Lilley: Related to publishing, there's an effort to share
                scripts, e.g. mathjax.
  Chris_Lilley: Another one is our testing status script, which
                annotates the headings with our test results
  Chris_Lilley: Right now, it's removed from our specs for /TR, but
                in the future will include in /TR publications.
  [discussion of bikeshed's inlining of stuff]
  Chris_Lilley: There will be centrally managed scripts that we can
                publish with.
  [discussion of systems logistics]

  glazou: The current-work page... is it automated?
  Bert: It's built off a .ini file that generates html
  fantasai: We can't automate that, because the status there is more
            granular than the W3C statuses
  dbaron: Can't we put that status in the spec?
  [discussion of automation]

  Florian: What should also be in the draft in machine-readable
           format is: what spec is this spec replacing?
  Florian: We have this in the Module Interactions section,
  Florian: We should mark this up.
  Chris_Lilley: The IETF got this right, they update when a spec has
                been obsoleted.
  TabAtkins: I have a standing bikeshed issue to do exactly that.
  glazou: I would like an action item to make this automated.
  glazou: May not be able to put it in the official headers...
  dbaron: We put pretty arbitrary things in the headers at this
          point.
  glazou: I will take an action item to gather all the data.

  glazou: Next issue, some documents on dev.w3.org have no advocate,
          and we'll need to annul them.
  fantasai: E.g. Tables.

  gregwhitworth: wrt the caniuse stuff, is there an index of some
                 kind in addition to the headers?
  ...
  Chris_Lilley: Want an index of all properties.
  fantasai: That's on TabAtkins's to-do list for bikeshed. Will be
            part of the Snapshot.
  [discussion of updating snapshot]

  glazou: If we update current-work automatically, do we still need
          the snapshot?
  fantasai: Snapshot has more context, prefixing policy, indexes,
            etc.
  glazou: I'm not so sure.
  Chris_Lilley: If there's an up-to-date index of properties, why
                would anyone look at the snapshot that's updated
                once a year?
  fantasai: That's the same problem of why should anyone ever look at
            specs on /TR

  Armen Nakashian (observer): I've had a lot of frustration with /TR
         and documents on the website,
  Armen: It's hard to tell what is up to date, am I looking at the
         right thing?.
  Armen: I tried from portal, can't find anything, end up googling
         and landing in something ancient.
  Armen: Find interesting context, but usually not quite the right
         thing,
  Armen: Often way out of date.
  Armen: Lots of professionals are looking documents, but nothing
         ages the document.
  Armen: Don't know if what you're proposing will help.
  Chris_Lilley: Some specs has red boxes as warning.
  Florian: We have this on specs that are known to be wrong.
  Florian: Don't have this on /TR drafts that haven't been published
           recently.
  * Chris_Lilley points out that Google link ranking works against
                 us, because older documents tend to have more
                 incoming links

  SteveZ: There's a standing request for IT to automate flagging
          out-of-date documents
  SteveZ: Overlay a watermark saying this document is out of date,
          click on link for up-to-date document
  Florian: Would that handle, e.g. multicol spec that has no newer
           spec?
  fantasai: We could add a JS script to the script library that does
            exactly that.
  * fantasai wonders if leaverou could write the JS script that puts
             an Out Of Date Look Here watermark on the old specs?
  * fantasai thinks it would look better if leaverou did it than
             anyone else here
  * fantasai :)
  <leaverou> sure!
  <leaverou> fantasai: thanks for the vote of confidence :P

  gregwhitworth: Is the stuff that we're discussing going to have a
                 JS API?
  Bert: There will be a JSON api for published specs.
  [discussion of who's working on that]

  [side discussions]

  Bo: For someone learning the process, it's very difficult
      experience trying to understand what these documents mean,
      what version, where they are...
  Bo: Why is it out of date? Where are we going? Who is the target
      audience here?
  glazou: I want a link to current-work on all pages.
  glazou: Last stable state, current version, next stage.
  glazou: We'll have to think about these extra bits of prose on
          status to the document.
  glazou: Once we have that, we can start to think about caniuse,
          etc.
  glazou: Need basic information about the spec first.
  Bo: Status, what is an editor's draft, what does it mean to me,
      etc.
  fantasai: There's a stalled project on redesigning the spec
            templates; it should help with that.

  SteveZ: The specs aren't really the best place for developers to
          start learning about something. Goal is interoperable
          implementations.
  TabAtkins: Good examples always help, help implementers too.
  johanneswilm: The idea of having spec for developer is to check
                if what he expects of behavior, if that's what the
                spec says.
  johanneswilm: If browser doesn't do that, then he can file a bug.
  Florian: Nobody should be learning CSS from scratch from the
           specs, but once you have the foundation, specs are
           sometimes the best place to learn about a new thing.
  TabAtkins: I get this same feedback from web developers as well.
             Not everybody, but some developers do that.
  SteveZ: Also over time; once I'm familiar with something, more
          likely to look to spec, cuz has all the details

  ACTION fantasai file an issue against TabAtkins for bikeshed to
         include CSSWG status codes
  <trackbot> Created ACTION-684

  ACTION leaverou write outdated-spec-watermark script for w3.org to
         put on /TR

  ACTION glazou Investigate which data needs to be added and how to
         automate current-work
  <trackbot> Created ACTION-685

  glazou: OK, so we will do these actions, and then go back to
          AC/plh and iterate
Received on Tuesday, 26 May 2015 23:17:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:31 UTC