[whatwg] Feedback wanted on integrating fetch request/response and streams
In https://github.com/yutakahirano/fetch-with-streams Yutaka, Anne, and I are
working on how to integrate the fetch API with streams. The general pattern we
want is that for both request and response objects their creator is given a
writable stream to write body content to, using [the revealing constructor
pattern][1]. (That way, for requests or responses created by the browser,
developers can only read---not write---the bodies; for requests/responses
created by the developer, the developer can do both.)
The current fetch API when initializing with non-streaming bodies is roughly:
```js
var req = new Request(http://example.com;, {
method: POST,
body: '{ json: here }' // or blob or FormData or ...
});
var res = new Response('{ json: here }' /* or blob or FormData or ... */, {
status: 201,
headers: { 'Content-Type': 'application/json' }
});
```
Note how in both cases the most important value is given an unlabeled
position as the first argument: requests are about URLs, and responses are
about bodies.
Our current thought for streams integration is to overload the body position
for each of these with a function that takes a writable stream:
```js
var req = new Request(http://example.com;, {
method: POST,
body(stream) {
stream.write(myArrayBuffer);
stream.close();
}
});
var res = new Response(
stream = {
someCSVStream.pipeThrough(new CSVToJsonTransform()).pipeTo(stream);
},
{
status: 201,
headers: { 'Content-Type': 'application/json' }
}
);
```
Do we think this is good? Any other ideas?
Personally I find the overloads weird, especially since they behave completely
differently when passing a string versus passing a function. But after thinking
through this for a while I didn't have any better ideas that worked for both
requests and responses.
[1]: https://blog.domenic.me/the-revealing-constructor-pattern/
[whatwg] script content restrictions vis-a-vis HTML template data blocks
Re: the Restrictions for contents of script elements (4.12.1.2): Consider script elements containing data blocks. It's useful to embed templates in these; HTML templates for example. When embedding HTML templates, it would be onerous to have to either omit comments or implement an escaping / unescaping regimen. The specification suggests 'to always escape !-- as \!--', which isn't too bad for JavaScript, but would be a hassle for HTML templates. The following examples illustrate my interpretation of the requirements for script content. Is this correct? Non-conforming (does not match the outer production before comment-open / after comment-close / or both): script type=text/plain!-- a --/script script type=text/plain !-- a --/script script type=text/plain!-- a -- /script Conforming (newline characters satisfy the outer production in both positions): script type=text/plain !-- a -- /script Conforming (space characters satisfy the outer production in both positions): script type=text/plain !-- a -- /script
[whatwg] [hidden] attribute should not allow overrides via css
Those two lines from spec [1] are in conflict:
Because this attribute is typically implemented using CSS, it's also
possible to override it using CSS
if something is marked hidden, it is hidden from all presentations
The latter is not true as currently implemented.
The former allows a css enabled styled presentation to display a hidden
element,
while browsing with *styles disabled* with have the element hidden (not
displayed)
due to the default browser stylesheet making it so.
Technically it is therefore *not* hidden form all presentations and
breaks the hidden = aria-hidden accessibility assumptions. I find this
conflicting.
And allowing a css override, breaks my use case:
Say, I have a link: a class=email hiddenEmail/a . And I only want this
link to
render dynamically and conditionally as a mailto: href with a
'display:block' style.
I am unable to pre-style my links with a 'display:block', because it cancels
'hidden',
which makes 'hidden' useless to me here if it wasn't for a *[hidden] {
display: none; }
at the end of my stylesheet.
I strongly suggest that hidden be made a 'display: none !important' instead
to remedy this confusion.
[1] https://html.spec.whatwg.org/#the-hidden-attribute
Re: [whatwg] [hidden] attribute should not allow overrides via css
On Wed, Nov 5, 2014 at 5:07 PM, Bruno Racineux br...@hexanet.net wrote:
Those two lines from spec [1] are in conflict:
Because this attribute is typically implemented using CSS, it's also
possible to override it using CSS
if something is marked hidden, it is hidden from all presentations
The latter is not true as currently implemented.
The former allows a css enabled styled presentation to display a hidden
element,
while browsing with *styles disabled* with have the element hidden (not
displayed)
due to the default browser stylesheet making it so.
Technically it is therefore *not* hidden form all presentations and
breaks the hidden = aria-hidden accessibility assumptions. I find this
conflicting.
And allowing a css override, breaks my use case:
Say, I have a link: a class=email hiddenEmail/a . And I only want this
link to
render dynamically and conditionally as a mailto: href with a
'display:block' style.
I am unable to pre-style my links with a 'display:block', because it cancels
'hidden',
which makes 'hidden' useless to me here if it wasn't for a *[hidden] {
display: none; }
at the end of my stylesheet.
I strongly suggest that hidden be made a 'display: none !important' instead
to remedy this confusion.
[1] https://html.spec.whatwg.org/#the-hidden-attribute
This is intentionally *not* done, so that authors can hide it using
whichever technique they wish; in particular, authors need to be able
to do a transition of styles when setting/removing 'hidden', like
fading it to/from opacity:0. Forcing it to display:none would prevent
these kinds of animations.
~TJ
