Meeting minutes
github-bot, topic w3c/
[css-overflow] Scroll direction of unicode-bidi: plaintext.
<github-bot> OK, I'll post this discussion to w3c/
github-bot: none
<github-bot> JoshT, Sorry, I don't understand that command. Try 'help'.
github: none
<CameronPsychpsyo> I think Emilio said he might only make it to the IRC channel and left comments on Github
github-bot, topic w3c/
[css-sizing] "behaves as auto" needs clarifications
<github-bot> OK, I'll post this discussion to w3c/
fantasai: when we drafted the auto stuff, we were handy wavy about it
… it behaves as auto in most but not all cases
… interesting case brought up is margin collapsing
… box with margin height, its last child can collapse with its own margin and the following sibling
… but if it's not auto, like length or %, then margin collapsing does not happen
… so the auto behaviour gets set if % is resolvavle because the container has a definite height
… spec says that when the % can't resolve like in block layout, the height is calc in a way that behaves as auto
… but spec checks computed value which is %, not auto
… so the spec says you are not supposed to collapse the margins
… but since written, there are new keywords so what is the right thing to do in various cases
… brings up question that some impl include margin collapsing and some check the computed value specifically
… so on one side, people says it should behave as auto in all aspects. on the other side, should it also unpack margin collapsing
TabAtkins: comment in issue asks for concrete proposal
… right now it doesn't actually propose what is changing
… and asks for some examples
… i do not support a change now before more concrete pros, suggestions and what this means for pages
fantasai: I filed this originally to flesh this out a bit more
… oriol and anne got into this case of margin collapsing
TabAtkins: in that case, I don't know what you want to edit
… if that's only one aspect
fantasai: they're all probably independently editable
… i can't remember what other side effects there are for auto
oriol: I think that if we say something behaves as auto, then behaviour should be as close to auto as we can
… we could add dependencies on computed values, but I do not see agreement on that here
… we should only add the auto behaviour when there's a good reason
<CameronPsychpsyo> fwiw, I got confused by the spec wording on this while working on Ladybird once.
oriol: this allows margins to collapse as auto. it's only webkit that checks the computed value
<oriol> w3c/
oriol: several impl seem to collapse margins like webkit but there are some cases quite non-sensical
… explained in linked issue
… I think Blink's model is better
<Zakim> fantasai, you wanted to distinguish what's obvious from spec terminology != what's obvious for authoring
oriol: even then it's only webkit behaving in this way. I think it should allow collapsing margins as auto
fantasai: so I want to make a distinction for what makes sense based on what's in the spec
… the original reason for this behavuiur is that % are not resolvable
… we just needed some term to hook onto this idea
… would like to ask what will the author most likely expect to happen
… if most obvious is to collapse margins with % heights, then we should align on that
… if it's not, then we should do the other thing
<TabAtkins> I think my point is still just that this issue doesn't actually contain any proposals (but there's an *implied* proposal about margin collapsing, which has a proposed WPT change to match)
astearns: web compat is likely a good reason not to follow auto if impl are not following spec
… but also, does anyone know what is the test case that anne added is checking
oriol: i think originally came from a test cases I added
fantasai: test case about stretch keyword
… in most cases, it's treated as implicit size and margins will not collapser
… if it has a child, the margin will not collapse as it's not expected to match
<TabAtkins> Currently all browsers pass the test in its current form https://
fantasai: if the container that the stretched item is in has a height, we run into this issue of whether to collapse
… for stretch, the size of the container could be resolved
… but when you have explicit height, the margins collpse, and when you don't, the margins don't collapse
… that's confusing
oriol: for author expectations, when the spec is checking this, it's making sure margins only collapse when they align
<TabAtkins> *Is* this issue specifically about the margin-collapse issue? Elika stated it was about several things.
oriol: so you can make the bottom margin of last item and parent collapse
… if parent has explicit size, you can't guarantee that you can do that
<fantasai> It was an issue about "we have some wording that needs tightening up here". And the margin collapsing issue is the main one that we have identified.
oriol: if this case, a % behaves as auto for sizing purposes, then margin collapsing purposes is the same
… I think it makes sense to allow margin collapsing in all cases
fantasai: if you pick 40px as the size of your box, we still don't collapse the content
oriol: true. earlier linked to issue about it.
… but point is whether you guarantee it adapts to content
… % behaves as auto always, so size will always ???? contents
fantasai: depends on where you use the box
… if someone sizes margins and padding with some assumption about whether margins collapse and then put it in container with auto height, it may or may not collapse, it's confusing
… could cause unexpected breakage
… if you set it to stretch or 100%, you're expecting something different to happen
… for behaviour to change depending on what you put it into, it's confusing. if you want the other bhaviour,. you can just ask for it
… if you are expecting margins to collapse sometimes and not other times, that's not a winning thing
… depending on the spacing you want, you'd have to compensate for the collapsing or not collapsing
astearns: as Ian and TabAtkins suggested, we can take this back to the issue with one concrete example
… we can have an idea of what we want to resolve on before this comes back onto the agenda
github-bot, topic w3c/
[css-navigation-1] Add pseudo-class selector to target the element that initiated the outgoing navigation
<github-bot> OK, I'll post this discussion to w3c/
noamr: issue that was open for a while
… we wanted to address with css-nav-1 spec
… quite ready on it's own. to select a link that triggers a navigation
… unlike active pseudo, it stays on
<fantasai> Like :active in IE5!
noamr: so we defined in css-nav-1 as trigger-link. we define exact processing model of when it starts and stops being active
… we found about css-nav that it's a reflection of the Web Navigation API
… has concept of source-element.
… not sure if that was the best name
… can be a link, a form or submit button
… things that trigger a navigation
… trigger-link is both the source element and the link
… could be confusing otherwise with forms
… could say we have a navigation trigger element that also includes forms
… current case is a pseudo class called trigger-link
… activated on link you click
… stops when navigation is done
… when you swap to the new document
TabAtkins: echoing discussion, odd specialised just to links when there are forms doing nav
… assuming more general pseudo class, this is just adding 'a'
<fantasai> +1
TabAtkins: could we just let people use the tag name in the selector to say which they want to match on?
<CameronPsychpsyo> Don't image maps also have links in them?
<PaulG> web components and aria-* components will probably like to support this as well
noamr: not great in my opinion, but could be wrong. we can change that
TabAtkins: concern is just in general it's not great to encourage authors to use links when they should use a form
<fantasai> +1
TabAtkins: if these touch both cases, they should work on both cases
<dbaron> CameronPsychpsyo, image maps have <area> elements these days -- HTML4 had a feature that allowed them to use <a> as well but it got removed in HTML5 due to only one browser implementing it.
astearns: have maybe terrible idea. if we need something different than active for the lifecycle, then maybe this could be a parameter on :active
<CameronPsychpsyo> Yes, but <area> can have an href to link to elsewhere when clicked.
fantasai: had the same concerns as TabAtkins
… think a more general definition is better
… for more general name, could be navigation-source, connecting to the source term
noamr: sounds good to me
… i was nervous about trigger because we also have nav trigger
<PaulG> navigation referrer?
bramus: but you can have source and destination so having source here could confusing
noamr: still related
fantasai: what happens if you have a link that navs to a different part of the page?
noamr: it will still activate and pseudo will still be active
… as long as Navigation API is going, it will apply
<dbaron> I think (somewhat agreeing with Bramus) that some people might see the "source" as the page you're navigating from rather than the element that caused that page to navigate.
noamr: because it's very quick, effect might not be different from activ
fantasai: old versions of IE have more persistent versions of :active
noamr: will be active until animation is done
… same with smooth scroll
… as long as the spinner goes, this will also be active
fantasai: in general, a good idea
bramus: hearing +1 on the ask for a broader selector
… if we could have that, I'd be very happy as that was the original request
… then you just prepend an element selector
… for name, dbaron said he also agrees people might confuse source with source vs destination
… suggested in issue :navigation-trigger to make it clear it's the element and not the 'from' page
fantasai: the source element API is already using that term so reflecting that makes sense
… and you can't just select the page with a selector so there's no room for confusion here
noamr: we could just not use 'source' in other places and say 'from' in those nav to and from use cases
astearns: and the Navigation APi uses 'source' for this concept?
noamr: yes
astearns: any concerns about adding this regardless of the name?
… given everyone seems OK with it, shall we give a provisional name of :navigation-source?
… or :nav-source?
noamr: i like the shorter one because it makes it feel like an element
<PaulG> I still like referrer but it's harder to spell?
noamr: if we do something that is a navigation source, we can distinguish from a nav source
bramus: I'm leaning to full version
<romain> prefers to avoid abbreviations
fantasai: can we have nav-up, nav-down?
… would be consistent with that and nav is shorter to write and we have precident
<rachelandrew> I prefer not abbreviating in this case
astearns: precedent in specs or implementations?
<TabAtkins> i do prefer abbreviating
florian: I recall that nav-up and nav-down are not interoperable
astearns: at least on IRC, people are on both sides
TabAtkins: and HTML spec has nav element
<ChrisL> happy with nav
astearns: resolve on adding :nav-source in short form?
<noamr> :navigation-source-trigger-element
fantasai: I'm ok with either or doing a Twitter poll
<ydaniv> +1 on short form
<TabAtkins> :navigation-starting-element
<CameronPsychpsyo> "source" or "src"?
PROPOSED: add :nav-source pseudo for this use case
<noamr> source. src feels like a URL of sorts
<TabAtkins> lol we spell out "source" everywhere else in css
RESOLUTION: add :nav-source pseudo for this use case
<ntim> i'd rather abbreviate source than nav
people discuss src or source
<fantasai> PROPOSED: Add :nav-source to select element that initiates navigation (whether link or not)
<davidjmarland> sauce
<ntim> :navigation-src
RESOLUTION: Applies not just to links
github-bot, topic w3c/
[css-anchor-position-1] Add flip-self-inline/flip-self-block keywords
<github-bot> OK, I'll post this discussion to w3c/
astearns: Might be the shortest issue ever!
<TabAtkins> +1 to the keywords
fantasai: we have flip-inline and flip-block which use writing mode of the container
… we have use cases to have the writing mode of the element itself
astearns: both self and the parent?
fantasai: yes
… we should be consistent
… and make them the keyword that you use for the custom select dropdown
astearns: any concerns?
PROPOSED: add flip-self-inline and flip-self-block
RESOLUTION: add flip-self-inline and flip-self-block to position-try
<ntim> position-try-fallbacks
RESOLUTION: Use these values for ::picker(select)
github-bot, topic w3c/
[web-animations] How/when do the "rangeStart/rangeEnd" attributes the Animation interface get evaluated
<github-bot> OK, I'll post this discussion to w3c/
weinig: issue is that in the animations API in the JS API, there are places where you can set values
… the setters have been defined to take strings
… but the spec says 'parse this as...' and then a CSS property
… in this case, the issue with range-start is that it takes what it should parse, and animation-range-end allows a length-percentage with any number
… you can have length relative units
… there's no spec on how to resolve those units
… it's not happening during the style resolution
… in other places, there's an API that takes a string and parses it as a CSS construct
… normally we limit it to absolute units because we don't have a way to resolve relative units
… in this bug it's about range-end, but we can take the same idea to other cases and limit to absolute length units and %. % are ok because they resolve later
<TabAtkins> I'm fine with this
<fantasai> sgtm
astearns: is it possible to define some way to resolve %?
weinig: % are not an issue. it's just relative units
astearns: so can we just pick something to resolve against like the root?
weinig: there are other options we could takw
… one is to treat it like media queries
… say that relative units resolve against the initial style. could be different to the root
… could say the units resolve against the target element of anim if it exists
… then need to define what happens if target is null
… and we need to pay the sync style resolution cost
… or alt, we could define alternative time that these values get resolved against an element
… i think they're all complicated
… someone would need to figure out the tradeoffs
… right now not implementable
… want something implementable in a uniform way
<ydaniv> SGTM, until we define this properly
weinig: or maybe in future we'll have a generic way in JS to say 'given this element and unit, give me the computed px values'
… someone in bug says this makes it useless
… don't know if they were thinking if % weren't allowed
ydaniv: [that was me]. it is limiting, but it's OK to patch this now and spec it later
astearns: I agree and I'm fine, but if there is something that would be better for authors where we can arbitrarily pick an element without author choice, it might be better to do that than only have absolute units
… if we do only absolute units now, we'll need an opt in to get the better behaviour
weinig: we can just do a parse error for relative units for now, and then not have a parse error in the future
TabAtkins: I agree with sam. don't want to resolve on root element
… would rather make it parse-time invalid now
<fantasai> +1 to TabAtkins and weinig
weinig: my proposal is for both the string form and type CSS form
<TabAtkins> yeah there shoudln't be any difference between those two
weinig: you can do a typed value that is an em value, so we have to treat them the same here
PROPOSED: make it a parse error to set string values or typed CSSOM values that don't use absolute length units or percentages
weinig: one other clarificatio.n also precludes things like var, sibling-index() and anything that requires an element to resolve
<fantasai> sgtm
<fantasai> We can always relax restrictions once we figure out what's the best thing to do
weinig: but the implication is we're excluding anything that requires an element context
PROPOSED: make it a parse error to set string values or typed CSSOM values that require an element to resolve
RESOLUTION: make it a parse error to set string values or typed CSSOM values that require an element to resolve
weinig: I've filed a bunch of issues like this. should I turn them all into a single issue that we can resolve on later?
… or should we go through them one by one?
astearns: I'm fine with that if they're all basically the same decision
… we can even make it an async proposal
github-bot, topic w3c/
[css-view-transitions] [cssom] Inheritance of non-existing pseudo-elements.
<github-bot> OK, I'll post this discussion to w3c/
TabAtkins: emilio pointed out that we have a WPT that expects a non-existant vt element to inherit from its non-existent parent
… because vt pseudos aren't creating but you're asking for the computed style
… emilio suggests that we inherit from the existing element rather than assuming a non-existent tree
… the dev who did this had a crash and so he fixed it in a way and doesn't have opinions on which way it should go
… I also agree
… we probably should not be making assumptions about the state of a tree that doesn't exist
… I suggest we take emilio 's suggestion
… just say it's inheriting from the originating element
<bramus> sgtm
fantasai: so this is only while they don't exist? and then when we have a tree, do usual behaviour?
TabAtkins: yes
<TabAtkins> el.gCS("::foo")
TabAtkins: and there is always in the query an originating element to look at
fantasai: there was a term for ultimate originating element
TabAtkins: yes
PROPOSED: non existing pseudo-elements are considered to inherit from their ultimate originating element if you query the computed style
astearns: any suggestions or objections?
RESOLUTION: non existing pseudo-elements are considered to inherit from their ultimate originating element if you query the computed style
astearns: do we have any other situations like this?
TabAtkins: you can't ask for an element that might not exist. it's only pseudos where this can happen
<noamr> "A non-existent pseudo element falls in the forest. what style does it have?"