Hi Tobie

On 26/05/14 00:51, Tobie Langel wrote:
> On May 25, 2014, at 13:48, Michael Heuberger
> <michael.heuber...@binarykitchen.com> wrote:
>>>> * It is a redundancy. The browser already knows the status code, just
>>>> not JavaScript.
>>> That argument can equally well be used the other way round: it's a
>>> redundancy to expose in JS something that be easily exposed by the
>>> server.
>> I understand your perspective but you cannot compare two entirely
>> different things. Don't forget that most modern web apps are 99% driven
>> by JavaScript.
> That's data's made and far from the truth. :-)

Okay, I do not know the exact percentage but it is definitely a very
high number. All I wanted is to emphasize how important JavaScript is
these days. Getting more and more popular.

>> If the server returns a 404, JavaScript is still unable
>> to read the initial HTTP status code. Think about it :)
> How so? What prevents the server from adding a 404 status code in HTML markup?

I already explained this in a previous email. Should I repeat it here?
In short: it's a redundancy when the same information is already sent in
the HTTP header.

>>>> * Adding inline JS <script> slows down the page load.
>>> In that case, use a meta tag:
>>> <meta name=http-status content=404>
>>> Then in JS:
>>> var status = 
>>> parseInt(document.querySelector("meta[name=http-status]").getAttribute("content"));
>>> Should this pattern become pervasive, it might bathe sense to
>>> standardize it and expose it in JS. Frankly, though, it's the first
>>> time I hear of such a request.
>> That would work but is an overhead, a redundancy. Why add another meta
>> tag if the status code is already in the HTTP header??
> This would be an overhead for *your* application. But adding code
> that's very much specific to your use case to the whole platform
> creates overhead for browser vendors which have to implement and
> maintain that code.

Overhead? I am not so sure about that. I saw Firefox's source code and
for almost everything they have automated tests. When covered it
shouldn't be a big deal.

That's something the browser vendor should comment, maybe not the
WHATWG? Or are employers of browser vendors here in this discussion?

>> Yes, it's interesting why nobody has suggested this before. There is
>> always a first time. Probably I am the first to ask for this feature
>> because I've been working heavily with SPA's and node.js in the recent
>> years.
> Possibly. Should that usage become common, I'm sure your request will
> be reconsidered.

How can I be involved and help with the discussion? Where is the
official WHATWG group? Do they meet regularly?

>> Really, it would be awesome if JavaScript could read the HTTP status code!
> I agree. But there are plenty of other things which would also be
> awesome were they added to the platform and would enable use cases
> which cannot be hacked around server side, or would enable more common
> use cases.
> Hope this helps explain why there are little chances of this being
> implemented in the near future.

I totally respect that and can imagine that you have a very long queue
of feature requests.

But is there some kind of transparency? A platform where I can see all
the ideas, the requests and the process? Something like an issue tracker?



Binary Kitchen
Michael Heuberger
4c Dunbar Road
Mt Eden
Auckland 1024
(New Zealand)

Mobile (text only) ...  +64 21 261 89 81
Email ................  mich...@binarykitchen.com
Website ..............  http://www.binarykitchen.com

Reply via email to