Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

span with display: inline-block is treated as inline #448

Closed
alexneblett opened this issue Aug 10, 2016 · 9 comments
Closed

span with display: inline-block is treated as inline #448

alexneblett opened this issue Aug 10, 2016 · 9 comments

Comments

@alexneblett
Copy link

I am using spans with display: inline-block and width: x% to provide excel like formatting for financial cells within a table. The attached zip demonstrates what I am doing.

The spans containing display: inline-block and width: some% are treated as CM_INLINE rather than CM_MIXED. This causes whitespace between the span elements which increases the height of the cells. Also, if I happen to have div elements inside the spans (for descriptor cells), it causes the html to be rewritten so that inlines are inside blocks. You see the problem.

I am glad to help and appreciate what you have been able to accomplish.

inlineblock.zip

Cheers,

Alex

@geoffmcl
Copy link
Contributor

@alexneblett thanks for the issue...

Certainly, extacting your in and out sample htm files, and viewing them in a browser, and I can certainly see the additional vertical space created in the table... but still trying to understand why!

Yes, it certainly seems mixed up with the <div>, a block level element, and the <span>, which is an inline element... You have lots of them...

Will keep picking at it... but it would be much appreciated if you could create a very minimal example... hopefully maximum a 3 x 3 table, or less... reading and comparing the current in/out is quite difficult...

Anything you can do to really narrow down exactly what is tidy adding, changing, fixing, that causes that extra space would speed up the process... thanks...

@geoffmcl geoffmcl added this to the 5.3 milestone Aug 10, 2016
@alexneblett
Copy link
Author

so the extra space is caused by an extra space that tidy places between the spans with a display: inline-block. Removing that space cures it.

I made a small hack to src/tags.c to test my theory:

{ TidyTag_SPAN, "span", VERS_ELEM_SPAN, &TY_(W3CAttrsFor_SPAN)[0], (CM_INLINE), TY_(ParseInline), NULL },

to

{ TidyTag_SPAN, "span", VERS_ELEM_SPAN, &TY_(W3CAttrsFor_SPAN)[0], (CM_INLINE|CM_BLOCK|CM_MIXED), TY_(ParseBlock), NULL },

and it cured all the other issues. Now, for a proper fix and not a terrible hack...

I will put together and send over a small table in the A.M.

Thanks,

Alex

@geoffmcl
Copy link
Contributor

@alexneblett thanks for looking further into this...

Wow, yes, while that hack might cure a certain space problem, that really changes the attributes of <span>, and even the parser. I think that will do much more than just remove an extra space ;=))

And may break backward compatibility with html4-- mode... so may need to be re-set on mode changes... have not checked...

Look forward to a simple table to test, so I can even get to see exactly what extra space you are talking about...

Hopefully, maybe there is a quieter, less invasive fix... thanks...

@balthisar
Copy link
Member

Pinging @alexneblett, as some simple source demonstrating the issue would still be appreciated.

@geoffmcl geoffmcl modified the milestones: 5.5, 5.3 Feb 28, 2017
@balthisar
Copy link
Member

@alexneblett never came back, but what I think he's asking for is for Tidy to recognize display: inline-block and treat span (and presumably other elements) as such during pretty printing.

That would open us up to having to interpret CSS, and possibly Javascript, and not just for this particular issue, but for a plethora of new issues. We kind of arrived at the conclusion that Tidy shouldn't bite off more than it can chew while discussing custom-elements, so I vote for closing this. I won't hit the close button just yet in case I'm misunderstanding something, or in case anyone else has additional thoughts.

@geoffmcl
Copy link
Contributor

geoffmcl commented May 4, 2017

@balthisar well @alexneblett did attach a zip file with a sample...

If you extract the zip, and load spaninlineblock.htm in a browser, you will see a neat, compact table, where the cell height is say 1em, or there abouts...

Then if you run current tidy on that, and load the tidied output, or load his spaninlineblockout.htm, in a browser, you will see the cell height is at least double... there must be simple reason for this...

So this is a case where the browser view of the tidied document does not match the original! And that breaks one of the maxims of tidy to produce the same view...

Now his sample is quite large and complex, but it should be possible to reduce it down to a very minimal sample, and discover what has changed in the tidy output that causes this very large visual change...

It does contain a lots of <span style="vertical-align:bottom;width:80%;border-bottom:solid 2px #000000;display:inline-block;" class="center"> and <div ...> elements, but in general Tidy just repeats all those... no problem...

Yes, it would be nice if @alexneblett could help in this simplifying of the sample, and find the cause... then I am sure we can find a fix...

Again this is a simple case of tidied output not matching the display of the original, and I certainly do not think it should be closed... until solved, or at least understood, when we might even say Won't Fix, or maybe even Can't Fix...

It does not involve Tidy in interpret CSS, and there is no javascript... he is not asking tidy to recognize display: inline-block... it might involve how tidy relines, and places these spans and divs, in a table... and even saying that gives me some other thoughts to try...

I will try to push myself to look at this issue again... get a simple sample case... and work on a fix...

@geoffmcl
Copy link
Contributor

geoffmcl commented May 5, 2017

@balthisar, @alexneblett wow after a lot of reviewing I think I found the main problems with Tidy!

  1. It will not allow an open <span style="whatever"> to remain open on reaching a <div>.
  2. In places it puts a space between </span> and the next <span>. It is that space that causes an extra line height in each cell.

That is aside from the document has some other grievious problems, like it has displa\ny:block, cla\nss="blah", etc... That is it seems some wrapping tool has added line breaks in words! Ugh!

Now this issue of a <span><div> has come up before, like in #530, and maybe accepting this new option insert-inline-tags may help the situation, but as warned there could have a lot of other consequences...

I have still to research into where this extra space like </span> <span ... comes from... but have made some progress...

Additionally tidy seems to want to use the entity &nbsp; in place of the numeric equivalent &#160;, but maybe there is an option to control this, but it seems to cause no problem, either way...

To assist in the research have pushed some 448 samples to my tidy test repo. There, the in_448.html and out_448.html are the originals from the above zip.

The sample in_448-4.html is a manually cleaned sample. All the unnecessary <div> removed, and the above inappropriate linebreaks fixed, that, aside from the obsolete cellpadding and cellspacing on the table, will pass W3C nu, and tidy will not reports any warnings/errors.

And, if you do a global replace of </span> <span with </span><span in the tidy output, with --wrap 0 config - ie just removing that creepy space - the tidied output will correctly display the compact table...

Sort of out-of-breath on this issue for the moment... will get around to figuring out where that creepy space comes from... unless someone else beat me to it... it does not seem a big problem...

But this is working on the already partially fixed in_448-4.html sample. To work on the original requires either the above option insert-inline-tags to be considered, with its big consequences...

Or perhaps a more limited new option like allow-span-to-cross-div or something... in that it seems browsers do not care... maybe tidy could allow <span> to be a block-like tag, with this option yes, and thus span other blocks...

Just an idea... feedback welcome... thanks...

@geoffmcl
Copy link
Contributor

No comments for a while, but after re-reading maybe there is a possible new option here... still waiting for more feedback... but meantime moving the milestone out... thanks...

@geoffmcl geoffmcl modified the milestones: 5.5, 5.7 Nov 30, 2017
@geoffmcl geoffmcl removed this from the 5.7 milestone Sep 23, 2020
@geoffmcl
Copy link
Contributor

20200923: @alexneblett no further feedback, for years, so no feature request, no option, emerged... so closing this... sorry...

Feel free to re-open, or open a new issue... thanks...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants