W3C home > Mailing lists > Public > public-houdini@w3.org > October 2015

Minutes Paris F2F 2015-08-25 Part V: DeadRange, Building Blocks for Pagination, Spec Management, Issue Tracking on the Mailing List vs GitHub

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 16 Oct 2015 19:39:09 -0400
Message-ID: <CADhPm3sJ_WNtW_KxazOFMXrwky3MdbUymYAV2iDXPsgYXLUCEg@mail.gmail.com>
To: public-houdini@w3.org

  - There was clarification between where it says DOMRange in the
      lineboxing spec and what is informally being called DeadRange-
      a non-live range. The lineboxing discussion was referring to

Building Blocks for Pagination

  - The representatives from publishers let the group know that they
      were hoping that pagination and finding where a linebreak
      would be given a piece of text would both be addressed by
  - The group expressed a belief that these were both important use
      cases and should be addressable early in the Houdini work.

Spec Management

  - No one objected to moving the wiki to GitHub as long as
      everything is in the same place and there is some control over
      keeping the planning pages either private or restricted in
      some way to keep out spammers.

Issue Tracking on the Mailing List vs GitHub

  - RESOLVED: All Houdini discussion by default takes place on
              GitHub issues. We mail to the public mailing list when
              we have good reason to request the whole group to look
              at something. We set up an issues mailing list that
              gets the start of each issue. We explore more robots
              for better notifications.
  - There were positives and negatives to both keeping all the specs
      in one repo or splitting them so each has their own repo. For
      now, the specs will be in one repo hopefully served by bots to
      label issues appropriately. If that gets too frustrating, the
      specs will each get their own repo.


  scribe: TabAtkins


  ChrisL: In the previous discussion, there was a mention of "need a
          range here". How's that used?
  ojan: It's half-baked. You say what range you want...
  ChrisL: Oh so you don't declare ranges yourself, you set up the
          linebox and it tells you what range fits in there?
  ojan: Maybe. Half-baked.

  ChrisL: There was a description of a lighter-weight thing--
  esprehn: The range in this has nothing to do with DOMRange. This
           is in a separate scripting context, and this range is a
           disjointed concept, unrelated.
  esprehn: The spec says "DOMRange", it's just wrong.
  ChrisL: Ah, ok.

  ChrisL: People didn't like DOMRange.
  ChrisL: We informally called the new thing "DeadRange", because
          it's not live.
  ChrisL: I want more clarity in how people saw DeadRanges being

  esprehn: In our example, the measurement API returns metrics about
           spans. The breaking API returns boundaries.
  esprehn: So if you wanted the size of the first letter, you'd set
           up a DeadRange and ask about it. Don't think that's
           described in this document.
  ChrisL: There's some complications with, for example, bidi. We
          don't want to have to iterate by chars to know font -
          prefer larger "block" structure in the line.
  jdaggett: That's what implementations typically do.
  jdaggett: You end up with a single-font span.

  ChrisL: So when that font matching happens, can it change the
  jdaggett: In general no. There's some complication with variation
            selectors, but it's not that important.
  esprehn: I don't think we go backwards, either.
  esprehn: In this API, for first letter, you'd explicitly break off
           the first letter before calling the breaking API.
  ChrisL: So the segmentation isn't done automatically there.
  esprehn: Correct, you'd insert breaking points.

  ChrisL: So is there an idea for how to control that?
  esprehn: Don't think there's anything that describes it yet. I'm
           interested in fleshing it out with interested parties.
  jdaggett: If you really want to expose per-glyph info, it
            shouldn't be done at a higher level. You should get
            primitives for the character runs.
  ChrisL: Yeah, I wanted per-font level, but the per-glyph is
          secondary out of that.
  jdaggett: What you need for line-breaking is the advance info,
            which is there in the font level.
  ChrisL: Yeah, and Bruce was talking about balanced fit text.
  jdaggett: That requires an API that lets you take an arbitrary set
            of glyphs spans, and put them into a linebox.
  ChrisL: Right.
  ChrisL: I think the major confusion was that it had nothing to do
          with DOMRange.

Building Blocks for Pagination

  dauwhe: As I mentioned earlier in CSS, the publishing community
          has hopes that if browser aren't natively implementing
          pagination, that they'd at least have hooks to let the
          publishers implement it themselves.
  dauwhe: This is a big major use-case for them.
  dauwhe: And getting fragment information (look at an element,
          determine what fragment it's in) is also important, for
          page numbers, indexes, etc.
  dauwhe: That's all.
  johanneswilm: As someone who's implemented that stuff in
                JavaScript, the most important info is "if I have
                text, where will the linebreak happen?". If I have
                that in a way that I don't have to draw it and
                measure it and take it back out again, that will
                help a lot.
  johanneswilm: Both line breaks and the height of the lines - hacks
                today use multicol to separate things into a "one
                page" chunk, then manually breaks it in the DOM at
                that point.
  johanneswilm: Not cheap.
  TabAtkins: I think both of those are the version 1 features we're
             hoping to expose.

  bkardell: I dunno how Apple does this, but since we talked about
            building blocks of pagination...
  <bkardell> https://elements.polymer-project.org/elements/iron-pages
  bkardell: I'm wondering where that falls in fragmenting visible
            bits that are page-like.
  bkardell: For example, Polymer has concept of "pages", for making
            tabs or such.
  bkardell: The "page", then different subviews.
  bkardell: Would our building blocks satisfy that?
  Rossen: I'm hoping that if we expose enough in the box tree, in
          terms of boxes and fragment breaks, we'll never have to
          talk about pagination again.
  Rossen: It's the application developers who'll deal with it.
  Rossen: These are strong words, and we're far from it, but in a
          world where we have a box tree, and each box has a
          fragment break which is self descriptive, with custom
          layout you'll figure out how the fragment will continue to
          the next fragmentainer.
  Rossen: To further your point about "don't forget about the
          foundation", the underlying statement is "don't forget to
          add fragment breaks everywhere", and let the application
          deal with it.
  Florian: Having these in combination with the "ground" element
          (top-level) lets the browser deal with it too.

  SteveZ: What Rossen said.
  SteveZ: One other piece - the keeping of flows and positions in
          them, which is a piece of the fragment, is very important.
          More than just boxes, it's measuring where you are in
          streams of content.
  Rossen: Right, every fragment is self-descriptive. It's in some
          fragmentainer, has a position and size, and a reference to
          what follows next.
  Rossen: You decide what happens to the next fragment.
  Rossen: If I decide to switch to page 400 of War and Peace, I
          don't need to display the previous 399 pages.
  Rossen: And Regions is basically boxes with fragment breaks.
  Rossen: When you're able to create fragments yourself, you don't
          need them.
  johanneswilm: [asks about where in the presented spec these were]
  TabAtkins: It's not in the spec yet, we just talked about them;
             it's too early now.

Spec Management
  scribe: dael

  Rossen: Let's start with which wiki.
  shane: We can continue to use the wiki on the csshoudini.org which
         until recently was member only for writing, though anyone
         could read. The other option is to move to the wiki onto
         GitHub. I kind of prefer that. The specs are there and
         we're lodging issues there. The only thing not there would
         be meeting planning. So I wanted to suggest we open the
         wiki on GitHub.
  plinss: We opened the current wiki recently to everyone. We can
          set the access to any level we want to. Personally I think
          there's value to owning our own data.

  TabAtkins: Only argument I have for GitHub is better wiki syntax.
  ojan: We have the concrete thing of people not being able to
        figure out how to add to the wiki, but they know GitHub.
  Rossen: As long as meeting planning is private.

  ChrisL: What I would like is not to have things spread all over so
          that I have to spend a lot of time looking for things.
          Wikis are bad for that because they're bad for finding
          changes. But as long as it's all in the same place it's
          fine. As long as it doesn't include people spamming and
          the like.
  shane: Our issues list is on GitHub and we can link directly to
  tantek: It sounds like you're saying as long as someone keeps the
          sidewalks clean you're okay with anywhere on the web.
  ChrisL: I've seen a bunch of wikis that were well maintained and
          then had to close down for the spam. But as long as it
          works I don't care and being able to auto link is good.

  Florian: Should we ever change our mind we can export out?
  SimonSapin: Yes.

  Rossen: To be clear we are keeping the wiki for meeting planning.
  plinss: I'm sort of opposed to that. I don't want to have n wikis.
          I don't care where it is, but I just want one.
  TabAtkins: What's the reason for putting it on a wiki? It's
             publicly viewable.
  Florian: Security by obscurity.

  Rossen: The proposal is if we find a way to restrict the planning
          section to members only, can we move to GitHub wiki?
  TabAtkins: I don't understand what's wrong with the public having
             editing power. Anyone outside the group editing the
             planning page is a spammer and we treat it that way.

  plinss: So you need to action someone to move the data from the
  shane: plinss you need to unlock the wiki.
  plinss: And you'll move the wiki over?
  shane: Yeah.
  plinss: The only access control is people with push access.
          There's no fine grained control over the wiki.
  TabAtkins: Worst case we create a separate repo for Houdini

  SimonSapin: Where are we doing issue tracking?
  Rossen: Next topic.

  bkardell: If you type in the main domain you redirect to wiki, etc.
            If we're doing the wiki can we use a central page and do
            a nicer what this is?
  TabAtkins: Sounds like you want to design it.
  bkardell: Nope.

  dauwhe: The messaging about the project is important.
  gregwhitworth: shane and I had talked about writing language for
                 the project.
  Rossen: There's an action for us to write the roadmap and the wiki
          would be the best place to do it.

Issue Tracking on the Mailing List vs GitHub

  Florian: In the CSS WG which has a longer history, everything goes
           through the mailing list. This is the only place to
           discuss things. An alternative approach is they all must
           be in GitHub issues and gets forwarded to the ML and you
           don't discuss in the ML.
  Florian: So are we in a GitHub centric or a mailing list centric
           world? If you can get your GitHub issues via e-mail and
           reply to the e-mail, you can close things when they're
           done and you can find the things that aren't closed yet.
           This is also useful in long discussions.
  TabAtkins: It also prevent thread breaking.
  johanneswilm: One thing related that I saw in CSS working group
                e-mail solution vs GitHub, if things are old in the
                mailing list that thing may be lost and you have to
                go through the mail archive. But on GitHub it's easy
                to see what's open.
  Florian: In the e-mail load there are ways around that. You can
           download the archive which is something I did recently
           for CSS UI. It's not pleasant.

  ojan: You said you'd be opposed to just on GitHub? Is that because
        everyone needs to see every issue or you want to?
  Florian: I want to see everything and I want offline capability.
  ojan: You can subscribe to notifications for the whole repo. We
        don't have to mandate they go to the list.
  TabAtkins: The reason why using the mailing list is halfway when
             you set notifications or you get e-mails on every
  SimonSapin: If you watch the repo you get everything.
  astearns: Is there a way to get the archive?
  plinss: No.
  astearns: That's why it should all go to the mailing list.
  TabAtkins: Thread starts seems more useful.

  dbaron: The other possibility is if you have a second mailing list.
          The more general comment, everything goes to www-style and
          that makes it hard to manage reading it. When trying to
          deal with editing transitions I have to show I replied and
          I'm dumping crap in.
  ojan: That's why I was putting it in there. This whole publish
        HTML falls into a point where people are ignoring them. I
        was supportive of the www-style concept, but it's not
        working in practice.
  TabAtkins: That's why the solution of just send notifications of a
             new thread works.
  dbaron: There are issues I sent to www-style where that's a waste
          because only me and the editor care.
  ojan: If you care about that you can set that up on the GitHub and
        people can subscribe to the mailing list.

  Florian: The existing mailing list, what do we do with it?
  ojan: There are discussions you want a mailing list for.
  dbaron: There are issues you want the whole group to be aware of.
          It's worth raising those to the mailing list to say these
          are things you want to pay attention to. We can use that
          when we think it is important.
  gregwhitworth: And you only get the notifications for the things
                 you're editing.
  SimonSapin: Question on what you said. In that case where you want
              to see something, do you post it on GitHub issues and
              you post it to the mailing list or do you just on
  dbaron: Depends on what you want to do. If you say hey I made this
          massive change or something needs to be discussed.
  TabAtkins: We can set up a GitHub bot that sets up a tag and auto
             forwards to the mailing list.
  dbaron: That has the danger of not enough context. We might want a
          notification as to why.
  TabAtkins: We play with the simplest. Everything on GitHub issues
             and you e-mail the list if you want.

  Florian: We then have an additional mailing list that gets
           everything on GitHub for accessibility and usability?
  TabAtkins: I'm happy to make a public Houdini issues mailing list.
  Florian: I'm worried if you just do GitHub by default, when you're
           new you can't start be getting a sense of everything and
           filter. When you subscribe to www-style you notice things.
  TabAtkins: It's a matter of on-boarding a new member appropriately
             and making sure information is easily and widely
  dauwhe: The firehose is not the optimal on-boarding.
  Florian: It was for me, but I'll admit I'm odd

  TabAtkins: So CSS Houdini strategy is you open and discuss issues
             on GitHub. If you need something to have wide notice
             you send an e-mail and we set up a mailing list with
             the thread.
  franremy: Maybe we have something that says what threads are
            getting more attention?
  TabAtkins: If there are robots, let's do that.
  Florian: Also this is a good experiment for the CSS WG.
  Florian: So if we move to that model I can set up GitHub to mail
           me about everything?
  TabAtkins: Yes.
  TabAtkins: You can subscribe to the whole thing.
  TabAtkins: All Houdini discussion by default takes place on GitHub
             issues. We mail to the public ML when we have good
             reason to request the whole group to look at something.
             We set up an issues mailing list that gets the start of
             each issue. We explore more robots for better
  dbaron: Using it with a single repo means I get all the

  Bert: Can you open issues by e-mail?
  TabAtkins: I'm pretty sure you can.
  Bert: Okay.
  Bert: I want to know what I sent and my e-mail client is very good
        at remembering what I did.
  Rossen: Object?
  SimonSapin: GitHub doesn't support that.
  TabAtkins: We can set up a bot.
  Rossen: Any objections?

  RESOLVED: All Houdini discussion by default takes place on GitHub
            issues. We mail to the public mailing list when we have
            good reason to request the whole group to look at
            something. We set up an issues mailing list that gets
            the start of each issue. We explore more robots for
            better notifications.

  TabAtkins: So, one repo for Houdini instead of one per spec?
  TabAtkins: I understand the arguments for one per spec. It means
             you can watch what you want to, but you can't firehose.
             And it's clumsier if you try and do wide editing.
  gregwhitworth: You can do a W3C team and you're auto-subscribed.
                 If you're an editor you would automatically sign-up
                 for those.
  hober: We're a part of the W3C org.
  TabAtkins: But we don't want every W3C spec. But the functionality
             is there.
  shane: We can make a team.
  <dbaron> I find splitting the repo for issue tracking somewhat
           sad, since I think a single repo is better from a VCS
           perspective, but GitHub's issue tracking really
           encourages smaller repos.

  Florian: If we do this, setting up a new spec, how do you sync
           that to the server that serves the rendered spec?
  TabAtkins: There are various ways. There's nice command line tools.
             It's as easy as a git.init.
  Florian: I mean, the server where you read the spec.
  Florian: It can't just do ls in the repo. It needs to query GitHub
           about new repos.
  TabAtkins: We can bot it or those steps are infrequent and not
             hard to document.
  plinss: It's work on my end. That server only serves a single repo
          so I would need to change that to aggregate multiple repos.
  plinss: It's going to be work to set that up. I guess it's in the
          GitHub API, but I don't know how it will tell a Houdini
          repos. We're also operating under the W3C org.
  <franremy> (If each spec has its own repo, how do we work on
             issues that may concern more than one spec? Do we
             create duplicates and ask discussion to happen on only
             one of them?)

  SimonSapin: W3C has a few hundred repos. Is it useful to have a
              smaller organization?
  plinss: In the TAG we have our own.
  TabAtkins: And it would mean we have a useful front page for it.

  plinss: So we'll have to move everything over. We'll want to make
          sure we don't break.
  TabAtkins: No one should do direct GitHub links.
  Florian: Another down side is we do move text from one spec to
           another. That would be lost if we do separate repos.
           Personally the down sides are higher.
  TabAtkins: But we have easier history to walk through for each
             individual spec. Well, through the GitHub API it's find.
  TabAtkins: We'll lose some history. I don't consider it a huge
  dbaron: I'm okay with trying to keep one big repo. It's better
          from VCS. Issue tracking encourages multiple repos.
  shane: The issue tracking we can label each issue and that lets
         you filter. That does mean, as SimonSapin said, it makes it
         easier to have an issue across multiple specs.

  SimonSapin: One problem is only organization members can set the
              issue labels.
  Florian: It means random people filling issues aren't tagging.
  TabAtkins: Or the bot has to turn subject lines into labels.
  SimonSapin: But multiple repos we get that for free.
  dbaron: A bot could pull the url out and flag it.
  TabAtkins: Lets stick with one repo for now and if it's annoying
             we can split.
  shane: I think a lot of external issues will be I want to do x or
  SimonSapin: The rust project has a lot of bots.
  plinss: He has example bots.
  plinss: I have a bot on my server.

  plinss: I created the CSS Houdini team, but I don't have a list of
          everyone's GitHub ID.
  SimonSapin: So have we decided on one repo?
  Florian: Yes, one.

  Rossen: Adjourned for the day.
Received on Friday, 16 October 2015 23:40:08 UTC

This archive was generated by hypermail 2.3.1 : Friday, 16 October 2015 23:40:09 UTC