Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Documenting the Web together

blogs.windows.com

Post reply on HN
Print view View original

151–160 of 212 posts

Re: Documenting the Web together

#151

Post by nazri1 »

vbezhenar wrote: post #127
edent wrote: post #77

We were speaking about this at the W3C's Advisory Board meeting in London earlier this week. It distresses me that the specs on w3.org are so hard to read for the average developer. It's great to see how MDN focuses on simplicity, readability, and usable examples.

Specs are not meant to be read by average developer. Average developer should read books. Specs are meant to clarify moot points between different implementations. Spec is like legal document, they are hard to read, but they serve their purpose.

The thing is it shouldn't be that way in the first place isn't it? Take the golang spec, for example.

Re: Documenting the Web together

#152

Post by acdha »

vbezhenar wrote: post #127
edent wrote: post #77

We were speaking about this at the W3C's Advisory Board meeting in London earlier this week. It distresses me that the specs on w3.org are so hard to read for the average developer. It's great to see how MDN focuses on simplicity, readability, and usable examples.

Specs are not meant to be read by average developer. Average developer should read books. Specs are meant to clarify moot points between different implementations. Spec is like legal document, they are hard to read, but they serve their purpose.

I think that’s a very narrow view and it’s far from universally true. While a lot of W3C specs are impenetrable there are many counter examples at the IETF which might not be introductory level but are certainly easier for a developer familiar with the topic to follow.

I think this is actually fairly important for two reasons. The first is simply that unreadable specs are just as bug prone as unreadable code, but the second is that this increases the distance between the web as specced and the [much much much] larger developer community, and things like / show the benefit of having less of a communications chasm between those groups.

That doesn’t mean that specs can’t be precise but simply that good technical writing can accommodate a wide audience.

Re: Documenting the Web together

#154

Post by 482794793792894 »

ktta wrote: post #150
pritambaral wrote: post #146

Earlier quoted context omitted.

> where Netflix can be streamed Isn't that because of Netflix's choices, rather than technical reasons?

I'm not entirely sure. I believe it has to do with the DRM implementation. While Widewine is the DRM in Chrome and Firefox, Edge uses something different[1]. I've seen people talk about Chrome being able to handle 1080p in ChromeOS. So there seems to be more than just Netflix's choice involved here. Although I bet Microsoft being proactive helped. Definitely unclear. Also I don't see any reason why Netflix wouldn't w…

As far as I understand it, you need tight coupling between the browser and the OS to implement the sort of deep-reaching DRM that Netflix/Hollywood wants for 1080p. That would explain why Edge on Windows and Chrome on ChromeOS can do it.

Personally, I see it as a plus that my browser/OS combo does not support this. There have to be horrid security implications that just wait to be unturned.

Re: Documenting the Web together

#155

Post by r3bl »

1k2ka wrote: post #148
CoryG89 wrote: post #136

Earlier quoted context omitted.

While we're on MDN related awesomeness, shameless plug: Back when I was in school, I made this Chrome extension which allows you to jump directly from the address bar to the MDN page you want: https://chrome.google.com/webstore/detail/mdnjump/mfjekjhknp...

If you use DuckDuckGo as your standard search engine you can also prepend "!mdn" to your search query to search MDN. This also works with any website wich supports search I think. Other good ones include "!hoogle", "!hn", "!yt", "!g", and the list goes on.

FYI, if you're already shortening the so-called "bangs", you could use "!h" for Haskell. :)

Worth pointing out: submitting bang ideas is very, very trivial, but the whole process may last months. Last time I've read about someone complaining about a long bang, I've submitted "!gw" as a shorter version of searching Gentoo's Wiki and it became a thing a couple of days ago. This is maybe fifth or sixth bang that I've submitted to them via https://duckduckgo.com/newbang.

Re: Documenting the Web together

#157

Post by tim-- »

ktta wrote: post #145
shmerl wrote: post #76

> One of our guiding principles in developing Microsoft Edge is that end users should never have to worry about which sites work in which browsers. This philosophy—”the Web should just work for everyone“—led to our choice to target the “interoperable intersection” of web APIs in our browser engineering. That's a good move by MS. In this context it's great to see them supporting open codecs, and for istance OGG contai…

Also Edge is the only web browser where Netflix can be streamed at 1080p and 4K. OTOH Chrome and Firefox are only at 720p. Safari is at 1080p though. (Netflix's windows app is another route) Edge also supports Apple's Live streaming tech so, again the only browser on Windows which can be used to watch Apple's Live events. Too bad that Edge won't ever be on Linux.

Well, they ported their Javascript engine to *nix[2]. Also, it's not like Internet Explorer wasn't supported in Unix 'back in the day'[1]...

[1] https://en.wikipedia.org/wiki/Internet_Explorer_for_UNIX

[2] https://github.com/Microsoft/ChakraCore

Re: Documenting the Web together

#158

Post by r3bl »

btilly wrote: post #137

My favorite line was this: One of our guiding principles in developing Microsoft Edge is that end users should never have to worry about which sites work in which browsers. This philosophy—”the Web should just work for everyone“—led to our choice to target the “interoperable intersection” of web APIs in our browser engineering. It wasn't favorite because I agree with it. It was favorite for the humor value of Microso…

People change, and so do its companies (or at least, their management).

Looking from a non-Windows-user perspective, in the last couple of years: VSCode is now a thing, .NET is open sourced, they've started financially supporting organization that I like (like OSI and the Linux foundation), Powershell is now available on my platform, and, if I ever decide to switch back to Microsoft's technologies (highly unlikely), I have Windows Subsystem for Linux and I'll be able to run Linux servers on Azure.

As a non-Windows user, I'm totally happy with this new Microsoft.

Re: Documenting the Web together

#159

Post by shmerl »

ktta wrote: post #150
pritambaral wrote: post #146

Earlier quoted context omitted.

> where Netflix can be streamed Isn't that because of Netflix's choices, rather than technical reasons?

I'm not entirely sure. I believe it has to do with the DRM implementation. While Widewine is the DRM in Chrome and Firefox, Edge uses something different[1]. I've seen people talk about Chrome being able to handle 1080p in ChromeOS. So there seems to be more than just Netflix's choice involved here. Although I bet Microsoft being proactive helped. Definitely unclear. Also I don't see any reason why Netflix wouldn't w…

If it's because of DRM, it's the fault of Netflix. No one stops them releasing their video DRM-free.

It's not the first time DRM hampers performance and thus degrades usability. It's by definition an anti-feature.

Re: Documenting the Web together

#160

Post by matt4077 »

ghostly_s wrote: post #143
carussell wrote: post #123

Earlier quoted context omitted.

When this article first appeared, I wrote a long comment here (now deleted) about how the content Mozilla inherited from Netscape DevEdge originally straddled the split by fully embracing that there were two different mindsets the audience might be coming in with, and simply creating two different sets of docs. There were the JavaScript Guide and the JavaScript Reference, for example, and they were pretty thoroughly…

Python's official docs do a good job with this approach too, I think. The Python Language Reference is relatively easy to read for a lay-man when that's necessary, and includes the formal logic of the spec in little call-out boxes -- but it's also accompanied by the Python Tutorial, which manages to cover nearly everything while making no attempt to get into every edge-case and obscure method, keeping it focused and…

I think Python is the worst-documented large language I use.

For ```list``` it says:

Lists implement all of the common and mutable sequence operations. Lists also provide the following additional method:

...where "common" and "mutable" are links.

Meaning: the methods of lists are strewn across three different location, four if you count the constructors above this sentence.

Post reply on HN