[webkit-dev] New CSS property -webkit-control-text-overflow

[Jon Lee]

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
> (hyatt at apple.com)
> 
> 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
>>> (hyatt at apple.com)
>>> 
>>> 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 <jonlee at apple.com> 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
>>>> webkit-dev at lists.webkit.org
>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>> 
>>>> _______________________________________________
>>>> webkit-dev mailing list
>>>> webkit-dev at lists.webkit.org
>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120119/e1006c63/attachment.html>