- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 9 Dec 2015 19:46:02 -0500
- To: www-style@w3.org
Telecons on 23 and 30 Dec
-------------------------
- All working group members should note on the Doodle (available
here: https://lists.w3.org/Archives/Member/w3c-css-wg/2015OctDec/0158.html)
if they'll be available for the 23 and 30 December calls.
Interoperability issues on border-image
---------------------------------------
- TabAtkins said that he had filed bugs and is putting pressure on
the teams handling gmail and calendar so that they no longer
rely on the improper behavior.
- Several implementors said they would be willing to change back
to the spec behavior once the two Google properties are fixed
as long as there isn't a long tail of other sites relying on
the bug.
- TabAtkins will report back to the group in January with any
updates on a timeline for the fixes.
Flexbox
-------
- RESOLVED: Accept the change for issue 5 (explained here:
https://lists.w3.org/Archives/Public/www-style/2015Dec/0018.html)
- No one was prepared to talk about if the proposed approximation
was the right solution to the problem with finding the
intrinsic cross-sizes of flex items.
- Implementors should review the proposal (available here:
https://lists.w3.org/Archives/Public/www-style/2015Dec/0055.html)
before next weeks' call and respond on the mailing list.
Anyone who hasn't given an opinion on the mailing list may
be asked to give one on the call so that a decision can be
made quickly.
- RESOLVED: Accept the change for issue 3
Align
-----
- Most of the align topics on the call were about changing items
from 'computed to' to 'behaves like'
- These items (topics: 3-7) will all be deferred to next week
to get more review.
- RESOLVED: Add the 'normal' keyword with bikeshed pending.
Scoping @font-face defined in shadow DOM
----------------------------------------
- TabAtkins brought his proposal to address the possibility of
font name being duplicated inside and outside a shadow DOM.
- The proposal would create a mapping where the external font
is translated into a guaranteed unique name when passed
into the shadow DOM.
- dbaron raised the possibility of instead using a function that
gets the name from the scope, which was a cleaner solution.
- TabAtkins will write-up a new proposal using functions and send
it to the mailing list for review.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2015Dec/0116.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Adenilson Cavalcanti
Greg Davis
Elika Etemad
Simon Fraser
Daniel Glazman
Tony Graham
Dael Jackson
Peter Linss
Myles Maxfield
Ryosuke Niwa
Edward O'Connor (IRC Only)
Simon Pieters
Anton Prowse
Alan Stearns
Greg Whitworth
Jeff Xu
Regrets:
Bert Bos
Angelo Cano
Tantek Çelik
Dave Cramer
Florian Rivoal
Ian Vollick
Johannes Wilm
scribe: dael
Telecons on 23 and 30 Dec
=========================
astearns: It's 5 after, we should start.
astearns: Any last minute items?
glazou: I sent one to the mailing list about 20 min ago.
astearns: About end of month meetings?
glazou: Yes.
astearns: That would be interesting thing to have people add to
IRC, but we'll have to use the mailing list since quite
a few people expressed regrets for today.
astearns: Can anyone who would like a meeting on 23 Dec put +1 in
IRC
<fantasai> +1 I'm free
<bradk> -1
<TabAtkins> -1, totally gonna be with family that week
<dael> +1 I'm available
<gregwhitworth> -1
<zcorpan> -1
<glazou> +1 doable
<hober> -1
astearns: Like I said, I'll put this to the private mailing list
too.
astearns: And now for 30 Dec. Who is available?
<glazou> -1 for 30th
<TabAtkins> +1 for the 30th
<dael> +1
<fantasai> +1 I'm free for 30th
<zcorpan> -1
<astearns> +1 for 30th
<bradk> -0.5
astearns: Okay.
TabAtkins: Do we want to do a doodle?
fantasai: I can set one up.
<fantasai> Member-only link
https://lists.w3.org/Archives/Member/w3c-css-wg/2015OctDec/0158.html
smfr: Can we move item 9 to the beginning? I have to drop.
astearns: Sure.
Interoperability Issues on border-image
=======================================
<astearns> https://lists.w3.org/Archives/Public/www-style/2015Dec/0080.html
TabAtkins: Chrome has a bug where we'll honor border-image even if
your border-style is set to none.
TabAtkins: That violates the spec and causes problems for other
browsers. I think calendar and gmail rely on it so Edge
copied and I think FF is considering it. We're bugging
internal to fix this, but does anyone think this is so
important we can't wait a bit to get the internals to
fix?
gregwhitworth: It's good to get it fixed, but no rush. It would be
great to see more equal, but sooner or later we're
going to be where we can't do web compat.
gregwhitworth: Is webkit still working toward the change?
smfr: Webkit is same as blink.
gregwhitworth: And will you guys change?
smfr: I think so, but this is two high level sites broken. I'm
worried there's a long tail of ones that will break.
gregwhitworth: We had this a long time. It was the Google
properties that forced our hand. I don't think
there's too much of a long tail, but maybe Firefox
is aware of more sites.
TabAtkins: So we have bugs on gmail and calendar and we'll make
sure there's pressure on them to fix. There might be
others, but those two big properties won't rely on it.
smfr: The patch that fixed the bug in webkit did have to change a
lot of tests since a lot had been written to assume the
broken data.
smfr: I think webkit would be willing to change behavior once the
Google properties are fixed. We'll see how it goes.
fantasai: Related note, I think Boris was complaining on Twitter
that Firefox was having to implement a lot of -webkit
because of the broken Google properties. Can we get that
to be a priority to fix to never code -webkit specific
when there's spec? How high would that have to go to be
on the to do list next year?
TabAtkins: I don't know, but I can get Alex Russell on the case.
<gregwhitworth> Alex Russell to the rescue.
fantasai: Okay. If you need more info ping Boris.
<zcorpan> border-image
https://www.chromestatus.com/metrics/css/timeline/popularity/43
with border-style:none
https://www.chromestatus.com/metrics/feature/timeline/popularity/1026
(but this counter hasn't hit stable yet iirc)
plinss: Can I suggest when implementors violate specs for Google
properties they whitelist it for just those Google
properties and not the web in general?
gregwhitworth: It sounds like the CV list hell we're in at times.
All the sudden you're enabling...you're going to
enable so you might as well do it for everyone.
TabAtkins: We have site specific code for when we had something we
wanted to change and a big site would break.
astearns: But when it's something like this where we're expecting
the change in the Google properties, we would get more
data if we whitelist them and move everyone else.
gregwhitworth: So should this be on the agenda for a call in early
January to see where we're at?
TabAtkins: I'm not sure what the group can do, but if you're
implementing something for a Google property, let us
Googlers know.
gregwhitworth: But for this thing tell us where things are?
TabAtkins: Yeah, that's cool.
astearns: So we're in a bit of a waiting game. Let's move on.
Flexbox
=======
align-items propagation to align-self on abspos
-----------------------------------------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2015Dec/0018.html
TabAtkins: align-items in flex and grid sets to propagate to align
unless you set to align-self. When we broadened align
and justify to work on everything, we want them to work
on for example abspos, but we have to deal with the
default of abspos right now.
TabAtkins: The cleanest way to do it is make the default not take
from align items so the alignment behavior on a
container doesn't mess with abspos, but you can align
explicitly. This is a minor change from flexbox, but
Christian who brought this up, is fine with it.
TabAtkins: If you have an abspos whose containing block is flex it
will no longer be effected by align items.
fantasai: Which for flexbox only has an effect on the staticpos.
fantasai: The flexbox doesn't have to be the containing block, but
it has to be the static position.
TabAtkins: There's a big confluence to make this happen. If
there's any concerns, speak up. We've made the change.
TabAtkins: Also, we're not even interoperable on this case yet.
astearns: Do you want a resolution?
TabAtkins: Flexbox is mature enough that any change of this
magnitude needs a resolution. We're trying to be
responsible.
astearns: Any objections?
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Dec/0018.html
fantasai: The reasoning is in the above e-mail.
astearns: Seems reasonable.
RESOLVED: Accept the change for issue 5
Intrinsic cross-sizes of flex items
-----------------------------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2015Dec/0055.html
fantasai: I don't think we can close on this. It's finding the min
and max content size of a column flex container with
multiple lines. You have a column flex with a max
height, they wrap until you run out of items.
fantasai: There's two issues. One is that when you're trying to
figure out what is the intrinsic size, how for you
calculate? And does the flex container wrap one column
or all?
fantasai: Wrapping the first doesn't make sense, you're asking it
to be shrink wrapped, but Firefox and Blink are not
currently wrapping all the columns, stuff overflows.
fantasai: IE does the calc correctly so we get good results.
<gregwhitworth> Blink wrap first item, Gecko first column, Edge
around all columns.
<Rossen> we aligned to the Chrome behavior for Edge in the
min-intrinsic case due to compat
<Rossen> we're not opposed to revert back to the IE behavior though
fantasai: The other problem is how do you find the size of these
columns, the width and height, given there's
interdependencies. If you want to do 100% correct you
have to put it in, size, put in another, see if it fits,
resize etc.
fantasai: All browsers are doing a heuristic that gives you a
sensible answer. They find the largest intrinsic size
and fit everything into that space. So if you have a
really long word that controls all the columns, they'll
all be that wide. It's pretty good for most cases.
fantasai: It would be good to have a better answer, but this works
pretty well. We're okay putting it in the spec, but it's
a heuristic.
fantasai: That's the discussion happening now. We need to hear
from more implementors. I don't think we can resolve on
the call because at least Christian is upset with our
proposal. Microsoft is fine with it, so I don't know
what to do with that discussion.
astearns: Is the heuristic that you would be considering putting
in the spec detailed enough on the mailing list for
people to evaluate?
TabAtkins: Yes. It's in the message in the agenda.
TabAtkins: It says the approximation.
fantasai: Our question is, is the approximation sufficiently
useful for us to specify and can we come up with
something better?
astearns: Are there people willing to talk about this on the call,
or should we go back to the mailing list?
TabAtkins: We need to close the issue soon, so mandatory yea/nay
next meeting?
astearns: Sounds like a good plan.
astearns: We'll put this on next week's agenda to give
implementors time to come up with an opinion. They can
either express on the mailing list or get put on the
spot next call.
fantasai: I prefer the mailing list.
<Rossen> fantasai, can you share the test cases please?
<fantasai> Rossen, for the flexbox issue? Sure
<Rossen> fantasai, yup
Align
=====
justify-content: auto -> start / stretch (on grid / flex items)
---------------------------------------------------------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2015Sep/0097.html
TabAtkins: Auto computing to start or stretch if you're grid or
not. There's a lot of issues dbaron had about things
computing to things. This one is justify content needs
to default to stretch for grids but start for
everything else.
TabAtkins: Previously it computed to start or stretch, now it just
stays as auto and acts like start or stretch at layout
time. Is that okay?
TabAtkins: Larger issue...is anyone willing to say anything about
align spec, rubber stamp us, or take a week to review?
<fantasai> Summary of all the alignment issues:
<fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2015OctDec/0143.html
<fantasai> Tab and I just went through a bunch of Box Alignment
issues. There were
<fantasai> a lot of concerns about values computing to other
values, with the
<fantasai> suggestion being to just have used-time equivalence.
<fantasai> The cases brought up were:
<fantasai> * justify-content: auto -> start / stretch (on grid /
flex items)
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Sep/0097.html
<fantasai> * justify-content: stretch -> flex-start (on flex items)
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Nov/0327.html
<fantasai> * 'left' and 'right' -> 'start' (when operating in the
wrong axis)
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Nov/0280.html
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Nov/0284.html
<fantasai> * 'flex-start' and 'flex-end' -> 'start' and 'end' (on
non-flex-items)
<fantasai> [rough corollary to the previous item]
<fantasai> * align/justify-items: auto -> start/stretch (depending
on 'display')
<fantasai> #2 in
https://lists.w3.org/Archives/Public/www-style/2015Dec/0061.html
<fantasai> Though we don't have a strong position, we're in favor
of making these
<fantasai> changes so long as the WG approves.
dbaron: I'm happy with changes that compute less. I haven't looked
in detail.
fantasai: Anyone else have an opinion?
TabAtkins: We can do a final agreement next week so dbaron can
review explicitly and anyone else that cares can.
astearns: Is css-align at the point where we need resolution on
these things? Or can you make the changes and people
review with time.
TabAtkins: They're changes in behavior to flexbox and grid in
several cases. Minor where you used to see one keyword
and now you get auto, but still.
TabAtkins: If it was internal, no, but this effects flex and grid.
fantasai: We want someone that isn't us to review.
<gregwhitworth> I'll take a look at it as well
astearns: gregwhitworth will take a look.
TabAtkins: mmmkay
astearns: dbaron will you have time in the next week to look at
these changes?
dbaron: Possibly. It's hard to know.
<fantasai> dbaron, they're summarized above
astearns: Does that mean, TabAtkins and fantasai, that items 3-6
are all in that state?
TabAtkins: And 7.
'auto' values in align-items/align-content/justify-items/justify-content
------------------------------------------------------------------------
fantasai: There's one issue we didn't cover.
fantasai: Where we renamed to normal.
TabAtkins: Ah, that didn't show up.
astearns: Link?
fantasai: Let me see if I can find it.
TabAtkins: It did show up in an e-mail.
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Dec/0061.html
fantasai: I think I found it ^
fantasai: To go over it, TabAtkins and I were going through
computed computation. We noticed the 'auto' on
align/justify was get this value, but in other places it
was do magic.
fantasai: We added the 'content' keyword to do the magic last
time, but we'd like to avoid it in align. So we'd like
to rename 'auto' to 'normal' where it's do the magic.
The magic is depending on display pick a proper default.
And then remove some computation that doesn't need to be
there.
fantasai: That's our proposal. Keep 'auto' on align-self and where
we have a new auto that means do the right thing for the
display, change that keyword to 'normal'.
fantasai: Thoughts?
fantasai: Good idea, bad idea? We think TabAtkins and fantasai are
always right?
dbaron: Is there a more specific name then 'normal'?
fantasai: I don't know. The keyword means pick a default alignment
appropriate to this display type.
TabAtkins: Some are start, some are stretch.
fantasai: It also means don't make me a BFC for the blocks.
<fantasai> (For align-content)
TabAtkins: If anyone can come up with a more descriptive name,
great. 'Normal' has been in a few other properties for
similar reasons so it seemed appropriate there.
<dbaron> it feels a little like there isn't a philosophy behind
what's 'normal' and what's 'auto'
<TabAtkins> dbaron: Yeah, there really isn't. :/
* bradk doesn't feel strongly without delving into it more.
<SteveZ> What about "displaytype" as the name
<fantasai> It's not a display type, it's an alignment
astearns: SteveZ mentioned one on IRC.
<fantasai> align/justify-self: auto | normal | start | end | etc.
<fantasai> align/justify-items: normal | start | end | etc.
<fantasai> align/justify-content: normal | start | end | etc.
fantasai: It wouldn't work because it's an alignment value. Their
properties would look like ^
fantasai: It will eventually...the used value will be start or end
or stretch, not a display type. Which it is depends on
the display type, but it's the condition not the effect.
astearns: It seems the purpose to 'normal' is something we use
'auto' for in other cases.
fantasai: We can't use 'auto' because 'auto' is taken.
TabAtkins: Unless we're willing to do a compat break on flexbox
and change its initial value.
fantasai: I think that might break stuff, bad idea.
TabAtkins: I would believe you if you said it broke something.
<gregwhitworth> I want as few changes to flex as possible, each
change seems to break stuff :/
* fantasai is pretty sure this would break stuff
<SteveZ> What about align: by-displaytype OR for-displaytype
astearns: It sounds to me like this change is in a different
category than the list of 3-7 on the agenda.
fantasai: They're related, but that's why we pulled it out.
fantasai: So there's a question of what do we call it, but there's
also a question as to if the keyword is a good idea.
TabAtkins: We can't not have it.
<dbaron> I think it's good to expose the behavior.
<gregwhitworth> I agree with the keyword since it seems to be
necessary
fantasai: We can resolve on the keyword, call it 'normal' for now,
change the name if someone comes up with better.
fantasai: dbaron, TabAtkins, and I think it's a good idea. Anyone
think this isn't a good idea?
<SteveZ> I think the idea is good, but the name is bad
RESOLVED: Add the 'normal' keyword with bikeshed pending.
astearns: To close on 3-7, we have at least one person, maybe
another, who will look at the changes. We will take all
of them as a group on a future call.
Flexbox
=======
Percent resolution in the presence of min-size: auto
----------------------------------------------------
<astearns> issue #3 on
https://lists.w3.org/Archives/Public/www-style/2015Sep/0038.html
fantasai: This is an issue where min-size: auto creates an issue
where every flex item is intrinsically sized. So percent
resolution won't work by default. We raised this and
decided to ask the implementors what to do because the
two options are we do two pass layout or they don't
resolve.
fantasai: We did a call with Microsoft and Blink and Mozilla
implementors. For this one they can do two-pass layout.
So that's what we put in the spec. So we wanted to bring
it back to the WG to say this is what you want to do and
resolve officially.
astearns: Is there a summary of the implementor conversation?
fantasai: Yeah, I thought I linked it. Let me get it out of the DoC.
astearns: You linked to some minutes.
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Dec/0014.html
fantasai: There it is^
fantasai: I did do the wrong link in the e-mail. Sorry.
fantasai: If people need more time because I did the wrong link,
that's fine.
astearns: Would anyone like more time to look into this?
astearns: silence = no. Does anyone object to resolving on this
now?
<dbaron> I guess I'm a little worried about performance
astearns: We have dbaron saying he's a little worried.
<dbaron> But it sounds like dholbert was ok with it, I guess?
<gregwhitworth> dbaron, yes
<fantasai> dbaron, yeah
TabAtkins: We can discuss it with...urm...dholbert.
dbaron: That's fine. I'm still worried about the performance here,
but it sounds like this isn't a big change the performance
characteristics. Is that the case?
fantasai: We believe so. In most cases it'll optimize away. If the
min-size doesn't control layout you won't need another
pass
<dbaron> ok
RESOLVED: Accept the change for issue 3
<fantasai> https://drafts.csswg.org/css-flexbox/issues-lc-20150514#issue-3
<fantasai> (above issue)
astearns: adenilson joined...are you okay with waiting to get the
Google properties to move off of this issue and having
the browsers change? (Topic 9)
adenilson: Yes, totally
Scoping @font-face defined in shadow DOM
========================================
<astearns> https://lists.w3.org/Archives/Public/www-style/2015Dec/0113.html
TabAtkins: I've been talking about this for a bit. This sets
font-family to foo. It inherits down, and inherits into
a shadow tree. That's fine. If the component that
doesn't know what's going on outside itself clashes
with a font name where the outer page font face is the
same as a system font, the component accidentally grabs
the wrong font.
TabAtkins: We've restricted shadow DOM from having these odd
things before. We're restricted the outer pollution,
but CSS construct that create a global name have the
same problem. Regions could be really confusing where
things do a total page break.
<gregwhitworth> this really sounds like we need better css
encapsulation in regards to shadow trees
ChrisLilley: I don't believe...where you said it inherits isn't a
natural consequence. That should be a 1d thing. It
shouldn't flow the other way. If the component
declarers it doesn't effect the outer.
TabAtkins: I agree. The 1d flow is the hard part. Flowing into the
shadow is the problematic part. This is related to
macro hygiene issues where you have variables in a
macro that need to not interfere with user declared.
The only solution is re-write the font name, maintain
mapping of the original names to the re-write, but
prevent accidental collisions between inside and
outside names.
TabAtkins: If the outer has foo, whatever crosses into the shadow
is something guaranteed unique. Then if the shadow uses
foo, it wouldn't select the outer font face. If they
wanted to they could look at the inherited value, but
it prevents accidental. And we would do that for
anything that declares a global name. If they're
exposed through inheritance we'd have a secret mapping.
<gregwhitworth> so foo becomes shadow-foo vs global-foo?
<gregwhitworth> This sounds feasible
ChrisLilley: That seems to make the basic case harder where you
want to use the same as the outer. You have to do the
import yourself.
TabAtkins: By default inheritance still works. The name you still
with be a guaranteed unique name, but will refer to the
correct font.
ChrisLilley: Okay. And the same as variables?
TabAtkins: Variables are a communication channel so they're
staying the same.
glazou: It's important to keep that.
TabAtkins: Yeah.
astearns: I was going to say the same. If using inheritance wasn't
an option for a component and they did want to get
something in, they would have variables as the vehicle.
<glazou> exactly what astearns said
TabAtkins: Yes, if they really want to, they could smuggle
something in...though you wouldn't want to have that...
gregwhitworth: So if I'm an ad on your page, using web components,
and I want to inherit your fonts, I don't know your
variables.
TabAtkins: Using the inherited font keeps working. We just do a
re-write and have a name mapping.
gregwhitworth: Okay, cool.
dbaron: It seems a little like instead of unique names you could
use a function that refers to a name in the parent scope.
Though I'm not sure which is better.
TabAtkins: We'd have to stack them to know which scope, but it's
an alternative. We just want a normal font name to
never collide. Function could achieve that and that's
fine too. It takes a parent function and evaluates a
keyword there and nest to go a few scopes up.
rniwa: Is this a proposal? I'm confused what we're discussing. Is
this a proposal for scoping or...?
TabAtkins: There's a concrete proposal on the mailing list. I just
sent one...it's in the agenda.
TabAtkins: You can read that for more details.
astearns: For font-family property are you making the entire
property value transformed or individual components?
TabAtkins: Individual components that refer to a font-face rule.
The issue is font-face rules not accessible. See what
are @font-face names and re-write those.
astearns: Are they user-idents? Can we spec that that it's all
user idents?
TabAtkins: I've have to check but probably? If it's an enumeration
of things that are defined...yes, in general custom
idents is what we'd want to rely on if we're defining a
global thing.
dbaron: One thing that seems odd is making computed value of
font-family depend on font-face rules which it currently
doesn't. That seems messy.
TabAtkins: That's what it would do, but I don't see a way around it.
dbaron: The idea of the function that gets the name from the scope
might be a way around it.
TabAtkins: Ooooh...that would work. You could put it on system
fonts and it would be the same name, but that's fine.
That works for me.
TabAtkins: I like that.
<gregwhitworth> sounds good
TabAtkins: Let's go with that. If that sounds okay I'll write up a
formal proposal for the list and make sure it's
applicable to everything that matters.
astearns: Sounds like a good step to me.
rniwa: For the function, how to we solve the shadow DOM, does it
solve that?
TabAtkins: Let's do odd details on the mailing list with concrete
examples, but that's a good idea.
myles: And you'd still re-write, but with a function.
TabAtkins: And we'd be able to do it unreservedly. We re-write all
of them to refer to the parent scope.
astearns: Alright, let's go with that. We're at the top of the hour.
astearns: Thanks everyone.
<TabAtkins> "font-family: my-custom-font, Comic Sans MS,
sans-serif;" would inherit into a shadow as "font-
family: outer-scope("my-custom-font"), outer-scope(
"Comic Sans MS"), sans-serif;"
<dbaron> although this would need some way to account for multiple
nested scopes
<dbaron> not sure if nesting outer-scope(outer-scope()) is the
best way to do that
<myles> dbaron: it seems natural to have nested function calls
<TabAtkins> Yeah, I presume "font-family: outer-scope(foo);" would
inherit into a further shadow as either "outer-scope(
outer-scope(foo))", or we can give an integer value
like "outer-scope(foo, 2)"
Received on Thursday, 10 December 2015 00:47:04 UTC