01:22
<MikeSmith>
Domenic: I see
01:23
<MikeSmith>
I agree with the sentiment but in the case of the outline algorithm I wonder if that would be possible without disallowing h1 within section etc
01:24
<MikeSmith>
as annevk alludes to in https://github.com/whatwg/html/issues/83#issuecomment-136933409
01:25
<MikeSmith>
I find myself agreeing with most or all of what Hixie and annevk say in that thread
01:26
<MikeSmith>
especially as far as the point that it seems like we can't just remove the outline algorithm without needing to make other changes as a consequence
01:26
<Domenic>
Did you see my latest plan?
01:26
<MikeSmith>
in that thread?
01:27
<Domenic>
Yeah posted today
01:27
<MikeSmith>
https://github.com/whatwg/html/issues/83#issuecomment-167440711 I guess?
01:27
<MikeSmith>
didn't read it yet
01:27
MikeSmith
looks now
01:29
<MikeSmith>
OK yeah that's something concrete to discuss
01:30
<MikeSmith>
so as far as the "change the authoring guidance" part I think that in part might amount to more than just changing guidance but also signficantly changing the normative document-conformance requirements
01:31
<Domenic>
Yeah
01:31
<Domenic>
So that documents are only conforming if they are usable by disabled users
01:32
<MikeSmith>
OK
01:32
<MikeSmith>
yeah that it is good way to frame it
01:32
<Domenic>
The big thing about that post is that it's different from my original plan of obsolete/remove everything.
01:32
<Domenic>
We can still say section etc. have semantic value
01:32
<MikeSmith>
yeah
01:33
<Domenic>
We just can't define their author-facing semantics such that they break user-facing UI
01:33
<MikeSmith>
yup
01:33
<MikeSmith>
so yeah I strongly agree with the goal
01:34
<MikeSmith>
concretely I think it might amount to requiring/saying that h1-h6 cannot be used in ways differently than they could before <section> and <article> existed
01:35
<MikeSmith>
personally I would like to see the spec say that
01:35
<MikeSmith>
basically that your h1-h6 hierarchy in isolation from the rest of the document must make sense, in isolation
01:36
<MikeSmith>
because that's basically how AT/screen-reader users "see" it, in practice
01:36
<MikeSmith>
it's basically how *all* tools see it
01:37
<MikeSmith>
the only exception are the tiny handful of things that implement the outline algorithm
01:37
<MikeSmith>
all that said, I think the challenge there is a social one, not a technical one, in that we would be rolling back what the spec has previously made valid and even recommended to author-developers
01:39
<MikeSmith>
getting author-developers to quit using h1 nested in <section>, despite years of the spec recommending that they do it
01:39
<Domenic>
Yeah that sounds about right
01:39
<MikeSmith>
OK, well I'm funlly on board with that, if that's where we want to take it
01:39
<Domenic>
Part of that I think is making the outline algorithm produce the same outline ATs use
01:39
<MikeSmith>
yup
01:42
<MikeSmith>
I have actually already implemented part of this in the HTML checker
01:42
<MikeSmith>
in that the checker already emits warnings for cases of non-top-level H1s
01:43
<MikeSmith>
and I would be happy to extend that stuff to experimentally support a new/different outline algorithm, if/when we come up with one
01:45
<MikeSmith>
so that the checker Show Outline feature could show what the document outline looks like to actual AT
01:45
<MikeSmith>
instead of showing what it looks like according to the outline algorithm
01:45
<MikeSmith>
or at least, showing both, so that authors can compare and see the difference for themselves
01:46
<MikeSmith>
and could have the checker would report warnings or errors for anything that doesn't create a usable AT outline algorithm
01:47
<MikeSmith>
as I said I think the checker's already doing some of that, but it could be extended furtherーespecially if I have actual requirements in a spec to work from
02:35
<MikeSmith>
commented https://github.com/whatwg/html/issues/83#issuecomment-167461826
04:44
<tantek>
MikeSmith: I agree more with annevk, specifically, obsolete section, h, hgroup
04:45
<tantek>
MikeSmith: I don't mean to bum you out - sounds like a miscommunication of tone. I'm more looking to simplify and drop things from HTML that don't have obvious benefits to typical, perhaps even "most" web developers.
04:47
<tantek>
I do find it a bit ironic that even a second attempt at the abstract section/h (first being xhtml2) has essentially failed in practice (in live deployment on the web, and in browsers doing anything with it).
04:49
<tantek>
MikeSmith, to rephrase this as a positive, do you use section/h/hgroup on your own personal website?
04:50
<MikeSmith>
tantek: yeah understood, I was kinda directing that "bummed out" comment to myself as much as anything gelse. In that I notice sometimes looking back at stuff I wrote on IRC that I come across kinda more negative than I intend
04:50
<MikeSmith>
tantek: I never use hgroup
04:50
<MikeSmith>
we don't have "h", right?
04:50
<tantek>
h1 inside section acts like h, right?
04:50
<MikeSmith>
that was an XHTML2 thing wasn't it?
04:50
<MikeSmith>
ah yeah
04:50
<MikeSmith>
yeah that I don't use
04:50
<tantek>
right
04:51
<tantek>
I used to use article, but I stopped because I couldn't find any benefit
04:51
<MikeSmith>
I use h1-h6 strictly according to order
04:51
<MikeSmith>
yeah I can't explain any benefit of it to anybody
04:52
<MikeSmith>
tantek: but anyway I agree we should obselete section and hgroup if we could
04:52
<tantek>
that would be a good start
04:52
<MikeSmith>
especially hgroup literally has no purpose at all outside of the outline algorithm
04:52
<tantek>
and to be fair, I was a fan of hgroup originally
04:53
<MikeSmith>
well currently I think its only purpose/effect in practice is to hide/suppress subheadings in the outline algorithm
04:53
<tantek>
used / taught it in the book and everything
04:53
<MikeSmith>
well I think a lot of this is hindsight
04:54
<MikeSmith>
I think most everybody thought this stuff was a good idea at the time
04:54
<tantek>
I wanted to believe and all that.
04:54
<tantek>
Enriching the language to cover more use-cases etc.
04:54
<MikeSmith>
yeah
04:55
<tantek>
Then it turned out many of these use-cases were too edge-case.
04:55
<tantek>
And weren't worth the cognitive cost of added complexity to the core language.
04:55
<MikeSmith>
yeah, and like a lot of other things with the platform, it's turned out to be a lot more complicated than it seemed, and has had bad unintended side effects
04:56
<tantek>
Agreed
04:57
<tantek>
Also I've pretty much given up on sets/pairs of nested tags for special functionality. Too awkward and easy to get wrong.
04:57
<tantek>
And then we end up having to define what should happen when they're misused anyway
04:57
<tantek>
tags work best when they perform single self-standing functions
04:58
<MikeSmith>
I think one good rule of thumb is that when somebody finds themselves repeatedly using an argument in support of something of the form "Vendors should just fix their buggy implementations", they seriously need to consider if they're on the wrong side of the argument (and the wrong side of history)
04:58
<MikeSmith>
tantek: yeah, it's a KISS thing in part
04:59
<tantek>
Yes, that's a good way to interpret the data point(s) of "buggy implementations"
05:02
<tantek>
FWIW it's taken *a lot* of work to figure out good ways to do hierarchical objects of any kind from microformats to microdata/rdfa to microformats2. And we're still finding edge cases to fix in parsers (to handle apparent natural author expectations).
05:02
<MikeSmith>
so as far as getting concrete progress maybe the lowest-hanging fruit is changing the spec so that we no longer have "h1 inside section that acts like XHTML2 h"
05:02
<MikeSmith>
tantek: yeah I can imagine
05:03
<tantek>
MIkeSmith yeah
05:04
<tantek>
the only way we have made any such incremental progress with mf2 is with active live use on the web, implementation in parsers, use of parsers by actual sites consuming and doing stuff with the data, then publishing more of it. a tight real world feedback loop.
05:04
<tantek>
without such real world publishing/implementation feedback loops, any attempt at language iteration is speculative at best, likely to fail at worst.
05:04
<MikeSmith>
yup
05:04
<tantek>
hence I've pretty much given up on anything unimplemented 1yr+ after being spec'd
05:05
<tantek>
or specing at all before at least one prototype implementation
05:05
<MikeSmith>
yeah and that's also why we should always be extremely cautious about adding any new elements
05:05
<MikeSmith>
I think we have been actually
05:05
<tantek>
MikeSmith: at this point we have web components to experiment with new elements
05:06
<tantek>
before we add them
05:06
<MikeSmith>
yeah
05:06
<tantek>
I'm also ok with extension specs
05:06
<tantek>
as a way to discuss ideas for new elements
05:06
<MikeSmith>
yes
05:06
<tantek>
but yeah, I wouldn't add anything to the core until there's some pretty serious critical mass
05:06
<tantek>
and OTOH I'd drop tons of stuff from the core, section/hgroup is just a start
05:06
<MikeSmith>
yeah I think we mostly have agreement about that these days, fortunately
05:07
<MikeSmith>
I mean about the critical-mass thing
05:08
<tantek>
I figured
05:08
<MikeSmith>
btw about h1-that-acts-like-h, for that I've already basically put some facts on the group by having the HTML checker (validator) emit warnings about it. I think I've had it emitting those warnings for almost a year or so now
05:09
<MikeSmith>
and nobody complains about them
05:09
<MikeSmith>
I don't get bug reports about those warnings
05:09
<tantek>
I've been circulating the idea of a drastic subsetting for some time among a few people, and pretty much always gotten a " it's crazy" response.
05:09
<MikeSmith>
so I take that to mean that authors are changing their documents to not have misplaced H1s
05:09
<tantek>
But now that AMP has been proposed, it looks less crazy. :)
05:09
<MikeSmith>
true
05:10
<MikeSmith>
things change
05:10
<tantek>
I tend to be impatient
05:12
<MikeSmith>
well, I think being impatient is a formula for frustration, as far as this platform goes 😆
05:13
<MikeSmith>
that said I'm also impatient
05:13
<MikeSmith>
can't help not being so I guess
05:15
<tantek>
MikeSmith: I've only found one place to direct that impatience with any positive results, my own website.
05:33
<MikeSmith>
tantek: yeah I should work on my own sites more
05:34
<tantek>
MikeSmith: on the theme of being more positive, it really helps
05:34
<MikeSmith>
yeah
05:34
<MikeSmith>
in that spirit I plan to get everything of mine running TLS-only soon
05:34
<MikeSmith>
let's encrypt is something to be really happy about
05:36
<tantek>
yes - it's a good thing
09:22
<MikeSmith>
http://stackoverflow.com/questions/34489810/firefox-push-api-aborterror-error-retrieving-push-subscription
19:56
<Domenic>
MikeSmith: what do you think of having the validator encourage people to use <script>, <script type="module">, or <script type="not-a-js-mimetype-or-module">?
19:56
<Domenic>
Currently it says that the value must be a valid mime type
19:56
<Domenic>
I think it would be a nicer story to say "if you want legacy script, don't include type. If you want module, include type="module". If you want an inert block, use anything without special behavior."
19:57
<Domenic>
But, maybe this would cause annoying warnings for people who are doing <script type="text/javascript">
21:49
<smaug____>
hmm, gstatic.com has been very slow recently
21:50
<smaug____>
I wonder what happens if I just block it
22:01
<smaug____>
any blink folks around?
22:01
<smaug____>
is https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/animation/ElementAnimation.idl&q=getAnimations&sq=package:chromium&type=cs&l=43 enabled by default?
22:02
<smaug____>
hmm, it is at least in dev builds
22:05
<smaug____>
but actually, I'm more interested in release versions
22:05
smaug____
wonders how to run different versions of chromium
22:27
<MikeSmith>
Domenic: I'm all for making the validator provide the most useful guidance it can; we could experiment with warning about type="text/javascript" and see what kind of reaction it gets
22:29
<Domenic>
MikeSmith: that would be cool. I want to figure out what to change the authoring "must" to and would prefer something like what I described.
22:30
<MikeSmith>
sounds good to me
22:32
<MikeSmith>
about <video> is it possible to completely programatically generate a video from scratch in JS?
22:32
<MikeSmith>
I mean similar to the way you can create a canvas or a audio stream
22:32
<MikeSmith>
I am guessing not, due to the encoding complexity
22:33
<MikeSmith>
and I mean without a JS library of some kind of video encoding
22:34
<Domenic>
I think some of the MSE stuff is aimed at that but I am not sure how low-level it is
22:34
<MikeSmith>
yeah I think MSE is not quite that low-level
22:34
<MikeSmith>
it can't generate the bytes on its own afaik
22:35
<MikeSmith>
anyway the context is http://stackoverflow.com/questions/34488237/can-html5-mediasource-be-used-to-dynamically-generate-a-single-color-video-of-ar
22:37
<MikeSmith>
these days I find SO to be a good source for finding edge cases of people pushing web-platform features to do odd/interesting stuff
22:38
<MikeSmith>
the Unanswered questions part of SO is at least as interesting as the questions that have good answers