W3C home > Mailing lists > Public > www-style@w3.org > May 2016

[CSSWG] San Francisco F2F 2016-05-10 Part III: Report on vertical writing award website, Testing, Sizing [css-sizing]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 25 May 2016 20:04:29 -0400
Message-ID: <CADhPm3vkm=Yq6KRScL2VTCVPTWR3fcEyYOqTgRdUQj8oMP4S6g@mail.gmail.com>
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:


  - 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
              5) Update specs to say that issue are filed against
      - 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.


  - RESOLVED: Create a new fit-content function in Sizing Level 3
              and Grid


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.
  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
  skk: When we use ruby we cannot put each character inside the grid
  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.

  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,
  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
  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?
  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
  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
  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

  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-
  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
  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
  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
  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
  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
  <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
  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]
    1) Set up mailing to receive GitHub issue notifications for
    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
  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
  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?
  <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
  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
  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

  gsnedders: I would much rather we got rid of the unique filename
  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.


  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
  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
  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

  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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:03 UTC