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

Minutes Sapporo F2F 2015-10-26 Part I: Agenda, CSSOM, GCPM Bookmarks, CSS-Style-Attribute, Inline Character Grid [cssom] [css-gcpm] [css-style-attr]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 18 Nov 2015 20:38:01 -0500
Message-ID: <CADhPm3utfBeMMo6neFn5uCmPhUux+6qfUZvBkCZ4Qd=J_2y8Fw@mail.gmail.com>
To: www-style@w3.org
Agenda and Introductions
------------------------

  - This discussion to set the agenda held no technical details.

CSSOM
-----

  - The working group agreed that CSSOM has been neglected too long
      and needs publication.
  - zcorpan will go through the spec and trim out things that can be
      dropped because they have no implementations and then an
      updated working draft will be published.
      - Once this is completed, the working group chairs will devise
          a schedule whereby the working group does monthly reviews
          one section at a time until the entire spec is reviewed
          and has an adequate test suite.
      - The hope is this process will allow the spec to get to REC
          quickly.

GCPM Bookmarks
--------------

  - Florian brought a suggestion to create some kind of auto value
      for bookmark-level using HTML outline algorithm.
  - At the suggestion of the group, he's going to first try and
      replication the outline algorithm using Selectors.

CSS-Style-Attribute
-------------------

  - Bert will fix the error in the spec markup.

Inline Character Grid
---------------------

  - Although the CSSWG does not plan to tackle a full inline
    character grid system until the line grid system is done,
    Florian reintroduced the idea of constraing the line length
    to an integer number of characters (as a stepwise function).

  - It was felt that there needed to be a more concrete proposal,
    that addressed the issue of assigning remainder space to either
    the padding or margin area of the box, and that more examination
    of use cases would help decide what that should be.

  - fantasai pointed out that the current fit-content formula does
    not do quite what's wanted in the case of shrinkwrapped text,
    particularly for text-balanced content, and this issue may also
    affect character-grid-aligned content.

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

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

Present:
  Rossen Atanassov
  Tab Atkins
  Takao Baba
  David Baron
  Brian Birtles
  Bert Bos
  Junichi Chiba
  Dave Cramer
  John Daggett
  Daniel Glazman
  Dongwoo Joshua Im
  Koji Ishii
  Dean Jackson
  Peter Linss
  Myles Maxfield
  Shinyu Murakami
  Simon Pieters
  Xidorn Quan
  Liam Quin
  Matt Rakow
  Florian Rivoal
  Andrey Rybka
  Hiroshi Sakakibara
  Simon Sapin
  Alan Stearns
  Shane Stephens
  Johannes Wilm

Regrets:
  Adenilson Cavalcanti
  Dael Jackson

Scribe: TabAtkins

Agenda and Introductions
------------------------

  - This discussion to set the agenda held no technical details.

CSSOM
-----

  glazou: I think the CSSOM is a basis for a lot of the stuff in the
          working group.
  glazou: We're adding OM to more and more modules.
  glazou: I think it's the foundation of too much to leave unattended.
  glazou: In particular, we need to have it improved and possibly
          reimplemented for Houdini.
  glazou: I'd like us to be more active on that front.
  glazou: Fortunately I have some free time now to do so. ^_^
  glazou: I think we should set a deadline for that spec, and be
          firm on the fact that, at that day in the future, we
          should have a PR for the basic OM for CSS.
  glazou: The work on OM started long ago, and it's now a too-old
          effort in this WG, but we rely on it.

  dino: What do you mean by "the OM"? We talked about typed access
        and other modern bits. What exactly?
  glazou: For me, the OM is the revamp of what we had in the DOM 2
          Style spec.
  glazou: Cleaner, better, simpler, with no extensions. The
          foundation should be cleaner.
  glazou: Some interfaces, ones not implemented, need to be removed.
  fantasai: The CSS2.1 of the CSSOM
  glazou: Others are not interoperable, and having a REC would help
          stabilizing things.
  glazou: With a good foundation, we can improve the OM.
  glazou: Without that we're designing new APIs without a foundation.
  glazou: It's going to be a problem sooner or later.
  dino: So you're suggesting codifying what exists...?
  glazou: Taking what Simon has been doing, push that document to
          REC ASAP.

  Florian: Re: deadline, I think it's helpful to avoid pushing it
           forever, but it's only meaningful if implementors are
           pushing. It needs to be both.
  Florian: You need an editor driving, and also the WG responding.
           You have to have both, not only one.
  glazou: I agree. But without spec work, nothing will happen.

  glazou: We're at a crossroads, and this foundation document is too
          old, but we really need it.
  glazou: What we have to show is the CSS2.0 OM, which isn't
          interoperably implemented, and sometimes not at all.
  zcorpan: What's also necessary is a test suite, and people working
           on fixing bugs in browsers.
  glazou: So vendors, are you willing to help? Contribute tests,
          fixing holes, etc?
  dino: We'd love to help implementation wise. Spec-wise, not so much.
  fantasai: Can you help with testing?
  dino: Yes, testing is important to us and we'd contribute to a
        test suite.
  <gsnedders> I know Servo has interest in tests for this.
  <gsnedders> But they don't have that much in way of resources.

  Florian: I think if the champions of each topic bring it to
           discussion, I think there's a good understanding that it
           needs to move forward.

  shane: Is it possible, at this stage, for the implementors to
         become interoperable?
  shane: There's some deep differences.
  Florian: I think trying to identify where we can join, and where
           we can't, is valuable.
  SimonSapin: Servo is starting to implement as well, and we can
              bring up issues we find and write tests.

  <dbaron> Isn't one of the really important pieces having a new
           values OM, which isn't spec'd yet?

  fantasai: What's the scope currently? New stuff?
  zcorpan: Some new stuff. Some of it's implemented, like
           CSS.escape().
  zcorpan: But in general it's just old stuff.
  zcorpan: If anything needs to be cut, it's fine.
  fantasai: It might be worth going through the spec and seeing what
            of the old stuff isn't implemented and needs to be
            dropped.
  zcorpan: One thing is alternate style sheets. In Gecko, but I
           don't think anywhere else. Maybe Microsoft?
  fantasai: We can push things that aren't implemented or not
            interoperable into a level 2 different spec, just to
            keep their text around. Then level 1 can just be things
            with at least 2 implementations. If there are not two
            implementations, the web probably doesn't depend on it.

  glazou: The last WD is from 2013. I'd like to publish a new one
          ASAP, request feedback from community, vendors, etc, and
          start writing tests.
  Rossen: How much has changed since 2013?
  zcorpan: Not much.
  Rossen: From Daniel's point of view, your proposal is to make a
          spec we can publish ASAP with the interoperable core of
          the OM.
  Rossen: It should be relatively straightforward with enough test
          coverage.
  Rossen: Simon, between you and Glenn, do you need any help with
          editing?
  zcorpan: Glenn hasn't done much since I started editing. OM hasn't
           been a priority for me the last 2 years, but I can
           definitely get back to it, particularly if there's
           implementor interest in fixing bugs.
  Rossen: I think implementors like to fix bugs as long as they're
          not major architectural redesigns.
  zcorpan: The problem with bugs is that there's always a risk of
           breaking websites.
  zcorpan: And there's little benefit in fixing from browser point
           of view, because the web already works.
  Florian: From point of view of Servo, etc, it's really valuable.
           Can have official behavior, with optional compat
           exceptions specified, and Servo can test to see what's
           necessary.

  glazou: Documentation on the core OM almost doesn't exist.
          Basically there's nothing.
  Florian: How can we engage with jQuery/etc? They probably know the
           differences.
  glazou: jQuery foundation is in the WG.
  Florian: They probably already have tests. Maybe in the wrong
           shape, but...
  shane: Going back a moment, Blink is willing to contribute tests
         to help.
  <gsnedders> There's some CSSOM tests in the presto-testo dump. I
              don't know how useful/relevant they are.

  fantasai: So Simon is going to try and trim the spec, republish,
            request review, get jQuery to send up incompat reports.
  fantasai: And go through the spec every month with "the WG reviews
            this section". It's a big spec, but with "this month is
            MQ OM", etc it's easier.
  TabAtkins: Like our 2.1 process.
  fantasai: 2.1 was a bit scattershot. We had tons of issues; didn't
            have to go looking for them.

  Rossen: So for timeline, Simon, do you think you have time to work
          on this?
  zcorpan: Yeah, certainly. Target 1 year from now to have something
           close to ready...
  fantasai: It's 11 or 12 major sections, so one a month...
  Rossen: Let's start by IDing the core of the spec.
  glazou: The end of our current charter is June 2016.
  glazou: It would be good to have an idea of the status of this
          spec by that time.
  Rossen: Is there part of the spec we can REC today?
  fantasai: Main issue is not the spec, but if we have test suite.
  zcorpan: I'm not confident there's such a section - not enough
           test coverage for any one section.
  zcorpan: But some parts are more interoperable than others.
  fantasai: Also if we're going through the spec from the WG, we
            also need QA people from the browsers converting or
            writing tests.
  fantasai: So not just people in this group, people from testing too.
  Rossen: So I guess Simon needs to refocus, and start bringing up
          issues that need discussion.
  Rossen: If we're targeting end of next year, or end of charter...
  Rossen: We'll see how it goes from there.
  * fantasai thinks TPAC next year is a reasonable optimistic
             estimate, June seems unrealistic :)

  shane: Does Simon want to guide browsers in what to test, or
         should we be bringing up areas ourselves?
  Rossen: Either is fine. If we ID part of the spec that's most
          interoperable, we can start from there.
  fantasai: We can do both.
  Rossen: I agree that we've been neglecting this for some time.
  glazou: I can help.
  zcorpan: I don't mind more editors.

  Florian: How do we coordinate between this and new Houdini stuff?
  Florian: New things that live alongside can stay, but maybe
           replacements mean we can just drop the old stuff?
  fantasai: This will be the spec of things we can't drop.
  shane: I don't think there is much replacement. The big thing in
         Houdini is the typed OM, for performance reasons. It
         doesn't drop the other OM.

  Rossen: Daniel, do you want to be co-editor?
  glazou: Not yet. I need to ramp up. Perhaps later.

  fantasai: So Action Items: 1. Simon goes through the spec, maybe
            with help, and trim things we can drop. Then publish WD.
  fantasai: 2. WG reviews and submits tests.
  fantasai: 3. Chairs drive a schedule where we do monthly section
            reviews.
  Rossen: I'll contact Glenn and see what his commitment is.

  koji: When you say OM, does that include CSSOM View?
  zcorpan: No.
  glazou: It's a separate topic.

GCPM Bookmarks
--------------

  <astearns> https://drafts.csswg.org/css-gcpm/#bookmarks
  Florian: I don't know if people remember GCPM bookmarks
  Florian: It is a set of 3 properties that let you do PDF-style
           bookmarks.
  Florian: Bookmark-label, defaults to content. Bookmark-state,
           which is open or closed. And bookmark-level.
  Florian: First, it's slightly weird in CSS. It doesn't really
           affect the document's style.
  Florian: But then there are many ways to render the doc; you can
           render to PDF, and have a bookmark pane.
  Florian: This relies on the cascade/etc., so it's a slightly weird
           fit. Would be better with cascading attribute sheets, but
           we don't.
  Florian: [lists places where this is implemented or intent to
           implement]

  Florian: But I was wondering about bookmark-level. Can we add an
           "auto" level, to work with the HTML algorithm, rather
           than setting up selectors manually?
  Florian: If you, for example, use nesting+h1, it's a little
           difficult. The HTML outline algorithm defines the heading
           level there.
  Florian: But there's nothing there right now. It's just none or
           manual.
  fantasai: Can we do this through the UA stylesheet?
  Florian: Maybe. If you use h1-6 it's easy. But with h1+nesting,
           it's a little more complex. With nesting+mixtures of
           heading numbers, much harder.
  Florian: HTML outline algorithm defines how all that works,
           combining nesting and numbering. That's very difficult or
           impossible to do through selectors.
  fantasai: I think you can do this with selectors, it'll just be a
            lot of selectors
  Florian: [example of combining nesting and numbering]

  zcorpan: The outline algorithm in HTML is not implemented. The
           a11y techs that are supposed to benefit from it don't use
           it, they just expose h1-6 etc.
  zcorpan: It seems premature to create selectors for it.
  TabAtkins: This isn't for Selectors, it's just about bookmark-level.
  Florian: We could make a bunch of selectors in the UA stylesheet,
           maybe, but it's troublesome.
  Florian: And it's HTML-specific. I'd prefer one that depends on
           the document language.

  liam: When we added this to XSL:FO, we had to allow for e.g.
        tables and figures to appear in different levels of the ToC,
        some tables appearing others not, etc.
  liam: I support the idea that there's a use-case for explicitly
        marking things for PDF bookmarks.
  Florian: I'm not suggesting getting rid of explicit levels.
           Definitely reasons to set it manually.
  Florian: But there seems to be a large set of documents that you
           shouldn't need to do this for - you can just get it from
           the structure.
  Florian: Just wanting to *add* an "auto" value.
  dauwhe: I'd be happier with examples of documents where you can't
          achieve the desired effect with the existing property.
  Florian: I think for any individual document you can do it
           manually. But there's a lot of information that's present.
  dauwhe: I'd like to see if we can do it via selectors.
  TabAtkins: It's very messy.
  fantasai: I prefer the UA stylesheet. We can tweak it later as we
            find problems much more easily. A UA can implement it
            with non-CSS code (e.g. C++) if they want to. And this
            is the easiest way to implement - just copy/paste.
  fantasai: And authors can easily tweak.
  * Bert implemented the HTML headings algorithm, in a published
         product… (Not tested very much, though)

  Florian: I was wondering if we would need to use cascading
           properties to do additive math as we go down the tree.
  fantasai: I suggest just trying to do it, first.
  dauwhe: I'm happier with a UA stylesheet first, too.
  dauwhe: And easier to debug, if a customer doesn't understand why
          something has a weird level. I could just see the rule
          applying it.
  Rossen: Agree. If we can do without magic, good.
  Florian: Okay, I can try.
  dauwhe: Also, given how picky people are, I'm not sure an "auto"
          keyword can actually satisfy enough people.

  <zcorpan> https://html.spec.whatwg.org/multipage/rendering.html#sections-and-headings
            is HTML's UA stylesheet for sections and headings

  ACTION Florian to try and implement some approximation of the
         outline algorithm using Selectors, for bookmark-level.
  <trackbot> Created ACTION-726

  dauwhe: This material officially lives in Generated Content, not
          in GCPM.
  Rossen: Go ahead and remove it from GCPM.

  johanneswilm: Are people other than the publishing programs even
                thinking of bookmarks?

  <Bert> -> https://drafts.csswg.org/css-content-3/#css-bookmarks
         Bookmarks (for PDF)
  <SimonSapin> dauwhe, https://drafts.csswg.org/ lists "Generated
               Content" which links to GCPM. Is there another
               Generated content?

CSS-Style-Attribute
-------------------

  <astearns> http://www.w3.org/mid/737F97AF-69E2-41DD-A047-E71012B81B71@rivoal.net
  Florian: There's a bug in the spec's markup, and confuses Bikeshed.
  Florian: There was an action, but nothing happened.
  fantasai: If it's just a markup fix, Bert can do it inline.
  Bert: As long as it's just a markup fix, yeah.
  Florian: Yeah, "style attribute" was just <dfn>'d twice. I removed
           the tag from one.

Inline Character Grid
---------------------

  Florian: This was brought up last night.
  Florian: Line Grid has a strict arrangement of lines.
  Florian: In CJK, they do similarly with characters in the inline
           dimension.
  Florian: This is probably not something to tackle right now
           (though I'd be happy to think about it), but there's some
           small steps we can take now.
  Florian: If the line length is a multiple of the CJK character
           width, then justifying works. Fine for pure CJK, and
           works right when mixing in Latin.
  Florian: So I suggest being able to define some max-width thing
           that goes up as a step function of the CJK size.

  fantasai: There's two places you might need to put space - padding
            or margin.
  fantasai: I agree that it should be solved, but I don't have a
            concrete proposal that would address the concern.

  Florian: I have two questions, and maybe answers.
  Florian: Does the extra space go to padding or margin?
  TabAtkins: Can't box-sizing do this?
  fantasai: Don't think so - you're always sizing the content box.
  fantasai: If you have a max-width of 90px, and available space
            100px, the 10px will go outside (margin). But we might
            want it to be inside (padding).
  fantasai: And if there's space, how to align the content? We have
            the alignment properties to handle that.
  fantasai: So as we limit the length of the line, are we leaving
            the padding in place, or are we pulling the border-box
            in with us?
  fantasai: I think just working with max-width works.
  fantasai: Just do it as a step increment.
  fantasai: Imagine you're in a box, and want the background color
            to fill the box. Padding to give you some space.
  fantasai: If you pull in the border-edge to satisfy a max-width,
            you have a gap you weren't expecting.

  Florian: So look at use-cases, I guess.
  Florian: So does this look like a property, or as a value?
  TabAtkins: Look at use-cases. ^_^
  jdaggett: I think you need to be more specific. And I have some
            concerns that this might be hacky, but I can't say that
            firmly until I see something.
  <fantasai> I'd talk to some CJK CSS authors.

  Hiroshi: If we want to discuss character grid, do we need a draft
           spec for it?
  Hiroshi: Is it good for this group?
  fantasai: The actual Character Grid, we're not tackling yet. Line
            Grid first.
  fantasai: This is a smaller issue of measurement - just making
            sure the context box is an integer number of characters
            wide.
  fantasai: Easier topic.
  fantasai: [reiterating the discussion]

  Florian: So based on that, I think getting the CJK community to
           look for examples, and find where the space wants to go.
  Florian: If everyone wants the same thing, then it's easy. If
           different, we need a switch.
  fantasai: I say don't look at "documents", but at magazines and
            websites, and think about them as the page changes size.
  Rossen: I'm assuming you already have test-cases.
  Hiroshi: Yes, can help gather and send to the group.

  scribe: fantasai

  TabAtkins: There has been discussion before about min() max()
             functions or floor() ceiling() functions.
  TabAtkins: They were rejected in past because can reverse layout
             constraints.
  TabAtkins: You no longer have a linear function for the size, it's
             piecewise linear.
  TabAtkins: That's much harder to handle in sizing algorithms.
  TabAtkins: dbaron can elaborate more.
  Florian: One way to deal with that would be to limit just the line
           length.
  Florian: Whether or not that addresses use cases ...

  scribe: TabAtkins

  fantasai: Related issue is shrink-wrapping.
  fantasai: When you shrink-wrap, we follow the formula of
            max(min-content, min(max-content, available space))
  fantasai: If you're doing line-breaking, that can get you to a
            position where you have a lot of extra space in your
            element that doesn't need to be there, because you
            wrapped. (Some big items get wrapped, leave a big gap at
            the end of the line.)
  fantasai: This happens a lot with text-wrap: balance.
  fantasai: [draws diagram]
  fantasai: Four large words in the element. max-content slightly
            overflows.
  fantasai: Shrink-wrap is two-lines tall. Three items on one line,
            one item on next.
  fantasai: For "balance", you want two items on each line, and
            shrink-wrapped to the width of that.
  fantasai: What you get instead is still width of available space,
            with tons of empty space.
  Florian: Does this mean the shrink-wrap formula needs to be
           enhanced?
  fantasai: It used to be, in distant past, but for performance
            reasons we moved to this simpler one.
  fantasai: But we will need some way to opt into this later.
  astearns: For example, a background behind a "balanced" box that's
            sized to the line length, not the full available space.

  astearns: In the last publication of Line Grid, I stripped it to
            what I think is the minimum necessary step.
  astearns: The Line Grid and Line Snapping are ready to implement.
            Box snapping might still need spec work.
  astearns: So, vendors, take a look and I think it's mostly ready.
  Florian: What did you remove?
  astearns: Character grid, and some things that dealt with the
            issue you brought up.
  Rossen: So action the group to have implementors review.
  fantasai: I think it needs more work, but getting implementor eyes
            on it would be useful.
  Rossen: Agreed. Table discussion yesterday concluded that even
          something simple, where lines are a multiple of some size,
          would be sufficient.

  [discussion of various things that make line-height not sufficient
      to do simple line grid]

  <br duration=15m type=coffee>
Received on Thursday, 19 November 2015 01:39:04 UTC

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