- 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