- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 25 May 2016 20:04:29 -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.
=========================================
Report on vertical writing award website
----------------------------------------
- skk presented his report on the vertical writing award website.
The slides are available here:
http://mari.bpsinc.jp/~skk/20160510_award_report.pdf
Testing
-------
- RESOLVED: All tests are added to csswg-test via GitHub PR, if
implementation already reviewed push directly.
- gregwhitworth will write some basic contributer documentation.
- RESOLVED: All new issues for test should be on GitHub
- gsnedders will develop a syntax for shepherd to be able to get
the issues and an automatic tagging procedure and plinss will
develop a way to get the GitHub test data into Shepard.
- RESOLVED: Move issue-filing to GitHub in the following steps:
1) Set up mailing to receive GitHub issue
notifications for archiving
2) Switch to using GitHub for issue tracking
3) Notify www-style
4) Copy over issues filed against www-style to GitHub
and reply with link. (for new issues filed after
transition)
5) Update specs to say that issue are filed against
GitHub
- Any issues filed to the mailing list after this resolution
is implemented will receive an answer from a spec author
informing the individual of the new process and porting
the issue over to GitHub.
- RESOLVED: Remove test-building aspect of build system, just
build manifests.
Sizing
------
- RESOLVED: Create a new fit-content function in Sizing Level 3
and Grid
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/san-francisco-2016#proposed-agenda-topics
Report on vertical writing award website
========================================
[skk's slides: http://mari.bpsinc.jp/~skk/20160510_award_report.pdf]
[Notes from skk's presentation:
Kanji are often rendered at a larger font size than kana
Link underlining is not working interoperably in vertical text]
Scribe: fantasai
fantasai: That's specified in text-decoration.
dbaron: It's also possible to control it.
fantasai: The spec has UA style sheet rules.
<gregwhitworth>
https://drafts.csswg.org/css-text-decor/#propdef-text-underline-position
dbaron: I think technically we implemented as an initial value,
but that's hard to detect as different from the spec.
<dbaron> or maybe we implemented the initial value of the property
but didn't implement the property?
skk: We have grid sheets for writing, to keep characters on the
grid.
skk: When we use ruby we cannot put each character inside the grid
box
skk: In this example here, each character is inside its grid box
skk: This is a very discussion-able point, but governmental
document, they use character grid
skk: That document grid does not use ...
Florian: Japanese does not breaks at spaces, it breaks anywhere
except before comma, before period, etc.
Florian: Government documents break anywhere, no exceptions.
Florian: Not a small corpus, government writes a lot...
Florian: Because it looks like ancient Chinese, looks formal.
fantasai: Doesn't word-wrap: wrap-word do that?
fantasai: I hate the names of these properties. Wish I had tried
harder to rename them...
<zcorpan> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4187
(test for underline with vertical japanese text)
Florian: It's interesting that there were no good designs submitted.
Florian: There was a lot of time between the Web and Web that
looks good, so seems like we have something similar here.
Florian: Maybe takes awhile before we have design that looks good.
Testing
=======
Scribe: gregwhitworth
Where to add tests
------------------
gsnedders: I had a list of what we needed to do:
<gsnedders> discuss for testing? when-does-review-happen, do-we-
move-to-git-only, do-we-move-issue-tracking-to-GitHub
astearns: Whatever we resolve on we should use the table spec as
guinea pig (cc franremy)
gsnedders: Should have everything go in/out of git or mirroring
with mercurial?
gsnedders: There are constraints on mercurial that aren't on git,
etc.
gsnedders: like branches on the root.
plinss: That's a policy only.
plinss: The bridging handles branches just fine.
gsnedders: It feels repetitive, we should just standardize on one
and if we're trying to move to WPT.
Florian: Maybe we should have a one-way mirror.
TabAtkins: Yes please. No one rebases in mercurial.
fantasai: A lot of people do.
shans: Can we relax the policy?
plinss: It's not my decision, but yes we can - but there was
consensus a long time ago because it's confusing.
shans: I've contributed to a ton of GitHub projects and the
branches are not confusion.
dbaron: Branches cause confusion, people have committed on the
wrong branch.
plinss: It's a policy about how it's used, I don't care one way or
the other.
shans: If we only do PRs on branches.
plinss: That's what we do already.
gsnedders: Do we have a two way mirror between mercurial and git?
gsnedders: It makes it confusing on review because git gets
reviewed before PR and on mercurial does not.
Florian: People who use mercurial use shepherd for review.
shans: Yes that does sound like an issue.
shans: Ignoring which control system is used it makes sense to
have the review done before the merge.
astearns: We had this discussion and it was leaning towards moving
to WPT.
dbaron: I'm fine with that if the browser vendors can push with
the review like in WPT.
astearns: Yes, the goal of this is to ultimately merge into WPT.
Florian: Do we currently have the capability to push via mercurial
via a different branch?
plinss: There is nothing in the tool stopping you, but there is a
policy and we could make it happen.
plinss: There is no tooling that is going to say oh this branch is
a PR, etc
plinss: but if we're moving to GitHub let's not re-invent the wheel.
Florian: Given the current state then should we stop pushing to
mercurial.
plinss: Sure.
plinss: My only issue is that there are people that push tests
that use mercurial and don't want to use git--we run the
risk of loosing their contribution.
Florian: The main problem here is that we lose the shepherd
cycle, and that's what we no longer want.
Florian: We could build another tool.
plinss: The mirroring that does the work in mercurial can point to
anything and that adds another level of complexity.
gsnedders: Yeah, we should be trying to remove complexity.
Florian: This is an explicit question.
Florian: It will upset some people and given their contributions...
Florian: I don't know.
plinss: Maybe we can teach them and maintain the workflow
Florian: The problem is that they don't want to just use mercurial
but also shepherd with mercurial.
gsnedders: Anyone else have an issue with git?
<silence>
Florian: If we make the change we should take them into account.
ChrisL: But part of the problem is we want more people doing it
and if switching to git gets us that.
fantasai: My only concern is that GitHub makes it harder to review
the tests.
fantasai: And while it may be annoying, if we provide clear steps
on how to use it and map them to mercurial then it can
make it easier to get started.
fantasai: We don't do very complicated commands here.
ChrisL: It was asserted that it was harder in git than shepherd,
but I disagree because right now they live in two
different areas and no one knows really where to look for
the tests.
ChrisL: This makes things particularly hard.
gsnedders: As I said yesterday, we can do mirroring and provide a
link on PR to view them live.
ChrisL: We have contributions from years ago.
fantasai: There are comments has 2.1 comments from years ago on
Microsoft tests, but no email is sent, etc.
dbaron: Then the changes go back into shepherd and can't be
reviewed again or searched.
fantasai: plinss can you please make it that there is no automatic
conversion from "needs review" to "needs work"?
dbaron: I'm asking to limit that change to only ones that are
manually switched to "needs work".
dbaron: I've submitted ~300 tests like this where it was flagged
as incorrect because of formatting problems that I then
fixed by just pushing a fix; these should stay as
resubmitted for review.
plinss: There is a preference in shepherd to allow them to auto
resubmit.
plinss: This is all irrelevant though if we're moving to git.
rbyers: Going back to it being hard on reviewing the changes
online, you can use rawgit.
gsnedders: Some of them may not be able to do that due to
.htaccess files.
Florian: Does rawgit deal with relative urls?
rbyers: Yes.
plinss: Even images in another dir?
rbyers: Yes.
<fantasai> ACTION plinss Flip auto-resubmitted tests back to Needs
Work if Needs Work was not auto-flagged
<trackbot> Created ACTION-771
rbyers: Any tests that you can't run statically then we should put
in another folder.
rbyers: The static ones are easier to run in browser and in impl
test suites.
gsnedders: Anyone going to object to us resolving to test
submission solely to GitHub?
RESOLVED: All tests are added to csswg-test via GitHub PR, if
implementation already reviewed push directly.
<fantasai> https://wiki.csswg.org/tools/hg
fantasai: gregwhitworth can you please convert our tools mercurial
page to git
fantasai: basically we should have a contrib in README.md
fantasai: And also create a page that explains how to pull down a
PR locally, review, possibly edit, and merge into master.
ACTION: gregwhitworth to write basic contribution guidelines
<trackbot> Created ACTION-772
Location of test issues
-----------------------
gsnedders: Issues about tests, should they be GitHub issues.
Florian: Other issue is the tests on the mailing list.
gsnedders: Currently we have issues in three different areas.
Florian: Issues in shepherd are they issues on tests that we've
approved already.
plinss: Sure.
ChrisL: It can happen for a number of reasons.
Florian: Interesting, didn't know people did that.
gsnedders: I would assume it's ok...
plinss: Define what you're asking then, are you asking for new
issues or moving all shepherd issues to GitHub?
gsnedders: I would prefer that but that's a lot.
plinss: yeah.
fantasai: Is there a way to create a map of all of the issues for
a given test from GitHub?
Florian: Not really.
dbaron: I do use the shepherd issue searching stuff and that is
useful.
fantasai: That is the primary reason we built shepherd.
dbaron: If we have the GitHub issues it'll be like the mailing list.
<TabAtkins> GitHub issues are a support forum
Florian: Most people don't find mail issues.
gsnedders: Also on mail you have no context of close issues.
gsnedders: I'll note we have under 200 tests open on WPT.
<tantek> on email, all issues are always open
dbaron: I can't filter for our recent mozilla tests.
Florian: I think external contributors can't tag things.
fantasai: Yeah that doesn't scale much unless it's just the vendors.
rbyers: The tagging issue with external contributors is a common
complaint.
fantasai: Shepherd has its weaknesses but being able to search for
all of the issues of their tests is very helpful.
dbaron: The big issue with shepherd is that no emails are sent.
Florian: They're slightly related, without knowing the issues are
there you can see them and find them and issues don't
pile up.
fantasai: Can we just fix shepherd, how hard is that?
plinss: It's not too hard.
dbaron: My first thought is to file all new issues in GitHub and
see how it goes.
plinss: Getting all issues into GitHub is not something I'm
signing up for today.
plinss: Nothing we've discussed today kills off shepherd.
plinss: Always on the roadmap is to integrate GitHub issues with
shepherd issues.
fantasai: How do you key that?
fantasai: If there was a field that allowed you to have a test id
you could map them.
fantasai: One thing with shepherd is you can't see one issue that
addresses 50~n tests.
fantasai: If you have a problem in a test you have that same
problem for lots of tests, that is one of the great
weaknesses of shepherd, that you can't file a single
issue against a bunch of tests.
fantasai: If we can figure out a way to map the issues with the
tests then that only improves GitHub.
ChrisL: If shepherd is just a filter on the GitHub info then that
only improves it.
gsnedders: My only other issue is that shepherd is just another
bug tracking system, and they're complex.
ChrisL: That isn't a barrier though because they can file the
issue on GitHub.
fantasai: I would like for us to find a way to get the issues into
shepherd so that they're searchable.
Florian: The labels and tags can help.
gsnedders: WPT adds the tags automatically based on dir.
fantasai: Because we will have a billion tags if it's one-tag-per-
test.
fantasai: Maybe if you put in some comment block in the issue.
Florian: Can you machine read comments?
gsnedders: Yeah, use the API.
fantasai: Perfect, that would allow Shepherd to track that to
search issues by test.
gsnedders: If a code block contains a bunch of paths then it
refers to those files, most issues already do that.
gsnedders: More specific we make that the less likely it is to be
picked up by the system.
RESOLVED: All new issues for test should be on GitHub
ACTION gsnedders: come up with a syntax for shepherd to be able to
get the issues
<trackbot> Created ACTION-773
ACTION gsnedders: get the automatic tagging setup - figure it out
<trackbot> Created ACTION-774
ACTION plinss: get the GitHub issues reflected in Shepherd
<trackbot> Created ACTION-775
<gsnedders> did we resolve on dropping the build system once the
test harness no longer relies on it?
<gsnedders> I think not, should we discuss that later?
Issues on the specs
-------------------
ChrisL: It's up to everyone on what to do.
ChrisL: I would like to suggest moving those issues to GitHub.
ChrisL: Labeling, tagging, etc.
ChrisL: I was skeptical at first at web audio WG and it turned out
I was wrong.
Florian: I partly disagree with the problem statement, they are
not filed everywhere.
Florian: They are filed in the ML, and tracked various places.
dbaron: I think having issues in the spec is very good.
ChrisL: I'm not saying remove them from inline, but the thread
should be in GitHub.
dbaron: I think forcing the editor to file a GitHub issue and I'm
going to write them down, I don't think we should file
GitHub issues for that.
dbaron: I think it's ok to have an issue only in the spec.
ChrisL: I think once there is a discussion, that discussion should
be on GitHub.
Scribe: fantasai
Florian: So, does filing issue in GitHub mean we move technical
discussion out of the ML into GitHub, or no?
ChrisL: That's not what I was saying.
dbaron: I would like to do that.
gregwhitworth: I think the best benefit of discussions on GitHub
is that the thread ends, there's a close button.
gregwhitworth: Can't say how many times on an ML thread, the
closed discussion is reopened by someone making
more comments.
gregwhitworth: You know that the discussion is closed.
gregwhitworth: You can directly correlate a push to a closed issue.
gregwhitworth: People can continue to comment, but the issue is
closed.
gregwhitworth: Additionally, Disposition of Comments becomes easy
once the issues are tagged.
gregwhitworth: Makes the process a lot easier.
TabAtkins: While on this topic, bikeshed does have support for
easily inlining GitHub issue;
TabAtkins: you do ISSUE(num):
TabAtkins: Grabs contents of the first comment, and links back to
GitHub for you.
ChrisL: I wanted to add on something wrt what Greg said.
ChrisL: DoC is definitely better on GitHub
<tantek> +1
fantasai: You were so adamant about having multiple statuses per
DoC issue, and that's impossible on GitHub, what gives.
ChrisL: I changed my mind.
<tantek> besides, we can use labels for multiple statuses per DoC
issue on GitHub
ChrisL: It's possible to prove on GitHub that the person who
commented was CCd on the resolution.
<tantek> (and impossible on the mailing list)
<tantek> yes! another convert!
Florian: If all issues are filed on GitHub, then only can talk to
people on GitHub. How do you CC somebody who's not on
GitHub?
ChrisL: You can send them a link.
ChrisL: Transcribe their comment into GitHub issue.
Florian: GitHub is much better at tracking whether or not
something was closed.
Florian: Doesn't make it better to track whether someone has been
informed and whether or not they agree.
TabAtkins: The benefit of GitHub here is that when you do that
nice, give me date range of these issues.
TabAtkins: I can drop labels on everything, easily see it and
track it.
TabAtkins: Anything is going to be easier than our manual
text-based tracking.
ChrisL: Yes. Especially if director wants to figure out why thread
is not in the DoC.
ChrisL: Etc. So annoying.
tantek: So we're done with that?
TabAtkins: Lets be done with that.
gregwhitworth: Is there some kind of W3C archiving requirement?
How would we manage that requirement?
ChrisL: *waves hand handwavily*
fantasai: Should we pipe all of the comments to a read-only
mailing list?
ChrisL: Gives you the raw data. Not very usable form, but it's
there.
ChrisL: We'd be screwed if GitHub shuts down, it is an issue.
TabAtkins: We can do that part today.
TabAtkins: Just need to create a new ML.
Florian: Yes, everything that happens on Git should be sent
somewhere, a subscribe-able place.
fantasai: One of my main issues with switching systems is being
able to work offline.
Florian: You can respond by mail, just can't open new issues.
Florian: Ability to file issues offline would be curtailed...
everything else seems to be doable.
Rossen: Trying to summarize...
Rossen: Hearing a lot of sympathy for moving to GitHub
Rossen: And one drawback is being able to open issues offline.
fantasai: Opening issues is less important to me than being able
to respond offline.
fantasai: But, does GitHub have References headers?
fantasai: Or does it just send email without any actual threading.
Rossen: Only thing we can't do is open issues offline.
tantek: There's just one thread...
Florian: I think fantasai was asking about threaded trees.
dbaron: fantasai was asking about whether it threads in her mail
client.
dbaron: There's no tree-threading. But GitHub issues should be
simpler discussions.
dbaron: I think having the threading tree encourages people to
make the conversation large.
shane: It's really easy to link to other issues, so if you notice
that something is actually another issue then you can split
it off and track it separately.
tantek: I've seen in groups that switch from email to GitHub
issues, there is an adaptation period where some number of
people will create a single GitHub issue as if they're
writing an essay about all their concerns.
Florian: Bad behavior in email too.
tantek: In that case, you need to not respond, just say "we are
going to split this issue into multiple issues".
plinss: Close the whole thing, open new individual issues.
shane: And link to all of the new sub-issues, it becomes a landing
page.
<liam> [ we had the same behaviour in XQuery when we switched from
email to bugzilla (10 years ago or so) and took the same
approach with new issues, when we could ]
Rossen: So, what should we do?
Florian: What's the scope of the ML if not technical discussions?
Rossen: Can discuss purpose of ML separately.
fantasai: I'm okay with not being able to file new issues, if
necessary.
fantasai: I will be very unhappy if GitHub doesn't use References
headers for proper threading.
<liam> checks his GitHub mail and sees References headers
Rossen: So should we resolve?
hober: Probably want to let the ML people know
Florian: Will the current ML receive the GitHub notifications?
Florian: [Transitioning current www-style readers to GitHub]
fantasai: I would like to make switching to GitHub contingent on
having the receiving ML set up correctly.
Florian: Include in this resolution, then what do we do with
people who file issues against www-style?
?: Redirect them to GitHub
fantasai: I think as a courtesy, at least at the beginning, we
should copy the issue over to gitHub for them, and reply
with a link saying "discussion will continue over here"
[general agreement]
Proposal:
1) Set up mailing to receive GitHub issue notifications for
archiving
2) Switch to using GitHub for issue tracking
3) Notify www-style
4) Copy over issues filed against www-style to GitHub and reply
with link. (for new issues filed after transition)
5) Update specs to say that issue are filed against GitHub
ChrisL: A discussion we've not had yet, is do you have one big
repo or separate repos?
TabAtkins: That's a separate discussion.
tantek: Is there a time limit on the hand-holding?
TabAtkins: Don't see any reason to stop.
hober: Can be up to the editor.
Florian: As an inclusive community, our response to an
incorrectly-filed issue shouldn't be "You did it wrong,
go do it again over there" it should be "We're tracking
issues over here, I moved this one for you, please
continue over there."
RESOLVED: Move issue-filing to GitHub as described above.
Purpose of www-style
--------------------
Florian: What's still okay for www-style?
fantasai: Minutes, agendas...
TabAtkins: General interest announcements and publication
announcements, etc.
Florian: Discussions of should we have a spec for that?
shane: As soon as there's anything more than hell no, or maybe
that's reasonable, move to GitHub?
dbaron: Sometimes even big issues are appropriate on the ML.
dbaron: E.g. changing something that really everyone ought to know
about.
dbaron: Worth mailing ML to let people know.
fantasai: Tab and I sometimes send a summary of "this is stuff we
did, and these are open issues we have to discuss", that
can stay on www-style.
TabAtkins: Can go back to most people here mostly reading www-style.
TabAtkins: Instead of mostly just me and fantasai reading most of
www-style.
TabAtkins: With luck, most of the rest of the ML will be lower
volume, higher value, be notified about things.
TabAtkins: If we start getting noisy, doing things wrong.
TabAtkins: e.g. random implementer watching the list wouldn't
care, probably doesn't go on the list.
<tantek> telcon agendas?
<tantek> TabAtkins would you consider support requests noisy?
http://25.media.tumblr.com/tumblr_m7otxiGuoH1rvsbh9o1_500.jpg
<TabAtkins> tantek: www-style is not intended for support
requests, so yes, they're 100% noise
Rossen: Anything else?
ChrisL: Nope, exactly what I wanted to achieve.
Dropping the build system
-------------------------
gsnedders: Dropping build system?
plinss: Test harness requires the manifests.
gsnedders: Build a manifest from unbuilt tests.
plinss: Building manifest without building, sure.
plinss: Probably also index files, cuz why not.
gsnedders: Affects things like requirement like tests in a given
test suite having unique filename.
plinss: We actually have unique filename requirement across entire
repo.
gsnedders: We've had people contributing tests to the repo getting
that wrong.
plinss: We can drop that requirement independently
gsnedders: Can we? If we're copying files around, depends on that
rule being true.
Florian: Can we consider build system as part of the test harness,
doesn't affect anyone else?
plinss: There are applications of requirements to make this work.
plinss: But those requirements weren't put on the repo by the
build system, the build system adopted from requirements
we chose.
plinss: So we can changes those requirements.
plinss: It was a choice to have unique filenames across the repo,
so that tests could be moved and results are the same, etc.
plinss: If you want to say just the path has to be unique, could do.
plinss: Nice thing harness does now, if the test moves, you can
move from one test suite to another, the results go with it.
plinss: Or you can use the same test in multiple test suites, and
the results are bound to the test.
plinss: That requires having some kind of unique identifier, so we
are using the filename.
plinss: The paths are all relative, the build system just deals
with that.
gsnedders: Wrt running tests in browsers, want to create a
manifest of all tests in the entire repository
gsnedders: without regard to current "set of test suites".
plinss: Want that, sure, but also want manifest per spec.
plinss: Want to track testing coverage and implementation progress
for a given spec.
gsnedders: But don't need to actually build.
plinss: Don't need to generate into a separate directory as we do
today.
plinss: Can adapt the test harness to work with tests remaining in
place in the repo.
RESOLVED: Remove test-building aspect of build system, just build
manifests.
gsnedders: I would much rather we got rid of the unique filename
rule.
plinss: If they're not unique, can't move them around.
gsnedders: Is that a significant problem?
tantek: That's what motivated some of the naming requirements
early on.
plinss: Features move from spec to spec.
gsnedders: Then you end up with large subsections of test suites.
gsnedders: And then [...]
fantasai: I think only the test name needs to be unique.
gsnedders: But when you have support files...
gsnedders: Want to just name the support file, not have to have
unique names for the support file.
fantasai: I think it's not needed to be unique.
fantasai: Although there are a set of common support files, which
are expected to be identical across repositories.
Sizing
======
Scribe: gregwhitworth
fantasai: There have been authoring issues I've been trying to
work around.
fantasai: [describes tables in CSS specs: spec has 50em max-width
for readability, but want table to fill up to 100vw,
not be pressed into 50em and have too-tight wrapping
within cells]
fantasai: Shrink to fit means
fantasai: Be at least as big as my min-content and no larger than
my max-content the in between is the available size.
fantasai: The in between is taken from the containing block.
TabAtkins: It's the other way around.
fantasai: You can represent it both ways.
TabAtkins: One's wrong.
<dbaron> max(min-content, min(max-content, available))
<TabAtkins> never mind, i'm wrong. elika's formulation is right,
it's just imo way more confusing
<TabAtkins> it's more natural to say that the min size is
min-content, max size is available space, and it
*tries* to be max-content, clamped between those two.
dbaron: I'm going a little ahead
dbaron: but imagine fit-content is an argument fit-content(100vw)
the table will do the stf algo using the fill up to the
viewport width.
Rossen: Basically you're changing your available width.
fantasai: [draws an example]
fantasai: Another common thing you want to do with grids, you want
to label input fields
fantasai: and you want to set the labels column to be the
max-content width and the rest of the width of the
inputs should be 1fr.
fantasai: But as you make the window narrower, having the inputs
really narrow is awkward for typing
fantasai: so we should allow the labels to wrap
fantasai: which would allow the inputs to be wider--but also
flooring at min-content would mean the labels also never
overflow
fantasai: If this input starts to get smaller than 50%, then we
should start to wrap the label.
fantasai: I feel like this is a very good behavior for this
usecase, but we can't achieve it.
fantasai: That's my proposal: fit-content() as a function,
the default argument would be the available size.
jensimmons: There are a lot of great use cases here.
jensimmons: With a lot of the new layout modes you can allow the
content to dictate the container.
fantasai: Thoughts?
Florian: I've run into this quite recently.
dbaron: I was in favor when you were two sentences in.
fantasai: Should we add it to the spec?
Florian: Does it take calc?
TabAtkins: Yes calc is just a length.
plinss: Why not use a generic minmax() function?
fantasai: The minmax() doesn't have the ability because
shrink-to-fit is a 3-arg formula.
fantasai: I tried, we don't have a generic min or max functions to
build it out of.
plinss: That's what I was proposing.
fantasai: No one has interest in implementing min() & max() though.
fantasai: We've discussed it before and we always agreed not to do
it, and I don't recall the reasons.
TabAtkins: Table layout reverses percentages and it causes problems.
fantasai: Even doing that in the future doing this is common we
would want a simple function
fantasai: and fit-content is already a keyword we have and we're
just adjusting it.
fantasai: It depends on the available size is bigger or smaller.
dbaron: You could do it if you have min() or max()
dbaron: It does some crazy things in some contexts, and we could
just define them away.
TabAtkins: Like we decided to allow calc() to just do auto in
tables.
fantasai: I'm willing to open generic talks again but I still
think we should have this. It's much more usable for
authors than max(min-content, min(max-content, foo))
Rossen: To summarize, the fit-content function that will override
the available width for the shrink-to-fit formula.
RESOLVED: Create a new fit-content function in Sizing level 3 and
Grid
dbaron: For the record, min-content, max-content and fit-content
were created to expose existing concepts in the engine and
they didn't have use-cases
dbaron: and they turned out to be useful.
Rossen: We're adjourned.
Received on Thursday, 26 May 2016 00:05:31 UTC