|
So as far as I can tell, my Middleman installation literally does not take any layout files that are not in ERb format. What I've seen perfectly good Middleman examples that use HAML layouts, what the gently caress? I'm just ranting now, cause it's annoying.prom candy posted:HAML is great, where did you get this idea? I like it myself, it's a lot more convenient than ERb or raw HTML.
|
# ? Aug 3, 2014 20:50 |
|
|
# ? May 16, 2024 18:39 |
Probably better suited for the Rails thread honestly
|
|
# ? Aug 3, 2014 21:31 |
|
Pollyanna posted:I like it myself, it's a lot more convenient than ERb or raw HTML. Are you using notepad.exe or something?
|
# ? Aug 3, 2014 21:38 |
|
pokeyman posted:Are you using notepad.exe or something? Having a whitespace-aware language with no closing tags is more readable no matter what text editor you're using.
|
# ? Aug 3, 2014 22:36 |
|
Kobayashi posted:Good info, thanks. The proxy is probably a bit overkill for my needs. A lot of what I want to do boils down to adding a little empirical weight to my subjective observations. For example, instead of simply telling a client, "hey, you're really hurting the user experience by using multiple redirects," I want to quantify the effects. I wish it wasn't so dorky to find an area with poor network reception and plop open my laptop, but if that's what it takes to make my case, that's what I'll do. In addition to the other suggestions, I saw on one of the recommended newsletters that the latest versions of Safari now support the Navigation Timing API. I hadn't heard of this before, and it's already supported by the other major browsers, but it looks like this could enable in-page performance analytics that are similar to what I want to do.
|
# ? Aug 4, 2014 00:19 |
|
prom candy posted:HAML is great, where did you get this idea? From using Slim instead.
|
# ? Aug 4, 2014 00:29 |
|
pipes! posted:From using Slim instead. Yeah HAML was a good stepping stone when it was the only templating lang around, but the jade styles of syntax have cut even more visual noise out of HTML editing with no added problems.
|
# ? Aug 4, 2014 01:26 |
|
pipes! posted:From using Slim instead. I discovered Slim yesterday and it's super interesting. Going to convert my existing ERb templates to Slim this week. Is there anything I should watch out for? I found a gem for it, but I figured doing it manually would be a good way to learn it.
|
# ? Aug 4, 2014 05:48 |
|
enraged_camel posted:Is there anything I should watch out for? If you're using a build tool like Gulp the error reporting is not great. Chances are if there's an issue, it's because something isn't piped properly (or that's what I ran into, at least). You can enable it in CodePen in the HTML input area if you want to play around a little.
|
# ? Aug 4, 2014 15:11 |
|
pipes! posted:From using Slim instead. Okay yeah Slim is pretty great. I'm actually not sure why I haven't switched to it considering I've been using Emblem to work on Ember projects. One thing I have noticed with HAML is that elements with lots of data-tags-with-hyphens get ugly pretty quick when you end up with something like code:
code:
|
# ? Aug 4, 2014 22:44 |
|
prom candy posted:The Slim sytax of Let's see how I can turn that into valid HTML: code:
|
# ? Aug 4, 2014 23:38 |
|
Yup, they're exactly the same.
|
# ? Aug 8, 2014 03:29 |
|
So slim is basically HTML but with Python-style white-space rules to obviate the need for braces? I'm okay with that.
|
# ? Aug 8, 2014 04:16 |
|
EB Nulshit posted:So slim is basically HTML but with Python-style white-space rules to obviate the need for braces? I'm okay with that. The thing I like more about the white space rules is that it makes it really easy to understand the flow of the document at a glance and eliminates the need to have closing tags. I know most modern text editors are pretty good at managing your closing tags but one little slip up can leave you with a frustrating debugging experience. Especially since different browsers will try to comp for missing or extra closing tags in their own way.
|
# ? Aug 8, 2014 05:17 |
|
prom candy posted:Especially since different browsers will try to comp for missing or extra closing tags in their own way. How so?
|
# ? Aug 8, 2014 07:12 |
|
Less versions of IE/Win to debug! As of 2016, only the latest version of Internet Explorer per Windows version will be supported
|
# ? Aug 8, 2014 13:40 |
|
The Merkinman posted:Less versions of IE/Win to debug! Great, now just get all the corporations that are still on XP to migrate! It also means no flexbox until May 2017.
|
# ? Aug 8, 2014 14:02 |
|
Why is my Avant Garde font appearing different on Chrome for Mac OS X and Chrome for Windows? I am very confused. zfleeman.com
|
# ? Aug 8, 2014 16:45 |
|
zfleeman posted:Why is my Avant Garde font appearing different on Chrome for Mac OS X and Chrome for Windows? I am very confused. Because either your Windows or OS X machine does not have Avant Garde installed, so it's falling back to the others in your font stack until it finds one it can display. http://dowebsitesneedtolookexactlythesameineverybrowser.com/ If for some reason you feel the need to ensure everyone sees the exact same font, use one of the "safe" ones, or use a face you can include via CSS. Google fonts is a nice place to get free ones. People can only see fonts they have installed on their machine, unless you deliver the font along with your page. Lumpy fucked around with this message at 16:53 on Aug 8, 2014 |
# ? Aug 8, 2014 16:50 |
|
I'm designing an API right now that presents some objects like so:JavaScript code:
JavaScript code:
1. http://blahblah.com/place/1/special_output/ 2. http://blahblah.com/place/1?special_output=true or what? If it's just personal preference I think I'll go with #1 as I prefer the cleaner look of urls without query parameters, but if there's a standard for REST API's (that I can't seem to find right now), I'll stick to the standard.
|
# ? Aug 8, 2014 18:32 |
|
Lumpy posted:Because either your Windows or OS X machine does not have Avant Garde installed, so it's falling back to the others in your font stack until it finds one it can display. I've been using cssfontstack.com, which I thought had 'web-safe' fonts.
|
# ? Aug 8, 2014 18:40 |
|
zfleeman posted:I've been using cssfontstack.com, which I thought had 'web-safe' fonts. If you hover over the i you'll see it's installed on approximately 1.08% of Macs and 0% of Windows machines.
|
# ? Aug 8, 2014 18:58 |
|
The Merkinman posted:If you hover over the i you'll see it's installed on approximately 1.08% of Macs and 0% of Windows machines. Oh, wow. Well, I really like the way it looks on my Mac. How can I figure out what it is that I am seeing so I can use that instead?
|
# ? Aug 8, 2014 19:00 |
|
Thermopyle posted:My question is, how should I allow the consumer to request this optional output? I can do URLs like: I'm not aware of standards around this - I just see "X is optional" and think immediately of the query, not the path. You've gone one farther and said "X is optional and just modifies the output". /place/id?xml=true is a clearer logical parallel that I think makes the the case a bit better.
|
# ? Aug 8, 2014 19:20 |
|
zfleeman posted:Oh, wow. Well, I really like the way it looks on my Mac. How can I figure out what it is that I am seeing so I can use that instead? If you don't have Firebug, I guess you could manually misspell a font in the stack until you see it change Even if you find which one it is that you like, you only know it is showing that font on your Mac. If you need everyone to see the exact same font, then either pay for one through typekit or get a free one (converting it with font squirrel and host it like you images, or use Google Fonts. The Merkinman fucked around with this message at 19:38 on Aug 8, 2014 |
# ? Aug 8, 2014 19:31 |
|
Thermopyle posted:I'm designing an API right now that presents some objects like so: I would do 2. to allow users to request specific things (/1?fl=thing_name), and I would alias common actions (in this case, /1/special_output). (also I would just use Solr)
|
# ? Aug 8, 2014 19:32 |
|
Munkeymon posted:I'm not aware of standards around this - I just see "X is optional" and think immediately of the query, not the path. You've gone one farther and said "X is optional and just modifies the output". /place/id?xml=true is a clearer logical parallel that I think makes the the case a bit better. This is a good point and you've convinced me.
|
# ? Aug 8, 2014 19:38 |
|
Thermopyle posted:My question is, how should I allow the consumer to request this optional output? I can do URLs like: Normally your API would return relations as references JavaScript code:
JavaScript code:
JavaScript code:
|
# ? Aug 8, 2014 19:46 |
|
Sedro posted:...good points... I get a lot of that for nearly-free as I'm using django-rest-framework, so that's something.
|
# ? Aug 8, 2014 19:49 |
|
pokeyman posted:How so? I don't remember the specifics since I haven't had to deal with closing tags on a regular basis in a very long time, but issues like this that I found while Googling were never fun to debug: http://stackoverflow.com/questions/5623109/firefox-automatically-adding-closing-form-tag-too-early-ie-and-chrome-ok
|
# ? Aug 8, 2014 19:58 |
|
Munkeymon posted:I'm not aware of standards around this - I just see "X is optional" and think immediately of the query, not the path. You've gone one farther and said "X is optional and just modifies the output". /place/id?xml=true is a clearer logical parallel that I think makes the the case a bit better. However ?xml=true is a special case when a HTTP header should be used instead, Accept: application/xml versus Accept: application/json.
|
# ? Aug 8, 2014 20:18 |
|
MrMoo posted:However ?xml=true is a special case when a HTTP header should be used instead, Accept: application/xml versus Accept: application/json. Yeah, you're technically right, but doing that from a browser is kind of annoying and could behave in unexpected ways, and that's the perspective I'm coming from/assuming. The server could easily just check both to be a more friendly API, I guess.
|
# ? Aug 8, 2014 20:55 |
|
Munkeymon posted:Yeah, you're technically right, but doing that from a browser is kind of annoying and could behave in unexpected ways, and that's the perspective I'm coming from/assuming. The server could easily just check both to be a more friendly API, I guess. Yeah, the real issue from my viewpoint is that so many sites do the format selection via a query parameter that consumers kind of expect it. A lot of sites support both the HTTP header and a query parameter.
|
# ? Aug 8, 2014 20:59 |
|
Munkeymon posted:Yeah, you're technically right, but doing that from a browser is kind of annoying and could behave in unexpected ways, and that's the perspective I'm coming from/assuming. The server could easily just check both to be a more friendly API, I guess. Varying on Accept also invites caching bugs, since URL + last-modified/etag is no longer enough to determine whether the resource needs to be refetched.
|
# ? Aug 8, 2014 21:14 |
|
I don't do much web development, but I'm putting something together using google charts, and using jquery to toggle visibility on some elements. I don't have much experience doing anything with javascript, but this stuff is normally pretty easy to piece together. http://jsfiddle.net/d5uq9780/ Unfortunately, I get this annoying "GViz is Great." text tag showing up when I show a hidden google chart. Any ideas what I'm doing wrong? I can't find anything on this anywhere, though google searches show the tag showing up in random pages.
|
# ? Aug 8, 2014 21:22 |
|
Subjunctive posted:Varying on Accept also invites caching bugs, since URL + last-modified/etag is no longer enough to determine whether the resource needs to be refetched. That sounds more like an API bug if merely varying the Accept header changes the content (as distinct from the presentation) of the response. Which probably means a dozen popular APIs do just that.
|
# ? Aug 8, 2014 21:22 |
|
pokeyman posted:That sounds more like an API bug if merely varying the Accept header changes the content (as distinct from the presentation) of the response. Well, it means that if you have the XML flavour of http://thing.com/api/1/pokeyman in cache and you get a request for that same URL looking for the JSON representation, you can't return the cached content. Which is fine, except your cache needs to know that, and I would be totally unsurprised to discover that many caching setups don't.
|
# ? Aug 8, 2014 21:30 |
|
Subjunctive posted:Well, it means that if you have the XML flavour of http://thing.com/api/1/pokeyman in cache and you get a request for that same URL looking for the JSON representation, you can't return the cached content. Which is fine, except your cache needs to know that, and I would be totally unsurprised to discover that many caching setups don't. Oh I see. I was thinking of client-side caching, and I think you're describing server-side caching, which makes total sense as a place you'll see this problem.
|
# ? Aug 8, 2014 21:58 |
|
pokeyman posted:Oh I see. I was thinking of client-side caching, and I think you're describing server-side caching, which makes total sense as a place you'll see this problem. You could see it on the client side of an API as well, if the HTTP stack caches. That's actually what I was thinking of.
|
# ? Aug 8, 2014 22:53 |
|
|
# ? May 16, 2024 18:39 |
|
Civil posted:I don't do much web development, but I'm putting something together using google charts, and using jquery to toggle visibility on some elements. I don't have much experience doing anything with javascript, but this stuff is normally pretty easy to piece together. From what I can tell it's nothing you're doing wrong; you're loading the "Visualization" Google API module to make your chart, and the "GVis" tag is being added by that at their end as a means of acknowledgement I suppose.
|
# ? Aug 9, 2014 07:18 |