TextArea in Chrome has 2px more than in other browsers #126

Closed
SharpNoiZy opened this Issue Sep 13, 2012 · 27 comments

Comments

@SharpNoiZy

Can you maybe somehow normalize/fix this.
This is realy bad.

<input type="text" style="width: 200px">
<textarea style="width: 200px"></textarea>

Looks great in IE, both boxes have the same length, but in Google Chrome the textarea has 2px more width ;(

Best regards

@necolas

This comment has been minimized.

Show comment Hide comment
@necolas

necolas Sep 13, 2012

Owner

I'm not seeing it: http://jsbin.com/ibadan/1/

Owner

necolas commented Sep 13, 2012

I'm not seeing it: http://jsbin.com/ibadan/1/

@SharpNoiZy

This comment has been minimized.

Show comment Hide comment
@SharpNoiZy

SharpNoiZy Sep 13, 2012

I see it also on your site?!

Can I somehow add an Screenshot to GitHub?

I see it also on your site?!

Can I somehow add an Screenshot to GitHub?

@necolas

This comment has been minimized.

Show comment Hide comment
@necolas

necolas Sep 13, 2012

Owner

Make a reduced test case please, and provide details on your test environment.
The test case above doesn't result in any extra width in Chrome.
Firefox has some differences due to the different border widths.

Owner

necolas commented Sep 13, 2012

Make a reduced test case please, and provide details on your test environment.
The test case above doesn't result in any extra width in Chrome.
Firefox has some differences due to the different border widths.

@SharpNoiZy

This comment has been minimized.

Show comment Hide comment
@SharpNoiZy

SharpNoiZy Sep 13, 2012

Like I said, I see extra width on the url you post above!
http://jsbin.com/ibadan/1/

So, I can show you on a screenshot.

Like I said, I see extra width on the url you post above!
http://jsbin.com/ibadan/1/

So, I can show you on a screenshot.

@walterdavis

This comment has been minimized.

Show comment Hide comment
@walterdavis

walterdavis Sep 13, 2012

I see a narrower textarea field in Firefox. Chrome and Safari are identical (Mac OS X 10.7). Screenshot = Safari, Chrome, Firefox top to bottom.

On Sep 13, 2012, at 9:58 AM, NoiZy wrote:

Like I said, I see extra width on the url you post above!
http://jsbin.com/ibadan/1/

So, I can show you on a screenshot.


Reply to this email directly or view it on GitHub.

I see a narrower textarea field in Firefox. Chrome and Safari are identical (Mac OS X 10.7). Screenshot = Safari, Chrome, Firefox top to bottom.

On Sep 13, 2012, at 9:58 AM, NoiZy wrote:

Like I said, I see extra width on the url you post above!
http://jsbin.com/ibadan/1/

So, I can show you on a screenshot.


Reply to this email directly or view it on GitHub.

@necolas

This comment has been minimized.

Show comment Hide comment
@necolas

necolas Sep 13, 2012

Owner

@noizy Use imgur. But a screenshot alone isn't going to help when 2 other people running WebKit browsers see no difference. I need to know your details about your environment.

@walterdavis Can't see your screenshot. Paste a URL please.

Owner

necolas commented Sep 13, 2012

@noizy Use imgur. But a screenshot alone isn't going to help when 2 other people running WebKit browsers see no difference. I need to know your details about your environment.

@walterdavis Can't see your screenshot. Paste a URL please.

@walterdavis

This comment has been minimized.

Show comment Hide comment
@walterdavis

walterdavis Sep 13, 2012

http://scripty.walterdavisstudio.com/text_fields.png

The ugly orange background in Firefox is because I set a default background color in the browser prefs to remind me to set that attribute in CSS.

Walter

On Sep 13, 2012, at 11:01 AM, Nicolas Gallagher wrote:

@noizy Use imgur. But a screenshot alone isn't going to help when 2 other people running WebKit browsers see no difference. I need to know your details about your environment.

@walterdavis Can't see your screenshot. Paste a URL please.


Reply to this email directly or view it on GitHub.

http://scripty.walterdavisstudio.com/text_fields.png

The ugly orange background in Firefox is because I set a default background color in the browser prefs to remind me to set that attribute in CSS.

Walter

On Sep 13, 2012, at 11:01 AM, Nicolas Gallagher wrote:

@noizy Use imgur. But a screenshot alone isn't going to help when 2 other people running WebKit browsers see no difference. I need to know your details about your environment.

@walterdavis Can't see your screenshot. Paste a URL please.


Reply to this email directly or view it on GitHub.

@DiehlC

This comment has been minimized.

Show comment Hide comment
@DiehlC

DiehlC Sep 13, 2012

Same computer? OSx or Windows or Linux? Px or other relative units of measurement? Are all your browsers default font size set to the default 16pt? Which browser Version? & are theyre any other things you can think of that may effect the different browsers?-------- Original Message -------- From: walterdavis Sent: Thu, Sep 13, 2012 11:59 AM To: necolas/normalize.css CC: Subject: Re: [normalize.css] TextArea in Chrome has 2px more than in other browsers (#126)http://scripty.walterdavisstudio.com/text_fields.png

The ugly orange background in Firefox is because I set a default background color in the browser prefs to remind me to set that attribute in CSS.

Walter

On Sep 13, 2012, at 11:01 AM, Nicolas Gallagher wrote:

@noizy Use imgur. But a screenshot alone isn't going to help when 2 other people running WebKit browsers see no difference. I need to know your details about your environment.

@walterdavis Can't see your screenshot. Paste a URL please.

Reply to this email directly or view it on GitHub.

          —
          Reply to this email directly or view it on GitHub.

DiehlC commented Sep 13, 2012

Same computer? OSx or Windows or Linux? Px or other relative units of measurement? Are all your browsers default font size set to the default 16pt? Which browser Version? & are theyre any other things you can think of that may effect the different browsers?-------- Original Message -------- From: walterdavis Sent: Thu, Sep 13, 2012 11:59 AM To: necolas/normalize.css CC: Subject: Re: [normalize.css] TextArea in Chrome has 2px more than in other browsers (#126)http://scripty.walterdavisstudio.com/text_fields.png

The ugly orange background in Firefox is because I set a default background color in the browser prefs to remind me to set that attribute in CSS.

Walter

On Sep 13, 2012, at 11:01 AM, Nicolas Gallagher wrote:

@noizy Use imgur. But a screenshot alone isn't going to help when 2 other people running WebKit browsers see no difference. I need to know your details about your environment.

@walterdavis Can't see your screenshot. Paste a URL please.

Reply to this email directly or view it on GitHub.

          —
          Reply to this email directly or view it on GitHub.
@walterdavis

This comment has been minimized.

Show comment Hide comment
@walterdavis

walterdavis Sep 13, 2012

OS X 10.7.4, all default everything. Latest public version of all three browsers (not nightly or anything odd). Chrome and Safari are identical to my eye. Firefox is the big problem. Not what the OP was saying at all.

Walter

On Sep 13, 2012, at 1:03 PM, DiehlC wrote:

Same computer? OSx or Windows or Linux? Px or other relative units of measurement? Are all your browsers default font size set to the default 16pt? Which browser Version? & are theyre any other things you can think of that may effect the different browsers?-------- Original Message -------- From: walterdavis Sent: Thu, Sep 13, 2012 11:59 AM To: necolas/normalize.css CC: Subject: Re: [normalize.css] TextArea in Chrome has 2px more than in other browsers (#126)http://scripty.walterdavisstudio.com/text_fields.png

The ugly orange background in Firefox is because I set a default background color in the browser prefs to remind me to set that attribute in CSS.

Walter

On Sep 13, 2012, at 11:01 AM, Nicolas Gallagher wrote:

@noizy Use imgur. But a screenshot alone isn't going to help when 2 other people running WebKit browsers see no difference. I need to know your details about your environment.

@walterdavis Can't see your screenshot. Paste a URL please.

Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.

OS X 10.7.4, all default everything. Latest public version of all three browsers (not nightly or anything odd). Chrome and Safari are identical to my eye. Firefox is the big problem. Not what the OP was saying at all.

Walter

On Sep 13, 2012, at 1:03 PM, DiehlC wrote:

Same computer? OSx or Windows or Linux? Px or other relative units of measurement? Are all your browsers default font size set to the default 16pt? Which browser Version? & are theyre any other things you can think of that may effect the different browsers?-------- Original Message -------- From: walterdavis Sent: Thu, Sep 13, 2012 11:59 AM To: necolas/normalize.css CC: Subject: Re: [normalize.css] TextArea in Chrome has 2px more than in other browsers (#126)http://scripty.walterdavisstudio.com/text_fields.png

The ugly orange background in Firefox is because I set a default background color in the browser prefs to remind me to set that attribute in CSS.

Walter

On Sep 13, 2012, at 11:01 AM, Nicolas Gallagher wrote:

@noizy Use imgur. But a screenshot alone isn't going to help when 2 other people running WebKit browsers see no difference. I need to know your details about your environment.

@walterdavis Can't see your screenshot. Paste a URL please.

Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub.

@mkantor

This comment has been minimized.

Show comment Hide comment
@mkantor

mkantor Sep 13, 2012

On Ubuntu Linux (Gnome 2.30.2), from left to right this is

  • Firefox 15.0.1
  • Chrome 21.0.1180.89
  • Opera 12.02
  • Epiphany 2.30.2

Ubuntu Linux textarea browser comparison

As you can see the textarea is wider in Chrome for me as well.

I'm guessing the inconsistencies in our results come down to browsers trying to have a native look and feel for widgets like these.

mkantor commented Sep 13, 2012

On Ubuntu Linux (Gnome 2.30.2), from left to right this is

  • Firefox 15.0.1
  • Chrome 21.0.1180.89
  • Opera 12.02
  • Epiphany 2.30.2

Ubuntu Linux textarea browser comparison

As you can see the textarea is wider in Chrome for me as well.

I'm guessing the inconsistencies in our results come down to browsers trying to have a native look and feel for widgets like these.

@marcj

This comment has been minimized.

Show comment Hide comment
@marcj

marcj Sep 13, 2012

I have some weird textarea-widths here, too.

Yay

marcj commented Sep 13, 2012

I have some weird textarea-widths here, too.

Yay

@staabm

This comment has been minimized.

Show comment Hide comment
@staabm

staabm Sep 13, 2012

Maybe browser scaled font size (increased per ctrl+"+") ?

staabm commented Sep 13, 2012

Maybe browser scaled font size (increased per ctrl+"+") ?

@walterdavis

This comment has been minimized.

Show comment Hide comment
@walterdavis

walterdavis Sep 13, 2012

Not here. All default, all the time.

On Sep 13, 2012, at 1:50 PM, Markus Staab wrote:

Maybe browser scaled font size (increased per ctrl+"+") ?


Reply to this email directly or view it on GitHub.

Not here. All default, all the time.

On Sep 13, 2012, at 1:50 PM, Markus Staab wrote:

Maybe browser scaled font size (increased per ctrl+"+") ?


Reply to this email directly or view it on GitHub.

@yopming

This comment has been minimized.

Show comment Hide comment
@yopming

yopming Sep 14, 2012

Chrome is normal, but Firefox is not(OSX 10.8.1)
Firefox is werid

yopming commented Sep 14, 2012

Chrome is normal, but Firefox is not(OSX 10.8.1)
Firefox is werid

@thezoggy

This comment has been minimized.

Show comment Hide comment
@thezoggy

thezoggy Sep 14, 2012

inspect the box and see whats applied/computed for the width. i would assume theres some sort of browser specific css being applied / boxsizing (border-box?) thing going on

loaded up the jsbin, it's also off for me on ff14.0.1 (osx 10.6.8). noticed that you link to an older normalize, changed link to
https://raw.github.com/necolas/normalize.css/master/normalize.css and see a bit of a different result.. still off though.

inspected the text-box, i see:
that firefox is doing: border: 2px inset threedface; via it's user-agent
if i set the text box border to: border: 1px solid #ff0000
then everything aligns.

for ref, user-agent being applied by the browser:

input {
    -moz-appearance: textfield;
    -moz-binding: url("chrome://global/content/platformHTMLBindings.xml#inputFields");
    -moz-user-select: text;
    background-color: -moz-field;
    border: 2px inset threedface;
    color: -moz-fieldtext;
    cursor: text;
    font: -moz-field;
    letter-spacing: normal;
    line-height: normal !important;
    padding: 1px 0;
    text-align: start;
    text-indent: 0;
    text-rendering: optimizelegibility;
    text-shadow: none;
    text-transform: none;
    word-spacing: normal;
}

however the same border is being applied already to textarea.. so not really sure why there is a difference

textarea {
    -moz-appearance: textfield-multiline;
    -moz-binding: url("chrome://global/content/platformHTMLBindings.xml#textAreas");
    -moz-user-select: text;
    background-color: -moz-field;
    border: 2px inset threedface;
    color: -moz-fieldtext;
    cursor: text;
    font: medium -moz-fixed;
    letter-spacing: normal;
    margin: 1px 0;
    resize: both;
    text-align: start;
    text-indent: 0;
    text-rendering: optimizelegibility;
    text-shadow: none;
    text-transform: none;
    vertical-align: text-bottom;
    word-spacing: normal;
    word-wrap: break-word;
}

inspect the box and see whats applied/computed for the width. i would assume theres some sort of browser specific css being applied / boxsizing (border-box?) thing going on

loaded up the jsbin, it's also off for me on ff14.0.1 (osx 10.6.8). noticed that you link to an older normalize, changed link to
https://raw.github.com/necolas/normalize.css/master/normalize.css and see a bit of a different result.. still off though.

inspected the text-box, i see:
that firefox is doing: border: 2px inset threedface; via it's user-agent
if i set the text box border to: border: 1px solid #ff0000
then everything aligns.

for ref, user-agent being applied by the browser:

input {
    -moz-appearance: textfield;
    -moz-binding: url("chrome://global/content/platformHTMLBindings.xml#inputFields");
    -moz-user-select: text;
    background-color: -moz-field;
    border: 2px inset threedface;
    color: -moz-fieldtext;
    cursor: text;
    font: -moz-field;
    letter-spacing: normal;
    line-height: normal !important;
    padding: 1px 0;
    text-align: start;
    text-indent: 0;
    text-rendering: optimizelegibility;
    text-shadow: none;
    text-transform: none;
    word-spacing: normal;
}

however the same border is being applied already to textarea.. so not really sure why there is a difference

textarea {
    -moz-appearance: textfield-multiline;
    -moz-binding: url("chrome://global/content/platformHTMLBindings.xml#textAreas");
    -moz-user-select: text;
    background-color: -moz-field;
    border: 2px inset threedface;
    color: -moz-fieldtext;
    cursor: text;
    font: medium -moz-fixed;
    letter-spacing: normal;
    margin: 1px 0;
    resize: both;
    text-align: start;
    text-indent: 0;
    text-rendering: optimizelegibility;
    text-shadow: none;
    text-transform: none;
    vertical-align: text-bottom;
    word-spacing: normal;
    word-wrap: break-word;
}
@waldyrious

This comment has been minimized.

Show comment Hide comment
@waldyrious

waldyrious Sep 14, 2012

This issue sounds quite similar to a bug I once encountered, which had to do with the default font family of the input elements. However, in that case the inconsistency was because I was trying to size the boxes using em (font-dependent) values, rather than px as in this case, so I am not sure the same explanation is valid here. Still, I'm mentioning it here, hoping that it might spur some ideas about how to tackle this problem.

This issue sounds quite similar to a bug I once encountered, which had to do with the default font family of the input elements. However, in that case the inconsistency was because I was trying to size the boxes using em (font-dependent) values, rather than px as in this case, so I am not sure the same explanation is valid here. Still, I'm mentioning it here, hoping that it might spur some ideas about how to tackle this problem.

@gero3

This comment has been minimized.

Show comment Hide comment
@gero3

gero3 Dec 23, 2012

This is on chrome 25.0.1364.5 dev-m on windows

this is the input
input

This is the textarea
textarea

gero3 commented Dec 23, 2012

This is on chrome 25.0.1364.5 dev-m on windows

this is the input
input

This is the textarea
textarea

@CrocoDillon

This comment has been minimized.

Show comment Hide comment
@CrocoDillon

CrocoDillon Feb 5, 2013

Tested http://jsbin.com/ibadan/8 on Windows 8:

  • Chrome 24

    input 204px (200px + 2x2px border)

    textarea 206px (200px + 2x2px padding + 2x1px border)
  • Firefox 17

    both 206px (200px + 2x2px padding +2x1px border)
  • Internet Explorer 10

    input 204px (200px + 2x1px padding + 2x1px border)

    textarea 206px (200px + 2x2px padding + 2x1px border)

Here comes the interesting part... when going to edit mode in jsbin everything changes.
All 3 tested browsers show both elements at 200px total by applying user agent box-sizing:border-box

Adding the box-sizing:border-box manually http://jsbin.com/ibadan/11
Works in both view and edit mode on all 3 tested browsers.

Now the question is, what is preventing the user agent style from being applied in view mode?

Tested http://jsbin.com/ibadan/8 on Windows 8:

  • Chrome 24

    input 204px (200px + 2x2px border)

    textarea 206px (200px + 2x2px padding + 2x1px border)
  • Firefox 17

    both 206px (200px + 2x2px padding +2x1px border)
  • Internet Explorer 10

    input 204px (200px + 2x1px padding + 2x1px border)

    textarea 206px (200px + 2x2px padding + 2x1px border)

Here comes the interesting part... when going to edit mode in jsbin everything changes.
All 3 tested browsers show both elements at 200px total by applying user agent box-sizing:border-box

Adding the box-sizing:border-box manually http://jsbin.com/ibadan/11
Works in both view and edit mode on all 3 tested browsers.

Now the question is, what is preventing the user agent style from being applied in view mode?

@SharpNoiZy

This comment has been minimized.

Show comment Hide comment
@SharpNoiZy

SharpNoiZy Feb 5, 2013

Can confirm what CrocoDillon said, looks good for me too!

My vote please add "box-sizing: border-box;" in normalize.css to all text input elements (text, textarea, password)

And thx to CrocoDillon for finding this one!!

Can confirm what CrocoDillon said, looks good for me too!

My vote please add "box-sizing: border-box;" in normalize.css to all text input elements (text, textarea, password)

And thx to CrocoDillon for finding this one!!

@CrocoDillon

This comment has been minimized.

Show comment Hide comment
@CrocoDillon

CrocoDillon Feb 6, 2013

Yw :) Too bad box-sizing:border-box fails in IE < 8 (in this example it seems to fail in IE8 too, but that's because of the selector)

Good news is I've found out browsers add this rule in quirks mode only:
http://trac.webkit.org/browser/trunk/Source/WebCore/css/quirks.css

Yw :) Too bad box-sizing:border-box fails in IE < 8 (in this example it seems to fail in IE8 too, but that's because of the selector)

Good news is I've found out browsers add this rule in quirks mode only:
http://trac.webkit.org/browser/trunk/Source/WebCore/css/quirks.css

@SharpNoiZy

This comment has been minimized.

Show comment Hide comment
@SharpNoiZy

SharpNoiZy Feb 6, 2013

But in my opion, people how use IE < 8 have much bigger problems then "box-sizing:border-box", don't you think?! :)

So, still my vote, please into normalize.css!

But in my opion, people how use IE < 8 have much bigger problems then "box-sizing:border-box", don't you think?! :)

So, still my vote, please into normalize.css!

@CrocoDillon

This comment has been minimized.

Show comment Hide comment
@CrocoDillon

CrocoDillon Feb 6, 2013

Yeah true, and even without border-box as long as it doesn't break layout they will be fine.

By the way, in the bottom part of test.html most seem to work because of this internal css:

#boxsize button,
#boxsize input,
#boxsize select,
#boxsize textarea {
    width: 200px;
    padding: 5px;
    border: 1px solid #333;
}

Why not normalize padding and border in normalize.css if border-box isn't an option?

Yeah true, and even without border-box as long as it doesn't break layout they will be fine.

By the way, in the bottom part of test.html most seem to work because of this internal css:

#boxsize button,
#boxsize input,
#boxsize select,
#boxsize textarea {
    width: 200px;
    padding: 5px;
    border: 1px solid #333;
}

Why not normalize padding and border in normalize.css if border-box isn't an option?

@TheDutchCoder

This comment has been minimized.

Show comment Hide comment
@TheDutchCoder

TheDutchCoder Mar 17, 2013

For me, Chrome 25.0.1364.172 adds 2px padding to a textarea, better to reset it in normalize.css.

For me, Chrome 25.0.1364.172 adds 2px padding to a textarea, better to reset it in normalize.css.

@atomicframeworks

This comment has been minimized.

Show comment Hide comment
@atomicframeworks

atomicframeworks Jan 9, 2014

Windows 8

  • Chrome: 32

    input 204px ( 200px + 0x1px padding & 2x2px border )

    textarea 206px ( 200px + 2x2px padding & 1x1px border )
  • Firefox: 25.0.1 & Firefox 26 & Firefox 3.6

    input 206px ( 200px + 2x2px padding & 1x1px border )

    textarea 206px ( 200px + 2x2px padding & 1x1px border )
  • IE 11.09

    input 204px ( 200px + 1x2px padding & 1x1px border )

    textarea 206px ( 200px + 2x2px padding & 1x1px border )
  • Opera 18.0

    input 204px ( 200px + 0x1px padding & 2x2px border )

    textarea 206px ( 200px + 2x2px padding & 1x1px border )

Side note that chrome has different border colors as well.
textarea - rgb(0, 0, 0)
input - rgb(238, 238, 238)

The inputs are the same I would suggest normalizing padding and borders to fix these issues.

textarea-and-inputs

Firefox 3.6.28
ff3 6

Windows 8

  • Chrome: 32

    input 204px ( 200px + 0x1px padding & 2x2px border )

    textarea 206px ( 200px + 2x2px padding & 1x1px border )
  • Firefox: 25.0.1 & Firefox 26 & Firefox 3.6

    input 206px ( 200px + 2x2px padding & 1x1px border )

    textarea 206px ( 200px + 2x2px padding & 1x1px border )
  • IE 11.09

    input 204px ( 200px + 1x2px padding & 1x1px border )

    textarea 206px ( 200px + 2x2px padding & 1x1px border )
  • Opera 18.0

    input 204px ( 200px + 0x1px padding & 2x2px border )

    textarea 206px ( 200px + 2x2px padding & 1x1px border )

Side note that chrome has different border colors as well.
textarea - rgb(0, 0, 0)
input - rgb(238, 238, 238)

The inputs are the same I would suggest normalizing padding and borders to fix these issues.

textarea-and-inputs

Firefox 3.6.28
ff3 6

@necolas

This comment has been minimized.

Show comment Hide comment
@necolas

necolas Jan 16, 2014

Owner

Thanks for all the great OS/browser research, screenshots, etc. Really useful and gathers more information than I could ever do alone!

But I don't think this can be taken care of nicely at this level (i.e., in normalize.css), because styling input (especially border) affects the style of a large range of different native UI elements – buttons inputs, color pickers, range sliders, etc.

It doesn't seem to be a practical problem, because any library / application code is going to add custom styles to form elements within components. That will result in these differences going away.

Going to close as "wontfix" for now. But happy to reassess if I've missed anything.

Owner

necolas commented Jan 16, 2014

Thanks for all the great OS/browser research, screenshots, etc. Really useful and gathers more information than I could ever do alone!

But I don't think this can be taken care of nicely at this level (i.e., in normalize.css), because styling input (especially border) affects the style of a large range of different native UI elements – buttons inputs, color pickers, range sliders, etc.

It doesn't seem to be a practical problem, because any library / application code is going to add custom styles to form elements within components. That will result in these differences going away.

Going to close as "wontfix" for now. But happy to reassess if I've missed anything.

@MetalG3arSo1id

This comment has been minimized.

Show comment Hide comment
@MetalG3arSo1id

MetalG3arSo1id Jan 15, 2016

I found the problem in chrome was the wrapper container height was an ODD height value e.g. 401px all borders looked to be 2px. Every time the container height was e.g. 400px all borders within it changed to 1px. This is great news for static content, just style the wrapper container to be of a even height value. But for dynamic content in wrapper containers this sucks, because there is no way of making sure the wrapper height value will be an even or odd number.

I found the problem in chrome was the wrapper container height was an ODD height value e.g. 401px all borders looked to be 2px. Every time the container height was e.g. 400px all borders within it changed to 1px. This is great news for static content, just style the wrapper container to be of a even height value. But for dynamic content in wrapper containers this sucks, because there is no way of making sure the wrapper height value will be an even or odd number.

@MetalG3arSo1id

This comment has been minimized.

Show comment Hide comment
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment