Hacker News new | comments | show | ask | jobs | submit | bill-nordwall's comments login

Yep! Neil Diamond wrote I'm A Believer.

Also, Carole King wrote Pleasant Valley Sunday. Here's her original demo: https://www.youtube.com/watch?v=FtyqPzeso5A

-----


I was able to get my java-applet-based VPN working again by temporarily re-enabling Apple's Java SE 6 applet plugin: http://support.apple.com/kb/HT5559

-----


Was it this one? http://www.geekwire.com/2012/lean-technical-chose-furnished-...

-----


Support for aria-hidden is still pretty spotty: http://www.456bereastreet.com/archive/201205/hiding_visible_...

-----


Why aren't the "ng*" attributes prepended with "data-" to make them valid HTML5 attributes? It's a minor nit, but kind of annoying nonetheless.

-----


You can use several binding declarations styles, including data-ng-*: https://github.com/angular/angular.js/blob/master/CHANGELOG....

-----


Thanks for the info!

Although, forgoing "data-" prepending by default in the interest of saving a few bytes doesn't seem like a good tradeoff. If you have any HTML5 validation as part of your testing process, not having valid attributes is going to throw a whole mess of errors that you'll have to ignore.

-----


Does HTML5 validation really matter when your goal is to build an MVC JavaScript app? I'm not trolling btw, many others in the community have long had validation pegged as a red herring [1] [2].

Validation of your attributes is fairly meaningless, and if you have a decent validator setup as part of your workflow (save-time or build-time - I personally wouldn't bother with either), then you should be able to customise it to turn off silly errors. You could also pre-process your JS files as part of your build step to replace ng-* with data-ng-* if it really meant that much to you. The byte-saving doesn't matter of course, but it seems like extra typing and more repetition in your templates for zero benefit.

[1] https://groups.google.com/forum/?fromgroups#!msg/html5boiler...

[2] http://www.nczonline.net/blog/2010/08/17/the-value-of-html-v...

-----


The problem is not whether a validator spits several errors or not, HTML validators are tools designed to point out stuff that is not conforming to the specs. It's stuff that you should avoid, not that will necessarily break your application on any web browser.

Why should you avoid it? Because, basically, if it's explicitly forbidden, or not covered by spec, you can't be sure of what will happen in all (or newer) browser implementations. If there's no defined behavior for some code, any behavior is correct.

Also, it's not like you have to go an extra mile in order to follow the specs here.

-----


You can use data-* prefix for all the directives.

Btw, here's my point: The reason, why you want valid html, is to be able to use some html validator, which is super helpful, when finding bugs like unclosed div etc. However, if you prefix all the custom attributes with data-* you only get these attributes ignored, not validated. For example if you type data-ng-rrepeat="", the validator won't catch it.

So I would rather extend html validator to accept new tags/attributes in some format, say JSON, so that during the build process of your app, you can get all the directives your app defines and validate them. Then you get even your custom directives validated. I believe that's the way to go.

-----


Small bug: the fixed-position "See Plans & Pricing" link that shows up at the bottom of the page when you scroll is partially hidden by the fixed-position "Talk to Us" link when the browser window is narrower than 1245px or so.

-----


That'd be my fault :(

Fix is forthcoming - thanks for reporting

-----


good catch

-----


Hopefully a Wordpress plugin is in the pipeline. This would be a no-brainer any Wordpress site if setup is as simple as installing and configuring a plugin.

-----


There is! It is functional already, just a little more testing before we release it.

-----


How about testimonials? The designs are fantastic, but I want to hear the story of someone catching a recruiter's eye from one of these.

Figure out away to demonstrate social proof that your resumes are giving job-seekers the edge they desperately need.

-----


We're working on that. We've just been live for a little over a month and are still doing it as a side project. But, that's something we have planned.

-----


Nope. Screen readers have been able to handle javascript-generated content for years. According to WebAIM's most recent screen-reader survey, 98.4% of screen reader users have javascript enabled: http://webaim.org/projects/screenreadersurvey3/#javascript

-----


Crawlers, less so. The major search engines are getting smarter about it, but for now, you still need some kind of HTML output from the server if you really want to be indexed properly.

It doesn't rule out a pure client-side app at all, but you do have some extra work involved to output HTML from the server. Which is why NodeJS will ride on the coat-tails of this approach; less redundancy.

-----


Hah! "The major search engines" - you mean Google, right? ;)

-----


How effective is Javascript with screen readers, though? It's been a while since I played with a screen reader (late 2009 or so), but when I did even really simple things like a pop-up div confused it. It didn't inform the user that something new was being rendered or anything.

-----


Surprisingly effective. A colleague of mine published some techniques to add consistency to Javascript events across screen readers: https://github.com/ryanfitzer/Accessibility

-----


Love this!

A few notes:

- When I click on an item thumbnail on your sample list page, it takes me directly to the image hosted on S3. Having the image appear in a lightbox would ensure that users are kept on the page.

- The title tag for every page reads "List of Things for Sale". I would populate the title tag with the name of the user (e.g. "Matthias McGregor's List of Things for Sale")

- Add FB/Twitter/Email to Friend links, which would provide three one-click marketing channels for users to share their for-sale items with their immediate network.

- Populate the page with Facebook Open Graph metadata. That way if users want to post a link to their store on Facebook, they'll get a nice link description and thumbnail automatically.

- I like the single-page experience, but I can't help wondering if it would be better if the app would generate discrete pages for each item users are selling. This might make it easier for users to share each item discretely, instead of just point people towards a single store page.

Really nice work!

-----


Thanks for all the nice comments!

- We've debated the pros and cons of lightboxes for a while now. We don't like them and prefer to see the image without chrome, but our users may feel differently. We'll soon see!

- Excellent point. I'm really looking forward to making loads of little tweaks like this.

- Yep, totally agree - it's coming.

- Thanks for the tip. It will be done!

- Item pages are on our list of things to do, although it's another tension between minimalism and e-commerce.

-----

More

Applications are open for YC Summer 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: