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.

Sign up for GitHub

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

Jump to bottom

Namespaced elements of XHTML and CSS are not correctly handled #1513

Open
danny0838 opened this issue Jul 25, 2024 · 4 comments
Open

Namespaced elements of XHTML and CSS are not correctly handled #1513

danny0838 opened this issue Jul 25, 2024 · 4 comments
Labels
bug

Comments

@danny0838
Copy link

danny0838 commented Jul 25, 2024 •
edited
Loading

Describe the bug
Namespaced elements of XHTML and CSS are not correctly handled.

To Reproduce
Steps to reproduce the behavior:

  1. Create the test page and CSS somewhere:
    • element.xhtml 
      <!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:myns="http://example.com/myns">
<head>
<meta charset="UTF-8" />
<style>
@namespace myns url("http://example.com/myns");
myns|elem-1 { background-color: lime; }
</style>
<style>
@namespace url("http://example.com/myns");
elem-2 { background-color: lime; }
</style>
<style>
@namespace myns url("http://example.com/myns");
myns|elem-3 { background-color: lime; }
</style>
<style>
@namespace url("http://example.com/myns");
elem-4 { background-color: lime; }
</style>
<style>
@import "./element-import.css";
elem-6 { background-color: lime; }
</style>
</head>
<body>
<blockquote>
<myns:elem-1>myns:elem-1</myns:elem-1>
</blockquote>
<blockquote>
<myns:elem-2>myns:elem-2</myns:elem-2>
</blockquote>
<blockquote>
<elem-3 xmlns="http://example.com/myns">elem-3</elem-3>
</blockquote>
<blockquote>
<elem-4 xmlns="http://example.com/myns">elem-4</elem-4>
</blockquote>
<blockquote>
<elem-5 xmlns="http://example.com/myns">elem-5</elem-5>
</blockquote>
<blockquote>
<elem-6>elem-6</elem-6>
</blockquote>
</body>
</html>
    • element-import.css 
      @namespace url("http://example.com/myns");
elem-5 { background-color: lime; }
  2. Save the page with default options
  3. Open the saved page

Expected behavior

  • Namespaced CSS do not apply, since the saved page is .html instead of .xhtml.
  • Style rule of elem-6 is not correctly namespaced (should be under http://www.w3.org/1999/xhtml instead of http://example.com/myns).

Environment

  • OS: Win10
  • Browser: Chrome 126
  • Version: 1.22.54
@gildas-lormeau
Copy link
Owner

gildas-lormeau commented Jul 29, 2024 •
edited
Loading

Thank you very much for the detailed report!

It looks like the proper way to fix this issue would be to always use a separate <style> element for each @import instead of inlining their content. I'll have to think about it... Out of curiosity, how do you handle this problem in webscrapbook?

@danny0838
Copy link
Author

danny0838 commented Jul 29, 2024 •
edited
Loading

WebScrapBook normally saves each @import as a separate file, and thus doesn't natively has the issue.

When saving as single HTML, WebScrapBook recursively converts the <link> and @import content into a data URL (need some special care about circular importing). This is ugly and not volume efficient but such stupid fidelity can prevent many potential issues introduced by converting a <link> or @import into <style>, for example:

  1. When the @import contains a media, layer, or support query.
  2. When the @import appears after another CSS rule (which makes it invalid by spec and ignored by most modern browsers).
  3. When the <link> is an alternative stylesheet and may have been switched by the browser (e.g. Firefox supports switching alternative stylesheet).

P.S.: As a developer I really hate all the CSS related things...

@gildas-lormeau
Copy link
Owner

gildas-lormeau commented Jul 29, 2024 •
edited
Loading

Sorry, I had forgotten that webscrapbook saves resources separately. In fact, I do more or less the same thing (I guess) in SingleFile when saving the page in self-extracting format. The only major difference is that I use Blob URIs.

I'm still studying on this problem and I can confirm that it's probably going to take me a while to fix it because of the refactoring. Anyway, I think it should be doable. For now, I'm just resting my brain to get back to it later.

I completely agree with you about CSS. For example, I'm not a fan of the fact that the URL passed to the FontFace constructor is inaccessible via the DOM. More recently, I've (re-)discovered CSS Worklets (see also the paint function). It seems that some sites are starting to use them (see #1502). I'd also like to avoid having to use a third-party library to parse the CSS. And let's not even talk about constructed (and adopted) stylesheets... It was tense enough with the Shadow DOM, I hope Houdini APIs won't make our extensions obsolete.

@danny0838
Copy link
Author

It is unfortunate that there is no available standard-compliant CSS parser, making many things difficult to handle. Although browsers support CSSOM, it's not enough to retrieve details of a apecific cssText in a rule, such as referenced CSS variables.

The closest one so far is parse-css. Unfortunately it's still buggy and needs improvement, and the maitainer still haven't review my patch PRs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@gildas-lormeau @danny0838