[CSSWG] Minutes Sophia-Antipolis F2F 2014-09-08 Part I: CSS3 Text, Display Module, Backgrounds


  - This discussion to set the agenda held no technical details.

CSS3 Text

  - RESOLVED: Make control characters visible. (This will be
    consistent with Unicode, but will break backwards-compatibility
    on the Web.)
  - RESOLVED: Text shaping MUST be broken across inline element
    boundaries when:
                A. one of margin/border/padding are non-zero
                B. vertical-align is not 'baseline'
                C. it is a bidi isolation boundary
              Text shaping MUST NOT be broken across inline element
              boundaries when there is no change in formatting.
              Text shaping SHOULD NOT be broken across inline
              element boundaries otherwise, if it is reasonable and
              possible for that case given the limitations of the
              font technology.
  - RESOLVED: No change for issue 59

Display Module

  - Plan to defer longhands of 'display' to the next level;
    this will allow restricting combinations of 'display-inside' and
    'display-outside' that are difficult to implement at this time.

  - Discussed open issues with 'box-suppress', including details that
    need to be defined for the 'hide' value and how this interacts
    with 'visibility' and 'speak'. This section needs more work.


  - RESOLVED: Accepted Bert's proposed wording for CSS2.1 erratum
              on interaction of 'display: none' and the root background.


  Glenn Adams
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Dave Cramer
  Elika Etemad
  Daniel Glazman
  Koji Ishii (Skype)
  Ian Kilpatrick
  Philippe Le H├ęgaret
  Chris Lilley
  Peter Linss
  Edward O'Connor
  Simon Pieters
  Florian Rivoal
  Andrey Rybka
  Simon Sapin
  Dirk Schulze
  Alan Stearns
  Shane Stephens
  Greg Whitworth
  Kazutaka Yamamoto

  Scribe: fantasai


  This discussion to set the agenda held no technical details.

CSS3 Text

  <fantasai> http://dev.w3.org/csswg/css-text-3/issues-lc-2013
  <fantasai> http://dev.w3.org/csswg/css-text-3/issues-lc-2013#issue-72

  fantasai: We're waiting for MSFT to get back to us on whether we
            want to make the change.
  Rossen: We're still waiting to hear on one of the dependency teams
          we have at Uniscribe/DWrite
  Rossen: From our POV, shouldn't be a problem.
  Rossen: Compatibility cost shouldn't be a problem, to basically
          implement the feature.
  Rossen: So as of now, tentative OK, unless we hear otherwise from
          the teams that are lower on the stack.
  fantasai: So we'll take that, make the edits, and you can come
            back with "Stop the Presses!" if needed?
  Rossen: Yep.
  fantasai: So, resolved to make control characters visible?

  RESOLVED: Make control characters visible
  <fantasai> koji and fantasai will make edits

  <Clilley> presumably not CR and LF?
  <Clilley> ok, 80 to 96 ones
  <fantasai> (Unicode category Cc)
  <Clilley> ty

  <fantasai> http://dev.w3.org/csswg/css-text-3/issues-lc-2013#issue-70
  <fantasai> http://dev.w3.org/csswg/css-text-3/issues-lc-2013#issue-79
  <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Aug/0217.html
  <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Aug/0295.html

  fantasai: Issue 70 and 79 have the same proposal
  fantasai: We got a request to clarify when inline joining happens
            across an inline boundary and when it doesn't.
  fantasai: There's basically 3 cases:
  fantasai: MUST NOT break shaping (no style change, no excuse to
  fantasai: MUST break shaping
  fantasai: RECOMMEND to not break, but depends on font tech

  dbaron: Seems like number two is two different cases, e.g. no
          reasonable way to render an fi ligature with one from one
          font and one from other is clearly nonsensical,
  dbaron: but Arabic shaping is doable.
  fantasai: There's cases in the middle that are less clear, e.g.
            Indic shaping, which can be done by ligatures,
            contextual forms, etc.
  fantasai: So while we can say clearly for the fi ligature that
            it's not possible, and for Arabic forms you can force
            shapes by using ZWJ/ZWNJ at the edge of runs so that's
            always technically possible, a lot of things in between
            we can't say for sure, it depends on exact case.
            [Therefore didn't want to split hairs.]
  fantasai: Are people ok with splitting into 1-3?
  dbaron: Yes, but unsure if SHOULD should be that strong.
  dbaron: It seems odd to say, e.g., that implementations SHOULD NOT
          break shaping across changes in font-size.
  TabAtkins: I want to have more than a may.
  TabAtkins: "Totally should, probably can't"
  TabAtkins: Totally should avoid breaking Arabic, but probably
             can't avoid breaking ligatures

  fantasai: Cases which are 3,
  fantasai: Proposed to have 3 cases:
            A. one of margin/border/padding are non-zero
            B. vertical-align is not 'baseline'
            C. it is a bidi isolation boundary
  [Seem to have agreement on A]

  fantasai: The second case is is if vertical-align doesn't match
  fantasai: We thought about matching values, but actually, we want
            to say if it's not baseline (not matching parent)
  fantasai: e.g. top and middle won't align baselines anyway.
  TabAtkins: And definitely don't want adjacent superscripts to join.
  [fantasai said something about siblings and parent relationships
            and vert-align not inheriting]

  astearns: Maybe there are cases where we want two top things to
            join if they happen to line up?
  fantasai: I think we want it to be predictable.
  TabAtkins: We know there are cases where we don't want it to join.
  TabAtkins: Also, you can always put them into a common parent and
             vertical-align that, and they will join.

  florian: Any i18n concerns?
  fantasai: There's cases where you have different alignment i18n-
            wise, but that's done with changes in which baseline you
            align to, not by 'vertical-align'.
  [Seem to have agreement on B]

  fantasai: Third case was bidi isolation boundary.
  fantasai: I can't think of a case where you would want joining
            across a bidi isolation boundary,
  fantasai: But this is overloading a bidi control.
  florian, TabAtkins: It doesn't make sense to join across that

  florian, TabAtkins: Not worried about CJK.
  fantasai: Theoretically, CJK can be written cursively.
  fantasai: Do you want to break between Japanese and Chinese words
            in a paragraph? Maybe, maybe not.

  glenn: Language changes might cause switching of font tables.
  florian: That would fall under "Should join" if you can pull it off

  TabAtkins: But definitely it should break on bidi isolation.
  fantasai: Any other comments on bidi isolation and joining?

  fantasai: Unicode defines bidi isolation codes, doesn't define
            them to have any effect on shaping. We probably want to
            ask them about it, too.
  fantasai: So, should we put this in the spec and then ask Unicode
            to comment?
  glenn: Implementors don't connect over level runs.
  dbaron: It might just be direction changes, rather than control
  florian: If you have control characters that keep in the same
  fantasai: The case of 2 embeddings next to each other...
  fantasai: Do those join?
  glenn: They would be the same level... so yes, would join
  florian: ...
  <dbaron> (probably embedding level changes rather than direction
           changes, maybe)
  fantasai: Because embeddings are not fully encapsulated, you can't
            have rule about boundaries because text can shuffle
            around/through that boundary
  fantasai: but for bidi isolation you can, because it fully
            encapsulates its contents.
  dbaron: Gecko does ligaturize across an embedding boundary.
  fantasai: For bidi isolation, you don't shuffle text
            around/through the boundary, and you can detect the
            boundary by just looking for it.
  fantasai: But I'm okay either way on this point.
  <dbaron> http://lists.w3.org/Archives/Public/www-archive/2014Sep/att-0001/lig.html
  <dbaron> was my testcase

  fantasai: As long as we have A and B, most problematic cases
            should be taken care of.
  dbaron: I'm fine with saying join across an isolation boundary
  fantasai: From http://www.unicode.org/reports/tr9/#Shaping "Thus,
            the characters before and after a directional isolate
            will not join across the isolate, even if the isolate is
            empty or overflows the depth limit."
  fantasai: Looks like Unicode already says you don't break across
            isolation, so I think we're good on that.

  <Clilley> if anyone thinks you should not break over an isolation
            boundary they are welcome to write the opentype feature
            that implements it
  <glazou2> it's hard to record a consensus from two opinions...

  RESOLVED: Accept proposal on text shaping breaks
  <fantasai> For C, refer to UAX9

  <dbaron> http://lists.w3.org/Archives/Public/www-archive/2014Sep/att-0001/lig.html
           is about level changes, not isolation boundaries
  <dbaron> ... and only the first example actually has a level
  <dbaron> ... the first should not have a ligature, the second and
          third should be a ligature
  <zcorpan> dbaron -
            blink only does the ligature for <p>fi
  dbaron: There's interesting markup in there, but there isn't text
          inside it
  dbaron: So the text should just ligaturize

  <fantasai> http://dev.w3.org/csswg/css-text-3/issues-lc-2013#issue-59
  <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Aug/0321.html
  fantasai: Issue was, do we add inter-character as equivalent to
            distribute, because people are confused what distribute
  fantasai: Rossen asked to defer to F2F
  koji: Distribute also has a side-effect of changing
  koji: That behavior is probably confusing.
  koji: Inter-character and distribute are different use cases and
        don't want to change
  fantasai: I think you're thinking of inter-ideograph.
  koji: No, distribute causes text-align-last to justify,
        inter-character would be confusing
  florian: So you're saying that distribute implies an extra bit of
  <koji> Yes.
  Bert: Why does it do that?
  fantasai: The use cases that wanted distribute wanted the last
            line to justify, so to avoid having to specify 'text-
            align: justify; text-justify: distribute; text-align-
            last: justify', we made the 'auto' value of text-align-
            last account for distribute
  fantasai: Maybe it would have better to have text-align:
            distribute; and have that just do the right thing... but
            have to think about that more.
  fantasai: We actually have a similar issue with Kashida.
  fantasai: But we can go over that another time.

  RESOVLED: No change

  [round of intros]

Display Module
  Scribe: Bert
  <fantasai> http://dev.w3.org/csswg/css-display-3/

  fantasai: This discussion doesn't affect the next publication, but
            the one after.
  fantasai: We want to limit the number of value combinations.
  TabAtkins: Keep the longhand-combining syntax of the shorthand.
  TabAtkins: Some combinations not very popular with implementers,
             like table cell and flexbox

  fantasai: We publish today without this change. So that it is
  fantasai: We can refer to it when we want to re-add.
  fantasai: But for now we'll simplify for level 3.

  florian: I liked them separate... but well.
  florian: Leave them set to split and mark it at risk?
  fantasai: No, don't want to do that.
  TabAtkins: No, because nobody wants to implement a combination
             like table-cell/flexbox
  TabAtkins: We publish it to keep the history and may want to visit
             again later.
  Rossen: Or call out the combinations that are not supported
  TabAtkins: That's problematic.

  fantasai: We had originally split them out at this level because
            we needed noneness to be a separate control. And if we
            were going to split 'display', we had to split it into
            whatever our final set of longhands would be. But now
            that we've realized noneness needs to be an independent
            control, that is not a longhand of 'display', that
            constraint no longer exists, and we can split 'display'
            later just fine.

  Rossen: We effectively have the split inside/outside internally
  TabAtkins: We don't
  Rossen: I'm partially excited about the possibilities. Better than
          cram everything in one property.
  Rossen: Your proposal might be better, but I haven't seen it.
  fantasai: Danger is that we define now and people use it, that
            will be that and we cannot change anymore.
  fantasai: If we add that as syntactic possibility now, it will be
            forever the same behavior.
  fantasai: So instead we restrict the syntax so that that is not
            possible right now.
  fantasai: Remove things we don't want to support right now by
            restricting syntax.
  fantasai: At some point in the future we want to have all
            combinations, then we can have the longhands.
  Rossen: OK, in favor of publishing as-is and then change as

  TabAtkins: Table internal ones that will not allow a second value.
             Maybe remove display-inside: auto.
  fantasai: [Shows section 2.4 from ED]
  plinss: Confused, can you still [?]
  plinss: flex inside table row?
  TabAtkins: Table row generates a wrapper automatically. No change
             from current.
  fantasai: We want other combinations in the future, but
            syntactically restricting them for now.
  TabAtkins: We proactively want to define some single-value things
             and say also which can be arbitrarily combined.

  <fantasai> http://dev.w3.org/csswg/css-display-3/#box-suppress
  TabAtkins: Also we want feedback on box-suppress naming issues.
  fantasai: Other ideas are welcome.
  florian: Property name and values both?
  TabAtkins: We want just one value that keeps things visible, so
             it's easy to toggle.
  Rossen: I'd expect something like 'box-display'
  SimonSapin: Special case for display:none?
  TabAtkins: Yes, that is explained in the spec.

  dbaron: Is the 'hide' well defined?
  dbaron: It looks like it requires every other feature in CSS not
          to define if it is hide or not.
  dbaron: What is intuitive for some is not so for everybody.
  TabAtkins: Fair point.
  dbaron: Animations don't count as layout?
  TabAtkins: Right, animations themselves don't do layout.
  fantasai: It is only that the timer doesn't stop.
  dbaron: That is not clear. In FF animations stopped. Recently we
          changed it.
  dbaron: Has to do with display:none? That is short.
  dbaron: Hmm, no, boxes go away when display is none.
  TabAtkins: We may need to define it better.

  Rossen: Collapsing?
  TabAtkins: That counts as layout.

  dbaron: Anonymous box construction is important to define.
  dbaron: Hide could be implemented with a new kind of box.
  dbaron: Anonymous boxes are an interesting case.
  TabAtkins: ... An anonymous empty flex...
  TabAtkins: Does hide on a table cell create a table row around it?
  fantasai: Relates to collapsing behavior we talked about earlier,
            visibility: collapse.
  fantasai: We expect same thing to happen for flexbox...
  fantasai: So how does this behave for collapsing? Or *is* this the
            collapsing control?
  fantasai: Outside tables and flex, 'collapse' means 'hidden'
  fantasai: In tables without spanning cells, it does something
            sensible wrt collapsing.
  fantasai: (With spanning cells, it just clips, which is useless.)
  fantasai: Did we define it for flexbox?
  Rossen: And grids?
  <fantasai> I guess box-collapse might be a naming idea.
  <fantasai> or display-collapse

  Clilley: Box-suppress can be used for things that do not use box
           model (such as SVG)?
  TabAtkins: SVG has a box model, it just has not been defined yet...
  Clilley: Is this clear in the spec?
  TabAtkins: No, not clear [that this property applies to SVG]
  fantasai: We can take an action to say it applies to SVG.
  SimonSapin: 'box-suppress' makes sense for SVG. The values can
              have a reasonable interpretation.
  Clilley: Yes, I just wanted to know if it was meant to apply.

  fantasai: Does anybody implement 'visibility: collapse' for flex?
  [several: don't think so]
  fantasai: In that case, we can just restrict it to tables and
            define something new for flex here.
  dbaron: It looks like FF does stuff...
  dbaron: That's not widely used.

  plinss: Or a counter proposal: put this under 'visibility'
  TabAtkins: We still want to support 'display: none'
  Hober: [missed]
  plinss: Adding values to 'visibility' is possible. Like 'suppress'
  fantasai: We need to think about usability. And about the effect
            on speech.
  florian: Visibility is not a great word to use with speech...
  dbaron: Does 'box-suppress: hide' stop speech?
  fantasai: Currently, no.
  TabAtkins: Well, speech is a kind of layout...
  fantasai: Need to discuss the interaction with 'speak'...
  fantasai: Let us know about issues like this!

  fantasai: The display-outside issue with counters-
  TabAtkins: If you hide the box, you also suppress the counter.
  fantasai: We need to work on that.
  dbaron: I think animations continue, but counters stop.
  dbaron: It's a long time since I worked on counters...
  dbaron: Counters need to be updated dynamically.

  [discussion about different implementations of counters...]

  dauwhe: I'm probably the one here who uses counters most, but I
          don't really have an opinion yet...

  * zcorpan wonders what happens with display:contents on svg


  <Bert> http://lists.w3.org/Archives/Public/www-style/2014Jul/0312.html
  Scribe: fantasai

  Bert: We decided we needed an erratum for interaction of body,
        canvas, background, and display: none
  Bert: Decided if there's no box, then the background is
  Bert: I came up with some text for that

  fantasai: works for me
  <glazou2> +1
  dbaron: This is another interesting case for display: contents.
  fantasai: Yes, that's why we changed the text.
  plinss: what about display: contents on the root?
  fantasai: It computes to block

  RESOLVED: accept erratum

Received on Monday, 13 October 2014 20:36:13 UTC