After discussing this matter with other WebKit developers, and given Gecko's support already, we've decided to follow suit, and implement the feature with the text-overflow style instead. Thanks to everyone for their input. Jon On Jan 16, 2012, at 11:46 AM, Jon Lee wrote: > We believe the unique behavior of showing and hiding the ellipsis based on focus warrants a new property. > > text-overflow has thus far acted as a "static" property, in that web authors would expect that anything styled with it should remain as such, even in the focus case. As an author, I would find it strange that upon focus of a text input the ellipsis would just disappear. I would think that I should instead include the style > > input:focus { text-overflow: clip; } > > or something of that nature. The unfortunate consequence is that it also implies that I could state > > input:focus { text-overflow: ellipsis; } > > which, as you mentioned, would interfere with the user's ability to edit the text. Encapsulating this whole behavior with a property mitigates both issues. > > Given this line of reasoning, I would concede that since <select>s would not exhibit this focus behavior, text-overflow could be used for those elements. > > Jon > > On Jan 15, 2012, at 10:04 AM, Mats Palmgren wrote: > >> FYI, the behavior you describe is implemented in Gecko for >> "text-overflow:ellipsis" for single- and multiple-line text >> controls. This is to avoid the ellipsis interfering with >> the text caret and the user's ability to edit the text. >> >> The text-overflow spec already allows for this behavior for >> text controls so I don't see the need for a separate property. >> http://dev.w3.org/csswg/css3-ui/#text-overflow0 >> >> >> /Mats > >Received on Thursday, 19 January 2012 21:41:14 UTC
This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:09 UTC