- 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