<kochi> Is it too late to put constructable stylesheets in the agenda https://wiki.csswg.org/planning/berlin-2018?
<kochi> (constructable stylesheets : https://wicg.github.io/construct-stylesheets/index.html)
<astearns> I've added it to the "If there's time" section, kochi
<kochi> Thanks!
<scribe> ScribeNick: dael
<Rossen> Rossen Atanassov, Microsoft
<rego> Manuel Rego, Igalia
<Loirooriol> Oriol Brufau, observer
<shane> Shane Stephens, Google
<surma> Surma, Google
<TabAtkins> Tab Atkins, Google
<flackr> Rob Flack, Google
<ericwilligers> Eric Willigers, Google
<birtles> Brian Birtles, Mozilla
<dbaron> L. David Baron, Mozilla
<gsnedders> Geoffrey Sneddon, Invited Expert
<majidvp> Majid Valipour, Google
<rune_> Rune Lillesveen, Google
<jihye> JIhye Hong, LGE
<iank_> Ian Kilpatrick, Google
<cbiesinger> Christian Biesinger, Google, observer
<astearns> Alan Stearns, Adobe
<myles> Myles C. Maxfield, Apple
<smfr> Simon Fraser, Apple
<fantasai> fantasai, Invited Expert
<rachelandrew> Rachel Andrew, Invited Expert
<Guest47> Richard Rutter, Clearleft
<florian> Florian, Invited Expert
<tantek> Tantek Çelik (tantek.com), Mozilla, (also AB)
<monica> Monica Dinculescu, Google
github: https://github.com/w3c/csswg-drafts/issues/2388
<plinss> : present+ Peter Linss, Invited Expert
florian: The snapshot has a section with the general policy of the WG. WE don't do vendor prefixes but do draft maturity. The WG can make exceptions based on market pressure. WE don't list what the exceptions are. fantasai created proposed text and a list of examples.
dbaron: One of my concerns about the list is over the past 15 years we've cleared various features at various times that are scattered across minutes. The mor complete the list is the more serious it is to have them listed.
fantasai: We should get to the point where the list is comprehensive. If there are things not on the list we should add them.
florian: It's a not so repub isn't hard.
<astearns> section under discussion: https://drafts.csswg.org/css-2018/#experimental
dbaron: WE may find two or three missing over the course of a month.
fantasai: That's okay.
florian: Review the list?
fantasai: I think my list was things we've already cleared. There's stuff we didn't clear buy shipped.
florian: [reads list]
... Chris suggested we add conic gradient
... Focus-within?
fantasai: I don't think explicitly cleared, but it's shipping.
florian: That's the list. fantasai has an edit proposed. If everyone is happy we'll merge.
dbaron: Is this the edit with similar text?
fantasai: Yeah, we have to clean that up.
dbaron: I'm fine with merging after the duplication is sorted out.
florian: Are we okay resolving to merge this after editorial improvements?
astearns: And going forward as we approve things edit this in.
fantasai: And if there's something that needs to be added to the list let us know.
dbaron: There's things that should be on the list but I couldn't find minutes.
fantasai: Just list and say "I think we cleared but I couldn't find miuntes"
dbaron: Some were over 10 years ago.
fantasai: Put them in and we'll find them or re-resolve
Rossen: Other suggestions?
... Objections?
RESOLUTION: Merge this text in after editorial changes
florian: There are 4 open issues.
Link in the agenda. Do we want to publish before dealing with
them?
... One is an issue in bikeshed, the indexes are slightly
wrong, I wouldn't block on that. Document conformance should be
added from 2.1, that should happen. But do we want to block on
it?
... Last is sort of related, issue #1139. NOthing lists what
the fields in the propdef table means. Snapshot could be
that.
??: I think that's the right place.
florian: It's a new snapshot because it's a new year.
Rossen: Sure. It will be more
beneficial to get the snapshot out.
... Was issue should we block on those?
florian: yes
Rossen: Obj to proceed with publishing snapshot as-is including the open issues?
RESOLUTION: proceed with publishing snapshot as-is including the open issues
Rossen: Both myself and astearns have been asked many times why we have so much agenda, we cna't make it through everything, should we go back to 4 meetings?
TabAtkins: We have an open afternoon right now.
astearns: It'll fill.
... Given the last month of telecon that were too long for the
time.
... Unfortunately tpac is in September so it makes it awk to
put 3 in before that.
dbaron: TPAC will be about a month earlier than this year.
Rossen: If we needed to get 4
next year that would make it hard unless we do one in
December?
... The fact is that at least since Seattle 2017 we've been
running every meeting with parallel tracks as much as we can so
we can absorb more agenda and have more focused areas of
discussion.
... Even with these efforts we're still running tight on the
schedule.
... Is 4 meetings in general something we should think
about?
... If we do go back to 4 we have to start thinking about what
the first meeting of 2019 would look like.
fantasai: Given the way TPAC is scheduled it's likely best to think how many months between a meeting.
florian: Yes and no. 3 months after TPAC is December.
fantasai: TPAC is end of OCtober?
dbaron: Yes.
fantasai: So we might do 3
meetings in 2019 because TPAC, but then it might be 4 the next
year.
... The problem with this is it's been 6 months since the last.
IF we space out better it'll work better. I'm happy for 4 a
year but if it's a short year one ever 3 months-ish will be a
short year.
Rossen: We know we have TPAC and TPAC-next. end of Oct 2018 and Spet 2019. THat's a shorter 11 month period.
fantasai: If we want to space every 3 months we should do Jan next year.
dbaron: I was trying to work out even spacing for 2 between TPAC and it's early Feb and late May/early June.
fantasai: And 4 would be Jan/May/July
astearns: Would anyone be able to host late Jan/early Feb?
Rossen: That's the 2 meetings?
astearns: That's even with the 4 because we can't move the first any further back due to holidays.
TabAtkins: If we'll do Feburary we'd be happy to do another Sydney.
fantasai: You've got no one based in Sydney.
shane: I'll still help.
Rossen: We have Sydney as a potential host in early Feb/late Jan. Any other ideas or offerings?
<dbaron> I think even spacing would be early-mid February, and then late May / early June
Rossen: Should we resolve on a
end Jan/early Feb 2019 meeting? That's long enough after Leon
TPAC.
... We've got one offer for hosting and we'll figure out if
anything else comes.
fantasai: Maybe Apple can host?
myles: Our new building doesn't have anywhere to do that.
TabAtkins: We discussed yesterday and Mozilla Toronto might host in the summer.
dbaron: It's nice in the summer.
<dbaron> Strict averaging would say meeting the week of February 11, and then the week of either May 27 or June 3
Rossen: Proposal: End Jan/Early
Feb 2019 for the first winter meeting.
... If we only want one meeting between that and TPAC it may be
late Feb.
... So we have a tentative Feb 2019 meeting and we'll have to
work out logistics.
... Objections to winter 2019 meeting, potentially in
Sydney?
RESOLUTION: We will have a late jan or in feb 2019 meeting, possibly in Sydney
Rossen: Based on Sydney we can see if we need to squeeze two more in that year or jsut one.
Rossen: I'm not sure who put the issue in.
tantek: I put that in during the telecon where you said Edge will support horizontal % modal.
astearns: As I recall we set ourselves up for this. We left ambig in the spec and let it fester.
tantek: Worse, we created ambig in the spec.
astearns: If anyone has ideas on how to avoid in the future.
florian: Impl were already disagreeing when we made it ambig.
TabAtkins: Agree. That's when we officially undefined it.
astearns: Maybe we shouldn't do that.
fantasai: This is the first time since I"ve been here where we had a disagreement where we couldn't agree what the spec should say. There are places where we make something undefined because we need to move forward, but we plan to align. Every time we've had technical discussion we've figured out what the spec should say. This is the first time WG was completely split.
tantek: We had agreement at NY F2F and we resolved and changed the spec and then we undid it in Paris. So we started with agreement and then, correct me, but TabAtkins brought forward a case and saying we disagree.
shane: I don't think that's what happened in BY.
TabAtkins: Our impl disagreed and we said we'd check it out.
<tantek> Resolution from 2015 NYC f2f https://lists.w3.org/Archives/Public/www-style/2015May/0314.html
Rossen: Agreement on symetric resolution of % was led by us based on how we wanted overall model of grid. One of the guidance principals was we wanted it as symmertric as possible. When we discussed we generally agreed this is the right modal to have. If it was in a vacuum I don't think we would have changed.
<tantek> "RESOLVED: Flexbox top/bottom margins and padding resolve against height."
Rossen: However we had a requirement to keep flexbox same as grid. When we wanted to backport flexbox it was already widely implemented. People were using the % padding hack for aspect ratio and that was a problem for Google when they tried to flip to the new model. Google came back and said they'd break everything.
<astearns> as much as is possible I would like to limit the re-litigation of this particular issue, and instead see if there are suggestions on how to avoid this impasse in the future
Rossen: It wasn't a disagreement,
it was a statement of facts that we are going to break the web.
What tantek is pushing for is we have a model that makes
perfect sense and we have new people using grid and flexbox and
let's have something that makes sense.
... Fastforward to 2 months ago, we were the only ones shipping
grid for a long time. When other impl shipped grid we had more
and more pressure to fix the bugs.
... I think this is more of an outlier then a practice we have.
I don't think we've had this drastic reality. Yes we must avoid
this on all counts.
florian: I don't see how we find a process to avoid getting stuck on not agreeing. Once you have the split, what do you do?
tantek: Other reason given to
have the split is the potential utility of the aspect ratio
hack, if that's something we want we should have a feature for
that. We as a group didn't follow through and that's also
partly to blame. If we were to have a good proposal that might
have been a way out of the compat mess. That didn't
happen.
... I understand we've been backlogged on agenda and
bottlenecked on editors, but with hindsight that might have
been avoidable.
fantasai: There was also a fair
number of comments in the bug where author feedback was also
split. A bunch of authors wanted it to work the way MS did and
a bunch that wanted Chrome.
... Some were about aspect ratio, but some where about other
aspects of using it. If there had been strong feedback one way
or the other that would have pushed us a way to go. We had a
split in the WG and a split in feedback. I don't think that's a
pattern we tend to follow. Yes, we were backlogged and in
hindsight. But I don't think this is a systematic problem.
<fantasai> s/in hindsignt/in hindsight there are always things we could have done better/
astearns: We can close this saying we don't think this is a good pattern and we don't think we normally do it, but if anyone sees us falling into it please call it out.
tantek: Because we had split author feedback combined with that the browsers hack were pressured.
astearns: When we find outselves in a place where we want ot leave something undefined we need to do analysis
tantek: WE did analysis. We knew we needed the feature.
fantasai: People disagreed on what was the right thing.
florian: It was not the only issue. If aspect raio had been solved it may have helped.
tantek: To solve it we needed and
aspect ratio solution. It might not have been enough.
... If we're ever tempted t oundefine we should use this as a
prediction of what will happen.
fantasai: WE knew this would happen. We'll put both and someone will have to switch due to web compat.
florian: There was a note from the time saying it was sucky.
tantek: You don't have 2 major impl sticking with one way of doing it for no good reason
fantasai: We knew it would come
to a web compat fist fight. WE could not come to a consensus.
WE discussed many times for hours. You can't tell us we didn't
try. We decided this will suck, we have two impl, and web
compat will drive it in one direction or another. WE've never
had that problem before and I don't expect us to have it
again.
... We'll always have web compat bugs. They're not due to
intention of the working group. THat's not what happened here
and makes it different from every other case.
Rossen: I think the lessons have
been learned. I don't think we can have anything in a more
formal way to avoid these sort of issues. I don't believe we've
made such issues intentionally besides this one. I'd encourage
anyone who wants to come up with a process to put your thoughts
on the wiki to say this is a dangerous one and let's not repeat
the padding/margin issue.
... It sucks when this happens, users the most, because they
get crappy output, but that's where we ended.
tantek: There's an additional conclusion which is when there is web author demand for a feature and that's expressed via a hack that should be a strong signal to the group to make it official.
TabAtkins: tantek that's a spec you could have edited.
fantasai: You're complaining why didn't anyone submit a patch.
tantek: Any of us could have done it. I'm making a forward looking statement where if we see this in the future it behooves us to pay attention.
Rossen: We can make a new flag in github saying to elevate this.
florian: You can't with a missing feature.
Rossen: Why not?
tantek: Prior example was advancemenet with animations and transitions back in 2000s with webkit. It was massive changes to the platform where we didn't act soon enough and we had to endure a lot of pain.
Rossen: Let's move on.
florian: johannas is the only
editor of page floats and he's not funded to do this work. He's
uncomfortabe both that it's not progressing and that his name
on it and it's not progressing.
... I think it's good to have multiple people on the hook.
rachelandrew raised her hand and I'm interested.
rachelandrew: I'm happy to take it on, it has relation to the work I'm doing in multicol
florian: I would propose to add rachelandrew and I in addition to Johannes
Rossen: Is Johannes inerested in remaining?
florian: Yes.
Rossen: Objections to adding rachelandrew and florian as editors to page floats
RESOLUTION: add rachelandrew and florian as editors to page floats
github: https://github.com/w3c/csswg-drafts/issues/2458
florian: Had resolution to move
the definition to css sizing
... There was a large re-write while it happened. I filed this
to disagree with some of it.
fantasai: We want to add a
normative reference to UI 3. 2.1 refers to width and height but
doesn't say if it's inner. UI 3 has a diff written in English
to figure out how it works. It's an awful bit of spec writing
we shouldn't add.
... Proposal is add a normative reference from CSS Sizing to UI
3. Also maybe fold the edits into 2.1 so it's not necessary to
have this.
florian: And this monkey patch
once written is mostly obvious, but when unwritten it's not
clear.
... For referring to the monkey patch sounds good.
... Other part I raised is that you defined normatively width
to mean inner-width and we haven't checked all our specs.
fantasai: In 2.1 any instance where it's ambig it's the inner width
<tantek> tantek: and test cases revealed bugs in the definition as well that we had to fix in css-3-ui
florian: Sometimes it means the value of the property.
fantasai: In those cases it's the value minus borders and padding. THat enture monkey patch it's the inner width. The fundimental concept of 2.1 is it's inner width. There might be cases outside of CSS 2 where we were less careful, but those are bugs in the spec.
florian: What I was thinking about is in practce in practical speech they're unavoidable. I'd rather normatively define and anchor term that's non-ambig so if you run into width you don't have to wonder if they meant innor or forgot to be careful
tantek: Also dimensional width vs property width, computed, cascaded etc. It's not just inner vs outer, but also the width as a property in cascade. There's multi levels of ambig going on.
florian: To solve that I'd like the inner to be an anchor term which you can link the in bikeshed.
dbaron: Are the places where we say width and mean inline size?
florian: That too. In enough cases it's ambig but obvious enough and in those cases we should fix.
dbaron: I think the fact that there is a second thing we ought to audit for maybe we should not assume here.
fantasai: CSS L3 I haven't looke dat position, but the rest are careful to use block size.
dbaron: But non-layout.
fantasai: Any spec TabAtkins or I worked on is being careful. Anyone else editing might want to look.
tantek: I think we're not focusing on the issue. I think we should resolve this that CSS UI defines box sizing. And then the plan moving forward is separate.
fantasai: Box sizing moved tot he sizing module. florian opened asking for the monkey path to be copied into box sizing. I think it's better to nromaive reference CSS UI from Sizing. Box sizing should have been in the sizing spec so it was in CSS UI.
gsnedders: CSS UI 3 have a normative reference?
tantek: No. It's fine in CSS3 UI and it's because form elements behave that way. For external specs I'm not sure why we're talking double direction here.
florian: Prop is keep the box
sizing definition out of UI 4 and into Sizing with a reference
to the monkey patch in sizing and refer to sizing where it has
better sizing. Mostly defined in sizing and refer to the monkey
patch to CSS UI 3
... To be able to apply the monkey patch to 2.1...the other
thing you dropped from UI to sizing is that i normatively
defined width and the like.
fantasai: Box sizing has the terms defined but in pieces. Inner is separate from min/max size. But the terms to exist in sizing. I didn't feel like duplicating your version.
florian: I felt you underfined them.
fantasai: Inner is defined in
sizing. In CSS 2.1 the spec is written witht he understanding
that width means inner-width. If you want to read it with the
context of box-sizing existing you need to know that. MOnkey
patch can be compressed to a sentence saying it's referring to
ineer-width/height. All your changes were about that.
... I think we should resolve on having 2.1 so that the
potentially ambig references to width are corrected so we don't
need awk patch.
tantek: We need to open an issue on 2.1. This issue is multi spec.
fantasai: That's fine.
<gsnedders> I am strongly in favour of fixing 2.1 here.
Rossen: Let's take resolution to 2.1
florian: Can we normatively reference the monkey patch from sizing?
fantasai: Yes
Rossen: We need to update CSS 2.1 by normatively pointing UI 3?
fantasai: 2.1 to be edited.
tantek: That's why I'm suggesting a separate new issue.
Rossen: What's the 2.1 fix?
<fantasai> https://www.w3.org/TR/css-ui-3/#box-sizing
tantek: In florian's long comment on 2458. Errata CSS 2.1 bullet point.
florian: Trying to craft the wording isn't group. We should open the issue and until we fix 2.1
Rossen: Prop: Add an issue and a
fix for 2.1 to disambiguate width for inner and outer
width.
... Obj?
RESOLUTION: Add an issue and a fix for 2.1 to disambiguate width for inner and outer width.
<br type="15min">
<gsnedders> FYI: I want to have some discussion about future editing of 2.1 at some point during the week, probably as some breakout at some point.
<tantek> gsnedders: count me in :)
Rossen: Let's get going
Rossen: WE need to action someone to do the updates of 2.1
Rossen: We still have one 2.1 editor in the room. So we can action him to make the errata edits.
florian: I think we should be setting up the build system.
fantasai: gsnedders should be working on it
Action tantek to make updates to CSS 2.1 Errata
<trackbot> Created ACTION-871 - Make updates to css 2.1 errata [on Tantek Çelik - due 2018-04-17].
[planning for dinner]
github: https://github.com/w3c/csswg-drafts/issues/2179
<tantek> In practice we have 3 2.1 editors in the room, since fantasai has been editing 2.1 for many years in practice, and gsnedders voluntered to edit 2.1 also
<gsnedders> And we have a resolution adding me as an editor from last year.
<tantek> (those two statements should be outside of this issue)
astearns: We resolved to do that.
And we're still waiting on Facebook to join. majidvp added a
comment saying it'll be okay, please do this thing. Hopefully
they'll find time to continue the spec.
... You're not interested in co-editing majidvp ?
majidvp: I mentioned in the discussion I'm happy to be the fallback, but I prefer the original editor.
astearns: Hopefully soon we can get Facebook in and you two can continue.
Rossen: majidvp thank you.
... Do we have a timeline on when this will come from WICG?
astearns: TBD because we need an editor.
Rossen: If we added majidvp today can we move the spec?
astearns: It's overcommitting majidvp I think.
majidvp: The right thing is give the current editor some more time.
astearns: We'll wait on a response.
fantasai: Status is that there
are some tests failing. Main issue...some we can explain as
impl bugs. Main issue is that the automatic sizing of
orthogonal flows, we didn't have interop to begin and then we
added rules for scroll containers. There's no impl of what's in
the spec. It's not a difficult fix.
... Status is we should have an impl report soon to show, but
we need a couple of bug fixes.
... I was going to finish impl report, but got sick so it
hasn't happened yet.
Rossen: Is impl report something you need help?
fantasai: I just need a day. koji
and I spent time going over test results. It's just taking them
and putting them in a document that explains.
... We need bug fixes and updated CR> We should also CR in
writing modes L4. It's everything we cut from L3.
astearns: Is there FPWD?
fantasai: Yes.
florian: Sideways, sideways-lr
dbaron: All maintenence?
fantasai: Duplicated
<dbaron> s/maintenance/maintenance to level 3 also in level 4/
fantasai: Updated CR for L3 and transition to CR for L4 and we'll need 2 impl of the sizing stuff in the spec.
koji: We also need to make an exception for the PR. fantasai can do the change in 2 weeks for Gecko. I don't have a timeline for Blink so may not get second Impl in time. I don't think it's worth to wait.
florian: WE need to convince W3M that we should ignore these things. Fix is easier than explain away if it's reasonably easy
koji: Our impl...I'm doing other positioning.
dbaron: Is there stuff going to CR in L4 that hasn't been to CR before?
fantasai: Nope, it's just a straight copy of what's been there before.
Rossen: Let's get a resolution to republish Writing Modes L4
fantasai: L4 transition to CR, L# update CR
Rossen: Obj to transition L4 to CR
RESOLUTION: Transition L4 of writing mode to CR
RESOLUTION: Republish L3 writing modes CR
florian: Do we have to set a minimum time before it can PR?
Rossen: 4 weeks is okay.
RESOLUTION: CR transition period for L3 is 4 weeks
Rossen: Anything else on writing modes?
fantasai: Not at this point
Demo link: https://wicg.github.io/spatial-navigation/demo/blog/
Spec Link: https://wicg.github.io/spatial-navigation/
jihye: spacial navigation is
ability to nav between focusable elements.
... florian and I introduced this last year. Most browsers have
not histocially offered these features. Some browsers have
allowed it using arrow keys. No browser now provides it by
default. Some web apps provide using JS libraries.
... We thought to spec basic behavior and provide some
overriding APIs of the default behavior.
... [shows spec]
... florian and I wrote the ED. It includes processing model
which is basic browser behavior. We're writing overriding APIs
and the CSS property.
... I also made a polyfill based on the spec. It's not
complete, but supports main behavior
florian: This is mostly not a CSS
spec right now. From a CSS sense it's as if everything was
auto. We need to say what happens when a user tries to do
things when everything is auto and then we have some JS for
chaning auto.
... We started with CSS properties but with limited data on
what authors and users want we thought it was better to get the
basic APIs and then add additional CSS properties based on what
people do with JS. This works without JS, but the JS overrides.
The questions we have later is things the depend on
layouts.
jihye: [shows demo]
... In the page there are several focusable elements and you
can nav using arrow keys. You can do with tab, but you have to
press more times. Web apps using inline layout spacial nav is
very useful.
... [shows a page with many examples of layout]
... There's many corner cases, including hover cases.
florian: One of this thing we're interested in seeing is the long standing questions about re-ordered sequential navigation and we think they want spacial navigation. We're interested to see if people still want the re-ordered sequential after we've done this.
tantek: There's always been an a11y desire to make sequential work without a spacial view.
florian: This is a side note.
Rossen: We've been impl and
shipping spacial nav on Xbox with Edge for a few releases.
WE've precieved it as a general UI nav and for that reason
we're allowing a generic UI for a11y and anything, including
XBox controller or input based on connect motion or verbal
commands is just working. WE don't have to deal with all modes
of input and user input, that's tempered by a11y
interface.
... Also, from what tantek said, I've been in the APA WG and
that's been their top gripe aboutflexbox and grid and
everything else. I'm very interested in anything we'll do to
help those efforts. If we're not solving this for a11y as well
I think we're missing out.
<tantek> agreed with Rossen
florian: We have an open issue saying if you have use cases not solved by spacial nav for reordered sequential please tell us. We haven't heard, but maybe don't have the right eyes. I don't think there's anything incompat, but I've heard conflicting requests for the seqential and some of them may be solved.
tantek: It's better to look through minutes for joint CSS WG and a11y meeting at TPAC 2017
florian: I did. There's multiple
people saying conflicting things. I suspect that some of these
conflicts would go away once we have spatnav.
... But that's not what we wanted to talk about today.
... For issues, one thing that became apperent is stat nav
isn't easy. If the first focused button is several pages down
you want to scroll until you get to it. When we tried to spec
in relation to scroll we found it difficult to define in terms
of CSS. There's some in overflow, some in scroll snap points,
some in CSSOM view which defines API. These bits are not well
integrated. The more proceedural approach in CSSOM view doesn't
talk about snap points.
<jihye> https://github.com/w3c/csswg-drafts/issues/2322
florian: We have two issue son the agenda. #2322 and #2323
<jihye> https://github.com/w3c/csswg-drafts/issues/2323
<myles> A+
florian: IT's the desire for a scrolling spec to exist. #2322 we found a need to refer to a thing that can be scrolled.
github: https://github.com/w3c/csswg-drafts/issues/2322
fantasai: Do you want something that can be scrolled by the user
florian: Yes and that can be manually scrolled. It's not already scrolled all the way in. If it's all the way down it cannot. If it's the last mandatory scroll point you cannot. If a use wants to scroll in this direction, could they? We found a need to try and talk to that. You can describe this, but there's no single term.
fantasai: What do you want the WG to do?
florian: These two issues call for a scrolling spec that folds all the things in so that we don't have to talk about proerties from many specs when talking about scrolling. What's the WG stategy to make scrolling easy to refer to.
fantasai: Termonology in Overfow makes sense if it's general. If it's API-based it should be in there.
florian: This is anchoring termonology.
fantasai: CSS Overflow
florian: We needed a thing that can be manually scrolled in another direction and the other is scroll directionally by a UA defined amount taking into account all the other properties.
fremy: Scroll a single user?
florian: If you pressed the down arrow, find an anchoring term
fantasai: Scroll in intended direction.
<fantasai> https://www.w3.org/TR/css-scroll-snap-1/#scroll-types
florian: There's the classification of things in Scroll Snap.
fantasai: We can move that section to Overflow.
Rossen: I think what fantasai said is CSS Overflow is where termonology should be. If it's not there point it out. In terms of additional features that live on those termonologies, we shouldn't have base definitions in snap points
florian: So propose terms to Overflow with notes to spec how they effect that term
majidvp: Overscroll introduces scroll boundary and that's something you alluded that you needed so it makes sense to refactor.
florian: I'll propose the relevent edits.
Rossen: For issue #2322 do you need anything for the group?
florian: No, I need to propose.
myles: I wanted to ask for clarifcation on the xbox. Were you talking about logicial vs visual ordering or talking about making the API work for a11y
Rossen: Mine was about that we've
been asked many times to help a11y WG by defining how the
flexbox reordering, or grid, plays nicely with a11y. a11y for
all the providors today is still tree based and based on
content order. If you reorder using flex order or you target
visually different grid cells you are disconnecting visual
order from content order.
... This has been the #1 issue the a11y WG has been asking us
to help them solve.
... They have also been asking in addition for help with
generla spacial nav. Put aside flexbox and grid, if they have a
canvas with a bunch of little thing sin side how do the
spacially navigate. Like with a map. Then going back to
HTML/CSS how do you nav over a document.
... I sympathize with the effort. I hoped florian and jihye
work would help with both things. I hoped that they wouldn't
reinevent the wheel with how it currently works. If this is
something that can aid this.
florian: Clarification. We're trying not to reinvent. Our model is closer to the one that exists in Chrome. It doesn't exist by default, but you can get it in a console command and it's similar to presto. I don't know the type of stat nav.
iank_: It's similar to presto when it was in opera.
Rossen: myles does that answer?
myles: Yes.
<jihye> https://github.com/w3c/csswg-drafts/issues/2324
github: https://github.com/w3c/csswg-drafts/issues/2324
florian: background 3 says border radius changes border edge. If you link to border edge it doesn't say if it effects it. The spec that does talks about border edge but not the other varius boxes. It makes it really awk to refer to in other specs. If we can define the border edge in level 3
TabAtkins: I like shaped border edge to refer to it.
florian: And we can add all the thigns that can be shaped.
TabAtkins: WE wanted to refer to the things outside.
florian: If it effects hit testing it should be there.
iank_: clip-path yes, but I don't believe share-outside
florian: Editors will do it? I think it's border and backgrounds L3
TabAtkins: Sure. Seems fine.
astearns: Since it's just missing testing to go to rec....it's just a term. As long as you don't open hit testing in backgrounds and border I'll be happy.
Rossen: prop: Add the definition of the border shape edge to Borders and Backgrounds L3
RESOLUTION: Add the definition of the border shape edge to Borders and Backgrounds L3
github: https://github.com/WICG/spatial-navigation/issues/29#issuecomment-378153116
florian: Is this an operation
that we can use or is it hard to impl?
... When you have dialogs or things popping over a page you
can't click on the things behind. Currently tab nav can get
behind, but spat nav is relatively new. It would be nice that
if an item can't be clicks on it can't be navigated to. It
could be possible to declare these things as inert, but if we
didn't have to ask authors it would be good. Can we or is it
hard to impl?
tantek: It would require nomative reference to can you click on it.
florian: We haven't defined how hit testing works so we don't have to depend on it.
iank_: If there's a 1px edge and you want to test exposed.
florian: If it's barely visible then you made it visible.
iank_: This is asking for hit testing on an area and you have to determine the area.
smfr: As you scroll and animations run you have to animate every frame. IT's super hard.
Rossen: Every imple layers
differently. WE layer for perf. We layer things interdendently
for painting and hit testing doesn't benefit on that. Mech of
doing hit testing may suffer, but hit testing isn't highly
demanding.
... Thing to point out, though, I would encourage you to take a
look at HTML AAM or ARIA AAM and see how they go about it. They
define landmarks and all of the sites I've seen with pop ups
they have a11y.
florian: There are mech to say obscure things aren't interactive. Given our thing doesn't have compat bagagge if it's necessary for authors to make them do it that's okay, but if it could be authors don't have to do anything it's a nicer experience.
Rossen: You'd discourage authors to do what's rec for a11y reasons.
florian: I'm hearing hard to impl and poss not desirable, don't do this.
fremy: We have a JS exposed function called ms-elements-from-rect where we return all elements that match the rectangle. Rectanlges are easy but chapes and SVG things get harder. If you want to define this as there is an element for the entirey of the object. Can you click on some pixel is hard.
Rossen: And then you get into the argument of where is the origin of the pixel.
fremy: If you want to see if there is one object that completely covers and object that's easier.
Rossen: And with this you don't get the order of the rects.
florian: So rely on author actively disabling things.
Rossen: Which they should do for a11y. I would continue encouraging people to support that a11y agenda. It should work for everyone.
tantek: florian you said you saw contradicting items. most comprehensive write-up is from James Craig. I would reach out ot him to ask for him to point you to latest thinking
github: https://github.com/WICG/spatial-navigation/issues/41
<jihye> https://github.com/w3c/csswg-drafts/pull/2494
<florian> https://github.com/w3c/csswg-drafts/pull/2494
florian: We have a few media
features that let you test input device to try and help author
of page media query their way into more convenient UI
... We propose it would be useful for an author to know if user
has sequential or spacial nav available to them.
... If you're on a think that lacks a mouse but has stat nav
grid is fine. If you lack a mouse and stat nav you likely want
visually linear. Having a ability to know if they match seems
useful.
... I made a PR, can we add that to MQ L5.
... Web signage would be an example.
fantasai: Reasonable to me. might want to distinguish 4 direction navigation and navigation that can go in many directions.
florian: I'd suggest opening that as an issue on the feature.
fantasai: Okay.
smfr: I'm slightly opposed to a MQ that exposes a user setting because it's extra fingerprintting.
Rossen: If you have a mobile decide and connected to a hub that gives you board and mouse, what's the expectation.
florian: It's also for authors to not be unreasonable. You can query an ability to hover when there's a mouse. You could reorder the whole page at that itme, but it would not be wise.
Rossen: I also want to echo smfr concern about user fingerprintting. We're going through extreme efforts to not bleed anything into the user logic level that would ID users with disabilities.
<tantek> Also want to echo concerns about fingerprinting
florian: I think this is different where devices that provide this always and devices that allow it. if it's an opt in functionality we can say you're allowed to opt-in.
dbaron: I'm a little sceptable to the fingerprining because the site can tell what the user is using. They'll get mouse events.
smfr: True if those events go to a frame doing detection. be detection without user input is more dangerous.
fantasai: I would hope we'd get more browsers impl spacial nav.
myles: Would MQ enable when you press modifier.
florian: The MQ would not be on when you press a key, it's on when you're in a browser where you can.
myles: So every page gets this MQ when you update your browser the internet looks different...being a spacial nav enabled browser is different then saying optimize your site for spacial naviagtion.
florian: I don't think it means
perfer. It's like when hover is on. If I'm about to do a design
that would look terrible without that feature, I should rethink
when you don't.
... This isn't meant as a request for prefering design for stat
nav. Design for stat nav is typically a typical design.
myles: So if every major browser ships, what would a web author do with this MQ?
florian: If you're on a device with no pointer but there is stat nav it's reasonable to have the same main layout we see. If their's neither it's not so great. If you're on a TV with no tab key you might want to know.
smfr: Are there any UA where tab
is only form of nav? WE should envourage people to write web
content that works everywhere, not content right with a mouse
but terrible with tab. This feels a bit too far. And we
shouldn't assume there's UA with only terrible tab navigation.
Those are bad UA.
... I'd prefer not to have this.
florian: Summerize the feedback as "hmm maybe, come back with stronger use cases"
smfr: Yeah.
Rossen: I'd say "hmm not really
but if you come back with something stronger we'll
reconsider"
... Anything else for spacial nav?
florian: Just a request for people to look at what we've done.
<florian> https://wicg.github.io/spatial-navigation/
Rossen: That's jihye and florian
github: https://github.com/w3c/csswg-drafts/issues/2452
fremy: [whiteboards]
... Issue is pretty simple
... When you have a float and another float later that has a
different shape constraint. We try and size the BFC with the
remaining space in the block. If your BFC is taller then the
point where size constraint changes then you have to do
something.
... In FF every time this happens a new layout is drawn and we
try to resize the BFC. It's repeated as many times and needed.
It's an arbitrary number of relayouts.
... Chrome looks like some weird behavior where they tried to
do it but it broke websites.
... We'd like to find something int he middle
Rossen: We'll layout in the first available space and then slide the other block down until we find space. We're optimizing for not relayout so we avoid overlap
astearns: But you're not using the width of the space.
Rossen: We are. The BFC might become wider and shorter so you don't intersect. When I wrote this in like IE9 you do an intersection with all yoru geometry until you fit the space in your initial BFC and you use that.
iank_: Did you change recently?
Rossen: Maybe but not so much
fremy: We do first layout and move the box at the first place you fit.
Rossen: We may not do relayout.
dbaron: One problem with the
description. While making something wider generally makes it
shorter, sometimes it makes it taller. Like when you have an
overflow:hidden and the image has a fixed width if you make it
wider the image get taller.
... You can't assume that it's going to not overlap.
... Other thing is these overlap cases happen on real websites,
esp wikipeia. Browsers that get this wrong have overlapping
content in wikipedia.
... FF in wikipedia cases have like 3 layouts.
iank_: We looked into this. We think our current impl is a little funky. One thing we can do is you look for next available area that is unbounded and doesn't have a float blocking it off at the bottom.
Rossen: You can have a zig zag of floats. If you want to start filling it with a zig zag you'd push the first BFC down in this case.
iank_: It will skip the zig zag. That's the best 2 pass.
fremy: 2 pass option, first we try and use the size. If you overflow with another float you can try to get the smallest distance that you have in the future and try to layout in that space. If that's more then the minimum space you do the usual.
Rossen: What do you mean it'll work in 2 passes?
fremy: If it doesn't work we do edge behavior, but if it does you find the smallest space in the future. You simplify the geometry and the remaining space is what you try to use.
Rossen: Furthest left and furthest right can be disjointed.
fremy: To get 2 passes. [missed]
<iank_> Here is a testcase I created a while ago... https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=5370
florian: So furthest left and right, not shortest distance.
dbaron: There's one assumption
about gecko you made that I think is wrong. I think you assumed
we did a layout...let me check...
... I think we're using intrinisic min-content width and not
doing layout.
... We're doing a layout to determine the height.
Rossen: That's the one we're talking about. THe widths are created by the geometry.
dbaron: I need to read it.
iank_: One thing to point out is when you introduce margin collapsing if the BFC 'smargin effects position of floats.
Rossen: If BFC psoitions after the floats it will have to be in content order. Only thing that could be effected is BFC position
iank_: Margins collapsing through in an empty div.
Rossen: But they're already committed.
iank_: Not until you know the
final margins.
... You can have a margin that's further down in the doc that
effects where the floats re positioned.
Rossen: You'll have to show me the test case.
Rune: top margin will collapse through?
iank_: Yes.
Rossen: dbaron did you get this into your head?
dbaron: Kinda. There are a set of positions you can reject without layout.
Rossen: What does 2.1 spec suggest?
astearns: From my recollection when defining shapes, FF has the right behavior where you slide things until it fits.
Rossen: What do you mean by slide? In fremy picture, would you consiter sliding?
astearns: I recall line layout, not BFC.
Rossen: line layout is regid.
dbaron: Line layout has the same problem because the line can get longer.
astearns: And trying them at a lower position can change the width.
Rossen: [draws]
... Assuming this geometry is what you have to play with (large
multi tiered box) what do you mean by sliding?
... Let's assume everything above is taken. First place you can
position is here Then you arrive and get to some kind of
layout. Is sliding on he x axis? one of the geometries?
dbaron: For both line layout and
BFC you have 2 nested loops. If you fail to fit....the outer
loop is over your y position and the inner is over your
reduction in width.
... If you try and place here and fail because it intersects
below you narrow your width to account for the intersection and
try again. You go until you fit or you fail but there's no more
floats.
... That's the inner loop. Outer loop is we failed to find a
width for this vertical position so then we move down to the
next vertical position with more room.
... In the simple case what we impl right now is look for next
position where something changes.
... Traditional floats it's not that bad, in shappes we should
loop
iank_: On shapes we switched shape sizes and BFC so shape has no effect on BFC.
dbaron: I hink you can exclude a decent amount of things.
astearns: Changing what you're doing depending on float or shape I don't think that makes that much sense. Everything you can do with hspaes you can do with sufficient number of floats.
iank_: We have use counters saying it's not used so we switched it off.
astearns: I'm not that concerned with BFCs but everything we're discussing as a problem for BFCs is also a problem for placing first line of non-BFC content next to lfloats.
iank_: SLightly different.
Rossen: In general what you desc makes sense. I hope there's a spec where we can define this. I failed to find anything when I impl.
astearns: Section 9.5.1
dbaron: 2.1 defines it for lines
but not well for BFC is my memory.
... All float rules in 2.1 are in terms on constraints and this
is a case where constraints is a bad way of defining it.
fremy: This is potentially a lot of layout.
iank_: In our new impl of block layout we went with FF behavior going through each oppotuniry.
Rossen: From user POV tat's the better behavior.
iank_: I can describe the 2 pass
method.
... The 2 pass one is layout and the based on I think
min-content you lay out in one of the areas.
fremy: I proposed you first try the first position. Then you try the furthest right space. If it's bigger then the min-width you put the element there. That's what Edge is doing. I'm faily confident that'll work almost all the time and then you don't have to layout again and again. As an author you don't expect this to be super expensive, but it can be.
<rego> this non-BFC example has overlapping issues on Blink/WebKit http://jsbin.com/yebelixowu/1/edit?html,css,output
florian: If I understand dbaron in the case without minimum the extra part you compress. But if you have the minimum you have to do a re-layout.
dbaron: Most expensive case is
[whiteboards] a table and you're dealing with a shape that has
a really rough uneven edge.
... So you keep having to relayout.
iank_: This is why we switched this off for shapes.
fremy: We only do this a few ties
and then give up and overflow the floats.
... What this would do is it would try to lay it out and if it
doesn't work it would put the table under the shape.
astearns: I'm not sure the example of the narrowest place works for this example.
dbaron: Depends on what the shape is.
fremy: If the table fits it fits. If it's bigger it goes undermeath.
myIes: I think the point is it's valid, but not good.
astearns: I see the appeal from
an impl side, but as an author I can't imagine wanting...if an
author wants the content as far up in the layout as possible so
FF and half of Chrome is what I expect an author would
want.
... If we have to have a strategy to avoid re-layouts, giving
up and going past the floar may be better.
fremy: Chrome would like to remove this thing.
iank_: We've removed shapes. WE
added counters to shapes and barely saw usage. I believe shapes
now only effect line-boxes.
... As people add lots of lfoats, sure. Shapes is easy to go
into every max-length.
dbaron: I think saying shape-outside doesn't effect BFC is a reasonable comprimise.
astearns: We deferred to 2.1 in the spec.
fremy: [missed]
dbaron: I think wikipedia looks better with the algo.
fremy: In most cases you do it in 3 which gets you same result.
dbaron: It's reasonably common that the narrowest thing will be something narrow.
astearns: Because we counter with shapes and BFCs is small, a different rule for BFC is fine. But I'd hate that to be preceident for line layout.
iank_: That's easier because when you do the first pass you know the height.
astearns: I don't mind as long as it doesn't apply to line layout.
florian: Are you sure problem isn't for lines
dbaron: You don't change height of the line depending on it getting narrower. If you shrink the line it might shrink, but it might not increase in height. If you shorten the line and it gets shorter in height, but it fits, you leave it.
iank_: Always works in 2 passes.
Rossen: And BFC the norrow you make it the longer it gets usually.
dbaron: You can guar the shortening look is 2, the moving down can be more loops.
fremy: 2 proposal. 1 to say BFC....
Rossen: 1) Do all possible layouts which will optimize for the area.
myles: 2) layout to widest. If it
doesn't fix calculate some numbers and if it doesn't fix push
it.
... 3) is always push it.
Rossen: We try and find space for the layout and then push it.
fremy: Reason we're here is we've found 3 is not good on wikipedia.
myles: 1 is what user wants. astearns pointed out option 3 may be better then option 2 for user.
fremy: [missed]
astearns: Option 1 will often find a > min place to put the BFC.
fremy: Not as likely.
dbaron: Depends on the
floats.
... If your floats are like this (smallest on top right) then
you'll be find on the top.
iank_: [whiteboards]
Rossen: Can I make a proposal?
I'm not sure we'll be able to resolve without wasting more
paper. Holding the whole group on this prob. not very helpful.
Let's take this over lunch with the people interested.
... So what we believe is best for user and impl and we'll come
back after the break.
<fantasai> Iank drew two stepped sets of floats, one of decreasing widths on the left, on eof increasing widths on the right, leaving a diagonal channel
dbaron: I think one resolution that solves part of the problem is the interaction with shapes and BFC. Prop: BFC flow around floats don't care about shape-outside.
fremy: If you do shape-outside and you do a float BFC is wrong. If you do shape outside the entire element floats.
florian: For FC it's rare enough it's okay.
Rossen: Shapes with BFC is probably not common. Shapes with text is how feature was intended.
myles: why do we want this proposal
iank_: Impl complex.
dbaron: Gets rid of worst cases.
myles: You just look at mins and maxes
Rossen: Whatever you have with shape you can make with floats.
dbaron: Okay, I take back that we might be able to resolve.
<br type="lunch" dur="60min">
return at 13:35
<iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=5879
Rossen: Let's resume
github: https://github.com/w3c/csswg-drafts/issues/2452
Rossen: This is the picture we were trying to illustrate on the white board. It's intended to illustrate the 3 proposals.
action Rossen send the image of https://github.com/w3c/csswg-drafts/issues/2452 discussion to archives
<trackbot> Created ACTION-872 - Send the image of https://github.com/w3c/csswg-drafts/issues/2452 discussion to archives [on Rossen Atanassov - due 2018-04-17].
fremy: Proposal #3 is when you have an image that overflows you just push it down, but that was also leaving a lot of empty space. Edge is doing that right now.
Rossen: We do one layout. We're assuming inline is in top left.
astearns: BFC tried for full width and intersected with float.
Rossen: Right. If we don't fit because we intersect we try and fit and end up at the bottom (behavior #3)
florian: Width is full width of containing block?
Rossen: Might not. It doesn't fit.
fantasai: That's super weird.
Rossen: And super performant.
astearns: Edge is getting bugs on clearing and leaving the empty space above.
<fantasai> Rossen was explaining that once they've cleared past the floats into a larger-width area, they don't lay out into that larger area but keep the width of the initial reflow
<fantasai> This is what I thought was super weird
Rossen: Say you have a div and a
tiny 0 width float and then another smaller float. In this case
there's a 0 width which we layout the BFC next to the 0 width.
BUt it intesects with the smaller float. Then we slide the BFC
down. Say it doesn't fit and then it's before the small
float.
... you can argue we can fix our bug with behavior #2 which has
different drawbacks.
fremy: Proposal #2 is if it doesn't fit you try one more layout. You try to find first place you can fit the min content of the BFC you're trying to place. If you can fit the min-content and there are no floats limiting the height below it you put it there. Downside is you may end up in a situation where it goes down if the min-width is too small. You try to find somewhere you can fit the min width. It doesn't require any layout. It's a guar valid. Drawback is it could be min width is very small so yo uget very tall.
florian: In this logic if there is several places you can fit do you try all?
iank_: The first one. In this case there's three areas. You start at the first and if it fits you put it there.
fremy: If it doesn't you try the second and then the third.
iank_: It's a 2 pass layout and you're trying all areas.
astearns: It fixes the floated UI issue.
fremy: Option 1 is Firefox. It's literally trying all possibilities.
fantasai: Nobody gets the rainbow where it is?
Rossen: Firefox is rainbow.
iank_: I posted a link at 1:22 pm of a test case for this.
myles: rainbow is FF, 3 is edge, no one does 2.
iank_: Blink and webkit is undefined.
fremy: There's one thing I don't like is that.
Rossen: People use offset flows. [missed] it's the only way to offset floats veritically.
fremy: No gap here (position the float, the then BFC) means that someone really wanted that space.
astearns: So we have 3 which goes below the floats. 2 which makes and attempt based on heuristics and 1 which does the best but is expensive.
fremy: Also will Chrome disable this for shapes.
astearns: Rossen said there was a conclusion.
fremy: [missed]
group decision: no conclusion
fremy: If people won't agree on #2...I thinkw e should resolve on 2.
Rossen: 2 is improvement for us and Chrome and reduced experience in FF.
iank_: The test case I dumped in IRC we do 2 in.
<gsnedders> what test case?
astearns: Would anyone objec to spec the second option?
dbaron: Who does it now?
<gsnedders> 12:22 < iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=5879
many: no one
dbaron: I would object to spec something no one does.
fremy: We can't spec what Chrome is doing. Firefox is option 1. That's better then our version.
astearns: Sounds like we don't agree.
iank_: WE can see how expensive 1 is.
Rossen: We can resolve on 1, ask
whomeever impl it to spec it. If this is performance we can ask
to get some data back. In the meantime other impl...we'll do
something to fix. For normative behavior it's hard to argue #1
isn't the best. It's up to us to figure out easy engineering
tricks to optimize as much as possible.
... So is there objections to #1?
fantasai: Sounds better.
astearns: Objections to spec #1 for BFCs?
fremy: No special about shapes?
Rossen: No, nothing special about shapes.
astearns: If we spec we'd need a floats module.
Rossen: Let's get a resolution about the behavior we want.
<rego> https://github.com/w3c/csswg-drafts/issues/2452
astearns: Prop: The working group preference is to specify BFC float avoidance behavior to match what is spec in 2.1 for inline layout float avoidance behavior
Rossen: ish.
astearns: To follow those
guidelines and spec it well.
... Obj?
RESOLUTION: The working group preference is to specify BFC float avoidance behavior to match the guidelines of what is spec in 2.1 for inline layout float avoidance behavior
Rossen: Where does this go?
florian: 2.1?
astearns: I think floats module. 2.1 is vague on inline.
Rossen: In CSS positioning the fork happened for floats and position.
fantasai: I'd rec not in the same module because psoitioning and floats are quite divergent.
Rossen: That's okay. We can take
the line out of 2.1 and start a module.
... A resolution for that?
gsnedders: If we're removing a line from 2.1 we should have a resolution.
astearns: We're not taking out,
we're making a module to refine.
... objections to someone creating a css float module at some
point?
Rossen: I can create the fork and start it.
dbaron: I can help, but I don't want to be only person
astearns: objections to fantasai and dbaron creating a css float module?
smfr: This isn't about float layout, but wrapping behavior. So if shapes trigger same behavior doesn't make sense.
astearns: Shape outside is in relation to floats and exclusions would tie in.
fantasai: I think floats is right place.
dbaron: I think if I'm putting it with something it would be block layout and that doesn't really have a L3 for that.
myles: That's better then proposal. Rather then a new spec we should have someone take up stewardship of the block layout
fantasai: It has more stuff in it.
astearns: Like with any other
module the bits and pieces that refer to other specs say it's
defined over there.
... Can be floats module, can be wrap. They're pretty
synonymous for css so I don't care on the name.
Rossen: Floats is more specific and targeted.
astearns: Prop: Start a CSS 3 Floats Module with dbaron and fremy as co-editors
RESOLUTION: Start a CSS 3 Floats Module with dbaron and fremy as co-editors
astearns: We have layout stuff this afternoon.
<fantasai> https://www.w3.org/TR/css-grid-2/
fantasai: Issue with grid L2 it
has some proposals and no feedback. I can do anything to go
forward
... Open issues are like here's 2 proposals for subgrid, which
do we want?
... I wanted to bring this up because there's strong requests
from the community to do this, but the spec for subgrid is
there's 2 specs for subgrid. I don't know what to do next.
florian: Is there author feedback?
rachelandrew: I have feedback. Authors really want subgrid. The use cases I've seen are tied to dimension sub grid....the proposal that was pulled from L1 wouldn't solve them. People want the columns to be the sub grid. They don't want to define the rows. Having to locked to both dimenstions would be more frustrating then useful. Things I"ve seen assumed one dimension.
fantasai: Proposal is to resolve on per axis subgrids.
Rossen: Didn't we decide in tokyo?
tantek: We added it as a possibility in tokyo.
Rossen: sgtm. I thought we did
that.
... This is the 1.5 dimension model?
fantasai: No, the way we set
thing sup there's not many changes from one version to the
other. Differences are in green. Main change is for per axis
you need to ensure that if you're interweving the algo of the
parent and child grids.
... Algo is all defined. That's where spec is at. I think it's
complete mostly.
astearns: Do we have impl?
fantasai: I don't think anyone is working on sub grids.
TabAtkins: Mats was interested and opposed the non-per axis. That's what Igalia part impl.
rego: We didn't impl anything yet.
<tantek> Mats is working on it, see the Firefox subgrid meta bug (with dependent implementation bugs) https://bugzilla.mozilla.org/show_bug.cgi?id=1240834
fantasai: Syntatic difference the per axis has a subgrid keyword on grid-template-rows and grid-template-columns. Just one was a keyword on grid-template.
astearns: Would anyone object to single axis subgrid?
TabAtkins: No one has described how to do it yet.
fantasai: It's in the spec. Here's the algo (section 2.4)
astearns: It's spec as a diff to a doc with both.
fantasai: It inlines everything in. It just has two colors of ink.
astearns: Anyone besides TabAtkins have concerns on single axis subgrid.
rego: Seems more complex to impl but it would be good to know use cases. If there are clear use cases where we need this it's fine.
rachelandrew: I brought use cases
to the last F2F but I rarely see something from an author that
works for double axis. An ecommerce site that has a template
where they want it to work no matter if there's 2 rows or 6
rows of stuff.
... Let me see if I can find the examples
astearns: Would people object to 2 axis subgrid?
florian: I think rachelandrew would.
<rachelandrew> https://codepen.io/rachelandrew/project/editor/68cc7a5da9cfbb56c6e8366d7d92e6ba
astearns: I'm hearing some people for and against single axis subgrid but I haven't heard opinions on 2 axis besides everyone thought it was too hard to get to for the first level of grid.
<tantek> IIRC, all variants of subgrid were too much for grid level 1
<rachelandrew> this is a better view, some examples https://codepen.io/rachelandrew/project/full/68cc7a5da9cfbb56c6e8366d7d92e6ba/XWYGMD/
Rossen: I still agree it was a good move to hold it back. To your second point as to if one or two axis is what we want, now that we can reason about it and think hoelistically the one axis is an easy shortcut to cover some use cases but during Tokyo I heard enough compelling reasons to have the per axis. I will admit I haven't reviewed spec. But I prefer the per axis one. I don't think there will be all that much work per axis, at least in our impl.
astearns: Perhaps we could leave it at peole should review the spec and look at the use cases and then come back soon?
rachelandrew: I could probably get more use cases now that people are using grid.
astearns: Is there an issue for choose which appoach?
fantasai: Yep.
<fantasai> https://github.com/w3c/csswg-drafts/issues/2280
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/2280
astearns: I suggest we continue
discussing in that issue.
... Anything else?
fantasai: Whe do we want to return?
Rossen: End of F2F.
astearns: WE can try and bring
this up end of Thursday. Then perhaps we can make a
decision.
... Please take breaks or lunch time if as you read you have
questions.
dbaron: Would it help to get Mats on a call.
fantasai: It would be good to
have Mats look and reply on github.
... I haven't heard from him.
dbaron: If you want me to poke him can you send me what you want me to do?
fantasai: Review the spec and comment.
florian: Also express a preference? Or he always has.
<fantasai> fantasai: And if there's nothing wrong with it say it's good
astearns: Other part of grid L2 as aspect ratio contols
github: https://github.com/w3c/csswg-drafts/issues/1116
<astearns> github: https://github.com/w3c/csswg-drafts/issues/2280
<astearns> github: https://github.com/w3c/csswg-drafts/issues/1116
fantasai: We resolved to add this to the first level of the WD. Just a request for people to let me know.
TabAtkins: Other then that I want a unit on these I think it looks great.
fantasai: unit proposed is ar unit for aspect ratio
astearns: Two options are a bare number or an ar unit
fantasai: I'm open to name suggestions
TabAtkins: I regret not putting unit on flex.
astearns: Could ar be used in other places?
TabAtkins: A generic aspect ratio
florian: It's mathematically unitless.
fantasai: It's a multiplier.
TabAtkins: Whatever the other thing results in multiply it.
florian: Does the unit thing play into if we want to ever use calc on it.
TabAtkins: Numbers tend to cause parsing issues. It causes issues on the flex things. I'd prefer not to keep that. This has a specific meaning so it should be tagged in a specific way. agnles are just numbers.
fantasai: They're not.
TabAtkins: They're radians which are just an ID.
fantasai: Somewhat releated discussion has been aspect ratio units needed, #1173
<ChrisL> how are radians an ID?
fantasai: There was a request for having an aspect ratio in the grid spec. A lot of the cases we want to have are covered by an aspect ratio property. Question was if there isn't an element can you asign the aspect ratio property.
<TabAtkins> ChrisL, Radian is (length of arc) / (length of radius), which is unitless
<ChrisL> an aspect ratio is (by definition) a ratio. It is a length divided by a length, and thus also unitless.
fantasai: You might decde you have a bunc hof fr columns and you want the rows to be 1:1. Once we add this if there's at least one element you can key off of you can auto-size the rest. If you don't put anything the auto row collapses to 0.
astearns: The only things in having that row were spanning it would be weird.
<TabAtkins> Yes, that's my point. We already associate units with "unitless" things, to give it an easily-interpreted meaning and help with parsing. THis is the same deal.
fantasai: One proposal was to
have an ar unit in grid template columns that would represent
the aspect ratio multiplied by the axis. QUestion was what if
they are different sizes
... Proposal I had is 1ar is always 1fr in the other.
florian: You can't map to a colum 'cause you don't know which ot match.
fantasai: I'ts not clear what we need to do.
astearns: And a side discussion.
fantasai: A unit may be useful in this case.
<ChrisL> remember though that whenever we add units, it stops those things being used in custom properties, because we can't divide by united values
astearns: So do you want to resolve to add a ar unit?
TabAtkins: If we accept hte gap syntax I feel we should have a unit.
ChrisL: Remember when we add units you can't use them in custom properties. You can't devide by an ar.
TabAtkins: You can, ot works now.
astearns: Objections to adding an ar unit to the grid 2 spec for align content and justify content?
<TabAtkins> (I've been slow to add the functionality to calc(), but we resolved to do so a while back, and Typed OM allows it.)
RESOLUTION: add an ar unit to the grid 2 spec for align content and justify content
astearns: Anything else on grid 2?
<ChrisL> fair enough; would be good to see that agreement in the spec, and implemented
fantasai: It's just those 2 things. Once we have agreement on subgrid and someone has read it I'd be happy to request CR.
astearns: I'd like to get an impl started. I'd like to see progress on grid area styling proposal.
fantasai: That's grid 3. grid 2 is just subgrid and this one other small thing. Styling of grid areas is more complex spec-wise for sure (uncertain about impl-wise). In terms of figuring out the spec that'll be harder.
github: https://github.com/w3c/csswg-drafts/issues/2356
<florian> https://florian.rivoal.net/csswg/grid/grid-span-auto-001-ref.html
florian: I was laying out a page of manga using grid so each cell is a grid. It should layout like ^
<florian> https://florian.rivoal.net/csswg/grid/grid-span-auto-001.html
florian: Defining a bunch of
columns and rows and everything can fit, but it's manual.
... Here's what you get ^
... It has unneeded empty spaces.
<TabAtkins> Very simple example: https://github.com/w3c/csswg-drafts/issues/2356#issuecomment-379878492
florian: I think this boils down to current sizing algo not considering enough things. It's descried as a possibly improvable heuristic. If we agree this is a good thing to solve...it sounds desireable...I think this is linear programming solvable by constraints. I'm not good enough at math to put the steps but I think this is solvable.
TabAtkins: Simple example ^
... [explains example] We take the largest of the planned
increases so we're not loosly wrapping each item. Ideal would
be the latter image. It's one possible version.
florian: I believe an algo exists that we could solve it, or are we too locked into compat.
fantasai: I think we should be able to make the adjustments. I don't think anyone depends on this slight amount of slack. As time goes on we might get more constrained but I think we're not at that state. IF we could solve it it would be great, but I don't know how to do it.
florian: I might be able to research the thoroetical algo but I'm not righ to say if impl-able.
fremy: I've been working on some layouts and you can do a post-process to reduce the sizing.
TabAtkins: This example (bottom of link) it shows one possible switch. BUt there's several ways to solve it like making the columns 50,250,0, which is a big change from the current way they lay out.
florian: Some examples have a
range of solutions, mine has one solution.
... I think it's worth looking into if there's a general option
that we're not blocked in. I'd appriciate a mathematically
inclided person to help. Maybe do the current algo and squish
would work. I
fremy: browsers are impl grid and we don't want to change whole algo so that's easier.
TabAtkins: And your site may be doing it for you. In the manga example your images have known widths, it's just easier if CSS does it for you.
fantasai: TabAtkins and I can take an action to look at post-processing step to see if that works. Maybe send a email to bert with a link to this issue to see if he has some insight.
ChrisL: We was talking to people from Monash univeristy with expertese.
fantasai: We also had César who was working on an impl of Bert's grid spec.
<Rossen> dael, here's the illustration that should go with the BFC discussion (issue 2452) https://lists.w3.org/Archives/Public/www-archive/2018Apr/0001.html
florian: I think the trickier part is that this is more complicated. If we have auto sizing it's simplier. If you have one min and one max you span. It's much harder to explain to people that don't know CSS but I'll try.
astearns: Anything more?
florian: Nope.
github: https://github.com/w3c/csswg-drafts/issues/2177
rego: Quite related, You have an item that spans 2 columns. One of them is outside it's flexible track and we weren't sure what would be the best result. We're not sure what's the core approach. Rossen was tyring to clarify in the last comment.
astearns: There's a specific tweak to the algo you propose?
rego: Original algo was aligned that you don't expand a track with a flexible track sizing. Maybe we can open the use cases.
fantasai: We should try Rossen suggestion in the issue and see if it works. I haven't fully through it through but that's what I'd want to try.
Rossen: When we looked we played
with magizine layouts. One recurring thing was when you have a
splash page when an item that spans x columns and want to
influence rest of layout. Those columns need to be flexible
when you're on a browser. That was the original
motivation.
... Since then in the issue...we can go either way. I don't
think there's enough concept to support one or the other. What
I proposed should work.
fantasai: Makes sense to me.
astearns: Do we need a resolution to edit in Rossen proposal?
fantasai: Resolution to add Rossen proposal and we'll revisit if there's a problem
RESOLUTION: edit in Rossen proposal in https://github.com/w3c/csswg-drafts/issues/2177
github: https://github.com/w3c/csswg-drafts/issues/1420
astearns: We've discussed in the past.
TabAtkins: As florian says from third to last comment, right place to start reading is the one above.
<fantasai> https://github.com/w3c/csswg-drafts/issues/1420#issuecomment-378751428
TabAtkins: florian obj to current spec are 3. 1) in current spec you can't robustly fix the ratio of the defualt column gaps
florian: fixed that
TabAtkins: 2) default behavior of space between ends up with not the correct ratio because space-between space is added. Trivial fix, if you set column-gap to 0 it works. Solving it precisely would incolve special cases multii col if the column gap and so we'd be against that.
<fantasai> sorry link to comment is https://github.com/w3c/csswg-drafts/issues/1420#issuecomment-303958104
florian: You should not set the column gap to 0, though, because depending on the space you end up with it might be 0 and it's unreadbale.
TabAtkins: Then you set padding.
florian: I'm not completely opposed to your proposal. Setting gap to 0 it can be mushed so you get padding on the edges. Typically multi col has text, though,a nd if you don't have roon you fallback to block which is good. BUt if you're forcing padding for space you keep the padding when you collapse.
TabAtkins: I disagree. So you
want space around. You leave column gap at 1em and padding to
1/2em on either side. I don't see why when you go to 1 colum
that you don't want the 1/2em gap. You put it there for a
reason and I don't see why it goes away. It goes away in multi
col because it has no gaps, UBt you're explicitly putting the
gaps.
... If a single column you want the text flush you'd want that
in many columns.
fantasai: Like if you have 1
column and you split to 2 you don't want padding on common
container but you want a gap between the 2.
... Regardless, I'm opposed to different calc between multicol
and grid.
rachelandrew: Authors wouldn't
use space around if they're not okay with gaps on the outside.
If you didn't want that you'd use space-between.
... I agree we want to be able to maintain the 1em so people
don't set column-gap to 0.
florian: This issue traces back to before we merged the models. Now we have. i'm okay with what you proposed, we jsut never discussed it. It was just added to the spec. If everyone agrees.
fantasai: Prop: Alignment and gaps in multicol behave exactly like grid.
astearns: Close no remaining changes.
TabAtkins: I could go with a note for how it works.
fantasai: I think people know how to do padding. They figured it would for grid so you'd have to have anot ein both.
florian: There's many ways to space in grid that don't require figuring this out. I think a note wouldn't hurt. Doesn't have to be multicol specific, but I think it would help more there.
astearns: I'd prefer the note
because it shows we considered this, discussed, and have a
solution. as people read they can agree or disagree. WIthout a
note it's fairly opaque.
... Prop: alignment and gaps in multi col behave exactly like
grid and we will add a not explaining the issues in the issue
and how to solve them
... Obj?
RESOLUTION: alignment and gaps in multicol behave exactly like grid and we will add a note explaining the issues in the issue and how to solve them
github: https://github.com/w3c/csswg-drafts/issues/1299
fantasai: SelenIT commented that rachelandrew article had the opposite meaning of row-axis and column-axis as what's in the grid spec. We only use them in a handful of spaces and since most people learn grid from rachelandrew it's probably better to match her.
rachelandrew: I've commented before that people struggle to learn this. People are used to a main and a cross which you don't have in grid. People are explaining it all sorts of ways It's gone around and around.
fantasai: 3 options. 1 is don't change the spec 2 flip to match rachelandrew 3 remove termonology.
<fantasai> Reasoning for the spec is in https://github.com/w3c/csswg-drafts/issues/1299#issuecomment-298106439
TabAtkins: I'm in favor or removing the termonology. Both schemes make sense. Flipping to the other doesn't have a compelling reason because other people will not understand. WE should use block and inline
<fantasai> terminology is in https://drafts.csswg.org/css-grid-1/#grid-concepts
rachelandrew: I prefer block and inline.
Rossen: rachelandrew can you fix and teach people the way we have intended this to be spec?
rachelandrew: I'd prefer us to use block and inline.
Rossen: I think it's fine but also spec what the row and columns are correctly.
fantasai: Note that the axis names appear 3-5 times total.
Rossen: I'm slightly opposed because the column and row axis are something which applies to internal layout of grid. Easy to rationalize which is which. Even thought inline and block axis apply externally the two aren't nec the same.
fantasai: Exactly the same.
... Question...which is the row axis? Horz or vert?
Rossen: Vertical.
fantasai: It's horizontal in the
spec.
... If we want to match your head we need to flip.
Rossen: Row is if you add more rows so it's how it advance.
plinss: Thing you put in a row progress horizontally.
astearns: I hear these terms aren't used much in the spec. What damange does removal cause?
TabAtkins: Every time we use the terms we also call it block or inline in parans.
fantasai: There's no occurance of these terms where both aren't used.
astearns: Usless terms. Cause confusion. WE should remove.
<ChrisL> row-progression-direction
RESOLUTION: Remove these terms from the grid spec
<rego> the last comment in previous issue: https://github.com/w3c/csswg-drafts/issues/1299#issuecomment-377490475
Issues list: https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-align-3
<fantasai> https://github.com/w3c/csswg-drafts/issues/2297#issuecomment-376263348
<rego> was suggesting about if it'd make sense to change the properties "grid-column-start" to "grid-inline-start" and "grid-row-start" to "grid-block-start" and so on
github: https://github.com/w3c/csswg-drafts/issues/2297#issuecomment-376263348
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/2297#issuecomment-376263348
<fantasai> rego: no
<rego> fantasai: :)
fantasai: it was to discuss 0ing out a % vs the entire expression. Example calc (10% + 10px) 0ing the entire expression is what's impl. 0ing the % is more meaningful. This is for purpose of calc intrinsic size calc of element.
dbaron: It's also continuous in terms of what happens when you have a calc that approaches 0 and you remove the calc.
<fantasai> Comment summarizing issue: https://github.com/w3c/csswg-drafts/issues/2297#issuecomment-376263348
TabAtkins: Are we okay with some properties having a different indefinite percent with calcs.
fantasai: I prefer 0 out the %
florian: Justification to 0 everything other then it's what we have
fantasai: Id din't hear anything.
Rossen: I agree with fantasai. 0ing the % makes more sense. Having a box model with some % and non-% values results in the same logic, where we would zero out the % values and add the rest of the defined sizes
fantasai: For size we ignore
entire calc. We closed that in #1132. SOrry,w e throw out the
calc and treat as auto. Fallback to initial value
... That makes snese for sizing in a way it doesn't here is if
you fallback to the original that has some kind of meaning. In
this case there's no meaningful value for margins and
padding.
astearns: In only 0 out % for calc that's not sizing it's a slight descrepency.
fantasai: correct.
florian: We can do calc of 10%+10px is the same as 10px but we cant do auto+10px because that's not defined.
astearns: Arguments against only
0ing out % on non-sizing use of calc
... Obj?
<fantasai> (Florian was responding to Alan's question of why we throw out the expression for sizing props)
RESOLUTION: zero out percentages on non-sizing use of calc
fantasai: We're waiting on dbaron
to get back to us on a pile of Alignment issues.
... #1611 is open
<fantasai> https://github.com/w3c/csswg-drafts/issues/1611
github: https://github.com/w3c/csswg-drafts/issues/1611
fantasai: You have a flexbox and
inside you have items with last-baseline alignment but the
flexbox is less then you need we have to decide how to align
them. Just like for first baseline you align and then start
align at the top.
... but what if it's too small to contain all the items. In
that case, what happens? Do we continue to align at the bottom
and overflow the top or do we take the things that are too big
and put them at the bottom and they no longer participate in
base alignment.
astearns: From I can access and read safe is better, but from design unsafe is better.
myles: impl difference.
fantasai: We were generally unsure before.
myles: have we asked authors?
florian: Can we default to safe? Default ing to safe sounds...safer? And let authors opt-in.
TabAtkins: We don't let you set it. It seemed like more switches then you needed access to.
fantasai: We could make it possible to combine the keywords.
florian: I'd prefer default safe and have the keyword.
astearns: We last left this that someone would write a blog post.
fantasai: That was not done.
astearns: I don't think we should assume we will add a switch. we should decide based on probablility that this is a weird edge case so it's not worth our time to have a switch.
TabAtkins: That's why we haven't done it.
Rossen: Can we resolve on choosing safe? If someone squeaks really hard we'll solve it.
astearns: Objections to using the safe behavior in this case of last-basline alignment?
fantasai: All using the alignment properties.
astearns: In this case with content that will not fit in it's container and we faill to be able to last baseline align things things will overflow in a safe direction.
RESOLUTION: In this case with content that will not fit in it's container and we fail to be able to last baseline align things things will overflow in a safe direction.
fantasai: New WD once dbaron says they're okay?
astearns: Objections to new WD once we get through some of the remaining open issues?
ChrisL: I'd rahter be told when it's approved, not we approve some time in the future.
Rossen: Let's publish now and again later.
astearns: WE just resolved 2 things.
fantasai: One was no changes.
Rossen: The one for calc was in sizing?
astearns: Objections to publishing a new WD of Alignment with the one edit from the earlier resolution.
RESOLUTION: Publish a new WD of Alignment with the one edit from the earlier resolution.
<br type="short">
astearns: We should get started again.
github: https://github.com/w3c/csswg-drafts/issues/2384
TabAtkins: This is for min-width
and height. Do they fallback to auto or 0? General rule is we
fall back to initial value. Is that 0 or auto? Initial used to
be 0, changed to auto.
... 2.1 explicitly says they're treated as 0, but it was prob
on the assumption 0 was the initial value.
... Only real case is you have a flex item and you can't
resolve the min-height should it be auto or 0?
... I'm of the opinion it hsould be auto.
Rossen: Current?
TabAtkins: 0 which was previous
initial value.
... Change to be consistent with the change to initial.
fantasai: I'm trying to wrap my head around when this would be different.
astearns: Last time we discussed 0% when we said it should be 0 it's different on width then min-width.
fantasai: auto for width isn't hte same as min-width.
astearns: We could throw out the calc on min-width if it's doesn't resolve.
TabAtkins: either the percent 0s out or we throw it out.
fantasai: Makes more sense.
tantek: Treat min-width and min-height the same as we just resolved to deal with percentages.
astearns: So it's 0 rather then auto.
TabAtkins: Still a change from current. calc is replaced with 0. Current is calc(10%+10px) = 0. Now it's =10px.
fantasai: This makes the most
sense. Consistent with margins and padding.
... If you set min-width to a non-auto size you're not
expecting it to look at content
astearns: Prop: treat indefinete % in min-width and min-height as 0
RESOLUTION: treat indefinite percentages in min-width and min-height as 0
Rossen: This is web compat?
TabAtkins: If you have a complex calc it's a change. percent only is the same.
github: https://github.com/w3c/csswg-drafts/issues/820
fantasai: Shorthands are nice. We
have them for many things, but not combo of width and
height.
... We hadn't added that because there's a size property like
thing that the app page has tht does not behave anything like
this shorthand would. That sets the size of the writing
box.
... Options are do something wierd where size doesn't work for
@page. Other option is some other word then size. "box-size" is
the current issue in the suggestion.
... It would be for block-size and inline-size. min-box-size
would be the other.
florian: Naming conflict is that bad?
fantasai: It's a descriptor but operating on a box that accepts other boxes. It'll be weird forever.
TabAtkins: Weird because page
takes width and height and size should be a property there.
Conflict itself is weird but especially in the exact
case.
... box-sizing is close.
dbaron: box and block might be confused by some.
<tantek> indeed
Rossen: What is the motivation here?
TabAtkins: People want to set width and height together.
florian: When people want to says omething different they repeat themselves.
fantasai: It's likely you'll want both to a keyword like auto or 100% or contain.
TabAtkins: Equal sizing is reasonable.
Rossen: The short shorthand is always going to give you squares.
florian: If you do % it will not.
TabAtkins: Unless box-size 50% is same for height and width.
fantasai: If we didn't have a naming conflict this would be in the spec.
florian: I'd ignore the naming conflict and say you can't use it in @page rule
astearns: I don't like that
because if you don't know anything about @page it's
surprising.
... Here I've found I have to use it and the styles I set up
perfectly are no longer good.
florian: It's the code you wrote to size the page that would be weird.
<fantasai> @page { size: 8.5in 11in; }
rune_: Page doesn't match any elements?
florian: no
<fantasai> @page { size: letter; }
astearns: I'm thinking copying from another container.
emilio: I think having a special-case for @page rule/ above for page rule isn't worth it.
astearns: First comment TabAtkins said is people have been asking for this and it would be mildly useful. I'm not sure mildy is worth it.
fantasai: I've had people bug me for this. Those people are not sitting here.
astearns: I'm not hearing
consensus on using size or another name. I'm not hearing huge
enthusiasm for solving this
... Might be worth a note in the spec saying we've considered a
shorthand and have not found enough motivation for dealing
witht he problems and outline what the problems are.
... Objections?
RESOLUTION: Add a note to the spec explaining this problem and move this issue to level 4
florian: Do we need a new WD?
fantasai: Sure
astearns: Obj to a new WD of Sizing with all current resolutions edited in?
<tantek> +1
RESOLUTION: Publish a new WD of Sizing with all current resolutions edited in
github: https://github.com/w3c/csswg-drafts/issues/2353
TabAtkins: We made some edits and we need to WG to approve.
Rossen: Can you go over the edits?
<fantasai> https://drafts.csswg.org/css-flexbox-1/#change-2017-flex-min-contribution
TabAtkins: Last comment in the issue has a link to the change
fremy: I need to process it.
astearns: Anyone else want a summary?
Rossen: Let's get back tomorrow. I want to look as well b/c I spent time working on this issue. We had a change fixing some edge inconsistencies with this problem. We have to back it out because it seemed others were inconsistant.
fantasai: We went with dholbert's solution over fremy.
astearns: There's a 2nd layout section Thursday morning. Let's add this then
github: https://github.com/w3c/csswg-drafts/issues/2442
TabAtkins: If you have a table
that's flex item the flex sizing algo tells it what size to be
but that's can be smaller then the table's min size. What
happens? Edge and FF only use table sizing algo. Chrome flexes
the table, but I'm not sure if it flexes more then minimum
size.
... fremy says table should flex and overflow to it's min size.
I agree.
astearns: Anyone disagree that tables flexed to smaller then their minimum size should overflow?
fantasai: It should be a min-size.
TabAtkins: Does that happen?
fantasai: We shouldn't be like the flex item is smaller then it actually is. If the table has a min-size it should be reflected in the min size in the algo.
TabAtkins: If it has a specified size to . Content of 200px but width of 10px. It'll be 200px but we don't go down a path to look at the contents.
fantasai: THe table has a minimum size that's not reflected in min-size property. Max of specified min size and min size from table layout should be the size.
TabAtkins: Yes, that makes sense.
dbaron: And only for auto layout tables?
fantasai: Yes.
Rossen: If width is spec it's still a min-width
rune_: Flex consideres and explicit width as a min-width?
TabAtkins: At all times tables cannot shrink below their minimum content
cbiesinger: Can you put that in the spec somewhere?
TabAtkins: Sure.
... Between flexbox and table spec we'll put this.
fantasai: Used min-width of a table considers the content of the table and then we make sure flexbox hooks into that.
astearns: We only want flex algo to key of used min-width for tables.
fantasai: No reason for it not to in general. We just need to make sure correct terms are in flexbox and that tables has that concept.
astearns: Used min-width isn't a term?
fantasai: It is, but we need to make sure tables spec uses it.
astearns: Used means layout has happened.
TabAtkins: This is a flex item.
cbiesinger: You need min-width before you layout flex item.
TabAtkins: Sure. Tables need to do layout earlier.
fantasai: Just calc min-content width.
astearns: Prop: define what used
min width is for tables and to make sure the flex algo uses
that.
... That's the approach we're taking. Let's have you all come
up with proposed edits.
cbiesinger: Anything else have the used min-width?
fantasai: No. Nothing else has a used min-width that depends on random other information.
astearns: Anything more on this?
fantasai: TabAtkins and I
suggested we draft L2 where it's flexbox 1 + the current set of
alignment properties with all their values. Flexbox 1 only has
a subset of alignment.
... It's L1 + aligning keywords + gap properties so people can
talk about it.
TabAtkins: Technically you can read alignment and sizing and figure it out but this would be convenient.
fantasai: We'd have to dup some parts of the algo but most we can say refer to current Flexbox. We're getting very stable so end of the year I think we can fold it in.
astearns: Flexbox level 2 would mostly be a diff spec?
TabAtkins: It shouldn't be a diff spec, just Flexbox 1 with some extra stuff.
fantasai: Basically normative references into flexbox and alignment and some normative text on how it combines with maybe some quotes from the algo. Then in the future we'll fold in all the text.
astearns: Sounds like it would be best as an ED
TabAtkins: Yeah
fantasai: Yeah. Once alignment goes to CR we should have a WD
TabAtkins: Sure
astearns: Objections to an initial ED of Flexbox L2?
RESOLUTION: have an initial ED of Flexbox L2
github: https://github.com/w3c/csswg-drafts/issues/1975
fantasai: If you load the first
link the first issue you'll get the PDF.
... Basic issue is you have a paragraph or a sentence. You put
it in a box with a width constraint so it wraps. All the lines
of text aren't 100% filled. One is 80% one with 50% full.
... You want text left aligned byt the paragraph to be centered
in its container.
... We can't do this in CSS. TTML would like for us to be able
to do this. Different ways to approach it.
TabAtkins: Line beak is between is and enormous in the example. They want text left aligned but once you have the line breaks center the group and then left align within the established center.
astearns: Text can do this in a 2 line, they want this in a 3 line scenario
TabAtkins: And any line might be the longest.
Rossen: If we have padding auto, that's what they want.
astearns: Not only centering
dbaron: Underlying feature is you want to re-shrinkwrap the width of the block after wrapping lines and then figure out what to do with it.
florian: This is a sizing thing or a text effect thing.
fantasai: If this was laid out with css the left gap would not be here.
Rossen: You're sure we can't with flexbox?
TabAtkins: Yes. YOu need to re-shrinkwrap after linebreaking and flexbox determines size after linbreaking.
myles: So you want to layout the first line, figure out the width?
dbaron: Layout all the lines,
figure out which is the longest, and then shrink
... You have a size, layout all the line in the size, then
change the width of the block smaller so that it's lined up
with the widest.
myles: Does flaots make that real harD?
dbaron: Probably
TabAtkins: Solution was a second level of text alignment where it's within the bounds of the longest line. Should be fine with floats, or at least well defined.
dbaron: You'd have to do work to define what to do with extra bits.
florian: Driving use case isn't floats driven.
TabAtkins: And you don't need a second wrapper to get that.
astearns: You and I TabAtkins have some solution just properties are reverced.
dbaron: I think what I desc is what browsers did pre-CSS. Like netscape 4 would narrow the backgrounds to make the longest line.
astearns: To my mind what's happening is here you have a center-left paragraph. We lay it out as if it's left aligned, taking the longest line and centering the whole paragraph. I'm looking similar to text-align-last, I suggested text-align-inner where you say this is acentered paragraph by inner is left.
floI saw it the other way around.
astearns: I forgot how TTML asked.
florian: I htink TabAtkins is better for forward compat. left left is better then fully centered.
TabAtkins: fantasai pointed out a futher use case when handling some CJK topography where most content-ful should be centered but shorter are justified by the width. Right now you have to size the box with ic unit.
fantasai: That would solve a complain from CJK that jsutification causes their lines to have too much space.
florian: I think there is still advanced CJK alignment, but this gets up most of what they want.
myles: This is center-left and you're talking center-justified?
astearns: this is a text-align: left with a tex-group-align: center
fantasai: And when there's floats you try to shift as much as the shortened line would allow.
florian: For TTML float interuption is unimportant, but in CJK we care.
koji: So it's a group?
fantasai: The question we have to think about is from TTML if we only deal with one block it's probably good enough.
florian: Per BFC instead?
TabAtkins: I was assuming 2 paragraphs there were use cases to have them the same. Don't cross BFC bounderies.
myles: What happens if you put it on one paragraph of BFC>
TabAtkins: It FCs the block or it's ignored because block is not a BFC.
dbaron: Inherited or non?
TabAtkins: Non
myles: Put it on your BFC and hopefully authors knows what a BFC is
fantasai: I don't think it needs to BFC anything. If we're going to have a block, a section with 2 paragraphs is we want them to be a unit they property has to be non-inherit and when you apply on a section it modifies line box on both sections.
astearns: More complicated.
florian: blocka nd to descendencts
fantasai: You break at BFC bounderies. The block itself doesn't need to be a BFC
dbaron: It applies to all the lines that are in this block and it's descendent blocks? Only traversing child blocks and not into the lines?
fantasai: Right.
dbaron: I feel like scope is similar to first-letter or text-indent for finding things? But those just look at first and this is looking at all?
<dbaron> dbaron: ... never mind text-indent, that's inherited
astearns: Before we go further into complicating we should ask the TTML people if they want to align paragraphs.
florian: CJK does
koji: CJK the whole block is one BFC and then we need to layout everything.
florian: For CJK case i'm worried about floats.
TabAtkins: [whiteboards
floats]
... Have big element and a floating picture and some
text.
... This block of lines having a shorter allowed line width is
handled separately for the second block?
Rossen: That would be horrible.
fantasai: I don't think separate blocks.
dbaron: Look at the exits, not the lengths.
florian: floats are aligned to the box
fantasai: no
dbaron: So you have some excess on each line, figure out the smallest, and use that for the alignment.
Rossen: But then add a float o nthe right side.
dbaron: THere's still excess on each line.
TabAtkins: Excess you know whichever has the smallest because all the others can be adjustested jsut as much.
dbaron: Suppose you're crossing
multiple blocks and they have different text alignment. You
block align it center, and you have a child with right
align.
... You accumulate excess on both sides and use the smallest
from both. I think that's similar. If the left aligns have 0
and the right is whatever is the smallest. If you're then told
to center you move the over by that much.
fantasai: I was thinking alignment after the group alignment. You find out the shortener and then you shrink your line box. Then we center in the remaining space after we apply group alignment.
dbaron: I think you're right.
florian: Use cases to make it more complex then TTML wants are CJK. If we're not solving moving the alignement we're not solving CJK.
astearns: I suuget we design this only at the paragraph level.
TabAtkins: Won't work if there's floats for CJK. We want the extra shrinkwrapping.
[everyone talks]
iank_: We want smartness and things will be complex.
fantasai: Offset on list is in respect to he edge of the lin with alignment so it'll move with this.
astearns: Let's get the conversation to one person at a time.
TabAtkins: I think this needs more design. I don't think we should agree right now, but it's good to get this in fron tof people.
<dbaron> I think the CJK usecase requires the block-level thing that Netscape 4 did.
fantasai: Before we consider restrict to single paragraph we should hear from TTML to see if it works for them. I think we have agood idea what we want to try and let's see if it works. I would suggest we draft the proposal into Text 4 and work it through as a part of writing.
astearns: And having sep issues.
florian: Most solve TTML, nice for CJK
astearns: Add a text-group-align
property to text 4 with an outline and open issues on that text
once it's drafted.
... Obj?
koji: Early someone mentioned creating an anon block?
fantasai: I think that's more
difficult for the mechanism.
... Can you explain the use cases in the issue?
koji: Yes.
RESOLUTION: Add a text-group-align property to text 4 with an outline and open issues on that text once it's drafted.
astearns: And we'll talk witht he TTML.
fantasai: They're looking to edit.
github: https://github.com/w3c/csswg-drafts/issues/1974
astearns: In this onethere is a PDF of what they'd like. There can be vertical gaps between lines that don't get a background color in CSS. They'd like to spec that hte background should be extended to be contiguous even if there's a gap like this.
TabAtkins: I don't like the magical background
fantasai: Should say it's the box.
TabAtkins: Is this related to linebox size calc proposal?
dbaron: Prob not. One questions is what to do if box is bigger then the line gap.
florian: semi-transparent you don't want transparency to pile up.
<leaverou> what about background-clip: line-box? :)
tantek: For borders you can do the cheap and ugly overlapping borders or the likely wanted borders around the whole thing.
astearns: My summary was insuficeient. It's also extending background on both sides to half the gap.
florian: Consistent with increasing height of inline block.
dbaron: What if there's a tall image on one line?
astearns: I asked about what if a float is in the way and they didn't care.
smfr: Feels a little like how when webkit does selection and tries to eliminate selection gaps?
TabAtkins: In float example I suspect that...it wouldn't be contiguous...first line is a little bigger but not touching. That's solved by inlines being the height of the line property.
astearns: How to accomplish this.
florian: inline height: auto and
fill
... inline property with legacy and filled.
leaverou: line box as psuedo element?
fantasai: Wouldn't solve the problem.
leaverou: Wouldn't line height address it?
TabAtkins: Inline box sizing wrap the content reasonably tight such that line height can produce gaps.
leaverou: If there's a linebox psuedo element wouldn't they be able to set padding?
florian: pseudo element controls too many things.
fantasai: Can we pause this and switch to next issue? It's similar in the opposite axis.
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/1973
<fantasai> leaverou, they're the first links in each issue
fantasai: This one is an issue
where they want padding at start and end of line and applied to
inner most element at that point.
... If ou have a span broken across 2 lines and at the end line
padding is inserted into the span. With CSS you can wrap all
the text but it gives you the last result. THis is effectively
the opposite of letter spacing. This is outside the letter on
the start and end.
... SHould be easy to impl, but we need syntax for it. I wanted
to do this because it's easy to understand.
TabAtkins: Am I imagining a difference in the black line from hello and my?
fantasai: I think that's not intentional.
TabAtkins: Okay.
myles: If you have 2 nested do you use innermost
TabAtkins: It would be like letter spacing where one wins on the letter that ends the line.
florian: this inherits?
fantasai: I think that's simple.
TabAtkins: Has to. Letter spacing but for the space where we don't put letters.
myles: Recommendation is at the tie you do the line breaking you do this for the end of the line? Not sure how it works for beginning.
fantasai: You look at first character on your line and before you figure out how big the character is and like that you have to go forward a bit.
<fantasai> You take the line-padding value of that character
astearns: They use line padding as the avenue to control this.
fantasai: We could introduce a line-padding property that has a longhand.
florian: and if you're intrupted by a float?
fantasai: It's between you and the float.
dbaron: Are there interesting things with bidi?
fantasai: no.
dbaron: pre or post reordering
fantasai: post
myles: there's always a character at the end of the line. Whatever element that's part of is what you consult.
florian: If you're post-reorder you might get a different character at the end.
fantasai: Alternative is have this on the block. Whatever block makes the line box gets the value
Rossen: Similar to the box direction.
TabAtkins: Then you jsut shrink
the line box.
... Possiblity is make it not inherit.
fantasai: YOu want inherit because you make anon boxes. BUt you can put it on the block container at which point it's applied.
florian: I think possibility of different padding based on bidi is not useful and complicates things quite a bit.
TabAtkins: This does seem better. NO drilling down and no bidi. I like this.
fantasai: The property is
inherited by applies to block containers. When you do your
layout you look at line padding property of the line box you're
in which comes from the block container.
... I guess we're rsolved on that approach of having the
property
astearns: Text level 4 again?
fantasai: Yeah. Other option is css Inline. Not sure where it fits better.
astearns: Prop: Add a line-padding property as described in minutes to text level 4.
RESOLUTION: Add a line-padding property as described in minutes to text level 4.
github: https://github.com/w3c/csswg-drafts/issues/1974
fantasai: In this case I think we need to apply to the inline.
florian: I don't know if you need to but there's no complication on it.
koji: When talking about extending inline boxes height?
fantasai: Only for painting.
Rossen: Is it?
fantasai: Yes, layout is based on line height. We don't care about padding, amrgins etc.
fremy: I put a link on IRC that's
a website that tries to do this.
... I think how the did it is set some padding on the line and
let's you extend the background.
Rossen: They'll have overlap.
dbaron: If you choose too much you cover up text in other line.
Rossen: If you resize the window down to 3 lines you lose some of the y
<leaverou> fremy: I've also seen it done with box-shadow to simulate line-padding, it's a very common effect
fremy: They also used box shadow.
florian: Are we discussing a protential property that siwtches the outer content height of inline boxes to be the height of the line?
dbaron: I think border height
fantasai: Outer is margin
florian: meant border.
fantasai: Interesting thing is
this is all element. What if I have superscript? I think what
they would want is ou're still going from top to bottom of
linebox. Amount of extra background ink [whiteboards]
... If we draw this and want to increase by x on each side, but
if you have an element with different baseline you'll want to
go from top to bottom of linebox. Normally when calc size of
background area you're going to use the size of the contents,
your font metrics.
... We're saying isntead of doing that ignore where all the
text is, just find the lin box and draw from the top to the
bottom.
... Should be clear regardless of the vertical positioning the
background moves with the txt.
... Might be margin box you want.
dbaron: NO harm in the margin box
because then it makes margin useful.
... Then you could inset some of the background.
florian: It's commonly set i nboth direction because it only does something in one.
TabAtkins: This won't be turned on by default.
florian: I guess.
dbaron: Also let's people make the border stick out by using a negative margin.
florian: Okay. I buy that.
... Property with normal and fill?
fantasai: Or add it as a keyword on padding property. Padding top-fill so it means make the padding such...
astearns: Then you have to do it on each direction
fantasai: We have padding-block-start.
<dbaron> I'd note that this does introduce negative padding, which might be interesting...
<fantasai> fantasai: You could say 'padding-block: fill'
<fantasai> on the inline
Rossen: I would the prefer this
to be inline background. We can figure out what the bounds are.
We don't have to implode padding or margin. It's a drawing
effect. That way once we switch we can ensure there's no
overlapping so when you're using semi-transparent it's always
complete.
... If it's only after rendering I would prefer higher lelev.
Pushing this down to lineline you'll have some times do it and
it's more complex.
fantasai: Wht makes it more complex to impl? On every inline you haev to call the paint your backgrounds function.
iank_: This goes over the size of the line potentially.
fantasai: You have to handle that for line-height.
iank_: That's line-box sixe.
fantasai: If I set my line ehight ot 10 and padding on my inline box is 10 above and below I'll leak over.
florian: Rossen you're version if the middle is top green and bottom yellow how to you know it doesn't overlap.
Rossen: It doesn't. It's a
simplification because it's one background behind all.
... But they want different colors. Not jsut one element.
koji: smfr pointed out we do that code for selection painting. The approach is like what Rossen suggested, it's easy to impl. If we go with padding it's more complex.
fantasai: padding doesn't effect [missed]. it changes box size but not things around.
Rossen: You can have tearing or overlapping.
fantasai: You can already do the overlapping. i'm not sure how concerns about overlapping or not are valid.
florian: When you do approauch where you'r line height wasn't 20 pixels it's possible you migth get a bit of a gap inbetween. Instead of sizing each individually you can edit as one shape.
fantasai: But then what about when you do images?
myles: Our selection does it piecemeal. We're very deliberate about how we round and floor. It fills peices 1 by 1 and avoid pixel crack with careful rounding.
Rossen: If we leave to authors we'll have different rounding.
astearns: We're saying design the
feature at an inline level and impl deal with stiching together
with the rounding errors. And it's what TTML is asking for in
the issue.
... Do we follow TTML lead and call it fill-linegap?
fantasai: No.
florian: inline-box-sizing?
koji: Sizing sounds like layout.
florian: inline-height: normal|fill
leaverou: Too much like line-height.
astearns: Line-extend
iank_: border-outsets
<leaverou> line-area?
fantasai: You're not outsetting, you could be insetting.
florian: inline-height and line-height are similar but if you're aware of both you won't be confused.
iank_: Not all webdev know all css properties.
fantasai: line-gap-fill
astearns: Pierre suggests line-box-fill on IRC
[quiet contemplation]
fantasai: thinking about to where
we might extend there's a variety of metrics you might be
interested in. Right now it's not entirely defined where the
content box of the inline element is. You could want it to
match em box, glyph bounding box.
... Or match the edge of the line-box. There's several
different values we might want at some point. You have a
zapfino heading and you want a highlight behind.
astearns: line-gap-fill-ink
florian: if padding is applied to the outer padding goes in from there. Or we apply box-sizing.
fantasai: Let's name the
property. Fill value picks a value such that it fills the
margin box.
... We need a name and it should be compat with having
different values in the future.
... inline-sizing.
florian: inline-height sounds fine to me.
astearns: All the names inples changing geometry
fantasai: We do change the geometry of the box. If you put a border the size of the border changes.
astearns: [reads pal question]
dbaron: replaces the padding I
think. It's adjusting the paddign to make margin edge line
up.
... Also introduces possiblity of negative padding.
florian: Do we only grow or also shrink is a separate question.
fantasai: leaverou suggests
leaverou: We can reuse line paddign and have it take 1-4 values for all directions and have a fill keyword.
fantasai: I think....we had a fill keyword with 1-4 values what if you apply it to the inline-start.
leaverou: I'm not sure.
fantasai: If you have line-padding-inline-end: fill on a short line the color goes all the way to the edge. THat's not unreasonable.
myles: And that's on a span so it's only to the end of the span if there's a linebreak?
fantasai: Only if it's the end of the line.
astearns: If it's in the middle it goes to the end of the span. If the span ended a line it goes to the end of the line box.
myles: Line break in the middle?
fantasai: If the span is in the middle and there's text at the end there's no effect. If the span breaks or is last thing the background goes to the end.
myles: You have to look at deepest span?
fantasai: In fill case...yeah. Yeah. You'd impl as adding extra space and all the spans extend to the end of the line. Wont' effect position, it's jsut poiint.
florian: Confusing if there's whitespace with a different span at the end?
fantasai: If you use whitespace-pre that's your fault.
astearns: I think we have vague
consensus on an approach. Is this in Inline? Would be nice for
all TTML in one spec. Others are in Text L4. But this is more
inline then text.
... Prop: Have a line padding shotrhand with all the attendant
longhands that in additon to lengths takes a fill keyword.
leaverou: Can we have a background:clip keyword that makes it so they don't have to wrap it in a span?
fantasai: What element has the background?
leaverou: Heading and you want to apply the linbox to the heading but you don't want to wrap the heading in a span.
fantasai: You want a pseudo element for the root inline.
leaverou: A new pseudo is more complex to add.
fantasai: This is for a box that exists.
leaverou: Why can't we use padding on that rather then a line wrapping property?
fantasai: Padding is applied to inner most, not outer.
florian: I thought we had normal and fill and you said lengths and fill.
fantasai: This use case for inline needs lengths.
florian: They apply to different things.
myles: Instead oa new property why wouldn't you use lineheight to move lines?
fantasai: Not changing layout which is what line height does. We're changing how box is painted.
myles: what does length do?
fantasai: We discussed adding space like letter spacing, that needs length. Then we discussed how to fill disance between edge of box and edge of linebox and that takes keywords. leaverou asked why not have a single set of 4 properties that solves both use case.. But we're not ure we can.
florian: One was desc as working on block and the other on inlines. fill could be made to work in both, but let's not. It looks like 2 sets of 2 things
astearns: Prop: A line-padding property?
myles: It's valuable to not conflaint properties that mess with layout and ones that mess with paint
fantasai: line-padding was for
the letter spacing type thing. I think line-padding is a fine
name.
... We need a name for the one in the other axis.
... That's changing how we size the box for painting purposes.
We've got normal which is what we do not and fill the line
box.
myles: CHange veritical alignment?
fantasai: It does not.
florian: We might in the future want to separate extending top and bottom side.
fantasai: I think we'll start with one value for both of these. If someone wants different we can split.
myles: Background will paint outside of the boxes the spans create?
florian: You're extending that.
fantasai: That box has no effect
on layout in vertical. It's only about painting.
... It doesn't change where the text is for that or any
element.
florian: And you can already set hte border.
leaverou: We're trying to come up with a second property name for the fill keyword, why not work in one direction?
astearns: I think we're at the point where we can't combine the effects because where we're adding them in the inline is only block container and fixing the gaps can't.
fantasai: One takes lengths and the other keywords.
florian: And we are only missing a good name.
astearns: Prop: A propserty to be named that applies to everything with 2 values, normal and fill. It inherits and applies to inline boxes.
<fantasai> and might take additional keywords in the future
florian: Remaining question for
that property is if you have enough borders it would shrink
into the text and then what?
... If you have 20px height and 30px borders, did you ask for
that and that's your problem?
dbaron: Related to the can it go negative question.
fantasai: Overflow doesn't apply
for inline. Border goes behind the text.
... Which is reasonable in a lot of cases. The alyout area you
might want to have negative padding to get things to look the
way you want.
florian: Okay.
... Do we need to define borders are behind the text or is that
clear?
<fantasai> The glyph area of a character might be significantly smaller than the em box
astearns: I think next step is
get this in the draft.
... Obj to having this property?
RESOLUTION: Add a property to be named that applies to everything with 2 values, normal and fill. It inherits and applies to inline boxes.
astearns: Added to CSS Inline. Ideas on names are welcome.
[schedule wrangling]
<florian> https://github.com/w3c/csswg-drafts/issues/1971#issuecomment-377078084
<florian> github: https://github.com/w3c/csswg-drafts/issues/1971#issuecomment-377078084
florian: Missed the telecon where
we discussed. We recently resolved overflow:clip does not
trigger BFC. I think it failed to considered some of the things
that implies.
... The motivation that triggered adding to spec was usage in
combo with contain:paint so you can have contain:paint with
text overflow or resize property. Only apply to overflow not
visible elements. We don't want to use contain:paint with
overflow:hidden because UA might look for too many
resources.
... If overflow:clip does not creat a BFC are impl comfrotable
saying resize and text overflow applies to elements that are
overflow:clip?
TabAtkins: During discussion before we couldn't come up with you'd want overflow without scrolling, this is the reason. There are properties that depend on things being non-visible.
florian: Resize.
fantasai: I think it doesn't matter for resize.
florian: I'm not saying should not apply. but if we're going with it's not a BFC we also have a bunch of properties that should change to not visible or clip.
dbaron: There were use caes for the opposite.
<fantasai> and I think that 'text-overflow' should never have keyed off of 'overflow'
TabAtkins: This is the use case for this situation. WE only can up with use cases for the other resolution. Something tha tacts like overflow:visible but it's clipped.
florian: NOt effect margin collapsing.
TabAtkins: Or sticky or
scrollsnap.
... This is a reason for the opposite where it's like hidden
but don't scroll.
dbaron: They can't apply for text:overflow partly because this is a purely paint time effect.
florian: This is also a purely paint time.
fantasai: True.
dbaron: I guess those two could maybe be changed to not include the visible. Nothing is like this because we've put overflow does not equal visible across all our specs where that's not what we mean.
fantasai: I think a lot that key
off overflow not visible key off if it's a BFC.
... I think a lot of things are keying off that. There's many
effects that key off of that and we don't have to handle the
spec. There may be sone that don't.
florian: That we need to rename
was mentioned. If we clarify that doesn't apply to
text-overflow and resize that solve my first concern.
... Are we okay closing that sub topic?
astearns: Additional concerns?
florian: Assuming we don't find another problem we can clarify the previous resolution to mean text-overflow and resize refer to non-visible elements.
<fantasai> fantasai: To rephrase Florian without negatives, text-overflow and resize apply to elements with 'overflow: clip' just as they apply to elements with 'overflow: hidden'
florian: The second concern was about what overflow:clip means when applied to the document or body element and propegate to viewport
fantasai: Same way we translate visible to auto we translate clip to auto.
florian: That's good.
astearns: Resolve on both?
... Prop: text-overflow and resize apply to elements with
'overflow: clip' just as they apply to elements with 'overflow:
hidden'
RESOLUTION: text-overflow and resize apply to elements with 'overflow: clip' just as they apply to elements with 'overflow: hidden'
astearns: Prop 2: when overflow:clip is propagated to the viewport it's changes to overflow:hiddent he same way visible is changed to auto
RESOLUTION: when overflow:clip is propagated to the viewport it's changes to overflow:hidden the same way visible is changed to auto
astearns: You're fine with the resolution?
florian: Yes. I'm mildly skeptical, but not objecting.
opic: padding-bottom in overflow content
github: https://github.com/w3c/csswg-drafts/issues/129
... none
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/2473
github: https://github.com/w3c/csswg-drafts/issues/2473
majidvp: There's a resolution to add this to oerflow inline and block which is reasonable.
florian: We don't have a resolution on this. We have it on similar.
astearns: Overflow vs Overscroll.
Oooh.
... Obejctiosn to adding block and inline to overscroll
behavior?
RESOLUTION: add block and inline to overscroll behavior
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/2484
github: https://github.com/w3c/csswg-drafts/issues/2484
Oriel: It only lets you set overflow-x and overflow-y. It would be more convenient if it accepted two values. Then there was the question is the order should be physical or logical. As an example background-position is x and y. It will prserve physical order. There's another issue looking to switch longhand and shorthand into phsycial order.
florian: Other is issue #1282 which discussed adding logical keyword to all places currently phsycial.
astearns: Separate from that
switch, do we let overflow accept 2 values?
... Concern about changing this?
... Weird mistyped decalrations may now have an effect?
florian: I suggest we presume
that's rare and if it's a problem we raise it
... A more consistant system where they all have shorthands and
they're physical.
astearns: Prop: Allow overflow to have two value and for the ordering to be physical.
iank_: Which order?
emilio: x and y.
dbaron: Quesiton: There are sets of values transofrmed into other values. If x is visible and y is scroll we make scroll into auto. Should those combos be syntatically valid for shorthand?
myles: Related that this shorthand shouldn't allow new functionality
dbaron: Transofrmation would still happen. I'm thinking a it would be nice if it rejected but b it's not possible because serialization problem. Because then values could not serialize to short hand
emilio: Happens in a lot of places.
dbaron: I guess it's not really a serialization problem. Do we want the things that are not going to be valid in the end be parse errors?
emilio: I think it would be weird if spec shorthand would yield different results.
myles: You set the shorthand and it's rejected and that's different that if you set the 2 longhands.
florian: You have a minifier and it takes the 2 longs and puts them to short and that's a parse error.
astearns: I would prefer let ou set the shorthand to whatever and letting it transform.
florian: I don't think we gain by forbidding these.
fantasai: If you serialize out computed values it's valid.
florian: What do we gain by forbidding?
dbaron: Reject things that don't makes sense.
florian: Makes sense when you transform.
dbaron: CSS tries to reject things that don't make sense.
fantasai: Would be nice if a validation tool flagged this.
astearns: Computed value shows something changed.
fantasai: That always happens.
emilio: [missed] fantasai Tranforming em to pixel doesn't show you've got a problem in your style sheet.
astearns: I'm not certain having a transofmr apply implies there's a problem in your stylesheet.
fantasai: rachelandrew?
rachelandrew: I don't have an opinion.
florian: Stylesheet maintenece it's strange.
myles: Have we never encountered this?
fantasai: Almost for display but we made all combos invalid. We got rid of the longhand.
emilio: Outline style stuff which when you have hidden outline and the line-width becomes 0.
astearns: Anyone have a concern
with allowing whatever combo we spec? Anyone object to taking
what we get and stransform?
... Prop: Allow 2 values on the overflow property in physical
x/y order in any existing values.
myles: What a combo authors want with different keywords?
astearns: hidden x auto in y.
myles: So only one scroller.
astearns: People use overflow x and y in various situations and it' sjust that it would be nice to let them use the shorthand for both.
rune_: If you have visible overflow in x and y you get visible.
florian: Transformed to auto.
myles: Hiddena nd auto are okay.
astearns: Obj
RESOLUTION: Allow 2 values on the overflow property in physical x/y order in any existing values.
astearns: we're done for the day.
<astearns> trackbot, end meeting
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 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/then usual/than this year/ FAILED: s/in hindsignt/in hindsight there are always things we could have done better/ Succeeded: s/right/what was the right/ Succeeded: s/switch/switch due to web compat/ Succeeded: s/compat/compat bugs/ Succeeded: s/what happened/not what happened/ Succeeded: s/Aslo dimensial/Also dimensional/ Succeeded: s/vs [missed]/vs property width, computed, cascaded etc./ Succeeded: s/form element/form elements/ Succeeded: s/open an issue/open an issue on 21/ Succeeded: s/21/2.1/ Succeeded: s/width existing/box-sizing existing/ FAILED: s/maintenance/maintenance to level 3 also in level 4/ Succeeded: s/the explain/than explain/ Succeeded: s/Is impl something you need help/Is impl report something you need help/ Succeeded: s/There/I did. There/ Succeeded: s/a11y meeting/joint CSS WG and a11y meeting at TPAC 2017/ Succeeded: s/conflicting things/conflicting things. I suspect that some of these conflicts would go away once we have spatnav/ Succeeded: s/write up is James/write-up is from James/ Succeeded: s/add/query/ Succeeded: s/stringer/stronger/ Succeeded: s/??/Rune/ Succeeded: s/floats/sufficient number of floats/ Succeeded: s/fix the min-content/fit the min-content and there are no floats limiting the height below it/ Succeeded: s/someone/Mats/ Succeeded: s/these small things/subgrid and this one other small thing/ Succeeded: s/impl-wise/spec-wise for sure (uncertain about impl-wise)/ Succeeded: s/making the column 300 and the last one goes to 0/making the columns 50,250,0, which is a big change from the current way they lay out/ Succeeded: s/(sp?)// Succeeded: s/Caesar/César/ Succeeded: s/Monash (sp?)/Monash/ Succeeded: s/revisit/revisit if there's a problem/ Succeeded: s/I'm/Regardless, I'm/ Succeeded: s/map/calc/ Succeeded: s/flex/grid/ Succeeded: s/space between/space-between/ Succeeded: s/Having a box model with tabbing and you'll 0 out %/Having a box model with some % and non-% values results in the same logic, where we would zero out the % values and add the rest of the defined sizes/ Succeeded: s/plinss/astearns/ Succeeded: s/a shorthand/a special-case for @page rule/ above/ Succeeded: s/things/tables/ Succeeded: s/rune_/cbiesinger/ Succeeded: s/rune_/cbiesinger/ Succeeded: s/block/block after wrapping lines/ Succeeded: s/space/too much space/ Succeeded: s/shorten as/shift as/ Succeeded: s/line/line would allow/ Succeeded: s/shoot/shrink/ Succeeded: s/mana/make/ Succeeded: s/rossen/fantasai/ Succeeded: s/is not right/sounds like layout/ Succeeded: s/transpate/translate/ Succeeded: s/ties/tries/ Succeeded: s/pool/tool/ Present: jihye surma cbiesinger koji birtles dael astearns rego ericwilligers Naina_Raisinghani Google tantek Vlad ChrisL leaverou Found ScribeNick: dael Inferring Scribes: dael WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 10 Apr 2018 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. 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.)[End of scribe.perl diagnostic output]