[CSSWG] Minutes Sophia-Antipolis F2F 2014-09-10 Part I: CSS UI, Positioning, Next F2F Dates

CSS UI
------

  - andreyr brought up the request for a last-visible-line-in-block
      ellipsis. More discussion is needed to create a concrete
      understanding of all the related problems and come up with a
      solution.

  - RESOLVED: The number of lines of context visible as the caret is
      moved towards the edge of a scrollable area is a quality of
      implementation issue

  - No change for :focusWithin, can use :has(:focus) instead.

Positioning
-----------

  - andreyr will put together a proposal to update positioning
      to better handle fixed & sticky positioning inside
      overflow:scroll boxes

Next F2F Dates
---------------

  - Due to flight costs, proposed dates are the week of 9 February
      with CSS meeting Monday and Tuesday and meeting with SVG on
      Wednesday.

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

Present:
  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
  Greg Whitworth
  Kazutaka Yamamoto
  Steve Zilles

  Scribe: gregwhitworth

text-overflow : ellipsis-lastline
---------------------------------

  andreyr: Text overflow ellipsis
  andreyr: There's no way to ellipsis a multiline block of text.
           There's an Opera specific -o-ellipsis-lastline that does
           exactly, It should clamp an HTML element by adding
           ellipsis to it if the content inside is too long.
  andreyr: There doesn't seem to be a way to ellipsis multiline of
           text.
  <andreyr> https://github.com/Merri/ellipsis-lastline
  andreyr: One of the versions of opera has ellipsis-lastline.
  andreyr: You might have multiple boxes with wrapping, so it gets
           really complicated.
  andreyr: If you have 10 different rectangles with news info you
           would need ellipsis to show there is more text.
  Rossen: We have discussed block overflow ellipsis. It seems easy
          with just text. If you have tables, flex, images where do
          you ellipse?
  Rossen: When you try to generalize it as a web platform solution
          it becomes very difficult.
  Andreyr: Does it have to be anything beyond text?
  <hober> See also -webkit-line-clamp

  <dbaron> we had a thread at
http://lists.w3.org/Archives/Public/www-style/2013Oct/thread.html#msg624
  dbaron: Someone just needs to come up with a proposal in each case
          and then we can determine whether it is okay.
  dbaron: Authors will figure out how to/not to use it because it is
          in demand.
  rossen: This is one of the number one requests.
  rossen: Then when we start talking about how they're going to use
          the content they tell us they don't have control over the
          content.
  rossen: We ask can we assume that you only have text and the
          answer is normally "No"
  rossen: It's easy to say this on the first level, but when we
          start referring to children with different display types
          and floats this becomes complicated.
  dbaron: The text is normally inside something else, and then
          inside something else.
  rossen: This makes it hard to determine what to truncate.
  rossen: It's not trivial.

  andreyr: Can I get help? TabAtkins and GregWhitworth offered to
           help.
  plh: Rossen, can you put these problem examples together?
  <dbaron> http://wiki.csswg.org/spec/css4-ui#text-overflow-block-hint
  <Rossen_> andreyr: here's a wiki about block ellipsis
            http://wiki.csswg.org/spec/css4-ui#text-overflow-block-hint

  bert: If you have a region but want a continuation mark, not
        ellipsis how do you do this?
  rossen: Isn't this what we discussed in Seoul? Being able to
          control the overflow but also the marker so that you can
          add events and design it?
  rossen: Then having the regular ellipsis inserting the fade
          gradient and how to add eventing?
  andreyr: Hover is very common in this functionality.
  bert: Is this the same mechanism for continuation mark, or is it a
        different one? Can we combine overflow: ellipsis and
        overflow: paged?
  rossen: Yes, that is what we were wanting to have. It has to be
          mutually exclusive.
  rossen: I don't want to have overflow: scroll and ellipse.
  florian: Yes, scroll and ellipsis doesn't make sense but I do
           think of use cases for ellipsis and paged.
  florian: Overflow ellipsis doesn't send the content somewhere else.
  rossen: Sure, we can have overflow: block ellipsis paged, and
          block ellipsis continue.
  rossen: If we figure out block ellipsis we can add this
          functionality.
  bert: We will want to be able to extend it, so let's not design
        ourselves into a corner.
  chrisl: You can have the content in a footnote and have it linked
          up.
  andreyr: We can meet up later to discuss this.

Number of Lines in Content Editable
-----------------------------------

  andreyr: Now to the next issue.
  <andreyr> Ability to control the number of lines of "context" to
            show in a scrollable content editable
  <andreyr> http://bloomberg.github.io/chromium.bb/repros/cursorContext.html
  andreyr: On the example, keep pressing enter, to add the scroll
          bar by going to the bottom of the viewport.
  andreyr: Currently this is working in Safari, Webkit, Firefox and
           IE.
  andreyr: I thought this was a bug in Chrome.
  fantasai: When you're in a content editable, and you move the
            cursor up it starts scrolling because you're beyond the
            edge of the screen. We could call it caret context to
            show visibility of lines
  ed: It seems like a quality of implementation issue.
  glazou: The mechanism doing it is in the word editor, not the
          browser
  <fantasai> glazou, I think you might want to explain that into IRC.
  glazou: Some online editors want to control finely caret's
          position inside the editable area but is this on the
          browser side or the app side?
  bert: Like highlighting text to show the cursor.
  astearns: There is the editing explainer that this might be
            beneficial to be brought up to them.

  andreyr: Does Chrome agree with that?
  TabAtkins: Sure, file a bug.

  RESOLVED: Quality of implementation issue

  <astearns_> perhaps add to http://w3c.github.io/editing-explainer/

:focusWithin
------------

  <andreyr> :focusWithin
  <andreyr> I'm sure there's a better name, but a selector that
            would match if that element or any of its children
            currently has focus. Without this a parent can't
            change its appearance when focus enters an inner
            element, for example adding a glow around a section
            for a page that has multiple forms on screen and you
            want an indication what larger subset of the page in
            currently being operated on.
  <andreyr> http://lists.w3.org/Archives/Public/www-style/2013Apr/0713.html
  <fantasai> (it was previously proposed as :contains-focus)
  <TabAtkins> :focus, :has(:focus)

  andreyr: This is a previously reported issue.
  TabAtkins: We have the :has selector now so you should be able to
             test this without doing a special case.
  TabAtkins: It's already in the spec it just needs to be
             implemented.
  florian: Does this work on the children psuedo elements?
  TabAtkins: It should, not sure why it wouldn't.
  * dbaron isn't so sure about :has() and pseudo-elements
  * TabAtkins dbaron, why?

Fixed & Sticky positioning inside overflow:scroll inner divs
------------------------------------------------------------

  <andreyr> Fixed & Sticky positioning inside overflow:scroll inner divs
  <andreyr> Position:fixed and position:sticky are great, but for
            some strange reason they are only relative to the entire
            document.  If you have a little scrollable div in the
            middle of your page it is perfectly reasonable to expect
            the same fixed and sticky positioning could be done
            relative to your nearest overflow scrolling parent. This
            would enable things like fixed headers for scrolling
            tables and lists.
  andreyr: If it would help, I can put together an example.

  dbaron: Is sticky different from fixed here?
  andreyr: Maybe it's better to wait for an example.
  TabAtkins: What do you mean?
  glazou: If you scroll the window it will move, if you scroll the
          inner content the fixed header will be there.

  TabAtkins: I'm looking into abspos.
  Rossen: Huh?
  TabAtkins: Make a container, give it an abspos child and scroll.
             It will not act like a fixpos when scrolling.
  TabAtkins: It's like it's fixed relative to the container rather
             than the document.
  Rossen: It's not going to scroll.
  glazou: Just make the test.
  TabAtkins: That's what I'm doing right now.

  <TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3167
  [TabAtkins shows test case]
  TabAtkins: The red box should stay in the corner.
  TabAtkins: Assuming we want to update the positioning spec, this
             sounds reasonable.
  TabAtkins: If we build positioning primitives this will pop out as
             something we can do.
  rossen: There are still work arounds for this.

  andreyr: I guess this isn't a huge issue, but we have work arounds
           for everything already and we don't want to do them.
  TabAtkins: I had a draft of them and the group didn't want it.
  rossen: Well, you went a little bit too far.
  andreyr: Is there something I can start with?
  TabAtkins: There isn't currently, I went down a rabbit hole.
  andreyr: I'll put something together.

Next F2F Dates
---------------

  [Discussing February 2015 dates]
  dbaron: There are some price cliffs based on the dates. I think it
          happens to deal with vacations, so we should shift it by a
          week (at least right now).
  dbaron: I think Krit had issues, though.
  krit: That's okay though.
  glazou: I suggest the 11th, 12, 13th of February. It would be
          beneficial if the SVG WG could move their dates. We would
          prefer the 9th, 10th and 11th.
  [We will wait for SVG WG answer before resolution]

  * ed thinks having the f2f that week would be better, can I
       mention that as an option in the SVG WG call tomorrow?
  <TabAtkins> ed, yeah, please do
  * ed TabAtkins, meaning svg 9 - 10th, fxtf 11th, css 12 - 13th?
  * TabAtkins ed, yes
  * glazou ed the contrary ; css beginning of week, svg at the end
  * ed glazou ok

Aside
-----

<fantasai> needs IE results for
           http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%20%20lang%3Dja%20style%3D%22width%3A%2010em%3B%20border%3A%20solid%3B%20text-align%3A%20justify%22%3E%0A%EC%84%9C%EC%9A%B8%ED%8A%B9%EB%B3%84%EC%8B%9C%E7%89%B9%E5%88%A5supercalifragilisticexpialidocious%3C%2Fp%3E
<chrisl> fantasai - pass criteria?
<fantasai> chrisl that's the issue, we don't know yet :)
<fantasai> I'm trying to figure out what browsers do, i.e. where
           is space distributed on the first line?
<chrisl> There's a screenshot in your mail.
<fantasai> Cool, thanks. If you add text-justify:
           inter-ideographic, does it change?

<fantasai> Note to self: elt { flow-name: foo; } elt2 { content:
           extract-flow(foo) | copy-flow(foo) |
           continue-flow(foo); }
<fantasai> (ideas discussed over dinner based on Bert's comments
           yesterday)

Received on Wednesday, 15 October 2014 18:48:08 UTC