- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 15 Oct 2014 14:47:40 -0400
- To: www-style@w3.org
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