diff --git a/UseCaseComparisons.md b/UseCaseComparisons.md
index dd5825b3..9f3c0f73 100644
--- a/UseCaseComparisons.md
+++ b/UseCaseComparisons.md
@@ -4,27 +4,27 @@ This document is indended to address the use cases addressed by both the `pictur
Assuming three image “breakpoints” based on maximum widths, using pixel-based values: 400px, 600px, and 800px. The smallest image source has been designated as fallback content.
**`picture` Element*
-`
**Extended `srcset`**
-
+``
### Using min-width ###
Assuming three image “breakpoints” intended to remain in sync with a media-query-based CSS layout making use of `min-width` media queries.
**`picture` Element**
-
- `
**Extended `srcset`**
N/A
@@ -34,19 +34,19 @@ N/A
Assuming three image “breakpoints” intended to remain in sync with a media-query-based layout specced in `em` units.
**`picture` Element**
-
+`
-
+`
**Extended `srcset`**
N/A
Note: the `em` values above could be manually converted to `px` by the author to ensure that the image breakpoints are within a few pixels of the `em`-based layout media queries, resulting in:
-
+``
While the `em`-based CSS layout will be reevaulated based on user zoom in all modern browsers (see http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/ for a description and functional example) and we can assume the same for the `em`-based image breakpoints, the `px`-based image breakpoints will fall out of sync with the layout when the user zooms in or out.
@@ -54,47 +54,54 @@ While the `em`-based CSS layout will be reevaulated based on user zoom in all mo
[ … ]
**`picture` Element**
-
+`
-
+`
**Extended `srcset`**
N/A
## Display Density
-The two proposals are functionally identical in terms of dealing with display density when independent of the “Viewport Sizes” use case above:
+The two proposals are functionally identical in terms of dealing with display density when independent of the “Viewport Sizes” use case:
+
+**`picture` Element**
+`
+
+
+`
-
+**Extended `srcset`**
+``
## Display density in conjunction with viewport sizing ##
Assuming three image “breakpoints” based on maximum widths, using pixel-based values: 400px, 600px, and 800px. The smallest standard resolution image source has been designated as fallback content.
**`picture` Element**
-
+`
-
+`
**Extended `srcset`**
-
+``
## Print sources
Assuming two image sources indended for display on screen depending on window size, each with a standard and high-definition source, and a single image source intended for printing.
**`picture` Element**
-
+`
-
+`
**Extended `srcset`**
N/A
@@ -103,11 +110,11 @@ N/A
This is based on the high-contrast mode and ambient light media queries currently being proposed in the CSS WG.
**`picture` Element**
-
+`
-
+`
**Extended `srcset`**
N/A
@@ -122,11 +129,12 @@ N/A
## Potential for addressing new image formats
**`picture` Element**
-
-
-
+`
+
+
-
+`
**Extended `srcset`**
+N/A
diff --git a/implementation_plan.md b/implementation_plan.md
deleted file mode 100644
index b1c50f68..00000000
--- a/implementation_plan.md
+++ /dev/null
@@ -1,14 +0,0 @@
-steps towards a working picture element
---------------------
-* Should I insist on compiling chromium with vanilla WebKit?
-* HTMLPictureElement: public HTMLImageElement
-* What do we want to do with ImageInnerElement? Should we duplicate a
- similar one as HTMLPictureElement's shadow DOM, and can we use it as is?
-* Add handling of tag to the PreloadScanner
-* How can I do media queries eval inside the preload scanner?
- MediaQueryMatcher? All I need to get started is get the window
-dimensions from somewhere...
-* How can I scan source tags with the preload scanner?
-* What the hell does the HTMLTagNames.in syntax mean !?!?!?
-* Add HTMLPictureElement.h include to HTMLElementFactory by changing
- make_names.pl