06:31
<annevk>
https://twitter.com/cwilso/status/742864947986587648 So because Chris Wilson was not personally acknowledged (did he ever contribute?) he doesn't care that others are no longer acknowledged either? What a weird thing to say...
07:32
<zcorpan>
https://github.com/whatwg/html/pull/907#issuecomment-226106645 ;_; ;_; ;_; ;_;
07:33
<zcorpan>
apple people, please get this fixed
07:36
<zcorpan>
othermaciej hober ^
07:38
<othermaciej>
I love that the sample page URL he gives is scrolled to HKBodyTemperatureSensorLocationRectum
07:39
<ondras>
:D
07:41
<othermaciej>
I guess this bug is a pain in the ass?
07:43
<othermaciej>
zcorpan: probably better for hober to field it but it would help to know what the issue is more specifically. I see that you requested not to use the menuitem tag but from the issue log I don't think I'd be able to explain to the docs people why it's wrong that they are doing so
07:43
<zcorpan>
it's a pain in the ass for chromium trying to ship <menuitem> with spec-conforming parser. it's really really trivial fix on your side (change "<menuitem" to "<menu-item" in the markup and any css etc)
07:44
<othermaciej>
zcorpan: has the parser always had a requirement that would make this page get mis-parsed, or is it a recent change?
07:45
<othermaciej>
zcorpan: is this the only page on Apple's docs site that has the issue?
07:45
<zcorpan>
othermaciej: they are really using a custom tag, no the spec's menuitem, so it should be a custom tag or a <div> instead
07:45
<zcorpan>
othermaciej: it has always been void, which breaks the page. it was recently changed to be "like option" but it still breaks the page
07:45
<zcorpan>
othermaciej: firefox parses it like unknown elements are parsed, which does not break the page
07:46
<othermaciej>
zcorpan: hmm, I thought we'd had a 100% conforming implementation of the HTML parsing algorithm in WebKit
07:46
<othermaciej>
at one point
07:47
<othermaciej>
maybe <menuitem> got added after that? Which I guess shows the foolishness of adding new void elements.
07:47
<othermaciej>
anyway I think hober is more likely to be able to pass this along effectively, hopefully he will see this in his scrollback
07:48
<zcorpan>
othermaciej: yeah menuitem was probably a new void when hixie tried to make the spec somewhat closer to gecko (who invented menuitem iirc)
07:49
<zcorpan>
othermaciej: ok thanks
07:50
<othermaciej>
since Firefox doesn't actually parse it that way, that seems like an obsolete reason
07:51
<othermaciej>
Maybe the spec should change, since it is hard to use new void elements in content and still have it degrade gracefully. And there may be more content using it wrong. Should not be too hard to get Apple's docs fixed. It would help to know if it affects other pages though.
07:52
<zcorpan>
right, the spec was changed to no longer be void. we've researched this and couldn't find any other page being broken, and there haven't been any other reports about other pages being broken
07:53
<zcorpan>
the problem with the current spec is that <menuitem>x<menu> parses like <menuitem>x</menuitem><menu>
07:54
<othermaciej>
So I guess you can always use end tags to support browsers that don't match the latest spec, but if you actually try to use the allowance for tag omission you will get unexpected parsing in older browsers
07:54
<zcorpan>
right
07:54
<othermaciej>
that seems gratuitous for a convenience feature of end tag omission
07:58
<zcorpan>
maybe so. but you don't see people doing <video><source></source> because it parses differently in old browsers. so in 5-10 years maybe people will happily use <menuitem> without the end tag, if that is supported?
07:59
<zcorpan>
anyway, it is possible to change the spec to match firefox, i'm just sad that it's only apple docs that is blocking
08:32
<MikeSmith>
fwiw gecko did not invent menuitem
08:32
<MikeSmith>
Hixie did
08:33
<MikeSmith>
then gecko unilaterally implemented a variation of menuitem that did not conform to what Hixie has specced
08:37
<annevk>
Tweeting about a new t-shirt is my career highlight
09:00
<MikeSmith>
I wish roc has revealed his secrets while he was still working on gecko http://robert.ocallahan.org/2016/06/nastiness-works.html
09:00
<MikeSmith>
as far as tactics for pressuring him to prioritize bugs
09:54
<Ms2ger>
OH: "are you writing XSLT to create the bikeshed?"
14:03
<Manishearth>
annevk: we're having a meeting near the registration desk @ the beanbags about navigation; coming? :)
14:04
<jgraham>
Manishearth: annevk is busy I believe
14:05
<Manishearth>
ah
14:44
<gsnedders>
https://webkit.org/blog/6589/next-steps-for-legacy-plug-ins/ is interesting insofar as navigator.plugins and hiding what's installed and the privacy consequences of it
14:49
<annevk>
Manishearth: sorry :-/
15:02
<Manishearth>
annevk: np
15:40
<zcorpan>
MikeSmith: i thought Hixie_ invented <command> but gecko implemented <menuitem> instead
15:41
<MikeSmith>
yeah Hixie_ made command too but pretty sure he has also specced out an explicit <menuitem> as well
15:42
<MikeSmith>
but I could be wrong
15:42
<MikeSmith>
and you are likely to remember it better than me anyway
15:42
<zcorpan>
https://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0264.html
15:42
<MikeSmith>
given that you were editing the doc that tracked the diffs
15:43
<MikeSmith>
there you go :)
15:43
MikeSmith
eats crow
15:44
<zcorpan>
:-)
15:44
<zcorpan>
ask me what i had for dinner two days ago, wouldn't have a clue
15:44
<MikeSmith>
haha
15:45
<zcorpan>
AMA about html's history, off the top of my head
15:45
<zcorpan>
weird brain
15:45
<MikeSmith>
you have some special storage there
15:45
<MikeSmith>
optimized for HTML
15:56
<caitp>
that's sad, how are you going to remember that delicious tender bloody prime rib, and that $500 wine you got for christmas?
15:56
<caitp>
priorities man
16:26
<annevk>
Manishearth: in badge area now…
16:28
<Manishearth>
annevk: might want to talk with ajeffrey if he's still in the hotel
16:28
<Manishearth>
I'm not :)
16:29
<zcorpan>
caitp: i know right
18:49
<Domenic>
I like the framing on that WebKit blog post: "guest post from the Safari team". Seems kind of cool to emphasize that separation.
18:50
<Domenic>
I'm hoping one day we can just spec navigator.plugins and navigator.mimeTypes to return an empty array or something
18:51
<Domenic>
And get rid of all the specialized types
18:52
<Domenic>
Well, maybe we won't be able to get rid of PluginArray and MimeTypeArray, as they have too many non-array methods :(
18:52
<Domenic>
Chrome also fills those up with stuff for PDFs and DRM and NaCl so maybe they will never go away
19:09
<othermaciej>
we have built-in PDF rendering that is implemented as a plugin under the covers, but we largely hide that fact (I think)
19:41
<Ms2ger>
Servo had to implement them (as empty sets) for compat with twitter
19:41
<Ms2ger>
https://github.com/servo/servo/issues/9991