- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 5 Apr 2018 16:22:18 -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.
=========================================
Fonts Level 4
--------------
- RESOLVED: Publish a new WD of Fonts L4
Values & Units 4
----------------
- RESOLVED: Extend value definition syntax to handle value ranges
and possibly other syntactic restrictions, syntax TBD.
(Issue #355)
CSS Display
-----------
- RESOLVED: Accept change set
https://github.com/w3c/csswg-drafts/commit/b2d484c6ab9c4dbdb8fdca899e2d37d59d6953e3
(Issue #1643)
- RESOLVED: Add the appendix
https://drafts.csswg.org/css-display-3/#box-guidelines
to Display 3 (Issue #1643)
- RESOLVED: Run-in flow-root blockifies to block and not flow root.
(Issue #1715)
- RESOLVED: Treat display:contents as display:none for MathML.
(Issue #2167)
- RESOLVED: We define how SVG elements interact with
display:contents based on SVG defined categories. We
will add a new issue about what to do with attributes.
(Issue #2118)
- RESOLVED: Keep this note (The display property has no effect on an
element’s semantics: these are defined by the document
language and are not affected by CSS. Aside from the
none value, which also affects the aural/speech output
[CSS-SPEECH-1] and interactivity of an element and its
descendants, the display property only affects visual
layout: its purpose is to allow designers freedom to
change the layout behavior of an element without
affecting the underlying document semantics.) in Display
L3 (Issue #2335)
- RESOLVED: Pending AmeliaBR edits, publish a new WD of Display L3.
CSS Grid
--------
- RESOLVED: Specify the current behavior in all the browsers except
Edge. Just don't use repeat() in grid serialization.
(Issue #2427)
Multi-Col
---------
- RESOLVED: Remove the UI defined bit and go with 1em for computing
normal in multi-col. (Issue #2145)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Apr/0001.html
Present:
Rachel Andrew
Tab Atkins
David Baron (beginning of call)
Amelia Bellamy-Royds
Garrett Berg
Elika Etemad
Dael Jackson
Chris Lilley
Theresa O'Connor
Manuel Rego
Melanie Richards
Florian Rivoal
Alan Stearns
Regrets:
Angelo Cano
Tony Graham
Vlad Levantovsky
Peter Linss
Liam Quin
François Remy
Geoffrey Sneddon
Shane Stephens
Lea Verou
Greg Whitworth
Eric Willigers
Scribe: dael
astearns: It's 5 after. We have...10 people on the call. Which seems
pretty light.
astearns: Maybe we can get through a few things.
astearns: fantasai mentioned the first item on the agenda is a name
convention that might should wait until TabAtkins calls in.
astearns: Anything else anyone would like to add to the agenda?
Fonts Level 4
=============
Publication of Fonts L4
-----------------------
astearns: I understand this is just a regular WD and we've had FPWD
fantasai: Yeah.
astearns: Objections?
<ChrisL> +1
RESOLVED: Publish a new WD of Fonts L4
<fantasai> \^_^/
Values & Units 4
================
Define <positive-integer>, <positive-number>, <positive-length>, etc.
sub-types
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/355
AmeliaBR: A couple years ago there was discussion and it got lost in
bikeshedding syntax. I wanted to at least get a clear
opinion from the group if the idea is good.
AmeliaBR: I'd like to see if that when we have properties with
constraints enforced by the parser, most common is no
negative values, there is a way to explain that in the
grammar rather then only prose.
AmeliaBR: It would be convenient for people impl parsers if the
grammar covered everything esp now that Houdini is
exposing the value syntax. Might be time to be more strict
about value definition language.
<florian> +1, makes total sense to me
AmeliaBR: I was hoping to get a resolution that it would be a good
idea to extend value definition language to cover all
constraints from the parser.
<dbaron> "all constraints that can be enforced by the parser" sounds
like it might be a little much
AmeliaBR: I had a second question on narrowing down approaches.
<astearns> +1 from me as well
<TabAtkins> positive-int, and gez-int and gez-number seem very fine,
along with gez-length/etc
<astearns> define gez?
<TabAtkins> greater-equal-zero
<TabAtkins> p-integer, nn-integer
fantasai: I don't think we'll be able to put in all parsing
restrictions because I remember there are restrictions not
in the grammar that aren't just about limiting range of
numbers. We won't get to 100% but it should be possible to
put range restrictions. If this is author exposed syntax
that might be important.
florian: I think we could take somewhere between...in V&U we define
non-negative ranges and houdini relies on that. If it's not
the case already in individual specs we have something that
looks like int but with constraints we define a new type.
Doesn't have to be shared in V&U. That's not actionable,
that's how to write. The actionable part I'm all for it.
astearns: I'm all for having this defined in the grammar and not
lost in the prose. I don't care what names we use
particularly.
fantasai: I'd like the syntax to be reasonably readable and not so
long that the grammar is hard to read.
non-negative-integer is really long.
fantasai: Every time we throw in one or four of these it gets long
and maybe wraps and it's hard to read. It seems like a
great idea but I haven't seen a proposal for yes we should
do it this way. If this is exposed in Houdini we should
put thought in understandable and usable like we do for
other property values we define.
astearns: I think consensus is this is a good direction to take.
Second question?
AmeliaBR: My initial idea was new name types but in the discussion
there was a suggestion of introducing it more as a
modifying constraint within the type. Syntax that looked
readable was make it look like a HTML attribute.
AmeliaBR: It's very nice and readable. Other aspect is it's open
ended. Could be a benefit, could be a negative. Do people
like the idea of adding a general way of adding
constraints or is it something we want to keep to named
types?
TabAtkins: I hadn't seen that comment, I'll have to think about that.
<florian> I am not sure, but I am intrigued
<TabAtkins> Ah, I suggested p-* and nn-* in the issue. ^_^
astearns: proposal: we will add more terms tot he grammar to
describe value ranges and such, but approach is in the air.
astearns: Objections?
<fantasai> proposed resolution: Extend value definition syntax to
handle value ranges and possibly other syntactic
restrictions, syntax TBD
RESOLVED: Extend value definition syntax to handle value ranges and
possibly other syntactic restrictions, syntax TBD.
CSS Display
===========
Defining box ↔ element style correspondence
-------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/1643
<fantasai> https://github.com/w3c/csswg-drafts/issues/1643#issuecomment-374414522
<fantasai> https://github.com/w3c/csswg-drafts/commit/b2d484c6ab9c4dbdb8fdca899e2d37d59d6953e3
fantasai: We got two issues out of the one filed. First is that it's
not defined that the things that apply to and element
apply to a box. We tightened that in this change set ^
fantasai: That's the first issue.
florian: Is it a one to one correspondence?
fantasai: No because some apply to principle box and some to others.
On a table some are to wrapper box and some to table. So
we said computed value to the box to which it applies.
astearns: Quick read from me seems like that change is good.
astearns: It's really expanding on the sort sentence we had.
fantasai: Yes.
astearns: Objections to this change?
RESOLVED: Accept change set
https://github.com/w3c/csswg-drafts/commit/b2d484c6ab9c4dbdb8fdca899e2d37d59d6953e3
florian: Question, you're saying inherited prop inherit through box
tree. Does that do strange when some boxes are suppressed?
fantasai: I don't think so. When they're suppressed they're not in
the box tree.
fantasai: I don't know of a case when an element generates two boxes
where one is the child then the other and there's a
suppressed box between.
florian: So children of display:none has no inheritance?
fantasai: Inheritance happens in the element tree. Before and after
boxes inherit. Anon boxes inherit. First you do the
cascade, then inheritance, then you get prop for every
element in the tree.
florian: Sentence I'm reacting to is a clarification, not a
requirement. It's not clear that's what was meant. It
confused me.
fantasai: Sentence says [reads]. So I don't know where you'll get a
problem.
<fantasai> + In general, <a>inherited properties</a> are assigned to
the <a>principal box</a>,
<fantasai> + and then inherit through the box tree
<fantasai> + to any other boxes generated by the same element.
florian: If you think enough there's only one explanation and it's
the sane one.
astearns: If you can come up with something clearer feel free to
make a PR.
florian: This is fine.
Adding appendix of anonymous box construction guidance for spec
authors
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1643#issuecomment-374414522
astearns: Second change?
fantasai: Second it was asking for guidance on box tree
construction. We added an appendix.
<fantasai> https://drafts.csswg.org/css-display-3/#box-guidelines
fantasai: It has four bullet points of things you need to define if
you're writing a spec that changes boxes.
astearns: Looks fine to me.
florian: That's useful.
astearns: Objections to adding this appendix to display 3?
RESOLVED: Add the appendix
https://drafts.csswg.org/css-display-3/#box-guidelines
to Display 3
fantasai: That's if for this issue. There was a grumble about 2.1
terminology.
Blockifying 'run-in flow-root' to 'block' (for consistency with
inline-block)
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1715
florian: Was an alternative considered? I can't think of one.
TabAtkins: It's the question in the title. Should it blockify to
flow-root. It shouldn't.
TabAtkins: An inline flow root blockifies to an ordinary block. This
is for legacy reasonings. A run-in flow-root needs to
blockify somehow. The general rule for run-in they're
identical to inlines. Thus it should blockify the same as
inlines.
TabAtkins: Alternative is if blockifies to flow-root which makes
sense in abstract, but we'd loose the connection to
inline.
florian: Consistency argument wins or theoretical purity.
astearns: Run in flow root blockifies to block and not flow root.
astearns: Objections?
RESOLVED: Run-in flow-root blockifies to block and not flow root.
'display: contents' on MathML
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/2167
TabAtkins: We have special rules for how display:contents should
work in SVG. [missed]
TabAtkins: How to handle display:contents- a few elements treat it
like HTML, ones with a transparent content model.
Everything else is treated as display:none because
children can't be rendered one level up. Looking at
mathML there are 0 instances where children can be
rendered in outer context.
TabAtkins: It would almost never be correct to lift children to
outer context. There are a few places where it's right
with only a certain number of children. Best thing I can
see is make it always display:none on MathML. Firefox
devs were fine with this.
<florian> +1
astearns: Given other times we said display:contents are handled as
display:none and how well they went over I expect this to
come up again.
TabAtkins: If someone can point to a MathML function where it makes
sense we can change this.
fantasai: We'll CC MathML WG when we publish a WD
florian: And we CCed some MathML people along the way.
astearns: You want to talk to math on the web community group
astearns: Objections to treating display:contents as display:none
for MathML?
RESOLVED: Treat display:contents as display:none for MathML.
'display: contents' on SVG elements
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2118
TabAtkins: We've resolved on which SVG elements respond in which
ways to display:contents.
TabAtkins: It was pointed out I made a mistake. That points to a
larger issue that as SVG evolves the elements that are
categorized will evolve. Instead of categorizing
explicitly we should use the element categories that SVG
defines.
TabAtkins: AmeliaBR suggested a particular grouping for each one.
SVG WG did review and said it was fine. I think it's
fine. If the rest of the group is okay switching to using
SVG categories we can do that.
ChrisL: I agree this is best and I like AmeliaBR categories.
AmeliaBR: Categories are appropriate. They weren't made with this
use case, but by intersecting existing categories we can
make it work.
AmeliaBR: One thing, we haven't designed...would display:contents on
a text-path override layout defined on an attribute?
AmeliaBR: t-span and text-path are ones we're saying text content
works as an unboxing. They both involve layout with
attributes not CSS properties. I had been assuming that a
display:contents would mean ignore any layout specific to
this element, but we should be explicit.
ChrisL: Agree.
ChrisL: They're not presentation attributes?
AmeliaBR: No.
TabAtkins: I need to finally write up the explanation for how SVG
rendered into CSS box model. We keep having to do this
tap dance and we know it uses a reasonable concept of
boxes. Then it'll all work out.
AmeliaBR: Can you do that by next week? ^-^ Elsewise a note saying
it unboxes all layout regardless of syntax.
florian: Follow up question on attributes. These presentational
attributes on the element, can some be described as
inheriting to anonymous box with the text? Or are they all
clearly to the suppressed box?
AmeliaBR: Good and complex question.
TabAtkins: There's no anonymous box around text, it's lifted to
parent. Anything presentational that's CSS disappears.
Anything which is just in SVG terms we'll for now put
something in that says do the same.
florian: So they just disappear? You bold a font in the style and
display:contents on the span you get bold text. Do we have
things like that in SVG where they need to apply to the
text-run?
AmeliaBR: The bit where I said it was complex...the layout
attributes inherit down in a way that doesn't quite match
CSS because it's per character. But it's similar to
inheritance.
florian: It seems to me the thing we're about to resolve on it right
but a bit incomplete. We need to talk per attribute. Or is
there a well enough defined thing in SVG.
AmeliaBR: What's the spec status? Trying to get to CR and don't want
an open issue?
TabAtkins: It's not a big issue. We look at each and say if it's an
inheriting property.
fantasai: Next step is WD so it doesn't need fix today.
AmeliaBR: I can try and write up something and perhaps a note about
an open issue needing more review.
fantasai: Sounds like we're going to accept the changes. There is a
followup issue on attributes that should be opened
separately.
astearns: Question on the categories. We're going to call out
categories that are not doing display:none and anything
not called out is the display:none. If at some point SVG
defines new things that might have something different
then display:none we'll have to add it in the future. Is
that the right approach?
AmeliaBR: Yeah. Presumably most elements that are new would fit into
one of these categories. This idea with these category
names is they should be open ended.
astearns: So a new thing would be classified as a renderable element
it would be fixed.
AmeliaBR: If we defined a new attribute as a renderable element it
would auto-apply
ChrisL: It would only be a problem if we needed a new category
astearns: Prop: We define how SVG elements interact with
display:contents based on SVG defined categories. We will
add a new issue about what to do with attributes.
astearns: Objections?
RESOLVED: We define how SVG elements interact with display:contents
based on SVG defined categories. We will add a new issue
about what to do with attributes.
<florian> AmeliaBR, do you want to file that new issue? I believe
you got my point, and you're more likely than me to phrase
it right.
<AmeliaBR> florian, yes, I'll do that.
Clarify (non-)effect of 'display' on document semantics and assistive
technology
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2355
<fantasai> https://github.com/w3c/csswg-drafts/issues/2355#issuecomment-375084853
fantasai: This is about adding a note to explain display properties
doesn't effect semantics. I was asking for WG review of
the note text. Let me know if there are changes to suggest.
florian: I agree with the note but I'm surprised it's needed. If I
understand it's a note because browsers do mess it up.
fantasai: They acknowledge this is a bug.
florian: We're not stuck for compat?
fantasai: Everyone agrees it's a bug, it just hasn't been a priority.
florian: Good.
astearns: I guess there is no linkable bit in the spec to this note.
<astearns> https://drafts.csswg.org/css-display-3/#the-display-properties
astearns: This section^ This is the section the note is in. But
there's no way to link to just the note in the bit.
fantasai: I can give it an anchor.
astearns: I don't know it's necessary. Just trying to get text into
the minutes.
fantasai: It's quoted in the comment
<fantasai> The display property has no effect on an element’s
semantics: these are defined by the document language and
are not affected by CSS. Aside from the none value, which
also affects the aural/speech output [CSS-SPEECH-1] and
interactivity of an element and its descendants, the
display property only affects visual layout: its purpose
is to allow designers freedom to change the layout
behavior of an element without affecting the underlying
document semantics.
astearns: Any other opinions or concerns about this note?
astearns: Proposal: keep this note in display L3.
astearns: Objections?
RESOLVED: Keep this note in Display L3
Publication
-----------
fantasai: Once we fold in the edits.
astearns: Pending AmeliaBR edits, objections to publishing a new WD
of Display L3?
RESOLVED: Pending AmeliaBR edits, publish a new WD of Display L3
CSS Grid
========
Disallow repeat() syntax in grid-template-rows/columns resolved values
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2427
Scribe: fantasai
TabAtkins: So we resolved to serialize out the repeat()s that were
specified,
TabAtkins: but actually you can't do that as fantasai points out in
https://github.com/w3c/csswg-drafts/issues/2427#issuecomment-377357237
TabAtkins: So we need to choose some different option
TabAtkins: There are a few possible options
TabAtkins: First is to reverse previous resolution: don't use
repeat() in serialization of gCS
TabAtkins: This is very simple and straightforward
TabAtkins: downside is it can potentially produce very long values
for grid-template*
TabAtkins: if you do something like grid-template-rows:
repeat(10000, 1px)
TabAtkins: Second option is to compress any adjacent tracks that
have the same track size (and line names)
astearns: Clarification on 2nd option, is that only when specified
value was repeat() or anytime?
TabAtkins: Anytime
TabAtkins: more complicated variants are to track which tracks came
from a repeat(), and then collapse them if possible
(These options are summarized in
https://github.com/w3c/csswg-drafts/issues/2427#issuecomment-377357237
)
TabAtkins: The Igalia folks don't like tracking which things were in
repeat() originally
TabAtkins: seems like too much complexity for little gain
TabAtkins: I think the best thing to do is to not serialize
repeat(). The only issue is a blow-out of string sizes if
you have long ones
TabAtkins: but there is a cap on the number of tracks so it won't be
too crazy
florian: I think I'd go with non-collapsing things
florian: Seems to me that there are a lot of corner cases
florian: I think I'd go with non-collapsing things as well. As i'm
looking through there seems to be lots of corner cases. I'm
not sure they'll all be fine.
florian: Given there's limited value le's skip the pain.
Scribe: dael
florian: Given that you get things like calc that are somewhat the
same. I'd rather just not go there.
astearns: Only edge rep is melanierichards. Since Edge is the
browser that retains repeat() and thought we should. I'd
like to get an Edge opinion.
fantasai: frremy says still siding on the don't use repeat() side.
TabAtkins: Rossen wants repeat() and frremy would rather not.
astearns: Since frremy commented on the issue my Edge concern is
satisfied.
astearns: Other comments on if we should deal with repeats or throw
them out?
astearns: Prop: Specify the behavior in all the browsers except
Edge. Just don't use repeat() in grid serialization
RESOLVED: Specify the current behavior in all the browsers except
Edge. Just don't use repeat() in grid serialization.
MultiCol
========
Make "column-gap: normal" to be 1em in multi-column per spec
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2145#issuecomment-377445142
rachelandrew: In the multi-col spec there's a suggested value of 1em.
rachelandrew: Everyone is doing 1em so we suggest it's mandatory.
florian: And this interop includes print formatters. Let's go for it.
astearns: Proposed is remove the UI defined bit and go with 1em for
computing normal in multi-col
RESOLVED: Remove the UI defined bit and go with 1em for computing
normal in multi-col
astearns: Thanks everybody for calling in. We'll have the F2F next
week so please add things to the agenda.
astearns: Safe travels to everyone coming and talk to you all next
week.
Received on Thursday, 5 April 2018 20:23:15 UTC