- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 18 Nov 2015 20:38:01 -0500
- 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