"0" should not be an error in "rules for parsing dimension values"

[zcorpan]

https://html.spec.whatwg.org/multipage/rendering.html#dimRendering

The width and height attributes on applet, embed, iframe, img, object or video elements, and input elements with a type attribute in the Image Button state and that either represents an image or that the user expects will eventually represent an image, map to the dimension properties 'width' and 'height' on the element respectively.

https://html.spec.whatwg.org/multipage/infrastructure.html#rules-for-parsing-dimension-values

(6) Collect a sequence of characters that are U+0030 DIGIT ZERO (0) characters, and discard them.
(7) If position is past the end of input, return an error.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3638
is different from
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3639
(at least in webkit/blink/gecko, haven't checked IE/Edge)

so this algorithm should be able to return 0 instead of error. But we need to check other uses and check if they want to apply 0 or not.

[zcorpan]

• img width height
  • http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3642
  • Everyone supports "0"
  • Gecko turns "0.9%" to "0%", WebKit/Blink/IE11 don't
• table width height
  • http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3644
  • "0" and "0%" should be ignored
  • Gecko/IE11 ignore "0.1" and "0.1%"
  • WebKit/Blink ignore width:0 in CSS
• col width
  • http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3645
  • IE11 ignores "0", "0.1", "0.1%"
  • Gecko applies "0" but ignores "0%" and "0.1%"
  • Blink/WebKit ignore small values (in the above, < 6px)
• tr height
  • http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3647
  • Gecko applies height=1 and height=1% and style=height:0.9% but ignores 0, 0%, style=height:0, 0.9, 0.9%
  • WebKit/Blink apply all
  • IE11 applies 1, 1%, style=height:0, style=height=0.9%; ignores 0, 0%, 0.9, 0.9%
• th/td width
  • http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3648
  • Gecko/IE11 apply 1, style=width:0, 1%; ignores 0, 0%, style=width:0%, 0.9, 0.9%
  • WebKit/Blink apply 1, 1%; ignores the others
• th/td height
  • http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3649
  • Gecko applies 1, style=height:0, 1%, ignores 0, 0%, style=height:0%, 0.9, 0.9%
  • WebKit/Blink apply 1, 1%, ignore the others
  • IE11 applies 1, style=height:0, style=height:0%, 1%; ignores the others
• hr width
  • http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3650
  • Gecko/WebKit/Blink apply all, but 0.9% is interpreted as 0
  • IE11 applies all; 0.9% is properly supported
• applet, embed, iframe, img, object, input[type=image], marquee vspace hspace (check 0.9%)
  • http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3651 embed vspace
  • http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3653 img vspace
  • 0 is the default, so there is no difference between applying and not applying 0 AFAICT
  • Blink/WebKit support 0.9 and 0.9%. Percentages for vspace refer to the width of the containing block (like the spec, since it maps to margin-top).
  • Gecko ignores 0.9 and 0.9%. Percentages for vspace refer to the height of the containing block.
  • IE11 is like Gecko, but doesn't support vspace for embed
• applet, embed, iframe, object, video, input[type=image], marquee width height
  • http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3654 iframe width
  • http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3655 video width
  • http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3656 marquee width
  • like img

• In quirks mode, a td element or a th element that has a nowrap attribute but also has a width attribute whose value, when parsed using the rules for parsing dimension values, is found to be a length (not an error or a number classified as a percentage), is expected to have a presentational hint setting the element's 'white-space' property to 'normal', overriding the rule in the CSS block above that sets it to 'nowrap'.

  • http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3657
  • IE11/Gecko/WebKit/Blink don't reset white-space for width=0.
  • WebKit/Blink have this quirk in standards mode, too.

[zcorpan]

I'm tempted to make everything here support 0.

@dbaron do you happen to know if something here is known to break the Web if 0 is supported (e.g. <td width=0>)?

[dbaron]

I think when I was rewriting table width calculation in Gecko, I discovered pretty quickly that width=0 needed to be ignored. So I suspect the Web does rely on that, although I'm not sure.

[dbaron]

Then again, I'm clearly misremembering, since I didn't rewrite that part. I probably discovered it quickly while writing my own testcases.

[dbaron]

(Though it might be that some browsers ignore the CSS 'width: 0px' on table cells, and some don't, leaving the quirkiness only in the HTML attribute parsing. So it might be Web-compatible in some browsers but not others.)

[zcorpan]

http://webdevdata.org/ data set 2015-01-08 (780 Mb) 87,000 pages.

$ find . -type f -print0 | xargs -0 -P 4 -n 40 grep -iEo "<(td|th|col|table|tr)\s([^>]+\s)?(width|height)=[\"']?0%?[\"']?(\s|>)" > ../width-height-0.txt

I inspected the matches in Nightly and applied width:0 or height:0 as appropriate in devtools to see if the rendered result was affected. 20 first URLs were unaffected (some had changed), then I found one that regressed its rendering:

http://magiran.com/

current rendering:

style="width:0"

So I suppose we should keep ignoring 0 and 0% for the table-related elements...

[zcorpan]

(The above PR referenced this issue by mistake; now fixed.)