Support the <slot> tag #848
Conversation
<slot> was added to the WHATWG HTML5 Living Standard on April 20, 2016.
|
@lhchavez thanks for the Feature Request... I pulled your fork, built a 5.7.28.I848 version... created some sample html... it seems great on some things... but puzzled by a few things... I had added Then still got a warning - Then from the code - <div>
<span slot='title-1'>Title A</span>
<span slot='title-2'>Title B...
...got a warning - On another sample - Tidy outputs - Just thinking aloud, should With those niggles discussed, solved, added... looks like a good PR... thanks... To continue testing, could you supply some, hopefully small sample html to test, explore, etc... thanks |
This change contains the testcase needed for htacg/tidy-html5#848
Given that the <slot> tag by itself is not too useful, this commit also introduces support for the global slot attribute.
|
Done, added one testcase that has some snippets pulled from https://developer.mozilla.org/en-US/docs/Web/HTML/Element/slot and should now pass cleanly. |
|
the one thing i could not find an easy way to do is to allow both I'm using |
|
@lhchavez thank you for the additional pushes to this PR, but not sure I agree with all, yet... But pulled and built And thanks for the There, in PR-32, suggest a small enhancement, to remove some diff --git a/cases/testbase/case-848.html b/cases/testbase/case-848.html
index d74c3ca..2ff2bf9 100644
--- a/cases/testbase/case-848.html
+++ b/cases/testbase/case-848.html
@@ -1,7 +1,8 @@
<!DOCTYPE html>
-<html>
+<html lang="en">
<head>
- <title>test</title>
+<meta charset="utf-8">
+<title>add 'slot' tag</title>
</head>
<body>
<p><slot name="my-text">My default text</slot></p>But these are not particularly important... Question on I do want to understand why I have a test file in_848.html, which satisfies Yes, strongly note you have switched And that raises the question about Using definitions by MDN, or even by W3C, for that matter, does little to understand the problem in the I started to look back in the issues related to Feel the PR has advanced, but still some Look forward to further feedback, comment, patches, PR, etc on this... thanks... |
This might be a bug in
Which sounds like it's contradicting itself.
yes, that should be valid in a template, but there is no ready-to-use solution to parse arbitrary HTML that should be allowed in Re: |
|
@lhchavez thank you for the feedback... It seems we are 90% there, only differing on the You suggest I can not find Presently
You further suggest a Is what you suggest based on performance on What happensWhat happens if the flag is say, Or some other combinations... How do they perform in the Started an analysis of the current
Here, I tried to point to some earlier - turn off tidy - discussion... in general, it seems the consensis is - This HTML Tidy - what do you want it to do? There are many other text manipulation tools, to avoid Parsing by Is it suggested that the But that seems a different, and NEW issue... must refer to the previous discussions... thanks...
Maybe, but maybe we do not understand, fully, those cute definitions of More importantly, how that can that be But back to this great PR -I would like to see some more testing of other table options... before deciding which is the best... will continue that... options/example/results testing appreciated... Look forward to further feedback, comment, patches, PR, etc on this... thanks... |
|
@lhchavez I have now conducted lots of further test, and concluded diff --git a/src/tags.c b/src/tags.c
index 9f72a70..760c37b 100644
--- a/src/tags.c
+++ b/src/tags.c
@@ -323,7 +323,7 @@ static Dict tag_defs[] =
{ TidyTag_OUTPUT, "output", VERS_ELEM_OUTPUT, &TY_(W3CAttrsFor_OUTPUT)[0], (CM_INLINE), TY_(ParseInline), NULL },
{ TidyTag_PROGRESS, "progress", VERS_ELEM_PROGRESS, &TY_(W3CAttrsFor_PROGRESS)[0], (CM_INLINE), TY_(ParseInline), NULL },
{ TidyTag_SECTION, "section", VERS_ELEM_SECTION, &TY_(W3CAttrsFor_SECTION)[0], (CM_BLOCK), TY_(ParseBlock), NULL },
- { TidyTag_SLOT, "slot", VERS_ELEM_SLOT, &TY_(W3CAttrsFor_SLOT)[0], (CM_INLINE), TY_(ParseInline), NULL },
+ { TidyTag_SLOT, "slot", VERS_ELEM_SLOT, &TY_(W3CAttrsFor_SLOT)[0], (CM_INLINE|CM_BLOCK|CM_MIXED), TY_(ParseBlock), NULL },
{ TidyTag_SOURCE, "source", VERS_ELEM_SOURCE, &TY_(W3CAttrsFor_SOURCE)[0], (CM_BLOCK|CM_INLINE|CM_EMPTY), TY_(ParseBlock), NULL },
{ TidyTag_SUMMARY, "summary", VERS_ELEM_SUMMARY, &TY_(W3CAttrsFor_SUMMARY)[0], (CM_BLOCK), TY_(ParseInline), NULL },
{ TidyTag_TEMPLATE, "template", VERS_ELEM_TEMPLATE, &TY_(W3CAttrsFor_TEMPLATE)[0], (CM_BLOCK), TY_(ParseBlock), NULL },At first I tried to reason it out, analyzing the current See the temptable.htm using your But they do not seem to answer the question... I then constructed more samples for testing... in addition to in_848.html, already published to my repo, added 848-1, 848-11, 848-12, 848-2, 848-3, and eventually 848-4... will try to get around to publishing these... but... I built more versions of tidy... if we consider the table is made using 3 bit flags, inline (I), block (B), mixed (M), and 2 parsers, inline (I), and block, (B)... so built versions -
Then used each version of Perhaps the most important is 848-4, which is based on the working, online sample, at MDN/web-components ... with the addition of a config - It also re-open the addition of the So I am now convinced the above patch needs to be applied to this PR... then feel it is good to go... at least after maybe a few tweaks, time, more tests... Look forward to further feedback, comment, patches, PR, etc on this... thanks... |
This is still suboptimal since ParseBlock will make it so that <slot> always expects "Flow content", whereas the spec says that it should have a Transparent content model. In practice, it should allow all the cases that the spec allows for, but it will also allow some cases that the spec does not allow. Notably, if a <slot> tag is found in a Phrasing content (an inline context in libtidy lingo), it will wrongly let Flow content (block tags in libtidy lingo), whereas it shouldn't. But all in all, it's a good compromise.
welp, that was my bad. i should have linked the canonical W3C definition of Phrasing content, which does contain the And I'm sorry if I sounded like I was suggesting that
IIUC the definifion is "if it is contained in the canonical Phrasing content tag list".
Errr, sorry, I got a bit confused with the Here's where it gets tricky. <section> <!-- this is Sectioning content, that has a Flow content model -->
<slot>...</slot> <!-- this now has a Flow content model, so ParseBlock is more correct -->
<p> <!-- this is Flow content, that has a Phrasing content model -->
<slot>...</slot> <!-- this now has a Phrasing content model, so ParseInline is more correct -->
</p>
</section>
yeah :/ as I mentioned, both options are suboptimal and break some cases, as outlined above.
Orginally I made the decision of using
What I'm most interested in is the automatic rewriting feature of tidy, which we would lose by turning it off :( |
|
@lhchavez thank you for the additional commit 99b6c660 ... this looks good... Have not yet had a chance to update, rebuild, and test... etc... will try to get to that soonest... but the PR looks good... I can see you are still trying to tie together the two sets of logic, W3C/MDM - Flow/Phrasing vs libTidy - ParseBlock/ParseInline... and do not quite agree with all the comments, in your sample... but, no problem... It is important to have a reasonable sample set... and more welcome... actual use cases... So along with the other 7, in my repo, in_848.html in_848-1.html in_848-11.html in_848-12.html in_848-2.html in_848-3.html in_848-4.html, added yours, as in_848-5.html... tks... But am not sure what extra it adds... it is passed by both tidy-I-I.exe and the tidy-IBM-B.exe... so does not sway the argument either way... ParseBlock vs ParseInline, in So, perhaps it is agreed, as it stands at the moment, if merged, There is also the pending problem with the It seems downright wrong to move I don't exactly understand to So after I get around to a bit more testing, I think this is a good addition, to Look forward to further feedback, comment, patches, PR, etc on this... thanks... |
|
@lhchavez sorry for the long delay on this... I have subsequently changed PCs, and am in the process of setting up the testing of this again... At least one quick change in the PR, is where we add the As further suggested there, I think the wording in OPTIONS.md, ATTRIBUTES.md, and probably others, needs to be Meantime, I will try to get back to testing Look forward to further feedback, comments, other patches, PR, etc, on this... thanks... |
|
@lhchavez have build your forks diff --git a/include/tidyenum.h b/include/tidyenum.h
index 543a82e..8fe5f52 100644
--- a/include/tidyenum.h
+++ b/include/tidyenum.h
@@ -988,13 +988,13 @@ typedef enum
TidyTag_OUTPUT, /**< OUTPUT */
TidyTag_PROGRESS, /**< PROGRESS */
TidyTag_SECTION, /**< SECTION */
- TidyTag_SLOT, /**< SLOT */
TidyTag_SOURCE, /**< SOURCE */
TidyTag_SUMMARY, /**< SUMMARY */
TidyTag_TEMPLATE, /**< TEMPLATE */
TidyTag_TIME, /**< TIME */
TidyTag_TRACK, /**< TRACK */
TidyTag_VIDEO, /**< VIDEO */
+ TidyTag_SLOT, /**< SLOT */
N_TIDY_TAGS /**< Must be last */
} TidyTagId;
@@ -1144,7 +1144,6 @@ typedef enum
TidyAttr_SHOWGRIDX, /**< SHOWGRIDX= */
TidyAttr_SHOWGRIDY, /**< SHOWGRIDY= */
TidyAttr_SIZE, /**< SIZE= */
- TidyAttr_SLOT, /**< SLOT= */
TidyAttr_SPAN, /**< SPAN= */
TidyAttr_SRC, /**< SRC= */
TidyAttr_SRCSET, /**< SRCSET= (HTML5) */
@@ -1344,7 +1343,8 @@ typedef enum
TidyAttr_AS, /**< AS= */
TidyAttr_XMLNSXLINK, /**< svg xmls:xlink="url" */
-
+ TidyAttr_SLOT, /**< SLOT= */
+
N_TIDY_ATTRIBS /**< Must be last */
} TidyAttrId;If you agree, appreciate it being added to this PR... thanks... I built your And of course that case fails using the current 5.7.29, as expected... thanks... Are there any other tests I need to run? I will look around for some So, if the above Look forward to further feedback, comments, other patches, PR, etc, on this... thanks... |
|
@lhchavez eventually got to it... now merged... thanks... |
was added to the WHATWG HTML5 Living Standard on April 20, 2016.