SVG attributes flagged as proprietary #903

cqcallaw · 2020-10-31T02:32:39Z

The following HTML input to tidy (build from 1889880 on the next branch) validates with zero errors and zero warnings on https://validator.w3.org/nu/#file, but generates the following warnings in tidy. The "proprietary" attributes seem to be well-defined in section A.3.7 of the SVG 1.1 DTD, so this looks like a simple implementation gap that can be filled by adding the attributes to attrs.h, attrs.c, and attrsdict.c If so, I can contribute a pull request.

Tidy Output

$ ./build/cmake/tidy -i -w 120 svg.html 
line 8 column 9 - Warning: <svg> proprietary attribute "stroke-width"
line 8 column 9 - Warning: <svg> proprietary attribute "stroke-linecap"
line 8 column 9 - Warning: <svg> proprietary attribute "stroke-linejoin"
line 8 column 9 - Warning: <svg> proprietary attribute "stroke-miterlimit"
line 8 column 9 - Warning: <svg> proprietary attribute "stroke-opacity"
line 8 column 9 - Warning: <svg> proprietary attribute "stroke-dasharray"
line 8 column 9 - Warning: <svg> proprietary attribute "fill"
line 8 column 9 - Warning: <svg> proprietary attribute "stroke"
Info: Document content looks like HTML5
Tidy found 8 warnings and 0 errors!
...

HTML

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8">
        <title>SVG sample</title>
    </head>
    <body>
        <svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" stroke-width="2" stroke-linecap="butt" stroke-linejoin="round" stroke-miterlimit="4" stroke-opacity="1" stroke-dasharray="none" fill="currentColor" stroke="currentColor">
            <path d="m 0.75,12.0 11.25,-9.0 4.5,3.375 0.0,-1.5 2.25,0.0 0.0,3.375 4.5,3.75 -2.25,0.0 0.0,9.0 -5.625,0.0 0.0,-7.5 -6.75,0.0 0.0,7.5 -5.625,0.0 0.0,-9.0 z" />
        </svg>
    </body>
</html>

The text was updated successfully, but these errors were encountered:

geoffmcl · 2020-11-11T17:46:32Z

@cqcallaw thank you for this issue, and sample code, which I will label as a Feature Request, but it could just as easily be considered a BUG ;=))

From the W3C reference, and the fact that your sample passes the W3C nu validator, certainly indicates tidy is wrong in flagging these attributes as proprietary!

But this is in a HTML5 document, so care should be taken to continue to flag these attributes in legacy documents... if you replace the DOCTYPE with say 4.01 head, the W3C legacy validator will list lots of errors... adding xmlns to the list...

And in brief testing, it seems the <svg> tag shares the same parser, ParseNamespace, as the <math> tag. Maybe this is ok, or maybe needs a new, different parser - not sure.

For sure, we would need to add the missing attributes, but take care these need to be added to TidyAttrId enum, in tidyenum.h, just before the current last, N_TIDY_ATTRIBS , and NOT in groups, or alphabetically, as the current docs indicates. See #851, and others...

Look forward to further feedback, patches, or PR to implement this... thanks...

Fixes htacg#903

cqcallaw · 2020-11-12T01:11:03Z

@geoffmcl Thanks for the follow up! I've pushed a commit, but it has a few issues:

There's a lot of trailing whitespace in the files which my editor (VS Code) is stripping this out, even if I disable the feature. I've captured the whitespace trimming in a separate commit which can be dropped if the diff gets too noisy to review.
The version compatibility doesn't seem to be working as I expect. The following HTML 4.01 document doesn't raise any errors with my branch build, contrary to the W3C validator behavior:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
    <head>
        <title>Conforming HTML 4.01 Strict Template</title>
    </head>
    <body>
        <svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" stroke-width="2" stroke-linecap="butt" stroke-linejoin="round" stroke-miterlimit="4" stroke-opacity="1" stroke-dasharray="none" fill="currentColor" stroke="currentColor">
            <path d="m 0.75,12.0 11.25,-9.0 4.5,3.375 0.0,-1.5 2.25,0.0 0.0,3.375 4.5,3.75 -2.25,0.0 0.0,9.0 -5.625,0.0 0.0,-7.5 -6.75,0.0 0.0,7.5 -5.625,0.0 0.0,-9.0 z" />
        </svg>
    </body>
</html>

This issue isn't unique to this patch, however; the xmlns attribute predates the patch but is still accepted as valid by tidy. It sort of seems like the version compatibility matrix in in attrdict.c isn't being honored. Any thoughts or advice?

geoffmcl · 2020-11-12T20:13:16Z

@cqcallaw thanks for kicking this off... this is great... a few thoughts, and suggestions...

You appear to have added your commits to the next branch, in your fork. This can cause all sorts of problems, when it is eventually merged into htacg tidy next! You will have problems trying to update your fork later.

It is better you create a local branch, like $ git checkout -b issue-903; Add the commits for this issue only to this branch; then push that branch to your fork $ git push -u origin issue-903.

Not sure how to back out of this now, but there might be a git way... In the past, when faced with this, I, and others, have just deleted the whole fork, and forked htacg tidy again... Maybe others can help on this... it might be easy...

But yes, your stripping of the line space endings does really mess up a review process, and adds a much larger than needed commit to the git history. But if you take the above branch advice, then you could re-do the commits, without these changes... sorry... but at this stage, it is just a cut and paste of two blocks... one in tidyenum.h, and the other in attrs.c...

But in attrs.c, you have marked each of the new attributes with CH_PCDATA, which you will note is defined as a NULL. That is, NO check attribute value service provided!

I can see many are just a number, where CH_LENGTH, (CheckLength), or CH_NUMBER, (CheckNumber), could be used... not sure why we have two services that seem to basically do the same thing...

But others are words, like butt, round, etc. If these have a fixed list of value strings, then they could be added to say CheckType, once a nodeIsSVG is defined, like #define nodeIsSVG( node ) TagIsId( node, TidyTag_SVG)...

Or each is given there own checker, like CheckVType, CheckScroll, etc... each with their own list, or combined into one say CheckSVGAttrs, keeping them all together...

Also we must check those attribute already defined, in W3CAttrsFor_SVG, like TidyAttr_WIDTH, ... already does the right thing... but these seem ok... ATM...

Finally, we must check the document mode... see TY_(IsHTML5Mode)(doc)... to continue to report proprietary for most of these attributes, if NOT in html5 mode... and find out why xmlns="...url..." gets through in both cases, and is the validity of the url checked...

With a new branch setup in your fork, I could clone, build and test your fork/branch, and add further comments, as this moves forward, until we have a complete PR ready, and tested...

If I have missed something, please ask...

Hope this is not all-too-much for you... but you have made a reasonable start... look forward to more... thanks...

Fixes htacg#903

cqcallaw · 2020-11-12T22:18:49Z

@geoffmcl Thanks for taking a look! I'm pretty sure the next branch on my fork is even with the upstream branch; I'm seeing my commits on the svg-paint-attrs branch I created. Do you see something different?

I've dropped the whitespace commit, so a PR should be cleaner now. Digging into the attribute validator logic is going to take some time; I'll update the branch and the issue when I have more to share.

Fixes htacg#903

cqcallaw · 2020-11-13T04:04:20Z

@geoffmcl I've sketched out what seems like a good direction for the validation of SVG attributes. Please take a look and let me know if the structure seems sound and I'll fill in the rest of the details.

I don't think I can commit to writing the code to process each and every valid SVG attribute, but I should be able to cover the core paint attributes that are defined in my patch.

cqcallaw · 2020-11-13T04:19:42Z

I'm quite mystified about why the HTML 4.01 parsing doesn't flag the added attributes as proprietary. Seems like the logic at https://github.com/htacg/tidy-html5/blob/188988022da4a64d80bc4a2eba21c33d57eb5152/src/attrs.c#L490..L505 is designed to handle this.

geoffmcl · 2020-11-13T18:28:08Z

@cqcallaw Wow, this is starting to look good... many thanks...

Yes, I can now see the commits are in the svg-paint-attrs branch of your fork... this is fine... did I miss this before? And thanks for fixing the trailing space problem...

I cloned your fork, switched branches, and did a build, and started a MSVC Debug session... The first little problem is the attribute_defs [] table, in attr.c, MUST be in the SAME order as the TidyAttrId enum in tidyenum.h... I have fallen into this trap several, many, times...

You have duplicated TidyAttr_COLOR... Just removing that entry fixes it... You mentioned VS code editor so assume you are using MSVC... If you were to try to run the Debug build of the library, you should have been stopped by the assert ... of course assert is a NOOP in other configuration builds...

Of course you have to adjust the CH_COLOR checker, like do if (nodeIsSVG(node)) return CH_SVG;, or something like that...

But in the CH_SVG I do not see where attr color is handled... but maybe I missed it... but do see a TODO comment, so maybe you are still working on it... it seems we need to support many colors ... as well as RGB, #abc and #aabbcc ... ugh!

And maybe it is time we added static in front of the likes of ctmbstr const paintValues[] = {...}; and the like, to reduce the function stack usage...

And unless you add a return inside each if (attrIsXXX) { } context, this should be an if (...) else if (...) else if (...) etc, to avoid each if being evaluated every time it is called...

Now to the html5 vs legacy question... yes, the TY_(AttributeIsProprietary) service is part of this... but maybe not all... I will have to get into a Debug session to try to understand this more...

I have had some success by adding the option --strict-tags-attributes yes... but not sure this should be required in this case... and still getting Warning: <svg> proprietary attribute "color" on html5, and the following on legacy -

line 7 column 9 - Error: <svg> attribute "xmlns" not allowed for HTML 4.01 Strict
line 7 column 9 - Warning: <svg> proprietary attribute "color"
line 7 column 9 - Error: <svg> attribute "stroke-width" not allowed for HTML 4.01 Strict
line 7 column 9 - Error: <svg> attribute "stroke-linecap" not allowed for HTML 4.01 Strict
line 7 column 9 - Error: <svg> attribute "stroke-linejoin" not allowed for HTML 4.01 Strict
line 7 column 9 - Error: <svg> attribute "stroke-miterlimit" not allowed for HTML 4.01 Strict

Have added your html5 and legacy samples to my tidy test repo, with the color="blue" added... for consistent testing... but still testing, questioning...

Of course, in CheckSVGAttrs we could add at the top if (!TY_(IsHTML5Mode)(doc)) report warning, or something... but still pondering this...

Will revert if I find out more on this question...

This is a great step forward towards a good PR, but needs a little more work... look forward to further feedback... thanks...

cqcallaw · 2020-11-13T21:30:02Z

@geoffmcl thanks again for your help! I've pushed a couple of additional patches to my branch with fixes for issues highlighted above.

As far as I can tell, the SVG color attribute has the same semantics as other parts of the spec, so I don't see a need to enable special processing for SVG colors. Please let me know if I'm misreading things. I've done the same for other attributes (stroke-dasharray, stroke-miterlimit, opacity, etc) that don't seem to require special processing. We could just as easily use the CH_SVG function to pass validation of those attributes through to the relevant check functions; do you think this is more readable? I'm happy with either approach.

geoffmcl · 2020-11-14T17:47:30Z

@cqcallaw thanks for the fixes - using else if (...), and adding static to the data arrays - this is all good... except you were a little over zealous on adding the else on the first two in the block, since these already had a return...

There are two(2) separate things about TidyAttr_COLOR ...

The first is it is NOT present in the TY_(W3CAttrsFor_SVG)[] array, so if I add --strict-tags-attributes yes, it pops up as Warning: <svg> proprietary attribute "color". We need to add it to that array.

The second may NOT be particularly related to this issue, but Tidy pesently only supports some 16 named colors in the static const struct _colors colors[] = ... array, while the SVG11/ColorKeywords link lists some 143 named colors!!!

Fixing the first, and changing my in_903.html sample to use color="yellowgreen", and I get a warning Warning: <svg> attribute "color" has invalid value "yellowgreen"... but it is NOT invalid!

Now the question is, do these ONLY apply to the color= attribute on the svg element, or to ALL elements that support a color attribute, which, in tidy, includes 3, <basefont>, <font>, and <link> tags?

In other words can we just extend the current _colors colors[] array, or do we need to separate these checks...

I presently think it can be applied to ALL, but could be persuaded otherwise... What do you, others, think?

I did not quite understand what you are trying to say in the last part of the above paragraph. I note there are some 15 attributes listed in the IsSvgPaintAttr service, while the block only has about 8 attribute tests.

Now I can see some 6 attributes do NOT use CH_SVG. No problem about that. But then why are they in IsSvgPaintAttr? Am I missing something here? But not really a problem...

And a very small thing, can we add this issue number, to the code comments like /* Is. #903 - Check SVG attributes */, and maybe some other appropriate places... to leave a trail in the code...

Still try to decide on whether --strict-tags-attributes yes option should be required on legacy documents, for these svg paint attributes... At present think no... They should always be flagged on legacy docs... Appreciate comments on this...

Getting close... look forward to further feedback... thanks...

cqcallaw · 2020-11-15T01:37:08Z

@geoffmcl thanks again for your continued attention to this issue; I didn't expect it to require so much of your time. I'm glad you're still willing to help :)

I fixed the overzealous bits and added the color property back into the appropriate array. I think the color issue is larger than SVG; I didn't do an exact comparison, but the SVG color names seem to be equivalent to the CSS colors referenced in the HTML5 spec.

Since the coverage of attributes was confusing, I've revised the code so all SVG attribute validation is handled in CheckSvgAttr, even if where it's just a call to another validator. I've added a code comment referencing this issue as well, and also cherry-picked the test files from your branch.

I think I agree that --strict-tags-attributes yes shouldn't be necessary for the legacy documents, since this is the behavior seen on the W3C validator. I don't know enough about to code base to know how to fix it, though...

geoffmcl · 2020-11-15T19:41:30Z

@cqcallaw it is not my time that is the question. I am an old, retired programmer, and have lots of that, now for only FOSS projects...

No, it is the motivation, enthusiasm, ... that is important. I get sick of just me coding tidy, so much so that I recently took nearly a year off from tidy, when nothing was coded... so it's your efforts that keeps me going ;=))

You can see quite a lot of issues which end with look forward to feedback, patches, PR..., and blank there after. I will do nothing until someone starts to make a lot more of an effort, than just reporting an issue, and expecting me to fix it... end of rant ;=))

Thank you for putting all svg attrs through CheckSvgAttr. Last night I had decided to come back today and suggest exactly that! ;=)) My reason is given later...

And thanks for finding another W3C named-color list. I too have not compared everything, but a lot, and am convinced they are the same list, even down to the same 4 or 5 duplicated gray/grey entries... so will try to attach a new struct _colors colors[] table for you to add to tidy... to be used in GetColorCode and GetColorName services... for all nodes that support a color attribute...

We do have to decided about TidyAttr_COLOR, presently directly using CH_COLOR... And TidyAttr_WIDTH, HEIGHT, ..., ie other shared attributes... if anything... But maybe this/these can be considered later...

And I have been meaning to ask, "Is it true that ALL these paint attrs support "inherit" value?" I did not see that in my reading, but maybe I missed it... I can see it on stroke-linecap, stroke-linejoin, color-interpolation, color-rendering and maybe others, but ALL, as you have coded it, does not seem right? Maybe it has to be duplicated in each of the appropriate values[] lists...

Now, concerning html5 vs legacy, as suggested earlier, we can now test the current mode, early in CheckSvgAttr, and bounce out a warning if (!TY_(IsHTML5Mode)(doc)). We do need to check how that would interact with --strict-tags-attributes yes? We do not want two messages, one a warning the other an error...

On legacy documents, exactly what attrs are allowed, on <svg>, if any? I have experimented, and can not get anything to pass the W3C validator. It seems to reject the <svg> element completely, on legacy! What am I missing here?

If there is no <svg> element before html5, then it should be flagged as proprietary, and not particularly its attributes... This goes back to the main tag table, Dict tag_defs[] for svg... Need W3C HTML4, and earlier, reference here... this may change my idea on some of the above...

Thanks, but please do not include sample test files in this branch. These have no place in this htacg/tidy-html5 repo, thus makes a PR impossible...

We do have a repo of test files - https://github.com/htacg/tidy-html5-tests - called regression tests, and may consider adding some samples there... but that can wait... I just drop things in my personal test-tidy repo since adding them to the regression costs a lot more effort...

Marching forward... look forward to further feedback... thanks...

PS: Will try to embed colors3.c.zip here, but if that fails, it is also available from my tmp folder - http://geoffair.org/tmp/colors3.c.zip .... contains colors3.c to replace the existing list...

colors3.c.zip

cqcallaw · 2020-11-16T04:07:44Z

@geoffmcl Glad to hear my contributions aren't a burden, and thank you for maintaining this project!

If that's okay with you, I'd prefer to handle the additional color values in a separate commit. I think this commit is getting pretty large already, and I'd like to constrain its scope if possible.

Regarding inherit values, I read through the docs and it appears that every one of the attributes I've added is allowed to have an inherit value. Even fill refers to a type that allows inherit.

According to Wikipedia, SVG 1.0 become an official recommendation in 2001, whereas HTML 4.01 was officially recommended in 1999. I'm not sure why the W3C validator allows the tag at all--maybe they knew SVG was being drafted so they thought they'd allow some draft version of SVG to validate?

I've reverted the sample files from the branch, so all should be well there. Thanks!

geoffmcl · 2020-11-16T18:17:27Z

@cqcallaw Actual code contributions are very, VERY seldom a burden ;=))

Of course, they can be, if you disagree with the developer's direction, which has happened in the past... but not when you are working towards a common, agreed goal... like tidy supporting <svg>... thanks for your code contributions, and general feedback...

Yeah, the additional color support, can be a separate commit... no problem... but it means my in_903.html sample will continue to show a warning until then... and in reviewing a complete diff to next, I don't think the commit is too large, and is well within the scope of supporting SVG colors... but as you like...

Ah, thanks for tracking down those dates... As you probably already understand, the W3C validator, is actually two(2) separate beasts - the legacy validator, which used to run tidy, in the early days, and nu, a completely re-written validator, to handle only html5 doctypes...

Given that the legacy validator generally lagged behind the W3C recommendations, and would certainly not pick up something from a draft document, I doubt if anything of the general svg spec would have got into there...

And I am starting to think, tidy, when parsing a legacy document, should likewise treat it as proprietary... and not bother about attribute checking on tags not approved... still pondering... feedback welcome...

But I am happy with where we are at the moment on this, only giving error if --strict-tags-attributes yes... and the finer detail can be left until another time... when/if the issue comes up...

Re: inherit

Yes, I agree, most of the paint attributes support "inherit", and when we had other numeric type attributes going directly to length, number, decimal checkers, this was no problem, saving a little bit of code space, by dealing with this inherit separately...

But now, as the CheckSvgAttr if/else tumble is presently constructed, something like stroke-dashoffset="inherit", or stoke_width="inherit", etc, would be validated... or am I somehow misreading this?

How you deal with this is up to you. You could have another service like IsSvgAttrNumeric, listing those that have a number value, then change if (AttrValueIs(attval, "inherit")) to if (!IsSvgAttrNumeric(attval) && AttrValueIs(attval, "inherit")){ return; }, or perhaps better, remove it, and just repeat "inherit" in the data arrays necessary... but it seems something needs to be done... do you agree?

Re: unix/linux issue

Now being a mainly Windows person, I have been overlooking another important issue, and that is the visibility of these new services. If a service is only ever used in that specific module, ie a single C source file, then is MUST have a static attribute added. That is not available outside this module...

And if it is used across modules, then is MUST be in a TY_(ServiceName) macro, which expands to prvTidyServiceName... see forward.h...

The window compiler/linker already only exposes, in its export library, the API services marked TIDY_EXPORT, so no problem there, but it seems gcc exposes everything NOT marked static, and we already have unix issues about the prvTidyXXXXX services, which still needs to be addressed... see #743, and maybe others...

I can see that there were already some mistakes in this module, before you started, so was misleading, and I am not asking you to fix those, but we must make an effort to conform to the libTidy standard for all new things we create...

So that should be static void CheckDecimal, static Bool IsSvgPaintAttr, static void CheckSvgAttr, etc...

I am sorry to bring this up at such an advanced stage, but it is important, for linux shared library distribution...

And thanks for removing the test samples...

Had quite a short day today, and did not get any testing done... but will get to that... thanks for your continued support...

geoffmcl · 2020-11-16T19:17:09Z

@cqcallaw oops, made 1 or 2 small boo-boos in colors3.c... glad you had not yet included it...

I re-extracted the table from the https://drafts.csswg.org/css-color/#named-color link, ran Perl HTML::Strip;, extracting the text, and ran a Notepad++ macro to remove the RGB values, then some simple find & replace macros, and got a slightly modified color4.c module... all in a few mins... just for fun...

Am now sure if conforms exactly to the web page...

Hence the imbedded zip - colors4.c.zip

And, as before, also available here - http://geoffair.org/tmp/colors4.c.zip

This looks good, when you are ready...

Regards, Geoff.

cqcallaw · 2020-11-17T19:50:37Z

@geoffmcl My basic concern with including the colors patch comes down to bisections and reverts. If we bundle color updates with the SVG paint attribute handling and our bundled commit introduces a bug, it's harder to revert the change cleanly. I don't know how this has been handled by this project in the past, though. How are regressions typically handled?

Treating SVG tags as proprietary in HTML 4.01 sounds good to me, but I'd suggest creating a separate commit for the reasons mentioned above. I think we want to keep any changes that might break existing validation workflows as small as possible, so we can react quickly and precisely to regressions.

Regarding inherit, I understand stroke-dashoffset="inherit" and stoke_width="inherit" to be valid, per the documentation. Legal values for stroke-width are " | | inherit"; legal values for stroke-dashoffset are "butt | round | square | inherit". I observed the same thing for all other paint attributes.

Regarding module exposure, no worries; I am a Linux user and want to make sure the tool works well for myself and other Linux users. I pushed an update that makes IsSvgPaintAttr static. I believe the forward declarations for the other new members have made them static already; do I have that right?

geoffmcl · 2020-11-19T21:02:34Z

@cqcallaw thank you for the further feedback, and sorry for the brief delay...

Color Patch

Although I do not expect any revert, or bisection - I hope we get the chance to fully test, and verify before we get to a PR, and merge - as previously stated, this can be left until later... no probs...

My minimal experience with revert is that it should be avoided if at all possible. It just adds another big BLOB to the git history... And the once or twice I tried bisection it did not go well ;=((

proprietary in HTML 4.01

And again agree this can be dealt with after things have settled down a bit...

`inherit` valid everywhere on these svg paint attributes

Yes, sorry, on re-reading the docs, I guess it can. And the nu validator also accepts stroke-width="inherit"... go figure...

But that presents us with another small problem. It seems width="inherit", and others, is also acceptable!!! Ugh! But at present this would go directly to CH_LENGTH (CheckLength), so would output warning BAD_ATTRIBUTE_VALUE. How should we handle this?

forward declarations and static

Yes, I noted that after I sent my last...

I do not like it - I would prefer that static be used on both... making it clear, so that other dummies like me can not be fooled - but, ok... if that works... and the actual formal declaration keeps the static?

Other items

Is attrIsSVG_STROKEOPACITY used twice in CheckSvgAttr, or am I going blind?

My re-reading the docs, I now note some support a <percentage>, like stroke-width, stroke-dashoffset, and maybe others, but on carefully reading CheckLength, it does not handle a percentage properly. As written, it seems it would allow 123%45%6, but maybe this could be treated as a separate new issue, and dealt with later...

And just as a heads up, I hope to find the energy to merge some outstand for a long time PRs over the coming days. At least one of them also modifies the enums, and as I have seen in the past there may be some merge conflicts later...

If I do get around to these merges, maybe you may need to rebase your fork next to upstream next, and then your branch to next... but maybe not...

A few steps close... thanks...

cqcallaw · 2020-11-19T22:41:38Z

@geoffmcl Sounds good, thanks for your continued attention. As of right now, I think we have these additional issues to address once this issue is closed:

Color name patch
Mark SVG tags as proprietary in HTML 4.01
Fix handling of percentages in CheckLength
(optional, but it'd be a nice quality-of-life improvement) Trimming of trailing whitespace across the entire project

I've fixed the double use of attrIsSVG_STROKEOPACITY and added the static modifiers to the function definitions for clarity. Regarding inherit values of the width property, I see the W3C nu validator accepts width="inherit", but I don't think this behavior is correct. The width attributes that I can see in the DTD are all of the Length datatype, and I don't see inherit specified anywhere in the datatype docs for Length. This looks like a bug in the W3C validator to me; would you agree? If so, I'm inclined to comply with the spec.

Thanks for the note that a rebase may be necessary. I plan to squash the commits from my branch together before submitting a PR anyway, so I'll probably rebase as part of that operation.

geoffmcl · 2020-11-20T17:01:35Z

@cqcallaw thanks for the fixes, and feedback...

I agree those 4 items can be separate additional issues...

Color name patch
Mark SVG tags as proprietary in HTML 4.01
Fix handling of percentages in CheckLength
(optional, but it'd be a nice quality-of-life improvement) Trimming of trailing whitespace across the entire project

Although, still very optional on 4... I did a quick check of the some 54,000 lines of current tidy source, and found some 1,186 with trailing white spaces, just a few percent... and checked back to the old cvs src, some 39,000 lines, 868 with trailing, so most came from before we moved to git... But then again, I did a check of the oldest src I have, Raggett Aug 2000 src, and it has none... so maybe, sometime, ...

Have also had a chance to do the tidy regression tests using your new tidy, and nothing popped. But that is more because there is only 1 XML <svg> sample in there, case-646946.xml, so that is perhaps an additional issue, to add say the in_903.html sample to there... but again that can wait...

Concerning inherit, yes, it does seem strange nu accepts it on width, height, ... and I too can not find it in the docs... so lets go with what we have for now...

Unfortunately, did not find the energy, enthusiasm, to begin clearing out the long outstanding PRs today... maybe this weekend...

Getting there... thanks...

Fixes htacg#903

cqcallaw · 2020-11-20T19:52:52Z

@geoffmcl sounds good, thanks for following up. I've squash my branch and submitted a PR; I can rebase as necessary if other changes merge first. Now, on to the next issues :)

No code changes here, just a quality-of-life edit per htacg#903

geoffmcl · 2020-11-21T18:06:42Z

@cqcallaw as you can see got started on some PR catching up today, on some easy ones - just 4 - a short day... hope I can continue tomorrow, really deciding on some older ones... in or out or whatever...

Thanks for the (squashed) PR #907, for this - seems no conflict yet... good...

And the new issues... will get to them in due course, even the trimming ;=))

The trim PR #911 does already seem to have a small conflict in just 2 files... but the fix probably should wait until I finish my fiddling... say into next week...

Moving forward... enthusiasm begets enthusiasm... thanks...

Fixes #903

No code changes here, just a quality-of-life edit per htacg#903

cqcallaw changed the title ~~SVG attributes flags as proprietary~~ SVG attributes flagged as proprietary Oct 31, 2020

geoffmcl added the Feature Request label Nov 11, 2020

cqcallaw added a commit to cqcallaw/tidy-html5 that referenced this issue Nov 12, 2020

Add SVG paint attributes

2aa1144

Fixes htacg#903

cqcallaw added a commit to cqcallaw/tidy-html5 that referenced this issue Nov 12, 2020

Add SVG paint attributes

76b7c5f

Fixes htacg#903

cqcallaw added a commit to cqcallaw/tidy-html5 that referenced this issue Nov 12, 2020

Add SVG paint attributes

aae73f7

Fixes htacg#903

cqcallaw added a commit to cqcallaw/tidy-html5 that referenced this issue Nov 13, 2020

Add SVG paint attributes

78154d3

Fixes htacg#903

cqcallaw added a commit to cqcallaw/tidy-html5 that referenced this issue Nov 13, 2020

Add SVG paint attributes

b0b3067

Fixes htacg#903

cqcallaw added a commit to cqcallaw/tidy-html5 that referenced this issue Nov 20, 2020

Add SVG paint attributes

989763c

Fixes htacg#903

cqcallaw mentioned this issue Nov 20, 2020

Add SVG paint attributes #907

Merged

This was referenced Nov 20, 2020

Flag SVG tags as proprietary in HTML 4.01 documents #909

Open

Fix handling of percent symbols in CheckLength validation routine #910

Closed

cqcallaw mentioned this issue Nov 20, 2020

Support extended color names in HTML 5 #908

Closed

cqcallaw added a commit to cqcallaw/tidy-html5 that referenced this issue Nov 20, 2020

Trim trailing whitespace

79a679e

No code changes here, just a quality-of-life edit per htacg#903

cqcallaw mentioned this issue Nov 20, 2020

Trim trailing whitespace #911

Closed

geoffmcl closed this as completed in #907 Nov 22, 2020

geoffmcl pushed a commit that referenced this issue Nov 22, 2020

Add SVG paint attributes (#907)

91ae127

Fixes #903

geoffmcl added a commit that referenced this issue Nov 22, 2020

Is #903 PR #907 Bump to 5.7.41 for this merge

c0e6d68

cqcallaw added a commit to cqcallaw/tidy-html5 that referenced this issue Nov 24, 2020

Trim trailing whitespace

713e4aa

No code changes here, just a quality-of-life edit per htacg#903

SVG attributes flagged as proprietary #903

SVG attributes flagged as proprietary #903

cqcallaw commented Oct 31, 2020

geoffmcl commented Nov 11, 2020

cqcallaw commented Nov 12, 2020 •

edited

geoffmcl commented Nov 12, 2020

cqcallaw commented Nov 12, 2020

cqcallaw commented Nov 13, 2020 •

edited

cqcallaw commented Nov 13, 2020

geoffmcl commented Nov 13, 2020

cqcallaw commented Nov 13, 2020

geoffmcl commented Nov 14, 2020

cqcallaw commented Nov 15, 2020

geoffmcl commented Nov 15, 2020

cqcallaw commented Nov 16, 2020

geoffmcl commented Nov 16, 2020

geoffmcl commented Nov 16, 2020

cqcallaw commented Nov 17, 2020

geoffmcl commented Nov 19, 2020

cqcallaw commented Nov 19, 2020

geoffmcl commented Nov 20, 2020

cqcallaw commented Nov 20, 2020

geoffmcl commented Nov 21, 2020

SVG attributes flagged as proprietary #903

SVG attributes flagged as proprietary #903

Comments

cqcallaw commented Oct 31, 2020

Tidy Output

HTML

geoffmcl commented Nov 11, 2020

cqcallaw commented Nov 12, 2020 • edited

geoffmcl commented Nov 12, 2020

cqcallaw commented Nov 12, 2020

cqcallaw commented Nov 13, 2020 • edited

cqcallaw commented Nov 13, 2020

geoffmcl commented Nov 13, 2020

cqcallaw commented Nov 13, 2020

geoffmcl commented Nov 14, 2020

cqcallaw commented Nov 15, 2020

geoffmcl commented Nov 15, 2020

cqcallaw commented Nov 16, 2020

geoffmcl commented Nov 16, 2020

geoffmcl commented Nov 16, 2020

cqcallaw commented Nov 17, 2020

geoffmcl commented Nov 19, 2020

Color Patch

proprietary in HTML 4.01

inherit valid everywhere on these svg paint attributes

forward declarations and static

Other items

cqcallaw commented Nov 19, 2020

geoffmcl commented Nov 20, 2020

cqcallaw commented Nov 20, 2020

geoffmcl commented Nov 21, 2020

cqcallaw commented Nov 12, 2020 •

edited

cqcallaw commented Nov 13, 2020 •

edited

`inherit` valid everywhere on these svg paint attributes