Last post Oct 03, 2020 12:36 PM by CincySteve
Oct 02, 2020 05:25 PM|CincySteve|LINK
I have a Blazor Wasm app (that may not be relevant) that renders an html table that has input elements within the td elements. The inout elements are what trigger event handlers for user data changes.
When I click on a td that has contenteditable=true and then subsequently keep hitting the tab key, it takes two tabs to move from one contenteditable=true td to the next. I'm hoping there is an easy way to enable on a single tab to cause the jump.
Oct 02, 2020 05:43 PM|mgebhard|LINK
It's hard to provide advice with the source code. The tab key behavior is deterministic. Pressing tab goes to the next selectable item. I assume it appears to take two tab presses because there are two selectable items in the <td>.
Oct 02, 2020 06:13 PM|CincySteve|LINK
I'm sorry. I thought the situation was simple enough not to require posting the code. It is shown below, though these html elements are surrounded by Blazor loops that generate multiple <tr>s with a variable number of <td>s inside of them. Hope that helps.
Perhaps Blazor put something inside the <td>.
<tbody style="border: 1px solid green; overflow-y: scroll">
<td contenteditable="true" style="width: @BBDAllCellsLists[yearIndex][colIndex].ColWidthInPx">
@onchange="@((ChangeEventArgs e) => BBDCell_OnChange(e, formattedData, yearIndex, currColIndex, @currYear, @colName))"
@onfocusin="@((FocusEventArgs e) => BBDCell_OnFocusIn(e, yearIndex, currColIndex, @currYear, @colName))"
@onfocusout="@((FocusEventArgs e) => BBDCell_OnFocusOut(e, formattedData, yearIndex, currColIndex, @currYear, @colName))" /></td>
Oct 02, 2020 08:13 PM|bruce (sqlwork.com)|LINK
as designed by the browser.
when you set contenteditable on the td, it becomes a user editable element with it own focus. just tab to the div, and you can type text outside the input box and it appears, or you can delete the input box.
Oct 03, 2020 12:36 PM|CincySteve|LINK
Bruce - Thanks for the perspective.
After both setting contenteditable="false" and removing it completely (which means it inherits it from its parent, presumably as false), the need for a 2nd tab went away, as you say. I had falsely thought that tab was stopping or not in the table cells
based on how I had contenteditable set. But with it set to false, I get the same result, which means the input elements I have in the td elements allow tab stops (and get a default tab stop order that makes sense), while the straight text I have in the other
cells does not. Makes total sense now.
I'm afraid I don't know what your "note" means, but may not nee to because my problem is solved.
Thanks again. You are always helpful. And I will endeavor to post code with questions, including seemingly simple ones, in the future. Steve