- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 11 Dec 2019 20:07:33 -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.
=========================================
CSS Fonts
---------
- TabAtkins will review issue #4497 (Limit local fonts to those
selected by users in browser settings (or other browser chrome))
with the security team before giving feedback
CSS Values 4
------------
- There is a commit for Issue #4482 (Switch advanced attr() to being
var()-like) which needs review. Assuming no major changes are
requested a resolution will be requested next week. Commit:
https://github.com/w3c/csswg-drafts/commit/ed7beac806cc4753d8134857ff526150bb2a631c
Media Queries
-------------
- The on call agreement for issue #4535 (color-gamut Keywords) is
align the color function keywords with preexisting color gamut
keywords however there weren't the right people on the call to
resolve on that proposal conclusively.
CSS Sizing
----------
- In issue #4531 (intrinsic-size lost the thread) the proposal is to
return to just having a property to set a size for an ]
async-layout element when we're not actually calculating the
content's size and omit the extra use cases discovered during
the F2F since this use cases added significant complexity, made
the original use case harder, and were achievable using other
methods.
- After discussion there were two possible paths forward 1)
rename the property and only solve the limited use case. 2)
leave the property broad knowing that there will be
additional use cases to solve in the future within a similar
problem space.
- Additional use cases will be gathered in issue #4585 (Use
cases for explicit intrinsic-size) until the January meeting
at which point the group will decide between the two
possible approaches.
CSS Pages 3
-----------
- Issue #4491 (Add orientation descriptor) needs visual examples
before the group can decide on the use case. It was generally
agreed that four directions will be necessary rather then just
portrait/landscape
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Dec/0012.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Christian Biesinger
Oriol Brufau
Dave Cramer
Elika Etemad
Simon Fraser
Chris Harrelson
Dael Jackson
Sanket Joshi
Brian Kardell
Myles Maxfield
Anton Prowse
Manuel Rego Casasnovas
Florian Rivoal
Devin Rousso
Jen Simmons
Regrets:
Rafal Bartoszek
Daniel Holbert
Scribe: dael
Rossen: Any additional items or changes?
florian: I suggest adding celebration of Writing Modes L3
* astearns \o/
<fremy> yay! celebration!
Rossen: I second that
<myles> 🎉🎉🎉
<rego> 🎉
Rossen: Certainly a celebration is warranted and deserved.
Congratulations to everyone who participated and everyone
who endured all the conversations. It's a really great result
<dauwhe> !yarooh
Rossen: Congratulations
[Searching for the right people for agenda topics]
CSS Fonts
=========
Limit local fonts to those selected by users in browser settings (or
other browser chrome)
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4497
myles: I can't take this
myles: Not sure I understand the proposal
Rossen: And Chris is not on.
florian: I think TabAtkins will want to push back so we should wait
for him
TabAtkins: I am on now
TabAtkins: For this topic, no comment right now. I didn't see it
earlier. I'll talk to our security people and see what
our opinion is.
Rossen: That's on Fonts?
florian: The comment is consistent with Fonts
CSS Values 4
============
Switch advanced attr() to being var()-like
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4482
TabAtkins: I finished the edits to re-write and they're in Values 4
ED. I put attr() in its own section. mostly cribbed from
var spec. I have a note to re-write substitution
algorithm.
<AmeliaBR> commit for changes:
https://github.com/w3c/csswg-drafts/commit/ed7beac806cc4753d8134857ff526150bb2a631c
TabAtkins: Otherwise it works similar to old. You give a type,
checks if the attribute exists, and substitutes in if it
does. Assume valid at parse time. If it fails when you
put it in it's invalid at computed value time.
TabAtkins: Our implementor thinks it's reasonable. If anyone else
wants to look it would be great.
TabAtkins: Only possible controversy is spec what type the value is,
doing parsing on it. If you say 'color' it's recognized
as a 'color'. Want to keep because attributes are a
messier channel. Easier to mess with, scripts sometimes
write them. Ensuring a valid thing comes out and then
switch to default seems valuable here.
TabAtkins: I'm happy with current. Any further comments or strong
opinions please give them here or in issue.
TabAtkins: I'll ask for resolution to approve next week.
Rossen: Thanks.
Rossen: Action on everyone who cares about these changes to review
so we can discuss on next call.
<florian> +1 to the design goals. Will review details
Media Queries
=============
color-gamut Keywords
--------------------
github: https://github.com/w3c/csswg-drafts/issues/4535
TabAtkins: Is chris on?
Rossen: I think he is
[silence]
florian: I think he said since they mean different it's okay that
they are different
TabAtkins: I want to ask follow up questions. I think it's bad that
they're slightly different and spelled differently. I
want to discuss with him on.
Rossen: fwiw I agree with you on principle to either merge or break
far apart
fantasai: I think chris is saying- there's 2 things to consider. One
is this is shipping in impl. Other is these are not
keywords that hook into those color profiles. They hook
into color profile that's similar to the named profile.
There's a concern if we rename to match the color profile
keywords people will expect to match that profile exactly.
<fantasai> https://drafts.csswg.org/mediaqueries/#color-gamut
fantasai: The definition is much more handwavy
florian: I don't think spelling is enough.
TabAtkins: Original intent is they were intended to be the same.
That they diverged now seems after the fact reasoning.
Shouldn't play into if it's good.
florian: Is other shipping?
TabAtkins: No
AmeliaBR: We can rename it but can't change to be equal value
florian: Meaning can't change. Property is intentionally specific.
TabAtkins: Maybe
florian: If divergence is accidental then solution seems easy
TabAtkins: We'd need to remove the dash from ref-2020 which makes it
less consistent, but it's not a huge deal since the - is
just between word and number. Just realign the color
keywords.
AmeliaBR: Concern is using the keywords for meanings and when people
are using color profile as color values would they expect
to use the MQs to test specifically what profile is
supported.
florian: Keywords have same meaning, MQ has different. MQ is if the
gamut is roughly similar
TabAtkins: Reasonable to conclude if gamut is P3 you should be able
to use the full range and have it work. Might have some
clipping at the ends
AmeliaBR: Sounds like call preference is to revert some of the
changes to keywords in color profiles so they match color
gamut MQ keywords
AmeliaBR: That might be pending objections from chris
florian: Put in GH and sit on it for a week
TabAtkins: Yep
Rossen: Let's not resolve now we can take it next week.
Rossen: Proposed resolution is align the color function keywords
with preexisting color gamut keywords
CSS Sizing
==========
intrinsic-size lost the thread :(
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4531
TabAtkins: At TPAC I introduced intrinsic-size proposal. During
discussion realized this sounded more generalizable to
override intrinsic size. Upon further review it means
display locking case is much harder to use because have
to control if intrinsic-size is applied or not
TabAtkins: If the thing has been rendered you don't want to override
anymore. You want to override the contain:size that comes
from async and remove contain state.
TabAtkins: Proposal is we go back to the older idea. We give a non-0
default size. Other use cases at TPAC around bad
intrinsic size for scrollers and virtual scrollbars this
wouldn't block them from being addressed separately
TabAtkins: What we agreed at TPAC makes async much more complex for
the author. The cases piled on top for a more general
intrinsic size aren't worth the increase in complexity
TabAtkins: Want to revert to it changing way contain:size works
fantasai: Questions: display locking there's a magic state no
reflected in attributes and in some there's contain:size
or in all?
TabAtkins: In some of the states
fantasai: And contain:size has to be removed by author?
TabAtkins: Done automatically
fantasai: If there's an intrinsic size the UA doesn't know to remove
or not
TabAtkins: Yes, exactly
fantasai: Okay, I think I understand what's happening
fantasai: I'm a little uncomfortable with this being separate
because it does fundamentally same. One is to explicitly
say always and one is for sometimes. I'm a little
uncomfortable with them being distinct features that don't
relate to each other
fantasai: Not sure I'm happy with a separate property. Seems similar
case to aspect ratio where we have use case for explicit
which are always in effect and then ones that are only
until image is loaded. There's a state dependency.
fantasai: We have this idea where those concepts are in the same
property. I think that my preference is we keep it as
intrinsic-size property and add a keyword for if it takes
effect or if it's auto
fremy: That's what I was going to suggest. Say if this is all the
time or only sometimes
TabAtkins: My objection is outside of this display locking we hadn't
IDed any use cases that needed an explicit size. We can
use this to make it say 0 but it doesn't need full power
of a size. Other nice thing is make an element always
have scrollbars is a nice to have. There's reasonable use
cases for this. It's nice, but not very important and I
don't want to complexify
TabAtkins: One happy accident with intrinsic-size is when people are
doing virtual scrollers you want scrollbar to look the
right height. Right now people put a tall invisible
element. If we use intrinsic-size argued it could spec
the same thing. This element is 10000px intrinsic so you
get a large scrollbar
fantasai: Gotcha
TabAtkins: florian disagreed if that should mechanically happen,
though
fantasai: I think dbaron has brought up case of setting intrinsic
size more explicitly, but I don't remember them
dbaron: I don't either
chrishtr: As part of TAG review they pointed out it's not clear what
layout modes intrinsic-sizing would make more powerful in
ways that matter. Unless it's a way to provide
placeholders for things you want to have detached
layout for
chrishtr: I second TabAtkins not being sure there are more use cases
for this general property. The scrollbar and flexbox
algorithm we can fix more explicitly
TabAtkins: Flexbox algorithm use case is scrollers get too big
TabAtkins: We can rename the property to be more explicitly about
what it does. That would make it clearer if we need
intrinsic-size explicit override
AmeliaBR: I'd argue for that even if we don't expect a general
intrinsic-size. Let's make a name that's containment size
or something that's clear
<dbaron> +1 to having a more specific name if it has a more specific
behavior
<fantasai> +1
Rossen: Agree. Intrinsic-size as a concept is something explicit.
Rossen: Other than the name is this still a property we want to
pursue
<fantasai> Would suggest 'contain-size', sharing a prefix with
'contain' and suffix with '-size' property
florian: Should spend more time re-thinking. This is an interesting
point. If no strong use case for the general TabAtkins
proposal makes sense. If we will go there eventually
fantasai proposal makes sense. Should see if we remember
use cases
<fantasai> +1 to florian
fremy: I recalled mine but thinking more they were all better with
custom layouts
fremy: I feel like my use cases could be solved with custom layout.
It's a better solution. Originally custom layout wasn't
there. But now that it is I can't think of one that would be
better without the custom layout
* fantasai would be interested in the specific examples
chrishtr: If we have more use cases and a general property we would
still need a property to switch
florian: Yes, we want a single property with mode switch if there
are other cases. If not special property
<dbaron> (to apply only when `contain:size` is present)
chrishtr: I hope we start with that part
fantasai: I agree with florian's description of where we are
TabAtkins: Can we timebox it?
TabAtkins: Sooner is better, we're trying to finish in our impl.
It's not must right now, but sooner
fantasai: Timebox of next week or first week of Jan?
TabAtkins: If dbaron had use cases before a week should be enough to
remember. Presumably we've discussed in the past.
florian: Difference between next week and early Jan isn't much
unless you're trying to ship before Xmas
fremy: And have to keep in mind people are in vacation
dbaron: I wanted to say about use cases is the things I remember use
cases for are 2 things. One is to override the behavior
where overflow !=0 causes min-intrinsic to be 0. And the
others were setting intrinsic size to be 0; don't remember
if it's min or max size
AmeliaBR: Sounds like people might want to skim previous issues.
Initial proposal had many variations, such as whether this
applied as a minimum or maximum or both. Different use
cases had different situations
<AmeliaBR> Previous discussion where many possible use cases were
brought up:
https://github.com/w3c/csswg-drafts/issues/4229#issuecomment-531615054
TabAtkins: Also intrigued that both of dbaron's use cases are 0 or
not, not about setting a non-0 value
fantasai: Objects which don't have intrinsic size and we default to
300x150 and this could allow a more usable size. Most
could be handled by setting a size.
iank: Use case to set to 0 is if something is shrink to fit and
available size is smaller then the minimum size and you've got
overflow:scroll That float will never be able to shrink to the
available size.
<iank> e.g. https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=7541
florian: Another use case is to set the min intrinsic size is larger
than natural layout. We have number of layout modes that
use min-size to do things but math conclusion of min-size
may be too tight. You want things to work from a slightly
larger min. An element with a multicol and min-size goes to
shortest word but you know you don't want less than 2 col
florian: This isn't clearly articulated; I'd appreciate more than
a week
chrishtr: Let's wait until 1st week in Jan to write use cases and
decide then
fantasai: Start a new thread on use cases rather than follow up on
this issue?
chrishtr: Sure. I'll make a new issue and link to it from the
existing
Rossen: I think that's all we can say on this issue. chrishtr thanks
for making the new issue. We'll take this back in beginning
of Jan
<fantasai> Issue for use cases at
https://github.com/w3c/csswg-drafts/issues/4585
CSS Pages 3
===========
Add orientation descriptor
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/4491
chrishtr: Way to rotate page without changing layout. Different
rotation in PDF is the use case. Intended is to set rotate
descriptor in PDF.
florian: Wouldn't do anything if print to actual paper?
chrishtr: Right
florian: Sure
<fremy> sounds useful
TabAtkins: Reasonable to me. Not sure if it's better to do explicit
direction keywords or portrait. Happy to advance
florian: Suspect picking direction is useful
chrishtr: I can imagine left or right depending on visual preference
florian: If you're not controlling...no, I guess MQ. If you don't
decide if the whole should be portrait or landscape you can
use MQ to decide a section
fantasai: I don't think portrait vs landscape is sufficient because
you might want to rotate +90 or -90. You want to rotate
entire page
dbaron: This would be clearer with examples as to what is and isn't
rotated
florian: No effect to layout, just set a flag in PDF
dbaron: Not just that. Could use examples saying this pair of size
and orientation should look like this. In terms of what PDF
looks like vs page and content orientation
chrishtr: I can add example
AmeliaBR: Would be helpful. I think...visually for me is a PDF
mostly portrait and we want to display a page in landscape
or is it that page is layout in landscape but display as
portrait. Which cases?
fantasai: Thing that is relevant here is relationship of content to
page box. Headers and footers to page box. Orientation of
page box itself.
fantasai: I can interpret this in 2 ways. Only changes orientation
of page, but header is still at top or it layouts entire
content including header and then rotates. I'm not sure
about it.
florian: Some sections in landscape can handle with page sizing.
Don't need something to change aspect ratio of some pages
AmeliaBR: But having headers match other pages is the missing
<fantasai> The landscape keyword on size doesn't affect orientation
<fantasai> it's a shortcut for sizing
florian: I thought it was print normally, then physically rotate the
3rd piece of paper. Examples would help
chrishtr: That's what I intended. Hand't thought detail on
header/footer
Rossen: Intended for anything outside page. Could this be used in
regular HTML? Thinking of ePub where people might want
similar control. Why is this PDF specific?
<fantasai> Not PDF-specific, but @page specific
Rossen: Kinda goes back to lack of examples. What is this intended
to solve? I clearly hear PDF. I don't believe we want per
page control. In summary it goes back to getting clearer
examples in proposal
fantasai: I want to clarify landscape keyword on size is just a
shortcut to say I want 11x8.5 instead of 8.5x11. Please
don't confuse orientation with that keyword.
fantasai: Second point, I think we want it to apply to more than
PDFs. Proposal is descriptor on @page rule which talks
about page box for paged media.
florian: I think it applies to most but not all paged media. Doesn't
apply to paper because if you're printing to paper how you
position the pages is out of our control. But if you're in
a PDF that's different because renderer can decide how to
layout pages.
fantasai: In terms of some pages oriented one way vs another we have
a feature that allows us to assign content to different
types of pages. This section is on legal where rest is on
letter. An orientation descriptor lets you do something
similar where this chapter is landscape. That falls from
existing functionality
TabAtkins: It is applicable to paper. Controlling which direction
the landscape graph is in a paper book is worthwhile.
Printer will auto rotate but if you have it oriented you
stick with that.
florian: I was thinking of home printer, but yes if you're binding
that makes sense
myles: You guys said much of what I would say. We have a size
descriptor already. If goal is to let your big table be
printing on landscape you can do that. Only value is what
TabAtkins said where for printed context it tells the printer
what to do. For PDF it's no effect because you can do the use
case. Only way this makes sense if if it's no effect on PDFs
TabAtkins: Makes sense for PDF. If layout in landscape but want to
display PDF as portrait you can do that
AmeliaBR: Overrides the default PDF view where if it's landscape it
displays landscape. Forces to show in the printed book
fashion
myles: Why would anyone want that?
TabAtkins: DnD books for example that have a wide table. Page is
pointed vertically. Want to have PDF match look of book
is reasonable
myles: Don't have have to turn your computer to read it?
TabAtkins: Sure
<bkardell> sees pdfs with this quality today (myles point)
AmeliaBR: Other case of content in landscape but headers in portrait
you can do with writing mode
florian: Can't do by page can you?
AmeliaBR: You can say this section has vertical writing mode and
that effects content
TabAtkins: As we come to end of hour, seems like some disagreements
about when applicable. Seems reasonable to do. Open
question as to if it changes header position. Good to
look at use cases to see which the use cases prefer. If
it's mixed we can look at a switch
florian: So if page margin boxes are orthogonal to content
fantasai: Yes
florian: Can't you do that with writing modes?
fantasai: Yes
Rossen: chrishtr will you add the use cases? Or TabAtkins?
TabAtkins: I volunteer chrishtr as tribute
fantasai: It's not just page margin boxes this effects Question is
do we disassociate content from the concept of top/bottom/
left/right from the page's concept or are we rotating the
whole page? Does that page's concept of top/bottom/left/
right match the content's
TabAtkins: Don't think can lay out a top margin box that would
layout as a tall skinny thing. Need to know if layout
into tall skinny or squat wide.
fantasai: Separate thing
florian: My understanding is it rotates the whole page. And then use
writing modes etc to make changes
fantasai: Probably easiest
<fantasai> I think also we agree that 'orientation' should take 4
orientations, not just landscape/portrait
<fantasai> and probably should use syntax consistent with
'image-orientation' even though it's awkward
Rossen: We're at the hour please add thoughts to the issue.
Rossen: We've got 2 issues left that we'll start with next week
Rossen: We'll chat next week
Received on Thursday, 12 December 2019 01:08:15 UTC