Hacker Newsnew | comments | show | ask | jobs | submit | mathias's comments login

More details on the Unicode regex problems in JavaScript (slide 62) and how ES6 will solve most of these issues: https://mathiasbynens.be/notes/es6-unicode-regex

-----


Luckily shaaaaaaaaaaaaa.com itself is fine: https://shaaaaaaaaaaaaa.com/check/shaaaaaaaaaaaaa.com

-----


I spotted this earlier this week when ordering a t-shirt through TeeSpring using PayPal. I authorized a payment of 22.95 USD. Here’s a screenshot from the payment confirmation email I received: http://i.imgur.com/BGjKcsW.png The math doesn’t quite add up.

-----


Please use http://meiert.com/en/indices/html-elements/ instead, as it’s based on the WHATWG HTML Living Standard rather than W3C’s versioned fork.

-----


Two things about that:

1. What are the differences? I've no idea what the significance of the source is.

2. The one you linked is hella unreadable. OP's table is, due to the color differences, extremely easy to skim, while the one you linked has only very similar black&white x and checkmark symbols, which require closer inspection to differentiate.

-----


The "main" development site for HTML5 is the WHATWG. That's where all the browser implementors convened when they lost faith in the W3C.

The WHATWG doesn't bother with versions, there will be no HTML6, for example. They just continually update the HTML5 spec. It's a living spec.

The W3C kind of tracks the WHATWG progress and tags certain points with version numbers (that's where the "5.1" comes from).

Although they do some development on their own, and sometimes both sides disagree and the specs diverge. At some point WHATWG removed an element that W3C retained or the other way around.

I have no idea if they still diverge. I just discard the W3C when it comes to HTML5 and follow WHATWG.

Well, practically speaking, I follow what the Mozilla Development Network documents. :-)

-----


> Well, practically speaking, I follow what the Mozilla Development Network documents. :-)

Yeah, I don't quite know when such a table is very useful anyway. What I check is: (A) http://www.whatwg.org/specs/web-apps/current-work/multipage/... (B) http://caniuse.com/

-----


I love http://caniuse.com but I wish they had more detail. For instance, on the XHR page, I'd like to know which browsers support addEventHandler syntax and which ones require the use of onreadystatechange.

-----


> That's where all the browser implementors convened when they lost faith in the W3C.

With the notable exception of Microsoft.

-----


I actually found it interesting to see what was in HTML5.1 and not in HTML5, even though I agree the 5.1 version number is quite silly.

-----


Note, the reason why there some features in 5.1 that are not in 5.0 is that there are some features not implemented yet, 5.0 only includes implemented features.

-----


The page you linked to doesn't look very trustworthy because it displays third-party ads. (Just an observation.)

-----


Is anyone out there actually using XHTML 2.0 currently?

-----


The point of typing a message in a webmail UI and sending it is to deliver the exact message you entered to the recipient. Adding hard line breaks, effectively altering the original message, is not useful.

Making text fit on a 80-character fixed-width screen is not something the email sender should do; the recipient’s email client should do it based on their preferences.

-----


You do realize that RFC 3986 doesn’t actually match reality, right? http://url.spec.whatwg.org/#goals

-----


My exact use case was the following: the user clicks a bookmarklet that passes the current URL in the browser as a query string parameter to a URL shortener script. The validation is then performed before the URL is shortened.

In that scenario, and with the given requirements, I can’t think of a case where the validation fails. There’s no need to worry about protocol-relative URLs, etc.

(Keep in mind that this page is 4 years old — I very well may have missed something.)

> If you really want your URL shortener to reject bad URLs, then you need to actually test fetching each URL (and even then...)

I disagree. http://example.com/ might experience downtime at some point in time, but that doesn’t mean it’s suddenly an invalid URL.

> As an aside, I'd instantly fail any library that validates against a list of known TLDs. That was a bad idea when people were doing it a decade ago. It's completely impractical now.

Agreed.

-----


I still don't quite follow the purpose of the validation. Is it against malicious use? In normal use, I would think that pretty much any URL that's good enough for the browser sending it would be good enough for the link shortener.

-----


But then you might end up shortening things like `about:blank` by accident.

-----


Yes, to reject non-URLs and also some URLs that are technically valid but that I want to explicitly disallow anyway.

-----


That was not an option in this case, as the goal is to validate URLs entered as user input and blacklist certain URL constructs even though they’re technically valid.

-----


So check if uri.host matches your blacklist.

-----


> Deviating from the formal spec because everyone practically agrees how to do things, albeit differently than in the formal spec, is something quite different from making shit up, and actually tends to be even harder than building things to spec, as there tends to be no easy reference to look things up in, but instead you might have to look into the guts of existing implementations and talk to people who have built them to figure out what to do - and you would normally start with an implementation according to spec anyhow, and only add special cases for non-normative conventions lateron.

This is exactly what Anne van Kesteren has been doing with the URL Standard: http://url.spec.whatwg.org/

-----

More

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

Search: