21–30 of 66 posts
Earlier quoted context omitted.
> is it really necessary to have this as an npm package ? Is anything really necessary? Not snark: almost nothing is necessary in life but many things are convenient .
Surely a cdn is more convenient. I don't want to install an entire package manager just to 'install' 2 CSS files.
Oooh this will not end well.. Also side question, is it really necessary to have this as an npm package ?
On the contrary. CSS functions and mixins may make a lot of current cruft unnecessary.
Obvious question: are CSS functions Turing complete?
Welp, time to make a @function preprocessor. There is no reason for every single client to recalculate things which could have been completely or partially calculated at build time.
Welp, time to make a @function preprocessor. There is no reason for every single client to recalculate things which could have been completely or partially calculated at build time.
But there are also plenty of use cases where recalculation will be valuable in the client. CSS variables cascade so a preprocessor isn't going to be able to know ahead of time what any given variable value is.
Luckily, CSS Modules are starting to land in multiple browsers. Firefox added support behind a flag, and it might ship in 145.
So you'll be able to import the CSS from your JS modules, and apply it to the document:
import extras from 'css-extras' with {type: 'css'};
if (!document.adoptedStyleSheets.includes(extras)) {
document.adoptedStyleSheets.push(extras);
}
this.shadowRoot.adoptedStyleSheets.push(extras);Earlier quoted context omitted.
XHTML (or the XML syntax for HTML) wasn't removed (see: https://html.spec.whatwg.org/multipage/introduction.html#htm... ). You may be thinking of XSLT, which may be removed in future.
So I guess it really is true that nothing actually gets removed -- except the one that wasn't actually controlled by WhatWG or W3C. Is there still a real-world use case for XHTML/"XML syntax for HTML", or is this just exhibit A that no standard can actually be removed from browsers? Re: XSLT, back in the everything-is-XML days I desperately wanted to like XSLT, it seemed so useful (I was that annoying co-worker telli…
If I need the markup of a page to not contain any structural errors, I often use XHTML for testing at least because, though it's a little more verbose, if there's a nesting error, for example, the browser will flat out refuse to render it and show some sort of stacktrace error page instead. So it's quite a good built-in "tool" for checking that your markup is clean.
With HTML, everything goes and the browser will happily render broken markup, which is probably the correct default for the web as a whole. After all, you surely don't want a page like Wikipedia to show an error message to its users because a developer forgot to close a tag somewhere.