CSS Validation - Page 2

KevinH · 09-13-2025, 07:32 PM

Have you enabled javascript in Edge? I thought Edge and Chrome used the same basic engine?

KevinH · 09-13-2025, 07:38 PM

So it appears Edge and Firefox are not allowing a local file to post via javascript? Very strange!

This all works properly on macOS and Linux, so is this some new security "feature" of Windows?

It it time to retire the W3C Validator website? Does the website itself work on Windows with Firefox and Edge when done manually?

DiapDealer · 09-13-2025, 07:57 PM

My only question is why the OP can get things to work on Windows 11 & Firefox by having the browser open? And even when they don't have it open, it sounds like it's the first empty tab that's the only one not validating.

philja · 09-14-2025, 04:43 AM

Quote:

Originally Posted by KevinH

So it appears Edge and Firefox are not allowing a local file to post via javascript? Very strange!

This all works properly on macOS and Linux, so is this some new security "feature" of Windows?

It it time to retire the W3C Validator website? Does the website itself work on Windows with Firefox and Edge when done manually?

As I noted earlier, W11 (up to date with updates) with sigil 2.6.2 and latest Firefox works fine. Tab opens for each CSS and W3C reports nff or details the CSS faults.

I was surprised W11 didn't opt to use Edge and respected my default setting of Firefox. I was also surprised that W3C didn't identify the CSS file by name in the tabs.

So I would guess it's not a Windows problem (not MS this time).

Maybe the difference noted by DiapDealer and DNSB is down to user security settings inside the browsers?

DiapDealer · 09-14-2025, 06:37 AM

Quote:

Originally Posted by philja

I was also surprised that W3C didn't identify the CSS file by name in the tabs.

It's been a while since I've seen the code, but I don't think any file is being uploaded to W3C servers. I believe the contents of the css file are being put into a form field in a locally generated temporary html file and then submitted with JavaScript (after about a 3 second delay). So it's no surprise that the filename is not presented in any way. The W3C website doesn't know the file name.

KevinH · 09-14-2025, 08:44 AM

I will look into if adding an html title tag helps in distinguishing the multiple buffers.

And yes I think it must be browser security setting related. But setting the default browser does not always seem to be detected by Qt. In my testing on Manjaro, I had to remove falkon (a Qt based browser) and even calibre (temporarily) as both were chosen before my selected default browser as handling html files!

By the way falkon gave me the exact same errors you are seeing but it did not allow javascript by default.

DiapDealer · 09-14-2025, 09:09 AM

The error I'm seeing is exactly what I see if I go to the form submission url from CSSResource.cpp with no post content.

https://jigsaw.w3.org/css-validator/validator

The local JavaScript is performing the submit after 3 seconds though. Otherwise, the 'Check' button would be waiting for me to click it I would think.

KevinH · 09-14-2025, 09:19 AM

So nothing in that textarea? That is very strange.
Something is fishy.

Perhaps we temporarily lengthen the auto submit to 20 seconds so that the user can visually confirm that the css has been properly copied into the form textarea for debug purposes? If it really is blank we can start to add debug to the CSSResource.cpp to try to figure out why? GetText() should always return with the proper CSS text.

DiapDealer · 09-14-2025, 09:34 AM

No. There's content in the text area when the javascript fires after 3 seconds. I realize my previous post might have been a little misleading. Minus the form data, going directly to that url produces the same errors listed on the results page.

Plus I was saying that if javascript were not allowed, the content should still be there after 3 seconds waiting for the user to manually click the "Check" button. But JavaScript is at least attempting to submit the form data.

For the record... this is happening to me on Arch with Chromium as well. The first time I tried it, I got a message about there being something wrong with my profile that I had to dismiss before anything proceeded. Now I can't get that message to present itself again, of course. I'm going to try with a fresh prefs folder a little later today to see if I can that message back.

KevinH · 09-14-2025, 12:06 PM

I just found this little gem in the latest Qt docs for QDesktopServices:

Quote:

static]bool QDesktopServices:

penUrl(const QUrl &url)

Opens the given url in the appropriate Web browser for the user's desktop environment, and returns true if successful; otherwise returns false.

If the URL is a reference to a local file (i.e., the URL scheme is "file") then it will be opened with a suitable application instead of a Web browser.

I added the bolding. So it seems whatever application is set to open ".html" files on that system is being launched. Not necessarily the browser. This explains how "calibre" became the selected application to launch on my Manjaro box, eventhough it was not set as my default browser.

The browser is acting as a fallback for that request. It would be interesting to see the list of applications that claim to handle html files are and what is set to be default.

DiapDealer · 09-14-2025, 12:35 PM

I backed-up/renamed my default profile for Chromium on Linux and was able to reproduce the Chromium error I was getting.

title: "Profile error occurred"
msg: "Something went wrong when opening your profile. Some features may be unavailable."

That message leads me to believe there may be a permissions issue of some kind.

In my case, the call to QDesktopServices::OpenUrl() seems to be functioning properly. A chromium browser is opened with the form data field pref-filled with css (one tab for every css file). The javascript fires in 3 seconds to submit to W3C, and that's when things fail. The resulting W3C error page seems to indicate it was looking for a file for input.

Quote:

Target: No file
I/O Error: You have sent an invalid request.

KevinH · 09-14-2025, 12:38 PM

I tried adding the name of the css file both as comments inside the css file and in a title tag in the on the fly created form html (created in CSSResource.cpp) but the W3C Validator ignores both and returns nothing at all that might indicate the source.

So there is no identifying way to see the css file name that is associated with the results sent back. So really validating one css file at a time makes the most sense.

And no matter what I try both approaches just work on MacOS and Manjaro Linux so I will need help tracking down what is going on.

DiapDealer · 09-14-2025, 01:08 PM

I think we're overthinking it! I changed the action url in CSSResources.cpp from 'http' to https' and it all works for me now (on Linux with Chromium)! So I'm thinking that the automatic redirect from http to https may have been working for some OS/browser combinations and not for others?

I'll see if it works on the Windows machines I was having trouble with.

KevinH · 09-14-2025, 01:17 PM

Wonderful! That would explain everything!

Let's hope that what it is.

DiapDealer · 09-14-2025, 01:43 PM

As far as getting the file names, I just don't think it's possible with the submission method we're using. We're submitting the css data and the desired css-level to W3C and nothing else.

I can look to see if anything named in the validator method is displayed that we could use, but I doubt it. We'd probably have to see if we could cobble together an html file that would simulate their file upload submission form rather than the data submission form we're using now.

09-13-2025, 07:38 PM	#17
KevinH Sigil Developer Posts: 9,125 Karma: 6404930 Join Date: Nov 2009 Device: many	So it appears Edge and Firefox are not allowing a local file to post via javascript? Very strange! This all works properly on macOS and Linux, so is this some new security "feature" of Windows? It it time to retire the W3C Validator website? Does the website itself work on Windows with Firefox and Edge when done manually? Last edited by KevinH; 09-13-2025 at 08:44 PM.

09-14-2025, 08:44 AM	#21
KevinH Sigil Developer Posts: 9,125 Karma: 6404930 Join Date: Nov 2009 Device: many	I will look into if adding an html title tag helps in distinguishing the multiple buffers. And yes I think it must be browser security setting related. But setting the default browser does not always seem to be detected by Qt. In my testing on Manjaro, I had to remove falkon (a Qt based browser) and even calibre (temporarily) as both were chosen before my selected default browser as handling html files! By the way falkon gave me the exact same errors you are seeing but it did not allow javascript by default. Last edited by KevinH; 09-14-2025 at 08:55 AM.

09-14-2025, 09:34 AM	#24
DiapDealer Grand Sorcerer Posts: 28,932 Karma: 207182180 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	No. There's content in the text area when the javascript fires after 3 seconds. I realize my previous post might have been a little misleading. Minus the form data, going directly to that url produces the same errors listed on the results page. Plus I was saying that if javascript were not allowed, the content should still be there after 3 seconds waiting for the user to manually click the "Check" button. But JavaScript is at least attempting to submit the form data. For the record... this is happening to me on Arch with Chromium as well. The first time I tried it, I got a message about there being something wrong with my profile that I had to dismiss before anything proceeded. Now I can't get that message to present itself again, of course. I'm going to try with a fresh prefs folder a little later today to see if I can that message back. Last edited by DiapDealer; 09-14-2025 at 11:18 AM.

09-14-2025, 01:08 PM	#28
DiapDealer Grand Sorcerer Posts: 28,932 Karma: 207182180 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I think we're overthinking it! I changed the action url in CSSResources.cpp from 'http' to https' and it all works for me now (on Linux with Chromium)! So I'm thinking that the automatic redirect from http to https may have been working for some OS/browser combinations and not for others? I'll see if it works on the Windows machines I was having trouble with. Last edited by DiapDealer; 09-14-2025 at 01:10 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
CSS validation uses wrong validator?	bookman156	Sigil	18	03-26-2016 05:22 PM
CSS validation error	kamanza	Sigil	3	12-17-2012 05:40 PM
CSS validation error	kamanza	Conversion	11	12-12-2012 03:21 AM
ADE breaks CSS --> CSS Validation: Parse Error / Value Error	dasboeh	ePub	4	12-10-2012 04:25 AM
Question about validation and items referenced in css	ldolse	Sigil	9	02-02-2011 05:17 AM

09-13-2025, 07:32 PM	#16
KevinH Sigil Developer Posts: 9,125 Karma: 6404930 Join Date: Nov 2009 Device: many	Have you enabled javascript in Edge? I thought Edge and Chrome used the same basic engine?

09-13-2025, 07:57 PM	#18
DiapDealer Grand Sorcerer Posts: 28,932 Karma: 207182180 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	My only question is why the OP can get things to work on Windows 11 & Firefox by having the browser open? And even when they don't have it open, it sounds like it's the first empty tab that's the only one not validating.

09-14-2025, 09:09 AM	#22
DiapDealer Grand Sorcerer Posts: 28,932 Karma: 207182180 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	The error I'm seeing is exactly what I see if I go to the form submission url from CSSResource.cpp with no post content. https://jigsaw.w3.org/css-validator/validator The local JavaScript is performing the submit after 3 seconds though. Otherwise, the 'Check' button would be waiting for me to click it I would think.

09-14-2025, 09:19 AM	#23
KevinH Sigil Developer Posts: 9,125 Karma: 6404930 Join Date: Nov 2009 Device: many	So nothing in that textarea? That is very strange. Something is fishy. Perhaps we temporarily lengthen the auto submit to 20 seconds so that the user can visually confirm that the css has been properly copied into the form textarea for debug purposes? If it really is blank we can start to add debug to the CSSResource.cpp to try to figure out why? GetText() should always return with the proper CSS text.

09-14-2025, 12:38 PM	#27
KevinH Sigil Developer Posts: 9,125 Karma: 6404930 Join Date: Nov 2009 Device: many	I tried adding the name of the css file both as comments inside the css file and in a title tag in the on the fly created form html (created in CSSResource.cpp) but the W3C Validator ignores both and returns nothing at all that might indicate the source. So there is no identifying way to see the css file name that is associated with the results sent back. So really validating one css file at a time makes the most sense. And no matter what I try both approaches just work on MacOS and Manjaro Linux so I will need help tracking down what is going on.

09-14-2025, 01:17 PM	#29
KevinH Sigil Developer Posts: 9,125 Karma: 6404930 Join Date: Nov 2009 Device: many	Wonderful! That would explain everything! Let's hope that what it is.

09-14-2025, 01:43 PM	#30
DiapDealer Grand Sorcerer Posts: 28,932 Karma: 207182180 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	As far as getting the file names, I just don't think it's possible with the submission method we're using. We're submitting the css data and the desired css-level to W3C and nothing else. I can look to see if anything named in the validator method is displayed that we could use, but I doubt it. We'd probably have to see if we could cobble together an html file that would simulate their file upload submission form rather than the data submission form we're using now.

Advert

Advert