- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 27 Aug 2012 22:13:09 -0700
- 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
height..
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"
category.
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
aliasing.
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
avoid-page:
<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
shorthand.
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
everything?
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
containers]
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