Migrated my website from Graphics.Element to elm-html

[Max Goldstein]

Today I upgraded my website from 0.14 and Graphics.Element to use elm-html. In the end I like the result but it took a little hair-pulling. It's not on GitHub but you can grab the source.

Background, briefly: my website is meant to serve as a professional contact point and link to side projects. I want to not spend too much time on it, not master bootstrap/jquery/their ilk, but I want something that's half-decent on mobile. The most prominent thing there is an animated bar chart I made in D3, so I was a little worried about DOM diffing interfering with that. Turns out that if I created the SVG in Elm, it wouldn't render properly, but if I appended to a div made by Elm it works fine.

On the plus side, I'm using Markdown everywhere and that becomes easy to style with CSS, even if it means nesting h2->div->p elements. There's no way to add attributes or a different tag to elm-markdown; all you can do is make it the child of something. Additionally, there's no small caps option in the Text library, so before i had to assign it a tag (id) and use CSS of that; now i can do the sane thing and use a class, so I can add more than one. Most of the styling is in a separate CSS file.

The only place I use inline styles is with regard to spacing and layout. In the old version, I created spacer elements and flowed right to center the main content. After falling down a painful rabbit hole with CSS and positioning, including the problem of getting the spacers to extend down the end of the viewport when I didn't know how tall the page was, it occurred to me to use spacers at all. The body has a gray background, and the content div has a white one. Inline styles are used to set absolute positioning and width on the content div; these numbers are derived from Window.dimension. (It's a very hacky methodology for responsive design.) Now the problem was if the window was smaller than the div; the content flowed off when you scrolled. So I set overflow: scroll; which works except you can't scroll on the gray body. If someone has a better technique, I'd like to know what it is.

Another annoying thing was that virtual-dom will silently drop invalid attributes. I was passing widths without a specified unit and they just disappeared. Everything was fine when I started add "px" to the end. Furthermore, there was all sorts of crazy margins, which I had to strip out in CSS. I'm not sure what's going on there.

Jacob's Font Awesome library started this off, because how I was doing social media links before was visually similar but a total hack. It's great to have a native solution.

All-in-all, I learned some CSS and got much cleaner Elm code behind my website. Hopefully this writup was useful to someone.

[Max Goldstein]

I figured out how to get scrolling in the gray gutter working. I have a background div that is white, the desired width, the current height and offset, and fixed position (fixed in screen space). Then the content itself is absolutely positioned (fixed in page space). The result is that you scroll like a normal page, but there's a white box that always stays exactly where I want it underneath it.

Maybe that's obvious (or horrifying) to CSS experts but I think it's pretty cool.

[stepvhen]

On Sunday, May 17, 2015 at 1:12:42 AM UTC-4, Max Goldstein wrote:

I'm using Markdown everywhere and that becomes easy to style with CSS, even if it means nesting h2->div->p elements.

When I was moving my website over to elm-html I figured out that you can include CSS directly in a markdown block, but only if that block has no other content in it, otherwise the styling gets screwy. I had do use this path because I wanted four different stylings for links on my website, and there was no method for that with standard elm/markdown.

Here's the relevant code, and the website. (mostly just tricks to parse colors onto a webpage as easily as a terminal.

[Max Goldstein]

The first thing I noticed is that you've hacked together indexing into lists, and you're using the old unsafe head operation and haven't updated to 0.15. My first instinct was to use Arrays, which give you indexing, but still returns a Maybe. You have too many colors for an n-tuple (if not in theory, then in practice) so my unsolicited advice is to move to a record of tuples or single elements. Instead of relying on index to convey what's the background, use the record label to do so. That ought to make your code type-safe and it makes the semantics clearer by eliminating magic numbers. (Isn't it great when type-safety forces you to write cleaner code?) I'd recommend a specific record structure but I can't figure out what colors are which in the current code.

Sorry for the tangent - I see, styles injected into Markdown blocks which are parsed with sanitization turned off. You're doing so much formatting maybe it would be easier to use a table or something?

Anyway, don't let me tell you how to build your website, thanks for sharing.

[stepvhen]

No worries, thats all really valuable input. I haven't updated it in quite a while. All the colors are taken from xrdb settings (16 colors, with a foreground and a background); i rotate color schemes often, at minimum every 3 months, and I wanted a fast way to translate schemes from xrdb files to my website. The list stuff is definitely a hack, but it also allows me to map over it, since for displaying the hex codes it requires creating a color of that code and printing the code itself. I could definitely make a record, naming each color as it is in a regular xrdb scheme, but it might be more work than i feel like putting in.

Again, thanks for your input, I hadn't really considered another way.

[Kevin McGee]

Nice post, thanks!

Max, I'm very new to this party but I get the sense of tussle/debate/changes in regard to rendering Graphics Elements and HTML.  Do you have a minute to reply with some history or context?

Basically, my n00by question concerns the cognitive conflict between statements like "graphic elements are DOM nodes" (which I have read in this group) and the output of the elm-html package.

Since we are ultimately rendering to the browser, it seems everything ends up being a DOM node, right?

So I'm puzzling over the diff?

Best, KJM

PS. Absolutely positioned stuff horrifies only the purists :)