W3C home > Mailing lists > Public > www-style@w3.org > August 2012

[CSSWG] Minutes and Resolutions San Diego F2F Mon 2012-08-13 PM I: Syntax, Fragmentation

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 27 Aug 2012 22:13:09 -0700
Message-ID: <503C5365.2070707@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
CSS Syntax Level 3

   Tab presented his draft of CSS Syntax Level 3, which is defines CSS parsing as a
   state machine, and asked for feedback. Some work still necessary before it's ready
   to publish officially as WD.

CSS Fragmentation

   - RESOLVED: Accept fantasai's edits for the breaking/painting rules.

   - RESOLVED: Accept the spec's mapping of page-break-* to break-* as a
               shorthand as the means of aliasing the two properties.

   - RESOLVED: Breaks seek the nearest matching fragmentainer, and break
               everything between.  If there is no match, no break occurs.

   - RESOLVED: Add "any" and "all" to break-* to break through nearest and
               all fragmentation contexts respectively; Research what to do
               for "always".

   - Discussed float placement rules for layout into varying-measure pages.

====== Full minutes below ======

CSS Syntax Level 3
Scribe: fantasai

   Tab: I was thinking about asking for FPWD, but think it's not quite
        ready yet
   Tab: The purpose of bringing up here is to explain reasoning between
        having syntax draft
   Tab: and get objections / feedback up front rather than later
   Tab: CSS grammar is hard to work with a complicated grammar scheme,
        especially one that tries to be total -- to handle all possible
        byte streams
   Tab: There are some things that are officially undefined
   Tab: Even some cases defined, there are corner cases that are handled
        differently by different browsers
   Tab: What I've done instead, instead of using a grammar, is to define
        in terms of a state machine parser
   Tab: Broken up into 2 steps like HTML parsing algo
   Tab: Fist step is tokenizer, other is parser
   Tab: resulting in a CSS OM
   Tab: Goal is to make everything extremely well-defined
   Tab: Also make it easy to modify,
   Tab: And easy to read and understand

   Tab asks dbaron for feedback
   dbaron: Some of it, I just don't quite understand what states your
           state machine goes through in the parser
   dbaron: Not so worried about tokenizer side
   Tab: There's a top-level state, and then 3 substates: at-rule, selector, ..
   Tab: at-rule mode or selector mode, depending on what is seen
   <glazou> http://dev.w3.org/csswg/css3-syntax/#top-level-mode-
   Tab: parser very easy to write, took me about a day. Tokenizer took
        about a week
   dbaron: Part of what worries me is that
   dbaron: defining correct error recovery with this parser spec
   dbaron: we have a bunch of abstract error-recovery rules, we know
           exactly what they mean
   dbaron: With this spec, seems easy to get the error-recovery rules
           wrong in the spec
   Tab: Differing implementations of those rules
   dbaron: Because easy to make mistakes in the implementation
   dbaron: Also some rules are well-understood in CSSWG, but poorly
           explained in spec, so we have a clear definition, but others
           can't interpret one so easily
   dbaron gives an example of matching curly braces
   dbaron: If you describe that as an abstract rule, you describe it and
           you're done
   dbaron: If you do it as a state machine, you need to fall into that
           out of many different states
   Tab explains how he handles it in the spec
   Tab: I think I've handled that correctly
   Florian: Even if you do it right now, wouldn't what dbaron says mean
            we might easily make mistakes in future extensions?
   Tab: I think I've defined it in away that you get it for free
   dbaron talks about a stack of stacks
   dbaron: Outer stack for each error recovery point, inner stack for the
           ({[ that you have to match to get back to it
   Tab: Initial concept is stacks, where you can enter an error
   Tab: Once you enter an error state, it knows how to consume to where
        it needs to be. Consumes a block is part of that, no further
        error handling there
   dbaron: We should probably sit down together some other time

   Tab: There are some minor changes to the grammar, discussed by the group
   Tab: Including the plus-or-minus sign direction in the definition of
        NUMBER token
   Tab: Group resolved to include that already
   Tab: A few other places with corner cases or inconsistencies. Need to
        list them
   Florian: Didn't you discuss at some point not accepting comments
            between ! and important?
   Tab: One issue that makes parser hard to handle right now... gives
        parser infinite lookahead
   Tab: Appears we need to retain comments in token stream
   Tab: Then you can have unlimited number of tokens between ! and important
   Tab: !/*comment*/ /*... */ /*...*/important
   Tab: ...
   dbaron: I don't see what you mean here.
   dbaron: why is this lookahead?
   dbaron: You get a !
   dbaron: you go into "parsing !important" path
   dbaron: Either you get identifier "important"
   dbaron: Or you get something else, in which case you go into error condition
   Tab: Issue is, it's not always an error
   Tab: could have it in a variable
   dbaron: Think we should change it so ! can't show up in a variable
   Tab: ! would be counted as a delim, which is a valid part of a variable
   dbaron: Don't think saying you can't have a ! in variable prevents [that]
   Tab: Then I'd have to be more explicit in the grammar
   Tab: Before, just match value production, and everything worked
   Florian: Do people put comments between '!' and 'important'?
   glazou: You should check
   Bert: I don't think we need to check, there's no reason to change it

   Tab: Plan to ask FPWD within next 2-3 weeks
   Tab: Please bring up objections on the list beforehand
   Bert: Would like the grammar normative, not the state machine
   Tab: I would like the opposite
   Tab: If the grammar doesn't cover every possible input stream, then
        it's not well-defined error recovery
   Bert: I don't care about those
   jdaggett: Why not?
   jdaggett: There are many features of CSS that are implemented only
             within more recent versions of a browser, they are handled
             as errors by older browsers
   Bert: But all of those are within the core grammar
   Bert: original model was only to define correct style sheets, slowly
         been adding more rules to handle errors
   Tab: I care that we define all error-handling
   Florian: And all interpret them the same way
   Florian: For HTML parsing, having common CSS handling has been important
            to get interop
   Florian: Think the situation is not as bad for CSS
   Florian: I'm tempted to go this way, though I don't think we need it
            as badly as HTML
   Tab: We have inconsistent/poorly-explained rules for handling e.g.
        braces in unexpected places. Want to make this obvious and clear.
   Tab: Can implement as not a state machine
   Tab: as long as results match
   Bert: Can't, if it's a state machine have to parse in start-to-end order
   Bert: Proving this one is the same as the CSS2.1 grammar is going to
         be hard
   Tab: Plan to throw lots of tests at it
   Bert: We need to prove the spec, not the implementations here
   Bert: Looks like a big step backwards to replace one page of nice
         grammar with however many pages of text
   Tab: The one page of nice grammar isn't interpretable by normal people
        without help from the CSSWG
   sylvaing: Implementers prefer this (the state machine)
   Bert: Context-free grammars were meant to replace this kind of thing
   Tab: Context-free is great for things like properties, where once it's
        invalid, you're done
   Tab: But doesn't work so well for general total parsing
   Bert: When adding new features, need to know what is valid per grammar
   Tab: Grammar's are great for higher-level things, not so great for parsing
   ACTION TabAtkins: Fill out Changes from CSS 2.1 Core Grammar section,
          intro etc.
   <trackbot> Created ACTION-492

Case-insensitive/sensitive identifiers

   jdaggett: need to discuss case-insensitivity issue
   fantasai: Don't think it's a parsing issue
   jdaggett: I think some of the arguments made about case-sensitivity
             are wrong
   ACTION: fantasai and jdaggett to discuss case-sensitivity at the break
   <trackbot> Created ACTION-493

CSS Fragmentation
Scribe: TabAtkins

   fantasai: There was a bunch of outstanding edits from Hamburg and in-between.
   fantasai: One was adding recto/verso to the break properties.  That's done.

   fantasai: Another was the "Splitting Boxes at Breaks" section.
   fantasai: We'd decided that if the box is block-level with a specified
   fantasai: I interpreted "specified height" in the resolution as
             "specified length or percentage".
   fantasai: We didn't discuss non-block elements.
   fantasai: I put inline in the "doesn't stretch to the end of the fragment"
   dbaron: Limiting the extra-space rule to length or percentage...
   dbaron: If you have min-content, I think you want it there.
   dbaron: You don't want a break to make height:min-content overflow.

   fantasai: Different issue.  height:min-content will *draw the background*
             in the rest of the fragment, but yeah, it won't consume any of
             the height, so it won't overflow.
   dbaron: That it doesn't consume any of the specified height should apply
           to all types of heights.

   fantasai: The other case we didn't discuss was table-cells, grid cells,
             and flex items.
   fantasai: The reason we decided not to draw the bg was if you were lining
             up your background with the content.
   fantasai: But in the other layout models, flex/grid/etc, you're putting
             things side-by-side.  You want the boxes to end together.
   fantasai: So I think it makes sense for those to draw to the bottom of
             the page.
   szilles: I'm hearing use-cases for both solutions.
   szilles: So you'll probably want a property for this later.
   szilles: So it seems simpler to just pick a single answer for all of these
            for now, even if it's suboptimal for some, and address it later
            with an explicit property, rather than choosing different answers
            for lots of different things.
   fantasai: I would almost rather have none of them gap, than all of them gap.
   szilles: Yeah, sure.  I just think people will be more confused by having
            to deal with an 'auto' value that chooses things "intelligently"
            than having a single answer that's not always correct by default.
   fantasai: [shows some ascii diagrams of the behavior we ended up deciding
              on for slice/clone for blocks

   fantasai: So, do we accept the edits?
   fantasai: Basically what I have is that anything that's not a block
             *always* does the behavior where it extends to the bottom.
   szilles: Right, I think everything should use the top or bottom behavior.
   fantasai: [explains the ascii examples more thoroughly]
   RESOLVED: Accept fantasai's edits for the breaking/painting rules.

   fantasai: Next is how to deal with the page-break-before/break-before
   fantasai: Florian's idea was to treat the page-break-before property
             as a shorthand for the break-before property.
   fantasai: All the values map to themselves, except
             page-break-before:always maps to break-before:page.
   florian: The only issue is that the 'item()' function on CSSStyleDeclaration,
            it expands shorthands and only has the longhands.  So, you
            lose the 'page-break-*' versions here.  But doing it any other
            way turns out to be a lot of work for very little gain.
   florian: So I consider this suggestion the best possible rule.
   fantasai: [explains why page-break-before:avoid should map to
              break-before:avoid, rather than break-before:avoid-page]
   <fantasai> Murakami-san explains why avoid should map avoid and not
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Aug/0351.html
   vhardy: Okay. It just seems like we're losing the kind of break.
   fantasai: Sure, but this is just a legacy thing.  You can get all the
             breaks you want by using the correct property name.
   RESOLVED: Accept the spec's mapping of page-break-* to break-* as a

   fantasai: Alan brought up the issue that if I request a column break,
             but I'm not in a column context, but I *am* paginated,
             should I get a page break instead?
   fantasai: That makes sense to me.
   fantasai: The test says that when a forced break occurs, it finds the
             nearest fragmentainer of the correct type, breaking through any
             intervening fragmentainers.
   fantasai: Going all the way to the root if necessary.
   * sylvaing this all sounds like throwing exceptions...
   fantasai: The alternative would be to define column breaks to also act
             like page breaks otherwise.
   fantasai: The difference is how the two interact with regions, and
             future fragmentainers.
   dbaron: So if there's no matching fragmentainer context, it just breaks
   dbaron: My intuition would be that nothing breaks if there's no
           matching fragmentation context.
   dbaron: The other option is that we have a ranked ordering of break types.
   fantasai: Or setting an explicit equivalency.
   szilles: I think the "find the nearest fragmentainer" was a positive change.
   TabAtkins: fantasai, can you justify why you want a column break,
              if you request a page break and are not paginated?
   fantasai: Because you want the broken thing to be at the top of *something*.
             If you can't be at the top of a page, being at the top of a
             column is the next-best thing.
   plinss: Looking at OpenOffice (and maybe Word), column breaks don't
           turn into page breaks in a single-col situation.
   fantasai: I think the way to get the text you guys want is...
   fantasai: If a column break is requested, it'll be satisfied by a page
             break, but not the other way around.
   [some confusing discussion, conclusion was still the "find nearest
    matching fragmentainer, if there isn't one then no-op"]
   Rossen: Somewhat farfetched, but if you had nesting of different frag
           types, like columns inside of regions.
   Rossen: And you have content that wants to break at some point inside
           the region...  You can do this kind of handshake between stacks.
   Rossen: And if there's nothing, it doesn't break.
   fantasai: Okay, sounds like a clear resolution.
   RESOLVED: Breaks seek the nearest matching fragmentainer, and break
             everything between.  If there is no match, no break occurs.

   fantasai: Next, there are two interpretations of "always": break the
             nearest fragmentainer, or break everything.
   sylvaing: "all-the-things" for all of them?
   Bert: Not sure if we need the "break everything" one.
   dbaron: I like "any" and "all".
   TabAtkins: What does "always" do, then?
   dbaron: I thought "always" was only for page-break-*.
   dbaron: Do we need break-*:always?
   fantasai: multicol has "always" in it.
   TabAtkins: So let's get some testing to see what impls actually do for
              "break-before: always", and if we can drop it.
   RESOLVED: Add "any" and "all" to break-*, research what to do for "always".

   plinss: any objections to publishing a new WD with these edits?
   RESOLVED: Publish a new WD of Break, after the edits resolved on during
             this session.

   * hober thinks we need a 'break-*: dance' value
   <dbaron> break: glass ! in case of emergency;
   ACTION fantasai: define root fragmenting element
   <trackbot> Created ACTION-494
   <sylvaing> fragmentainer? is that a thing now?
   <stearns> sylvaing: yes, it's a thing (unless you have a better name)

   fantasai: Whoops, remaining issue is about broken floats - should they
             stay next to each other or not if the second page is narrower
             than the first?
   fantasai: Option A is to try and shrink the floats to keep them side-by-side.
             If they can't be shrunk enough, they just overflow.
   fantasai: Option B is to use the normal float collision algorithm on
             the fragments, so that one may move below the other.
   szilles: I prefer B for the simpler behavior - it's the same as normal
            float behavior.
   dbaron: I don't understand how you get the option A behavior.
   dbaron: auto-width floats depend on the width of their containing block
           and their contents, not surrounding floats.
   dbaron: So what makes floats get narrower in this case?
   fantasai: This very overconstrained situation.
   Rossen: But that changes the behavior of floats.
   fantasai: So people seem to prefer B?
   Rossen: [outlines why it makes sense to do option B for varying-width
   florian: I think you're saying that percentage-width floats change
            their size in the next page?
   szilles: Yes, that's already in the spec.
   dbaron: One thing the float placement rules say is that, if you wanna
           place a new float, you must ensure that its top is below the
           top of any other floats.
   dbaron: So here you get into interesting issues where you have a bunch
           of existing floats...
   dbaron: So if you're in the situation in the option B diagram...
   dbaron: If a narrow float is anchored in the little bit of text above
           the right float piece, does it sit there?  Can it push the
           right float down?
   TabAtkins: I think all the float pieces should be considered as
              originating at the start of the page, so any floats anchored
              in the page normally are "after" them, and thus are subject
              to normal float placement rules.
   dbaron: I think I agree.  I'm curious if I implemented that.
   dbaron: So I think we need to amend the float placement rules, either
           here or in the float spec, to make sure this is specified.
   Rossen: I think this might already be included.  We can refer to them
           and extend if there's something missing here.
   Tab: In this case, on the second page here
   Tab: You have a page-break-before the word float on the second line
   Tab: And the next page is extra-wide, what happens there?
   dbaron: More interesting question, what about a new float?
           ... unplaced continuations
   <dbaron> We need to decide if the pushing down the unplaced float
            happens only for unplaced floats that can go on the current
            page, or for breaks that have been forced to the next page.

   fantasai: If you had a break in the left float, wouldn't that make
             the left float go all the way to the bottom?
   fantasai: Would this depend on the gap/no-gap behavior difference?
   fantasai: I think we need it to continue to the bottom of the page
             by default, because of floats used for columns.
   <fantasai> side discussion of whether forced breaks in floats should
              affect surrounding contents: no they should not
   plinss: If I have an auto-width float, and it breaks across pages,
           will it have the same width across pages?
   fantasai: depends on whether it landed on min-content/max-content or
             on fill-available in the shrink-to-fit expression
   fantasai: if it lands on fill-available, it will vary
   fantasai: But if it landed on min/max-content, then it sticks with
             that for all the fragments, and is constant.
   <fantasai> [that's not exactly true; depends on whether it recalculates
              to fill-available at some point. But min/max-content are
              not recalculated per fragment]
   dbaron: min-content and max-content should always measure across all
           the fragments
   RESOLVED: Use Option B (float fragments are placed as if they're new
             independent floats).
   dbaron: I think we need someone to propose an adjustment for the float
           placement rules.
   dbaron: So that when you move from a wider to a narrower, you may not
           be able to place all of the fragments on the same line.
   dbaron: You consider the top of the float fragment, not the float itself,
           when placing on the new page.  But maybe you don't consider the
           top of the fragment when you place on a third page?
   szilles: If there are floats continued from previous fragmentainers,
            process the floats in the order they were originally declared,
            then the content.
   florian: Problem is if there's a small float in the content, does it
            get pushed to the next page as well if one of the fragments
            breaks again?
   florian: I think we agreed to push it.
   <SteveZ> The principle that I was trying to propose was that layout of
            a fragmentainer is done using the normal layout rules (including
            the rules for float collision avoidance) on the content coming
            into that fragmentainer.
   ACTION fantasai write a proposal for how to modify the float placement
          rules for the presence of fragmentation -- in particular, saying
          that the continued fragments of floats continued from the previous
          (or earlier) fragment are placed in the current fragment in the
          original order, and figuring out whether it's allowed to place
          the top of a float (a) when there's a continued float that could
          be placed in the current fragment but hasn't been placed yet
          [consensus leaning towards yes] and (b) when there's a continued
          float that needs to be placed in the next fragment (e.g., because
          of a forced break) [no consensus yet]
   <SteveZ> The content coming into the fragmentainer consists of the normal
            flow, the fragment of any floats that were fragmented in the
            order in which they were originally called out.
   <SteveZ> Then, the float fragments are placed first, using the normal
            float rules and then the normal content is placed and any
            floats called out in this normal content will be place after
            the floats carried into this fragmentainer.

   <dbaron> fantasai, does the fragmentation spec say how to place
            absolutely positioned elements (esp. those that use
            static-position or those that are relative-to-bottom)?

<br duration=15m>
Received on Tuesday, 28 August 2012 05:13:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:50:26 UTC