02:15
<MikeSmith>
do any UAs support the as= attribute in e.g. <link rel=preload as=video href=...> ?
02:15
<MikeSmith>
and does anybody know the point of that attribute?
02:16
<MikeSmith>
it basically just seems to repeat the element name
02:16
<MikeSmith>
<link rel=preload as=script href=...>, <link rel=preload as=style href=...> etc
02:16
<MikeSmith>
http://w3c.github.io/preload/#attributes
02:17
<MikeSmith>
igrigorik_:
02:17
<MikeSmith>
igrigorik_: ⬆
02:18
<MikeSmith>
I am trying to decide whether to add support for as= to the HTML checker
02:19
<MikeSmith>
https://github.com/validator/validator/issues/276#issuecomment-216287257
07:31
<mkwst>
MikeSmith: Chrome supports that to some extent. yoav will have details.
07:35
<yoav>
MikeSmith: Yeah, Chrome supports it and the point is to start a Fetch for that resource with the proper destination so that it could be matched when later requested by an element uses that resource, fetched while taking the proper CSP directives into account, and with the right request headers (e.g. Accept)
07:36
<yoav>
`as` is the main difference between preload and its (not-very-useful) predecessor subresource
07:41
<zewt>
what happend to the whole "browsers try not to break pages" thing
07:43
<zewt>
(re: Object.observe suddenly going away in a chrome update and now android systrace is broken, and now I get to do the extra hazardous thing of updating Android tools near the end of a project and hoping everything doesn't explode)
07:48
<annevk>
zewt: they try, but not always succeed?
07:48
<annevk>
zewt: I think Object.observe() had a deprecation period of several releases
07:48
<annevk>
zewt: and it was never implemented by more than one browser, another sign it was rather unstable
07:49
<zewt>
all I care about at the moment is that a tool I was using regularly just stopped working, and as far as I can tell I'm just screwed
08:04
<annevk>
MikeSmith: spam at https://www.w3.org/Bugs/Public/show_bug.cgi?id=12845#c39
08:12
<zewt>
google sure is going to a lot of effort to make sure I can't do my job
08:18
<Cablegunmaster>
whats wrong zewt?
09:15
<Ms2ger>
annevk, yt?
09:48
<annevk>
Ms2ger: what's up?
09:48
<Ms2ger>
I was stupid enough to look into about:blank
09:50
<Ms2ger>
Do you think it would make sense to defined Document's "ready for post-load tasks" and "completely loaded" flag in DOM? Then we could set then explicitly for createDocument/createHTMLDocument/new Document()
09:51
<Ms2ger>
HTML seems to miss new Document() right now
09:58
<jochen__>
annevk: a) it's a W3C WG for better or worse
09:58
<Ms2ger>
w3c specs can reference whatwg specs
09:58
<jochen__>
annevk: and b) I think documenting all the places where the W3C html spec doesn't even satisfy the requirements of other W3C specs is a worthwhile execise
09:59
<jochen__>
it's problematic once you want to move beyond WD
09:59
<annevk>
Ms2ger: sounds reasonable
09:59
<jochen__>
see the SRI stuff currently going on
09:59
<jochen__>
https://lists.w3.org/Archives/Public/public-webappsec/2016May/0002.html
10:00
<Ms2ger>
Seems like it's not problematic?
10:00
<Ms2ger>
Anyway
10:02
<jochen__>
i'm not saying you're wrong
10:02
<jochen__>
i'm saying you're having the discussion with the wrong person
10:03
<jochen__>
you should totally bring this up on the mailing list
10:06
<Ms2ger>
I don't have time for that
10:07
<Ms2ger>
Also, the mailing list post you linked seemed to completely disprove your point
11:57
<smaug____>
whaat, browsers supporting focusin/out seem to dispatch them at really odd time
11:57
<smaug____>
totally against the spec
12:00
<annevk>
Is that the kind of specification where you have to read between the lines? Because last I checked they were not really defined... There's an open issue against HTML for them.
12:02
<smaug____>
it is defined
12:03
<smaug____>
but I'm seeing focusin dispatched after focus
12:03
<smaug____>
am I on crack here
12:04
<smaug____>
http://mozilla.pettay.fi/moztests/focusin_focusout.html is my testcase
12:05
<annevk>
Defined where?
12:05
<annevk>
That resource doesn't load for me by the way
12:06
<smaug____>
annevk: defined in UI events spec
12:06
<smaug____>
oh, what happened to pettay.fi
12:07
<annevk>
smaug____: that is rather hand wavy, e.g., it doesn't define the interaction with focus()/blur(), presumably not with autofocus="" either, or click(), etc.
12:08
<smaug____>
oh, sure, but at least it defines whether focusin should happen before focus etc
12:08
<annevk>
I guess that is something...
12:23
<annevk>
smaug____: any ideas for an alternative name for rootNode? Are you fine with the suggested alternatives? E.g., treeTop?
12:23
<smaug____>
treeTop would be ok
12:24
<smaug____>
not very great, but I don't think we can really find anything much better
12:28
jgraham
wonders what's wrong with rootNode
12:28
<jgraham>
(treeTop sounds very strange to me)
12:28
jgraham
isn't following wherever this discussion is happening
12:29
<smaug____>
jgraham: rootNode isn't compatible with the web
12:29
<smaug____>
it is being used by script libraries, apparently
12:30
<annevk>
jgraham: it's rather sad, https://github.com/whatwg/dom/issues/241
12:30
<Ms2ger>
Doh
12:34
<gsnedders>
when did the prescan move to being 1024? I remember it being 512, and that's what html5lib implements.
12:34
<jgraham>
FWIW I think the reason that treeTop doesn't match is because it's a screwy mental model were the top of the tree and the root of the tree are the same point
12:37
<annevk>
jgraham: interesting, why is that the wrong model?
12:37
<annevk>
jgraham: note that furthestAncestor doesn't work for the root itself
12:38
<jgraham>
annevk: Why doesn't it work for the root iself?
12:38
<annevk>
jgraham: you want root.rootNode === root
12:38
<jgraham>
annevk: I'm comfortable with the root being its own furtestAncestor
12:39
<annevk>
jgraham: hmm, the spec calls those inclusive ancestors
12:39
<jgraham>
More comfortable than I am with the top and the bottom of the tree being the same point
12:39
<jgraham>
annevk: Well no one reads the spec (apart from like a dozen implementors and language lawyers), so that doesn't seem like a very strong argument ;)
12:40
<annevk>
I suppose, but if ancestor is used elsewhere and means something different it'll be confusing
12:41
<jgraham>
Is it used elsewhere?
12:41
<jgraham>
(apart from XPath)
12:44
<annevk>
jgraham: I don't know
12:48
<jochen__>
anybody got an opinion about disallowing alert and friends in microtasks?
12:48
<mkwst>
jochen__: How about disallowing them in macrotasks too?
12:48
<jochen__>
the reasoning is that while an alert is displayed, if you e.g. resize the browser windows, all browser dispatch events at the web page
12:48
<jochen__>
which kinda violates the idea of microtasks being ran outside of the main message loop
12:48
<jochen__>
mkwst: working on that :)
12:49
<annevk>
jochen__: what kind of events?
12:49
<annevk>
jochen__: oh, I see what you mean
12:50
<jochen__>
resize for example
12:50
<jochen__>
or whatever happens to come in on the message loop
12:51
<jochen__>
i'm toying with the idea of blanked disallowing those apis: https://codereview.chromium.org/1940253002
12:54
jgraham
can't imagine much opposition to that
12:54
<jgraham>
Well unless it's already a compat issue
12:54
<Ms2ger>
Of course it is
12:55
<jgraham>
Ms2ger: In microtasks?
12:55
<jgraham>
I mean removing alert entirely is a huge compat issue ofc
12:55
Ms2ger
points at the topic
13:08
<gsnedders>
To answer my own question: https://github.com/whatwg/html/commit/51babfe760a1dbe28c4521b2070e692ac872550a
13:17
<MikeSmith>
annevk: thanks, banned that bugzilla spammer
13:18
<MikeSmith>
yoav, mkwst thanks I guess I’ll go ahead and add as= support to the HTML checker
13:19
<mkwst>
MikeSmith: Sorry. I told yoav to stop being awesome and implementing new things, but he never listens to me. :(
13:20
<MikeSmith>
hahah
13:20
<MikeSmith>
you two are keeping the W3C in business
13:21
<mkwst>
I'm not sure that's a good thing?
13:50
<MikeSmith>
mkwst: I’ll leave that up to you to decide for yourself :)
13:51
<MikeSmith>
mkwst: by the way, have y’all moved to autopublishing for your specs yet?
13:51
<MikeSmith>
CSP, tc.
15:05
<yoav>
annevk: Hey! Is there a particular reason that "Accept-Encoding" is in the forbidden headers list in Fetch?
15:06
<yoav>
Are there security risks involved with SW changing it to add support to new codecs, etc?
15:07
<annevk>
yoav: I think one of the problems is that the browser handles that entire layer in principle
15:08
<yoav>
Oh, so content encoding gets decoded before the bytes get to SW?
15:08
<annevk>
yoav: we don't expose the content before content codings have been handled, and there's a number of schemes for which that would not even make sense, as I understand it
15:08
<annevk>
yoav: yes
15:08
<yoav>
got it! Thanks! :)
15:08
<annevk>
yoav: see "handle content codings"
15:09
<annevk>
invoked as "handling content codings" (though you can also click the definition to find where it's invoked)
15:49
<SimonSapin>
https://w3c.github.io/unicode-xml/#Bidi recommends browsers ignore Bidi Embedding control characters (since users are supposed to use markup instead), but they apparently don’t: data:text/html,&%23x202e;Test renders as tseT in both Firefox and Chromium
15:50
<SimonSapin>
so there’s probably content out there that rely on these code points
15:57
<MikeSmith>
zcorpan: (and others) Do we seriously really want to have the HTML checker emit a warning for every single document that’s missing a lang attribute on the HTML element?
15:57
<MikeSmith>
because once I add that is it going to instantly become the #1 most common error
15:58
<MikeSmith>
and I think some authors/developers are going to see it as noise
15:59
<MikeSmith>
on the other hand, if we think it is that important that every single document on the Web really should have a lang attribute on the html element, then I guess this would be a good way to help make that happen
15:59
<MikeSmith>
so maybe my question is, just how important is this to us?
16:00
<MikeSmith>
or how important is it for the Web
16:00
<MikeSmith>
what real problems does it solve for users in practice
16:00
<MikeSmith>
context is https://github.com/validator/validator/issues/284
16:00
<zcorpan>
MikeSmith: it affects users of AT primarily, when reading content that is in a different language than their system language
16:00
<MikeSmith>
and https://www.w3.org/Bugs/Public/show_bug.cgi?id=26942#c13
16:01
<MikeSmith>
zcorpan: OK
16:01
<zcorpan>
MikeSmith: i suppose that may be a smaller set of people than the people who will be annoyed about validator errors, i dunno
16:01
MikeSmith
reads recent comments at https://www.w3.org/Bugs/Public/show_bug.cgi?id=26942
16:01
<MikeSmith>
I hope this is just not another table@summary
16:03
<zcorpan>
i think what would be best for users is probably for ATs to do language analysis themselves, but that's not the situation today
16:04
<MikeSmith>
yeah, doing language analysis over an entire doc when you load it is a pretty big deal
16:05
<MikeSmith>
or even trying to programatically determine some subset to analyze
16:05
<zcorpan>
don't need to run it over the whole document, just a few words is typically enough to get a confident answer
16:05
<zcorpan>
iirc
16:06
<MikeSmith>
yeah but which words do you choose?
16:06
<zcorpan>
the words you're about to read next? :-)
16:07
<zcorpan>
imho this should also work if the user types into a textarea
16:07
<zcorpan>
MS Word deals with it
16:08
<zcorpan>
for spell checking, i mean
16:09
<zcorpan>
OS X has language detection for spell checking in general also
16:12
<jyasskin>
Chrome already detects languages to see if it should show the Translate prompt, and it has an extension API to do it (https://developer.chrome.com/extensions/tabs#method-detectLanguage). I wonder if we should synthesize lang attributes, or an equivalent aria attribute...
16:13
<MikeSmith>
zcorpan: it is a lot easier to do in that case than in the case of trying to analyze text nodes in document order in real time as I parse a document
16:13
<MikeSmith>
do I just check the first text node? or the first 10 text nodes? or what
16:23
<MikeSmith>
I feel like this should be a separate tool
16:23
<jgraham>
It totally seems like the AT should try to do the linguistic analysis here
16:23
<MikeSmith>
that users could opt into
16:24
<MikeSmith>
jgraham: yeah well as we know the vendor of the most widely used AT is not going to add it
16:25
<MikeSmith>
I now am wondering if Richard Ishida has not already implemented a tool for doing this
16:25
<jgraham>
Would be nice if eventually the most widely used AT wasn't any more due to others implementing better features
16:35
<MikeSmith>
NVDA devs are trying
16:57
<MikeSmith>
jyasskin: do you have any idea how much of the text of a document Chrome checks before showing the Translate prompt?
16:57
<MikeSmith>
or what it checks?
16:58
<MikeSmith>
I am wondering if there is some existing literature on how best to do this for HTML documents
17:00
<jyasskin>
MikeSmith: I haven't worked on the system, but it is open source. ;)
17:00
<MikeSmith>
OK
17:01
<MikeSmith>
will look at the sources
17:05
<gsnedders>
language detection of single-language strings is pretty much solved by now, and it's certainly practical to run over the entire doc, cost isn't that high
17:07
<gsnedders>
the problem is you can't guarantee a single HTML page is a single language
17:09
<Mek>
https://sites.google.com/a/chromium.org/dev/developers/design-documents/translate doesn't seem to have been updated since it's initial version, so no idea if that still bears any resemblance to the implementation
17:10
<MikeSmith>
gsnedders: it is not practical for me if I am not building a DOM or any other in-memory representation
17:12
<MikeSmith>
the checker only does anything with text nodes at all just for particular elements that the spec puts requirements on the text content of
17:13
<MikeSmith>
and the checker is currently extremely fast and it is hard to see how doing this is any form is not going to add a measurable performance cost
17:14
<MikeSmith>
Mek: thanks will look at it anyway
17:14
<MikeSmith>
hmm, “The renderer already extracts the text from each loaded page for indexing purpose”
17:16
<gsnedders>
MikeSmith: there's some silly fast and accurate langid tools out there, but maybe not practical
17:49
<Domenic>
yoav: up for reviewing https://github.com/whatwg/html/pull/1141? :)
17:59
<yoav>
Domenic: will review later tonight. Seems like the email fell through my mail filters... :/
18:01
<Domenic>
\o/
19:06
<Domenic>
I wonder why IDL has so many special cases for RegExp objects
19:18
<caitp>
you mean like `If V is a native RegExp object, then throw a TypeError.`
19:18
<caitp>
?
19:19
<SimonSapin>
TabAtkins: which SVG spec should I look at for a new implementation?
19:20
<SimonSapin>
or, is the SVG 2 draft mostly additive or does it rewrite the basic stuff?
19:23
<gsnedders>
SimonSapin: it drops some of the stuff nobody really supports and makes optional stuff that people want to get rid of, mostly
19:23
<gsnedders>
SimonSapin: I /think/ it's probably the best reference
19:24
<SimonSapin>
(I’m thinking of making a toy implementation to play/experiment with some stuff. Nothing that’s gonna ship :))
19:42
<jyasskin>
MikeSmith: I'd read your initial discussion as wanting to decide whether your checker should check for a lang= attribute, and was arguing for not-checking because browsers can fairly straightforwardly infer the language without that attribute. Later it looks like you're trying to make the checker infer the lang= attribute, which my and Mek's comments don't
19:42
<jyasskin>
help as much with.
19:57
<gsnedders>
annevk: URL spec doesn't allow fatal handling of errors? :(
19:58
<Domenic>
caitp: yeah, it's everywhere. Any object is allowed to be treated as an implementation of a callback interface.... except RegExps.
20:07
<caitp>
webidl seems to distinguish between "a native RegExp" and a RegExp type
20:07
<caitp>
for some reason
20:07
<caitp>
I dunno, interesting
20:36
<Domenic>
I think one is the Web IDL type corresponding to the JS type
20:36
<Domenic>
Just like there is a Web IDL boolean type with two possible values, true and false
20:37
<Domenic>
Guess how you convert a Web IDL boolean to a JavaScript value
20:37
<Domenic>
Guess
20:37
<Domenic>
I bet you can't guess
20:37
<Domenic>
(sorry, I am being weird)
20:49
<caitp>
is it not the ToBoolean internal op because webidl thinks it has to be able to support non-JS languages too?
20:52
<Domenic>
it is: if the value is the IDL boolean value true, return the JavaScript value true. If the value is the IDL boolean value false, return the JavaScript value false.
20:52
<Domenic>
ToBoolean is for the other direction, JS values -> IDL boolean values.
20:53
<caitp>
ah
20:53
<Domenic>
Basically, the separate type system seems pretty silly sometimes. But I am not sure I have a principled alternative.
20:54
<Domenic>
Something about it all being JavaScript values and just doing conversions between them (like ToBoolean) when necessary
21:03
<rniwa>
annevk: yt?
21:34
<jyasskin>
Do we have any patterns yet for events that you might want to register for from the foreground but receive in a designated Worker? I see http://w3c.github.io/push-api/#the-push-event, which is done with a dedicated manager on ServiceWorkerRegistration, but that doesn't give the page much flexibility.
22:29
<Domenic>
jyasskin: I don't think we have any patterns that have received wide review and approval. The service worker specs and maybe some houdini specs are probably leading the way here. A survey of what all they're doing would be nice.
23:09
<gsnedders>
uhhhh
23:09
<gsnedders>
so it turns out that reparsing to change the encoding never actually worked in html5lib
23:09
<gsnedders>
o_O