Closed Bug 1373351 Opened 7 years ago Closed 7 years ago

Abspos <input> does not stretch like a <div> would, with "width:auto" & values for left/right

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Version:
52 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 733914

People

(Reporter: vader.24, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(2 files)

ex.html
758 bytes, text/html
Details
many html elements affected by the bug.
1.68 KB, text/html
Details 
User Agent: Mozilla/5.0 (Windows NT 6.3; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20170411115307

Steps to reproduce:

I used:
form
{
   width:300px;
   min-height:300px; 
   position:relative;
}
 
input[type="submit"], button
{
   position: absolute;
   left:20px;
   right:20px; 
   bottom:20px;
   width:auto;
}


Actual results:

It ignores right:20px; 
It works like "quirksmode" but I declared <!DOCTYPE html> and quirksmode shall be disabled. It works like the "true" button/input is placed inside a inline-block or inline-table element...

The MSIE 11 doesn't have this problem.

For <div>s, <label>s the problem doesn't occur, but I hate "divitis" and I don't want to use any wrapper if it is not absolutely needed. 

box-sizing: content-box doesn't help to it. 


Expected results:

The element shall be stretched to width of the form minus 40px.
Please create a minimal html file showing the bug and attach it here (use the "Attach file" link above).
Thanks!
Flags: needinfo?(vader.24)
Keywords: testcase-wanted
Component: General → Layout
Attached file ex.html — 
Attached file with wrong positioning.

Please also test for: 
- other types of <input>
- <button>
- <textarea>
- <select>

Here may be some bugs.
Flags: needinfo?(vader.24) → needinfo?(moz)
Keywords: testcase-wanted → testcase
Same problem in FF version 52.2.0 (32-bit) LTS/ESR.
Keywords: testcase → testcase-wanted
Please add flag "testcase". 

Longer example attached.

Please check also tags: 
- <img> 
- <video>. 
They can also be affected. 

Affected are also:
- <textarea>
- <button>
Flags: needinfo?(epinal99-bugzilla2)

    
  
Keywords: testcase-wanted → testcase
Version: 45 Branch → 52 Branch

    
    

    
  
Daniel, do you have an idea about the specs and the correct rendering in this case? Is IE11 wrong?
Flags: needinfo?(moz)
Flags: needinfo?(epinal99-bugzilla2)
Flags: needinfo?(dholbert)

    
    

    
  
Hi Vader!

The elements mentioned here (img, video, input, etc) are all considered "replaced elements", which indeed *do not* do the width-stretching-to-honor-left-and-right behavior that you seem to be expecting.

You seem to be expecting the behavior that's specced here for *non-replaced* elements (e.g. divs):
> 5. 'width' is 'auto', 'left' and 'right' are not 'auto', then solve for 'width'
https://drafts.csswg.org/css2/visudet.html#abs-non-replaced-width (CSS2 10.3.7)

BUT: that spec text does not apply, because it's specifically for *non-replaced* elements.  And here, we're dealing with replaced elements.

So -- the spec text that DOES apply to your examples is here:
> 10.3.8 Absolutely positioned, replaced elements
> [...]
> The used value of 'width' is determined as for inline replaced elements.
https://drafts.csswg.org/css2/visudet.html#abs-replaced-width

And that links to this earlier spec text which says this about how to determine "width":
> [...] if 'width' has a computed value of 'auto', and the element has an
> intrinsic width, then that intrinsic width is the used value of 'width'.

So: in your examples, we see "width:auto" on an absolutely positioned replaced element, and we see that the element has an intrinsic width.  So we use that intrinsic width as the element's width.

So, I'm going to close this as INVALID, because we're matching the spec.  If you really want the stretch-to-honor-left-and-right behavior, you probably need to wrap your <input> in a <div> and then give the input width:100%, or something like that.  (Sorry for the "divitis". :))
Flags: needinfo?(dholbert)
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
Summary: <input> and left+right positioning, branch 45.9.0 LTS/ESR → Abspos <input> does not stretch like a <div> would, with "width:auto" & values for left/right

    
    

    
  
Does thr DRAFT is actual? Does it have STANDARD clause? 
What is definition of replaced elements for the moment?

    
  
Flags: needinfo?(dholbert)

    
    

    
  
(In reply to Vader from comment #8)
> Does thr DRAFT is actual? Does it have STANDARD clause? 

W3C "draft" versions are generally the most up-to-date versions of specs (and have clarifications, typo fixes, & other improvements that are to-be-published).

In this case it's just a minor improvement (CSS 2.1 is a W3C recommendation, and CSS 2.2 -- what I linked to above -- will be a minor revision to fix typos & make clarifications to CSS 2.1, not to rethink anything majorly, as far as I know.)

So I don't think there are substantial changes between the versions, but you can look at http://www.w3.org/TR/CSS21/ if you'd rather be using a more authoritative version.  I suspect it's got identical or near-identical language to what I quoted/linked for you above.

> What is definition of replaced elements for the moment?

It's defined here (and I'll link to CSS 2.1 since you prefer that over the draft):
 https://www.w3.org/TR/CSS21/conform.html#replaced-element
 "An element whose content is outside the scope of the CSS formatting model, such as an image, embedded document, or applet."

The list isn't exhaustive, but it does mention some of the elements that you mentioned (image, and by extension video).  As for <input>, the element you originally filed this bug about: older version of the spec did explicitly mention <input> elements, too:
 https://www.w3.org/TR/REC-CSS2/conform.html
 "In HTML, IMG, INPUT, TEXTAREA, SELECT, and OBJECT elements can be examples of replaced elements."

Form widget rendering behavior (like <input>) is largely unspecified, but browsers do tend to treat them as replaced elements.
Flags: needinfo?(dholbert)

    
    

    
  
(Here's one rough way to tell whether an element is replaced or not: see if it fill the width of its containing block, when you style it as "display:block".

Non-replaced elements (with "display:block") will stretch their width to fill their containing block, but replaced elements will not, because CSS's sizing rules are different for these two categories of elements.

Here's a demo of this for various replaced elements (including <input> elements) vs. a non-replaced <div>:
 https://jsfiddle.net/1oogh8o6/

(IE11 and Edge agree with us on *this* testcase, BTW, which means their abspos behavior is clearly-inconsistent.  They're sizing <input> as a replaced element when it has "display:block", but they size it as if it were a non-replaced element when it has "position:absolute;left:...right:...".  This inconsistency is a bug you've stumbled upon that's worth reporting to Microsoft, if you'd be up for that.)

    
    

    
  
No L'Oreal for Microsoft. 

She is not worth it. (-; 

Well, this is embarassing, that I must use "div-itis" for "replaced elements".

    
    

    
  
(In reply to Vader from comment #11)
> Well, this is embarassing, that I must use "div-itis" for "replaced elements".

These days you may solve your problem with something like this:

input { width: calc(100% - 40px) }

    
    

    
  
Is it legal according to W3C to use calc(100% - 40px)? Is it accepted by W3C now? It will be very helpful to create front-end of pages. 

Where can I find the specification of this extension and similar?
Flags: needinfo?(moz)

    
    

    
  
(In reply to Vader from comment #13)
> Is it legal according to W3C to use calc(100% - 40px)? Is it accepted by W3C
> now? [...] Where can I find the specification of this extension and similar?

calc() is specified in this W3C spec:
  https://www.w3.org/TR/css3-values/#calc-notation

And yes, calc(100% - 40px) is valid for any property that would accept both "100%" and "40px" individually as values.

It's basically universally supported in browsers these days:
  https://caniuse.com/#feat=calc
Flags: needinfo?(moz)

    
    

    
  
The behaviour of MSIE is... correct for input elements. Please read CURRENT SPEC FOR HTML5. Definition of replaced elements for HTML4 and HTML5 is different. 

https://www.w3.org/TR/html5/rendering.html#replaced-elements

This document has valid status W3C RECOMMENDATION. It isn't living standard or working draft or editors draft. 

This is bug in Firefox and Chrome. Not fully implemented HTML5 requirements.
Flags: needinfo?(dholbert)

    
    

    
  
Please reopen this bug and set approppriate status.

    
    

    
  
> https://www.w3.org/TR/html5/rendering.html#replaced-elements
> 
> This document has valid status W3C RECOMMENDATION. It isn't living standard
> or working draft or editors draft. 

True, but this cocument is not relevant for browser development, it's out of date before adoption.
What _all_ browser vendors aim to implement is:

https://html.spec.whatwg.org/multipage/rendering.html#replaced-elements
  "The following elements can be replaced elements:
   applet, audio, canvas, embed, iframe, img, input, object, and video."

Interestingly MDN docs  https://developer.mozilla.org/en-US/docs/Web/CSS/Replaced_element  state:
  "The only form control that is also a replaced element is <input> of the image type. All other form controls
   are non-replaced elements."

So do we need a spec clarification? Is <input> a replaced element or not? Why "can" it be?
If <input> is a replaced element, MNN docs are wrong,
if not, this is a valid bug.

    
    

    
  
(In reply to j.j. from comment #17)
> So do we need a spec clarification? Is <input> a replaced element or not?
> Why "can" it be?

Presumably the spec authors didn't want to bother being over-specific on this point.  That's their bad, I guess.

In practice, yes, <input> is a replaced element.  Please see comment 10 for how you can clearly tell in a different context (whether the element honors display:block by stretching to fill the viewport or not).  Do you see any other spec justification for why IE/Edge don't stretch the elements in that comment's testcase?  I assert it's because those elements are replaced.

I do agree that the spec could be clearer here -- perhaps one of you would be up for emailing the whatwg list to request clarification on this?

> If <input> is a replaced element, MNN [sic] docs are wrong,

It looks like that MDN tweak was only made 2 months ago:
https://developer.mozilla.org/en-US/docs/Web/CSS/Replaced_element$compare?locale=en-US&to=1268499&from=1068642
... with the editor referencing the very chunk of spec text we're discussing.

(I think they perhaps missed the spec paragraph that j.j. mentioned -- or perhaps they interpreted "can be" to mean that only some sorts of input elements are replaced? Anyway, I'll go ahead and revert that MDN tweak.)
Flags: needinfo?(dholbert)

    
    

    
  
I filed a bug on the HTML spec, for what it's worth: https://github.com/whatwg/html/issues/2948

    
    

    
  
(In reply to j.j. from comment #17)
> > https://www.w3.org/TR/html5/rendering.html#replaced-elements
> > 
> > This document has valid status W3C RECOMMENDATION. It isn't living standard
> > or working draft or editors draft. 
> 
> True, but this cocument is not relevant for browser development, it's out of
> date before adoption.
> What _all_ browser vendors aim to implement is:
> 
> https://html.spec.whatwg.org/multipage/rendering.html#replaced-elements
>   "The following elements can be replaced elements:
>    applet, audio, canvas, embed, iframe, img, input, object, and video."
> 
> Interestingly MDN docs 
> https://developer.mozilla.org/en-US/docs/Web/CSS/Replaced_element  state:
>   "The only form control that is also a replaced element is <input> of the
> image type. All other form controls
>    are non-replaced elements."
> 
> So do we need a spec clarification? Is <input> a replaced element or not?
> Why "can" it be?
> If <input> is a replaced element, MNN docs are wrong,
> if not, this is a valid bug.

If all controls can be described with use of W3C, the controls NO LONGER need to be replaced elements. The IMG layout cannot be described with standard W3C CSS and... it is replaced element. I partially (private) described only img if it is scaled via width but I cannot describe behaviour of image if is scaled via only height. It means: it is still replaced. image[type="text"] etc., buttons and etc. can be described with CSS2 or CSS3. 

Hmm. In the whatwg documentation (ONLY LIVING STANDARD) no words for TEXTAREA (in HTML5 non-replaced) and BUTTON (due to W3C and WHATWG also non-replaced).

W3C (due to "RECOMMENDATION" and primary priority of W3C requirements) shall have greater priority during implementation.

Living standard... with today date... Well, this is embarrassing. 

I think: Mozilla should start implementation of HTML5 standard for non-replaced elements instead of change the specification. SPEC is SPEC, developers works with this specification and developers are annoying that recommendation is not implemented. 

Please file bug to whatwg to change "input" to "input[type=image i]".

    
    

    
  
Please change status of this bug. IT IS NOT RESOLVED and IT IS NOT INVALID. I cannot change status for the moment.
Flags: needinfo?(dholbert)

    
    

    
  
(In reply to Vader from comment #20)
> W3C (due to "RECOMMENDATION" and primary priority of W3C requirements) shall
> have greater priority during implementation.

Sorry, that's just not the reality. Browser implementors treat the WHATWG version of the HTML spec as the definitive source. As I recall, the W3C version is just a snapshot of the WHATWG version, too, so it's not really that different (just older / less-maintained).

> Living standard... with today date... Well, this is embarrassing. 

That simply means it receives bug fixes and is updated to reflect reality.

> I think: Mozilla should start implementation of HTML5 standard for
> non-replaced elements instead of change the specification. SPEC is SPEC,
> developers works with this specification and developers are annoying that
> recommendation is not implemented. 

Specs are not magic received truth, and sometimes they're wrong or impractical, or aren't compatible with the web as it exists.  Some specs are written retrospectively, in an attempt to describe/rationalize behavior that browsers are already shipping (and they may do so incorrectly / with missing parts).  And sometimes they're internally inconsistent and self-contradictory.  Here we have a mix of these (partially covered by the WHATWG bug that I filed in comment 19).

Let me be clear: it would be extremely impractical and unwise for us to make a change...
 - ...based on exactly 1 other implementation (representing a minority of users) which seems to be inconsistent with itself (regarding which form elements get the replaced-element behavior & under what circumstances).
 - ...*away* from our current behavior which happens to match the majority of web browsers (in terms of market-share and number-of-engines) & hence which sites may have come to depend on.
 - ...*to* a behavior which is specced in vague & internally-inconsistent spec language, which may have been written retroactively/descriptively rather than prescriptively anyway, and which isn't implemented coherently anywhere right now.

Given that, this bug is going to remain closed. INVALID seems appropriate to me since there is no clear/internally-consistent spec language that we are violating right now -- though if it'd make you happier, I'm happy to change it to WONTFIX instead of INVALID.  The result is the same, though, so it doesn't much matter.

> Please file bug to whatwg to change "input" to "input[type=image i]".

I'm not sure what you're asking here, but in any case, you are free to do this yourself if there's a change you'd like to see made in the spec. I already filed a spec bug that covers the spec issue here as I see it.

(In reply to Vader from comment #21)
> Please change status of this bug. IT IS NOT RESOLVED and IT IS NOT INVALID.
> I cannot change status for the moment.

I'm not going to reopen this bug, sorry.  Please re-read my statements above and try to understand why it's not rational for us to change here, given the current state of the spec & other implementations.
Flags: needinfo?(dholbert)

    
    

    
  
But the textarea due to WHATWG is non-replaced alement, BUTTON also. 

It means, I should open new issues for BUTTON and TEXTAREA?

BTW. Please put button inside TD and set height 100% and add border:10px solid #ff0000. Does "all" browsers render it identical? After adding box-sizing:content-box, it looks more weird. All browsers render it differently.
https://plnkr.co/edit/WvEqNCxEcLY5yS1IT738?p=preview

Because the behaviour of "replaced elements" is unpredictable, this is time to remove Quirx Mode v1.1 if document is declared as html5. 

Change of INPUT, BUTTON and TEXTAREA to non-replaced elements shall be not invasive for old pages written with using html5. 

BTW. TECH EVANGELISM will a more proper status if OPEN is bad.
Flags: needinfo?(dholbert)

    
    

    
  
(In reply to Vader from comment #23)
> But the textarea due to WHATWG is non-replaced alement, BUTTON also. 
> 
> It means, I should open new issues for BUTTON and TEXTAREA?

I don't think you should new issues for either of those here in this Mozilla bug-tracker, if that's what you're asking. As I recall, all browsers agree on <textarea> sizing (they all size it as if it were a replaced element). So, it doesn't seem productive to file a specific Mozilla bug on that.  RE button, I think it's in the same category as <input type="button"> (and it's similarly covered by my above-filed WHATWG spec issue), so that doesn't seem productive to file a separate bug on that either.

If you're asking about WHATWG issues: maybe? It might be worth filing an issue on the fact that <textarea> is specced as non-replaced and yet browsers size it as if it were replaced; I don't know. That may eventually be addressed via the github issue I already filed, though.

> Does "all" browsers render it identical? After adding box-sizing:content-box,
> it looks more weird. All browsers render it differently.
> https://plnkr.co/edit/WvEqNCxEcLY5yS1IT738?p=preview

That plnkr looks the same to me in Firefox, Edge, and Chrome.  I'm not sure what you're trying to get across here.

> BTW. TECH EVANGELISM will a more proper status if OPEN is bad.

The Tech Evangelism component means "we need to do outreach to this specific website to convince them to change their code [and the bug tracks that outreach]".  That is not the case here.

Please stop needinfo'ing me here - I'm not really interested in further discussion on this issue.
Flags: needinfo?(dholbert)

    
    

    
  
Looks like this was actually filed many years back as bug 733914 -- I'm going to dupe this bug over to that one, so that the issue is better-represented in a single place.
Resolution: INVALID → DUPLICATE

    
    

    
  
If it is duplicated, not by me, it mesans: It is strongly embarrassing. Due specification TEXTAREA and BUTTON are at the moment non-replaced elements and people ASKED about it because the specification is ignored and developers are annoying. 

BTW. ALL BROWSERS reach 100/100 in acid3. Except of Firefox. It means: if only Firefox behaviour is other, the Firefox shall fix it. It is your thinking.

    
    

    
  
(In reply to Vader from comment #26)
> If it is duplicated, not by me, it mesans: It is strongly embarrassing. 

The duplicate was filed 6 years ago -- and we noted that this behavior was underspecified at the time (and still is).  Also, apparently in the time since that bug was filed, browsers have converged on Firefox's behavior, not on the behavior that you're asking for.

> BTW. ALL BROWSERS reach 100/100 in acid3. Except of Firefox. It means: if
> only Firefox behaviour is other, the Firefox shall fix it. It is your
> thinking.

The Acid3 issue is fixed in Nightly, via bug 1325080, but Acid3 has precisely zero to do with anything that's been discussed on this bug, so I'm not sure why you brought that up.


We try to maintain a positive & collaborative atmosphere - I've done my best to treat with you with respect on this bug, but your recent series of comments have seemed pretty demanding, aggressive, and shouty.  Please take a step back and reconsider your interaction style, and read the bugzilla etiquette & please try to behave respectfully from here on out:
  https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

(Also: if this bug is causing you trouble [and I imagine it must be given how strongly you've been pushing here], keep in mind that you've got bigger problems than just convincing Mozilla to change behavior -- e.g. Chrome, the majority player, has the exact same rendering behavior that we do in this case.  So if your website depends on this behavior, the best use of your time is *not* to try to get us to change away from the current consensus behavior, but rather to apply one of the interoperable workarounds suggested back in comment 10 or comment 12. And in the meantime, hopefully the WHATWG spec-bug will get some further traction and the spec+browsers will converge on some behavior that makes sense.)

    
    

    
  
(Ah, I see there's another Acid3 failure which is a test bug, which is bug 1311329. Anyway, as noted, not at all related to this bug here.)

    
    

    
  
It is not bug. All other browsers interprets it identically except of Firefox for Windows/Linux. It means, due your words, the spec shall be corrected and behaviour of Firefox.

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: