Hi Carsten, (for reference, I'm also posting this message in the original thread)
I've played around with the options a bit more, and this is what could work - with this you'd have an input field (and therefore automatic text-control by the browser), and then you could also effectively disable the keyboard: <label for="text">Textfield:</label><input id="text" name="text" type="text" value="irgendwas" onkeyup="return false;" onkeydown="return false;" onkeypress="return false;" /> regards, Martin On 8/13/07, Carsten Pieper <[EMAIL PROTECTED]> wrote: > > Hi Martin, > > > Well, if you change every intended span to be on block-level, there > > will be a huge influence on the rest of your CSS. > er, like what? Could you elaborate on this one, please? > > > So I wouldn't do this for each and every text-field. > Well, our actual status is, that we're doing it for each and every non-input > text-field... > > As always, best thanks, > Carsten > > > Martin Marinschek wrote: > > > > Well, if you change every intended span to be on block-level, there > > will be a huge influence on the rest of your CSS. So I wouldn't do > > this for each and every text-field. > > > > @sidenote: I wonder what the markup/JS/CSS looked like for this to > > work in CIS (your existing web-framework)? Maybe we could replicate it > > from there? > > > > regards, > > > > Martin > > > > On 8/13/07, Carsten Pieper <[EMAIL PROTECTED]> wrote: > >> > >> Hi Adam, > >> > >> perhaps I should be a little more speicific: > >> > >> We want to be able to delimit the length of the outputText's text (so > >> that > >> long text's won't > >> break our pages' layout). The way we came up to achieve this was to have > >> something like > >> display: block; > >> overflow: hidden; > >> in our CSS. Without this CSS-tweaking above, a width definition via the > >> inlineStyle attribute > >> has no effect (as you'll surely know; I just mention it for those of us > >> lesser experts...). > >> If the text now gets longer than the "inlineStylish" width, it still can > >> be > >> accessed > >> by/presented to the user via the tooltip (shortDesc). > >> > >> Thus, we enhanced the OutputTextRenderer to be styleclass-aware and to > >> set > >> the tooltip > >> accordingly (if no other tooltip is defined). > >> > >> Do you consider this to be contrary to the "intended spirit" of the > >> outputText (eh, or even > >> weird) or is this approach OK? > >> > >> Thanks, > >> Carsten > >> > >> > >> > >> Adam Winer wrote: > >> > > >> > Generally speaking, you don't want to do this for > >> > outputText: you want to style parent components > >> > and/or the default font of the skin, not the outputText > >> > itself. > >> > > >> > -- Adam > >> > > >> > > >> > On 8/10/07, Carsten Pieper <[EMAIL PROTECTED]> wrote: > >> >> > >> >> OK, thanks for the speedy answer! > >> >> > >> >> So it look's we should build our own renderer... > >> > > >> > >> -- > >> View this message in context: > >> http://www.nabble.com/-Trinidad--Skinning---no-CSS-selector-for-tr%3AoutputText--tf4247489.html#a12121153 > >> Sent from the MyFaces - Users mailing list archive at Nabble.com. > >> > >> > > > > > > -- > > > > http://www.irian.at > > > > Your JSF powerhouse - > > JSF Consulting, Development and > > Courses in English and German > > > > Professional Support for Apache MyFaces > > > > > > -- > View this message in context: > http://www.nabble.com/-Trinidad--Skinning---no-CSS-selector-for-tr%3AoutputText--tf4247489.html#a12121648 > Sent from the MyFaces - Users mailing list archive at Nabble.com. > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
