- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 13 Nov 2012 22:59:06 -0800
- To: "www-style@w3.org" <www-style@w3.org>
text-overflow: ellipsis
-----------------------
- RESOLVED: Selecting the ellipsis selects the ellipsed text.
- 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
- 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
case-folding.
Grid Layout
-----------
Discussion of direction, progress, and lack thereof.
====== Full minutes below ======
text-overflow
-------------
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
definition
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
interoperable
tantek: Some people take approach of leaving things vague, allowing for
improvement
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
selected?
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:
https://bug690187.bugzilla.mozilla.org/attachment.cgi?id=583694
<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
---------------------------------
http://wiki.csswg.org/topics/custom-ident-case-sensitivity
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?
[explosion]
http://lists.w3.org/Archives/Public/www-style/2012Aug/0899.html
[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
recommendation
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
http://lists.w3.org/Archives/Public/www-style/2012Oct/0828.html
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
both.
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