Spatial Navigation

<fantasai> Scribenick: fantasai

<florian> https://wicg.github.io/spatial-navigation/

florian: We initiated this spec in this working group. The suggestion back then was that this was a CSS topic, but not only a CSS topic, so we should try a more broad venue so went to WICG
... We've had a fair amount of feedback, but none of the ppl came from the WICG. Being in WICG didn't do anything useful for us.
... So in practice, didn't really help much
... But we've had different levels of review and different levels of enthusiasm
... Wrt impl, we're talking to Google and Vivaldi
... Google is positive, Vivaldi is quite excited about it
... Not quite ready for FPWD
... On the other hand, there is interest in the topic, and we want to keep moving on it
... And we think it'd be more comfortable to keep working in this WG rather than WICG
... There are many specs this needs to integrate with on the layout side and also things like overscroll-behavior
... Overall, this is not a CSS-only topic, but it is fairly integrated with CSS concerns
... So our request is to move back the ED to the CSSWG, with intent of doing the FPWD
... in the future

astearns: Comments or opinions?

krit: You are asking for an ED in W3C space?

florian: Yes, we have a draft in WICG , not sure what that's caled, but would like ot move that draft into this WG as an ED

astearns: Opinions from other browser vendors about suitability of the work?

<silence>

astearns: Given that we have some interest, and you have relatively good reviews...

TabAtkins: We're fine with this being in the CSSWG

astearns: proposal is to adopt this as an ED for the CSSWG
... Any objections?

<tantek> +1

RESOLUTION: Adopt spatial-navigation as CSSWG ED

florian: Other than that don't really have any specific issues to discuss today.
... If anyone wants to talk about this at TPAC, let's do breakout sessions

astearns: Any WICG issues open on the spec?

florian: A bunch, everyone welcome to look
... Also in addition to spec we have a polyfill, which we're trying to keep in sync
... Vivaldi has integrated the polyfll, if anyone wants to play with it I can provide a build

astearns: Part of the work of migrating to the WG would be moving all the comments

florian: I will move all the issues, but will not move the polyfill
... WG doesn't really keep polyfill code in this repo

iank_: Why not?

florian: We could, but CSSWG is not scoped ot maintain software. Also, if we move polyfill into w3c space we need to put it under a w3c license, currently it's MIT
... Having it in its own github repo makes it easier to integrate int npm or whatever

iank_: That sounds fine
... Just as long as the explainer is also kept

florian: We'll keep the explainer

astearns: What do we do for houdini code? Aren't there polyfills?

iank_: They're built by third parties
... There is example code in the repo, though

astearns: Example code for spatial navigation makes sense to keep if any

jihye: I hope that our spec can be worked on in CSSWG
... so I'm happy with this
... I think there will be some concerns that this spec is not all about CSS, so would like to hear if anyone has such an opinion

florian: Another significant aspect is integrated with focus
... so there is some integration on the HTML side as well
... But we won't stop listening to others of course
... Need to work with HTML, a11y, etc.

astearns: Might be worth sending out a notification prompting feedback / involvement from others

florian: I think that's it for this topic?

Fonts

drott: I raised this issue

<astearns> github: https://github.com/w3c/csswg-drafts/issues/3177

drott: It's about the local() value of font-face
... Used for uniquely identifying font on the local system
... Identifies one font
... Current description that it can only match the ??? name and the ??? name
... First want to expand it to Arial Bold Condensed
... We want the authors to have more success in actually matching the font
... Currently spec asks authors to add both names to the src descriptor
... So current proposal is to match both, help authors have more success in matching thefont
... Second part of the proposal is about which locale/language to match against
... Currently the spec says only match the US-en version first
... If this one cannot be found, then try to match the first one encoded in the font
... I find this aspect of the font rather arbitrary, and don't think we should be doing this
... I'm not so worried about conflicts here
... If any questions, be happy to answer those

heycam: Do we have any requirements on matching non-local font names?

drott: If you don't use the local() value, you do family style matching

heycam: But in terms of what the family name is matched against?

drott: family name matches against the family name
... Fonts have three name entries
... There's family name
... and then full font name
... and postcript name
... In regular font-family matching, you match that against the family prart

heycam: Is it true that some implementations match the postcript name for font-family?

drott: I believe so
... But the matching is not so sharp for family
... You leave it to the matching algorithm to find the closest font to what you specified
... But for local() you have to match exactly, that's the intent

myles_: I think both of these are good for the web platform, I just dont' know how to actually implement them.
... If someone knows how, that'd be great, happy to do it.

drott: Maybe don't specify as a MUST
... But I think we should remove the current specification that says english first, otherwise physically-first entry in the name table which seems pretty random
... I think Firefox implements this on all platforms
... Windows has DirectWrite API
... Fixing in Chromium, I also did this on LInux and Android so far
... Maybe not with CoreText, but iI think we can find a language that would allow implementations to do this

astearns: Is your suggestion to keep English first, but allow other matching, or drop any mention of English?

drott: I would prefer to match any

astearns: Do you have any particular spec language or just looking for agreement to go in this direction?

drott: don't have spec language ready, but agreement to go in that direction would be OK

astearns: so proposed resolution is to loosen font name atching requirements and allow more matching than is curretnly allowed

drott: Specifically to match both font names, and secondly to match against all languages

dbaron: Allow or require?

astearns: For the first part, full name and postcript name, would that be allowed or required?

drott: Required
... But for second part, locale-matching, would allow. not sure there's consensus to require

dbaron: My concern is that we'll end up in situations where impls do diferent things
... I'm more comfortable going with a requirement either way than to do MAY
... What we'll end up with there is someone haveing a web-compat problem and have to go fix it
... If that impl can't implement it, then we have a bigger problem

myles_: Agreed
... Part of this issue for me is relying on API that isn't clear what it's doing

drott: I see your point
... I would prefer a requirement as well
... Would be hopeful we can spec that
... Otherwise just widening allowances makes sense to me

dbaron: Maybe give Myles a chance to see what CoreText can do?
... We should care what platform APIs offer when we spec these things

myles_: Is CoreText the only API that's concerning here?

drott: I looked at FontConfig and DirectWrite and on Android looked at APIs
... On fontconfig and directwrite it's no problem

<dbaron> I don't know... jfkthame would probably be the person to ask for Mozilla expertise

drott: On Android I implemented an indexing method, so possible but might require own indexing

myles_: I would like to not parse font files myself

astearns: So I guess the proposed resolution is to find better/more ways to match fonts
... and try to make requirements a MUST
... but we don't have spec language for this

<gregwhitworth> fantasai: I agree with dbaron we need to see if myles_ can implement it

drott: Can we split the resolution? Can we match full name + postscript name

myles_: it's OK

astearns: So proposed to match on full font name and postscript name (MUST)
... Any objections?

RESOLUTION: local() matches against both full font name and postscript name

RESOLUTION: Investigate whether it's practical to implement multi-locale name matching

astearns: Might also want to ask the i18nwg if they have any input on this

<heycam> fantasai: to what extent are there fonts that have one localization plus english, and someone else has a different localization plus english?

<heycam> fantasai: let's say you have a font that's released in Japan and France, and the French version has English and French names, not Japanese names

<heycam> ... and the Japanese versoin has Japanese name and English name, but not a French name

<heycam> ... I think it was there to handle situations like this

<heycam> ... if you force the author to use the English name it could work in more place

<heycam> ... it's possible this is not why it's there

<heycam> myles_: I've never heard of a font author doing that. usually they just make a font in a particular set of languages

<heycam> fantasai: just want to check if this has historically happened in the past

Shadow parts

astearns: Let's ask rniwa if he can show up at 10:30 after the break?

Trying to find a Tpic

Overscroll Behavior

majidvp: I'd like to move overscroll behavior to FPWD
... Spec was in WICG
... we moved it to CSSWG a couple months ago
... Last we spoke resolution was to move to CSSWG and get an editor
... I agreed to become backup editor
... I am happy to be the editor
... It's a small specification, right now there's maybe two issues filed against it whihc should be small changes
... Next step is FPWD

fantasai: If previous editor doesn't want to join CSSWG, what happens to IP?

TabAtkins: I thought this was written by a googler?

majidvp: He's from FB

astearns: He's from FB, and FB is a member of W3C but not member of CSSWG
... But I understand that commitments made by developing in WICG are sufficient

majidvp: I think that's correct. I think he just didn't want to commit the time necessary to be the editor

dbaron: Was it published as a CG report by the WICG?

majidvp: I do not believe so

dbaron: It's possible that makes a difference here
... I think when reports are published companies can choose to make patent commitments on those reports

TabAtkins: I think WICG has something more extnesive than standard CG, but not sure of details

florian: What I remember is that when you submit to a CG you commit your own IP, and when you publish a report then other members can commit what they didn't contribute themselves

TabAtkins: FPWD triggers patent exclusion for this WG
... If benoit already contributed his IP as part of WICG, that covers us from FB's angle, right?
... Publishing here would trigger patent exclusion for CSSWG members

fantasai: So FB is not a member of the CSSWG, but the concern for them is not that they don't want to commit IP but that the editor doesn't want to spend time on it?

astearns: I've been alkign to benoit and their AC rep, as far as I understand their only concern is time
... I could maybe ask AC rep to join WG just from a patent commitment

fantasai: I think that would be a good idea

florian: They already committed what htey contributed

fantasai: Yeah , but if we end up with IP that they didn't directly contribute but own anyway, it helps us here.

florian: Yeah, can't hurt an dmight be good

fantasai: Wanted to ask if there was any issue wrt API design wrt writing-modes or fragmentation

majidvp: We just have an issue on adding logical longhands, issue 2473

<majidvp> https://github.com/w3c/csswg-drafts/issues/2473

fantasai: I would suggest let's fix that first before we publish

<smfr> +1

astearns: FPWD?

<franremy> +1

<dbaron> +1

astearns: Let's have that issue addressed, and I'll see what I can find out about IPR commitments today

<majidvp> +1

astearns: And maybe we can resolve on FPWD at the next telecon

Aspect Ratio

jensimmons: There's been a longstanding desire for aspect ratio support in CSS
... Brought up not only because I brought it up, but many people around the worl dhave been writing blog posts talking about this
... So fantasai drafted up some spec text last week
... Here's an example
... People are resizing their images in CSS, and width is being set to 100% and height to auto, and the image keeps its aspect ratio
... But some elements do not have an intrinsic aspect ratio
... e.g. iframe, article, tec.
... Some are replaced elements, some are not, but they odn't have intinsic aspect ratio so things get squished
... Why are people not using the video element?
... THey're using youtube, vimeo, etc.
... because of adaptive bitrate streaming
... but it's a reality that's very important for supporting varyious netowrk connections
... so videos in iframes are important
... Here's what happens when you try to resize the iframe: no preservation of the aspect ratio
... First solutionof the industry was fitvids.js
... It's not a great idea
... Everything since has been using the padding hack
... Using the fact that pading in % is going off the width rather than the hack, and ppl exploiting that to get aspect ratio
... Only some ppl know about it, it's tricky to use..
... Would be much better to have something in CSS to solve this
... Our current thoguht is to use a property, 'aspect-ratio: 16 / 9' e.g.
... This would cause the element to hook into all the existing rules that handle elements with an asepct ratio
... This is written up as a super rough draft in CSS sizing L4

<astearns> https://drafts.csswg.org/css-sizing-4/#ratios

https://drafts.csswg.org/css-sizing-4/#ratios

jensimmons: Videos would be done like
... iframe { aspect-ratio: 16/9; width: 100%; height: auto; }
... Syntax of the property is coming from the Media Query syntax for aspect-ratio
... Idea was just to copy that syntax
... for consistency and also I like that
... SO that's great, solve things like video in iframj
... But there are also other cases where we care about aspect ratios
... Let's say you want a bunch of squares with text in them
... In this example I used viewport units, but it would be nice to be able to just give an intrinsic aspect ratio
... Here's a use case
... We have boxes with different amounts of content in them, and we want them to have 2:1 aspect ratio
... Problem here is that in some cases there's too much text, and it oveflows!
... Want to be able to say that "I want this aspect ratio as my min-height, if the box get bigger let it grow like usual"
... Two options in the raft
... Option A is to have a keyword of some kind which you can put in min-height to request from-ratio, and then say that the height is max-content
... article { aspect-ratio: 2 / 1; height: max-content; min-height: from-ratio; }
... Other possibility is to use 'ar' units, which come from grid L2 spec
... I would change the name, don't think 'ar' is the right name
... But basically it grabs the number of the corresponding property in the opposite dimension and multiplies it
... e.g. we ahve gaps in one side, the other side says 2ar, it'll be twice the width of the other-dimension gap
... So we could use those in the height properties, e.g. 'min-height: 0.5ar'
... Going further, it'd be great if we could use attr() to grab the width/height attributes from the HTML and put it into the aspect-ratio
... This would solve a performance problem everyone wants to solve, to do layout before the image loads
... There's been a variety of proposals for adding new attributes to do this, but we could just use it with CSS by using attr

<TabAtkins> https://github.com/ojanvafai/intrinsicsize-attribute for the HTML-based way to set intrinsic sizes/ratio before loading them.

jensimmons: e.g. iframe { aspect-ratio: attr(width px) / attr(height px); }

<TabAtkins> Still an early proposal, could use some feedback from us.

gregwhitworth: I'm excited about this topic
... Prefer the aspect-ratio syntax from MQ

<TabAtkins> (I've given some feedback, I think it's pretty decent.)

gregwhitworth: We also did talk about aspect ratio in picture elements

<tantek> +1 I'm excited to see aspect ratio solved

gregwhitworth: I think we'd like an HTML solution because we want to do it earlier
... but of course also in CSS too
... Interested in the other stuff
... We have a WICG thread under ? for asect ratio that has additiona issues to think about that we should think about

<TabAtkins> (Ojan's proposal is *just* about setting intrinsic sizes of replaced elements that *already have* aspect-ratio information. Not directly intersecting with the 'aspect-ratio' property.)

<florian> fantasai: in terms of adding attributes to HTML, we were looking at this, and thinking we can just do that using the height and with attribute

<florian> fantasai: currently, they link to the width and height property, so you loose them when you set the css properties

<florian> fantasai: but we could change that, to make them also plug into the aspect-ratio property

<florian> fantasai: so if you set them in css, you'd override the width/height, but not the ratio

<florian> fantasai: we might be be able to do that in a web compatible thing

<florian> fantasai: so before we add more to HTML, we should look into whether we can do that mappinng in the CSS layer

glazou: I really like that
... Two things I'd like to know
... First, when we have for some elements a placeholder to display until the element isloaded from the network, we are going to have a cahnge of aspect ratio
... So it would be good to detect that the aspect ratio is changing from some external source like the network
... About your a) nand b) rpoposals for the limits
... from-ratio won't allow partial value sunless you allow into calc(), so I would prefer th eunit

<TabAtkins> (The point of doing *some* aspect-ratio things in HTML is, as Greg suggested, to be even more preloader friendly.)

futhark: For the min-height problem, try min-max aspect ratio

fantasai: We thought about it, but though tthis was mroe stragithforward and easier to understand
... what's a min-aspect ratio? would ahve to privilege one dimension over the other

gregwhitworth: ....

astearns: Might want to limit current discussion to concerns about whethe rto add to the draft

florian: based on what you said, I'm happy to move this forward

<dbaron> I think I prefer option A over B, for being clearer, and I think we should eventually get from-ratio into calc()

fremy: I would say that from-ratio seems way easier to implement
... ???
... Among the two solutions, an implementatio nperspective from-ratio is way easier
... That's all, not opposed to the unit

fantasai: Note that this unit exists already for gaps, we're just copying that solution here

krit: Shoudl look at preserveAspectRatio attribute

florian: I think parallel between preserveAsepctRatio is with the 'object-fit' property in CSS
... Some aspects of viewbox correspond to this
... My first impression is that even if we add as properties the things that SVG already has
... These things an this, have a shorthand-longhand relatioship, so there's no conflict
... We need to think through it but there's no conflict

jensimmons: If you look at issue 333, I've dropped links to authors writeups on aspect ratios
... So we need to go through all that and make sure we've thought about those comments and ideas

astearns: What about SVG?

jensimmons: Sara Soueidan wrote up a blog post on viewport in CSS

TabAtkins: I am in favor of doing this
... I want to put it WICG

florian: Let's incubate in the CSSWG like we always do

astearns: I'm going to close the discussion at this point.
... It's break time

https://www.w3.org/TR/2018/WD-css-grid-2-20180804/#alignment

ar units ^

<astearns> FYI: Chris and Lea are out at a hospital today, Lea's health took a turn for the worse yesterday evening.

<myles_> ScribeNick: myles_

::people fuss with the AV setup::

<TabAtkins> https://drafts.csswg.org/css-shadow-parts/

TabAtkins: we discussed shadow parts in the past, fergal_daly worked closely with rniwa to figure out hwo we can get a consensus solution on some details. It went well, made amny changes and feedback. Notable: we separated the naming of something as a part from forwarding something's parts up into your part namespace. They're now separate attributes. Chagned syntax of part forwarding to match JS syntax for desctructuring because it's the same. While it's

easy to get confused about whch name does what in JS destructuring, \people only have to learn it once. wen're not exposing ssomethign new and novel. Functionality is the same - can expose chunks of shadow dom

can't do further structuring, can't grab a part of a part, unless it's exlicitly forwarded, can do ::before and ::after

and other pseudoclasses

there are still some discussion about theme

the thing that automatically exposes your parts arbitrarily up so they can be used from anywhere. further discussion is ongoing but the core part, the part pseudo element and how to expose it appears to be reasonably agreed on by us and apple

<astearns> github: https://github.com/w3c/csswg-drafts/issues/2368

rniwa: there is consensus on the github issue. the 1 contentious part is the IDL attribute. for now we can add itand move foward. one question is because the topic of whether par tapplies to jsut hte first elemtn or everything? For theme, clearly allt he elements with the theme should ge tthe style, not jsut the first one. so the discrepancy there might be confusing. but on tehother hand, the use cases are different it may be okay that only the first elmetn

gets the first the styl

TabAtkins: so it's treated like an ID?

rniwa: it's a question. Let's say shadow root has 2 elements that have a part attribute, boht say part=foo. Sholud both get the style? If the model is users are exposing an element to to outside to style, then it should be just one element. but if hte model is more like the users define style for a part and the compoent takes it form the users and apply somewhere, then it akes more sense for multiple elements

TabAtkins: imagine a to do app. you want to expose for styling all of the indiviaul to do items. You can give them the same part naem and style them all, it works like a class. If you can only do one, each item would need a unique name.

emilio: that's better. I prefer to style the style of elements to be independent
... invalidation could be tricky. When you insert an element with a part element, you have to look for hte same part naem elsewhere in the tree

rniwa: that's fine.
... it's just a question. i dont' know the answer.

TabAtkins: the goal of the session is to confirm we hav rough agreement on the feature set. earlier there were more disagreement. so i don't think we're ready for FPWD now but we can adopt as official ED.

astearns: i dont' remember if its an EN

TabAtkins: it's marked as an ED>
... so we're pretty good. comments?
... please raise issues.

astearns: i suggest - the issue is a monster issue with many sub issues. if there's anything remaining, please move it to new issues. It's impossible to read.

TabAtkins: ok.
... we did already

fergal_daly: please use existin issues

astearns: sometimes TabAtkins will move comments for people

fergal_daly: i'll do that then.

fantasai: what are you looking for before FPWD?
... FPWD doesn't mean it's done. it' means it's rough
... and we have consensus on the approach, but not details. We don't have to fix the issues

TabAtkins: it coule be reasonable to do FPWD

fantasai: if there are no major issues before FPWD and we all agree we want to do it, we should do FPWD
... and continue work with more visibly public draft

fergal_daly: should we take theme out if we haven't decided on it?

TabAtkins: i'd be okay.

rniwa: it makes sense. we need to update the spec. the ED is outdated.
... remove the theme and the IDL attributes

fergal_daly: IDL is already out.

TabAtkins: yes.
... right nwo the only way to access parts is to ge tthe attrigbute using the standard dom api

fergal_daly: is there controversary for adding IDL for part as opposed to part fowarding? That's useful for feature detection

rniwa: no controversy. It's okay to epxose part IDL attribute.

fergal_daly: okay i'll do that.
... and leave otu the map stuff completely

TabAtkins: it might be worthwhile to officially do FPWD in a few weeks.

astearns: yes, i'd liek to see people sign off on the state of the draft before FPWD

TabAtkins: ok

fantasai: for extracting out the stuff we're not doing now, maybe throw that into Level 2

TabAtkins: ok
... we can incubte the theme attribute.

astearns: other comments?

rniwa: mozilla support?

emilio: it's reasonable
... when peopel askfor feedbakc, the conclusion iwas it's worht experiementing. the current agreed on thing makes sense

astearns: Edge signals?

TabAtkins: Edge just agreed to do shadow dom, so we'll see you in 6 months

astearns: next topic: i18n

<gregwhitworth> I said that we'll take a look at the proposal and provide feedback at a later date

::people cast around for short topics while we wait for i18n::

jensimmons: there is an issue for renaming the AR unit
... it's in grid level 2

Renaming ar unit

<fantasai> github: https://github.com/w3c/csswg-drafts/issues/3225

jensimmons: it's in grid level 2, mostly subgrid. THe use cases is if you're defining grid gap, and other gaps, and it's in one direction and you want it in the other direction to be an increment of the one in the first direciton, this unit lets you have a mulitplier for the other diemsnion. It's similar liek aspect ratios. i drilled aspect ratio math into my cells in my body in film, there's a way in those industries handle that math, the phrase aspect

ratio triggers that mathematical model for those people. So another name might be great

florian: the confusion by calling it aspect ratio, once we have the aspect ratio property, if the property says half and you say 2x half, what does that mean

jensimmons: what does "twice 16x9" mean
... with this measurement unit, you use the inverse fraction when you want to go the other direction, and there's no such thhing in aspect ratio math

florian: idea: transfer ratio, transfer dimesion. we're taking a measurement from somewhere and applying it somewhere else.

rachelandrew: i liek transfer size
... it's descriptive

florian: 0.5ts is hafl the transfer size?

fantasai: since it's a proportion, we have fr, so tr?
... other suggestions?
... rename ar to tr?

florian: i liek it better than ar, so let's resolve and make progress, but we may continue discussing later, but it's an improvement

jensimmons: i don't know if i'm convinced about the r because it's a ratio

florian: the "r" is for "tr" for TRansfer

<jensimmons> s/it’s a ratio/it’s not a ratio

fantasai: fr could be FRaction

astearns: is a design constraint that all units are 1 or 2 letters

fantasai: it's easier to type
... 7 letters is annoying

astearns: yes

glazou: is an aspect ratio always above 1?

fantasai: no

glazou: is 16/9 different than 9/16?

fantasai: no

glazou: is a AR always above 1?

florian: the convention is 16/9

fantasai: resolved??????

astearns: feelings?

<jensimmons> well, there are many conventions in the film & video industries — many way aspect ratios can be defined.

heycam: is transfer a term of art?
... it doesn't have a meaning in my mind

<jensimmons> 1.77 = 16x9 = 16:9

fantasai: there's a transfer size in hadnlign aspect ratios and other things. it's not exposed as. term but it is used

ericwilligers: why not fr?

fantasai: A) you often have multipe fr units in the same dimensions and they take up segments of a total. 2) this could be used in grid track listings, where fr has a different meaning

TabAtkins: it means "Fraction fo free space" which is a totally different hting.

fantasai: it's not a generic ratio

<Zakim> edent, you wanted to mention "Is there any user research on what people use? Or what they want?"

edent: is there any user research on what peopel use when they refer to this?

jensimmons: yes, we haven't come across anythign yet. in the film and video industyr, this doesn't come up. they dont' have this concept. So we're raising it to the group. Does anyone else know other parallel world wher ethis exists? I will keep asking. Maybe font people?

<heycam> 0.5or (for _or_thogonal dimension's value)

florian: we aren't convinced that it's the best name, but i didn't hear disagreement that tr is better than ar

astearns: ok
... objections?

<tantek> see for example the iOS Photos app which shows a menu for editing aspect ratio based cropping with original | square | 3:2 | 5:3 | 4:3 | 5:4 | 7:5 | 16:9

astearns: RESOLVED: Rename AR to TR

<tantek> re: edent question about user research

<emilio> ScribeNick: emilio

RESOLUTION: Rename AR to TR

Adding lang as a font-face descriptor

Github: https://github.com/w3c/csswg-drafts/issues/1744

myles_: This issue is about the desire of making a font only used by elements that are on a particular language
... So that each element with a particular language gets the right font attached to it
... My particular feeling is that this is the latest step in a long sequence of changes to add more styling capabilities to @font-face
... selectors already do that, in font-face we already have a bunch of other descriptor, and this moves into the model of adding more styling to font-face
... I don't want to implement all of CSS in @font-face, there are examples on the issue on how to do it using style rules

<gregwhitworth> +1 to myles_

addison: If you were to put this in there's a bunch of interesting problems you need to specify, like how the lang tags match and stuff
... ???
... If you name a language for a font-face, you don't render it anywhere else? How do you enforce that?

emilio: Isn't there a `:lang` selector you could use for that?

drott: that's the example of the issue, yeah
... I share myles_' concerns and conflicting semantics between `:lang` an this
... I think the intent is using the font in a more finegrained way than unicode-range and such, and I think the example also covers this, you can use css variables to use it as the same font, but not sure if I missed any part of the use case

addison: I think the idea is to affect how font-fallback works.
... that's pretty common for CJK

myles_: we already have facilities to do this with CSS

astearns: looks like preference is to use existing mechanisms for that, and not use descriptors, we should put the minutes in the issue and let people comment

florian: does a note / suggestion in the spec about how to solve this problem seem useful?

astearns: we should probably wait for more info from the proposers here

r12a: While seeking further info, one thing to ask is how would you treat with multiple languages for a single font

astearns: can that be handled by selectors?

nods

[css-logical] Flow-relative syntax for `margin`-like shorthands

Flow-relative syntax for 'margin'-like shorthands

Github: https://github.com/w3c/csswg-drafts/issues/1282

fantasai: currently css assign values in shorthands to the physical longhands
... it seems useful to make logical shorthands similarly convenient, which is useful for i18n
... but we don't have a proposal for which kind of syntax we want to have for this
... one's relative keyword, other is a bang keyword, others is a different property

<astearns> !no

fantasai: one of the main restrictions is try to keep it sufficiently easy to type

<dbaron> I would be pretty strongly against a ! syntax for something that's part of the property (i.e., not changing cascading).

fantasai: nothing on the thread seems to have stuck
... can we come up with some idea?
... other proposals were like global mode switchs, etc...
... we could do some or multiple
... [enumerates other solutions from the thread]

addison: one of the challenges is when you go to make a rtl page layout you need to edit your stylesheet to flip your margins, ideally it'd be default

TabAtkins: Something in the value space is maybe the best, like keywords
... I'd be against punctuation, no precedent and hard to google, plus not compatible with CSSOM
... similarly for the bang
... nor mode switches, dbaron argued against it, serialization is also harder that way

fantasai: typing relative is too long

<dbaron> +1 to tab saying it should be in the regular value space

myles_: Will the bang keyword be applicable on every property

*?

fantasai: only to some

<astearns> +1 to dbaron's +1 on regular value space

myles_: so part of the grammar of the specific properties, right?

fantasai: yes

myles_: it'd be cool if it works with variables

fantasai: that'd be terrifying

TabAtkins: you should be able to drop a whole relative margin value in a variable

<TabAtkins> TabAtkins: And you *cannot* put bang values into variables.

<myles_> emilio: expanding shorthand into mulitple lonahands dpeending on syntax, like overflow, is not something that any othe rproperty has righ tnow. So it's goig to require specifying how yous erialize when you have all of th e8 logical and physical margins. IF you want the solution that peoplw ill implement fast, the best option is different properties. Then, all the machinery is there already.

<myles_> fantasai: how do we come up with a systematic way of coming up with a new property that is consistent, short, easy

<myles_> emilio: yes

<myles_> TabAtkins: we do "margin-se"

<myles_> emilio: or "logical-margin"

<myles_> fantasai: it's way too long. some peopl will put all of their stylesheets all of the time, and will stop using physical properties. It needs to be ergonomic enough that it's possible

<dbaron> 'margins', 'paddings' :-P

<myles_> florian: will we push back against tab here about puctuation? ~padding ~margin?

<jensimmons> it might be faster to implement, but if we hate the choice 10 years from now, it’s not a good idea

<myles_> TabAtkins: if its property names, my objection is different. The only thing is that would not be an ident anymore.

<myles_> florian: can we fix it?

<myles_> TabAtkins: potentially but its a syntax change. It would be better for it to fit kn the syntax.

<myles_> florian: if somebody is using a property that uses idents, this would break.

<myles_> TabAtkins: we try to not change syntax

<myles_> florian: this may warrant an exception

<myles_> TabAtkins: yes. I think we can come up with a prefix in alphabumeric that's short

astearns: do we have anything more on that?

r12a: I agree with that fantasai and TabAtkins that it needs to be easy to type, I'd suggest `lmargin`

<myles_> +1 to not using "relative"

r12a: I think `logical` is a much better word than `relative`

<cbiesinger> +1 for not using relative

iank_: Any of the bang syntax will probably have very funky interactions with CSSOM

<TabAtkins> I think `l` as a prefix works okay. I think we can reasonably prefix any word with that.

iank_: setProperty has a different argument for `!important` and such

<fantasai> I don't like prefixing with alphanumeric because it's less obvious what's going on and it won't sort correctly.

<TabAtkins> *post*fixing with `l`?

<fantasai> we use prefixes for the real name of the property, and prefix relationships are about shorthands

<fantasai> postfixing makes it look like a different longhand of the physical shorthand

dbaron: So I think we all don't like the various bang things. I guess I'm not 100% convinced we want different property names, I think having it in the value would be slightly nicer even if we need to sort out a bunch of CSSOM issues, though it might depend on whether we find appropriate names for the properties
... different properties is probably faster

jensimmons: some of the things suggested where the good syntax is the old thing that nobody uses 10 years from now
... so even if might be more efficient or easier to implement we should peek a name that is a good name

heycam: I feel like all of the syntax proposed so far is going to be a bit different and awkward, so I'm not sure the goal of finding a clean word is feasible

jensimmons: I think lmargin is a bit more awkward than relative on the value

<dbaron> I guess another option is using a delimiter within the 'margin' value like 1em / 2em / 3em / 4em.

jensimmons: Some of them feels smoother than others

fantasai: can you give us your opinion on the different proposal?

jensimmons: I think -new is better than a new name, and keyword is better than a bang, but I can look at the list as we goo
... how does it look in 10 years is something to look into

<TabAtkins> schmlinss

<myles_> jensimmons: sticking a random letter in front of iframe hasn't seemed to hinder its adoption, it seems most people colloquially speak of iframes instead of frames

fantasai: prefixing breaks the sort order, margin-something feels like a longhand analogous to margin-left or such

<jensimmons> iMargin? lol

fantasai: I'm a little skeptical about prefixing / suffixing has the issue of making it relate to properties it doesn't relate to

*seem to relate

<TabAtkins> Allowed postfix punctuators in ident syntax: - or _ ^_^

<TabAtkins> margin-, margin_

<myles_> margin: ➡️

cbiesinger: I think lmargin and such are a huge concern, we have some other messy margin

majidvp: I think mode switch is the easiest. Is the concern about serialization really a problem? When do you have the problem?

<jensimmons> imargin = international margin

<cbiesinger> @mode "logical"; at the top?

<fantasai> cbiesinger, yes that's one option

florian: we have some of that problem with box-sizing and such

<fantasai> cbiesinger, the other is a block like @media

<cbiesinger> block seems worse to me

<fantasai> cbiesinger, yeah I agree

dbaron: I think we consider box-sizing a design mistake

<fantasai> cbiesinger, if we have a mode swbox-sizingch we might want to have a way to put a specific declaration into the other mode, though

r12a: dbaron proposed separators instead, maybe we should consider that?

<cbiesinger> fantasai, maybe but your escape hatch is margin-left

rachelandrew: From the POV of teaching this a keyword means that you can look at your code and know what I'm using here, seems to infer the intent best

dbaron: I suggested using separators, assuming we do want to move everyone to that, so that you can do something like `margin: 1em / 2em / 3em / 4em`
... It's somewhat obscure so it makes the distinction less obvious, but if it becomes the way to do it it may not be a problem/

<jensimmons> What Rachel just said makes me think that `margin: 10px 5px 15px 25px relative;` is more of a “equal” to `margin` today… changing to a different property infers that it’s a different thing

fantasai: we use slashes on some places already, so not sure we could switch everyhwere

dbaron: it doesn't need to be a slash, there are probably a number of those we haven't used yet

<cbiesinger> +1 for dbaron's suggestion

dbaron: the other reason it sort of makes sense to me is that the delimiter indicates a different relationship between the different values

<jensimmons> also, should we go the other way — to match Grid — …. ???? Crazy. but also....

myles_: looks like if you don't use slashes code work and it'd look just wrong in RTL

<fantasai> yes, jensimmons, we will go the other way to match Grid

TabAtkins: Since the direction is different it at least sometimes will look wrong

<fantasai> Grid is using the direction we picked out for logical 4-value syntaxes in general, we just never solved this particular syntax issue to have them :)

r12a: So you still have to deal with serialization and such

dbaron: yeah, that was emilio's concern, we need to solve that if we handle margins

<fantasai> It's interesting to note that the grid-area shorthand already uses slashes (and is logical)

emilio: You also need to handle compressing and serializing when you specify all the 8 margins

dbaron: you could condense those to two occurences to the margin shorthand, but it's a bunch of CSSOM work

<rachelandrew> there is an example of individual properties here for padding: https://codepen.io/rachelandrew/pen/OQrorW

dbaron: that's the 'this will take longer to get done'

<rachelandrew> from https://www.smashingmagazine.com/2018/03/understanding-logical-properties-values/

emilio: note that you also need to figure out how that interacts with the other sub-shorthands like margin-block / margin-inline

TabAtkins: yeah I think finding something using property names would be maybe the better idea

fantasai: I think you still need a switch to change to physical in specific cases, and whatever solution we choose needs to be workable for that

<fantasai> myles_: Mode switch at the top of the file, many CSS authors don't know CSS that well and just copy-paste, so mode switches would end up being problematic for them

myles_: It's harder for authors to understand mode-switches, and they'll just get it wrong

<fantasai> Bert: Said earlier that it might be a problem if margin expands to different properties based on whether there's a keyword or not. Is that true? Wouldn't it expand to all of them all the time.

fantasai: thanks, I had missed it :-)

<fantasai> florian: Depending on the values, they are propagated to different values, but always expand out to the same set of longhands (all of them)

<fantasai> dbaron: At the specified value it is, but at the computed value level, the two sets of properties compute the same values

<fantasai> dbaron: The way we've added logical properties, they are distinct properties at the specified value level nd they both exist in the object model

<fantasai> Bert: If you set margin-start, it goes to margin-start

<fantasai> Bert: If you set 'margin, does it also set margin-start or only go to margin-top

<fantasai> dbaron: We're rying to find a syntax that sets the margin-start property

<fantasai> Bert: Is it necessary?

<fantasai> florian: ...

<fantasai> florian: We don't have a logical shorthand. If we want logical to be the default way to write style sheets, we need that.

<fantasai> astearns: Short answer is no the shrothand doesn't expand to all 8

<fantasai> dbaron: Having the shorthand somehow set margin-top so that it sets the logical thing, could be doable, but would have some very confusing results

<fantasai> florian: I didn't understnad that

<fantasai> Bert: Problem is that the 'margin' property doesn't reset the logical margins. Can that be changed?

<fantasai> Bert: Like font resets font-size-adjust even tough it's not mentioned

<fantasai> fremy: I'm not sure why it doesn't set

<fantasai> fremy: These values would never be used

<fantasai> fremy: It doesn't matter if margin resets them or doesn't

<fantasai> fremy: If the orde rin which you reset them is such that you have the logical ones after the other ones its fine.

<fantasai> dbaron: That would be one solution to part of the object model issues.

<fantasai> dbaron: others around serialization

<fantasai> fremy: Somewhere we have to find principles of doing this, and need algorithm for this

<fantasai> fremy: I ddin't find it yet

<fantasai> dbaron: Might be in a GH issue somewhere

<fantasai> dbaron: probably don't want to dig too far into CSSOM issues right now

<fantasai> astearns: This was a good background on all solutions we could consider, but doesn't sound like we'll resolve today

<fantasai> TabAtkins: Sounds like we're interested in a declaration-based syntax

<TabAtkins> More specific than declaration-level. Property-name or value-level. (So not declaration glyphs, or ! values, etc.)

<florian> fantasai: I think whether or not we need a mode switch, we will have a syntax ???

<myles_> "use logical;"

<myles_> (instead of "use strict")

lol

<florian> fantasai: whether the shorthand resets 4 or 8 of the longhands is actually still an open issue

.

<fantasai> fremy, were you thinking of https://github.com/w3c/csswg-drafts/issues/3030?

<astearns> cbiesinger: 1:10 or so?

Environment Variables

<fantasai> Rossen: This was mostly a status question

<fantasai> Rossen: Where are we, why not FPWD?

<fantasai> Rossen: We have ppl shipping some of it so what is happening

<fantasai> TabAtkins: Quick bit of history, environment variables spec is something I put together after dino put together a PR on variables and then didn't respond to feedback

<fantasai> TabAtkins: If Safari is shipping, need a spec asap

<fantasai> TabAtkins: We've been thinking of shipping as well since then, so our implementers brought up more issues

<fantasai> TabAtkins: We have a lot of issues here

<fantasai> TabAtkins: I haven't been working on this lately, probably why not FPWD

<fantasai> TabAtkins: If we want to fast track I can prioritize

<fantasai> Rossen: Anything blocking FPWD?

<fantasai> TabAtkins: There's one important issue to resolve on

<fantasai> TabAtkins: List of variables must be vetted

<astearns> https://drafts.csswg.org/css-env-1/

<bkardell_> https://drafts.csswg.org/css-env-1/

<fantasai> Rossen: It's a pretty short list

<fantasai> TabAtkins: I think Safari is shipping additional variables beyond that set, is this true?

<fantasai> smfr: probably?

<astearns> https://github.com/w3c/csswg-drafts/labels/css-env-1

<fantasai> TabAtkins: Big feature to add is user-defined variables, but doesn't need to block FPWD

<fantasai> Rossen: What is overall thinking about this?

<fantasai> Rossen: Will enable variables supported by platform

<fantasai> Rossen: How do we see such a spec getting to a stable version?

<fantasai> Rossen: That list of variables will increase

<florian> fantasai: I have an answer

<florian> fantasai: we had decided that any variable that gets added needs to go through the standards process

<florian> fantasai: it's not just a registry about that list things, we need to define behavior as well

<florian> fantasai: so the regular process is appropriate

<myles_> https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/dom/ConstantPropertyMap.cpp#L53

<fantasai> TabAtkins: On that note, issue 2820 is specifically about if you are producing additional variables

<fantasai> TabAtkins: Need to put a MUST NOT ship non-standard variables into the spec

<fantasai> smfr: We feel the need for an extension point where we can put things that we don't think should be standardized because they're only applicable to our platform

<fantasai> smfr: Custom apple things that are exposed in CSS

<fantasai> smfr: Like Apple system fonts

<fantasai> smfr: webkit named image

<fantasai> smfr: special appearance for apple pay buttons

<fantasai> smfr: special color filter for doing inverted color messages

<fantasai> smfr: system colors we expose

<fantasai> smfr: these are all -apple-prefixed

<fantasai> smfr: Then some that are fullscreen

<fantasai> smfr: So I feel we need an exension point that we can add new stuff that's vendor-specific

<florian> fantasai: if it is going to be exposed to the web, then it should not be specific to safari

<fantasai> Rossen: It could be specific to that particular platform

<fantasai> Rossen: So something available to Mac or Linux not available to Windows

<fantasai> florian: Inverting screen colors is not apple-specific, not iOS specific, not Safari-specific

<fantasai> florian: Having a pay button

<fantasai> florian: Many things you listed in their current form are apple-specific, but

<fantasai> florian: Many should be done in a vendor neutral way

<fantasai> florian: e.g. should be able to have a pay button in Chrome as well as Safarai

<fantasai> fantasai: We want people to design for the web platform, not to a particular browser on a particular platform

<fantasai> smfr: We have a fancy recipe for a backdrop filter that Apple designed for its content, and expose to people who want to use it to look like Apple

<fantasai> florian: If something needs to works on all browsers, it should not be vendor-specific

<fantasai> florian: If it should not work in all browsers, it should not be on the Web.

<fantasai> astearns: Consider these sorts of things you're talking about as a type of user-defined variable?

<fantasai> TabAtkins: They're still ua-defined, they won't be --

<fantasai> TabAtkins: IIRC, when we were discussing how CSS doesn't want to use prefixes

<fantasai> TabAtkins: if it's actually a platform-specific thing, not just experimental, then prefixes are appropriate to expose

<fantasai> florian: Yes, but if something is only used for e.g. UI of iTunes, it should be prefixed *and* not exposed to the Web

<fantasai> florian: If you expose to the Web, it's not vendor-specific

<fantasai> TabAtkins: Anything exposed to iphone will be rendered by webkit

<fantasai> TabAtkins: You write the web page to have special code when you're browsing with Safari

<fantasai> florian: iTunes UI is an application, it's not like you're going to read its UI with Firefox

<fantasai> florian: But if you have a website, then other browsers will read that page or try

<fantasai> florian: Websites should be cross-platform

<fantasai> TabAtkins: ...

<fantasai> florian: iPhone has rounded corners, we should have iphone-specific thing for handling rounded corners ... but rounded corners are not iPhone specific

<fantasai> florian: We shouldn't have an apple-specific feature for it

<jensimmons> I posted the slides about Aspect Ratio being added to the Sizing Spec here: https://noti.st/jensimmons/FnU3KJ/adding-explicit-aspect-ratios-to-css

<fantasai> florian: Having these things is not an Apple-specific thing, so it should be designed as a cross-platform standard feature

<fantasai> florian: None of the examples given here are things that should only belong to one vendor

<fantasai> discussion of high contrast

<fantasai> and microsoft-specific stuff

<fantasai> gregwhitworth: I feel like we're talking past each other

<fantasai> gregwhitworth: Everyone likes standards, wnats things to work great

<fantasai> gregwhitworth: There's a bunch of stuff listed here

<fantasai> gregwhitworth: e.g. high contrast, system colors, people want these things

<fantasai> gregwhitworth: These types of things, here's where interest, we should start to standardize on these variables

<fantasai> gregwhitworth: High contrast in variables, can present what we're doing

<fantasai> gregwhitworth: Can stndardize them

<fantasai> gregwhitworth: but have to ship at some point

<fantasai> gregwhitworth: Where there's no alignment, then that's an avenue for authors to access ios specific aspects

<fantasai> florian: If I understand what you're proposing agree,

<fantasai> florian: Bring things to the WG, if others might want to implement, then we work on standardize

<fantasai> florian: but if it's clear that it's not of general interest, then shpi as vendor-specific

<fantasai> florian: That's fine

<fantasai> florian: But don't agree with "just ship whatever you want", may or may not be candidate for standardization, get stuck with web compat

<fantasai> hober: We've got product schedules and secrecy requirements

<fantasai> florian: Sometimes your'e constrainted by business constraints, that's one thing. But we are discussing best practices here.

<fantasai> dbaron: Have to think about what happens when web pages start using these things

<fantasai> dbaron: Have trouble finding cases where if one of these browser-specific features becomes widely used, other browsers aren't going to have to implement it.

<fantasai> dbaron: DTo use example of inset-radius, let's suppose hypothetically, that we knew for sure that Apple was the only vendor that was going to ship a phone that wastn' rectagulear

<fantasai> dbaron: Even in that case, we need to know that this feature exist and that other browsers need to return zero

<fantasai> dbaron: Or maybe sites depend on it being 10px, and we have to report 10px

<heycam> dbaron++ ; authors aren't always going to provide fallback values in env()

<fantasai> dbaron: But either way we need a spec about them, so we know what to do about them.

<fantasai> dbaron++

<florian> +1 to dbaron

<fantasai> TabAtkins: That's compelling, I agree.

<fantasai> Rossen: So let me try to close the discussion.

<fantasai> Rossen: Clearly I believe there is interest in this spec, by more than a few of us

<fantasai> Rossen: I want to see this spec get to FPWD

<fantasai> Rossen: sooner

<fantasai> Rossen: we will work on details, but getting to FPWD should happen

<fantasai> Rossen: Let's move on.

<fantasai> https://lists.w3.org/Archives/Public/www-style/2018Jul/0025.html

<fantasai> - RESOLVED: Accept proposal in the issue. “UA vendors MUST NOT

<fantasai> expose built-in env() features to the web without going

<fantasai> through that process” (Issue #2820)

<fantasai> fantasai: We resolved on this in Sydney very explicitly. That goes in the spec.

Constructible style sheets

<fantasai> rakina: Making CSS style sheet objects directly ocnstructible and also use them with shadow roots

<fantasai> rakina: 3 new methods on document

<fantasai> rakina: create style sheet, will return promise of CSS style sheet

<fantasai> rakina: One sycnhronous createEmtptyStyleSheet()

<fantasai> rakina: And one createsomethingsyncsomethingobject()

<fantasai> rakina: allows @import rules

<fantasai> rakina: For using constructed style sheets there will be a new attribute on document or shadow root interface

<dbaron> https://wicg.github.io/construct-stylesheets/

<fantasai> rakina: ...

<fantasai> rakina: Constructed style sheets can be added to adoptedStyleSheets on document or shadow root

<fantasai> rakina: same as stylesheet constructed on

<fantasai> rakina: constructed style sheets are part of document style sheets, are after the document or shadow root's stylesheets from the DOM

<fantasai> rakina: Blink has a working implementation and has resolved most issues. Interested in shipping

<fantasai> rakina: Open issues regarding usage of style sheets in ?

<fantasai> rakina: and also issues of style sheets from style elements and link

<fantasai> rakina: Interested in shipping style sheets that aren't used in multiple documents

<fantasai> rakina: and ....

<bz> +q

<fantasai> TabAtkins: Detail of the API, for review

<fantasai> TabAtkins: We resolved in the issues...

<fantasai> TabAtkins: we have 2 constructors, async and sync

<fantasai> TabAtkins: async allows anything from normal styelshet

<fantasai> TabAtkins: And a matching JS modules semantics

<fantasai> TabAtkins: it downloads all the imports and waits for them to finish before fulfilling the promise

<fantasai> TabAtkins: can use straight away with all data is ready

<fantasai> TabAtkins: synchronous version does not block

<fantasai> TabAtkins: Blocks but disallows import

<fantasai> TabAtkins: No waiting for network requests

<fantasai> TabAtkins: Wait for parsing of stylesheet only

<fantasai> TabAtkins: Thought that because style sheets might be large we might not want sync

<fantasai> TabAtkins: But if we don't do this, ppl will want sync

<fantasai> TabAtkins: And they will do it by split style sheet text into rule chunks and assemble them

<fantasai> TabAtkins: So made sync function

<fantasai> TabAtkins: Does have implication for CSS parsing API

<fantasai> TabAtkins: that greg and I have been planning to work on

<fantasai> TabAtkins: Because "maybe this is big, we should make it async" ... should reflect this the same way

<fantasai> TabAtkins: If you can build something out of sync pieces, don't worry if the larger thing is also sync

<fantasai> bz: I'm still a little confused about the multiple document part

<fantasai> bz: In particular if you're allowing this in the shadow root, they can change which document they're associated with

<fantasai> TabAtkins: So issue 23?

<fantasai> bz: You're planning to resolve this by disallowing ? what are you disallowing exactly?

<fantasai> TabAtkins: If you want to use a style sheet in a shadow root, you have to create it from the shadow root not the containing document

<fantasai> rakina: No, you can create from the containing document

<fantasai> TabAtkins: So what happens if you adopt on the shadow root and then import into another document?

<fantasai> rakina: We don't handle that already

<fantasai> rakina: If you're adopting something, then you need to check if the adopted style sheets are still valid or not

<fantasai> rakina: If not on the same document tree, then won't be used

<fantasai> TabAtkins: Was going to suggest requiring it constructed from shadowroot, but then can't use same stylesheet on multiple elements

<fantasai> bz: I don't know that you want to solve this right now?

<fantasai> TabAtkins: Can you file an issue?

<rakina> https://github.com/WICG/construct-stylesheets/issues

<fantasai> bz: There's no link to file issues?

<fantasai> ewilligers: We linked to some issues from agenda, so try to get to the repo from there?

<fantasai> rniwa: I think there are some bikeshedding to be done, it's kind of strange to have 3 methods like this

<fantasai> rniwa: also seems strange to formazlie on sync vs not,

<fantasai> rniwa: supporting or not supporting import is pretty significant, should reflect that somehow

<fantasai> rniwa: Bigger issue is that multiple shadow roots in more than one distinct document can refer to a single constructible style sheet

<fantasai> rniwa: That can lead to some weird relationships between documents

<fantasai> TabAtkins: We currently disallow adopting a style sheet if its document isn't the right document, I believe

<fantasai> domenic: My concer is web compat

<fantasai> domenic: If we silently disallow, and then suddenly figure out how it works, that's bad

<fantasai> TabAtkins: It should definitely throw an error

<fantasai> rniwa: But what happens when shadowroot that already uses the style sheet goes to use it

<fantasai> TabAtkins: Moving aorund, we haven't though tof

<fantasai> rniwa: We can resolve those issues

<fantasai> rniwa: I'll add that, another thing I'm a bit concerned about is frozen approach

<fantasai> rniwa; I thik there are cases where you might want to add style sheets in a different class hierarchy

<fantasai> TabAtkins: They can do that in constructors

<fantasai> rniwa: would be better maybe to add/remove style sheet that monidfy

<fantasai> TabAtkins: Take the frozen array off the dom property, turn it into a normal property, and then assign it and it freezes

<Domenic> sr.adoptedStyleSheets = [...sr.adoptedStyleSheets, newStyleSheet]

<fantasai> rniwa: i understnad that, but perhaps the API that ..

<bz> +q

<fantasai> Rniwa: It's not that we don't want to have a list of style sheet, but better to have an add/remove API instead

<fantasai> TabAtkins: Having discussion of how list APIs should work on the web platform

<fantasai> TabAtkins: tried to make this simple so that we could figure it out later

<bz> -q

<fantasai> TabAtkins: not against adding sugar for making this, but would prefer to defer until we figure out how to do arraylike objects beter

<fantasai> rniwa: This is differen from other stle sheet list

<fantasai> rniwa: this would be very different from document.stylesheets

<fantasai> rniwa; From author's perspective, you have stylesheets added by style element and link element

<fantasai> rniwa: Those show up in document.stylesheets

<fantasai> rniwa: Have another property that has document.adoptedStylesheets, would expect it to work the same way

<fantasai> domenic: The frozen array api is a superset, except it's missing the .item method which hopefully nobody uses

<fantasai> chrishtr: I belive spec does not say what is the relative timing of resolving ht epromis and display to the screen ,is that true?

<fantasai> TabAtkins: Those are tow separate issues. youc an't assign the promis anywher,e have to wait for it to finish, then take the style sheet out and put it in

<fantasai> Rossen: The promise gives you the constructed object. Not part of the collection yet.

<fantasai> chrishtr: OK, get style sheet from promis and then assign it

<fantasai> emilio: ...?

<bz> =q

<fantasai> TabAtkins: Runs in JS, doesn't block mroe than anything else

<bz> +q

<fantasai> emilio: Whether the promise blocked the load event

<fantasai> bz: Real question is whether imports kickced off by the style sheet would block the oad event

<fantasai> bz: which is how ? works

<fantasai> TabAtkins: There's no case that an async ocnstruction API blocks the load event

<fantasai> ...

<fantasai> TabAtkins: Until you put it into the document style sheets, it doesn't do anything

<fantasai> TabAtkins: It's just an async call that ...

<fantasai> bz: Not clear, spec needs to say that it's not blocking

<fantasai> Domenic: Given how unclear the spec is, need to say explicitly

<fantasai> TabAtkins: We can add a note, sure

<fantasai> TabAtkins: Question about applying issue before document finishes loading, that's unsolved

<fantasai> bz: Normal loads and imports block load

<fantasai> TabAtkins: Because they already apply to the document. The imports are trying to apply

<fantasai> emilio: Why would it be different from document......

<fantasai> Domenic: ...

<fantasai> Domenic: Equivalent of being connected is done after you apply the style sheet

<fantasai> emilio: You would never trigger a load for an unconnected link element

<fantasai> emilio: What happens if you adopted somewhere unconnected shadow root

<fantasai> Domenic: It's sill disconneted

<fantasai> Domenic: Agree it's different from normal, but it's reasonable

<fantasai> Domenic: It's nice that it doesn't block the load event

<fantasai> TabAtkins: Don't see how it could block the load event

<fantasai> Rossen: rniwa, anything you're looking for in terms of resolutions before you leave?

<fantasai> rniwa: I don't think we need any resolution today

<fantasai> Rossen: e.g. useing frozen array vs style sheets

<fantasai> Rossen: do we want to go through specific issues or close the topic?

<fantasai> rniwa: Eithe rworks fine

<fantasai> rniwa: I don't have a preference for frozen array just because it's a new thing we want to try

<fantasai> TabAtkins: They're not new

<fantasai> rniwa: For consistency sake, because other lists of style sheets are not using frozen array, I think we should use the same as the other

<fantasai> Domenic: We're trying to work away from legacy ??

<fantasai> Domenic: Current best idea is to use frozen arrays, because so API compatible

<fantasai> TabAtkins: Can you file that as an issue?

<fantasai> rniwa; one more thing, we probably want to have anotehr create style sheet that take sa URL

<fantasai> rniwa: pass it to this api

<fantasai> TabAtkins: we didn't do that because Fetch() takes a lot of options, and if we don't reproduce all those options it's limited

<fantasai> TabAtkins: and if we are reusing, then it's duplication, might as well just use fetch()

<fantasai> Domenic: ...

<fantasai> Domenic: Other apis have taken a promis as a response, pass directly ?

<fantasai> Domenic: This is the pattern we've seen

<fantasai> rniwa: All the @ rule sare automatically fetched using CSS, not overwrting that

<fantasai> rniwa: Not sure it's useful to support all fetch options

<fantasai> TabAtkins: Dealing with cross-origin stuff, etc.

<fantasai> Domenic: There are attributes in HTML that reproduce part of the fetch() api, could reproduce that in JS...

<Domenic> The pattern is, like WebAssembly.instantiateStreaming() etc., to accept a Promise<Response>, then you could do e.g. document.createStyleSheetFromResponse(fetch("...")) directly

<fantasai> Rossen: Any specific resolutions that you're looking for? Also, are we continuing to work on this in WICG or should it be pulled into CSSWG

<fantasai> TabAtkins: We didn't anticipate getting a bunch of new issues here

<fantasai> TabAtkins: But they're good issues

<fantasai> TabAtkins: But means goal of driving down last issues and promiting it isn't satisfied here

<fantasai> TabAtkins: Given that we have broad browser interst, do we thing we should move over to CSSWG or leave in WICG?

<heycam> +1 for bringing it to CSSWG

<fantasai> dbaron: Do you want it to be in CR?

<fantasai> TabAtkins: Soon. Want to resolve all issues asap

<fantasai> TabAtkins: Want to resolve all the shadow dom issue stha dpen on it

<fantasai> dbaron: Moving it into the WG comes before CR. :)

<fantasai> Domenic: We prefer ot iterate in WICG and get field experience before moving it

<fantasai> Domenic: So I would keep it htere

<fantasai> dbaron: I just filed two issues. I didn't know this spec existed until an hour ago

<fantasai> ...

<fantasai> bz: ...

<fantasai> Rossen: Sounds we don't move it to the Wg just yet

<fantasai> Rossen: Going to close this topic for now

<fantasai> Rossen: Hope you got enough input from the WG

<fantasai> Rossen: For those interested please follow the spec now

<astearns> https://wicg.github.io/construct-stylesheets/index.html

Resize Observer

<fantasai> astearns: There's a session tomorrow about resize observer, find it tomorrow if you are interested

scrollbar styling

<fantasai> tantek: We did FPWD already

<fantasai> https://www.w3.org/TR/css-scrollbars-1/

<fantasai> heycam: Not sure who put this on the agenda, but I can make a demo if ppl want

<fantasai> tantek: we have an implementation in nightly

<fantasai> https://github.com/w3c/csswg-drafts/issues/3237

<fantasai> github: https://github.com/w3c/csswg-drafts/issues/3237

<fantasai> heycam: Question about what should happen with getComputedStyle() and the scrollbar color

<fantasai> heycam: Not sure we want to use resolved value

<fantasai> heycam: strange to have auto value become something else

<fantasai> heycam: would like to use the actual comptued value

<fantasai> dbaron: Is there a distinction between "auto or comptued color" and auto and used color?

<fantasai> emilio: We resolve computed color

<fantasai> heycam: I don't think we should resolve auto to a color

<fantasai> tantek: Also this is two colors, not just one

<fantasai> tantek: We had two properties, folded to one

<fantasai> tantek: Can also say if you want dark or light theme scrollbar colors

<fantasai> tantek: so not just a color property, a bit more complicated

<fantasai> fantasai: so if you specify a non-<color> keyword, return that keyword, otherwise return the same kind of resolved color as other color properties

<tantek> resolved colors (plural)

RESOLUTION: getComputedStyle() resolves colors same as other color properties, but other keyword values return as the keywrd

<fantasai> heycam demos Firefo's implementation

<gregwhitworth> very, very cool heycam

<fantasai> tantek: Based on this implementation experience, we're pretty happy for light and dark for colors, and being able to specify colors

<fantasai> tantek: dark is interesting for web apps that have a dark theming regardless of what the OS theme is

<fantasai> tantek: Regarding width, having just thin vs not has been suficient for the use cases we've needed

<fantasai> tantek: we haven't implemented the <length> value and would be OK with dropping that

<fantasai> tantek: don't know if there are other implementers that have thought about this since Syndye

appearance property

<heycam> gregwhitworth: thanks!

<fantasai> florian: zcorpan has been working on spec for appearance

<heycam> gregwhitworth: (thanks should go to xidorn!)

<fantasai> florian: Lot of good work. Very detailed investigation of what property values do what

<fantasai> florian: Research on which values have specific behavior, which need to be just not "none"

<fantasai> florian: There is a lot of interesting details we should talk about

<fantasai> florian: But need to address fundamental issue

<fantasai> florian: There have been different assumptiosn from different ppl, need to crack that problem first before discssing specific issues

<fantasai> florian: As appearance has been spec in css-ui

<fantasai> florian: Has two values: auto and none

<fantasai> florian: auto turns HTML elements that ahve particular native look and feel into that look and feel, and none turns it off

<fantasai> florian: That design doesn't have more values, but can have omre values

<fantasai> florian: Similar to how y'uve specced it on your value, could say that e.g. button turns things into button

<fantasai> florian: Or can say that some additional values are accepted but turn into auto

<fantasai> florian: You do not have auto

<fantasai> florian: And you have a finite list

<fantasai> florian: Which implies you need to do something special for HTML elements that have special rendering but don't have a corresponding keyword

<fantasai> zcorpan_: I want to point out that Iv'e received from implementers that they watn to limt the property, what it applies to

<fantasai> zcorpan_: Currently in most impelmentations you can turn any element into any appearance

<fantasai> zcorpan_: but they want to limit that to whatever is required for web compat

<fantasai> florian: Yes

<fantasai> zcorpan_: So that button can only apply to buttons

<fantasai> zcorpan_: So I tried to look at web compat through http-archive

<fantasai> zcorpan_: What combinations of values are used

<fantasai> zcorpan_: e.g. some pages set button on a select element

<fantasai> zcorpan_: In Safari/Chrome/Firefox make it a button

<fantasai> zcorpan_: But in Edge it doesn't do anything except make the drop down arrow no longer render

<fantasai> florian: That is not covered by the spec I have, but is compatible with that model

<fantasai> florian: What is an exampel of a value you have found is not needed for web compat

<fantasai> zcorpan_: Didn't add inner-part of meter/progress elements

<fantasai> zcorpan_: implementations ...

<fantasai> florian: Do you have an example of a value that is suppose dto apply to an element (not a pseudo)

<fantasai> zcorpan_: Everything that is in UA style sheets by default on actual elements is in the spec

<fantasai> florian: I think we have previous resolution of this WG that we did not want to do this

<fantasai> florian: we did not want to have the full list of everything.

<fantasai> florian: We *can* spec that, but it means every time HTML adds a new form control, we need to add a new value

<fantasai> florian: So far as I have heard, especially from MSFT, not all values that were used in UA style sheets were needed for Web compat

<fantasai> florian: If we are going to specify the full list of all the values you need to write the UA style sheet

<fantasai> florian: That is a thing we can do

<fantasai> florian: But so far we've indicated that we wouldn't do that

<fantasai> florian: And if list needs to e shorter than what's needed to UA style sheet

<fantasai> florian: And if it's shorter, you still need to be able to write your UA style sheet

<fantasai> florian: This is where 'auto' comes in. Everything that doesn't have a corresponding value in the short list has 'auto' i nthe styl esheet,

<fantasai> florian: Then author can turn it off with none

<fantasai> florian: Another issue is that some of these values are needed to coordinate with values assigned to particular non-standard pseudos

<fantasai> florian: And WG strongly does not want to add those

<fantasai> zcorpan_: In FF and Chrome, it's possible to have values only supported in the UA style sheets

<fantasai> zcorpan_: So if there are internal parts of form controls that have stuff in the UAs tyle sheet , we can just do that

<fantasai> z/have values/have values and pseudo elements/

<TabAtkins> ScribeNick: TabAtkins

fantasai: I think that's not something we should be trying to do in general.
... ONly when we have to.

<gregwhitworth> can someone clarify the action of this - is this to get the webkit props into CSSUI?

fantasai: This doesn't seem like a case where we must have this model, where values are only valid in some contexts.
... Why aren't we able to go with a model where we have none/auto/[few more]?
... And a pile of keywords that compute to auto?
... That seems a lot simpler than adding a bunch of values that can only be used in UA stylesheet.

zcorpan_: I think the model is in principle the same.
... In my proposal I don't actually have the auto keyword, but othewise it works the same.

florian: Given that "auto" is the initial value in my proposal, if you dont' ahve it you don't have the same model.

zcorpan_: Yeah, it's different, and I agree. Mostly because it's different from what's today.
... Moz tried to implement and had webcompat problems with the initial value being auto.

fantasai: You can make initial be "none", then have UA stylesheet set it to "auto" on all necessary elements.

florian: What was found incompatiable was having no valid but "auto". If you have a few extra values, it might work.

<Rossen> gregwhitworth, yes

florian: Models are different where if you don't have auto, you must have the entire list, even if you only expose some part of it.

<emilio> https://bugzilla.mozilla.org/show_bug.cgi?id=1333482

florian: CSS says every element has a value for every property, you can expose it via gCS().

<emilio> (fwiw)

zcorpan_: The non-exposed values are only on internal pseudos, not elements.

fantasai: I don't know why we have to standardize any values the web can't see.

zcorpan_: Not saying we need to, it's an impl detail.

fantasai: But still every form control needs a non-none value, and ideally the author shoudl be able to set it *back* to that value.

zcorpan_: Yeah, revert.

florian: But revert isn't a value on its own.

iank_: I think we'd like to reduce the number of values we currently support.
... Last week tkent (maybe?) added some high-precision use-counters to track these.
... So in about 3months time we'll have very accurate usage data.

dbaron: I think some of what's going on here is that a bunch of people have constraints that haven't really gotten thru to the other side.
... I think it's not particularly clear to me or to engineers at Moz why we want to do things that deviate from teh already-existing stuff.
... Every time the group makes a bigger deviation, that increases the risk of having to spend mroe time dealing with the fallout.
... So how many months do you want to spend on it (and thus delay work on subgrid)?

florian: I think there are 3 possible models.

<gregwhitworth> +1 to what dbaron said

florian: 1 is we specify all the values, including the ones on pseudo-elements, because you need them all fo ra UA stylesheet.
... 2 is we specify the subset for webcompat, leave undefined the rest, and specify some mechanism about having values that exist only in the UA stylesheet (and what that implies for computed values, etc.)
... 3 is we replace this heap of values with an "auto" value
... Reason to not do what's currently implemented is that it depends on different, UA-specific lists. And the model depends on the full list.
... So creating the full list looks like a lot of work. Creating a mechanism to hide it is also a lot of work.
... If we want to make a new cascade-hiding mechanism, we need to actually do that. Can't just spec "appearance" assuming it exists.
... I assumed it didn't, so my two possiblities were #1 and #3.
... Looks like a reduced list is desirable.
... So that rules out #1. So we're left with reudced list with "auto", and reduced list with cascade-hiding mechanism.

<tantek> why are we bothering with anything appearance except for -webkit- compat?

franremy: This property was created to do something nobody wants anymore.
... Making an arbitrary element look like a button.
... First we found we don't need that, second it's bad.
... In Edge we implemented some values, but it doesn't do anything.
... We just parse a bunch of values because the stylesheet needs them.
... I don't think we need to go further.

<tantek> As the person who introduced the appearance property, yes, it was an attempt to do something we thought we wanted at the time but have long since abandoned.

<tantek> We should spec it for the compat spec and that's it.

franremy: So if th emodel we want is just to allow disablign the rendering, then let's find that subset we need (we already have that list implemented), then do auto for everything else.

fantasai: I agree with françois

<florian> so do i

zcorpan_: So what Edge does is kinda like the approach I'm aiming for. And Edge doesn't support "auto" itself.
... I think, Florian, you keep coming back to having to spec the full list..

florian: Or hide the values; UA-sheet-only isn't a real thing that exists.

zcorpan_: They're only on internal pseudo-elements, not web-exposed.

florian: They're exposed via gCS().
... I'm confused why you keep saying our models are the same.
... Even if they're restricted to pseudoes, we still want to reduce the list - Ian does.

zcorpan_: AGree.

florian: And so if we reduce, what do we return from gCS()? That must be specced.
... We already know we want less than the full set.
... So we have some number of HTML elements that have a value we dont' want to expose. What do we do for those?

zcorpan_: My understanding is that all the elements with an appearance, we'd specify a value fo rthose.

florian: That's not what François or Ian said.

<gregwhitworth> scribenick: gregwhitworth

CSS Cascade

TabAtkins: Did I add this?
... ok ok ok
... ah
... people want to only be able to import styles based on MQs

<jensimmons> link?

TabAtkins: but for reasons, we don't actually block downloading
... we have to go down the styles
... the web depends on them being walked

<Rossen> github: https://github.com/w3c/csswg-drafts/issues/3050

TabAtkins: so, people still want this
... leave the downloads only for devices that need them, etc
... @supports is a good example of this
... the proposal - the two that I have are either a: keyword like async after url()
... this indicates the stylesheet can be loaded async
... or we can add a media function similar to supports, the old will be forced function but this one will only occur when the method is satisfied
... does this seems like a good possilbities, if so which do you prefer?

myles: kind of like device width, if you resize the browser it will only fetch as you resize

TabAtkins: yes, it's bad to put it on things that are likely to change

heycam: I think it seems reasonable to add support for this - the media function doesn't seem like the best approach
... for print I'm not even sure
... you hit cntrl+p and having to print
... do you have any other scenarios

jensimmons: I'm very skeptical about this
... I think it's a thing we want to think about deeply
... there are many ways that people do to make it so that it's faster
... some of them are terrible

<emilio> o rly?

jensimmons: some of them make far more CSS, I'm not sure of anything but we don't want to do it too quickly
... offering the tool - it will have a huge impact on how people work with CSS
... now the industry is straining about CSS performance and it's getting kind of scary
... it's something we really want to explore - but we should dig into all of the aspects and not ship too quickly when the industry moves to a different approach that negates the investments here

emilio: why do we need to add import instead of link

TabAtkins: right now link rel=stylesheet doesn't have async
... whatever changes we have here we'll want to port over there as well

jensimmons: you know what I might be saying is that I want to engage with a CG with more webdevs

emilio: we rely on import, and others rely on that
... ...

TabAtkins: one thing I'm running into - this might want to be, more complicated
... rather than just @supports
... and import stays how it is

emilio: what is the context of why?
... why do we load print stylesheets even if we aren't printing

TabAtkins: the reason we do it now is because people expect this to be the way it always has been
... back in the day we didn't have promises for these types of things
... this will avoid some of our issues
... this is getting more complicated - let's WICG it, let's do what jen said
... that sounds reasonable to me

emilio: there is a way to do this in webkit, the .disable factory
... it won't load it
... it feels like I've filed various issues on that
... if we could agree on that - we could get web developers ideas on it, no need for something new

TabAtkins: that functionality doesn't work on import

emilio: I was hoping to not have to do this on import

TabAtkins: yeah we should though

emilio: we don't support all security on that either

TabAtkins: we should

RESOLUTION: Move this to WICG

Next on graphics issues

Rossen: this is about success on filters elements on the root element

<Rossen> github: https://github.com/w3c/fxtf-drafts/issues/282

chrishtr: I brought this a few months ago - there were a few pieces of feedback
... how do you treat the root element, in particalur frames that are transparent - similiar to iframes
... it's in a webview in side of an app for example
... some other device that wants transparency
... I did some more testcases
... and have a proposed solution
... the new proposal is that - there are two conceptual layers you draw into, the frame root background layer
... the root element layer
... the background is always opaque white
... so there is white and then the root element
... you draw the stacking context of the root element into that layer except the background is extended into the infinite canvas
... everything would apply as is
... clipping and filter and blend-mode and backdrop-filter are done in the same order as before
... so I went throught he examples that simone fraser came out as he expected

mstange: I don't think that is true
... in your root element layer there is no white background
... if you don't have a background element on html then you can apply and filter and it will break
... if you have the background there then we will get what Simon expects
... we need to update background-blend mode or we cannot invert

krit: blend mode currently defines white to be the pages backdrop

mstange: yes it does, but only the result of the blending is composited on top of it - it doesn't participate

chrishtr: is the contention - if you make it part of it then it fixes the invert, but if you don't then it breaks it

mstange: if you make the white part - part of the page group you fix invert but change how mix-blend-mode is defined
... this part isn't implemented by Chrome
... correct?

chrishtr: I think Chrome is probably incorrect

mstange: but if we change it, Chrome doesn't need to change

chrishtr: true

krit: I want to change web pages that will always have the white backdrop
... it is there for sites that didn't provide a background, is it providing the background for websites

mstange: we still allow people to change the default color to the background
... there may be a11y issues here

chrishtr: let's save that for a different issue

mstange: sure

chrishtr: do we want to consider white as part of the root
... then the root is not different than any other stacking context

mstange: the filter may be opacity: 0 - you'll need some type of result
... I support painting the background twice, once inside and outside of the page group
... and defining the remaining issues

chrishtr: why twice
... why isn't it ok to composite the filter to white?

mstange: that could work

chrishtr: you should just expect it to be composited to white

mstange: if we say it's white for now
... if you want invert to be inverted
... it needs to be painted in the page group
... if you want a merge to apply to the default background color
... the white needs to be present to the input of the filter, now you have a result so you composite that to something, what is under the result

chrishtr: it is white

mstange: that's why it needs to be twice

chrishtr: in the scenario where there is no background defined

Sim: you propogate the color to the root element layer, and then do the composition

chrishtr: yes
... I think it's equivolent

simon: if the root is white with alpha

chrishtr: I think the math comes out the same

krit: depens on the transform and color
... let's say you can set the color in the page group, what would happen? Would backdrop not get inverted?

mstange: FF settings don't allow alpha, the result would be opaque and that would be composted onto white, always gives you the same result

krit: my only concern - do we always have a solid color

mstange: as written, it would allow support for any background color including no background color besides what is defined on the root background color

chrishtr: whatever the screen happened to have on it would be composited

<mstange> proposed resolution: In mix-blend-mode, reword the paragraphs "The page group is an isolated group. The page group is composited with a backdrop color of white with 100% opacity." to mention that the default background color is also painted within the page group, i.e. that blending happens with the default background color.

Rossen: Any objections?

Resolved ^

Proposed Resolution: the filter applies to the result of the page group on top of the root background color

Rossen: objections?

Resolved ^

mstange: your document also changes opacity, mix blend modes and filter?

chrishtr: you mean it also changes opacity?

RESOLUTION: In mix-blend-mode, the default background color is also painted within the page group

mstange: if you have a background red on root and opacity: 0

RESOLUTION: the filter applies to the result of the page group on top of the root background color

mstange: if I have background red on the root element, does this go inside the page group and root group?

chrishtr: no

mstange: that changes what occurs - this does not change the root element

chrishtr: this would change

mstange: opacity is a type of filter
... clip-path and mask would change as well
... if you have clip-path on the root element, the clip would effect the background of red

chrishtr: I think that's good

mstange: I agree

Proposed Resolution: opacity, clip-path, mask and clip path will be applied to output of the page group on top of the root group

mstange: I don't agree with clip

chrishtr: it's always a stacking context

mstange: should we just not mention clip

chrishtr: sounds fine

Proposed resolution: clip path, opacity, mask will be applied to the output of the page group on top of the root group

Rossen: objections

Resolved ^

RESOLUTION: clip path, opacity, mask will be applied to the output of the page group on top of the root group

chrishtr: the reason I think we should use white as the background is to provide consistency to authors
... this is inconsistent with the need for a dark mode

krit: why not just keep a weight

Simon: Why not have white be the default and allow UAs to adjust it

chrishtr: I'm fine with that
... should we ok with defining opaque

krit: we should define the UA may define the background color and default is white

Simon: and it doesn't need to be opaque

Proposed Resolution: The background color is UA defined with default being white

RESOLUTION: The background color is UA defined with default being white

backdrop-filter

<Rossen> github: https://github.com/w3c/fxtf-drafts/issues/53

chrishtr: for reasons of implementation complexity, number 1 and avoiding situations developers would find confusing
... I want backdrop-filter to only apply to containing isolated group, which in spec terms is the background image of the group
... takes the group - applies filter and then clips and paint behind it and then paint on top
... issue 53, was originally filed to change the spec to not image but all the images from the root
... the prefixed impl that Safari has that draws everything up to the root - and unprefixed version in Edge also has that
... the reason I prefer it to the isolated group is because it's easier to implement and more performant
... whereas if you draw all the way up to the root we'll need to implement a new algo
... if you go to an isolated group that is above the containing isolated group you may have to take into account other graphical effects into account with filters that move pixels, etc
... this inreases complexity a lot
... this makes it complicated for developers - there are a few scenarios in the issue
... there's an element with backdrop-filter, somewhere in the ancestor an alement has opacity but it isn't in the isolated group but that opacity must be included - so you're getting doulbe opacity

krit: I have to agree that opacity is indeed strange, did you do testing on Edge/Safari

chrishtr: yes, there are screenshots in the issue and they do double opacity

krit: I think there is developer desire to do it on the entire section, not just the isolated group

mstange: can you mention a case that would be impossible?

krit: when you do an animation that has a filter on it
... there wouldn't be any backdrop filter on it since it's animating

mstange: that sounds like an animation issue
... that sounds like an ordering issue
... I agree with chrishtr that it would be easier to implement and be more predictable for authors

krit: how does it work more consisted with mix-blend-modes?
... you have two divs on top of each other, the second would be an isolation group - you would blend them together

mstange: mix blend mode and isolation groups are not always the same

<krit> https://codepen.io/krit/pen/pxOMdz

mstange: I'm interested in seeing scenarios in which I'm wrong

krit: or maybe I'm missing some
... looking at codepen

Simon: as I understand anything that creates a stacking context creates an isolation group

Simon that is contrary to the point of backdrop-filter which should apply to everything behind you

chrishtr: yeah
... I think this needs more discussion offline

Rossen: ok, thank you chrishtr

<krit> mstange: https://dbaron.org/log/20130306-compositing-blending

Text decoration

<Rossen> github: https://github.com/w3c/csswg-drafts/issues/3118

myles: we have two properties
... text-underline-offset and text-underline-position
... reads out values for each
... question is, both of these properties
... the problem is only in horizontal WM
... both of these describe the vertical position of the underline
... the spec does describe some situations on how they play together
... what happens if they collide?
... there are two possible ways to solve this problem, is rules and also to join them into one property and avoid the bad issues at the syntax scenario
... I prefer the latter as it's intentional and mechnaical

fantasai: I guess, I'm not sure which one is the better option
... the reason they were seperated was due to position may be dependant on the language where as the offset may be author messing with it
... that means any time you want to make an adjustment you'd need to provide the offset change and which side the line is on
... that is mostly important in vertical text where the line matters

drott: I think we still need both values, even if you combine them
... under auto | we still ahve to define rules when you combine them

myles: thinking of them as one as a position and as offset isn't valuable because having an offset from auto isn't useful because every UA has a different auto
... the pixel from the baseline to the underline is different
... we're in agreement here
... I do have a proposed sytax for this issue

fantasai: in the case of the conflict, over and from-font there are three ways
... treat from-font as 0, auto, or to take the distance from the alph baseline and compute that to a pixel

myles: you metnioned three of them
... two of them, pick a winter
... third is typgographically bad - because it's defined to not be applied anywhere else

fantasai: before we add another keyword
... there are whole lot of complications with underlines
... when you have inline elements that have different font sizes the position of the underline gets complicated
... if they're aligned alphabetically you're at least setting them from the same offset
... but if they're aligned along the central baseline you don't want the line crossing through the chars
... if you use under, you need to go below the largest descender and those calculations aren't tightly defined in L3 and we need to think about it for L4
... I want us to be thinking about it

myles: are you referring to the decorator box

fantasai: not sure which one is that, but you don't want to cross through text - the UA should be taking the descendants into account

myles: ok

fantasai: not sure where that brings us on this topic

drott: can you sketch out your syntax proposal

<myles_> https://github.com/w3c/csswg-drafts/issues/3118#issuecomment-421827968

myles: I can link to it

fantasai: easiest for combining is auto from-font | length

koji: how you set position of underline

myles_: no opinion - defer to fantasai

fantasai: the offset measure in the block axis, so it works fine for vertical text
... if the line is on the ascender side it goes away from the alphabetical baseline based on the value

drott: do we agree that the from-font should not be used for vertical text?

fantasai: I don't see why not?

drott: so we do want to use it as well?
... the second point here is a bit inconsistent because we had from-font only for offset value and here it's for a base align

<fantasai> auto | from-font | [ under || [ left | right ] || <length> ]

drott: here it's changing baseline left is equivelent to position before

fantasai: actually I think there is something we can do
... move font-font to the other

myles_: so it will clobber the other
... would it be added?

fantasai: from-font + a length?
... you get the offset and then it's added to the length
... I want it shifted down more

myles_: so would auto mean 0?

fantasai: auto currently means what the UA does?

myles_: the property that takes the length

fantasai: I'm not sure if the offset for left and right is 0
... if the UA does not hide the metrics of top or bottom, left or right

myles_: underlines are exactly on the bottom of the descenders

koji: what about when the issue is on the baseline?

fantasai: you're right we would have to do that
... the underline might be 0, but the alphabetic baseline there would be an offset that is UA defined
... auto means the UA gets to define what is appropriate

myles_: You said they add

fantasai: we can't have an offset of 0, it needs to be exactly on the baseline or the author has very little control
... the offset needs to be absolute
... underline position is something that folks will primarily use in CJK

myles_: so if both are auto it will look good, but if you set it to 0 it jumps up

fantasai: yes

Rossen: so what do we resolve on

<myles_> auto | [ [ under | from-font] || [ left | right ] ]

myles_: the grammar of text-underline-position turns into this^

<myles_> auto | <length>

myles_: the grammar of text-underline-offset is this^

koji: yep

fantasai: yeah I think that's right

drott: and the behavior if the value is from-font and then a length with offset they are added?

fantasai: yes

myles_: so if position is auto or from-font then they add

fantasai: no they always add, but it resolves to the alphabetic baseline

Rossen: Any objections?

<fantasai> auto resolves to the alphabetic baseline if the offset is not auto

RESOLUTION: ^

myles_: this is text-decoration-width

<mstange> scribenick: mstange

<gregwhitworth> myles_: shows presentation

<scribe> scribenick: gregwitworth

<mstange> scribenick: gregwhitworth

myles_: we wanted to be consistent with other things, but the purpose of consistency is easy of learning, and people are clearly confused, so I propose text-decoration-thickness

RESOLUTION: text-decoration-width is now text-decoration-thickness

<fantasai> dauwhe, you around? wondering if we should be looping back to some of the css-inline issues

<mstange> scribenick: mstange

Next face-to-face

<TabAtkins> ScribeNick: mstange

TabAtkins: Last week of february, 25th-27th
... Same building as last time
... San Francisco's february wheather isn't the best but better than San Francisco's summer weather
... TGIF uses that floor on Thursday, so we only really have half the day
... Monday to Wednesday are the only days we can use it usefully

Rossen: Are we not doing houdini topics?

TabAtkins: Don't have any

<TabAtkins> s/Dont' have any/Don't have any plans, expect to do a half-day side-track during CSS for anything we need to discuss

Selector feature query function for selectors

<Rossen> github: https://github.com/w3c/csswg-drafts/issues/3207

dbaron: When we discussed @supports back w hen we originally did it, one of the things we talked about that we maybe want to have support for more than querying for values
... There may be more important use cases
... Next addition would be testing for selectors
... If you have three comma-separated selectors, the entire rule is supposed to get dropped if any of tehm is unrecognized.
... This is painful because you don't get good negation operations.
... It has also come up recently when looking at scrollbar styling.
... @supports is useless for existing scrollbar styling use cases
... because some of them use selectors
... We all agree on what the syntax of testing for selectors should be, which is, it should be a function called selector.
... We want to allow combinators.
... There are currently some quirks related to ::-webkit pseudo elements
... There is a quirk that makes all ::-webkit pseudo elements not invalidate the selector
... We do not want to carry over this quirk to @supports selector

heycam: There is an open question about namespace testing

<myles_> https://bugs.webkit.org/show_bug.cgi?id=189089

dbaron: This turns out to be a bug in existing @supports because we didn't define it for content: attr(?)
... We should figure out how it interacts with @namespace prefix declarations

TabAtkins: I'm fine with not having them
... I definitely do not want to look at namespace, should either fail or pass always

fantasai: I agree

dbaron: I would lean towards saying the always succeed and act as they always match the namespace

emilio: I would like to argue for the opposite, we sohuld actually look at the namespaces in the stylesheet
... If you are testing for a selector that you actually use inside your @supports rule, that's what you want.
... It also doesn't require any special cases in the implementation.

plinss: Isn't that the point, to ask whether you support "this type of selector", not "this particular selector"?

emilio: I would argue that if it's an unknown namespace, you should not go into the @supports rule
... Invalid namespaces are invalid, they drop the whole rule
... just doing syntactic checking is inconsistent with other DOM APIs that throw on invalid selectors
... Like .matches

TabAtkins: Can we make them always invalid?

emilio: I'd prefer that over making them always valid

dbaron: There's a risk with newly-supported selectors in the future

emilio: Please don't introduce a special case

TabAtkins: The matches function always ignores namespaces, because it always throws when there's a namespace

emilio: because there's no stylesheet

fantasai: There's a rule in the matches spec that talks about namespaces, but it doesn't make it invalid

dbaron: The other thing about the selector functions is that at some point the drafts of those functions had a namespace argument that got dropped.

heycam: With CSS prefixes on the DOM node, no namespace prefixes are going to succeed except * or |

TabAtkins: That same behavior seems fine to have for @supports

fantasai: That doesn't make sense
... I want to check whether I support a selector. Any selector that I'm using in my stylesheet, I should be able to put it into @supports

emilio: I agree.

fantasai: Which is not what TabAtkins is saying.
... .supports would still return "yes I support namespaces"
... it's not about "Does querySelector" support this
... We're checking things at the syntactic level
... I'd be ok with checking the namespace whether it resolves

emilio: I would prefer to look at the namespace map, if it's around
... Then we don't conditionally need to make all namespaces valid in some cases.
... The rules in @supports should be the same rules as for regular parsing.

TabAtkins: What do you think about changing the regular parsing rule of "bad namespaces" kill the rule?

futhark: I tend to agree for regular namespaces. If we're not checking namespaces, I prefer that we actually allow namespaces.

emilio: So either check the namespace map as normal, or always succeed.

dbaron: We need another resolution first, which is to create level 4 of CSS conditional rules
... unless we want to put this in level 3

RESOLUTION: Create CSS conditional rules level 4

RESOLUTION: Accept selector feature functions for selector support in @supports, accepting a single complex selector as an argument.

dbaron: Do we want a resolution or two about the namespace thing?

<heycam> the namespace prefix issue is https://github.com/w3c/csswg-drafts/issues/3220

fantasai: For the namespace we've resolved that they're not always invalid.

RESOLUTION: Namespaces are either always valid or valid when they're declared.

vertical writing mode award

[selectors4] Name the “functional pseudo-class like :matches() with 0 specificity”

fantasai: Lea is not here, do we want to talk about it?
... Anybody have anything to add to this discussion? There's no clear "this is definitely what we should do" resolution.

<TabAtkins> New suggestion: smoosh()

<Rossen> github: https://github.com/w3c/csswg-drafts/issues/2143

<fantasai> https://github.com/w3c/csswg-drafts/issues/2143#issuecomment-408128027

<TabAtkins> Sorry, :smoosh()

<zcorpan> -webkit-appearance: smoosh

fantasai: This takes a list of selectors of which any can match. Unlike the :matches selector it basically zeroes out the specificity: anything you put inside has a specificity of zero.
... This gives you more control about which parts of the selector affect the specificity and which down.
... The only question is what to name it.
... Some of the suggestions didn't get any traction.
... We don't have any suggestion that is clearly better than the other ones.
... My concern with a lot of these is that it is not very clear for :if or :where why this is different from :matches.
... It's different because of the zero specificity, so the name should have something to do with that.

franremy: Last time we had narrowed it down to three.

fantasai: New ones were added after last time.

franremy: We almost agreed on one of them last time, don't remember which one.
... Would prefer to not expand the length of the list of candidates.

dbaron: To make progress, we need to say "Nobody leaves the room until we decide."

<ericwilligers> Last time: if vs where

<fantasai> https://lists.w3.org/Archives/Public/www-style/2018Jul/0027.html

fantasai: Our resolution last time was to narrow the short list to :if and :where, and we added :nil and :zero.
... So we could choose between those.

Rossen: if, where, nil, zero, quash
... In that order, with if being 1 and quash being 5, go ahead and put in your preferred 3.
... In the order of preference

<fantasai> 1 = if, 2 = where, 3 = nil, 4 = zero, 5 = quash

<franremy> 1 2 ... 4 3 5

<iank_> 2, 5, 3

<fantasai> 5, 3, 4, 1, 2

<cbiesinger> 2, 1

<florian> 1, 2

<TabAtkins> 3, 2, 1

<heycam> 2, 1

<futhark> 2 3 5

<dbaron> 4 3 2 5 1

<fantasai> https://github.com/w3c/csswg-drafts/issues/1170

<ericwilligers> 2, 1, 4

<Rossen> 2, 1

<eae> 3 2 1

<melanierichards> 2

<AmeliaBR> 2 4

<tantek> 4 3 5 :ns (no specificity)

<rachelandrew> 2, 1 , 3

<emilio> 3, 1

<Oriol> 1, 2, 4, but I would prefer any

<emilio> fantasai: lol

<bz> nsISelector

<bz> That's NS

Rossen: A lot of votes for number 2 as the first choice

<AmeliaBR> Why was `:is` dropped from the options?

Rossen: Resolve on :where?
... If anyone has a strong reason to change this, speak up now.

RESOLUTION: Name the selector :where

Leading Control

<fantasai> github: https://github.com/w3c/csswg-drafts/issues/3240

fantasai: On that page you see some diagrams that Jan and Niklas sent me.
... The problem we have in CSS that is driving a lot of typesetting people crazy is that we have above and below for text content, and it's very difficult to line up the text with other elements.
... You basically have to figure out how much space there is and use a negative margin. This is not a very robust system for achieving alignment.
... We need the ability to strip out the top part of the line box that is above the text, so that you only have leading between the lines but not above the first or below the last line.
... You also need to be able to strip out the half leading, which comes on top of the ascent, which is some arbitrary number that the font author put in that might not have much to do with anything.
... For different writing systems you want to use different metrics here.
... We need to strip it down to one particular font metric.

<astearns> didn't we talk about a first-baseline-offset property at some point in the past?

fantasai: The proposal is to add two new properties, for the over and under edge.
... Which strips the size of the space down to a particular font metric.
... The proposal is to have leading-trim-over/under properties which strip out the space.

dbaron: I'm concerned about how this works if you have multiple things in a line.
... If the goal is to have two things to line up with each other, adding properties which help you remove one of the things that cause the misalignment helps you get there, but it is not solving the problem as directly as you'd like.

fantasai: We also need the ability to control the line box sizing more precisely.

dbaron: What I'm thinking is that this seems more like a use case for something like line grid, or something line grid-ish.

fantasai: It is not about having a grid.
... It is about having the top align with an adjacent thing, or precisely controlling padding.
... If I have letters in a box with padding, the amount of space between the top of the capital letters and the top of the box, visually speaking, is not the number in my padding property.
... Having a line grid will not make that go away. It makes sure that consecutive lines have a particular rhythm, but it doesn't strip out this space.
... The problem in the images in this issue is that the top of the text is not lining up.

dbaron: One of them is about getting two things to line up, and one of them is about getting uniform spacing around something.

fantasai: The distance between the content box top edge and the text as you see it visually is not controllable by the author.

<astearns> (agrees with fantasai fwiw - this seems useful with or without a grid)

dauwhe: I've seen this problem in my work.

fantasai: Our job is to make it so that you don't need JavaScript to do basic layout.
... (Comparing to initial letter:) We do very precise alignment for initial letter. It is not about measuring the space, it is about getting the browser leave enough space.

<dbaron> I actually didn't finish saying what I was trying to say

koji: Would like to have these metrics be accessible from both CSS layout and from an API.

dbaron: What I was wondering is whether this is going to make other things that we want to do in this space harder.
... Is this an independent thing that is going to be able to float on its own or does it make other things more complicated?
... It's probably ok but I'm a bit worried about it.

fantasai: If your concern is about the line grid stuff, this is just about helping to set where that line grid starts.
... Line grid snaps baselines. Whatever calculation we do here is not going to affect the ability to snap things to baselines.
... And step sizing works on the margin box, so it's not going to be badly affected by this either.

florian: Detail: This needs to apply to the first and last lines in the paragraph, and not just to the direct children.
... This is not a problem with the design, but should be explained.
... If you have several paragraphs, you want this to apply to the first line of the first paragraph, not to each paragraph.

dbaron: So you're saying it should be a non-inherited property that applies to the first formatted line.

<jensimmons> if this is helpful to anyone, I just wrote this demo to help me: https://codepen.io/jensimmons/pen/GYYpvN

koji: I support it.

RESOLUTION: Add a leading trimming feature to the CSS inline spec.

<dbaron> Probably most people will mispronounce "leading" when they see it...

<astearns> they do

<astearns> maybe line-height-trim instead?

<heycam> github-bot: end topic

<dbaron> trackbot, end meeting

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/???/Arial Bold Condensed/
Succeeded: s/would ../would trigger patent exclusion for CSSWG members/
Succeeded: s/eays/easy/
Succeeded: s/before and after/::before and ::after/
Succeeded: s/validation/invalidation/
Succeeded: s/theme/theme out/
Succeeded: s/L2/Level 2/
Succeeded: s/AR/ar/
Succeeded: s/0.5ps/0.5ts/
FAILED: s/it’s a ratio/it’s not a ratio/
Succeeded: s/resoloved/resolved/
Succeeded: s/glazou: ???/glazou: is a AR always above 1?/
Succeeded: s/add more styling capabilities to elements/add more styling capabilities to @font-face/
Succeeded: s/multiple languages as a single language/multiple languages for a single font/
Succeeded: s/it/box-sizing/
Succeeded: s/consider it/consider box-sizing/
Succeeded: s/fantasai:/fantasai,/
Succeeded: s/the reason/whether/
Succeeded: s/schedules/schedules and secrecy requirements/
Succeeded: s/?/adoptedStyleSheets/
Succeeded: s/collectiono/collection/
Succeeded: s/zcorpoan/zcorpan/
Succeeded: s/webcompat/webcompat problems with the initial value being auto/
Succeeded: s/spend on it/spend on it (and thus delay work on subgrid)/
Succeeded: s/clip-path/clip/
Succeeded: s/mast/mask/
Succeeded: s/chrishtr/mstange/
Succeeded: s/things,/things, but the purpose of consistency is easy of learning, and people are clearly confused, so/
Succeeded: s/toface/to-face/
Succeeded: s/community topics/houdini topics/
FAILED: s/Dont' have any/Don't have any plans, expect to do a half-day side-track during CSS for anything we need to discuss/
Succeeded: s/Bert/plinss/
Succeeded: s/element that has the first line/first formatted line/
Default Present: krit, rego, emilio, jihye, cbiesinger, ericwilligers, smfr, lajava, vmpstr, tantek, mstange, heycam, Xiaolu, philipwalton, fantasai, rachelandrew, melanierichards, majidvp, skk, dauwhe
Present: krit rego emilio jihye cbiesinger ericwilligers smfr lajava vmpstr tantek mstange heycam Xiaolu philipwalton fantasai rachelandrew melanierichards majidvp skk dauwhe
Found ScribeNick: fantasai
Found ScribeNick: myles_
Found ScribeNick: emilio
Found ScribeNick: TabAtkins
Found ScribeNick: gregwhitworth
Found ScribeNick: mstange
Found ScribeNick: gregwitworth
WARNING: No scribe lines found matching ScribeNick pattern: <gregwitworth> ...
Found ScribeNick: gregwhitworth
Found ScribeNick: mstange
Found ScribeNick: mstange
Inferring Scribes: fantasai, myles_, emilio, TabAtkins, gregwhitworth, mstange, gregwitworth
Scribes: fantasai, myles_, emilio, TabAtkins, gregwhitworth, mstange, gregwitworth
ScribeNicks: fantasai, myles_, emilio, TabAtkins, gregwhitworth, mstange, gregwitworth

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 23 Oct 2018
People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)