- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 7 Jun 2017 08:20:29 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Specs to Rec
------------
- ChrisL will review the pending changes from gregwhitworth to
Variables.
- RESOLVED: Add gsnedders as editor to CSS2.2
Does inlinification really need recursion?
------------------------------------------
- RESOLVED: Blocks are turned into inline-blocks.
Blockification doesn't seem backwards-compatible for inline-blocks
------------------------------------------------------------------
- RESOLVED: We are provisionally going with option b (inline-block
-> block; inline flow-root -> flow-root).
- TabAtkins will open a new issue to decide if you maintain
separate computed values for just this one case or the whole
possible space of values. Depending on that discussion the
previous resolution may need to be revisited.
Propagation of text-decoration with display:contents
----------------------------------------------------
- RESOLVED: Define this as a box-tree concept.
Should anonymous boxes always inherit through the box tree?
-----------------------------------------------------------
- RESOLVED: Let's try it out, go forward with the diff
(https://github.com/w3c/csswg-drafts/issues/1118#issuecomment-301942276)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017May/0059.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Tantek Çelik
Dave Cramer
Benjamin De Cock
Elika Etemad
Tony Graham
Brad Kemper
Chris Lilley
Myles Maxfield
Anton Prowse
Liam Quin
Melanie Richards
Jen Simmons
Geoffrey Sneddon
Alan Stearns
Lea Verou
Greg Whitworth (IRC only)
Regrets:
Bert Bos
Daniel Glazman
Vlad Levantovsky
Peter Linss
Florian Rivoal
Scribe: tantek
astearns: Next week we are trying a AUS friendly time for telcon -
7 hours forward
astearns: 16:00 Pacific time
astearns: any more items?
(silence)
Specs to Rec
------------
astearns: Things going to REC. Chris gave an update on Fonts.
Still waiting for info on Writing Modes impl & test
report.
astearns: 3 things I see.
astearns: 1 bunch of things with resolutions but editing has not
caught up, like values & units.
astearns: smfr or bogdan here?
astearns: I will ping them separately to get transforms edits done.
Rossen: bogdan is out sick today, belated regrets.
astearns: Another thing, we expect a bunch of tests in Mozilla to
contribute to test suites, but dbaron?
dbaron: No [progress].
astearns: What can we do to move it along?
dbaron: Probably difficult in next month or two.
astearns: Someone we can delegate to?
dbaron: Organizationally, lots happening in next month or two
taking up everyone's time.
astearns: Noted.
astearns: Another, gregwhitworth is looking for test review of
submission for variables-
astearns: he has pinged a few people in the github pr.
astearns: Any volunteers to look at those and get them into the
test suite? tab? chris?
astearns: Just a review of a submission.
TabAtkins: I can review them then.
ChrisL: What bits? variables tests?
<gregwhitworth> yes
ChrisL: I started looking at them, didn't finish reviewing them, I
can look at them
astearns: Tab you're off the hook. ChrisL will get to them in the
next week or two.
<gregwhitworth> please do - I'd love to wrap this up :)
astearns: Last thing, pending edits to CSS2.2
astearns: gsnedders suggested adding an editor
astearns: because Bert is on vacation.
astearns: CSS2.2 is an odd duck
astearns: in terms of editing.
ChrisL: I would be happy to add gsnedders
ChrisL: It is an odd duck because it uses the old pre-processor.
ChrisL: We cannot use bikeshed because it is a multi page document.
astearns: It is a monumental task to convert even if bikeshed
could.
astearns: gsnedders you sure you want to take this one?
gsnedders: yes? not sure about time, but so little has happened. i
can certainly start getting through some of the back log
<dbaron> For what it's worth, I *used* to have the old spec
preprocessor working locally, although various distro
updates broke that...
astearns: I think adding an editor is something I can do by fiat
<ChrisL> +1
RESOLVED: add gsnedders as editor to CSS2.2
astearns: Not sure when Bert is back but it is in noted in the
mailing list.
<ChrisL> 5 weeks
gsnedders: What is the name? css 2.1 second edition?
astearns: I forgot. As editor, please figure that out.
Does inlinification really need recursion?
------------------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1341
astearns: let's get to the first github issue on the agenda
astearns: inlinification and recursion
TabAtkins: I can take it.
TabAtkins: our current ... does ... but not ...
TabAtkins: In order to keep certain inline layout modes in
particular ruby from being broken up by blocks showing
up
TabAtkins: we use inlinification
TabAtkins: but as currently defined in the display module it might
be too aggressive.
TabAtkins: In particular it turns plain blocks (not bfcs) into
inlines
TabAtkins: which preserves the inliniciation but almost certainly
messes up your intended layout.
TabAtkins: Blocks become inlines.
TabAtkins: The other way we could do it:
TabAtkins: make all types of blocks, flow root or flow, turned
inline blocks.
TabAtkins: This would preserve display a bit more closely to what
intended
TabAtkins: inline block
TabAtkins: but is a little more complicated in the spec.
TabAtkins: On the other hand we probably have to do the opposite
for blockifications, turning inline blocks into block
flow, not block root.
TabAtkins: If anyone knows of any impl difficulty one way or
another, let us know.
TabAtkins: Otherwise we may go the latter way, inline blocks
turning into plain blocks.
<fantasai> in favor of inlifying into inline-block
<Rossen> <div> text <span> more text <div>am I inline?</div> end
text </span></div>
Rossen: I have a question and just pasted an example
Rossen: (describes example)
TabAtkins: Inlinification is not triggered by that
TabAtkins: but if instead of a span you had a ruby.
TabAtkins: It would no longer be a block.
Rossen: What does inlinification apply to?
TabAtkins: Ruby bases and text, and I think there is one more
context, run-ins?
Rossen: In that case if it is only tied to those 2-3, then it
shouldn't be much of a problem.
<dbaron> Isn't part of the problem here that there's not
inline-block variant that *isn't* flow-root -- and that
such a thing doesn't necessarily make sense?
<dbaron> But inlinification of block -> inline-block does seem to
make sense, as long as there aren't compatibility
problems.
<fantasai> dbaron, I think the complexity here is that 'flow' for
blocks can mean flow-root depending on various external
things, and historically these cases have a display
type of 'block' not 'flow-root'.
<dbaron> What do implementations do?
TabAtkins: dbaron, they do inconsistent things, bc run-in not impl
yet, ruby spec describes different thing that is broken
in its own way, because it doesn't stop blocks from
breaking things, so it is doing something, but
inconsistent with many things, unclear what impls
actually do.
fantasai: One thing to keep in mind for ruby, the only impl that
even remotely follow the spec is Firefox, the other two
impls are tag-based hacks in layout that hook into
inline-layout code.
fantasai: As far as we are concerned there is only one impl of CSS
Ruby spec.
Rossen: How many impls follow HTML ruby spec?
Rossen: Ruby spec as it is not ready for imply in our opinion that
is why we are not impl it
* fantasai would agree the css-ruby spec is not really ready for
implementation :) Lots of outstanding issues.
Rossen: re: ruby interop, HTML ruby interop is good.
Rossen: Then there is the spec in the works which it is hard to
argue what is interop and what is not.
Rossen: Question, do we know what is from the author / content
point of view the expected behavior?
Rossen: Do we not break anything in the ruby context e.g. blocks?
or do we need to blockify?
fantasai: The general case is that ruby is not expected to contain
block level content, generally just text, not enough
text to wrap, though there are some pathological cases
where the text does wrap.
fantasai: We are trying to stop the bleeding.
fantasai: We don't want to have to deal with how do you break ruby
annotations across lines
fantasai: so we are inlinifying.
fantasai: Similar for run-ins
fantasai: e.g. if you have a headline and want to run into the
next paragraph
fantasai: if you stuck a block in that headline, then it's not
going to run-in properly.
fantasai: We could say if you have a block inside, then you could
say it does not run-in
fantasai: but then you have to inspect all the way down.
<jensimmons> +1
fantasai: We just want to check the element its properties and
parent(s)
fantasai: ... inline-block ...
fantasai: or we ... to turn into inlines
fantasai: ... everything is contain in a bfc that is now inline
<TabAtkins> (A simple test-case:
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5218.
Chrome's rendering is *incoherent* here, so our
behavior can't be depended on.)
Rossen: I agree with that logic
<jensimmons> what fantasai just said sounds right to me. Turn it
into an inline block.
Rossen: Is this an error case?
Rossen: In which case I expect exceptions or something more
dramatic
Rossen: so as an author I can see something wrong and go fix it
Rossen: rather than us trying to make it sorta work.
<jensimmons> as an author I would expect that is the ‘right’
behavior
Rossen: If this is an error, let's make this very obvious.
Rossen: Otherwise if we patch it up so it sorta looks ok, then
it's not going to be as good.
<ChrisL> I agree with Rossen on this
fantasai: Whatever we come up with is going to look weird.
dbaron: To some extent, inline is a more obvious error than
inline-block for something that was originally a block.
fantasai: But is also more work
fantasai: and I don't see that that is necessary.
<liam> not sure about "let's break existing pages" - can't assume
people will fix it
fremy: what about display none?
fantasai: Absolutely not.
fantasai: This is the web platform and we do not make things
disappear as an error case [except for XML draconian
heads :P ]
Rossen: Inlineness down recursively...
Rossen: I would be in favor of either inline-block or block.
jensimmons: I hear about things breaking more badly, but in a
practical reality, most authors struggle to understand
inline-block vs block vs inline does.
jensimmons: I think make it inline-block make it seem less broken.
jensimmons: Feels like make the outer inline while everything
stays block is how it supposed to work?
jensimmons: Authors are already struggling. Making it more broken
for them is not going to help.
fantasai: It is not really an error case
fantasai: but we need to do something with it.
TabAtkins: While doing inline-block is a little more complicated
from the spec perspective, it is fairly insignificant,
it's fairly straightforward, I'm happy to go with what
makes more sense.
astearns: I am hearing people are ok with either inline or
inline-block
astearns: but some pref for inline-block
astearns: so we should resolve inline-block and see how it goes.
astearns: Any objection to inline-block in this instance?
RESOLVED: inline-block because they're awesomeish
Blockification doesn't seem backwards-compatible for inline-blocks
------------------------------------------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1246
<fantasai> issue under discussion
https://github.com/w3c/csswg-drafts/issues/1246#issuecomment-301634850
TabAtkins: Exact opposite case
TabAtkins: When you blockify an inline-block what happens?
TabAtkins: Right now blockification just changes the outer display
type to block
TabAtkins: in particular for an inline-block, it becomes a block
flow root
TabAtkins: which when you ask its display type it says block flow
root
TabAtkins: but for legacy reasons it has to be block.
TabAtkins: We probably need to do same sort of exception.
TabAtkins: When you blockify an inline-block, it becomes a plain
block
TabAtkins: now that we have the opposite thing, it is reasonably
consistent.
fantasai: This is on the agenda because it is more complicated
than that.
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/1246#issuecomment-301634850
<TabAtkins> Two possibilities ^^^
fantasai: We can treat inline-block and inline-flow-root as the
same
fantasai: alternatively we can treat ... as ...
<fantasai> Treat inline-block and inline flow-root as
syntactically equivalent. Make both of them blockfy as
display: block. Treat inline-block and inline flow-root
as syntactically distinct. Make inline-block blockify
as display: block; inline flow-root will blockify as
flow-root.
fantasai: The advantage of first approach, is that the inline-foo
are all syntactic equivalents.
fantasai: The advantage of the second approach is ...
<jensimmons> I vote (b). It makes sense that the flow-root-ness
would stick around, imho.
Rossen: The 2nd approach will round trip nicer through the OM
right?
TabAtkins: Doesn't matter yet.
Rossen: The distinction between display outside and inside, which
one will round trip more gracefully.
fantasai: We have defined all the inline-* to all the
inline-space-* etc.
fantasai: We didn't have the display module in time to avoid the
inline-... and inline-...
fantasai: if you have a inline-space-table and read it back out in
the OM it will take the shortest most compat form and
return inline-table.
fantasai: If we want the 2nd approach we have to not convert,
maintain as a separate thing, e.g. inline-flex two ways
to syntactically define it and would not collapse.
Rossen: If we blockify a display block rather than inline flow
root, and you read back the display and set it back on the
same element, you are now going to turn an inline block
into a block.
fantasai: Yes that happens right now
fantasai: for flexes and other things that blockify
fantasai: happens in 2.1 and flex and grid.
<fantasai> (via abspos, floats, etc.)
Rossen: My understanding is ... blockification as opposed to flow
root in terms of where positioned, it will try to be block
as much as possible.
TabAtkins: I am confused about what you are trying to say Rossen
TabAtkins: anything inline-ish becomes blockish
TabAtkins: inline-root becomes flow-root
TabAtkins: inline-block becomes block.
Rossen: The inline block will become a flow root?
TabAtkins: Yup.
Rossen: If I read back (static) what will be different.
Rossen: Which one of those will be (static) be better (siren)
Rossen: which of those two if re-parented, if any will have more
expected behavior.
TabAtkins: The flow root one will
TabAtkins: that is the reason why blockificiation turns a
inline-block into a flow root
Rossen: ok that is why I am leaning more towards flow root.
TabAtkins: So that sounds like you are suggesting 2nd one:
TabAtkins: inline-block becomes block for legacy reasons
TabAtkins: but inline flow root becomes block flow root.
<fantasai> Option A: inline-block -> block; inline flow-root ->
block
<fantasai> Option B: inline-block -> block; inline flow-root ->
flow-root
astearns: Any other conversation on this?
astearns: Any obj to inline space flow become inline flow root?
fantasai: Main concern, we no longer treat inline-* and inline
space * as equivalent.
TabAtkins: For this specific value.
astearns: In part for legacy reasons.
TabAtkins: Entirely for legacy reasons.
fantasai: But that means if you compute inline foo ...
fantasai: But now we have to keep them distinct in the OM as well.
TabAtkins: Yeah we will have to.
astearns: Is your desire for syntactic equiv an obj?
fantasai: No, just wanted to make it clear.
dbaron: It is an extra point of confusion in that before we could
say these two things are equivalent
dbaron: but it is now more complicated because in this one case
they are not.
dbaron: The other question is whether you maintain separate
computed values for just this one case or the whole
possible space of values.
TabAtkins: hmm.
astearns: I would expect we would maintain equivalent where we can
and this is the exception that proves the rule.
<dbaron> I'm not crazy about the idea, but I'm not objecting to
it...
astearns: So.
astearns: Do we resolve to use option b and work through the
details? or shall we spend some more time working the
details in the issue and come back to this?
TabAtkins: I think we should resolve on b and I can open a
separate issue on the point that dbaron just raised.
TabAtkins: I'll open a separate issue for that.
fantasai: My concern is that if we go with option b and then we
have the other discussion, then we find we don't like
and want to come back to option a.
fantasai: b implies at least two things that a does not in terms
of how other values behave
fantasai: but that was not discussed in the issue in terms of a vs
b.
astearns: fantasai do you want to postpone making the resolution?
or ok to have provisional resolution for b?
fantasai: That is a more important discussion to have
fantasai: and then decide this issue because I think it is less
important.
fantasai: The resolution here should depend on that discussion.
TabAtkins: I disagree but I have no problem with changing the
resolution later
TabAtkins: if based on another discussion we decide we resolved
wrong.
astearns: When you open the new issue TabAtkins please link back
to this one, so once we decide on the other one we can
see if this resolution still holds.
ACTION TabAtkins open new issue on what we are doing with the
syntax equivalencies and linking back to this issue so we
can revisit this resolution
<trackbot> Created ACTION-852
astearns: Any objection to resolving on option b for current issue?
RESOLVED: We are provisionally going with option b.
Propagation of text-decoration with display:contents
----------------------------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1136
astearns: Propagation of text-decoration.
TabAtkins: Question: how do text-decorations propagate? on what
tree do they propagate? they are not inheritance.
something after inheritance. on box tree? element tree?
or something else magic?
TabAtkins: There are several arguments for box tree, in particular
compat constraints.
TabAtkins: If you have an inline with an underline
TabAtkins: if you have a span underline ...
<TabAtkins> <span underline>foo <div>INTERRUPTION</div> bar</span>
TabAtkins: If you have this^
TabAtkins: the foo and the bar get underlined, the INTERRUPTION
does not
TabAtkins: because the block has broken the span apart.
TabAtkins: If the decorations propagated through the element tree
then the div would get the decoration
TabAtkins: but if propagate through the box tree then that is what
we see.
dbaron: It is already specified in terms of the element tree, and
just specifies that case
<fantasai> https://drafts.csswg.org/css-text-decor-3/#line-decoration
TabAtkins: It is not well specified from what we can see.
dbaron: I believe we implemented it from a spec that was
relatively clear.
fantasai: I believe that was 2.1
fantasai: which does not distinguish between elements and boxes
very well.
dbaron: It was readable in terms of elements, and describes that
case as don't do this thing
dbaron: It explicitly said that.
<fantasai> https://www.w3.org/TR/CSS21/text.html#decoration
TabAtkins: That implies that display:contents as implications on
how we treat that
TabAtkins: whether that affects the decision.
fantasai: It shouldn't make a difference element vs block tree in
general, but it will affect once we have display:content
fantasai: Question is whether you can propagate to text nodes
which are new thing now.
TabAtkins: Side question if you specify it on a display:contents
element does it propagate to its contents?
dbaron: In terms of that we impl on the box tree.
TabAtkins: According to r... so do we.
astearns: Any other interop data?
<dbaron> we walk up the box tree, but through placeholders for
out-of-flows
fremy: Technically I can try... in IE.
TabAtkins: I got it the opposite.
TabAtkins: Fix up will interrupt decoration.
fremy: example?
<TabAtkins> https://bugs.chromium.org/p/chromium/issues/detail?id=553174
TabAtkins: Yes I have a CR example^
TabAtkins: This is interruption due to inline table. We are
propagating, other browsers do not.
dbaron: Beware of tables when testing text-deco because there are
quirks mode diffs.
fremy: ... apparently ...
<dbaron> The Gecko code is at
https://searchfox.org/mozilla-central/rev/b318c7dca7392bd16c0b11929f55b1be133f0b31/layout/generic/nsTextFrame.cpp#5373
TabAtkins: What about the 2nd case? where element is an inline
table?
TabAtkins: (describes bug)
fremy: I see what you mean.
TabAtkins: Our impl is inconsistent.
TabAtkins: The fact that these two cases should be identical in
any sensible interpretation implies that it should be a
box tree concept possibly with some nods to the element
tree e.g. block that splits inline.
fremy: I don't know either we would have to change something
either way.
astearns: Sounds like we need to spec this as box-tree concept and
file bugs on browsers.
TabAtkins: Chrome has a bug filed.
astearns: Any objections to defining this as a box-tree concept?
RESOLVED: Define this as a box-tree concept.
Should anonymous boxes always inherit through the box tree?
-----------------------------------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1118
TabAtkins: This is about inheritance, not normal inheritance.
TabAtkins: Do they inherit through box tree or element tree?
TabAtkins: We have a diff in the thread there as a suggestion.
TabAtkins: Aside from a few nits we don't have obj. well we have
anti as disagreement.
TabAtkins: Also says webkit could impl without much trouble.
TabAtkins: It touches several specs
TabAtkins: the implication of it is that in the example, first
post in the thread
TabAtkins: using the code provided where section provides a color
and div provides a color
TabAtkins: but div is display contents, the text will still be
green
TabAtkins: it won't turn red just because there is display
contents involved.
astearns: But if the div had an underline?
TabAtkins: Decorations are weird and should not impinge on this.
TabAtkins: This is just about normal inheritance.
TabAtkins: Recall these two examples:
<TabAtkins> <section color:red><div color:green display:contents>
Foo</div></section>
<TabAtkins> <section color:red><div color:green display:contents>
<span>Foo</span></div></section>
TabAtkins: First example, should text be green or red.
TabAtkins: Second example, there is an absolute correct answer,
and no way to question it.
TabAtkins: 2nd example span inherits from div in ordinary way, and
then foo gets its color from span.
TabAtkins: It's just the 1st ex that we have question about.
TabAtkins: Putting in an empty span like that shouldn't change how
inheritance works
TabAtkins: so the edit we put together, makes node text be stuff
in the tree.
TabAtkins: We have text nodes in the element tree, text runs in
the box tree
TabAtkins: means inheritance works the same in both cases
TabAtkins: (describes color and boxes)
astearns: I have not reviewed the diff, but I like the concept as
described, would like to go forward.
TabAtkins: If people feel they need more review that would be fine
but if they are ok with it I would like to commit it.
fremy: For us I think it would be fine.
astearns: Any obj to going fwd with diff?
RESOLVED: let's try it out, go forward with the diff
astearns: Almost to the hour. that's it for today.
astearns: Thanks everyone for calling in.
<astearns> REMEMBER that next week's meeting is shifted to 4PM PT
Received on Wednesday, 7 June 2017 12:21:35 UTC