- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 16 Oct 2015 19:39:09 -0400
- To: public-houdini@w3.org
DeadRange
---------
- 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
DeadRange.
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
Houdini.
- 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.
===== FULL MINUTES BELOW ======
scribe: TabAtkins
DeadRange
---------
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
produced.
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
segmentation?
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
issues.
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
wiki.
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
planning.
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
message.
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
GitHub?
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
displayed.
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
notifications.
dbaron: Using it with a single repo means I get all the
notifications.
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
deal.
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
y.
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