It's not. The relevant code in this case is https://searchfox.org/mozilla-central/rev/b3b401254229f0a26f7ee625ef5f09c6c31e3949/dom/html/nsGenericHTMLElement.cpp#1041-1042 which lands you in https://searchfox.org/mozilla-central/source/dom/base/nsAttrValue.cpp#1257,1264 so "-100" gets parsed as "0". Spec requires "valid non-negative integers" as an author conformance requirement at <https://html.spec.whatwg.org/multipage/embedded-content-other.html#attr-dim-width>. In terms of the parsing behavior, the spec says to do https://html.spec.whatwg.org/multipage/rendering.html#dimRendering which links to https://html.spec.whatwg.org/multipage/rendering.html#maps-to-the-dimension-property which says to use https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#rules-for-parsing-dimension-values which returns an error at step 7 in this case. So seems like we shouldn't be storing the value as an int if it came back negative... The docs on `ParseSpecialIntValue` say it implements https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#rules-for-parsing-dimension-values but it doesn't seem to actually do what that algorithm says. We use `ParseSpecialIntValue` in the following cases: * `<frame marginwidth>`. Spec says to use https://html.spec.whatwg.org/#maps-to-the-pixel-length-property which uses "rules for parsing non-negative integers". Chrome and Safari follow the spec. * `<frame marginheight>`. Same thing. * `<iframe marginwidth>`. Same thing. * `<iframe marginheight>`. Same thing. * `<hr width>`. Spec says to use <https://html.spec.whatwg.org/#maps-to-the-dimension-property> and Chrome/Safari seem to follow the spec. * `<iframe width>`. Same thing. * `<iframe height>`. Same thing. * `<input width>`. Same thing. * `<input height>`. Same thing. * `<marquee width>`. Same thing. * `<marquee height>`. Same thing. * `<video width>`. Same thing. * `<video height>`. Same thing. * <object/embed/img width/height>`. Same thing. * `<td width>`. Spec says to use <https://html.spec.whatwg.org/#maps-to-the-dimension-property-(ignoring-zero)>. Our code ignores the value if it's <= 0 in `HTMLTableCellElement::MapAttributesIntoRule` so we actually match the spec here. * `<td height>`. Same thing. * `<table width>`. Same thing, but 0 (and hence negatives) ignored in `HTMLTableElement::ParseAttribute` in our code. Chrome/Safari allow 0. * `<table height>`. Same thing per spec. In our code we will parse and clamp negatives to 0 and if you style the table with `display: block` you get layout that does not match the spec or Chrome/Safari. That said, Chrome/Safari allow 0, just not negatives. Filed https://github.com/whatwg/html/issues/4715 on this and the `<table width>` thing. * `<tr height>`. Same thing per spec. Safari and Chrome allow 0, but not negatives. Filed https://github.com/whatwg/html/issues/4716 * `<col width>`. Same thing per spec. In our code we parse and clamp negatives to 0. Something like `<table><colgroup><col width="-100">` with all styled as `display:block` and some script-added text inside the `<col>` renders wrong (0 width, not auto) in Gecko. Chrome and Safari allow 0, but not negatives. Filed https://github.com/whatwg/html/issues/4717 * `<col charoff>`. Really doesn't matter what we do here; its value is unused except in reflection. * `<tr width>`. Really doesn't matter what we do here; its value is unused. Per spec it's not special. * table section `height` attribute. Per spec this is not special. Chrome and Safari allow 0 but not negatives. Filed https://github.com/whatwg/html/issues/4718
Bug 1560055 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
It's not. The relevant code in this case is https://searchfox.org/mozilla-central/rev/b3b401254229f0a26f7ee625ef5f09c6c31e3949/dom/html/nsGenericHTMLElement.cpp#1041-1042 which lands you in https://searchfox.org/mozilla-central/source/dom/base/nsAttrValue.cpp#1257,1264 so "-100" gets parsed as "0". Spec requires "valid non-negative integers" as an author conformance requirement at <https://html.spec.whatwg.org/multipage/embedded-content-other.html#attr-dim-width>. In terms of the parsing behavior, the spec says to do https://html.spec.whatwg.org/multipage/rendering.html#dimRendering which links to https://html.spec.whatwg.org/multipage/rendering.html#maps-to-the-dimension-property which says to use https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#rules-for-parsing-dimension-values which returns an error at step 7 in this case. So seems like we shouldn't be storing the value as an int if it came back negative... The docs on `ParseSpecialIntValue` say it implements https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#rules-for-parsing-dimension-values but it doesn't seem to actually do what that algorithm says. We use `ParseSpecialIntValue` in the following cases: * `<frame marginwidth>`. Spec says to use https://html.spec.whatwg.org/#maps-to-the-pixel-length-property which uses "rules for parsing non-negative integers". Chrome and Safari follow the spec. * `<frame marginheight>`. Same thing. * `<iframe marginwidth>`. Same thing. * `<iframe marginheight>`. Same thing. * `<hr width>`. Spec says to use <https://html.spec.whatwg.org/#maps-to-the-dimension-property> and Chrome/Safari seem to follow the spec. * `<iframe width>`. Same thing. * `<iframe height>`. Same thing. * `<input width>`. Same thing. * `<input height>`. Same thing. * `<marquee width>`. Same thing. * `<marquee height>`. Same thing. * `<video width>`. Same thing. * `<video height>`. Same thing. * `<object/embed/img width/height>`. Same thing. * `<td width>`. Spec says to use <https://html.spec.whatwg.org/#maps-to-the-dimension-property-(ignoring-zero)>. Our code ignores the value if it's <= 0 in `HTMLTableCellElement::MapAttributesIntoRule` so we actually match the spec here. * `<td height>`. Same thing. * `<table width>`. Same thing, but 0 (and hence negatives) ignored in `HTMLTableElement::ParseAttribute` in our code. Chrome/Safari allow 0. * `<table height>`. Same thing per spec. In our code we will parse and clamp negatives to 0 and if you style the table with `display: block` you get layout that does not match the spec or Chrome/Safari. That said, Chrome/Safari allow 0, just not negatives. Filed https://github.com/whatwg/html/issues/4715 on this and the `<table width>` thing. * `<tr height>`. Same thing per spec. Safari and Chrome allow 0, but not negatives. Filed https://github.com/whatwg/html/issues/4716 * `<col width>`. Same thing per spec. In our code we parse and clamp negatives to 0. Something like `<table><colgroup><col width="-100">` with all styled as `display:block` and some script-added text inside the `<col>` renders wrong (0 width, not auto) in Gecko. Chrome and Safari allow 0, but not negatives. Filed https://github.com/whatwg/html/issues/4717 * `<col charoff>`. Really doesn't matter what we do here; its value is unused except in reflection. * `<tr width>`. Really doesn't matter what we do here; its value is unused. Per spec it's not special. * table section `height` attribute. Per spec this is not special. Chrome and Safari allow 0 but not negatives. Filed https://github.com/whatwg/html/issues/4718