<scribe> ScribeNick: dael
Rossen: One more minute and then
we'll get going. 9:03PT
... Let's get going
... I wanted to ask if there are additional agenda items or
changes to the current agenda?
<chris> you saw my agenda+?
github: https://github.com/w3c/csswg-drafts/issues/3020
Rossen: TabAtkins and fantasai
noticed this while reviewing Grid and they asked if we should s
tick to this or align to everything else. Opinions?
... TabAtkins is calling in
fantasai: I imagine he'sin favor
<TabAtkins> ^_^
<dbaron> makes sense to me
Rossen: We can resolve to align grid layout static position as content box rather then padding. Objections?
RESOLUTION: align grid layout static position as content box rather then padding.
github: https://github.com/w3c/csswg-drafts/issues/3028
fantasai: This is to drop or
defer border and background section. There'sa bunch of issues
against it which we can handle but these were put in and
sketched out on how to handle it. Parts critical for impl
writing modes are not this
... We propose to defer this section so we can stablize the
rest
... And address these in L2 if we think approach is good
<fantasai> https://drafts.csswg.org/css-logical/#background-and-borders
fantasai: Dropping all of section 5^
Rossen: In favor, but want to hear if others have opinions
<dbaron> sounds good to me
<bradk> +1
<dbaron> (I guess you didn't hear me)
Rossen: Objections to dropping section 5 from logical properties?
RESOLUTION: Drop section 5, backgrounds and borders, from logical properties
github: https://github.com/w3c/csswg-drafts/issues/3013
fantasai: Question was about
should hte mapping for logical values depend on element or
containing block. Not about logical properties, but values like
float inline start or text-inline-start
... First thing is currently the spec...it was stated values
compute to themselves. That's first question. Second is do you
map against containing block or element.
... Supposed to depend on kind of element. test-align:start
needs to map against element. For alignment we use containing
block so makes sense to do same for float b/c you don't want
element to move based on content, but rahter context
... Proposed is no change to spec but clarify the values map to
themselves
... I copied that in. Does anyone else have comment?
Rossen: Question. There are...all properties in box model, are they defined to resolve against own writing mode?
fantasai: Yes own. It was
sometimes correct and because you have to do computation of
writing mode with cascade it's much easier computation.
... It's unfortunate that's t he case because there's a lot of
cases to use containing block writing mode for something like
margins but we did element's own writing mode for
simplicity.
... Don't have same problem for values as they resolve at
layout time
... We should have down issue 3 first as it talks about
computed
[logical properties issue 3, not agenda issue 3]
Rossen: Other opinions?
<fantasai> #2821
Rossen: I asked about box model props because they are used for aligning box and sometimes used to align content inside. Align self and content align properties and values are very similar in layout impact so one doing self and the other containing block is weird.
fantasai: align self:start you
use containing block, align-self:self-start you use your own
writing mode
... text-align:start your children is what's being aligned.
Rossen: Get it. Not making case
against it. In same virtue you can say position left and right
can be used to align self and padding start and end can align
content box. Fromm that PoV they are similar.
... For box model all properites and values compute to writing
mode of element itself
... There is discontinuity here
... Can live with it.
... Other opinions or resolve on proposal to have values that
effect alignment compute in containing block. Value effect
alignment of content of a box o f an element are computed in
writing mode of element itself
fantasai: That's what's spec in grid, flexbox, and alignment
<bradk> +1
RESOLUTION: Accept proposal
github: https://github.com/w3c/csswg-drafts/issues/2821
fantasai: This is that the values
we spoke about compute to self, not left or right.
... This is necessary for text-align property so for
consistancy we should do that for all p roperties and if we
don't do that CSSOM physical coord won't align
dbaron: Flip side is that it means anybody looking at computed values to act on them has to do something more complicated. If a web page looks at computed value they need to consider 2x possibilities. They might not and therefore have bugs
fantasai: Yeah but you have to do
for inherited prop s why treat non-inherited differently?
... You have to do that on inherited.
dbaron: Not as strong a case for
not inherited ones
... and I think there are more of them, or maybe not
fantasai: Consistancy and so author can work in logical coord if they want to. Make these computed v alues be what they are and if browser needs to worry it should add convenience to its code before reporting to the user
dbaron: what about the CSSOM
Rossen: I think giving them all
the values and having them make the choice what ot use would be
better then the result of calc that will mask what value ended
up computed and trying to piece that back to the value's
origin. Esp. for inherited.
... I agree with dbaron it will require a bit more handling on
user side but prob not that much
... We can always simplify later
dbaron: okay
Rossen: Other opinons or try to resolve?
fantasai: Also nec. if keeping previous resolution
Rossen: Yes, but we could
revert.
... Objections to CSSOM exposes both logical and physical
values and the resulting values are that of the cascade?
... Is that the summary?
fantasai: What..no. Resolution is that the flow relative keyword values compute to themselves, not to physical equivellents
Rossen: Objections to this?
RESOLUTION: the flow relative keyword values compute to themselves, not to physical equivalents
Rossen: This was last logical issue
fantasai: There's 2 more, but
that's what we wanted to resolve before publishing
... Other 2 significant issues are marked in draft. 3030 and
3029. I think those need more time to discuss and publishing a
draft with them marked is good way to go forward
Rossen: Agree. Objections to publishing a new CR for Logical properties?
fantasai: We're on WD
RESOLUTION: Publish a new WD of logical properties
Rossen: We'll try for CR soon
github: https://github.com/w3c/csswg-drafts/issues/2995
Rossen: TabAtkins can you do without florian ? Or do we punt?
TabAtkins: We concluded and
wanted to see if obj.
... Spec wasn't clear what effect containments have on
baseline. florian convinced me. Layout containment should
censor the baseline b/c i t acts like there's nothing going on
inside
... Don't have to do layout on contents to layout parent.
Baseline requires you to know what's i nside
... Size containment does not censor. baseline doesn't effect
that size in any way. Sizing works fine and you can baseline
align
... Only potential weird is an overflow:visible element it can
shrink to 0 but still have a baseline. That can happen today,
though.
... Conclusion: layout containment censors baselines and size
containment no change. Other containments don't matter
here.
... Sound good?
Rossen: So this proposal only changes layout containment?
TabAtkins: Yes.
... urns out in chrome we don't pay attention to size but do
for layout. We should be able to change. Per spec this only
changes layout containment.
Rossen: Okay. Rest is clarification
<fantasai> +1
<fantasai> I think this is the correct resolution
Rossen: Reasonable. Seems florian
agrees. Other comments?
... Objections to layout containment censors baselines and size
containment does not
RESOLUTION: layout containment censors baselines and size containment does not
github: https://github.com/w3c/csswg-drafts/issues/1904
... none
chris: Selectors 3 was...we
produced new CR and we have 1 test of the 1 errata. CR was just
manditory for patent policy. That time has passed and there's
no open exlcusion. So can resolve for PR.
... I see gsnedders asked about t est suite. He's got a pull
request about build system not working for WPT. I don't see
relevance. This CR is one errata and making it normative. I
don't see this holds up PR and then REC. Selectors 4 is current
spec.
Rossen: Is gsnedders on?
... I didn't see regrets from him
[seems like no]
chris: Do we move forward?
Rossen: I'm in favor. Want to hear from group.
fantasai: makes sense
<astearns> +1 to PR from me
<tantek> +1
Rossen: Objections to publish Selectors 3 as PR?
RESOLUTION: publish Selectors 3 as PR
Rossen: chris do you need help?
chris: Fine. Done transition request except for resolution.
github: https://github.com/w3c/csswg-drafts/issues/1904
<chris> transition request here https://github.com/w3c/transitions/issues/83
Rossen: Way replaced elements
effected by break-inside properties
... Change we made with fantasai to go from a white list to a
black list of elements
... Currently break-inside is spec that it applies to elements
in normal flow that establish FC or are [list]
<fantasai> Changeset is https://github.com/w3c/csswg-drafts/commit/23d5a4c7b28f9767f7f7a621a7b895d4b858bbca
Rossen: Currently excludes
flexbox, grid, etc. Changed that to be a blacklist
... Proposal is break-inside applies to all elements except
[list from issue]
... While we did this we noticed break-before and break-after
weren't applied to grid and flex so we fixed that too
... That's the summary. Want to hear from WG if wemissed
anything or if we can resolve
<TabAtkins> +1, blocklist and allowlist
plinss: Can we stop using term black list and white list?
Rossen: disallow list and allow list
<bradk> Abspos includes fixed?
Rossen: Objections to accept the change: https://github.com/w3c/csswg-drafts/commit/23d5a4c7b28f9767f7f7a621a7b895d4b858bbca
<bradk> Ok
Rossen: Yes bradk it includes fixed
RESOLUTION: Accept the changeset: https://github.com/w3c/csswg-drafts/commit/23d5a4c7b28f9767f7f7a621a7b895d4b858bbca
github: https://github.com/w3c/csswg-drafts/issues/1529
fantasai: About an empty fragment
at a fragmentainer boundry. If you have a 0 height block or 0
width inline etc and the previous item that fi there filled the
whole line does the 0 size element stay on the page?
... Specs don't say anything now about where required to break
so UA can be intellengent.
... For 0 size might make sense to spec explicitly
... Question is do we want to spec that for fragmentation in
general or just for flexbox?
... flexbox is only place w e define that percisely right
now.
Rossen: I believe we discussedin the past. Don't remember if resolved.
<fantasai> because flexbox requires consistency more than quality-of-implementation, so its breaking rules are defined
Rossen: As far as I recall reason
is the empty elements are exausted opportunitically as much as
possible. If there are empty boxes at the end of fragment we
assume they fit. Done so you can reduce subsequent
fragments.
... That makes sense
... Other side is such elements or boxes are used for
positioning or to create containing blocks or abspos items that
go in and out for UI
... For those cases harder to argue it's better that such items
are consumed asap or pushed. Again, counter is there are avoid
break-inside and break-after properties where you can use such
and control correctly
... In both cases makes snese to position and consume empty
boxes a s early aspossible on frag where they are encountered
rather then pushing
... That's how I remember previous
... Curious if there are other arguments or if we can resolve
on that and spec it so we don't forget again
<bradk> +1
Rossen: Obj to Spec 0 size elements are positioned as early as possible in the fragmentation flow?
RESOLUTION: Specify 0 size elements are positioned as early as possible in the fragmentation flow
fantasai: Need to do DoC
first
... Look next week?
Rossen: Fine
github: https://github.com/w3c/csswg-drafts/issues/2818
Rossen: astearns you added this from the F2F. I wanted to hear from Amelia or myles or anyone involved
myles: This is asking for a distinction between off/on/do what platform does. For us on and do platform is the same. Proposal asks for explicit on. I wanted to knwo what other vendors thought about skipping on by default
fantasai: I don't think it's by default. Request is a value, doesn't mean we change initial. Initial is auto.
Rossen: Do we need auto?
fantasai: Yes. Wanted to allow UA to do what it felt like.
myles: Cool if all browsers decided default was do skipping so we could have 2.
Rossen: Our position is we just finished re-write inline layout. ink-skipping was on my shortlist, but that shortlist wasn't short so we didn't get to it. As a targetted behavior we'd want on by default once we have it. Just like w e enable kerning by default. Doable, not super concerning for perf.
myles: Sounds like you're okay with 2 values
Rossen: Yes
myles: We are also happy with 2
Rossen: Having said that there's now ay to force it. If platform supports but if i t decides on that device it disables you can't force it.
myles: When you produce a product that can have that behavior we can re-open?
Rossen: Fine.
... Is Emilio on?
dbaron: I don't think xidorn wanted it on for all
myles: Do you remember reasons?
dbaron: I think some w as related
to what he saw as default on platform. Maybe windows
primarily.
... Don't remember that well. Underlying was xidorn wasn't
comfortable with on by default for all.
myles: Maybe let this go into issue and ask him to comment in issue?
<emilio> Rossen: I'm on IRC fwiw (can't get on the call today :()
fantasai: Yeah. Can also take up on Sept 5 call
myles: Sounds good
Rossen: Sounds reasonable.
... Let's stop here and move on.
github: https://github.com/w3c/csswg-drafts/issues/2561
<fantasai> https://github.com/w3c/csswg-drafts/issues/2561#issuecomment-413144634
Rossen: florian is not here. Dunno if heycam or rachelandrew_ are here
fantasai: I'min favor of accepting proposal in last comment fwiw
Rossen: Other opinions?
rachelandrew_: I'd agree
<astearns> +1 to block-ellipsis
Rossen: Rename overflow to block-ellipsis. Rename auto to none. Rename ellipsis behavior to auto
rachelandrew_: Yes I agree
[missed]
... I agree and as Imentioned in comments I wrote docs for MDN
and this seemed sensible way to explain it
Rossen: We can try and resolve. Objections to Rename overflow to block-ellipsis. Rename auto to none. Rename ellipsis behavior to auto
RESOLUTION: Rename overflow to block-ellipsis. Rename auto to none. Rename ellipsis behavior to auto
github: https://github.com/w3c/csswg-drafts/issues/2430
chris: It seems...I thought this effected impl and rereading i t looks like this should be t he users default, apperently it already does impact medium. it's restoring language that was in the spec and was removed. Thought it was a change, but I no longer object. We can put the language back. I'd like to hear i f other vendors see a problem. Otherwise trivial change
myles: One thought. Proposal has changed through issue. In Apr 25 post from Amelia it says [reads]. I think that's more specific than original text. Helps me understand what text trying to say. If we make a change, should be one Amelia proposed
Rossen: You're okay with changes?
myles: Yeah
dbaron: One thing we've found in past is if you change the meaning of medium and default font size meaning many web pages break. Turns out to not be a good thing rather then zooming. Maybe that's changing as web changes
myles: One detail, we don't support changing meaning of medium, but do support bumping every font size by a %. No way to effect keywords without effecting font-sizes and that works well
chris: I thinkt hat was the basis for my original reluctance. We seemed to hope that would work in CSS 1, but now you can zoom entire page and that seems more robust and what people do. didn't want to restore on basis of it was in css2.
myles: Q for dbaron. If you change definition of medium to other then 16 pages break, but someone in the issue said chrome and ff allow changing definition of medium
dbaron: We do have a setting and over time it has gotten more hidden, but haven't removed. It's not a great idea to set.
<astearns> I have changed that setting and have had pages break
Rossen: What does that leave for this issue?
<chris> so we shouldn't really encourage changing it, then
myles: This is a natural pull between browsers custom a11y that they do without spec changes vs something normative the spec can say about how to improve font sizes. dbaron comment on how browsers evolved their solution and maybe normative spec text isn't nec makes sense. Could go either way
chris: Could go either as well. Don't want to encourage people to do a bad practice
Rossen: Leaning resolve no change?
<tantek> I don't think we have enough data to justify a specific change on this
<chris> fine with no change here if WG so resolves
Rossen: Going to take silence as agree
<tantek> +1
Rossen: Objections to no change to spec, leave piece of text out
<chris> +1
RESOLUTION: no change to spec, leave piece of text out
Rossen: We're at top fo hour, one
more font issue from fantasai
... Happy to push if can't resolve
... Okay, we are done
... We'll chat next week. Bye!
<Rossen> 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/[missed]/and I think there are more of them,/ Succeeded: s/In/what about/ Succeeded: s/properties/elements/ Succeeded: s/Amelia/Emilio/ Default Present: antenna, Rossen, dael, dauwhe, ericwilligers, bdc, plinss, tgraham, dbaron, chris, astearns, melanierichards, jensimmons, fantasai, garrett, zheng_xu, tantek, TabAtkins, antonp, myles, rachelandrew_, leaverou, bradk Present: antenna Rossen dael dauwhe ericwilligers bdc plinss tgraham dbaron chris astearns melanierichards jensimmons fantasai garrett zheng_xu tantek TabAtkins antonp myles rachelandrew_ leaverou bradk Found ScribeNick: dael Inferring Scribes: dael WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 22 Aug 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]