- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 22 Feb 2017 20:38:20 -0500
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Path to CR for CSS Fonts 4
--------------------------
- There was general agreement that ChrisL's proposed approach to
trim Fonts 3 and take it to REC was a good way forward.
- ChrisL will prepare a list of items that don't have two
implementations or don't have sufficient tests and send it for
review.
Use flex-order first or document-order first item's baseline?
-------------------------------------------------------------
- TabAtkins will determine the most interoperable approach for
order-modified document order and propose it to the group for
resolution.
Adding a 'size' shorthand for 'width'/'height'
----------------------------------------------
- No one was opposed to the shorthand, however there was very low
implementer interest.
- Some of the low interest came from the complexity of using
the word 'size' as it's already used in the @page rule.
- The discussion will be tabled until there's implementor interest
in using 'size' or a better name proposed.
Default color of text-shadow
----------------------------
- RESOLVED: Tie the color of the text shadow to the currentColor
with spec text tbd.
Serialization of CSS declaration block returned from getComputedStyle
---------------------------------------------------------------------
- RESOLVED: Have the declaration block serialize as an empty
string.
Percentages used to compute to auto; now compute to a percentage but
are used as auto
--------------------------------------------------------------------
- RESOLVED: Define behaves as auto in CSS Sizing. TabAtkins and
fantasai will write this. (In reference to
https://github.com/w3c/csswg-drafts/issues/1051)
What are "form controls"?
-------------------------
- TabAtkins will summarize his thoughts on GitHub on what makes a
form control and the difference between using 'behaves as' and
'computes to' and the group will revisit next week.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Feb/0085.html
Present:
Rachel Andrew
Tab Atkins
David Baron
Bert Bos
Dave Cramer
Alex Critchfield
Elika Etemad
Tony Graham
Dael Jackson
Brian Kardell
Vladimir Levantovsky
Chris Lilley
Peter Linss
Michael Miller
Liam Quin
Melanie Richards
Jen Simmons
Alan Stearns
Steve Zilles
Regrets:
Tantek Çelik
Scribe: dael
Path to CR for CSS Fonts 4
--------------------------
astearns: Let's start. Anything extra for the agenda?
ChrisL: Fonts 3 hasn't been updated for a long time and it doesn't
use bikeshed. Fonts 3 describes web fonts which is now
used everywhere. It's on 64% of top websites. It needs to
be a REC.
ChrisL: It also has low level open type support. More high level
font variant stuff is only implemented in Firefox.
myles: It's implemented in webkit.
ChrisL: I made a list of things in fonts 3 that aren't tested.
Fonts 4 has more text and better description of open fonts
stuff. It also uses bikeshed. All current discussion is in
fonts 4.
ChrisL: I think we need to trim from fonts 3 the small things that
aren't reliably impl. Put that in PR. Publish fonts 4 and
make that the current item.
ChrisL: I think dbaron pointed out that some of the things
fantasai wanted to push were just a title.
ChrisL: It's an area of active interested and active impl.
Vlad: I agree with ChrisL pretty much. One thing, font
variations-how it's in the draft what's missing is the
responsive layout support. Responsive is the most desirably
feature but what we have now is static.
Vlad: It's all nice to have, but I think we do need to put a
little more effort to make it a usable universal solution
ChrisL: I agree.
astearns: Is that issue recorded?
Vlad: I haven't, but I will. this is perfect timing because I just
finished fonts for OFF so I have free time.
astearns: I also think ChrisL's plan makes sense. Someone would
need to go through fonts 3 and make decisions.
ChrisL: I'm happy to do that. I think I have a list as a starter.
astearns: That's one thing I wanted to clarify. We should trim
things without 2 implementations, but also trim things
that don't have tests and just go to PR with things that
are interop tested. That would be fastest.
ChrisL: There's font object stuff, yes.
dbaron: It would be good to publish the list and see if people
have tests.
ACTION ChrisL come up with list of things to trim from fonts level 3
<trackbot> Created ACTION-830
astearns: Once we have that list we'll start the rest of the work.
astearns: Anything else on this topic?
Use flex-order first or document-order first item's baseline?
-------------------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/995
TabAtkins: Previous issue noticed there's an inconsistency between
grid and flexbox on which order of elements where we
take to determine the baseline. Grid is very specific.
Flexbox doesn't have a special specification which
implies standard dom order
TabAtkins: That's inconsistent with grid and according to a test
browsers reasonably interoperable to use the
order-modified order. So a fix to flex would bring us
into agreement with grid and impl. Just need a
resolution.
astearns: Clarification. When you say order-modified order that
could be different than visual if flexbox is set in
reverse.
TabAtkins: Great question.
TabAtkins: Let's check the test.
TabAtkins: Not sure at this moment. Correct answer is likely
whichever is more interop.
astearns: I'm happy to go with more interop.
astearns: Other opinions?
dbaron: Fine with me as long as you let whoever is in the less
interop half know.
ACTION TabAtkins determine what is more interop (on use flex-order
first or document-order first item's baseline? issue) and
bring to group for resolution.
<trackbot> Created ACTION-831
<TabAtkins> Quick test shows that Chrome uses straight
order-modified document order - flex-direction doesn't
matter.
Adding a 'size' shorthand for 'width'/'height'
----------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/820
TabAtkins: People keep wanting a short hand to set width and
height together.
TabAtkins: Size would be obvious, but it's taken by @page rule. So
should we use size anyway and it's different in a style
context or do we have another name? There's other names
in the thread, but I'm not a fan of any of those. My
personal preference is we accept that @page rule is a
different mechanic so it's different.
TabAtkins: I'm not sure how other impl are with this, though.
<bkardell> some preprocessors implement this and call it size
<bkardell> nobody seems to be too confused by it or anything,
seems like paving the cowpath makes most sense
fremy: I don't expect this to be useful enough to be worth impl.
But I don't mind.
myles: That's what I was going to say. If this doesn't add new
functionality it's pretty low priority.
TabAtkins: There's no new functionality. There's a sub discussion
about later handling aspect ratio at which point a
short hand makes sense.
jensimmons: It's true it doesn't add functionality, but it changes
authoring experience. I think that's not minor. It's a
thing.
astearns: [reads bkardell on IRC]
jensimmons: It seems to be a thing people want. And I could argue
that since it's no new functionality it's easy to impl.
myles: Has this been done in other places?
TabAtkins: Where we add a shorthand to agglomerate disparate
properties?
dbaron: The @page thing is what makes this hard.
TabAtkins: It wouldn't be trivial in chrome.
TabAtkins: I think this is largely a failure of early OM spec, but
we're in that situation.
jensimmons: Would it be easier if we don't use 'size'?
TabAtkins: It would avoid a complication.
astearns: But then you have worse author experience because people
have to remember the name.
jensimmons: The question is if there's a better name and we
haven't thought of one yet.
TabAtkins: I haven't seen a good one yet.
astearns: What I think I'm hearing is no one has an objection to
using 'size' but there's no implementor lining up to
implement the shorthand with that name.
TabAtkins: I think so.
TabAtkins: I think we should table until we can get implementor
interest or a name we believe has a good chance of
being accepted.
astearns: I think that makes sense. Table this, look for a better
name and/or implementor interest. If we can get more
authors asking for size it would move implementor
interest.
fantasai: It's worth noting inline size and block size use 'size'.
If we use a different word we're inconsistent.
astearns: Can you add that to the thread if it's not there?
Default color of text-shadow
----------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/942
TabAtkins: tantek did the agenda+. The core issue is easy.
TabAtkins: The text says that shadows by default use the color of
the ink they're shadowing. In simple text this is the
same as saying use the color property. But in complex
cases we're not sure we intended this. For example text
decorations. This is probably what it was meant to
suggest. But as written it means that multi-color fonts
should cast multi-color shadows and that's probably not
intended.
TabAtkins: Unless we did mean that we should amend the text
somehow. We're not interoperable on matching text
decoration color so we can change.
ChrisL: I agree we shouldn't cast multi-color shadows.
fantasai: I think going with the simple answer is the best. Most
cases the text shadow is a specified color or happens to
default to black.
<SteveZ> what about white on black pages?
dbaron: The other maybe related thing is what changes to color
happen under selection which is also non-interop.
TabAtkins: You're right that keeping original text shadow looks
bad when you invert the color under highlight.
TabAtkins: I'm not 100% sure how to handle given that the
selection is at a smaller level then where the text
shadow renders.
astearns: Should we resolve on the first bit and do selection
separately?
TabAtkins: I'm okay to leave an issue for handling selection
better.
fantasai: You can do whatever you want on selection for
::Selection selector.
fantasai: I guess you can't...if we split test shadow into multi
long hands you could do that.
astearns: I wasn't talking about leaving selection as an issue. I
meant for discussion right now separating the two things.
astearns: Proposal was to have the color of text shadow just go to
the color of the text and not be affected by text
decoration or emoji color.
fantasai: I would be more specific and say defaults to
currentColor.
TabAtkins: Yeah.
astearns: Obj to specifying text shadow uses currentColor?
<ChrisL> sgtm
dbaron: One comment is how this interacts with text-fill-color and
text-stroke-color. It's possible it should use text-fill.
TabAtkins: Those properties don't actually exist yet...
<ChrisL> yes, it should be text-fill-color (once it exists)
fantasai: I think more interesting question is does that give
correct behavior on inheritance.
fantasai: It's probably fine.
dbaron: Other interesting thing is when you have a text shadow
crossing multiple elements that are different colors.
TabAtkins: mmmhum
fantasai: If you set the color to be a color you paint those as
one shadow. If you don't you do whatever happens in that
case.
astearns: Didn't sound to me like anyone objected to specifying
text shadow uses currentColor.
dbaron: We just need to make sure it's the right currentColor.
TabAtkins: Yeah.
TabAtkins: In chrome if I set text color on a parent and have
child with different color it takes the color of the
child.
astearns: Can we figure this out on the call or do we need an
action for someone to write text?
TabAtkins: Sounds like we should resolve to go in this direction
and we don't want multi-color shadows. Exact spec text
to be resolved on a different call.
astearns: Proposal is tie the color of the text shadow to the
currentColor with spec text tbd. Objections?
RESOLVED: Tie the color of the text shadow to the currentColor
with spec text tbd.
astearns: Now what to do with selection?
TabAtkins: Given text shadow inherits down I think that standard
cascade will handle this properly if we use
currentColor.
TabAtkins: When you try and render the text now you check the
color and render the shadow appropriately so you get a
shadow matching the selected text color. I believe it
falls out. I wouldn't be surprised if the inherits down
to text nodes isn't defined throughly.
astearns: Other opinions?
astearns: Let's get the text for the last resolution drafted and
then we'll see how that fits with selection.
Serialization of CSS declaration block returned from getComputedStyle
---------------------------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/1033
astearns: Also from tantek.
astearns: Anyone up to date on this?
TabAtkins: Not enough to talk about it.
astearns: fremy I see you on the thread.
TabAtkins: I'm remembering.
TabAtkins: We might be able to address quickly.
TabAtkins: When you call getComputedStyle you get a declaration
block. How do you serialize that? Firefox and Edge say
empty string. Chrome and Webkit try and serialize it
out as a {} block. It doesn't have a good rhyme or
reason as to what appears.
TabAtkins: I suspect we can standardize on FF/Edge and do empty
string.
TabAtkins: There's a webcompat issue reported to Firefox, but it's
a Google property and we can get that fixed.
myles: Why wouldn't anyone want to serialize this?
TabAtkins: Presumably there's a reason, not sure why.
TabAtkins: Reading the issue.
TabAtkins: Looks like it's not a good reason.
TabAtkins: Due to the way the Firefox vs Chrome is working it's
triggering a really bad code path, but it's not being
used for a good purpose. So we can evangelize and get a
fix on our end.
astearns: Proposed: have the declaration block serialize as an
empty string. Objections?
RESOLVED: Have the declaration block serialize as an empty string
Percentages used to compute to auto; now compute to a percentage but
are used as auto
--------------------------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/1051
fremy: I added it yesterday and if people need time we can defer.
fremy: In CSS 2.1 if there's a percentage height that's pegged to
something that's auto the computed value becomes auto.
fremy: Apparently that was changed in CSS 2.2. You now follow the
same rules as if it's auto. I don't know why we did this.
dbaron: The change was intentional because we don't want computed
values to depend on complicated things that contain
layouts. Without this change the computed value of height
depends on the display property which is complicated and
we don't want inheritance to depend on that.
TabAtkins: Similar to various issues about computes to vs behave
as.
fremy: So then we should fix all the specs?
TabAtkins: Yeah.
fremy: That's some work.
dbaron: You can introduce terminology to do that.
fremy: But you need to do it on some spec first.
fremy: Maybe Sizing.
TabAtkins: Probably so.
fremy: Can we resolve on that? CSS Sizing will say something about
when the height behaves as auto?
TabAtkins: We can do that.
astearns: Proposed resolution is have some text in CSS sizing that
describes the behaves as auto behavior.
fantasai: Is it that behaves as is undefined or behaves as auto?
TabAtkins: Neither. Other specs that want to care about behaves as
auto are caring about computes to auto.
TabAtkins: We could do with a term of art here. We add a term that
nails it down.
fantasai: If the confusion is if the behaves as is the same as
computed as...
TabAtkins: That's not the confusion
fantasai: [missed]
<fantasai> Is it confusion over when the clause triggers or what
happens when it does?
TabAtkins: It's not confusion as to when it triggers, it's that
old spec texts were written when it was computed to
auto. There's no confusion, there's a needed spec
update and it will be easier to be consistent with a
term of art.
fantasai: I don't understand still. If there's an old spec that
said computes to auto we fix that spec.
TabAtkins: Yes. Question is how to have all the specs that do it
do it consistently. Solution is sizing does it and they
link to the term in sizing. There's no possibility of
slightly differing text.
dbaron: TabAtkins should repeat the thing he said.
TabAtkins: It's not confusion about when the thing triggers. Old
specs refer to the old process. They need an update,
but we want a consistent way to do that update. Sizing
defines a term of art of this and when we update all
the other specs they refer to this term and everyone is
consistent.
TabAtkins: Nothing more than we fix the specs but we use a term
for consistent
fantasai: Instead of referring to the value of auto we say height
is foo...
astearns: Instead of saying computes as auto we refer to this term.
dbaron: There are a bunch of specs that test if the computed value
is auto. They need to test if it's auto of a value where
it's supposed to be threated as auto.
fantasai: Or we define behaves as auto.
TabAtkins: I'd rather make this explicitly clear instead of doing
an implicit patch to every spec.
fantasai: That doesn't make sense. You're proposing to patch every
spec.
TabAtkins: You're talking about making a change in one spec that
implicitly updates every other spec where when you read
a spec you have to remember that this updated in
another spec.
astearns: I'd like to resolve we define behaves as auto in CSS
sizing and action TabAtkins and fantasai to get it done.
astearns: Objections?
RESOLVED: Define behaves as auto in CSS Sizing. TabAtkins and
fantasai will write this.
<dbaron> I don't think the term needs to be "behaves as auto"; it
could be something else...
What are "form controls"?
-------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/1024
astearns: In Seattle we discussed some things about form controls
and decided to have spec text, but someone noted form
controls isn't defined.
TabAtkins: yeeeeaaaah.
fantasai: Form control is anything that submits or could submit.
TabAtkins: That's not the thing, though. There's a layout behavior
that's shared by form controls and that's the thing
we're trying to differentiate on. They're the almost
replaced elements.
TabAtkins: I opened an issue to figure out what this concept is.
Then we can define which elements follow this concept.
astearns: Boris had an additional concern that if we made this
change to talk about this set of things he now has to
worry about what elements are being styled instead of
looking at elements.
TabAtkins: Yeah, change should be a behaves as, not a computes to.
TabAtkins: Technical wording of resolution was behaves as. It got
interpreted as computes as. In my opinion it's not
unreasonable to change.
dbaron: I think in this case there was discussion that it was not
computes to.
fantasai: I don't remember, but what I was doing I think as I
noted the way that computed style behaves for something
with or without a box is different and in style
computation layer you'll need to treat it differently.
dbaron: getComputedStyle is not computed values.
TabAtkins: She's talking about general computation process.
dbaron: This cannot be computes to.
fantasai: I'm fine to make it what it needs to be, but a bunch of
stuff depends on this. It's not at layout level.
TabAtkins: If you display not a form control it goes away. It
effects other properties because the box goes away. If
there's display none but a form control that effects
layout because it's an inline box.
TabAtkins: So there's still a computed value dependency, even if
we way behaves as. You have to worry about that in
computation.
TabAtkins: Usually behaves as it will become that in the used
value. This you have to know it's inline up front.
astearns: If that's true and it's also true that we can't have
this dependency, can we still do this behaves as inline
that we resolved on?
dbaron: I think we can, but I'm not in front of a computer right
now so it's hard to figure out.
TabAtkins: We could go the other direction and make display
contents act like display none.
fantasai: What happens if I apply float? Inline or block? Float
and display inline combo is not defined.
fantasai: Same with position. There's probably a bunch of things.
fantasai: Either way we go there's a whole can of worms here.
<dbaron> ok, maybe we actually can't do this easily
TabAtkins: I believe the entire thing came out as a result of
people trying to be complicated with making contents do
extra smart things with replaced elements. Going simple
with display:none solves all the problems.
fantasai: Discussion came out of "this is not defined" and we had
a bunch of options how to define it.
fremy: We decided on inline because that's what FF was doing. If
they're fine to change I think we can.
TabAtkins: Given dbaron needs time, let's re-open the issue about
display contents computing to inline. I'll put in a
summary and we can pick up next week.
ACTION TabAtkins to update the issue on [css-display] What are
"form controls"? and bring it to next week's call
<trackbot> Created ACTION-832
astearns: Thanks all and we'll talk next week.<div
id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
<tr>
<td style="width: 55px; padding-top: 13px;"><a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon"
target="_blank"><img
src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"
width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
<td style="width: 470px; padding-top: 12px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Virus-free. <a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link"
target="_blank" style="color: #4453ea;">www.avast.com</a>
</td>
</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
height="1"></a></div>
Received on Thursday, 23 February 2017 01:46:25 UTC