Comments (5)
I was about to report this (as I keep running into it a lot) and turns out there is already an issue. I was wondering if capturing styling by serializing document.styleSheets
had being considered at all. Potentially it could fall back to fetching contents for styleSheets who's rules can't be accessed at runtime.
I think this also has benefit of not needing to deal with import rules and etc.. as I believe imported sheets would also be listed.
from freeze-dry.
Alternative strategy might be to inline all the styles into elements themselves by obtaining those through getComputedStyle
API. But that is likely to increase overall page size.
from freeze-dry.
I was wondering if capturing styling by serializing
document.styleSheets
had being considered at all.
Yes, something to be tried out. I have not investigated how rich the CSSOM is, i.e. whether it lets us easily serialise the stylesheet again to get a string; ideally it would have (or we could create) an equivalent of Element.outerHTML
. But I vaguely remember that unlike with the HTML DOM, the comments cannot be accessed in CSSOM, quite unfortunately! (I think that put me off originally, opting to use postcss instead)
If we could always use the CSSOM, we could even remove the hassle with (and dependency on) post-css, which is now used to parse stylesheets in extract-links/from-css.js.
But as you say, we may need to fall back to fetching the contents, if the rules cannot be accessed through the CSSOM. Similar to how we deal with frames.
from freeze-dry.
I think this also has benefit of not needing to deal with import rules and etc.. as I believe imported sheets would also be listed.
You mean we would, for example, create two <link …>
elements, instead of keeping one link to a sheet that imports another? This could be an optimisation to flatten the resource tree (and in the current data:
URL approach, save space by avoiding base64-encoding an already base64-encoded string).
However, this approach would also manipulate the DOM unnecessarily. For various use cases, keeping things as equal as possible is desirable (e.g. for archiving or to keep xpath pointers intact). Moreover, some tricks would be needed to fix semantics; for example, if an stylesheet <link href="print.css" rel="stylesheet" media="print">
has an @import (orientation.landscape)
we should ensure that the newly created <link>
(or style
) element combines both media queries.
So I would probably opt to just leave the import structure intact. I do not see a difficulty in dealing with import rules (they have a .styleSheet
property to walk down the CSSOM), but I may miss somtehing. Instead of using document.styleSheets
, we could perhaps query all the style
and link[rel~=stylesheet i]
elements, and then take their .sheet
property.
By the way, one reason for reading document.styleSheets
: I see here that it also includes stylesheets defined in an HTTP Link header. Not that anybody uses that (I think?), but it may nice to support some day.
from freeze-dry.
You mean we would, for example, create two
<link …>
elements, instead of keeping one link to a sheet that imports another? This could be an optimisation to flatten the resource tree (and in the currentdata:
URL approach, save space by avoiding base64-encoding an already base64-encoded string).However, this approach would also manipulate the DOM unnecessarily. For various use cases, keeping things as equal as possible is desirable (e.g. for archiving or to keep xpath pointers intact). Moreover, some tricks would be needed to fix semantics; for example, if an stylesheet
<link href="print.css" rel="stylesheet" media="print">
has an@import (orientation.landscape)
we should ensure that the newly created<link>
(orstyle
) element combines both media queries.
I don't have specifics I just noticed that there is ownerRule
property on CSSStyleSheet
that according to MDN:
The read-only CSSStyleSheet property ownerRule returns the CSSImportRule corresponding to the @import at-rule which imported the stylesheet into the document. If the stylesheet wasn't imported into the document using @import, the returned value is null.
Which seems to imply that imported sheets would also be in the document.styleSheets
but may not be in HTML tree.
I guess you don't necessarily need to create link elements for imported sheets. Imported sheets could be just serialized and and import rule could be updated instead.
from freeze-dry.
Related Issues (20)
- Upstream freeze-dry dependency doesn't work with yarn HOT 4
- ESM support HOT 11
- Could you please publish used deps onto git as well HOT 3
- Do not make within-document links absolute
- Breaks on invalid URLs HOT 1
- Allow alternative blob seralizations HOT 4
- Handle encoding of subresources
- How to use in browser HOT 4
- Does it capture LocalStorage as well? HOT 1
- bug due to querySelector(All) assumptions
- freeze drying twitter seems to produce unreadable results. HOT 2
- Fix charset encoding of framed documents
- Error trying this on RunKit: Cannot find module 'doctype-to-string' HOT 3
- Subresources may disappear due to white space in data URLs
- Option to try erase hidden information
- awesome lib, can we have a working https://unpkg.com/freeze-dry link? HOT 1
- Is it possible to use freeze-dry from server? HOT 5
- Add a "who's using freeze-dry" section to readme HOT 1
- Ongoing development HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from freeze-dry.