Fair enough, reusing text-overflow introduces the fewest changes, and would be the best option for authors to use. I will update the bug patch to use that property instead, and close the issue on the www-style list.
Thanks for everyone's input! Jon On Jan 16, 2012, at 1:54 PM, David Hyatt wrote: > I strongly disagree with the reasoning in that post. You say: > > "As an author, I would find it strange that upon focus of a text input the > ellipsis would just disappear." > > I think it would be even stranger for the ellipsis not to disappear and to be > editing a truncated version of the input field's value. What does that that > even mean? I'd rather the author be surprised than the user! > > It seems like the options are: > > (1) Ignore text-overflow completely on text fields. Support a new property > for the dynamic display of the full text when focused. > (2) Honor text-overflow strictly on text fields. Support a new property for > the dynamic display of the full text when focused. > (3) Use text-overflow for the dynamic display of the full text when focused. > > To me (3) is clearly the most attractive choice. (1) would surprise authors > by having text-overflow not work. (2) would surprise both authors and users > by having text-overflow work badly when you focused the control. > > I see absolutely no reason to introduce a new property here, especially after > hearing that Gecko just made text-overflow do this already. My expectation is > that we would match Gecko's behavior and not introduce a new property. > > dave > ([email protected]) > > On Jan 16, 2012, at 1:53 PM, Jon Lee wrote: > >> There is a thread on the www-style list that discusses this point: >> >> http://lists.w3.org/Archives/Public/www-style/2012Jan/0687.html >> >> On Jan 16, 2012, at 11:41 AM, David Hyatt wrote: >> >>> I have the same question. Can you explain why text-overflow is >>> insufficient? I think in this case it would be acceptable behavior to just >>> make text-overflow behave the way you want, i.e., no longer showing the >>> ellipsis while the user is actively typing in the focused control seems >>> like fine behavior even for text-overflow. >>> >>> dave >>> ([email protected]) >>> >>> On Jan 13, 2012, at 2:45 PM, Ojan Vafai wrote: >>> >>>> Is this specced anywhere? Do we need a new CSS property? Could we just >>>> make text-overflow work on text inputs? >>>> >>>> On Wed, Jan 11, 2012 at 11:30 PM, Jon Lee <[email protected]> wrote: >>>> Hi WebKit! >>>> >>>> I wanted to let you know that we would like to add a new CSS property >>>> -webkit-control-text-overflow. It is a non-inheritable property that can >>>> only be applied to single-line text inputs. Acceptable values are the same >>>> as text-overflow, i.e. "clip" and "ellipsis". >>>> >>>> When the input is set with the "ellipsis" value, both the placeholder and >>>> inner text value of the input render with an ellipsis if the text >>>> overflows and the input is not focused. When the input becomes focused, >>>> the placeholder or text value renders clipped, as before. >>>> >>>> Although this is a small enhancement to text controls, we think this is >>>> especially useful for authors developing on the mac platform, since the >>>> analog native widgets behave similarly. >>>> >>>> The bug that tracks this is: https://bugs.webkit.org/show_bug.cgi?id=76118 >>>> >>>> Jon >>>> _______________________________________________ >>>> webkit-dev mailing list >>>> [email protected] >>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>>> >>>> _______________________________________________ >>>> webkit-dev mailing list >>>> [email protected] >>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
