Skip to content
This repository has been archived by the owner on Aug 6, 2021. It is now read-only.

For client side, any reason why not use CSSOM? #17

Open
andreinitescu opened this issue Jun 9, 2016 · 2 comments
Open

For client side, any reason why not use CSSOM? #17

andreinitescu opened this issue Jun 9, 2016 · 2 comments

Comments

@andreinitescu
Copy link

andreinitescu commented Jun 9, 2016

For client side, any specific reason not to just use CSSOM?
http://jsfiddle.net/v2JsZ/

@kemaldaggen
Copy link
Contributor

Hey @andreinitescu, thanks for the input. We thought about it too. But finally decided with a custom CSS parser.
Besides the obvious server side css parsing benefits, here are our reasons for not to use CSSOM:

  • Browser compatibility issues. Even on MDN page, they retrained to include a table due to many incompatibilities across different browser vendors
  • CSSOM requires you to actually put css into the page in order to get underlying object. While there are hacky methods to implement a usual interface to this hack, still doing a normal parsing seemed better.
  • CSS syntax is rather easy to parse.

But you are right, if we have programmatic direct access to browser's internal css parser, that would be way better.

@andreinitescu
Copy link
Author

andreinitescu commented Jun 9, 2016

Thank you Kemal.
I'm mostly worried about first one, compatibility across browsers.
Do you have any more info regarding that, any quick example which comes to your mind?

In order to parse CSS by CSSOM using a <style> element , I see the CSSOM objects and properties required are LinkStyle.sheet, CSSStyleSheet.cssRules, CSSStyleRule.style, CSSStyleDeclaration, which all seem from DOM Level 2 specification.
But maybe I'm missing something.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants