After much searching and struggling I've discovered that the
only way to adjust the size of an <input type=text> element is
with its size="number-of-chars" attribute.

Are there any common workarounds to let me style the thing
to (at least appear to) fill its containing box? Can I just simulate
one with a web component and having it look different but
feed a hidden <input> element in its shadow dom?

I suppose the answer to that last question is probably Yes.
Does this sound like a good idea?

luserdroog <luser.droog@gmail.com> writes:

> After much searching and struggling I've discovered that the
> only way to adjust the size of an <input type=text> element is
> with its size="number-of-chars" attribute.

Can you say more? Are you limited to what browsers you must support. I
thought you could style the width in most.

--
Ben.

On Fri, 28 Jul 2023 06:31:02 -0700 (PDT), luserdroog wrote:
> After much searching and struggling I've discovered that the
> only way to adjust the size of an <input type=text> element is
> with its size="number-of-chars" attribute.
>
> Are there any common workarounds to let me style the thing
> to (at least appear to) fill its containing box? Can I just simulate
> one with a web component and having it look different but
> feed a hidden <input> element in its shadow dom?
>
> I suppose the answer to that last question is probably Yes.
> Does this sound like a good idea?

Chances are that, whatever CSS you've tried to apply to the INPUT element,
is overidden by a higher priority styles. Meaning that, you styles aren't
defined with a CSS selector which is specific enough to have a higher
priority than the existing one.

Content in Shadow DOM is similar (but not the same) to a separate document
in an IFRAME. CSS rules by default, don't apply across Shadow DOM unless the
correct CSS selector is used.

On Fri, 28 Jul 2023 06:31:02 -0700 (PDT), luserdroog
<luser.droog@gmail.com> wrote in
<112fa9f3-7d2d-4c3b-b417-655eb0776264n@googlegroups.com>:

>After much searching and struggling I've discovered that the
>only way to adjust the size of an <input type=text> element is
>with its size="number-of-chars" attribute.
>
>Are there any common workarounds to let me style the thing
>to (at least appear to) fill its containing box? Can I just simulate
>one with a web component and having it look different but
>feed a hidden <input> element in its shadow dom?
>
>I suppose the answer to that last question is probably Yes.
>Does this sound like a good idea?

If you have
<input id='a' size='10' value='123'>
then adjust the size with
document.getElementById('a').setAttribute('size', 15) ;

If you have
<input id='b' style="width:10em" value='123'>
then adjust the width with
document.getElementById('b').style.width='25em' ;

You probably want to investigate getting width of a string and using a
fixed width font to get things to fit. "onchange" is useful.

You could also replace the input element with a bordered string inline
after the value is entered.
<span style="border:red 1px solid;">12345</span>

On 29/07/2023 11:05, JJ wrote:
> On Fri, 28 Jul 2023 06:31:02 -0700 (PDT), luserdroog wrote:
>> After much searching and struggling I've discovered that the
>> only way to adjust the size of an <input type=text> element is
>> with its size="number-of-chars" attribute.
>>
>> Are there any common workarounds to let me style the thing
>> to (at least appear to) fill its containing box? Can I just simulate
>> one with a web component and having it look different but
>> feed a hidden <input> element in its shadow dom?
>>
>> I suppose the answer to that last question is probably Yes.
>> Does this sound like a good idea?
>
> Chances are that, whatever CSS you've tried to apply to the INPUT element,
> is overidden by a higher priority styles. Meaning that, you styles aren't
> defined with a CSS selector which is specific enough to have a higher
> priority than the existing one.
>
> Content in Shadow DOM is similar (but not the same) to a separate document
> in an IFRAME. CSS rules by default, don't apply across Shadow DOM unless the
> correct CSS selector is used.

Firefox inspector is your friend here. For the record < input > does in
fact respond to style= "width: X px".

But the problem is that until you have written as many pages as I seem
to have the habit of turning margins paddings, and everything else to
zero on your <body> definition leads to many strange interpretations by
the browser itself that are different between browsers, oh, and if you
want to preserve fonts across browser and platforms embed those, as well.

--
How fortunate for governments that the people they administer don't think.

Adolf Hitler

On 29/07/2023 13:57, Dr.Kral@nyc.rr.com wrote:
> On Fri, 28 Jul 2023 06:31:02 -0700 (PDT), luserdroog
> <luser.droog@gmail.com> wrote in
> <112fa9f3-7d2d-4c3b-b417-655eb0776264n@googlegroups.com>:
>
>> After much searching and struggling I've discovered that the
>> only way to adjust the size of an <input type=text> element is
>> with its size="number-of-chars" attribute.
>>
>> Are there any common workarounds to let me style the thing
>> to (at least appear to) fill its containing box? Can I just simulate
>> one with a web component and having it look different but
>> feed a hidden <input> element in its shadow dom?
>>
>> I suppose the answer to that last question is probably Yes.
>> Does this sound like a good idea?
>
>
> If you have
> <input id='a' size='10' value='123'>
> then adjust the size with
> document.getElementById('a').setAttribute('size', 15) ;
>
> If you have
> <input id='b' style="width:10em" value='123'>
> then adjust the width with
> document.getElementById('b').style.width='25em' ;
>
> You probably want to investigate getting width of a string and using a
> fixed width font to get things to fit. "onchange" is useful.
>
> You could also replace the input element with a bordered string inline
> after the value is entered.
> <span style="border:red 1px solid;">12345</span>
>
>
Make your <input> a nice width and allow overflow in it.
The rest of the default HTML entry should be replaced with javascripted
buttons apart from the drop down menus which need to be utterly restyled
to not look like something out of the 1980s. File upload is another one
where you have to overlay the default styles.

>
>

--
Climate Change: Socialism wearing a lab coat.

luserdroog, 2023-07-28 15:31:

> After much searching and struggling I've discovered that the
> only way to adjust the size of an <input type=text> element is
> with its size="number-of-chars" attribute.

No. You can also set its width using CSS and "width". Also the distance
from the text and the surrounding border can be styled as well as all
colours.

--
Arno Welzel
https://arnowelzel.de

On Friday, July 28, 2023 at 2:11:45 PM UTC-5, Ben Bacarisse wrote:
> luserdroog <luser...@gmail.com> writes:
>
> > After much searching and struggling I've discovered that the
> > only way to adjust the size of an <input type=text> element is
> > with its size="number-of-chars" attribute.
> Can you say more? Are you limited to what browsers you must support. I
> thought you could style the width in most.
>

Thanks for all the responses. To the questions, it's a very simple
single page web app with only a half dozen users and I'm also the
primary user/developer/tester.

The context is a text edit widget that manifests inside a spreadsheet-like
table view of personnel scheduling data. Clicking a cell turns the
<td><span/></td> into a <td><input></td> and then onchange or onblur on
the input changes it back to a span.

eg.
https://github.com/luser-dr00g/luser-dr00g.github.io/blob/master/cm-tool.html#L1092

function addGridNotesWidgets(){
let notes = grid.querySelectorAll( ".notes" );
notes.forEach( (note) => {
let idx = note.dataset.index;
const clickHandler = (event) => {
let edit = document.createElement( "input" );
edit.value = global.data[ idx ][5];
//edit.size = 30; // tweak the size or width here?
let target = note.childNodes[0];
note.replaceChild( edit, target );
note.parentNode.removeEventListener( "click", clickHandler );
const done = (event) => {
if( edit.value == "" ) edit.value = "\t";
target.textContent = edit.value;
changeNotes( idx, edit.value );
edit.parentNode.replaceChild( target, edit );
saveData();
output();
};
edit.addEventListener( "change", done );
edit.addEventListener( "blur", done );
edit.focus();
};
note.parentNode.addEventListener( "click", clickHandler );
});
}

On Friday, July 28, 2023 at 2:11:45 PM UTC-5, Ben Bacarisse wrote:
> luserdroog <luser...@gmail.com> writes:
>
> > After much searching and struggling I've discovered that the
> > only way to adjust the size of an <input type=text> element is
> > with its size="number-of-chars" attribute.
> Can you say more? Are you limited to what browsers you must support. I
> thought you could style the width in most.
>

Oops, other question. Nope, I can safely assume/require the latest versions
of chrome or firefox. In fact I'm relying on this for the next rewrite
that'll use the new compression/decompression stuff.

luserdroog <luser.droog@gmail.com> writes:

> On Friday, July 28, 2023 at 2:11:45 PM UTC-5, Ben Bacarisse wrote:
>> luserdroog <luser...@gmail.com> writes:
>>
>> > After much searching and struggling I've discovered that the
>> > only way to adjust the size of an <input type=text> element is
>> > with its size="number-of-chars" attribute.
>> Can you say more? Are you limited to what browsers you must support. I
>> thought you could style the width in most.
>
> Oops, other question. Nope, I can safely assume/require the latest versions
> of chrome or firefox. In fact I'm relying on this for the next rewrite
> that'll use the new compression/decompression stuff.

So now I don't know what the problem is!

--
Ben.

On Monday, July 31, 2023 at 10:49:18 AM UTC-5, Ben Bacarisse wrote:
> luserdroog <luser...@gmail.com> writes:
>
> > On Friday, July 28, 2023 at 2:11:45 PM UTC-5, Ben Bacarisse wrote:
> >> luserdroog <luser...@gmail.com> writes:
> >>
> >> > After much searching and struggling I've discovered that the
> >> > only way to adjust the size of an <input type=text> element is
> >> > with its size="number-of-chars" attribute.
> >> Can you say more? Are you limited to what browsers you must support. I
> >> thought you could style the width in most.
> >
> > Oops, other question. Nope, I can safely assume/require the latest versions
> > of chrome or firefox. In fact I'm relying on this for the next rewrite
> > that'll use the new compression/decompression stuff.
> So now I don't know what the problem is!
>

All good now. style="width:inherit" did the trick.
It's beautiful. sniff.

On Monday, July 31, 2023 at 11:41:58 AM UTC-5, luserdroog wrote:
> On Monday, July 31, 2023 at 10:49:18 AM UTC-5, Ben Bacarisse wrote:
> > luserdroog <luser...@gmail.com> writes:
> >
> > > On Friday, July 28, 2023 at 2:11:45 PM UTC-5, Ben Bacarisse wrote:
> > >> luserdroog <luser...@gmail.com> writes:
> > >>
> > >> > After much searching and struggling I've discovered that the
> > >> > only way to adjust the size of an <input type=text> element is
> > >> > with its size="number-of-chars" attribute.
> > >> Can you say more? Are you limited to what browsers you must support. I
> > >> thought you could style the width in most.
> > >
> > > Oops, other question. Nope, I can safely assume/require the latest versions
> > > of chrome or firefox. In fact I'm relying on this for the next rewrite
> > > that'll use the new compression/decompression stuff.
> > So now I don't know what the problem is!
> >
> All good now. style="width:inherit" did the trick.
> It's beautiful. sniff.

Correction, it was
edit.style.width = td.offsetWidth + "px";
that finally worked.

On Monday, July 31, 2023 at 8:53:58 AM UTC-5, luserdroog wrote:
> [...]
> The context is a text edit widget that manifests inside a spreadsheet-like
> table view of personnel scheduling data. Clicking a cell turns the
> <td><span/></td> into a <td><input></td> and then onchange or onblur on
> the input changes it back to a span.

Is it not simpler to keep <td><input></td> and then with clicking toggle the readonly attribute?

The css :read-only selector will allow you to control appearance.

On Monday, July 31, 2023 at 10:59:34 PM UTC-5, Michael Haufe (TNO) wrote:
> On Monday, July 31, 2023 at 8:53:58 AM UTC-5, luserdroog wrote:
> > [...]
> > The context is a text edit widget that manifests inside a spreadsheet-like
> > table view of personnel scheduling data. Clicking a cell turns the
> > <td><span/></td> into a <td><input></td> and then onchange or onblur on
> > the input changes it back to a span.
> Is it not simpler to keep <td><input></td> and then with clicking toggle the readonly attribute?
>
> The css :read-only selector will allow you to control appearance.

Verry interesting. I completely hadn't considered that. With all the trouble
controlling the size of the inputs, I had written them off as part of "the real page"
in my vague design/imagination.

That would also solve the riddle of whether
to put the click handlers on the td or the spans (because sometimes the spans
had no content in which case they don't have a clickable area).
With <td><input></td> as a more permanent substructure, it's quite obvious that
the handlers should go on the input element.

Not swapping the elements in the dom means none of the dozens of lines of
code that do all that business. So, I'm loving this ideamore the more I think on it.