But it seemed like the trend was to move away from dedicated SSL-ports to SSL/TLS extensions making encryption (and authentication) part of the protocol, which means you have encrypted and unencrypted communication over the same port and you always start with a unencrypted hand-shake. In client software this is often called TLS, SSL upgrade or STARTTLS…
But while these extensions are defined and somewhat widely implemented for protocols like IMAP, POP and SMTP, this is not the case for HTTP. There exists a specification called RFC 2818 but it is hardly implemented in client software, let alone any major browser.
That's quite saddening IMHO, for example if you hear of corporate or proxies on the internet blocking (or simply not explicitly allowing) these SSL ports and that this basically means no encryption in the WWW (please don't come up with JS-solutions like you might find on some sites like ones found at http://www.meebo.com/, being not MITM-resistant makes them basically useless).
BTW:
It's interesting how many sites which don't offer HTTPS still offer normal HTTP traffic over port 443.
And then there are sites offering HTTPS over a dedicated domain like https://ssl.example.org/ or https://secure.informaction.com/ so I believe there must be sites out there that offer HTTPS traffic on port 80 like: https://ssl.example.org:80/
