Rendering: field-sizing support for some elements #9903
Conversation
This covers:
- input element as a text entry widget
size attribute is ignored if field-sizing:content
- input element as domain-specific widgets (optional)
- input element as a file upload control (optional)
- select element
size attribute is used only for dropdown/listbox switching if
field-sizing:content
- textarea element
cols/rows are ignored if field-sizing:content
Issue: whatwg#6807
Issue: w3c/csswg-drafts#7542
|
So I have a few concerns about how this interacts with
Also, This seems to also affect textarea inline-size which seems a bit surprising, but maybe it's fine? |
Yeah, we should not expose the autofilled text size for a security reason.
That's right.
I think it's fine. Web authors can specify a fixed inline-size even if |
That seems like it could cause layout issues in websites, but maybe it's fine. In that case the UA stylesheet should probably be extended with
It's not tho, right? There's no way to specify |
I updated the PR to include
I supposed to specify a fixed value like |
That only works if the font is monospace tho, right? |
Right. It's a workaround, not a perfect solution. |
but 'intrinsic size'. - Add an external definition of 'intrinsic size'
|
@zcorpan Would you review this please? |
|
@annevk , can you review this please? |
| <p>If the <span>'field-sizing'</span> property on the element has a <span>computed value</span> | ||
| of <span data-x="field-sizing-content">'content'</span>, the <span>inline size</span> is | ||
| determined by the text which the element shows. The text is either a | ||
| <span data-x="concept-fe-value">value</span> or a short hint specified by the | ||
| <code data-x="attr-input-placeholder">placeholder</code> attribute. User agents may take the | ||
| text caret size into account in the <span>inline size</span>.</p> |
There was a problem hiding this comment.
Say here that autofill text or uncommitted writing suggestion must not be considered in this step.
There was a problem hiding this comment.
Hmm maybe autofill doesn't need to be mentioned since there's the :autofill UA rule. Should a writing suggestion affect intrinsic size?
There was a problem hiding this comment.
Hmm, I'm not sure about a writing suggestion. If it suggest sensitive text such as credit card numbers, intrinsic size should not depend on it.
There was a problem hiding this comment.
User agents may take the text caret size into account
According to the latest changes to Chrome, should the may here be changed to must?
There was a problem hiding this comment.
Right. We can discuss desired interaction if both features were to be added, though.
Can we discuss it in #9065 ?
Anyway my current thought:
- If a suggestion by the writing suggestion feature is not shown in the page initially (e.g. shown in a popup window) and a user confirms it before committing it to a form control, we don't need to care about a combination of
field-sizingand the writing suggestion feature - If a suggestion by the writing suggestion feature is shown in a form control without a user confirmation,
- If the suggestion desn't contain any sensitive information,
field-sizing:contentshould assume the suggestion is a kind of content - If the suggestion might contain sensitive information, it should be treated as same as
:autofill. i.e. the form control has a fixed intrinsic size.
- If the suggestion desn't contain any sensitive information,
There was a problem hiding this comment.
I didn't realize writing suggestions were still an open issue, I agree then it can be considered as part of that issue. @tkent-google can you comment on that issue so it's not forgotten later?
I'm going to approve this now as I think it looks good, but waiting for @zcorpan to review/merge, since he still has a "changes requested" review from earlier.
There was a problem hiding this comment.
Moving to 9065 sounds good, I commented there: #9065 (comment)
@yisibl 's comment above is not addressed I think.
There was a problem hiding this comment.
According to the latest changes to Chrome, should the may here be changed to must?
I don't want to make it mandatory.
- Text caret is not defined in CSS specifications AFAIK.
- Text caret shape is implementation-dependent.
- Text caret painting is also implementation-dependent. For example, Blink can't paint text caret if the width of content box is zero, but can paint it if the width is greater than zero and it has no space dedicated to the text caret. Other UAs might be able to paint text caret even if the width is zero.
So, it's difficult to define concrete behavior and write tests.
Text caret wasn't visible if the content width is 0px. The HTML specification will have: > User agents may take the text caret size into account whatwg/html#9903 Bug: 1447058, 1523248 Change-Id: Id914795bfac2b09c0abce483e70f4e1e9bba4a77 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5252630 Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Auto-Submit: Kent Tamura <tkent@chromium.org> Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org> Cr-Commit-Position: refs/heads/main@{#1254905}
|
A WPT change is ready: web-platform-tests/wpt#44346 |
This commit adds the details of
field-sizingproperty behavior for some elements.This covers:
This also stops applying "presentational hints" and "user-agent-level style rule" for
widthandheightproperties in order to match to major browser behaviors.Issue: #6807
Issue: w3c/csswg-drafts#7542
field-sizingproperty WebKit/standards-positions#231 position:supportfield-sizingproperty mozilla/standards-positions#849 No replies yet.field-sizingCSS property mdn/mdn#476(See WHATWG Working Mode: Changes for more details.)
/infrastructure.html ( diff )
/rendering.html ( diff )