- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 26 May 2015 19:17:22 -0400
- 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