[CSSWG] Minutes TPAC Tue 2012-10-30 AM II: text-overflow, case-sensitivity, Grid Layout

text-overflow: ellipsis

   - RESOLVED: Selecting the ellipsis selects the ellipsed text.
   - RESOLVED: If all of ellipsed text is selected, show selection of
   - RESOLVED: put a note that behavior wrt partially-selected text is
               up to UA
   - Discussed clarifying examples in spec, adding tests.

Case-sensitivity of CSS identifiers

   Some discussion with i18nwg. No conclusions, but field of options
   seems to have narrowed to either ASCII-insensitivity or Unicode

Grid Layout

   Discussion of direction, progress, and lack thereof.

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


Scribe: fantasai
   tantek: First sub-item is wrt selection behavior of ellipsed content
   tantek: Second issue is what should we do about ellipsing block
           overflow content
   <glazou> http://www.w3.org/Style/CSS/Tracker/issues/279
   <glazou> http://lists.w3.org/Archives/Public/www-style/2009Nov/0219.html
   fantasai: I think we have a resolution from previous F2F for block
             overflow being out-of-scope for this feature
   fantasai: There are additional complications like wanting to display
             the overflow hint as a block below the current line, etc.
   tantek: captured on css4-ui wiki
   tantek: so should be resolved wrt this meeting

   tantek: first issue wrt selection behavior is unspecified in spec
   tantek: issue is, should it be specified, and if so... how
   tantek: One is wrt copy/paste, another is what happens when you select
   tantek: in Safari, you can see that the copy-pasted text is the complete text
   tantek: I think this is what is expected by users, implemented by other
           browsers, should put it in the spec
   arronei: There's a problem in this case is that the ellipsis doesn't
            look highlighted
   [some discussion of DOM ranges]
   Bert: Is this the first time we talk about selection in CSS?
   tantek: I thought we had something in the Selectors spec
   fantasai: Doesn't say what is selected, or selection behavior, just
             what the selection looks like
   Bert: If you use text-transform: uppercase; in selection, you may get
         uppercase or not
   Bert: Not opposed, but do we think we're strong enough to say what happens?
   tantek: In this case I think we are
   tantek: have strong interop
   tantek: Another issue is list markers -- what gets copied?
   sylvaing: We put this on the agenda because we have an issue wrt css3-ui
   RESOLVED: Selecting the ellipsis selects the ellipsed text.

   plinss: I think the ellipsis should look selected, though
   Rossen: We're now talking about selection which is happening with
           something not in the content
   glazou: Could select a list item by clicking list marker
   tantek: label selects an input
   arronei: It's weird and misleading if you don't highlight the ellipsis
   tantek: No implementation as far as I know will actually let you select
           the ellipsis itself
   tantek: I can't click on it and highlight it
   antonp: It's a problem with generated content in general
   tantek: It's bad behavior, but also interoperable
   tantek: There are some people that want to specify bad behavior that's
   tantek: Some people take approach of leaving things vague, allowing for
   tantek: I'm of the opinion that we should be vague in L3, and put
           normative should in L4
   Bert: Add some kind of note of what we intend, so implementers know what
         to expect.
   plinss: We don't require test passes on shoulds
   plinss: So let's just put a should.
   dbaron: What do you think UAs should do if part of the ellipsed text is
   dbaron: e.g. via DOM manipulation
   dbaron: or text selected prior to the resize that makes the ellipsis
   dbaron: or selection of text with the keyboard
   <dbaron> (maybe)
   <glazou> show ellipsis in a tooltip and allow selection in the tooltip
   tantek: Looks like selection with keyboard goes one character at a time

   TabAtkins: For highighting the ellipsis, think should only do so once
              contain the entire ellipsed text
   fantasai: And otherwise don't select any of it?
   dbaron: Don't know I'd require that; could do better
   dbaron: e.g. selecting part of ellipsis proportional to selected text
   tantek: That makes me lean towards a note, since we don't know exactly
           the right behavior
   plinss: I don't think we need to specify in excruciating detail, but
           give them some broad strokes
   plinss: If everything is selected, should select the whole ellipsis
   plinss: if partial selection, may indicate that some other way
   RESOLVED: If all of ellipsed text is selected, show selection of ellipsis
   RESOLVED: put a note that behavior wrt partially-selected text is up to UA

   Rossen: Have a minor issue wrt the example in the testcases
   * scribe wants a link to that testcase here
   Rossen: You only have an ellipsis on the last line of text, and they
           are confused
   Rossen: They think it's defining multiline ellipsis because the example
           only shows the ellipsis on the last line
   Rossen: This example sets the expectations
   fantasai: Change it to "CSS AWESOME IS"
   ACTION tantek: fix text-overflow example in the spec to not ellipse the
                  last line, but an earlier line
   plinss asks for clarifications on what this property does
   various explain

   Rossen: Other issue is wrt scrolling, and expectation to keep the
           ellipsis, recalc on every scroll
   Rossen: Currently I believe no implementation does that
   Rossen: No one has actually asked for this behavior
   Rossen: Depending on the underlying implementation, whether or not we
           need to reformat line of text when you render it, that behavior
           ties display with layout, which is not a good idea
   tantek: You're saying you don't want to scroll content into view?
   Rossen: If you have a horizontal scroller, no implementation does what
           you're saying
   tantek: Not true, FF does it.

   JohnJansen: Tantek, are your tests online somewhere?
   plinss: Secondary question: can you turn these into real tests in the
           test suite?
   <tantek> the tests were emailed to the list a while ago
   <tantek> I can resend
   <JohnJansen> ACTION: Tantek send the test cases to the list
   <tantek> and yes, we have an outstanding need for css3-ui test cases.
   <tantek> (unactioned)
   <stearns> tantek's testcase:

<trackbot> Could not create new action (unparseable data in server
             response: 'ascii' codec can't decode byte 0xc3 in position 0:
             ordinal not in range(128)) - please contact sysreq with the
             details of what happened.
dbaron: speaking of i18n, seems we can no longer assign actions to Tantek
<hober> ACTION: dbaron to make tantek send the test cases to the list
<trackbot> Created ACTION-519

Case-insensitivity of Identifiers

   fantasai summarizes the issue
   (see above)

   ishida: We may need to punt on a decision from i18n
   ishida: For extending out to full Unicode, recommendation would be to
           use default case-folding
   ishida: Would work for most people, except Turkish and Lithuanian
   ishida: because of dotted is
   ishida: Keeping case-insensitivity with default Unicode case-folding
           would create a problem for these users
   ishida: Don't know what more we can say today
   * fantasai thinks eszet is also a problem
   ishida: We don't have a conclusion in i18n
   TabAtkins: I think case-insensitivity in CSS was a mistake, but given
              we have this problem already, I would say keep it to ASCII
   TabAtkins: HTML already does this
   ishida: Problem with that is writing French, would assume you have
           case-insensitivity, but one character in your word happens
           to have an accent, would not be
   TabAtkins: Could recommend to authors to just use lowercase all the time
   fantasai: Or just recommend not relying on case-insensitivity, and
             always using consistent casing
   TabAtkins asks for ishida's opinion
   ishida: I personally feel that this seems a good way forward, but
           would have to discuss with i18n
   TabAtkins asks for a resolution by end of TPAC
   ishida: Not sure, but could have an answer by next Thursday,
           would that be ok?
   norbert: What extent do you actually need case-insensitivity
   TabAtkins: There's a significant fraction of people who use capital
              letters for CSS keywords
   TabAtkins: We can't change that.

   fantasai: So can we come to a conclusion on what we're doing here,
             pending i18n approval?
   [argument over what was resolved; see minutes above for actual resolution]
   Bert is not happy with ASCII case-insensitivity
   <jet> http://w3cmemes.tumblr.com/image/29509229758
   SteveZ: My understanding is we asked i18n to come back with a
   TabAtkins: And we want to tentatively resolve on something
   But there is no consensus, so we are waiting for i18n.

Grid Layout

   SteveZ: my issue is how to make progress on Peter's concerns.
           But not sure here is the right place to do that
   plinss: Takeaway from meeting with MSFT was that where there were
           differences between proposals, capture as issues
   plinss: and publish the spec
   plinss: And then modify the spec to bring in significant aspects of
           my proposal

   plinss: I was trying to go towards a general-purpose design grid
   plinss: Don't need all those features in this level, but want to take
           in a direction that's compatible
   plinss: I believe as the syntax stands now, it is incompatible
   TabAtkins: From my understanding of discussion with fantasai, it's
              mostly just syntax changes that are needed
   TabAtkins: basically changing -position/-span to -start/-end
   TabAtkins: and then other aspects slot in

Scribe: dbaron
   SteveZ: Want to see next steps happen
   fantasai: I think it's mainly a syntax brainstorming problem
   fantasai: There are various constraints we want to solve here
   Peter: I don't require major architectural changes to the proposal;
          just want minor changes to allow future changes
   Rossen: So do think at this point that everything will actually overlap?
   Peter: I think room for moderate tweaks in syntax and terminology,
          to keep existing model with terminology and syntax that will
          be compatible with the more expanded model.
   Peter: I don't see reason we should decide we can't do it and give up.

   fantasai: I tried mocking up on a whiteboard; main area I got stuck
             on is that Peter wants a model where you say which lines
             you're between, whereas MS model allows for an auto-placement
             model, which requires ability to express with start or end
             positions plus a span.
   fantasai: I had trouble figuring out a sane syntax that could represent
   Peter: I had notions of a functional notation.
   Peter: ... opposite side wants to be nth version of that line?
   Peter: We should ... and brainstorm.
   fantasai: Yep, brainstorming.

   Peter: My proposal can be broken into discrete levels.
   Peter: First order is agreeing to express grid model in terms of lines
          and fields instead of rows and columns.
   Peter: So expose it that way and present it to authors in that mindset.
   Peter: fields instead of cells, roles instead of names
   Peter: I don't know if we decide to adopt those as principles or wait
          for real syntax.
   fantasai: I think if we figure out the syntax it will be easier to
             write the prose; but I'm not the editor.
   Peter: I think ??? is an important direction; based on lines and
          fields instead of rows and columns.
   Peter: That distinction influences syntax.
   Peter: Syntax now is rows, columns, and spans.
   Bert: There's a danger using terms like fields, which have a meaning
         in some traditions.
   Bert: Our fields aren't exactly what they're used for in those traditions.
   Peter: I don't care about the exact words; don't want to be hung up on
          terms; but opposed to rows, columns, spans.

   SteveZ: We need to set up a call to discuss this.
   Tab: ... .  I contacted Phil about being a coeditor on this spec.
   SteveZ: Can we have a 15 minute update following the next CSS call?
   SteveZ: Status check of where we are on that.
   SteveZ: Outside of the telecon time.
   JohnJansen: Why not part of the agenda on the next call?
   ?: Not having the brainstorming on the call.
   Peter: Have a deadline for brainstorming to be done and report back
          to the group.
   SteveZ: Want it less than a month.
   Rossen: Reasonable to dedicate some time before the next conf call.
   Rossen: Minimal overlap that needs to go in the level 1 spec.
   Rossen: Two things we need to guarantee: (1) that there's no features
           of current grid that will contradict further development of
           overlap grid
   Rossen: ... (2) minimal set of syntax rewrite we'll need to do for
           current grid to verify (1)
   Rossen: If we come to the conclusion they're not overlappable,
           because of significant differences, then we each go our
           separate ways.
   SteveZ: ... and agree to disagree
   Rossen: So I guess we have an action to get together and talk about this.
   Bert: My next 3 weeks are very busy.
   Rossen: Who needs to be on call?
   Rossen: Peter, fantasai, Bert, Tab, Steve, Rossen, Phil
   Rossen: Let's schedule offline.
   ACTION Rossen to organise brainstorming call about grid
   <trackbot> Created ACTION-521

Received on Wednesday, 14 November 2012 07:05:43 UTC