Meeting minutes
<TabAtkins> can we get updated topic?
<TabAtkins> thanks rossen ^_^
Rossen_: Hey everybody. Let's give it another minute and then we'll get going
Rossen_: Let's get started
Rossen_: We have a full agenda. As usual I wanted to ask if people have any extra agenda items
Rossen_: Only reminder to give is about the upcoming F2F in February.
Rossen_: We have started to add the milestones to open issues. Feel free to mark agenda+ F2F for anything you want for the F2F.
Rossen_: Other details are in the private list
[css-cascade-5] Rename @layers to@layer
github: https://
Rossen_: fantasai anything to add?
fantasai: Nope
<florian> Seems fine
Rossen_: Any feedback or objections to renaming @layers to @layer?
<miriam> I'm in favor
<leaverou> in favor
Rossen_: Hearing no objects and seeing IRC support
Resolution: rename @layers to @layer
[selectors] Define how "legacy aliases" work on selectors.
Rossen_: Is emilio on?
[waiting for emilio to join]
github: https://
emilio: Have a couple places where we define a selector where for legacy reason can be impl as alias but no definion of that.
emilio: Came up as I did compat work on other pseudo classes.
emilio: Compat can change what needs to be done but seems as if we should have guidance on how this should work
emilio: afaict two options are keep zeroizing the non-standard or convert them at parse time
emilio: Some inconsistencies in Blink. Gecko should always turn it intot he stanrdard at parse time. I think that's what we do for properties in general
Rossen_: Prop is align more closely with converting at parse time
Rossen_: Questions or should we resolve on that?
Rossen_: I'll take silence as no
Rossen_: No comments or objections?
Rossen_: I see support in GH from TabAtkins
Resolution: convert at parse time
[math] [css-fonts] Solution to mixing text and math fonts in a document
Rossen_: Do we have folks to discuss these MathML issues?
Rossen_: fantasai you added this to agenda a while back
github: https://
Rossen_: Silence I will take as not ready.
github: none
Rossen_: We'll backlog at this point and remove agenda+
[css-display] math/inline-math
github: https://
Rossen_: Is this something we can resolve now and move forward and if anyone has issues we can reopen
fantasai: Mats prop that display:math outside of MathML should make element behave as an em row. I agree with Mats but Fred thinks more complex to impl. Mats had impl and didn't think it was complicated
Rossen_: Who was push back on complexity?
fantasai: Fred
<fantasai> https://
emilio: Also issue of display:math doing magical things depending on which element. Is there a different issue on that? That's the other concern Mats had
fantasai: Should be a different issue on that one
<fantasai> https://
emilio: I don't mind filing it, no need to discuss right now in order to discuss right now
Rossen_: Doesn't sound like we're ready to discuss
fantasai: I can't present Fred's PoV. I can point you on the comments. I agree with Mats so could represent that.
Rossen_: Let's push this on back to the backlog as well
Rossen_: Perhaps these can be F2F topics
fantasai: You need to schedule them when the people you want to show up will show up. It's been end of agenda so no one knows to call in
astearns: I pinged everyone involved and didn't get a response
Rossen_: Likewise. It's not for lack of trying
Rossen_: There are going backburner and those that care can bring them back
[css-pseudo-4] painting of the cursor and the caret with highlight pseudos
github: https://
fantasai: florian asked hwat happened with multi highlights and different caret values. Which one wins. top or top non-auto. Top most non-auto makes more sense I think but I don't know. Is anyone planning to impl these properties?
<castastrophe> Sorry, I need to drop
Rossen_: Regardless of plan to impl we should be able to define expected behavior. If top-most non-auto makes most sense we can resolve and when people impl if it's not the right choice we can discuss again then
florian: Alternative could be if no one thinks this is good to impl we could drop from list of elements that apply to this psedo element. These were added b/c not layout effecting. But if there's no interest we could drop them.
Rossen_: CHoices are drop it or top-most non-auto
GameMaker: I wasn't on the call but I recall reading notes about issues with this and grammar and auto-spell check b/c loading resources could be a security issue
GameMaker: Maybe didn't understand discussion, but thinking that could be a reason to drop. In my impl I haven't looked at doing cursor or caret. Definitely would be more complicated to do. I'm in favor of just dropping cursor and caret
<tantek> +1 to dropping. seems to add complexity for theoretical reasons
Rossen_: Anyone want to keep those?
florian: Not a strong want but it seems security only applied to one of the two. Caret color won't load resources
fantasai: But if no one wants to impl and there's no strong usecase we should drop
<tantek> I'd be in favor of only reconsidering them if an implementor felt compelled to try implementing it (for whatever reason)
Rossen_: Objections to dropping caret-color and cursor?
Resolution: drop caret-color and cursor
[css-sizing-4][css-contain-2] Revisiting auto-sizing when size-containment applies
github: https://
vmpstr: A little background. We have content-visibility:auto Way it works is when element goes offscreen we add size containment and when it's on screen we remove. Can change the scrollbar size which is undesired. Added contraint-intrinsic-size to manage this. Works great as a placeholder b/c gives some size even when size containment applies.
vmpstr: Problem is it's hard to know the right size so scrollbar can still jump. When element is on screen as it rolls offscreen browser knows size that would cause scrollbar not to jump. There is a value it oculd take. Broswer knows but it's not exposed
vmpstr: I think script can get an estimate
vmpstr: Prop is add an auto qualification to contain-intrinsic-size which is when size containment is first applied and when content has been previously rendered remember that size and use it as the value. Else use placeholder
vmpstr: Daniel and Christian raised some points that it adds dependency on sequence of steps.
vmpstr: Wanted to bring to group. Hoping there's a solution that doesn't involve script. Maybe not this exact proposal, but this is what I have
TabAtkins: Point about non-determinism about exactly when size is recorded, while technically true it's a cost we eaten with animations. Style depends on exactly when it started so you know how far in animation you are. Since we've eaten that cost for animations I don't see why not here unless we think that was unavoidably broken
TabAtkins: We should think about htis the same as animation start
<TabAtkins> smfr's idea makes sense to me as well
<TabAtkins> it's what you'd get if you did this by hand anyway
smfr: Slightly different prop is spec this exactly same as resizeObserver. Timing is well defined. Write the spec so you get the same behavior as if you registered a resize on it and that's the same size as you'd get with snapshot
vmpstr: Good idea. Question is when do we snapshot. If you add size containment and change another style I guess you first process size containment and snapshot at that time?
smfr: I think you would use size from the most recent event loop steps where your resize observer would have fired and given an answer. Might be loop before a style change that effects containment
smfr: That's last thing you saw on screen
vmpstr: Makes sense
chrishtr: resizeObserver is when content-visbility content is unskipped, right?
vmpstr: On the contents of the element. On the element itself the observer would still fire
chrishtr: So a polyfill would put it on the element and when it fires set contain intrinsic size on that. And smfr proposal is do that without any script
vmpstr: Pretty much. I've seen a polyfill that does that. I'm not sure what to do with padding and margins.
chrishtr: ResizeObserver allow syou to observe different boxes
vmpstr: Then yeah
chrishtr: What if it was independent of content visibility. It restricts to the c-i-s property
vmpstr: Content visibility was motivation. Proposal is change to contain intrsintic-size to save off the value
chrishtr: Only do when size containment wasn't present
vmpstr: Right. And just snapshot at the time size containment starts being applied
chrishtr: So if size containment isn't present that size is automatically reflected into contain-intrincis-size used value
Rossen_: Hearing alignment on prop from smfr to align with resizeObserver. Are we happy with that and then will work on additional details in the issue?
Rossen_: Objections to align the behavior of auto sizing for size-containment with that of resizeObserver
Resolution: align the behavior of auto sizing for size-containment with that of resizeObserver
[css-contain-2] Proposal: content-visibility: hidden-matchable
github: https://
Rossen_: This issue can take a lot of time. Let's try to spend no more than 10 minutes on this.
jarhar: Hello everyone. Proposed content-visibility: hidden-matchable property. I added responses on GH to the questions from last time. Wanted to know if there are additional issues and if responses on GH suffice
fantasai: Once concern is if the control should be in css or in markup. Might be good to ask TAG about that.
fantasai: Other than that, main question is defining details of what operations can and can't trigger matching
<tantek> +1 to fantasai's concern, "matchability" feels like an expression of more semantically relevant content and thus may belong more in markup rather than in styling.
smfr: I think chris's last comment is a good summary of my discomfort. I think TAG feedback would be good. There are features in UAs that vary and this prop has impact on those features. TAG level discussion would be great
Rossen_: I'm scrolling through open issues. I see the match event open from jarhar. Is there another active one with TAG?
jarhar: I believe I do have a TAG review open.
<Rossen_> https://
jarhar: Issue #511 on TAG
Rossen_: I believe that's scheduled to discuss during TAG F2F in a couple weeks
chrishtr: and the concern from smfr has not been yet discussed in TAG correct?
jarhar: Not that I know of
Rossen_: We have this issue crosslinked to TAG review. As the review with TAG we'll have the CSS issue as well for more context
<tantek> agreed with the reader-mode and screenreader semantics concerns comments in the issue
Rossen_: What I'm hearing right now is a pause on this issue until we have TAG review
Rossen_: Then bring it back here
Rossen_: Also heard concerns from Sam. That's the summary. Is that fair?
chrishtr: smfr you said you have discomfort. I guess not swayed by our arguemnts. But if TAG doesn't think it's a big problem you're okay?
smfr: If TAG is okay I'm okay. For example I got pinged by devs about what are a11y for hidden-matchable. There is ambig around a11y and reader mode. Prefer to resolve but understand why it exists
chrishtr: It's potential for dev confusion?
smfr: Dev and user. They ctrl f in reader mode but spotlight doesn't find it and that's confusing
chrishtr: So we'll take it to TAG
<tantek> +1 smfr
chrishtr: Your comments, fantasai, are good to consider. We shoudl work that out once we have consensus on smfr's issue
<jensimmons> We definitely don't want to create new CSS where the a11y best-practice is confusing and unknown. There should be calrity.
<jensimmons> *clarity
Rossen_: Cool. With that let's move forward
[css-pseudo-4] Fine-tuning ::first-letter punctuation pattern matching
<tantek> +1 jensimmons. agreed that's a good general methodology
github: https://
fantasai: Problems riased in terms of matching ::first-letter. Example in an issue a " b". When we added ability to include whitespace we chose to include word spaces
fantasai: Problem is we aren't considering what's on other side of punct. If spec only used to separate makes sense, but not always. We're picking up punct that should be attached to word following. That's a problem.
fantasai: I think exclude word and no-break spaces on following side of letter. Maybe leading side but definitely following
Rossen_: Feedback on this one?
Rossen_: No feedback on it, I guess
<tantek> +1 reasoning makes sense
fantasai: Objections to makeing word and no break spaces not included?
jfkthame: No objection but thinking it should be same both before and after letter since that's less confusing. If they want a word space they need to use a different character no matter what
fantasai: Happy to exclude from both sides for consistency. word space isn't the correct character to use typographically anyway
Rossen_: Prop: Exclude word break and no break spaces on either side of the letter
Rossen_: Objections?
Resolution: Exclude word break and no break spaces on either side of the letter
fantasai: There are several classes of punct. One we don't want to include is opening punct after first letter. first-letter then { doens't make sense to include. In european lang there's spaces so it doens't matter much. For other lang there is no such thing and we're trying to get first letter. WE have opening punct class and that thosuld be excluded
fantasai: Two ambig classes that are common where I don't know how to handle cleanly. Least we can do is exclude the opening punct
Rossen_: Any feedback?
<tantek> +1 on excluding opening puncts
bradk: Sounds reasonable
fantasai: Similar case with dashes. Not quite sure the conventions for dash after first letter. I suspect we want to exclude on following side, but I'm not entirely familiar. On leading side long dashes mark quotations. Not sure on following. Inclenation is also exclude dashes from following punctuation
<bradk> I don’t have opinion about dashes
Rossen_: One resolution here?
fantasai: Sure
fantasai: Prop: Exclude dashes and opening punct (ps and pd in unicode) from following
Resolution: Exclude dashes and opening punctuation (ps and pd in unicode) from following
fantasai: I think that's if for now on this issue. Will need to come back, I think
[css-pseudo] ::first-letter should include currency
github: https://
Rossen_: Has a test case in it
fantasai: Prop is we include symbols along with letters and numbers when looking for first-letter
fantasai: Makes sense and we should do it. Otherwise if you start paragraph with a symbol there isn't a first-letter. Blink and WK do this
Rossen_: Any reasons why we shouldn't do it?
<tantek> should we include # also in case you start your paragraph with a hashtag?
<bradk> +1
Rossen_: Obj to inlcude symbols when looking for first-letter?
Resolution: include symbols when looking for first-letter
[css-pseudo] ::first-line and line-height
github: https://
fantasai: Is ::first-line about to effect root inline elemnt fragment. Then an issue about if line-height can be changed about first-line. Same question.
fantasai: Seems to me letter it effect makes sense. Prop: root inline fragment on the first line is inside the ::first-line and therefore is effected by changes in size
oriol: Clarify, it's not jsust being able to change line-height, but also set smaller then line-height in the block container or is block container the min value
Rossen_: Currently block container is the min and the prop here allow it to be smaller
oriol: Depends on impl. In FF block cotnainer is a min but in chromium you can reduce to smaller
Rossen_: Which are we prop to change to? chromium or FF?
oriol: I think fantasai proposed chromium
Rossen_: So ability to set sizes smaller than block container
Rossen_: Additional comments or feedback?
Resolution: Align with chromium behavior for ::first-line and line-height
[css-pseudo] Multi-line ::first-letter
github: https://
oriol: Problem is theoretically first-letter should be in first-line. If block container is narrow enough it can happen that first-letter will span multiple lines.
oriol: I had a proposal to try to define how this should behave.
oriol: Some parts to this proposal
oriol: First would be to standardize what FF, old Edge, and WK do which is that if you don't have a typographic letter unit then the first-letter is allowed to match the punct.
oriol: If you have both punct and letter you incldue both. If you don't it's allowed to only have punct.
oriol: Second would be if first-letter could span multi-line we restrict it to first-line so it can inherit.
oriol: Browser that does both parts of this proposal is FF
Rossen_: Feedback? Any reason why we shouldn't adopt FF behavior?
Rossen_: Objections to adopt the FF behavior which allows us to...want to make sure we have right resolution
fantasai: Summary: first-letter speduo element is closed at the end of the line even if the content that would otherwise be part of it is wrapped to the next line
<tantek> +1 that's a good summary fantasai
Rossen_: Objections?
Resolution: ::first-letter pseudo element is closed at the end of the line even if the content that would otherwise be part of it is wrapped to the next line
end
Rossen_: That's the end of the agenda. We can break 5 minutes early unless there's any other topics for discussion
Rossen_: Going once, going twice...let's get 5 minutes back
Rossen_: Thanks everyone, we'll chat next week