- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 16 Aug 2017 20:58:45 -0400
- 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.
=========================================
Intrinsic size of replaced elements incorrect
---------------------------------------------
- RESOLVED: Close the issue (https://github.com/w3c/csswg-drafts/issues/794)
Should last-baseline's fallback alignment be safe or unsafe?
------------------------------------------------------------
- fantasai will make a blog post to get feedback on this issue
(https://github.com/w3c/csswg-drafts/issues/1611 )
Fonts
-----
- Myles wasn't on the call so all resolutions are pending his
review and chance to object.
- RESOLVED: Descriptors will be called color-<integer>
- RESOLVED: Define family without leading 0s
- RESOLVED: Move CSSFontFeatureValuesRule to L4 Fonts
- RESOLVED: Move the font-language-override property to fonts L4
- RESOLVED: Property name is font-variant-emoji (Issue 1092)
- The values for font-variant-emoji will continue discussion
on github. The options raised on the call were:
- monochrome | chromatic
- symbol | graphic
- plain | rich
- plain | graphic
- RESOLVED: Close issue 1144 no change
Definiteness of flex items' main size depend on flex-basis's
definiteness
------------------------------------------------------------
- Edge & Firefox will review their code in order to discuss this
topic next week.
Baseline self-alignment may affect the intrinsic size contribution of
the alignment subject
---------------------------------------------------------------------
- fantasai requested review of her edits for this issue (edits in
green): https://drafts.csswg.org/css-grid/#algo-content
Adding a 'size' shorthand for 'width'/'height'
----------------------------------------------
- The group agreed that the shorthand would be good, but shouldn't
be called 'size'. However, there wasn't time to come up with a
different name.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Aug/0016.html
Present:
Rachel Andrew
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Alex Critchfield
Elika Etemad
Tony Graham
Dael Jackson
Chris Lilley
Peter Linss
Anton Prowse
Melanie Richards
Jen Simmons
Geoffrey Sneddon
Lea Verou
Greg Whitworth
Regrets:
Rossen Atanassov
Brad Kemper
Alan Stearns
Scribe: dael
Spec Rec next steps/blockers
============================
Chris: Let's go
Chris: Any added agenda items?
Chris: Anything to report?
Chris: I didn't see an email. If anyone has anything to say?
[silence]
Intrinsic size of replaced elements incorrect
=============================================
github: https://github.com/w3c/csswg-drafts/issues/794
fantasai: There's a definition in the sizing spec about what the
min and max content size of images are. We defined to
account for sizing constraint in opposite axis. We're
defining by reference to css 2.1
fantasai: dbaron wanted these keywords to represent actual
intrinsic size. I spoke with him and he said given the
way impl behave in grid he's unhappy about defining it
that way but it is okay. As far as the definition dbaron
wants we can add another set of keywords if authors want
to express that.
fantasai: Seems unlikely as an author want, but might be useful
for Houdini things.
Chris: dbaron?
dbaron: I think that's a reasonable summary.
fantasai: If everyone is happy with the state we can close as
we've defined the sizing.
Chris: Objections?
Chris: Anyone need time to think?
RESOLVED: Close the issue
Should last-baseline's fallback alignment be safe or unsafe?
============================================================
github: https://github.com/w3c/csswg-drafts/issues/1611
fantasai: We discussed at F2F, wanted more feedback. I don't think
we got any.
fantasai: We need feedback from authors to know if there's a
reason to do one or the other. Implementor-wise either
way is doable.
Chris: How do we plan to solicit that feedback? Twitter poll?
fantasai: I feel this is a niche case that's hard to describe in
twitter.
fantasai: If you were to have a bunch of last baseline aligned
items that are taller than the row they're in, would you
want them to break the last baseline alignment or
overflow to the top?
fantasai: We understand, but that's hard to convey.
Chris: It needs a blog with illustrations. Does anyone want to
write such a thing?
<tantek> blog post + illustrations > twitter poll
Chris: As a group we're bad at getting high quality user feedback.
fantasai: We've tried and largely it's no response. I can write a
blog post on our blog. We don't have a commenting system
that's functional. I can use css3.info as commenting.
<tantek> hey I can help with the functioning comment system, if
someone wants help with their blog
<tantek> we have standards for that in #social now :D
Chris: Sure. It can also be linked to and tweeted.
Chris: Anything else to say?
ACTION fantasai make a blog post to get feedback on
https://github.com/w3c/csswg-drafts/issues/1611
<trackbot> Created ACTION-860
<rachelandrew> re: author feedback I think it is hard to get
feedback on stuff if authors can't think up a use
case for the thing - I'd write about the fallback
alignment but I've not come up with a situation
where I might end up in that situation. I try and
write these things so people think " I might need
to do that and here is a problem I can see".
Fonts
=====
@font-palette-values uses illegal integer descriptor names
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1523
Chris: Is Myles on?
TabAtkins: I can summarize the issue I think.
TabAtkins: This is about numeric descriptors? Yeah. Per css syntax
you can't have numeric property names. It's not
necessarily a problem to change, but it's not 100%
clear we want to vs using a name that is an ident.
TabAtkins: I don't have strong opinions, but this doesn't parse
successfully right now.
Chris: There was discussion on that earlier today. Suggestion
is...the thing that says the number of palette entries is a
uint16. Is there a way to declare the pattern?
TabAtkins: Same as custom property. Defining a family of
descriptors is what's needed here. There's no way
around that.
Chris: Could you give the syntax for that?
TabAtkins: It's not anymore tricky than variables where I say use
the pattern for the name. --* where * is anything
following restrictions. It's a number-* and we put in
restrictions and prose.
TabAtkins: That's orthogonal because no matter what we need to
accept an arbitrary number of descriptors. However,
current syntax per spec doesn't parse.
Chris: That's the worst problem. I'm assuming no one is arguing to
change syntax for numbers. I've seen people argue against
that.
TabAtkins: Myles says leave as number and change syntax spec.
That's fine, but it needs to have full agreement of
implementors. Or should we go back and say make these
an ident family instead of a number family.
TabAtkins: I want a change to syntax approved by a wider set of
people.
Chris: Which way do we want to go with this? I don't think Myles
was against renaming descriptors. It's more cumbersome but
eh.
leaverou: How about we step back and think if those are good names
for the descriptors. I think something like color-1...
TabAtkins: I agree. I don't think the numbers are very good
either. color-1 is more explicit.
leaverou: And seems reasonable to reserve int for something more
substantial.
<fantasai> in favor of the readability argument
Chris: I'm hearing an argument against raw int. Does anyone like/
dislike color-n?
<tantek> is also in favor of the readability argument
fantasai: I'm in favor for the readability argument from leaverou
<Bert>: I'd rather not change the syntax. Allowing numbers as
idents takes away some opportunity for error checking and
I wonder what happens with APIs that expect CSS property
names...
Chris: Objections?
Chris: I see IRC support.
RESOLVED: Descriptors will be called color-<integer>
fantasai: What about leading 0s?
Chris: If it's int you could put it in hex I guess. We don't want
a thing where color-1 and color-01 are different.
<tantek> interesting. because color:#1; color:#01; color:#001 are
all different :P
<tantek> just saying, not theoretical
<leaverou> tantek: Indeed. #1 and #01 are invalid
<tantek> leaverou: meh, they do stuff in browsers :P
<leaverou> tantek: Not in CSS.
Chris: TabAtkins is there a problem?
TabAtkins: Depends. Easier if we define that the family of
properties is int without leading 0s. It's possible to
do the other way. It's not a huge deal to discard extra
digits. It seems like that would make it more annoying
in a theoretical prospective. Other places with family
we compare on exactness.
Chris: I like canonical. I prefer we say what the canonical form
personally.
Chris: Other views?
fantasai: If you have canonical it has no leading 0s because we
don't know how many 0s to use.
Chris: Exactly.
plinss: It would probably sort badly.
Chris: Correct.
Chris: Is there a use case to sort descriptors? They might type in
odd orders so they override. So it's reasonable they should
append.
plinss: I'm not overly concerned. Hand authors won't be concerned.
It's tooling.
TabAtkins: It also depends on you have at least 10 values. Most
palettes are smaller.
Chris: That's correct.
Chris: That we've seen so far anyway.
TabAtkins: It's a matter of tooling and they can improve.
Chris: Objections?
RESOLVED: Define family without leading 0s
Chris: Should we leave room for Myles to object?
TabAtkins: Yes, absolutely. Myles should feel free to object since
he's not here.
The CSSFontFeatureValuesRule interface has only one implementation
------------------------------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/1713
Chris: This only has one impl. This looks like a prime candidate
to move to fonts 4.
Chris: We've moved the OM to fonts 4 in effect.
Chris: Has anyone got great news that they'll impl or should we
punt?
Chris: Objections to moving to L4?
RESOLVED: Move CSSFontFeatureValuesRule to L4 Fonts
Chris: Again, myles can object in the next few days.
The font-language-override property has only one implementation
---------------------------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/1714
Chris: Any plans for implementing this?
fantasai: Any status on font override descriptor?
Chris: It was added. But if the property is moved the other stuff
would be too. other stuff=descriptor
fantasai: Great. Is the descriptor more wide implemented?
Chris: I don't think so.
fantasai: If there aren't impl with the descriptor moving to L4
makes sense.
fantasai: If the descriptor was there it seems less work to impl
the property.
Chris: I think Gecko is only impl for both.
Chris: Objections?
RESOLVED: Move the font-language-override property to fonts L4
font-presentation doesn't have a great name
-------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/1092
Chris: It's if you present emoji as visual emoji or text.
Chris: There has been some discussion on this. Who wants to speak
to this?
* tantek thought emoji was text. or do you mean ASCII7 text?
fantasai: There were suggestions in the issue. I think we should
pick one.
Chris: Yes, tantek emoji are text, but you can present a smiley
face as a graphic or smiley-face-emoji (or something like
that) Unicode allows both.
TabAtkins: It's a monocolor glyph or a colored glyph for this.
<dbaron> I'd suggest maybe the property name isn't being very good
at describing what this does...
Chris: Oh. That's different actually. Unicode values are text and
emoji which is weird. Shouldn't it be chromatic and
monocolor? I hadn't got from text that it's black and white.
<TabAtkins> +1
<leaverou> +1
Chris: dbaron agrees with me.
dbaron: I was thinking it was the name of the property.
Chris: It's the name of the property we're bikeshedding. There are
various suggestions.
<dbaron> not the names of the values?
<dauwhe> examples for the confused:
https://typography.guru/journal/unicode-8-emoji/
TabAtkins: I know someone suggested font-emoji. monochrome and
color seem reasonable.
<leaverou> +1 for monochrome and color. monochrome is also
consistent with the MQ value
fantasai: If you have multi-color fonts they're not monochrome.
TabAtkins: Truuuuuuuue. Are they painted like normal text or tiny
images.
Chris: It's a strange way to present it.
Chris: If we have values that are monochrome and color it seems
font-variant-emoji would be reasonable.
Chris: That's my personal pick.
<Chris> font-variant-emoji: monochrome | chromatic
fantasai: Makes sense to me.
fantasai: It's definitely better. Unless someone has a different
preference we should resolve.
<leaverou> what about symbol and graphic?
TabAtkins: Property name is an improvement.
<tantek> agreed with the change to monochrome - much more
descriptive than "text"
Chris: Support on property name, still discuss values.
Chris: leaverou suggested symbol and graphic
fantasai: I like that.
TabAtkins: I'm not sure I like symbol. Graphic or image is good
for full color.
<tantek> line-art
leaverou: Line-art and graphic?
TabAtkins: It could be fully filled pictures.
fantasai: Glyph vs graphic?
Chris: They're both glyphs.
leaverou: Rich and plain?
<dauwhe> plain and fancy :)
TabAtkins: Plain's not bad.
TabAtkins: Plain and image maybe.
TabAtkins: We have ideas. We can continue value name in the thread.
Chris: Let's resolve on property and leave values for bikeshedding.
RESOLVED: Property name is font-variant-emoji
Override (Emoji) Variation Selectors
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1144
fantasai: Some discussion about having font-variant-emoji give the
default presentation for emoji in the text. Text can
have a variation to say display as graphic or text and
that overrides the font-variant default.
fantasai: This was opened to say the author should be able to
override the text and they suggested syntax was to add
an override keyword.
fantasai: Is this a feature we want? If so, is this the syntax?
TabAtkins: I'm not seeing the use case in the github issue. We
often let specific override general here.
Chris: I agree with TabAtkins. This is a lot like changing what
the text content is which is not styling's job.
fantasai: I'm also skeptical there's a use case. One I can think
of is in the user style sheet. I would lean toward not
adding unless there's a clear use case.
TabAtkins: I'm seeing a bunch of specific use of the override
character and I want to fix that. I suspect the use of
the override is nil. That can be added in the future so
no loss on not doing it now.
Chris: Right...
Chris: I also see Crissov asking us to liaise with unicode. Does
he think they have a different solution? I can't follow the
argument.
fantasai: His original idea was it's a text transformation that
inserts the variation selector, but I don't see why we
care.
fantasai: I'm not seeing a strong use case and I think we should
close until we get an actual use case.
Chris: Suggesting close no action?
fantasai: Yeah, with that we would reconsider with an actual use
case.
fantasai: That made it worth implementation and testing time.
Chris: mmmmm.
Chris: I also see Roel asking about using this in general. Do we
have an answer for him for how to do that? It seems like a
separate sub-issue.
fantasai: Is there a reason they won't be controlled by this
property?
Chris: Yeah, they're not variation selectors to do that. At the
moment if you support color glyphs and this format you just
display in color and maybe the user wants monochrome. That
sounds more style-like.
Chris: I guess I could ask him to re-raise that as a separate
issue.
<fantasai> https://github.com/w3c/csswg-drafts/issues/1144#issuecomment-291458684
fantasai: This comment ^?
fantasai: That's a good question because is the current feature
restricted to emoji or effect all glyphs?
Chris: Right. I'm not fully up on variation selectors.
fantasai: If font-variant-emoji effects more than emoji we need a
different name.
Chris: That one is only emoji according to unicode.
ACTION ChrisL ask Roel to re-raise
https://github.com/w3c/csswg-drafts/issues/1144#issuecomment-291458684
in a separate issue
<trackbot> Created ACTION-861
Chris: Myles had agreed to this and wanted to add the override. Do
you think he'd be okay with closing it?
Chris: I see Myles removed the needs edits. I'm feeling less
comfortable about just closing. What's the sense of the
people in the room? Do we close and let Myles object?
TabAtkins: I believe so. I've read through more and the
justification of the override is really choosing the
defaults.
RESOLVED: Close issue 1144 no change
Definiteness of flex items' main size depend on flex-basis's
definiteness
============================================================
github: https://github.com/w3c/csswg-drafts/issues/1679
fantasai: The grid has a behavior where we calc size of rows and
columns which could depend on content we then do a pass
to layout the items. So if the grid item is stretch or %
it will resolve, as will any child.
fantasai: Seems like there are impl of flexbox with a similar
effect where a flex item is considered definite even
though spec says if flex-item size depends on content
the % wont' resolve. TabAtkins and I are happy to define
what impl want, but we need to know if this was
intentional or not. It does require another pass.
fantasai: Basically, we want impl to say what they want us to put
in the spec.
TabAtkins: Specifically Firefox and Edge.
gregwhitworth: I was going to ask for another week if possible.
gregwhitworth: I was going to look into our code more. Unless
Gecko has feedback now.
fantasai: Next week is good.
Chris: Sounds good gregwhitworth. ANyone from FF, can they do
input?
fantasai: dbaron CCed dholbert.
Chris: Great. We'll defer.
Baseline self-alignment may affect the intrinsic size contribution of
the alignment subject
=====================================================================
github: https://github.com/w3c/csswg-drafts/issues/1039
fantasai: This one is an issue where the handling of baseline
alignment in terms of how it effects intrinsic track
sizing wasn't well specified. I checked in changes, I'm
asking for review at this point.
<fantasai> https://drafts.csswg.org/css-grid/#algo-content with
<ins> as green text
fantasai: I just wanted to announce that. Impl should see if they
fix the issue. The changes are green text in the spec.
fantasai: Just a request for review. Hopefully resolve next week.
Chris: We'll leave the agenda+ on this one.
Chris: We have 10 minutes left. What would people like to do?
fantasai: There was a sizing issue.
Adding a 'size' shorthand for 'width'/'height'
==============================================
github: https://github.com/w3c/csswg-drafts/issues/820
fantasai: Suggestion we should have a shorthand for both width and
height.
fantasai: Obvious would to use a size property. Problem is we have
an @page size descriptor and they behave just like
properties.
Chris: It shouldn't be a problem for a descriptor and property to
have same name. We have that, right?
TabAtkins: No.
TabAtkins: You have a width and a height descriptor on @page rule.
You also have a size, but it does not behave like this
proposal.
<dauwhe> @page { size: 6in 9in }
fantasai: Options are come up with another name or deal with that
they have the same name and this might be a little awk
in some impl.
plinss: Size descriptor, does that interact with width and height?
TabAtkins: Orthogonal.
fantasai: Not really. Page size is a size in which you put the box
and width and height desc the content box.
plinss: I'm wondering if we can't redefine the size in the page
[missed]
fantasai: Size defines the margin box and width/height are content
box.
TabAtkins: And the part of the grammar exists in the size
descriptor. You can put @page { size: 6in 9in } and it
looks exactly like the size shorthand for width and
height.
<gregwhitworth> How much is @page size descriptor used? Anyone
know?
<tantek> good q gregwhitworth
<gregwhitworth> I know whatever we call this shorthand it will be
used a ton
<Chris> in print stylesheets, obvs. for paper selection I imagine
<fantasai> gregwhitworth, it's used a lot in the printing world
<fantasai> gregwhitworth, e.g. by CSS->PDF it's almost always used
<gregwhitworth> good to know fantasai
Chris: So we've talked ourselves to this won't be a conflict.
TabAtkins: No, the opposite. There will be a conflict.
Chris: Got it.
fantasai: I feel like it's probably okay. But it is a question
where impl will have different handling for parsing in
size when it's parse in for @page and that could be
tricky.
TabAtkins: It's tricky for impl and confusing for authors if they
use @page rule.
Chris: Can we come up with a different name?
<gregwhitworth> dimension?
TabAtkins: I'm kind for box property. That makes it easy to fold
box sizing into the short hand.
fantasai: I don't think you want a size property that resets box
sizing. People set box sizing and just want to leave it
and pretend that we had border-box sizing from the
beginning. If you have a shorthand that resets it it
won't be useful.
<jensimmons> +1 to what Elika just said
<tantek> fantasai's observation is correct IMO
<tantek> what fantasai said is the path of least surprise
TabAtkins: Sometimes. Sometimes they want to reset it and doing it
in one property is great. But I see your argument.
Chris: I tend to agree with fantasai.
Chris: There's 4 minutes. Any bright ideas?
Chris: Sounds like not.
Chris: Anything to talk about in 3 minutes?
<gregwhitworth> We have cx and cy
<gregwhitworth> why not wh?
<gregwhitworth> I don't like it, but...
fantasai: We definitely have authors who want this shorthand to
exist, so we should figure out something here and do it.
Chris: gregwhitworth was that serious or trolling?
gregwhitworth: I don't know.
<TabAtkins> Those names are legacy from svg, we'd never name them
that fresh
gregwhitworth: I can't think of anything besides dimension and
size that make sense.
Chris: I agree with TabAtkins. We have those because we were going
for short attribute names.
Chris: Okay. no bright ideas.
Chris: Let's leave it open.
Chris: We'll discuss on Github.
<fantasai> area?
<gregwhitworth> proportion
<fantasai> looking through http://www.thesaurus.com/browse/size
<gregwhitworth> lol, same here fantasai
Received on Thursday, 17 August 2017 00:59:50 UTC