Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Why Polyfilling CSS Is Hard

Why Polyfilling CSS Is Hard

New features in JavaScript are often tested first by using a polyfill. However, this is not that simple (or even impossible) in the case of CSS, although we all know that "CSS is awesome". Why does this problem exist? In this talk you will learn how CSS interacts with the other parts of the browser and what the challenges for creating a polyfill for new CSS features are.

Julian Viereck

October 14, 2014
Tweet

More Decks by Julian Viereck

Other Decks in Programming

Transcript

  1. Outline of the talk • What is a Polyfill? •

    CSS is the Swiss Knife of the browser • CSS + JS 㱺 Polyfill all the things? • Short answer: No - but why? • Conclusion
  2. Polyfill • Replicate something the browser doesn’t have yet •

    Personally also: • Performance less important • Should not break existing features • E.g. setting style=“float: right” should still work
  3. – The Extensible Web Manifesto “Make it possible to polyfill

    more of the platform's new features.” Extensible Web Manifesto <3 Polyfill
  4. What’s in the CSS Box • CSS interacts with: •

    Visual appearance (text color, border, …) • Layout: • Dimensions of elements (width, height, …) • Position of elements (absolute position, CSS translation, …) • Interaction with other elements (inline vs block display, …) • Time evolution (CSS animations) • Content definition (via content property), GPU Acceleration • CSS “contains”: • Constraint solver • Interactive Query language (e.g. div:hover { color: red }) • And many more (CSS Variables, …)
  5. Polyfill CSS via CSS + JS • Example: • Polyfill

    CSS Animations • Set position in every requestAnimationFrame • From JS: `element.style.top = i +“px”` • Existing CSS features + JS 㱺 Polyfill ✓
  6. When does CSS Polyfill
 work at all? • Works if:

    • Can express new CSS features in terms of existing CSS features Goal: Existing features: Polyfill-able? ✓=yes ✓*=well
  7. What’s in the CSS Box • CSS interacts with: •

    Visual appearance (text color, border, …) • Layout: • Dimensions of elements (width, height, …) • Position of elements (absolute position, CSS translation, …) • Interaction with other elements (inline vs block display, …) • Time evolution (CSS animations) • Content definition (via content property), GPU Acceleration • CSS “contains”: • Constraint solver • Interactive Query language (e.g. div:hover { color: red }) • And many more (CSS Variables, …) ✓* ✓* x ✓/x ✓ Polyfill-able with CSS + JS: x=no , ✓=yes, ✓*=well x ✓ ✓
  8. Grid Style Sheet • Constraint CSS (CCSS):! • #article[font-size] ==

    #box[height] / 12 !strong • Grid-Flavored VFL! • Turns: • #panel[left] + 10 == #button1[left]; • #button1[right] + 10 == #button2[left]; • Into: • @horizontal |-[#button1]-[#button2]-| in(#panel) gap(10); • And more crazy things!
  9. Problem with 
 “Custom” Layout Engine • Need to map

    to existing features • DOM gets lots of style=“…” and 
 DOM event listeners • Need to work with existing CSS features • Is “float: left” handled in your engine? Getting floats right is hard, see: http://pcwalton.github.io/blog/2014/02/25/revamped-parallel-layout-in-servo/
  10. Might be okay, but… • Polyfill layout might be “okay’ish”

    • But, recall - CSS Is The Swiss Knife: • Interacts with many parts of the browser • But not all internals are exposed!
  11. Possibilities ≠ 
 Existing Features • Possibilities: • Change tree

    location • Add new boxes • Pollute styles • Change sizes • … (see next slide) ➡ Handwaving Solutions ➡ renderInSameBoxAs? ➡ GhostDom? ➡ ShadowStyles? ➡ ? ➡ ?
  12. Possibilities ≠ 
 Existing Features • And Even More: •

    Controlling font / image loading & rendering • Line breaking • RTL layout • Style single letter • … https://github.com/igrigorik/css-font-timeout/blob/patch-1/README.md http://extensiblewebreportcard.org/#toc-20 Internals are not ! exposed to developer more details:
  13. Scripting CSS? • How about making CSS “turing complete”/scriptable? •

    No :) • One turing complete language in the browser is enough (aka. JavaScript) • Keeps a lot of things simpler (GC, …) • Problem are underlaying missing exposed features • Better: More ways to express intends
  14. Conclusion • Writing a Polyfill for CSS: • Works fine

    for some features (animations, …) • For layout • Solutions are more hacks than polyfills • For rendering • Try to map to SVG/Canvas or bad luck :/ • Therefore: • Need new low-level CSS features to enable CSS Polyfills Not sure if this
 is a good idea!