Estelle Weyl | 22 Dec 06:21 2014

[specs] Discrepancies in spec explanations

i am seeing differing conventions in different specs

for example, in animation, for animation name I see
Value: <single-animation-name>#

but for transition-property i see
Value: none | <single-transition-property> [ ‘,’ <single-transition-property> ]*

should the former be
Value: <single-animation-name> [ ‘,’ <single-animation-name> ]*

or should the latter be
Value: all | none | <single-transition-property>#


fantasai | 20 Dec 01:32 2014
Picon

[css-writing-modes] Margin Collapsing Orthogonal Flows

Gérard has been testing Writing Modes and found an interesting
discrepency between Webkit/Blink and Gecko:

<horizontal-tb>
   <vertical-lr>
     <p>I have margins</p>
   </vertical-lr>
</horizontal-tb>

In Firefox, the left and right margins of the <p> collapse out
through the content edge of <vertical-lr>.

In Webkit, they are contained by <vertical-lr>'s content box.

I am wondering what is the preferred behavior in such a case:
should these margins collapse?

~fantasai

Rick Byers | 19 Dec 17:56 2014

Re: [mediaqueries4]Differentiating touchscreen+mouse from touchscreen only scenarios

On Thu, Dec 18, 2014 at 5:55 PM, Oren Freiberg <oren.freiberg <at> microsoft.com> wrote:
> We think the spec should avoid ambiguities around non-pointer devices---we were bitten by this during our implementation.
> Details: Even though 'pointer', 'any-pointer', 'hover' and 'any-hover' values are meant for pointing devices only (right?), the spec
>    http://dev.w3.org/csswg/mediaqueries-4/#mf-interaction
> defines 'pointer' and 'hover' values ambiguously with respect to inclusion/exclusion of non-pointing input device like keyboards:
>
> A. The 'pointer' value definitions include non-pointing devices, but the 'hover' value definitions don't. These defs use "... primary input mechanism ..." and "... primary pointing system ..." respectively.
> B. The 'any-pointer' and 'any-hover' definitions include non-pointing devices: "... capabilities of all the input devices ...".

It turns out Tab and I made some different assumptions on the intentions here (and failed to talk to each other about it - sorry!).  I think the two specific open issues are:

1) Is the distinction in the spec language between "pointer device" and "input device" meaningful?  Can we just clarify all the wording to refer to "pointing" devices to make it clear these APIs have nothing to do with non-pointer input devices like keyboards?

2) What are the semantics for "any-{pointer,hover}: none"?  If it's strictly a union of the {pointer,hover} values (as Tab instructed Dave off thread for our initial implementation in chromium) then 'any-pointer: none' will always be true.  If instead, it's a union of all capabilities (where 'none' represents the absence of a relevant capability) then 'none' is mutually exclusive with all other values and so 'any-pointer' is true iff 'pointer' is true.  The latter makes the most conceptual sense to me, and appears (from our limited testing) to be what the IE tech preview implements.  We've just switched our implementation to match this (before I was aware of the discussion between Dave and Tab on this point).
 
> Hope we didn't miss anything in-between.
> Mustaq
>
> On Thu, Dec 18, 2014 at 1:54 PM, Florian Rivoal <florian <at> rivoal.net> wrote:
> On 15 Dec 2014, at 21:54, Mustaq Ahmed <mustaq <at> google.com> wrote:
>
> Update: we are on track to ship 'any-pointer' and 'any-hover' media queries in Chrome M41 (https://www.chromestatus.com/features/6460705494532096). These are already available in Chrome canary builds for testing. Note that we shipped 'pointer'
> and 'hover' media queries in M38.
>
> BTW, IE 11 tech preview is also shipping these:
> https://status.modern.ie/mediaquerieslevel4interactionmediafeaturespointerandhover?term=media%20queries
>
> Good to hear, thanks for the update. Any feedback on the feature itself, or the way it is specified, based on this implementation?
> Also, I suppose you wrote some tests in the process of developing this. It would be greatly appreciated if you could contribute these to W3C to be included in the test suite for media queries 4, to help move the spec along the REC track.
>  - Florian
>
> PS: Hi Microsoft, same questions about feedback and tests for you.

Adding Brandon the developer to represent Microsoft for this feature area.

Thanks!
Oren
Daniel Glazman | 19 Dec 15:33 2014

[css4-ui] caret-color

Hi there. I started working on 'caret-color' and I have a first patch
for Gecko in [1] (written on behalf of Bloomberg). Bloomberg also has
an implementation for Chromium in [2] although I'm not sure that one
implements the 'auto' value that was discussed here a while ago.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1063162#c12
[2] http://bloomberg.github.io/chromium.bb/

</Daniel>

John Fischer | 18 Dec 20:09 2014
Picon

[selectors] Proposal :enter and :leave

:enter would be an pseudo class to detect when an DOM element will enter 
in the viewport of the browser.

This could happend, when page is loaded, scrolled or resized.

:leave would be the opposite meaning that it will occur when an DOM element will leave the viewport of the browser.

You can find a sample of this behavior by looking at the below library which reproduces this behavior by
adding dynamically "enter" and "leave" class on some specific DOM elements.

http://jfroffice.github.io/x-enterleave.js/

That would be handsome and quite useful to design "enter / leave" animation.

This purpose might also be extend to bind the same kind of event according the parent DOM element.
But it will cost maybe more in implementation. (even if overflow css properties look more less like an
already implemented algorithm in the browser).

I hope my proposal is quite understandable.

Do not hesitate, for some feedback.

Maybe I missed something and this problematic has been already debated.

- John

Sebastian Zartner | 19 Dec 13:11 2014
Picon

[css-inline] The TOC doesn't mention 'initial-letter-align'

Within the table of contents there is no explicit mention of the 'initial-letter-align' property.
It should rather be:

2.4 Alignment of Initial Letters: the 'initial-letter-align' property

Sebastian
fantasai | 19 Dec 08:26 2014
Picon

[CSSWG][css-align] Updated WD of CSS Box Alignment Level 3


The CSS WG has published an updated Working Draft of
the CSS Box Alignment Module Level 3
     http://www.w3.org/TR/css-align-3/

This module defines new features relating to the alignment of
boxes within their containers in the various CSS box layout
models: block layout, table layout, flex layout, and grid layout.

This draft includes details on baseline alignment, and a small
pile of more minor fixes.

Significant changes are listed at:
   http://www.w3.org/TR/2014/WD-css-align-3-20141218/#changes

Please send any comments to this mailing list, <www-style <at> w3.org>, and
please, prefix the subject line with

     [css-align]

(as I did on this message).

For the CSS WG,
~fantasai

Cameron McCormack | 19 Dec 01:27 2014
Picon

[css-logical-props] do shorthands have logical component longhands?

I'm working on making Gecko's logical properties behave as proposed in 
various mails to this list, where both physical and logical properties 
behave like normal properties in declarations but which are resolved at 
cascade time (after an initial computation of direction and 
writing-mode) to appropriate physical property values.

One question I have is whether logical longhand properties are 
considered to be parts of the corresponding shorthand, for example is 
margin-inline-start a longhand component of margin?  I think the answer 
should probably be "no" as you don't know what values to set the logical 
properties to:

   div { margin: 1px 2px 3px 4px; }

What would be the values of margin-inline-{start,end} in the declaration?

In terms of its effect on the layout of the document, it doesn't really 
matter, since margin-{left,right} would override any previous 
margin-inline-{start,end} properties in the declaration when we're 
resolving them during the cascade.  So from that perspective it makes 
sense to not set margin-inline-{start,end}.

On the other hand, it could be like other shorthands where if you don't 
have values specified for some components then they get set to their 
initial values (e.g. like when you leave out some parts of the font 
shorthand).  So we could have them set to 0.

Now, what if you want to clear the shorthand from script?

   <style>
   div { margin-inline-start: 1px; margin-inline-end: 2px; }
   </style>
   <script>
     document.styleSheets[0].cssRules.style.margin = "";
   </script>

I almost would expect that to clear the margin-inline-{start,end} 
properties, but that's not possible if they're not longhand components 
of margin.

Dave Cramer | 18 Dec 21:47 2014
Picon

[css-inline] CSS Line Layout Module FPWD Published

The CSS Working Group has published a first public working draft of
the CSS Line Layout Module:

http://www.w3.org/TR/css-inline-3/

This document covers special typographic effects for initial letters,
such as drop caps. As initial letters work very differently in
different scripts, we are actively seeking information and feedback on
initial letters in non-Latin scripts. In the future this spec will
also cover more general inline layout.

We welcome your comments. Please send any comments to this mailing
list, <www-style <at> w3.org>, and prefix the subject line with

    [css-inline]

(as I did on this message).

For the CSS WG,
Dave Cramer

Dael Jackson | 18 Dec 02:46 2014
Picon

[CSSWG] Minutes Santa Clara F2F 2014-10-27 Part IV: Grid, Test Suites

Grid
----

  - There was a long conversation about the request from SASS to not
      use bare parentheses since they use it for grouping.
      - Brackets were suggested as an alternative. The editors
          stated that when they were originally writing this part of
          the spec, the selection of parenthesis over brackets was a
          coin-toss choice, not a specific preference.
      - There was conversation on which provided more readability,
          brackets or parenthesis which no clear winner, but no one
          strongly disliking either option
      - However, there were a considerably number of people that had
          concerns about the precedent that the group would be
          setting by agreeing to make this change for one
          preprocessor, even though it's a large one.
      - Ultimately, there was no consensus on the change.

  - Rossen brought his proposed algorithm for grid fragmentation to
      the group for feedback.  His algorithm sought to maintain grid
      areas as non-fragmented as possible.
      - There was concern about forcing items onto the next page to
          avoid fragmentation and about defining a non-ideal
          algorithm when implementers may be able to do better
          behavior.
      - Break properties were also discussed with some concern
          expressed that the proposal states that they don't apply
          to grid items, just the content inside.

  - The work gregwithworth has done on collapsing was tabled for the
      time being.

  - Grid's inability to handle problems like this
      https://twitter.com/AlanHogan/status/519256635911307265/photo/1
      should be solved since it's a reasonable case. Fantasai
      outlined a potential approach and she and TabAtkins will work
      on making it possible.

  - Sizing of grid items inside the containing block will be
      clarified slightly in the spec language by explicitly stating
      that sizing is defined by the object's type.

Test Suites
-----------

  - ArronEi will go through the errata on CSS 2.1 and see exactly
      what needs tests so that an update can be published with a
      test suite.
  - He is also working on creating a document that standardizes the
      process for getting tests and will use the backgrounds and
      borders test suite to make sure his process is complete and
      accurate before presenting the document to the group.

===== FULL MINUTES BELOW ======

  Scribe: dael

Grid Layout
===========

Line Name Lists: Parentheses vs. Brackets
-----------------------------------------

  TabAtkins: Before we start full grid, I've been talking to the
             lead maintainer of SASS because they use parentheses as
             a grouping and that's common with preprocessors. The
             only way to work around this is to inject some very
             specific language. She's requesting we revisit the
             syntax and either make it named or use a different
             grouping character.
  ??: What would the named function be?
  fantasai: not-a-SASS-function()?

  TabAtkins: I don't think we...I'm not sure if we've implemented
             the syntax or if we just did it, but we could change
             ours.
  fantasai: I don't think we're shipping.
  TabAtkins: If we're okay coming up with a name, we can just say
             that and address what it would be on the ML?
  Rossen: I wouldn't be opposed.

  TabAtkins: Their request is please don't ever use bare parentheses.
  plinss: What about inside calc?

  <leaverou> shouldn't preprocessors follow CSS instead of the
             opposite? It's much easier for preprocessors to change
             their syntax than it is for CSS.

  TabAtkins: It's already intrinsically-magic. She's talking on the
             property level.
  Bert: We use them in MQ.
  TabAtkins: Different syntax pieces, it's any property where it
             means something different.
  TabAtkins: Right now they use parentheses as a grouping and
             they're heavily used everywhere. They can't change
             their current use and they want to, as much as
             possible, have that for SASS it is a super-set. Any CSS
             is correct in SASS and that would force that to change.
  TabAtkins: And she says that calc is a crazy special case already.

  TabAtkins: We'd be resolving to not ever use bare parentheses.
  plinss: I'm not sure I'm okay with that.
  TabAtkins: This preprocessor is already 5 years old.
  leaverou: CSS has more users then preprocessors. If both options
            are the same we can make it easier for preprocessors,
            but if this is easier for authors we should do it.
  TabAtkins: This is small, though.

  astearns: The parentheses in question are grouping line names?
  astearns: Is there any other place in CSS where we've wanted to
            give alternate names?
  TabAtkins: What do you mean?
  fantasai: One issue is you'll make the syntax more awkward. Even
            if you pick a great name, every time you define a grid
            template, you'll have to type it again. It's not buying
            the author anything great.
  <TabAtkins> http://dev.w3.org/csswg/css-grid/#track-sizing

  rossen: Can they special case?
  TabAtkins: Not without special case-ing this one property and any
             others where we create blanks.
  rossen: They can create a lookup table.
  TabAtkins: They've avoided it until now.

  fantasai: We have three options. 1) switch to brackets
  fantasai: 2) switch to curly brackets.
  TabAtkins: I don't think we want that.
  fantasai: 2) is switch to a short name.
  fantasai: 3) is we tell SASS that the effort to put this into
            special case...we tell them they have to special case
            this.
  fantasai: The downside of switching to name is it makes the syntax
            have a lot of noise and it becomes harder to read. It's
            not helping the authors any.
  fantasai: Downside of telling SASS to special case is they have to
            put in some time to implement a special case.
  TabAtkins: Also, handing stuff in script becomes harder. In this
             particular case the parentheses in a list get
             translated to actual parentheses. It makes the model
             less consistent.

  fantasai: The only option without a downside is switch to brackets.
  fantasai: I'm not impressed with the list.
  bkardell: Brackets is pretty good.
  TabAtkins: The only point of a function is to group.
  bkardell: Also SASS is open source so anyone can submit a patch.
            If the WG felt strongly SASS should change they can send
            a request.
  <bkardell> I don't support us changing SASS
  florian: It's also bad for SASS users.
  TabAtkins: Their population is smaller, but it's not insignificant.
             They have lots of users.
  TabAtkins: I'm fine with square brackets.

  fantasai: Any other issues with them?
  fantasai: The only option I'm not okay with is script.
  TabAtkins: I'm down with square brackets. And in the future when
             we need to group things, we'll just use square brackets.

  <leaverou> I would argue that parentheses are more natural and
             intuitive for any kind of grouping.
  plinss: The forward compat parsing is that you match parentheses
          and brackets. That means we can use them where ever we
          want. That someone else jumped over that isn't our fault.
  TabAtkins: And within functions it's different.
  plinss: But we might have something in selectors or something we
          don't see now in the future.
  fantasai: I think plinss is objecting on principle.
  TabAtkins: I think the practical overrides principle as long as
             there's a reasonable answer to it.
  <fantasai> http://dev.w3.org/csswg/css-grid/#named-lines

  dauwhe: Will brackets feel as natural?
  TabAtkins: You don't need shift.
  dbaron: Is that true for non US keyboards?
  [it's not]
  TabAtkins: Anyone that writes code on their keyboard can find a
             square bracket.
  SteveZ: I'm not opposed but to me traditionally that means
          subscript.
  SteveZ: I think it's going to be a point of mild confusion where
          parentheses would be less.

  TabAtkins: This isn't common in programming languages.
  many: lists
  dauwhe: What % of CSS users are programmers?
  TabAtkins: Pretty low.
  bkardell: It's loaded. A lot of CSS users do basic PHP. They're
            not totally withdrawn.
  rossen: dbaron, didn't you use brackets in your overflow or
          something?
  dbaron: I don't know.
  TabAtkins: It would be this (link above) with square brackets.

  gregwhitworth: What was the argument again?
  TabAtkins: SASS uses parentheses for grouping.
  TabAtkins: LESS has similar problems.

  plinss: I'm not married to the parentheses and I don't mind
          alternate syntax, but I object to us giving up parentheses
          forever.
  <leaverou> plinss++
  florian: We're weighing the pros and cons.
  TabAtkins: Any argument we make here is for anywhere we use
             parentheses.
  SteveZ: If you establish that square brackets are ways of
          identifying chunks, we should use that anywhere that we're
          doing chunks.
  florian: And if we find another reason to use naked parentheses we
           can still do it.
  <leaverou> As many pointed out, it's not this particular property.
             If we use brackets here, we have to use them in every
             future property that needs grouping/chunks of any sort,
             for consistency

  rossen: So if you go back to them and say no, would they declare
          war or...?
  TabAtkins: They'll figure something out, but it would be
             frustrating for them and their users.
  bkardell: The problem is there's a bunch of SASS out there now.
  rossen: Existing SASS targeting grid.
  bkardell: That's true.
  TabAtkins: They can't tell context immediately. It's probably
             possible to make it work, but it would be weird.
  plinss: Well, they could change it.
  TabAtkins: That would break that "all valid CSS is valid SASS."
  plinss: If that's their rule, they violated it.
  TabAtkins: Technically any syntax they choose violates that
             because we can use it.
  plinss: I don't want to constrain ourselves because someone else
          picked a syntax. If they had restricted themselves to the
          extension points in our syntax they'd be fine.
  TabAtkins: Like  <at> rule
  plinss: And prefixes
  TabAtkins: But they didn't and we can't go back in time. My first
             answer was "sucks to be you", but then she explained
             more and it makes sense.

  florian: Given that I don't find square brackets odder it's fine.
           In this case it's fine.
  leaverou: It's creating a precedent
  florian: If we find later a place where naked parentheses is
           better, screw SASS but right now we have an alternative
           that's not any worse.
  florian: If you think list you're in trouble, but this it doesn't
           matter square or round.
  TabAtkins: Sizes may be keywords so you need to disambiguate.
  fantasai: Or we might add the keyword.
  ???: Use strings?
  TabAtkins: It's uglier.
  fantasai: We had strings before. We switched to idents because
            that's what CSS uses for custom names. Also it's not
            just here, we use them in the grid position properties.

  rossen: I think the argument is beyond this. I think this is on
          the grounds of do we give up parentheses.
  florian: I don't think we have to always, but in this case they're
           not the only good choice.
  Rossen: You're saying that later in time there will be a larger
          chance of us going to SASS and ask them to change when
          they have more content because we'll have to use them.
  TabAtkins: We're making future us deal with it.
  leaverou: And they don't need to change until this ships.
  TabAtkins: We hope to ship in Q4
  florian: Forcing SASS users to use inconsistent, we want to avoid
           that.
  leaverou: But they'll special case.
  florian: But they'll have to remember the special case.

  <zcorpan> how about grid-template-columns: first nav 150px,
            main 1fr, last; ? i.e. use comma, all but the last
            component value are custom names
  <SimonSapin> Rossen, Is IE shipping the keywords-in-strings syntax
               of grid-template-areas?

  bkardell: Is there a compelling case why parentheses are better
            here? leaverou, I feel like you don't like this and I
            want to figure out why
  leaverou: I'm worried about the precedent.
  TabAtkins: When SASS has asked before, I've said no. It was a
             little inconvenient. They've just dealt with it like
             when we use /. This is a different bucket and way more
             inconvenient.
  bradk: Can they change their syntax?
  TabAtkins: Not at this point.
  TabAtkins: It would just make all SASS scripts broken.

  bkardell: Let me re-frame. I like brackets better.
  bradk: They make me think of attr.
  TabAtkins: That is where we use it right now.
  fantasai: Selectors is a completely different syntactic space.

  TabAtkins: If we pretend I had always used square brackets, is
             there an argument to switch to parentheses?
  <fantasai> Note, it wasn't Tab's suggestion to use parentheses
             originally, it was mine. :)
  dauwhe: The corner is hard on my eyes.
  dbaron: Would it inconvenience other preprocessors?
  TabAtkins: Not that I'm aware of.
  <dbaron> (Tab said he thinks [] are fine for SASS and LESS.)

  adenilson: For this specific case in grid we change to square, but
             it's important to let them know that this is an
             exception and we may use parentheses in the future.
             Since you'll have close contact, we can say we care
             about SASS but we are leading.
  TabAtkins: In this case which character doesn't effect our users.
  plinss: I think we need to be definitive that it's a future them
          that has to deal with this. If we do this the installed
          base of parentheses users will keep growing. Even if we
          say yes but we reserve the right, but we're creating a
          world where that's harder.
  TabAtkins: We can always say screw it SASS.
  fantasai: If the choices were between SASS fixes or we use names,
            I would says SASS has to fix its stuff.

  TabAtkins: So, square brackets. Objections?
  plinss: I object.
  TabAtkins: You object to future problems.
  fantasai: I think we switch to square brackets and tell SASS that
            if we have this problem again they have to fix it
  <hiroshi2> I think, to think about SASS users and scripts are
             important. but the time to take effects this
             parentheses would take some time. so, now we can ignore
             about sass. (SASS can moderate this change)
  TabAtkins: Remember future us has never treated past us's
             resolutions as unchangeable

  fantasai: Propose we switch grid line naming to square brackets
            and tell SASS that in the future they'll have to deal
            with it.
  rossen: Can we do a straw poll to see if others are objecting?
  glazou: I'd like to hear precisely.

  plinss: Is anyone else objecting to switching to square brackets?
  Rossen: I'm with you on the basis to giving up parentheses, yes.
          For a spec def that no one ships I don't care.
  florian: You can buy into a slippery slope where it applies.
  plinss: No matter what we say, we are.
  TabAtkins: No, we're not.
  plinss: If we're saying it's a bad idea now it'll be worse later.
          And the amount of pain and size will get worse.
  plinss: We're either forcing them to take pain now or force them
          to take a lot of pain later.
  Rossen: And you're saying if we use brackets here and need them
          again later we'll be inconsistent with ourselves.
  * glazou is with plinss and objecting too
  * ArronEi is also with plinss and objecting as well

  fantasai: We just did a coin toss to choose before and now SASS
            says we have a reason for you to go the other way. In
            the future we may need another type of grouping that's
            not square brackets, then we can tell SASS they have to
            deal.
  fantasai: We're saying next time we have this problem they have to
            deal.
  <leaverou> if in the future we have a similar discussion, there
             will also be the argument of consistency, i.e. "but
             we're already using brackets here and there"
  <leaverou> so it essentially makes it more difficult to resolve to
             parentheses in the future.

  plinss: Do you believe SASS will make changes based on this?
  fantasai: No.

  florian: As for it being worse in the future, this isn't obvious
           that SASS user base is growing faster than CSS.
  plinss: SASS may go away, but another one may step in.

  glazou: We have two arguments and no one is changing their mind.
          We have at least three objections. Raise your hand if
          you're objecting to using square brackets.
  TabAtkins: You're objecting to if we had picked brackets in the
             past.
  plinss: But if we had done the opposite we would be in the same
          place.
  glazou: So let me see hands.
  glazou: It's significant. It's too much.
  florian: We could use angle brackets, but it would inconvenience
           HTML users.
  dauwhe: This doesn't look like consensus.

  TabAtkins: I really don't like it.
  fantasai: People are objecting to changing but not to brackets.
  TabAtkins: We can say in the future we can tell SASS to change.
  plinss: We're telling SASS they made a mistake and they have to
          fix it now.
  TabAtkins: Your preferences are path-dependent
  glazou: We didn't choose to use the $ because it was used by
          preprocessors and we asked if they could change and they
          could not.
  glazou: We cannot be blocked by a 3rd party
  florian: It's about SASS users. Its inconvenient there.
  bkardell: If your argument is true, we already blocked ourselves.
  bkardell: If the argument is we set a precedent that we'll change,
            we already did it.
  <fantasai> could've just said script users need to use $$, just
             like in bash
  <fantasai> everyone else can use $
  glazou: But we found another option
  bkardell: Which we can do this again. If SASS had a WG rep they
            would have said they don't like parentheses.

  plinss: We're into our break. Lets go on break, meet back at
          3:30ish. If we come back with changed minds we can revisit.
          Otherwise this is done.

  <astearns> One possible argument that brackets could be better -
             the names can be nested in a repeat function
  <astearns> I find this: repeat(4, 10px [col-start] 250px [col-end])
  <astearns> easier to read than this: repeat(4, 10px (col-start)
             250px (col-end))
  <shans> astearns: me too

  [Snack Break]

Fragmenting Grid Layout
-----------------------

  plinss: Other grid issues?
  Rossen: Did we close on the previous one?
  gregwhitworth: It was no consensus.
  plinss: What's next on grid?

  <Rossen> http://dev.w3.org/csswg/css-grid/#pagination
  Rossen: The one issue I wanted to cover is grid fragmentation
          which is something I added earlier today so I don't expect
          anyone to have reviewed it yet.
  Rossen: I can go over the proposed behavior and explain some of
          the decisions.
  Rossen: So, for context, CSS grid is a layout mechanism that
          allows you to divide your area into rows and columns and
          define grid areas in between those and the content can
          influence those by their size.
  Rossen: When we talk in terms of fragmentation, it's not a use
          case where grid should be expected to work great.
  Rossen: In other words, grid as a layout primitive in an ideal
          should be used in non-fragmented cases. It should be in
          the page, not across many pages.
  Rossen: With that in mind, our intent with the proposed algorithm
          is we wanted to keep the areas as intact as possible.
  Rossen: That's why that algorithm is fairly simple. Any time you
          come across a row on a fragment break, we would want to
          push that row to the next fragment.
  Rossen: The question is how you would resolve fr and auto row
          sizes because they depend on content and you might end up
          with reverse dependency.
  Rossen: The current algorithm resolves grid in the first fragment
          space, assuming it has a definite width. Then we resolve
          all the fr and auto rows, then we would fragment that
          layout.
  Rossen: Again, the question is what happens when a row gets to be
          fragmented. For example it's the first row and it's long
          enough it needs to fragment.
  Rossen: Obviously the content will become longer and larger than
          what we measured inside continuous space.
  Rossen: We would fragment the current rows and will overflow grid
          rows in the case of fixed height or extend if they are
          auto or fragment without having to re-layout the grid
  Rossen: Does that make sense?

  SteveZ: The last statement of if the second column overflows, does
          that extend the row across?
  Rossen: If it's not fixed height.
  SteveZ: So you're taking the max?

  plinss: I think what you're saying makes sense but falls down in
          more complex cases. Maybe this is a non-issue. You said if
          a row is fragmented you take all the areas...
  Rossen: All the areas that start in that row. So what happens with
          the lines, the line on the row, you can align bottom in
          that fragment and bottom on the other.
  plinss: Probably available on both fragmentainers.
  plinss: So say you have a grid that's a single cell and you have
          something that spans two lines. So the spanning cell gets
          split in the middle. It may get taller than it would have
          been and needs to behave properly to push the line down.
  Rossen: Yes, in step 4 we say you would not take that into account
          when spanning items.
  Rossen: I'm sure that we'll keep refining this as we come across
          more cases, but as a general intent, we want to keep grid
          areas as non-fragmented as possible. In the error case
          where a row has to fragment, we follow normal rules and
          that row may or may not extend depending on if it's set to
          auto or fixed.

  fantasai: I don't think we should push to next page if they don't
            fit. People want to use grid for page layout. If you
            have a bunch of headers/navigation and an article, you
            don't want a lot of blank space between the header and
            the start of the article. Tables don't avoid breaks
            within rows that for that reason. If you want that
            behavior you can set it with 'break-inside: avoid',
            but it shouldn't be an unchangeable default.
  fantasai: The other comment, fragmenting of grid layout will have
            similar problems to flex layout. It might make sense to
            use the same spec text which is 'here are the general
            rules' and not spec the algorithm except in an example.
  fantasai: I think that trying to get, we don't want to push
            implementors to implement a fragmentation algorithm that
            isn't ideal and any we put in right now won't handle
            flex ideally. Like if you have something with a lot of
            flexing and pagination, you sometimes want to pull
            things *up* to optimize space rather than pushing it
            down.
  fantasai: If you're using flex to size you have extra space on the
            first but not the second, if you're fixed height you
            want to take that space to avoid a break by pulling into
            the first page. I don't want to normatively require
            something simple when we know people can do better.
  fantasai: We should encourage them to do better.
  <fantasai> Flexbox: http://dev.w3.org/csswg/css-flexbox/#pagination
  Rossen: I'm not opposed to it.

  astearns: I have a question, it says the break properties don't
            apply to grid items. There's no way to assign a break to
            a grid item. If an element is assigned to a grid area
            and it has a break before...?
  Rossen: It was clarifying to say you can't apply break properties
          to grid areas.
  fantasai: Flexbox propagates it out. For consistency we should do
            that. Break-inside should apply to all these things.
  plinss: I'm not so sure about that. If you have multiple columns
          and have a break, do you want to break every column at the
          same place?
  astearns: You could have items in the same row on different pages
            which would be weird.
  dbaron: I can imagine cases where pages would work badly if you
          don't line it up. So you have something on the side and it
          breaks in the main content, there's an expectation that
          they'd line up.

  fantasai: If you have a forced break inside a flex item, it's
            basically an expanded margin within the flex item,
            and stretches its content height.
  fantasai: If you have something that's 'I'm a flex item break
            before me', that pushes the item to the next page.
  fantasai: They just operate on the actual item.
  Rossen: That's the easy case.
  plinss: Problem is you have a multi-column grid. One thing in
          there wants to break. Does it break the entire grid?
  fantasai: Yeah. We can't put a forced break property on grid rows.
  plinss: I know cases where that's really bad.
  fantasai: You can't put it on the grid row, just the items in it.
  plinss: So I have multiple columns it's a magazine flow, and one
          article has a break.
  fantasai: It won't break the grid, it increases the height of the
            item. If you say this *item* should start on a new page,
            it pushes down the whole row.
  astearns: And you could end up in a situation where you have a row
            on the first page and a duplicate on the second page.
  plinss: Authors are going to want it both ways.
  fantasai: If they want it just in that, they can create a wrapper
            item. You can work around that. You're looking at
            conceptually there's an item that has stuff inside it
            and you're pushing stuff up or down.
  fantasai: I'm having a hard time coming up with examples where
            this makes sense.
  fantasai: If you're trying to get things to line up, you do that.
            If you don't want them to line up you shouldn't be using
            grid anyway. If the goal is you're using grid you want
            things to line up.
  fantasai: If you think this is a bad idea, maybe we should revisit
            flex.
  plinss: I think it makes sense for flex, but that's one dimension
          and this is two.

  Rossen: I'm mostly modeling after table layout.
  fantasai: You never have a case where a table cell starts on the
            next page just because all its content didn't fit.
  plinss: Page break before an entire cell.
  dbaron: I think the spec says it's not supposed to wrap.
  dbaron: I believe Gecko has bugs saying it doesn't work in Gecko
          and it does in other implementations and we've pointed to
          the spec saying it's not supposed to work.

  Rossen: We can try a different heuristic. Going to your example
          where you used grid to create a header and content. I'm
          not sure pushing grid down and starting on the second page
          is worse than breaking on the first page.
  fantasai: I think that it's much worse. If you want that you can
            opt in, but if you dictate you can't do that, no one
            will ever have a normal looking article. If we want it
            to replace tables and floats, we want it to look like
            that when we're printing. The printing should be
            equivalent.
  Rossen: Which is what tables will do.
  fantasai: They do not push. Want me to write a test case?
  dbaron: Bigger point isn't just about equivalence. They'll design
          a page and just expect printing to work. Massive gaps
          count as not working. So do a bunch of other things.

  SteveZ: What I don't understand, I would like to start the next
          row on a new page if it's a small gap. Since that's a
          conditional, we could define a property that says when to
          start a new page, but there's something we want to happen
          automatically that isn't force to a new page or break into
          a new cell.
  fantasai: I think if you want that you want that for all layout
            models.
  fantasai: File a bug against fragmentation.

  plinss: You might need a precedent where you have multiple grid
          items and conflicting layout. You have to come up with
          something rational for the whole row.
  fantasai: For the content of a grid item, you don't have two items
            consecutively in the same row, you just have one item
            and content inside the item. If you have to do different
            fragmentation requirements, then that just effectively
            increases the content height of the row.

  plinss: Is that it?
  Rossen: That's pretty much all I had.
  Rossen: That was the issue we addressed. We'll keep working given
          the feedback, but at least we don't have a big gap anymore.

Collapsing Rows and Columns
---------------------------

  plinss: The wiki said collapsing.
  gregwhitworth: We started by trying to come up with ways to
                 collapse a grid. At first it seemed simple like you
                 should be able to call an column, but then we
                 realized that the user would want to do that based
                 on an item, not a column.
  gregwhitworth: We came up with a couple ways to do it. I can paste
                 in the one that would be a pain to implement.
  <gregwhitworth> .grid::grid-row(“row-name”) {
  gregwhitworth: Inside that would be visibility: collapse and you
                 could declare a row name.
  gregwhitworth: There's no way to attach to a thing, so it would
                 end up being quite verbose. And I would like to
                 interact with an item and talk to its parent.
  plinss: The grid row solution; you're using two indexes to find it.
          You name/ID the two lines.
  plinss: Or use the span notation.
  gregwhitworth: I think it's one we can revisit.

  Rossen: Let's table this.
  plinss: But basically you're defining a new pseudo.
  gregwhitworth: It's the only thing we came up with.
  Rossen: Okay.
  plinss: No other issues?
  Rossen: We have issues, but nothing that we've worked on.

Auto-column-count Grids
-----------------------

  fantasai: There was one. Let me find it.
  <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Oct/0108.html

  SimonSapin: I sent something months ago. Grid doesn't define
              determining the size of the grid item which is
              unfortunate.
  TabAtkins: It does.
  SimonSapin: That was fixed?
  fantasai: I'm linking to something different.
  TabAtkins: SimonSapin can you find the original complaint?

  <fantasai> https://twitter.com/AlanHogan/status/519256635911307265/photo/1
  fantasai: The issue if you look at the second link (right above),
            it's the problem.
  fantasai: Well, this was kinda a grid layout. To try and get that
            layout you can't do it right now. There's a couple of
            problems.
  TabAtkins: The reason you can't do it in grid, it's not a 5
             column, it's fixed width columns, but as many as
             you need to fill the available space.
  fantasai: We need two things to fix this, which seems pretty
            reasonable.
  fantasai: To get this to work properly you need to put as many
            columns as fit items of size x. What we need is a repeat
            function that says as many columns that will fit in the
            space and they're 15em wide.
  fantasai: I think it would be useful and encourage flexible grids
            that look good on multiple screen sizes. I think this
            should be simple, but I don't have syntax yet.
  fantasai: Second thing that's necessary is, you'll notice the
            space is just enough that the columns fill the space. We
            have a property in flex that gives you this alignment.
            The simple solution is to reuse the property and have
            that mean there's a gap between the columns. Once you've
            figured out the size, space out the grid with that
            amount of space.
  fantasai: It might be tricky to define in terms of spanning, but
            it's a property we have.

  TabAtkins: We were planning to add row-gap and column-gap.
  fantasai: This is in addition. You might want those as minimums.
            We have basic syntax here.

  SteveZ: If I have a span, do I assume the span covers the gap?
  TabAtkins: So if your edge, it'll go over to the closest.
  SteveZ: So the ends of the span line up with the ends of rows.
  TabAtkins: It's difficult to spec, but we'll handle it.

  TabAtkins: This stuff should be the first things in level 2. As
             soon as things start to ship, next year we can start on
             level 2.
  fantasai: I think the repeat is almost syntactic sugar. The
            justify is tricky.
  TabAtkins: You can center the whole grid or, if you center each
             item within, you can get space.
  fantasai: Which is I think is good enough. I think it would make
            people happy if we did repeat to fill.
  TabAtkins: I'm trying to be as conservative as possible to get
             grid level 1 done. I want grid and flexbox to finish at
             the same time.
  Rossen: You're not alone.

  * leaverou notes that the tweet fantasai linked to also
             demonstrates a great case for static value
             interpolation (that we discussed a while ago in the ML)

  plinss: Is that it?
  fantasai: I think TabAtkins and I need to do a lot of editing and
            we'll come back.

Sizing the Grid Container
-------------------------

  SimonSapin: I have an issue. There was grid containers, that's
              fixed. The only thing I can find on sizing with ident
              is by default they're stretched in the grid area.
  TabAtkins: Grid defines the containing block as the containing
             area, what else do we need?
  TabAtkins: The size is that of the containing block.
  SimonSapin: You said size is the containing block. Where is the
              sizing defined? Same as blocks?
  TabAtkins: If they're a block they display as block?
  Rossen: This is the same as asking how the table cell size are
          defined by the view of table?
  SimonSapin: That's defined. What we do in the spec, the outside is
              defined specifically. Blocks have their own sizing,
              what is the sizing of grid items inside the containing
              block?

  fantasai: He has a point. They are participating in a grid layout
            context. What that does is not defined.
  fantasai: You're confusing display inside and outside.
  TabAtkins: I'm not. It doesn't have a display outside.
  TabAtkins: Once we've established how big based on the layout
             algorithm, it should just have a containing block.
  dbaron: So if a grid item is just display block, and it has a
          background, the background fills the width of the grid
          cell but not the height?
  TabAtkins: If its got align self stretch, it's height will be the
             height of the grid area.

  fantasai: Normally is under-defined because there's no normal.
            let's look at width.
  fantasai: If align-self is start, how does it display?
            Shrink-wrap?
  TabAtkins: Flex says that. What needs to be defined besides the
             containing block.
  fantasai: We need to say that if it's start it's shrink-wrapped.
            If it's not we should say that.
  SimonSapin: Maybe by normally you mean like blocks. That's fine.
  TabAtkins: But we can't because if you're a table you don't.

  Rossen: If your item is another grid, what do you expect?
  TabAtkins: Certain types of things, flex puts requirements on how
             you size. But sometimes the layout says format as
             normal and give me your size.
  TabAtkins: How does a block layout, it does things and you get a
             size back.
  Rossen: You get a grid item that is a grid. In this case normal
          means do your grid layout and give me back your size. If
          that item happens to be table, it sizes like a table, if
          it's block it will behave like a block.
  TabAtkins: So you're looking for context on how blocks behave and
             I'm not getting what exactly you want.
  TabAtkins: Some display models put extra constraints on how
             children layout, but otherwise the rules should be
             defined by the layout mode.

  dbaron: It sounds like if the editors don't agree what the spec
          says, they should make sure there is language.
  TabAtkins: I'd love to but I don't understand what's being asked
             for.
  SimonSapin: When in alignment it says that grid items stretch to
              fill the area, what does it mean.
  TabAtkins: The align: self defines how you stretch.
  SimonSapin: So the default is auto.
  TabAtkins: Which is stretch for grid items.
  TabAtkins: Chrome isn't conformant with this right now. We're in
             the process.
  SimonSapin: Maybe add a note that says the sizing of grid items
              depends on the items' layout mode.

  Rossen: Do we have this text on flex?
  TabAtkins: Flex puts some constraints, but it just says do layout
             based on these things. I'll find it and if it's
             inconsistent, we need to fix it, but I'd like to know
             why it's inconsistent or incomplete.
  <TabAtkins> Flex algo line 3E
  TabAtkins: Is this insufficiently specified? It's the same level
             as grid right now.
  SimonSapin: Okay.
  TabAtkins: If you can figure out what needs to be stated in those
             cases we can fix that.

  Rossen: An editorial note?
  TabAtkins: I can't think of what it should say. If you can come up
             with something we'll put it in, but I think that 'do
             layout as you would normally for your display type' is
             a thing that doesn't need more qualification.
  SimonSapin: The thing I'm missing is for it's type.
  TabAtkins: Okay. That's also missing from flex layout right now.
             Okay, we can add detail as to what it means to do
             layout.
  TabAtkins: Alright.

  TabAtkins: Can you send a reminder to what wording you want in
             flexbox?
  Rossen: Or just put it in the minutes. We'll parse it out.
  plinss: So is that it on grid?
  Rossen: We're done.

Topic Search
============

  Rossen: Who put flexbox?
  fantasai: I think we were expecting to have the issues in.
  Rossen: Can we push that to tomorrow?

  plinss: That's the agenda for today. We should pull something from
          tomorrow.
  [general mentions of brackets]
  ArronEi: The test suite?
  TabAtkins: We're talking about 3.1 Who put the 2.2 test suite?

Test Suites
===========

  <astearns> https://wiki.csswg.org/test/css2.1
  Bert: I put 2.2 up. We talked about publishing an updated 2.1 with
        the errata and we decided we couldn't because we don't have
        a test suite.
  Bert: Each errata needed one or more tests and there were people
        supposed to write them.

  [crickets... literally thanks to rossen]

  astearns: There's assignments, but nothing indicates if it's done.
  TabAtkins: There's reviews of changes, but not of tests.
  TabAtkins: ArronEi is on most of the lines.
  ArronEi: I was surprised.
  ArronEi: I can look at my stuff, but it won't be for a couple of
           weeks. Maybe next conference call.
  ArronEi: If I'm starting, I can look at them all and give an
           update on all of them.

  ArronEi: The other thing is about the current test suites for
           everything in CR. I'm starting to put together a detailed
           document on how to approach testing since its been ad hoc.
  * astearns dismally ad-hoc
  ArronEi: I want to direct the testing a bit more so we know how to
           approach various tasks. I'm putting that together to get
           done in the next few weeks so we can attack specs in the
           same way. I'm going to test my documentation by testing
           it against whatever spec needs the most done.

  ArronEi: Which one is the highest priority?
  fantasai: Backgrounds and borders is almost done. It needs someone
            to pull it together.
  ArronEi: That's my question. I'll create my process document based
           on that and test my theories. After that's tested and can
           move forward I'll hand it over.

  florian: When it comes to writing tests from scratch, we also have
           the case of the existing mountains of un-reviewed tests.
  ArronEi: I'm going to have the review and updating of those. I
           know there's a lot from backgrounds and borders that are
           coming from a lot of places.
  florian: Opera has large amounts of probably good tests, but they
           need updates.
  ArronEi: I'll make sure I cover something on who to contact to ask
           for tests.

  fantasai: Backgrounds and borders needs triage. There's a bug on
            that.
  ArronEi: I don't want to create new tests until I have everything
           documented.
  ArronEi: This isn't the case for all specs.
  fantasai: Pretty much anything implemented has a bunch of tests.
  ArronEi: I'm trying to catch all the pieces. I'll focus on
           backgrounds and borders and put links on the wiki.
           Hopefully in the next month or so we'll have a process we
           can hand to other people.

  plinss: That's it on testing?
  ArronEi: That's all I have.
  plinss: Anything else from tomorrow?
  plinss: the ::role() proposal?
  smfr: I think that was James Craig.
  TabAtkins: I think it should have been and it was testing of aria
             roles? Let's get him in here for that one.
  plinss: So are we done for the day?
  plinss: I think we're done.

  [End of Day]

Dael Jackson | 18 Dec 02:43 2014
Picon

[CSSWG] Minutes Santa Clara F2F 2014-10-27 Part III: Shrink-to-fit, Sizing

Shrink-to-fit
-------------

  - There was no agreement on the best behavior to create
      interoperability for layout.  Everyone seemed to like their
      own approach.
  - Several people were tasked with writing e-mails to the list
      describing their float layout for intrinsic sizes in order to
      try and create an agreement for how the sizing approximation
      works and then spec that.

Sizing
------

  - No one had a perfect solution for how to resolve intrinsic sizes
      of non-replaced blocks when the width isn't definite.
  - Assuming the value is 0 was raised and garnered some interest,
      but there was a desire to ensure that the description is
      correct.
  - The interested parties will work together offline for a solution.

===== FULL MINUTES BELOW ======

  Scribe: dael

Shrink-to-fit
-------------

  plinss: Let's get started.
  glazou: Is fantasai around for sizing?
  dbaron: Can someone text her?
  plinss: Who put this on the wiki?
  TabAtkins: I assume fantasai.
  plinss: Let's skip to inline-box?

  <gregwhitworth> http://jsfiddle.net/xzt063uv/2/
  gregwhitworth: IE does layouts and we want to get interoperability.
                 We want to figure out a way to do it without
                 layout, but we often get live sites that don't
                 render correctly. We'd like some feedback from
                 others who don't want to change their system.

  <dbaron> https://lists.w3.org/Archives/Member/w3c-css-wg/2006AprJun/0170.html
  dbaron: I managed to dig up last time we discussed this issue.
  dbaron: In the above minutes.
  dbaron: We didn't have a conclusion then.
  dbaron: A bunch of us have made architectural decisions that we
          don't do layout for this. We don't have major
          compatibility issues. It would be nice to have and
          agreement on what the rules are.
  dbaron: Gecko code and webkit/blink code is somewhat different and
          I don't think coming to an agreement between those is hard
          and I think it would be web compatible.
  gregwhitworth: I agree. We have a lot of problems with what we do.
                 I think a lot of people don't test us. We don't
                 want to switch because people layout the same until
                 shrink to fit.
  dbaron: That's not ignoring the spec. It doesn't define behavior.

  gregwhitworth: At the end of the day we just want websites to work.
                 We could say match us, but technically you're right
                 that when you push down isn't defined. As an author
                 I would expect the same layout and shrunk.
  dbaron: There's no laying out.
  gregwhitworth: They literally...if you look at the layouts
                 personally I think they should be the same.
  dbaron: Prior to 2006 or so we did it, but we stopped because it
          had tons of bugs and was slow. We decided webkit was
          surviving with doing what it was doing so that was
          compatible for web content.

  gregwhitworth: Let me track down the thread. I think it was
                 someone from Opera who said Presto is doing it
                 differently.
  florian: I think that was morten on the list.

  gregwhitworth: We don't have huge performance issues. I think most
                 authors would expect our behavior. What's the
                 working group's consensus? I don't want it to
                 stagnate because we have a few bugs.

  SimonSapin: What does it mean to do layouts...it depends on how
              much width is available, but we don't always have that
              information.
  dbaron: In the old days, all the layout code had a mode where you
          could execute that code with a value for available width.
          It would then place everything as if there was no width
          constraint. We would place floats along those lines.
  Rossen: When we run in unconstrained width we really run it
          unconstrained. Obviously you can't resolve percentage
          because they're meaningless.
  SimonSapin: What do you do with percentages?
  Rossen: You can backwards resolve or resolve against a computed
          shrink to fit size.
  dbaron: The what do you do with x, the answers are always what are
          you doing when computing intrinsic widths. They just use
          the layout code to do that instead of separate code.
  Rossen: So there's pretty much no difference in the two codes.

  gregwhitworth: It feels like again we all like our thing. I'm
                 looking for a just deal with it.
  dbaron: The algorithm I wrote was for the approximation stuff.
  dbaron: I would vastly prefer not to go back down the trying to do
          layout path. I think IE is the only major engine doing that

  gregwhitworth: Putting aside interoperability and implementation
                 details, do you not find it odd as an author that
                 the layout is completely different?
  dbaron: It's no different than if the absolute element had the
          same width. The only difference is the width for the
          abspos element. Yes it is a little weird but...
  gregwhitworth: I don't know where else to take this. If everyone
                 else is holding fast.

  Bert: One other thing. I'd like to have for things like tables and
        grid layout, you do layout where the width you want is the
        one that minimizes the height, that gives you most compact
        tables as possible.
  Bert: Maybe there should be a switch somewhere to use a different
        algorithm and then you really search for the smallest way to
        pack the content.
  Bert: Smallest in this case is smallest height
  Rossen: So that's your max content. It's shrink to fit.
  Bert: It's more complex than the basic approximation like two
        floats could fit together. You may have to do the layout
        multiple times. I've seen it done and you get beautiful
        tables. You may need a fast computer if you want it
        interactive.
  Bert: I don't know how it works with animation. I guess you turn
        it off. It's something to keep in mind and it may be a
        future way. For print especially you can get better layouts.

  Rossen: So, dbaron, you mentioned performance as an issue.
  dbaron: A lot of the gains came from how we do invalidation. We
          didn't permanently maintain the layout data so we would
          have to redo layout. I'm guessing you don't have that
          problem?
  Rossen: No.
  Rossen: In our case we have ways of reusing that data when we
          identify that it will be the same result so you only do
          the necessary overrides.

  gregwhitworth: Again, I point to the example where there's room in
                 the container for that stuff to fit. In the test
                 case your constraint is the viewport. It shouldn't
                 be pushed because technically there's room to fit.
  gregwhitworth: I'm leery to say match when it's a different result.
  Rossen: Given the content that's out there, does it make sense to
          have a higher quality of implementation? So the user
          expectation will match regular layout more? Or is this an
          edge case enough so we would go and change how we behave.
  gregwhitworth: I'd say 50/50.
  Rossen: I've seen bugs that argue both. The ones that suck are on
          the outer level of websites that control their layout
          through floats. That's where we have broken layout inside
          shrink to fit layouts.
  Rossen: Hopefully with grid and flexbox they'll move away from
          that practice, but in the meantime we're stuck with broken
          behavior.

  Rossen: One question is, dbaron, is this an idea you guys would
          even entertain, is to do something from approximation or a
          different way to do layout? If it's out of the question
          there's no reason to do this.
  dbaron: I think going back is pretty out of the question. I
          couldn't justify probably at least one person year of
          engineering time when what we have now is web compatible
          and works.

  Rossen: So if this is the case, can we at least spec that?
  dbaron: Spec the way the approximation works? I can do that. At
          one point I think I posted to the list what we do. I'd be
          interested in seeing what webkit does.
  smfr: We do the same as Gecko in this case.
  dbaron: There are some differences. They're subtle, but we
          sometimes get bugs.
  gregwhitworth: So can we action that or...?
  dbaron: I can write up the Gecko behavior.
  gregwhitworth: Anyone willing to write up others?
  TabAtkins: I can try and ping our people that know the details.

  Rossen: So where would we put that?
  gregwhitworth: Sizing?
  Rossen: It could be.
  plinss: Is the current text vague or silent?
  Rossen: It's basically a lot of hand waving.
  Rossen: Okay. I think we're done with that issue.

  ACTION TabAtkins: spec their float layout for intrinsic sizes
  <trackbot> Created ACTION-659
  ACTION dbaron: spec their float layout for intrinsic sizes
  <trackbot> Created ACTION-660

Percentages and Indefinite Sizes
--------------------------------

  TabAtkins: fantasai, did you put sizing on the agenda?
  fantasai: No.
  SimonSapin: I did.

  SimonSapin: In the sizing spec for the intrinsic sizes of
              non-replaced blocks - there are different cases
              depending on if the repeated width is definite or not.
  SimonSapin: If it's not definite...

  dbaron: What does it mean for definite?
  SimonSapin: Fixed length or a percentage that's against
              something definite.
  dbaron: So definite is a length or a percentage that resolves to
          length.
  fantasai: Could be resolving against ICB, but it doesn't have to
            do layout, just drill down.
  florian: Including calc?
  fantasai: If the things being calc are definite.

  SimonSapin: When it's not definite the spec says:
  <SimonSapin> If the computed inline-size of a block-level box is
               min-content, max-content, or a definite size, [...]
               Otherwise, if the computed inline-size of the block
               is fit-content, auto, or fill, its min-content inline-
               size contribution is its min-content inline-size plus
               any inline-axis margin, border, and padding.
  <SimonSapin> http://dev.w3.org/csswg/css-sizing/#block-intrinsic

  dbaron: So you're saying it should say what to do with percentage
          size and padding?
  SimonSapin: Yes.
  dbaron: It should.
  dbaron: I guess different browsers do different things. I believe
          this is a thing where Gecko does it different than other
          browsers.
  SimonSapin: I haven't tested.

  <dbaron> http://dbaron.org/css/intrinsic/#mbp-adjust
  dbaron: I wrote the above when trying to write this up.
  dbaron: I did write a definition that inverted the percentage in
          padding and margin. I believe Gecko does that, but not
          other browsers.
  Rossen: We don't for sure.
  dbaron: Gecko not for width, but padding and margin.
  SimonSapin: For some reason I thought the answer was treat
              percentage as 0.
  Rossen: That's what I do.
  fantasai: Maybe that was just in grid layout.
  Rossen: That would make sense.

  dbaron: The other interesting thing is that it does that for
          preferred width, but treats it as 0 for minimum.
  SimonSapin: Is there a reason?
  dbaron: Web compatibility. The reason for 0 as min content. The
          preferred width is because it works better.
  Rossen: I'd be surprised if webkit's did that. We don't.

  dbaron: The compatibility was the min-width. I guess I'm okay with
          dropping inversion if that's what everyone else does.
  fantasai: If it gives clearly better results, might be worth
            considering.
  dbaron: I'm okay with doing 0. I think everyone else has been
          doing that for a while.

  plinss: Is that specified?
  dbaron: No.
  plinss: So add it to sizing?
  fantasai: I think 0 makes sense if it ends up being 0. If you
            calculate assuming 0 and then calculate percentage
            against that size we have a problem.
  dbaron: And that exists in all the other browsers.
  fantasai: If we're making it 0 or intrinsic size we should make it
            0 for everything.

  gregwhitworth: That's the argument we just made with floats.
  dbaron: The other thing is hopefully people will be using floats
          for layout less over time.
  fantasai: And intrinsic sizing goes into everything.
  fantasai: If you special case floats, it doesn't make sense.
  dbaron: Floats are the only concept in CSS 2.1 that requires you
          to do layout to compute an intrinsic size.
  dbaron: They're the only place where you need height info to
          determine intrinsic widths. What Microsoft wants to do you
          need to know the height of every float to calculate the
          intrinsic width to layout. You're doing layout of lines.
  dbaron: To determine if two floats are next to each other you need
          to know the height of each line. It adds a lot of
          information to be able to calculate without a lot of value.

  fantasai: So if we're assuming 0 for intrinsic size, we should
            assume 0 for layout.
  dbaron: I'd argue that because layout is interoperable.

  Rossen: So you're okay with dropping to 0?
  dbaron: Yeah. I mean, everyone else is doing it.
  fantasai: So your ideal would be the opposite of Microsoft? So
            floats are extra complex, but lets do it for all these
            other things because it makes sense. And Microsoft
            argues the opposite that we want to do this for floats,
            but everything else is 0.
  Rossen: Percentages are funky when you backwards resolve so if you
          have many table cells that are percentage in width,
          backwards resolving most of the time is unreasonable.
  dbaron: Tables do resolve backwards, but only for table layout,
          that's interoperable. But we're not talking about table
          layout right now.

  SimonSapin: I don't know how much of an argument this is, but the
              way Servo does layout, we can't have any results from
              layouts for intrinsic width. We compute them all
              before we start layout for the heights.
  fantasai: I think Servo needs to change its architecture.
  Rossen: I don't think...I can probably come up with grid layout
          scenarios that would have a similar dependency. Rows that
          are fragment dependent. Vertical text is another one.
  Rossen: I'm not sure how we got to that discussion.
  gregwhitworth: Because the resolution is what I was trying to
                 argue so I hijacked it.

  plinss: I'm not sure if I'm hearing consensus.
  dbaron: One other point. The argument for wanting to try and do
          this the right way and invert the percentages is kind of
          weak because it's only web compat in 1/3 of the cases. We
          can look at width padding and margin. For web compat we
          can only do it for margin and padding.
  fantasai: This is block layout?
  dbaron: Yes.
  fantasai: It may be we have to cut our losses for this and do it
            correctly for grid and flexbox.
  plinss: So have a layout mode that authors can opt-into?
  dbaron: I'd be happier about trying to do it the right way in
          layout modes then adding mode switches.
  fantasai: I think that's probably fine. Block layout is really
            about stuff in the flow. Fancy sizing isn't its forte.

  plinss: Will you get prettier answers the other way, for example
          like ebooks?
  fantasai: I definitely want to look into trying to figure it out
            for flexbox and grid.
  dbaron: I'm not sure I'm comfortable changing flexbox that much at
          this point.
  fantasai: They should be consistent.
  dbaron: The last substantiative change to flexbox had a lot of
          problems.
  fantasai: Is that flex-basis? The resolution was "let's change the
            spec to this and get feedback" and then it was suddenly
            implemented.
  fantasai: That was also syntactic, not a layout issue.

  dbaron: So are we leaning toward we want these all 0 for block and
          try to do the inverting for new layout modes?
  fantasai: Makes sense.
  Rossen: I wouldn't change flex at this point.
  dbaron: Then we get to argue about what's new and what's old.
  Rossen: They're both old for us.

  TabAtkins: Given the problems table layouts had when we wanted to
             add new functions, like we can't do min/max. You
             objected on tables. You had to do a piece-wise linear
             function.
  dbaron: We should investigate that, yes.

  plinss: So what's the resolution?
  fantasai: I'd like it if you said "make my box as wide as it need
            to be to not wrap", you get that.
  Rossen: In all cases?
  fantasai: Ideally yes. If we can't because compatibility then we
            have a problem. I think we should honor the request to
            not wrap. And if the internet is dumb and we can't do it
            in some cases, then we can't, but if we can do it we
            should try and do it.

  plinss: So again...do we have a resolution, do we need to
          investigate more?
  fantasai: I don't know. I think we should stick four of us in a
            room with a whiteboard and the sizing spec.
  Bert: What FF does looks better than what Safari does. FF
        currently calculates that if you want everything on one line
        you get everything on one line. It really looks better. I'm
        trying to see about others. Prince puts you on one line but
        makes it bigger than it needs to be.
  Bert: So I'd rather not make it 0.

  plinss: So cage-match tonight with a whiteboard?
  dbaron: Do we have a whiteboard?
  plinss: We can ask.
  <fantasai> The meeting room is non-conformant wrt CSSWG meeting
             room specs...

  <fantasai> ACTION fantasai: Put IE's nearest-scrollable-box
             behavior into orthogonal flows spec
  <trackbot> Created ACTION-661

  plinss: So we'll loop back tomorrow? Folks will work this out
          offline?
  Rossen: Sure.

  SimonSapin: My understanding of intrinsic sizing is that it's
              intrinsic and doesn't depend on the context around it.
  SimonSapin: When we have a writing mode it isn't how intrinsic
              sizing is supposed to work. In particular the
              intrinsic block size.

  Rossen: What we do, basically the obvious pitfall is we say it's
          shrink to fit, assuming you do layout for shrink to fit.
          If you, let's assume you have one long line of text. You
          don't want shrink to fit that's one long line of text.
  Rossen: I believe there's text in writing modes that spec if you
          have no height in the orthogonal switch you cap that to
          the viewport. We do nearest scrollable box of viewport.
  Rossen: We discovered with orthogonal flow, the cases are mostly
          having some kind of webpage where you scroll down and find
          an example of vertical text. The idea is you want to be
          able to see that in your screen. You don't want to have to
          scroll both ways. In our implementation we cap the size of
          the vertical orthogonal content to be the min of your
          nearest scrolling ancestor and your viewport.
  Rossen: With that in mind you can go and compute your min and max
          size. You need to define that. Max size can be the layout
          that you would produce when you cap content at the min.
  Rossen: The min of the content would be the cap size, the viewport
          or nearest scrolling.
  Rossen: That's a fairly good result in almost all practical cases.
          I'm pretty sure you're looking to avoid where you have the
          min and max to be one line height.

  SimonSapin: Should sizing describe all of this whenever it talks
              about min/max block content size?
  Rossen: It's a split between writing modes and sizing. I think
          fantasai and I spoke about this, but I would expect it
          defined in one of the two or both specs.
  SimonSapin: Does it make sense to talk about that for things that
              aren't flows?
  fantasai: There's a couple things. If you set the keywords on the
            height you need some kind of result. There's also if you
            support writing modes it's not just the immediate
            orthogonal flow thing, you have to be able to compute
            the content size.
  SimonSapin: Once you're inside the block direction because the
              length direction.

  SteveZ: It seems to me it isn't totally writing modes. In
          principal you could have something else that changes
          direction like if you do rotating with layout. So it
          should be covered as a change in block direction.
  SimonSapin: How is that different?
  SteveZ: It's basically what you get with tabs on the sides.
  fantasai: We're implementing that in terms of writing modes.
  SteveZ: There's no reason to assume writing mode is the only place
          we'd want to change the block direction. Or we can say it
          is.
  fantasai: That's kind of what we landed on.
  fantasai: Unless we want to do 45 degree rotations.
  SteveZ: I think we should decide if it's with the orientation and
          in that case it goes with writing modes, but there's no
          harm in having a reference.
  fantasai: Oh yeah, there isn't.
  SteveZ: There's other things like a sequence of inline images.
          Like in vertical form it lays out and we have the same
          issue.
  Rossen: We had a similar issue with flex with intrinsic size of
          images in vertical flex versus horizontal flex. It's
          arguably the easiest to deal with it in writing modes and
          deal with just this weird case.

  Rossen: So SimonSapin, was your main point to figure out where
          this should go or what the expected behavior is or is
          there anything else we need to define?
  SimonSapin: If this is the behavior, it should be in the sizing
              spec.
  SimonSapin: I'm worried that this would prevent some layout.
  Rossen: Well, maybe.

  SimonSapin: Do you think we can still do parallel layout with
              this case?
  Rossen: Depends on what you would do and the type of inputs you
          would take.
  Rossen: From pure user standpoint, not having this dependency in
          orthogonal flows doesn't make sense. It's just going to
          produce wrong results, unfortunately.

  plinss: Any more on this?


Gmane