03:45
<Hixie>
;
03:45
<Hixie>
oops
07:20
<MikeSmith>
Hixie: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19582
07:20
<MikeSmith>
have you ever heard of those?
07:20
<MikeSmith>
I wonder how widely used they are
07:20
<MikeSmith>
coap and coaps
07:20
<MikeSmith>
schemes
07:21
<MikeSmith>
I assume the criteria for whitelisting schemes is that they are actually used
07:23
<MikeSmith>
or actually that there are Web sites that handle them, than can process them
07:53
<MikeSmith>
Hixie: I'm gonna forward a couple more comments I got back from IANA for other media-type registration requests
07:53
<MikeSmith>
do with them what you will
07:58
<hsivonen>
MikeSmith: do you know what the deal is with http://idpf.org/epub/30/spec/epub30-ocf.html#app-media-type purporting to contain a registration but the type is not in the registry?
07:59
MikeSmith
looks now
08:00
<MikeSmith>
hsivonen: I can only surmise that they have not actually submitted the registration request to IANA yet
08:00
<hsivonen>
ok
08:00
<MikeSmith>
despite the statement "This appendix registers"
08:00
<MikeSmith>
there unfortunately is no way to tell if anybody has submitted a particular media-type request to IANA
08:01
<hsivonen>
It surprises me a bit considering that Murata Makoto seems to have experience with navigating the registration procedure.
08:01
<MikeSmith>
because you have to submit requests to a non-archived address, and then they respond privately
08:02
<MikeSmith>
I guess the procedure has changed since the last time Murata-san got something registered
08:02
<MikeSmith>
I can ask him about that one if you want
08:03
<hsivonen>
no need.
08:04
<MikeSmith>
ok
08:18
<hsivonen>
sigh. reloading document.written docs. can’t we just do what WebKit does...
09:00
<jgraham>
hsivonen: What does WebKit do?
09:00
<jgraham>
And "yes, probably, if you implement it in Gecko"
09:01
<jgraham>
(I sort of recall that WebKit does something dumb though)
09:41
<hsivonen>
jgraham: WebKit loads the URL that the location object represents
09:41
<jgraham>
That sounds familiar
09:42
<jgraham>
It seems simple and user-hostile
09:42
<hsivonen>
yes
09:43
<hsivonen>
whoa. looks like glazou implemented EPUB2 after all
09:51
<Stevef>
FYI requested <main> element spec to be published as FPWD and listed recent changes http://lists.w3.org/Archives/Public/public-html/2012Oct/0133.html
09:59
<Stevef>
a question to any of the WHATWG regulars: am unclear whether its OK for me to continue to ask for feedback on <main> on the WHATWG list, any thoughts?
10:03
<annevk>
FYI: I'll be at TPAC
10:04
<jgraham>
Yay
10:06
<annevk>
Thanks to hsivonen and Mozilla
10:07
<jgraham>
You are being smuggled in his suitecase?
10:11
<annevk>
Yes
10:12
hsivonen
is planning to travel with a backpack
10:22
<annevk>
:-)
10:22
<annevk>
Stevef: yes
10:22
<annevk>
Stevef: HTML is definitely on topic
10:24
<Stevef>
annevk: ok thanks
10:30
<Stevef>
annevk: i want to ensure that all people who may be interested in it are aware that its being developed and have the opportunity to provide input
10:31
<annevk>
Yeah, makes sense to me
10:36
<hsivonen>
@charset handling in Gecko is interesting
10:36
<hsivonen>
if the @charset rule itself in encoded in BOMless UTF-16, Gecko will carefully decode @charset as UTF-16 and then decode the whole stylesheet according to whatever encoding was declared
10:37
<hsivonen>
even though a non-UTF-16 encoding must be bogus
10:37
<hsivonen>
since in the case of non-UTF-16, @charset itself wouldn’t be UTF-16
10:37
<annevk>
that's kinda messed up
10:37
<hsivonen>
so much brokenness because of UTF-16
10:38
<annevk>
that should just fail or something
10:38
<SimonSapin>
hsivonen: isn’t that what is specified in http://www.w3.org/TR/CSS21/syndata.html#charset ?
10:39
<annevk>
SimonSapin: where does it say there that a utf-16 encoded @charset but with @charset not listing a utf-16 encoding, it should decode it per the listed encoding?
10:39
<hsivonen>
SimonSapin: apparently yes! the spec is messed up, too!
10:40
<hsivonen>
annevk: see the table
10:40
<annevk>
hmm really?! the fuck
10:40
<annevk>
I wonder if Hixie is to blame for that table
10:40
<hsivonen>
also, the spec supports UTF-32
10:41
<SimonSapin>
I think this is to be rewritten in css3-syntax. Input on this subject is greatly appreciated: http://dev.w3.org/csswg/css3-syntax/#the-input-byte-stream
10:42
<annevk>
I think utf-16 should only be supported out-of-band-or-BOM
10:42
<annevk>
so you just check for ASCII "@charset" at the start and go with that
10:42
<annevk>
then you drop utf-32
10:43
<annevk>
and only support what the Encoding Standard says
10:43
<hsivonen>
also, CSS3 Syntax makes the default UTF-8
10:43
<annevk>
including the BOM handling of the Encoding Standard (by reference)
10:43
<hsivonen>
not that it matters, unless you support loading CSS without a referring Document
10:43
<hsivonen>
wait
10:43
<SimonSapin>
annevk: feel free to send this to www-style :)
10:44
<hsivonen>
CSS3 syntax doesn’t inherit from Document
10:44
<SimonSapin>
hsivonen: what do you mean?
10:44
<annevk>
is inheritance from Document also cross-origin?
10:45
<hsivonen>
annevk: good question
10:45
<annevk>
SimonSapin: if your HTML is windows-1252 and your CSS does not say, it's windows-1252 too
10:45
<hsivonen>
SimonSapin: what annevk said
10:45
<SimonSapin>
oh, inheriting the encoding
10:46
<annevk>
and I think inheritance should not work for utf-16 (that means utf-8 again or some such)
10:46
<SimonSapin>
css 2.1 does that. The new syntax draft should too, but I guess that part just hasn’t been written yet
10:46
<hsivonen>
annevk: good point
10:47
<hsivonen>
All this would be so much simpler if UTF-16 had never been used for interchange
10:48
<SimonSapin>
why does utf16 require special treatment?
10:49
<annevk>
SimonSapin: because it's the only non-ASCII-compatible encoding
10:49
<hsivonen>
http://memegenerator.net/instance/28773378
10:49
<annevk>
SimonSapin: and generally people have no idea what they're doing
10:50
<SimonSapin>
even the various CJK encodings are ascii-compatible?
10:50
<annevk>
SimonSapin: yes, see the Encoding Standard
10:50
<hsivonen>
SimonSapin: yes.
10:50
<hsivonen>
SimonSapin: UTF-16 is the only encoding that doesn’t conform to the pattern
10:50
<hsivonen>
well, UTF-16 and UTF-16BE really
10:51
<SimonSapin>
ignoring utf32
10:51
<annevk>
utf-32 is not supported in most browsers
10:51
<hsivonen>
SimonSapin: UTF-32 is defined not to exist on the Web
10:51
<SimonSapin>
oh, ok
10:51
<annevk>
EBCDIC is also not ASCII-compatible, but does not exist either
10:51
<annevk>
"exist" :)
10:52
<annevk>
hsivonen: you know how to get that on w3cmemes?
10:52
<hsivonen>
annevk: I don’t
10:52
<SimonSapin>
the table in css2.1 has entries for EBCDIC, IBM1026 and GSM 03.38. whatever these are
10:53
<annevk>
CSS 2.1 was written when we had not looked at encodings in detail I think
10:54
<annevk>
or when the feeling was we should support all of them or something because IANA lists them in a document somewhere? I'm not entirely sure what the thinking was at the time, but we can now say it was wrong
10:56
<SimonSapin>
annevk: if you feel like writing up the details of how css3-syntax should get unicode from bytes, that would greatly help
11:04
<annevk>
SimonSapin: As I'm still trying to postpone working on URL conformance I guess I can do that
11:07
<annevk>
SimonSapin: are you co-editor or something?
11:08
<SimonSapin>
annevk: no. I’m implementer and recently joined the wg, but not editing anything
11:09
<SimonSapin>
but I’m interested in seeing this progress, and maybe I can push it a little in the group
11:10
<annevk>
kk, I'll take a look
11:13
<MikeSmith>
anybody know what plans if any there are for the Streams API draft
11:14
<MikeSmith>
the one from Microsoft
11:16
<annevk>
well they implement it
11:16
<annevk>
and sicking was finally convinced it's better than chunked
11:16
<annevk>
so I put it in XHR
11:16
<annevk>
haven't heard much since
11:17
<annevk>
but maybe that's because it's WHATWG XHR and Microsoft does not care about that?
11:17
<MikeSmith>
dunno
11:18
<MikeSmith>
but I thought part of the job of the three editors of the W3C XHR draft was to track your upstream changes and evaluate them and pull them to the W3C version as needed
11:20
<MikeSmith>
and the Crypto WG seems to be interested in the Streams spec as well
11:20
<MikeSmith>
and other people have asked me about it lately
11:27
<annevk>
SimonSapin: http://html5.org/temp/cssencoding.txt
11:28
<annevk>
SimonSapin: I think that can replace all that CSS 2.1 has
11:28
<annevk>
SimonSapin: note that the Encoding Standard deals with all the BOM stuff already so that does not need to be listed
11:38
<annevk>
MikeSmith: is it? I've heard surprisingly little about their plans
11:38
<annevk>
MikeSmith: though hallvors came in here the other day suggesting something like that
11:38
<annevk>
MikeSmith: and he'd maybe even contribute to whatwg/xhr
11:40
<MikeSmith>
annevk: I think that's the general plan for all things you're editing that have a W3C equivalent
11:42
<annevk>
need a lot of editors then :p
11:42
<MikeSmith>
yeah
11:42
<hsivonen>
annevk, SimonSapin: http://lists.w3.org/Archives/Public/www-style/2012Oct/0615.html
11:43
<annevk>
ah cool
11:43
<annevk>
I tweeted my thing cc'ing TabAtkins
11:43
<annevk>
hopefully he'll sort it out somehow
11:43
<hsivonen>
annevk: wait, you’t honor the charset declared by @charset even if there is a UTF-8 BOM?
11:44
<annevk>
hsivonen: no, BOM overrides all
11:44
<annevk>
hsivonen: BOM is part of step 7
11:44
<annevk>
hsivonen: that's why the input to decode is called "fallback encoding"
11:44
<hsivonen>
annevk: why bother with EF BB BF in step 3 then?
11:44
<annevk>
ooh that seems like a bug
11:45
<annevk>
shit I thought the difference there was quotes or no quotes
11:45
<annevk>
my bad
11:45
<annevk>
fixed
11:45
<hsivonen>
annevk: thanks
11:45
<matjas>
annevk: “the set label” → “then set label”
11:45
<matjas>
i think
11:46
<annevk>
matjas: yeah fixed that when I fixed the thing hsivonen just mentioned :)
11:46
<annevk>
hsivonen: whoa CSS 2.1 was crazy
11:47
<annevk>
hsivonen: overriding the utf-8 BOM if the @charset that followed it said something else
11:47
<hsivonen>
I should check if I accidentally made scripts inherit UTF-16
11:48
<hsivonen>
sigh. I did.
11:49
<hsivonen>
though so did our old script decoding code
11:49
hsivonen
files a bug
11:57
<annevk>
kind of funny that out of that big table in CSS 2.1 the only relevant line ends up being 40 63 68 61 72 73 65 74 20 22 (XX)* 22 3B
11:58
<annevk>
to be fair, that's mostly because it catered towards utf-16/utf-32/BOM, but also EBCDIC / IBM1026 / GSM?!
12:07
<hsivonen>
whoa! http://lists.w3.org/Archives/Public/www-style/2012Oct/0597.html French and Dutch consider 0 positive????!!!‼⁇⁈⁉‽
12:08
<jgraham>
Like IEEE 754 then :)
12:09
<annevk>
hsivonen: nah, that's just Belgian usage
12:09
<annevk>
hsivonen: http://nl.wikipedia.org/wiki/Positief_getal
12:09
<jgraham>
(as opposed to -0 ofc)
12:09
<annevk>
hsivonen: in Dutch it's neither negative nor positive
12:09
<annevk>
well, Dutch as practiced in the Netherlands
12:10
<SimonSapin>
hsivonen: I’m french; just saying "positive" is often ambiguous
12:11
<annevk>
non-negative is good though
12:11
<SimonSapin>
when I studied math or physics (in france) we always said "strictly positive" or "positive or zero"
12:11
<annevk>
but ideally we just define these words somewhere
12:12
<annevk>
SimonSapin: Belgium does the same "strikt positief" :)
12:12
<annevk>
(I just read)
12:12
<SimonSapin>
non-negative is good, but I never heard it in french
12:18
<Ms2ger>
Actually, it's more complicated in Belgium
12:19
<MikeSmith>
wondering how could it be more complicated then discussed above...
12:19
<hsivonen>
how can it be more complicated than a yes or no question?
12:19
<hsivonen>
Is 0 positive? Yes or no.
12:19
<Ms2ger>
"Can be either, depending on the field the person you're talking to works in"
12:20
<webben>
could one just substitute "more than 0" and "0 or more" ?
12:21
<jgraham>
Yes, I think that this is the point where karlcow starts saying things like "different cultures, different perspectives"
12:21
<annevk>
half full half empty?
12:21
<jgraham>
To explain why not everyone can agree on a single unambiguous definition for the word "positive"
12:21
<MikeSmith>
jgraham: :-)
12:22
<MikeSmith>
so please try to have these kinds of conversations while karl's around
12:22
<Ms2ger>
Clearly, everyone should just agree on positive for >0 and non-negative for >=0
12:23
<SimonSapin>
… and on the metric system, and utf-8, and driving on the right side of the road
12:23
<SimonSapin>
and don’t forget Esperanto :)
12:23
<Ms2ger>
All of that, except for Esperanto :)
12:28
<jgraham>
I thought even the made-up-language folks hated Esperanto
12:28
<jgraham>
Isn't Lobjan where all the hot geek action is these days?
12:28
<MikeSmith>
we should make a natural language based on JavaScript
12:28
<SimonSapin>
I don’t actually know any Esperanto or other made-up language
12:29
<jgraham>
MikeSmith: Never bet against javascript
12:30
<AryehGregor>
GPHemsley, I should be able to give you SSH access if you give me your public key, but I'm not actually sure I should be doing that, so maybe better to ask Hixie.
12:30
<hsivonen>
made-up language folks don’t seem too focused on installed base and Support Existing content
12:31
<annevk>
AryehGregor: yeah you're allowed to do that
12:31
<jgraham>
In the vein of "there's an xkcd for that": http://www.exocomics.com/101
12:32
<AryehGregor>
Okay, tnen.
12:32
<AryehGregor>
then.
12:32
<AryehGregor>
GPHemsley, then I'll need your public key.
12:32
<AryehGregor>
I should still have my own login info lying around.
13:10
<annevk>
kinda wished we had gone with "idl" in xref rather than "webidl"
13:16
<annevk>
so URL terminology
13:16
<annevk>
URL is a string
13:16
<annevk>
there's relative and absolute URLs (also both strings)
13:16
<annevk>
parsed URL is the object you get from parsing a URL
13:17
<annevk>
conformance of relative URLs hinges upon the base URL in play
13:17
<annevk>
(base URL needs to have an hierarchical scheme)
13:18
<annevk>
absolute URL consists of "scheme", "data", "fragment"; for hierarchical absolute URLs "data" is "domain", "port", "path", "query"
13:18
<annevk>
for others it depends
13:20
<annevk>
relative URLs are either relative authority relative URLs (start with //), query relative URLs (start with ?), fragment relative URLs (start with #), or path relative URLs (anything else)
13:21
<annevk>
"http:path" weirdness is non-conforming
13:21
<annevk>
because it depends on the base URL whether it's relative or absolute
13:23
<annevk>
and I'm not a 100% sure about URLUtils.valid anymore as it does not say much about whether the input was conforming, just whether parsing did not result in failure
13:35
<scott_gonzalez>
Shouldn't dialog.showModal() set focus to the dialog element itself if there is no autofocus element? http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#dom-dialog-showmodal
13:35
<scott_gonzalez>
Or is step 9 saying that the dialog shouldn't even open in that case?
13:47
<GPHemsley>
AryehGregor: Where do you want me to send/put it?
13:47
<annevk>
scott_gonzalez: it's saying focus is not changed in that case
13:48
<annevk>
scott_gonzalez: it's opened the moment the open attribute is added
13:48
<scott_gonzalez>
annevk: Wouldn't a modal dialog without focus be a problem?
13:49
<annevk>
scott_gonzalez: why?
13:50
<scott_gonzalez>
Because you can't interact with anything other than the dialog, but focus is outside of the dialog.
13:50
<annevk>
(it does seem like there should be some integration of the inertness concept and focusing)
13:50
<scott_gonzalez>
How would a keyboard user accomplish anything in that case?
13:50
<scott_gonzalez>
And how would screen readers know to announce the dialog if it doesn't have focus?
13:51
<annevk>
well the other things are marked inert so cannot be interacted with either
13:51
<scott_gonzalez>
Should I bring this to WAI PF?
13:51
<annevk>
presumably that means the focus is on the Window
13:51
<annevk>
scott_gonzalez: I'd raise it on the WHATWG list
13:51
<scott_gonzalez>
ok
13:53
<Stevef>
scott_gonzalez: I would suggest focus needs to move to the dialog itself
13:53
<scott_gonzalez>
Stevef: That is my thought as well, and what we do in jQuery UI.
13:56
<annevk>
is <dialog> defined as focusable element though?
13:57
<scott_gonzalez>
I'm not sure, but presumably it should be if there are no requirements for a focusable close button.
13:58
<scott_gonzalez>
I would think that `control` should fallback to the first tab focusable element if no element with autofocus exists.
14:01
<annevk>
scott_gonzalez: anyway, email the list explaining the potential problems and I'm sure Hixie will address it
14:01
<annevk>
bbl
14:08
<MikeSmith>
"relative authority relative URLs" don't roll off the tongue so well
14:09
<jgraham>
heh
14:12
<annevk>
MikeSmith: I was just thinking about that some more, I think they're actually scheme-relative URLs
14:12
<annevk>
authority-relative would be path/fragment/query combined, but I don't think we need a name for that
14:13
<annevk>
MikeSmith: oh I see, the double usage of "relative", heh
14:14
<MikeSmith>
yeah that part
14:14
<MikeSmith>
I meant
14:15
<MikeSmith>
annevk: anyway, fwiw, all you outlined above earlier sounds sane to me
14:15
<annevk>
the thing the IETF is not going to like is that this stuff is scheme-dependent
14:16
<MikeSmith>
right
14:16
<annevk>
but at least for the hierarchical stuff that's how it's implemented
14:16
<MikeSmith>
but that is a face
14:16
<MikeSmith>
*fact
14:16
<MikeSmith>
yeah, what you said
14:16
<MikeSmith>
if they don't like reality there's not much we can do about that
14:17
<MikeSmith>
and I don't really think it's so widespread a dislike at the IETF
14:17
<MikeSmith>
I think it's a very vocal minority
14:17
<MikeSmith>
or a kind of "Moral Majority"
14:18
<MikeSmith>
I really wonder what causes people to turn from being pragmatic into becoming techno-reactionaries
14:22
<annevk>
MikeSmith: you want as "Michael™ Smith" in the acknowledgments or without the ™?
14:22
<annevk>
MikeSmith: and apologies for adding you so late, and even more apologies to abarth!
14:23
<MikeSmith>
annevk: I didn't do much
14:23
<MikeSmith>
but if you put me, with the tm in some form is great
14:23
<GPHemsley>
AryehGregor_: Where do you want me to send/put it?
14:53
<[tm]>
wow http://labs.ft.com/2012/06/text-re-encoding-for-optimising-storage-capacity-in-the-browser/
14:59
<hsivonen>
[tm]: so sad
15:05
<GPHemsley>
Hixie: I can't find any external contenteditable standard, and it seems to still be in HTML.
15:06
<annevk>
GPHemsley: that wiki page is talking about http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html
15:15
<GPHemsley>
annevk: Ah, thanks.
15:39
<annevk>
GPHemsley: btw, were you planning on maintaining mimesniff?
15:40
<annevk>
GPHemsley: if you need help in retrofitting what's there now as input for Anolis, let me know
15:41
<GPHemsley>
annevk: I hadn't thought about it, but I could give it a shot...
15:41
<GPHemsley>
annevk: If you're referring to the error I mentioned a while back, it was just the first one I grabbed.
15:42
<GPHemsley>
annevk: But if you're looking to lighten your load
15:45
<annevk>
GPHemsley: heh, I'm not doing anything with it at the moment and I don't think abarth is either
15:45
<GPHemsley>
yeah, was just gonna ask
15:45
<GPHemsley>
(I just assumed it was you, until I looked)
15:46
<annevk>
GPHemsley: not sure much needs to be done other than font sniffing, but there's a few other MIME related matters that could use looking at
15:46
<GPHemsley>
Did we ever get an answer as to where the source was?
15:48
<annevk>
I suspect either abarth has it or lost it
15:49
<annevk>
judging by https://github.com/abarth/websec/tree/master/drafts it was never in git
15:49
<jgraham>
Um, why don't the FT people just use some proper form of compression on the data they want to store?
15:51
<[tm]>
annevk: GPHemsley : i think before maybe abarth wasusin some
15:51
<[tm]>
some xml thing
15:51
<[tm]>
so that he could generate the ietf version
15:52
<[tm]>
in whatever asshat format that requires
15:53
<annevk>
GPHemsley: but it hardly has any cross-references so rewriting it back to normal is trivial
15:54
<GPHemsley>
annevk: Well, I don't have any experience using anolis, so I'd need guidance either way ;)
15:55
<annevk>
GPHemsley: I can make the Overview.src.html, was planning on doing that anyway
15:55
<GPHemsley>
alrighty
15:56
<annevk>
but yeah, with regards to MIME; MIME type parsing needs to be defined at some point
15:56
<annevk>
string -> parsing -> MIME object -> serialize (with options such as without parameters, lowercase)
15:56
<annevk>
and then everything in the platform that takes a MIME type needs to hook into that somehow
15:57
<annevk>
(or not)
15:57
<annevk>
and no longer tying MIME to IANA would also be nice
16:01
<GPHemsley>
annevk: You'd still want to have a registry though, no?
16:02
<annevk>
GPHemsley: yeah, wiki thing
16:02
<GPHemsley>
hmm
16:07
<[tm]>
the wiki thing in practice is not proving to be so brilliant
16:09
<[tm]>
though it's still better than the byzantine iana etc. stuff
16:09
<GPHemsley>
[tm]: What are the problems?
16:10
<[tm]>
GPHemsley: with the iana way?
16:10
<GPHemsley>
[tm]: No, with the wiki way
16:10
<[tm]>
ah
16:11
<[tm]>
there's an open bug about that
16:11
<[tm]>
remind me later if you care enough
16:11
<[tm]>
away from my pc now
16:12
<GPHemsley>
k
16:13
<[tm]>
the rel registry at micriformats.org is particularly FUBAR by design
16:13
<GPHemsley>
http://microformats.org/wiki/existing-rel-values
16:14
<[tm]>
was a bad idea to hitch sny wagon to that mess
16:14
<GPHemsley>
can it be unhitched?
16:15
<[tm]>
i sure hope so
16:16
<[tm]>
if common sense can eventually prevail
16:16
<GPHemsley>
You know what would be cool? If using a +modifier on a mailing list e-mail address automatically added it in brackets to the subject
16:16
<GPHemsley>
e.g. whatwg+mimesniff⊙wo => [mimesniff] sadfasdfj
16:17
<GPHemsley>
and likewise, subscribing to such e-mail addresses would only give you the messages prefixed as such
16:17
<GPHemsley>
then, those who want everything can subscribe to whatwg⊙wo
16:17
<GPHemsley>
and those who don't can subscribe only to the modifiers they want
16:18
<GPHemsley>
though I imagine someone will have to talk to the Mailman developers about that
17:04
<GPHemsley>
ugh, the structure of an MP3 is annoyingly variable
17:26
<GPHemsley>
Where does the code that powers the website live? And who's in charge of that?
17:28
<Hixie>
MikeSmith: i like the one where the guy says application/xhtml+xml and application/xml are in any way different
17:29
<Hixie>
MikeSmith: fwiw i'm planning on ignoring those, sometime next year i'll figure out a more practical way of documenting Content-Type values
17:29
<Hixie>
annevk: i think that table was by dbaron, but i could be wrong
17:33
<Hixie>
GPHemsley: i encourage you not to write text that is less accurate than possible in the interests of political correctness
17:34
<Hixie>
GPHemsley: e.g. webdatabase is dead, it's not "not being actively maintained"
17:34
<Hixie>
GPHemsley: politically correct phraseaology tends to mislead people who aren't familiar with the politics
17:40
<GPHemsley>
Hixie: IMO, saying it is dead is the language that is less accurate than possible. A spec cannot be "dead" so long as the document is still present and available.
17:41
<Hixie>
that's like saying a person can't be dead while the corpse isn't ceremated :-)
17:41
<GPHemsley>
Not really, because a spec can be resurrected at a future date (just like with HTML)
17:42
<Hixie>
HTML never died
17:42
<Hixie>
but would "abandoned" be better?
17:42
<GPHemsley>
I suppose, as long as you keep the date, as well.
17:43
<TabAtkins>
SimonSapin: If it's editorial, feel free to make the edit yourself, and ping me about it. Just be sure to honor the indentation/line-breaking style of the spec you're editting. ^_^
17:43
<Hixie>
i changed the date to "late 2010" since it's hard to pin down exactly when it was last maintained (it was certainly before the last date on the spec)
17:43
<Hixie>
(since i stopped working on it months before people asked for the warning to be added on the w3c copy)
17:43
<GPHemsley>
Very well
17:43
<Hixie>
(i even stopped working on it months before i deleted it out of the whatwg copy)
17:43
<Hixie>
(which itself was long before the warning was added)
17:44
<SimonSapin>
TabAtkins: see http://www.w3.org/mid/5083ED64.1090402⊙kf
17:46
<GPHemsley>
Hixie: Are the W3C versions of workers, sockets, storage, and server-side events identical to the language in the WHATWG HTML spec?
17:46
<Hixie>
the headers are definitely different
17:47
<GPHemsley>
content-wise
17:47
<GPHemsley>
normatively
17:47
<Hixie>
dunno how much the bodies differ, think the gorup froze the non-dev versions for TR/ publication
17:47
<Hixie>
i don't pay much attention
17:48
<GPHemsley>
well, these links are to the dev versions
17:48
<Hixie>
those should be more or less identical, at least in ways that matter
17:48
<Hixie>
certainly much more so than the w3c html5 spec
17:49
<GPHemsley>
I'm just wondering if the relationship between HTML5 and HTML is significantly different from the rest to warrant two different sections
17:49
<Hixie>
ah
17:49
<GPHemsley>
Because HTML5 is unambiguously a fork; perhaps the others strictly aren't.
17:49
<Hixie>
i wouldn't worry about it
17:52
<TabAtkins>
SimonSapin: I'm fine with changing it to "CSS in", but the "dot" is intentionally ambiguous, and should be defined wherever it is used. (I might not be doing this in Images 3 right now.)
17:52
<TabAtkins>
In MQ, it's device pixels. In Images, it's image pixels.
17:53
<GPHemsley>
Hixie: Also, if you could double-check the names for the former sections of the spun-off specs, that'd be great. I don't know where to find those, but I think we should make sure they're correct for anyone looking for them by their old names.
17:53
<GPHemsley>
Hixie: In many cases, I had to guess, because I didn't know where to look to find that info.
17:56
<Hixie>
GPHemsley: the names changed a lot over time
17:56
<Hixie>
GPHemsley: which names should we list?
17:56
<GPHemsley>
the most recent one before it was spun off
17:57
<GPHemsley>
I think
17:57
<Hixie>
that should almost always be the same as the new spec's name
17:57
<GPHemsley>
Oh, hmm
17:58
<Hixie>
actually /tr/html5 might actually be useful for this purpose :-)
17:58
<GPHemsley>
ah! :)
17:59
<Hixie>
yeah if you go back far enough you should be able to use those to find section names
17:59
<Hixie>
i expect in many cases it'll be difficult to pick one section name, though
18:01
<GPHemsley>
alright, I'll take a look
18:02
<scott_gonzalez>
Hixie: When I said that dialog's control should fall back to the first tab focusable element, I meant within the dialog, which would exclude the body.
18:03
<Hixie>
doesn't make any difference, does it?
18:03
<scott_gonzalez>
Well, it does in terms of what has focus to get exposed to AT.
18:04
<scott_gonzalez>
You said "This is no different than when the page first loads. If nothing has
18:04
<scott_gonzalez>
autofocus="", or if no script calls .focus(), then nothing in the page has
18:04
<scott_gonzalez>
focus."
18:04
<scott_gonzalez>
But the body gets focus in that case.
18:04
<Hixie>
not really
18:04
<Hixie>
the body having focus is one of those weird hacks that's not entirely true but we mostly pretend
18:04
<Hixie>
anyway, i would expect ATs to implement <dialog> natively and report that a dialog was opened, and act accordingly
18:05
<tantek>
[t m] why do you say "wiki thing in practice is not proving to be so brilliant" and "particularly FUBAR by design" ? do you have specific problems or suggested improvements?
18:05
<tantek>
[tm]
18:05
<scott_gonzalez>
So I guess I should ask browser vendors if they will expose the information when the dialog doesn't have focus?
18:06
<Hixie>
scott_gonzalez: what information?
18:06
<scott_gonzalez>
That the dialog has opened.
18:06
<scott_gonzalez>
If you do this in JS and use ARIA, I'm fairly certain nothing is announced unless the dialog gets focus.
18:06
<Hixie>
it'd be pretty inaccessible if you didn't report it
18:07
<Hixie>
ARIA has nothing to do with this
18:07
<scott_gonzalez>
I realize ARIA isn't involved here.
18:07
<scott_gonzalez>
But it's the only thing I can reference in terms of what browsers are exposing right now.
18:07
<scott_gonzalez>
For example, you can't have an alert() that doesn't get focus.
18:08
<tantek>
for anything microformats related, e.g. the rel-registry http://microformats.org/wiki/existing-rel-values, feel free to also /join #microformats and ask questions / provide feedback there
18:08
<tantek>
we'll continue to make improvements as people point out specific problems or make specific suggestions. thanks!
18:09
<Hixie>
scott_gonzalez: i think there are multiple things here that you are conflating but that are separate.
18:09
<Hixie>
scott_gonzalez: 1. reporting to the user that there is a (modal) dialog. 2. the keyboard focus. 3. the AT focus.
18:10
<Hixie>
scott_gonzalez: on Mac, if a dialog comes up, the app has keyboard focus, but no control in the dialog need have focus. a control will have AT focus, however.
18:11
<GPHemsley>
Hixie: Wrt the republications, why do you feel that it should be emphasized that the work is originally done in the WHATWG? (The entire page is already referring specifically to the WHATWG standard.)
18:12
<Hixie>
GPHemsley: because people have accused me of stealing from the w3c html spec and that pisses me off
18:12
<GPHemsley>
ah, ok :)
18:12
<Hixie>
:-)
18:16
<scott_gonzalez>
Hixie: I see what you're saying. So it's impossible to fully emulate the focus with JavaScript, correct?
18:16
<scott_gonzalez>
Because document.activeElement would continue to be the element that had focus prior to the dialog being shown?
18:17
<scott_gonzalez>
At least that's the behavior I'm seeing with alert() in Chrome, even while the OK button has focus inside the dialog.
18:17
<Hixie>
scott_gonzalez: not sure what you mean by "emulate the focus", but when a dialog comes up, if the previously focused element is now inert, it loses focus.
18:18
<scott_gonzalez>
If I focus on an element, then run alert() in the console, document.activeElement continues to be the previously focused element.
18:19
<scott_gonzalez>
But the whole page is inert, correct?
18:20
<Hixie>
no
18:20
<Hixie>
alert() is a different OS-level window, it doesn't affect the in-page focus of the previous page
18:20
<Hixie>
"inert" is a technical term that is used to implement <dialog>
18:28
<scott_gonzalez>
I guess I'll just have to wait for an implementation to be available.
18:37
<Hixie>
annevk: dude, i'm so not making every non-utf8 doc non-conforming. :-/ https://www.w3.org/Bugs/Public/show_bug.cgi?id=15332
18:38
<annevk>
GPHemsley: for the registrations Hixie had this idea to have a wiki page and move the ones that are proven into the main specification (with reference to another specification if present or otherwise inline)
18:39
<GPHemsley>
Interesting...
18:39
<annevk>
GPHemsley: either something like that or we'd need someone to make a web service of sorts, but the annoying thing with that is that you need to solve a lot of the same problems with respect to identity and such
18:39
<GPHemsley>
annevk: Identity of what? The person submitting?
18:40
<annevk>
GPHemsley: yeah, the nice thing about the wiki is that you already have an account and such
18:40
<annevk>
nice thing about a web service would be that the validator logic would become a bit simpler, because wiki scraping sucks
18:40
<annevk>
and the wiki already has history and such too
18:41
<GPHemsley>
why does identity matter? should only the attachment to a particular spec matter?
18:41
<GPHemsley>
s/should/shouldn't/
18:41
<Hixie>
i expect to do this registry stuff sometime next year
18:42
<annevk>
GPHemsley: you need some kind of protection against spammers
18:42
<GPHemsley>
annevk: Random spammers or malicious registration spammers?
18:43
<annevk>
GPHemsley: is there a difference?
18:43
<Hixie>
need to think about it some more, but i'm thinking there's conforming entries with spec text, non-conforming entries that describe actual use, experimental entries that people want to use, and rejected entries that were experimental and didn't work out
18:43
<annevk>
Hixie: I need something for URLs too
18:43
<GPHemsley>
annevk: Well, the former is nonsensical and the latter is... not
18:43
<Hixie>
annevk: oh there's lots of registries here
18:44
<Hixie>
mime, rel, meta name are the three big ones i have to deal with
18:44
<Hixie>
but there are many others
18:44
<Hixie>
meta name has been interesting, there are SO MANY out there
18:44
<Hixie>
not sure what we should do with that yet
18:45
<annevk>
it's pretty successful too
18:47
<annevk>
https://twitter.com/masinter/status/260438941751201792 heh
18:49
<Hixie>
annevk: it certainly documents more values than iana would
18:49
<annevk>
URL schemes is pretty interesting, as it has an effect on parsing
18:49
<Hixie>
annevk: but it has failed at making authors avoid dumb values
18:49
<Hixie>
anyway, gotta go to work, bbiab
18:52
<annevk>
I love http://lists.w3.org/Archives/Public/uri/2012Oct/0011.html
18:52
<annevk>
The way to achieve KISS is by writing specs like the way Hixie wrote HTML, by spelling out every single thing that needs to be done
18:53
<annevk>
Because only then do you realize a) HTML is actually super complex and b) you could probably design something simpler that does just as well
18:53
<annevk>
The way to achieve KISS is not by writing simpler specs, it's by coming up with simpler constructs, less variance, etc.
18:55
<GPHemsley>
Argh, HTML archaelogy is hard.
18:56
<annevk>
GPHemsley: following @mattur on twitter yet?
18:57
<GPHemsley>
annevk: No, why?
18:57
<divya>
he is the doyen of html archealogy
18:58
<annevk>
The problem with some members of the TAG, like Noah, is that they don't like complex specs for some reason, but we're only describing what was already out there. We're not even introducing new complexity in many cases. Far more often reducing it (e.g. the Encoding Standard makes many simplifications over what we have now).
18:59
<GPHemsley>
annevk, divya: Well, it's made more difficult by the fact that github is treating the (W3C-converted?) source as a binary file, even though it's all text.
18:59
<annevk>
Most of the HTML standard is about reducing complexity too. First you had 4+ different complex HTML parser implementations. Now you have 4+ equivalent complex HTML parser implementations (that all got slightly saner too).
18:59
<annevk>
GPHemsley: use http://html5.org/tools/web-apps-tracker ?
19:00
<GPHemsley>
I need access to the contents of the file itself at a given revision
19:00
<GPHemsley>
I'm trying to track down when things changed
19:00
<GPHemsley>
in 2009
19:00
<GPHemsley>
;)
19:00
<GPHemsley>
it's alright, I'm almost there
19:01
<annevk>
GPHemsley: there's a secret parameter named limit
19:01
<annevk>
GPHemsley: set it -1 and enjoy
19:01
<GPHemsley>
can't wait to find out what the commit message is, because it's clearly not going to be especially descriptive
19:01
<GPHemsley>
annevk: The problem is, I don't know what I'm looking for
19:01
<GPHemsley>
beyond the contents of the file
19:02
<GPHemsley>
I've narrowed it down to a few days in June 2009
19:02
<AryehGregor_>
GPHemsley, just give it to me on IRC, or pastebin or something. Or e-mail, which would probably be best because then I'll see it.
19:02
<GPHemsley>
AryehGregor: .name?
19:02
<AryehGregor>
Oh, you're around right now. So just give it to me on IRC.
19:02
<AryehGregor>
?
19:03
<AryehGregor>
ayg⊙an will work.
19:03
<AryehGregor>
May as well just tell me on IRC, though, once we're here.
19:03
<GPHemsley>
AryehGregor: I already had the draft set up, so I sent it via e-mail. :)
19:05
<AryehGregor>
GPHemsley, try logging in. whatwikiuser⊙wo
19:05
<AryehGregor>
(yes, it's a shared login and I just added you to authorized_keys)
19:05
<GPHemsley>
works, thanks
19:06
GPHemsley
is suddenly doing a hundred things at once
19:18
<GPHemsley>
annevk: I don't suppose there's a way to view the HTML page as it was at a particular revision?
19:18
<GPHemsley>
(the compiled version)
19:32
<annevk>
GPHemsley: no
19:33
<annevk>
GPHemsley: I have thought about doing it, but a) the subresources make that complex and b) it would take up a lot of space (but that's not necessarily a problem)
19:33
<annevk>
GPHemsley: also, usually you can get pretty far by using the W3C snapshots
19:39
<tantek>
Hixie - for a while I considered setting up documentation of existing meta name values on the microformats wiki similar to rel values, but to date it's been rejected due to meta name being an encouragement of the use of invisible metadata which is seen as bad (for data quality etc.) in general.
19:39
<tantek>
what's the utility of "validating" the use of meta names which are likely going to be used to pollute the web anyway?
19:41
<tantek>
that being said, it does seem like every new semi-popular social content hosting site wants to make up their own meta names (or pseudo-rdfa-like properties, FB OGP ahem) for purposes of "stuff about the page to include when someone posts a link to the page"
19:41
<TabAtkins>
hsivonen, annevk: Syntax spec updated to use Anne's list of steps and point to the Encoding Standard.
19:41
<tantek>
when multiple vendors independently innovate something like that, usually it's a sign that there's a need for a standard to reduce the burden on publishers.
19:43
<tantek>
so because of that, we may end up documenting research on existing meta name/property usage anyway :/
19:43
<tantek>
not sure it will be useful as a "registry"
19:43
<tantek>
but hey, that's how existing-rel-values started (documenting a few things)
19:44
<tantek>
and then eventually it turned into the most comprehensive documentation of rel values on the web
19:44
<tantek>
which I think is due more to it being on a wiki page than having anything to do with microformats in particular, although the culture of the microformats community is a very research/documentation-centric culture so that probably had something to do with it.
19:45
<tantek>
in contrast to a "just email your proposal to a mailing list and the 'experts' will consider it and get back to you eventually" type "culture"
19:46
<annevk>
TabAtkins: sweet, will review later!
19:46
<annevk>
MikeSmith: can we get a MIME component under the WHATWG product?
19:58
<annevk>
I updated http://mimesniff.spec.whatwg.org/ to be generated from a source file
19:58
<annevk>
It can use some work still
20:01
<annevk>
tantek: that's in part why I moved the specs to GitHub, so people can hack on the text
20:01
<annevk>
tantek: two pull requests to date, but I'm hoping it'll go better long term
20:01
<tantek>
annevk - github does lower the barrier to entry to contributing to specs
20:02
<tantek>
I tried (unsuccessfully) to get the CSSWG to "skip" using HG/mercurial and just wait with CVS a bit longer until it was obvious everyone was going to switch eventually to git/github
20:03
<tantek>
to avoid one unnecessary infrastructure transition
20:04
<annevk>
I should have done that in retrospect, but this works
20:04
<annevk>
and porting history was easier starting with hg
20:04
<tantek>
oh ok, that's good then
20:05
<annevk>
SimonSapin: TabAtkins just updated css3-syntax ;)
20:07
<SimonSapin>
annevk: yeah, I just saw that. Thanks for your input ;)
20:23
<zcorpan>
krijn: log page isn't updating properly
20:34
<krijn>
zcorpan: sorry, fixed
20:37
<zcorpan>
someone should make a meme of glenn adams' replies to hsivonen on www-style
20:44
<jgraham>
Hixie: To an excellent approximation, all documents are already invalid, so making UTF8 required for conformance hardly seems like it would make much difference
20:46
<jgraham>
othermaciej: I like your ideas and would like to subscribe to your newsletter
20:46
<othermaciej>
jgraham: which ideas?
20:46
<jgraham>
Or, more specifically, would like to attend your "how to use mailing lists more productivly" session at TPAC
20:47
<jgraham>
(I assume you meant it as a plenary day topic rather than a HTMLWG topic?)
20:50
<othermaciej>
I meant it as an HTML WG topic for HTML WG's use of lists specifically, but it sounds like it could also be a good plenary day topic
20:51
<jgraham>
Well I guess I am happy with either
20:52
<zcorpan>
TabAtkins: "If label is null, set label to the value of charset attribute on the <link> element that caused the style sheet to be included, if any." this could be xml-stylesheet as well (unless i dropped support for charset there? don't recall)
20:53
<zcorpan>
anyway, should probably be more generic or just provide a hook for the html spec to use or so
20:54
<TabAtkins>
zcorpan: Tell annevk, I just reused his text with light rephrasing. ^_^
20:54
<annevk>
TabAtkins: hey, you are responsible now ;)
20:55
<TabAtkins>
I explicitly disclaim any responsibility for encoding.
20:55
<zcorpan>
does step 6 match implementations?
20:55
<GPHemsley>
ALERT: I'm going to be starting the wiki upgrade momentarily. If there are any objections, raise them now. If not, expect the wiki to be a little weird for a while.
20:55
<zcorpan>
i would have expected that a bogus encoding decl falls back to inheriting the encoding instead of falling back to utf-8
20:56
<zcorpan>
or look for the next place that declares a label to see if that's a valid label
20:56
<annevk>
zcorpan: you mean the "get an encoding from label" thing happens between every step?
20:56
<GPHemsley>
Hixie, annevk, AryehGregor: Any objections?
20:56
<zcorpan>
annevk: something like that yeah
20:57
<annevk>
GPHemsley: did you backup?
20:57
<GPHemsley>
yup
20:57
<annevk>
GPHemsley: go ahead
20:57
<annevk>
zcorpan: yeah so if that's the case I guess we need to make things a bit easier
20:58
<annevk>
zcorpan: not entirely sure how
20:58
<zcorpan>
easier in what way?
20:58
<annevk>
zcorpan: maybe introduce "known label" as a concept
20:59
<annevk>
if label is null, set label to the value of the charset attribute on ..., if that is a known label"
21:00
<zcorpan>
oh easier to spec
21:00
tantek
scrolls up, reading about UTF-8 and validity
21:00
<zcorpan>
i don't see why that's easier than the current "get an encoding", offhand
21:01
<annevk>
try to rephrase that using get an encoding
21:01
<tantek>
othermaciej - if you did that as a plenary day topic, I would be very tempted to show up and take notes in order to capture them on the wiki ;)
21:01
<annevk>
you only want to set label if get an encoding does not return failure basically
21:01
<annevk>
at least, it seems to be that's what you're saying, this is all untested thus far
21:02
<tantek>
hmm, I think I would be ok with making UTF-8 required for HTML5 documents.
21:02
<tantek>
is that the basic idea jgraham?
21:02
<annevk>
GPHemsley: any chance we can configure the wiki to not have the redundant /wiki/ thing and redirect the old stuff?
21:02
<TabAtkins>
That would effectively make <meta charset=utf-8> a required part of every document, since documents default to something else.
21:02
<GPHemsley>
annevk: One thing at a time :)
21:02
<annevk>
GPHemsley: not sure if it's worth it btw
21:03
<zcorpan>
annevk: i'd just abort the algorithm once an encoding is found (or jump to the last step)
21:03
<annevk>
TabAtkins: yeah, that or a BOM or a content-type
21:04
<tantek>
annevk - we're actually thinking of making that same change (dropping the need for /wiki/ ) at microformats.org, since the wiki is where the newest content has all ended up, and the other semi-static areas (all in WordPress) are not as interesting.
21:04
<annevk>
zcorpan: still seems like that would be pretty unwieldy
21:04
<tantek>
new community sites are wiki-based but without the /wiki/ , e.g. http://indiewebcamp.com/
21:05
<tantek>
(as used by #indiewebcamp )
21:05
<annevk>
well we already have wiki.whatwg.org
21:05
<annevk>
and then another /wiki/ to boot
21:06
<TabAtkins>
tantek: I didn't even realize there was a non-wiki portion of Microformats.org
21:06
<tantek>
Exactly my point Tabatkins
21:06
<tantek>
in 2005, we used the building blocks for independent community as we best understood them.
21:07
<tantek>
over time we've learned what works and what doesn't, what becomes a good source of the latest "truth" and what becomes a "support forum" ;)
21:08
<annevk>
oh god
21:11
<zcorpan>
annevk: data:text/html;charset=windows-1251,<!DOCTYPE%20html>%0A<link%20rel%3Dstylesheet%20charset%3D"bogus"%20href%3D"data%3Atext%2Fcss%3Bcharset%3Dbogus%2C%40charset%20%26quot%3Bbogus%26quot%3B%3B%20body%3A%3Abefore%20%7B%20content%3A'%C3%A9'%20%7D">x%20
21:11
<annevk>
GPHemsley: well now we know you're maintaining we're gonna spam you of course :-)
21:11
<GPHemsley>
:)
21:11
<zcorpan>
starting point; haven't figured out what actually happens
21:11
<zcorpan>
now i need sleep
21:13
<tantek>
GPHemsely - thanks for maintaining the wiki - greatly appreciated.
21:13
<tantek>
GPHemsley even :)
21:14
<GPHemsley>
don't thank me yet :P
21:19
<zcorpan>
what's up with the whatwg wiki?
21:20
<annevk>
GPHemsley is updating it
21:21
<GPHemsley>
OK, the wiki is back up, but I have to figure out why the short URLs are broken
21:21
<Hixie>
jgraham: that seems a bit harsh
21:21
<Hixie>
GPHemsley: you know abotu the blame.r* files right?
21:21
<zcorpan>
ah
21:22
<GPHemsley>
Hixie: No, where are they?
21:22
<zcorpan>
Hixie: what bad effects would a utf-8 requirement cause?
21:23
<Hixie>
http://www.whatwg.org/specs/web-apps/current-work/blame.r* where the values of blame.r* are: (please hold, your call is important to us)
21:24
<annevk>
tantek: can't find the license of the microformats wiki
21:24
<Hixie>
blame.r0005 blame.r0050 blame.r0500 blame.r0954 blame.r1000 blame.r1250 blame.r1500 blame.r1838 blame.r1863 blame.r1936 blame.r1976 blame.r1980 blame.r2000 blame.r2200 blame.r2216 blame.r2500 blame.r2800 blame.r2905 blame.r2947 blame.r3000 blame.r3075 blame.r3250 blame.r3500 blame.r4000 blame.r4667 blame.r5000 blame.r5287 blame.r5372 blame.r5600 blame.r6000 blame.r6400 blame.r6666 blame.r7000 blame.r7393
21:24
<tantek>
annevk - CC)
21:24
<tantek>
er
21:24
<tantek>
CC0
21:24
<tantek>
it's on every edit that's done
21:24
<zcorpan>
maybe there would be more stuff being mislabeled as utf-8 when it's not in fact utf-8
21:24
<tantek>
since the end of 2007
21:25
<annevk>
tantek: but it's not stated anywhere visibly
21:25
<tantek>
every edit since then was a required public domain contribution per Creative Commons, forward compatible with CC0
21:25
<Hixie>
zcorpan: just seems like make-work for people who are happily using win1252 or whatever.
21:25
<tantek>
it is on the Copyright page
21:25
<Hixie>
zcorpan: not saying that utf-8 shouldn't be _strongly_ recommended, but still, non-utf-8 still works
21:26
<annevk>
tantek: link? cannot find that
21:26
<zcorpan>
Hixie: only if you don't mind being limited to ascii for new features where we require utf-8
21:26
<Hixie>
zcorpan: like what?
21:26
<zcorpan>
like workers
21:26
<Hixie>
can't put html in workers
21:27
<tantek>
annevk: LMGTFY microformats copyright http://microformats.org/wiki/Microformats_Wiki:Copyrights
21:27
<GPHemsley>
Hixie: Ah, very nice, thanks!
21:27
<tantek>
:)
21:27
<zcorpan>
Hixie: so? you can put text in a worker and send text from an html page to a worker
21:27
<annevk>
tantek: I guess Google would have been a better choice than using the microformats wiki search
21:27
<TabAtkins>
"
21:28
<TabAtkins>
"can't put html in workers" yet.
21:28
<tantek>
Google > MediaWiki search feature
21:28
<tantek>
I don't search wikipedia
21:28
<tantek>
I search Google for wikipedia term-that-i'm-looking-for
21:28
<GPHemsley>
Yay! Wiki is back
21:28
<tantek>
Yay!
21:28
<Hixie>
zcorpan: by that point it's UTF-16, so that seems like a non-issue
21:29
<GPHemsley>
If anybody finds any problems, let me know.
21:30
<zcorpan>
Hixie: not when the author writes the worker and the html page in a text editor and saves them both as win1252
21:30
<tantek>
still, annevk, it's a good point, and more discoverability helps.
21:30
tantek
goes to create some redirects
21:31
<annevk>
GPHemsley: MIT License image seems broken
21:31
<GPHemsley>
annevk: Link?
21:31
<tantek>
ok, wiki search for copyright should work again
21:31
<tantek>
er, should work *now*
21:31
<Hixie>
zcorpan: well we already require that workers be utf-8, so if they're already ignoring that, surely they'll ignore our requirement for HTML too
21:31
<annevk>
GPHemsley: oh, it doesn't link anywhere
21:31
<GPHemsley>
annevk: BTW, MediaWiki docs seems to discourage having the wiki at the top level
21:32
<annevk>
GPHemsley: footer could use some cleanup in general
21:32
<annevk>
GPHemsley: mkay, guess we can keep it this way, but it's rather ugly
21:33
<annevk>
Hixie: the idea is just to align the requirement so the message becomes a lot simpler
21:33
<zcorpan>
Hixie: that's not what i'm trying to say. :-) i mean Joe will be happy with win1252 until he tries to use workers, where non-ascii don't work for him. either he'll switch everything to utf-8 or just use ascii for the worker.
21:34
<Hixie>
zcorpan: i'm all in favour of us pushing Joe to UTF-8 everywhere. But I think saying you just can't use Win1252 or whatever, when it's working fine, is way more drastic than necessary.
21:34
<Hixie>
the validator could give a big-ass warning
21:34
<zcorpan>
ok
21:34
<annevk>
it's fine until you put a <form> in your page
21:35
<annevk>
or a link with a query string to another server
21:35
<annevk>
it's not really fine
21:35
zcorpan
*poof*
21:36
<Hixie>
that was an unconvincing disappearance :-P
21:36
<Hixie>
annevk: what's wrong with having a form in the page?
21:37
<annevk>
Hixie: user entering non-windows-1252 code points
21:37
<annevk>
Hixie: could be even worse if the forms contents are submitted through XHR to the server (will use utf-8)
21:38
<annevk>
there's so many encoding traps
21:39
<Hixie>
those codepoints just get collapsed into other text, right?
21:39
<annevk>
for <form> submission the server will get some HTML entity looking like things which it cannot distinguish from actually entered HTML entities
21:40
<annevk>
for <form> submission through XHR the server will get utf-8 which it might not know how to deal with considering it is outputting windows-1252
21:41
<Hixie>
yeah, well, like i said. we should encouarge people to use utf-8.
21:43
<jgraham>
All a validator can do for anything is issue "big-ass warnings"
21:43
<jgraham>
Some of them will be marked "error", but that isn't strongly correlated with them actually producing erroneous behaviour
21:44
<jgraham>
It does, however, seem very odd not to use the warning marked "error" in a case where erroneous behaviour is quite likely
21:46
<tantek>
Hixie, how hard is it to get form submissions to use UTF-8?
21:47
<Hixie>
as an author? not hard at al
21:47
<Hixie>
l
21:47
<tantek>
URL?
21:47
<tantek>
(of explanatory example)
21:47
<annevk>
tantek: <form accept-charset=utf-8>
21:47
<tantek>
does anyone do it?
21:47
<Hixie>
http://www.whatwg.org/specs/web-apps/current-work/#attr-form-accept-charset
21:48
<annevk>
tantek: submission as utf-8 with the page on which the submitted results might be shown not as utf-8 is a major no-no though
21:48
<annevk>
tantek: which is why I think usage of accept-charset is a clear sign of something being broken too
21:48
tantek
googles for the equivalent with "multipage"
21:48
<Hixie>
just stick multipage/ in front of the #
21:48
<Hixie>
it autoredirects
21:48
<tantek>
oh nice
21:49
<Hixie>
http://whatwg.org/html#foo will redirect to 'foo' in the multipage copy
21:49
<tantek>
wow that's a poorly named attribute
21:49
<Hixie>
(or, use a browser that can handle the spec :-P )
21:49
<annevk>
<form accept-charset> is like <link charset> or <script charset>, hacks for a bygone era
21:49
<tantek>
"accept" to specify what you're *sending* ?
21:49
Hixie
points to the /topic
21:49
<jgraham>
It's the charset the form accepts, obviously :p
21:49
<tantek>
hey if we can rename IRI to URL, why can't we fix this? ;)
21:50
<Hixie>
because software doesn't care what URLs are called, but does care about what attributes are called :-P
21:50
<jgraham>
In other news, insofar as a list of "features at risk" makes sense at all (it doesn't) how did register*Handler get on it?
21:51
<annevk>
tantek: the fix here is to just obsolete the attribute
21:51
<Hixie>
i hope the Navigation algorithm and Window objects are "at risk"
21:52
<jgraham>
Hixie: No, but if one believed The Process I think they would be
21:52
<jgraham>
I don't recall if the 2014 document tries to get around this somehow
21:52
<Hixie>
my suggestion on this utf-8 thing, btw, is to wait until utf-8 is more like 90% of the web, and then remove all the charset nonsense and just require utf-8 everywhere
21:52
<Hixie>
we're getting there
21:53
<jgraham>
(I am not of the opinion that the right thing to do here is to demonstrate how silly the process is by gutting the spec)
21:53
<TabAtkins>
Any clue what %age we're at already?
21:53
<annevk>
Hixie: until then you can make it a wilful violation of the Encoding Standard? :-)
21:53
<Hixie>
2010 we were just under 50%, rising quickl
21:53
<Hixie>
y
21:53
<Hixie>
annevk: yup :-P
21:53
<Hixie>
jgraham: we're long past the htmlwg doing "the right thing"
21:54
<tantek>
is there a <meta> for setting accept-charset on forms in the document to utf-8 by default so that authors don't have to remember to specify it for every form explicitly?
21:55
<TabAtkins>
Doesn't a document charset percolate to the form?
21:55
<say2joe>
in reference to the recent url (spec) (http://www.whatwg.org/specs/web-apps/current-work/#attr-form-accept-charset), I've long been confused by the use of the LABEL element. Why is there such rampant use of including input elements within labels? Would it not be more semantic to use <label for="controlName">My label:</labe><input name="controlName" /> rather than <label><input /></label>?
21:55
<jgraham>
Well it seems to me that whatever The Right Thing is, dropping features that have three mostly-interoperable implementations is rather obviously the wrong thing
21:55
<tantek>
TabAtkins - my understanding is that it doesn't, and that forms are weird that way.
21:55
<TabAtkins>
say2joe: What do you mean by "semantic"? The two are exactly equivalent.
21:56
<jgraham>
But I can't see that Opera (or anyone else!) has released their tests, so I will need to fix that
21:56
<say2joe>
IMO, a label should be just a label… and, not include a control.
21:56
<say2joe>
but people often omit the for attribute and wrap the label around an input control element.
21:56
<tantek>
because it's easier to maintain
21:56
<tantek>
no additional for/id attr to maintain
21:57
<TabAtkins>
say2joe: Yes, and there's nothing wrong with that. Wrapping an input in a label is *exactly the same*, semantically, as using an id to target the label.
21:57
<Hixie>
say2joe: it is defined as being equivalent in the spec
21:57
<say2joe>
they both work, obviously, but I prefer to only include the label within a label element… since it is supposed to be just a label.
21:57
<Hixie>
say2joe: it's not support to be just a label
21:57
<TabAtkins>
You're allowed to do that. But there's nothing wrong with the other way.
21:57
<Hixie>
say2joe: it's supposed to be a label and optionally the labeled element
21:57
<Hixie>
s/support/supposed/
21:57
<say2joe>
i was just hoping to get some feedback on why it seems the label element is so flexible.
21:57
<tantek>
where does it say it's supposed to be "just a label"?
21:57
<tantek>
citation?
21:57
<say2joe>
Hixie: I understood (supposed). np
21:57
<Hixie>
say2joe: it's flexible because that's more convenient :-)
21:58
<say2joe>
uh… the element name is label.
21:58
<Hixie>
the element name could be <pineapple>, that wouldn't change a single thing about its meaning :-)
21:58
<tantek>
reasoning from element name failed in HTML long ago
21:58
<say2joe>
i'm just inferring that it should be just a label.
21:58
<say2joe>
tantek: good point.
21:58
<tantek>
e.g. <address>
21:58
<Hixie>
<hr>
21:58
<tantek>
lol
21:58
<TabAtkins>
say2joe: And several people, including the author of HTML5, are saying that your inference is wrong. ^_^
21:59
<say2joe>
:) I'll drop the subject… but, i've brought this up to junior developers as my sense of properness… if one can be so bold.
21:59
<annevk>
tantek: document charset does set the <form> charset
21:59
<tantek>
wherefrom that "sense of properness"?
21:59
<annevk>
tantek: so you should just use <meta charset=utf-8>
21:59
<tantek>
ok cool, thanks annevk
21:59
<TabAtkins>
Given the convenience of wrapping inputs in labels, and the fact that there is *absolutely nothing wrong with it*, I'd strongly recommend against teaching people that using for/id is the "correct" way to do it.
21:59
<say2joe>
label (IMO) should just contain a label… that to me is proper… and more semantic.
21:59
<tantek>
and yes, then it *is* odd to have pages which display in one charset and submit in another :/
22:00
<Hixie>
say2joe: you have to read the spec to find out what elements mean... the element names have very little bearing on it
22:00
<Hixie>
say2joe: imagine all the element names to be opaque strings
22:00
<tantek>
what do you mean by more "proper" ?
22:00
<TabAtkins>
say2joe: You keep using the word "semantic", but you're using it in a way that suggests you don't really understand the definition. ^_^
22:00
<say2joe>
tantek: "label (IMO) should just contain a label… that to me is proper… and more semantic."
22:00
<tantek>
TabAtkins - ob-princess-bride
22:00
<TabAtkins>
say2joe: Semantics are just a contract between you, the page author, and the browser. A common language for you to communicate with the machine on the other end.
22:00
<say2joe>
semantic means contextually appropriate (to me)
22:00
<TabAtkins>
Nothing more, nothing less.
22:01
<Hixie>
the "semantic" of an element is what the spec says the element means
22:01
<tantek>
say2joe - I saw your statement about proper and semantic
22:01
<TabAtkins>
<label> communicates the same thing to the browsers whether it's wrapped around an input or uses for/id to link itself manually.
22:01
<Hixie>
not what the name makes it sounds like it should mean
22:01
<tantek>
I'm still wondering what you mean by "proper"
22:01
<tantek>
what values does it represent?
22:01
<tantek>
or principles?
22:01
<Hixie>
much like how "inflammable" doesn't mean the opposite of "flammable", despite it sounding like it should -- it means what the dictionary says it means
22:01
<GPHemsley>
annevk: I don't suppose you could add me to the wiki administrators group?
22:02
<Hixie>
wait, you reinstalled the wiki and aren't in the admin group?!
22:02
<Hixie>
what are we doing to you
22:02
<tantek>
different admin groups
22:02
<say2joe>
I understand that both methodologies are in common use (perhaps, my preference, being less so). anyway, I've gotten the feedback I desired, I suppose.
22:02
<Hixie>
ooh, new wiki is pretty
22:02
<jgraham>
krijn: Your clock seems to be 10 minutes in the future
22:02
<annevk>
GPHemsley: how do I do that?
22:02
<annevk>
Hixie: GPHemsley found a backdoor I guess :)
22:03
<Hixie>
GPHemsley: what's your username
22:03
<GPHemsley>
Hixie: GPHemsley
22:03
<krijn>
jgraham: problem?
22:03
<GPHemsley>
:P
22:03
<Hixie>
GPHemsley: done
22:03
<GPHemsley>
thanks
22:03
<Hixie>
dude, thank _you_
22:03
<GPHemsley>
:)
22:04
<Hixie>
seriously
22:04
<jgraham>
Why isn't the wiki linked from whatwg.org?
22:04
<Hixie>
it isn't?
22:05
<Hixie>
oh, the boxes
22:05
<Hixie>
i rotate them around irregularly
22:05
<annevk>
jgraham: FAQ/IRC are wiki links
22:05
<annevk>
Hixie: could replace News with Wiki; blog is not maintained :/
22:05
<Hixie>
hm yeah, we haven't blogged in a while
22:05
<jgraham>
annevk: Yeah, OK but the front page isn't linked
22:06
<jgraham>
Seems reasonable to link to the wiki under the title "Wiki"
22:06
<Hixie>
what should the text be below the link
22:07
<krijnh>
00:19:22
22:07
<jgraham>
"Otherwise tantek gets grumpy"?
22:07
<Hixie>
hah
22:07
<Hixie>
reload
22:07
<Hixie>
if anyone blogs let me know and i'll switch it back to the blog
22:08
<jgraham>
You could just add an extra link :)
22:08
<tantek>
hah - I'm not sure how useful it is to link wiki to wiki
22:08
<Hixie>
don't want to have too many
22:08
<tantek>
I mean, if everything is just moving to the wiki anyway...
22:08
<tantek>
wouldn't that just be "home" ?
22:08
<groms>
whattf.org is still hanging around :)
22:08
<krijnh>
00:10:01
22:08
<krijnh>
#thereifixedit
22:09
<tantek>
thanks krijnh
22:09
<annevk>
tantek: I was not talking about moving the wiki from wiki.whatwg.org to whatwg.org; just /wiki/ to /
22:09
<tantek>
how about dropping the subdomain instead?
22:09
<jgraham>
Well on the screen I currently have, 9 links take up the same space as 10
22:09
<tantek>
redirect wiki.whatwg.org/wiki/ to whatwg.org/wiki and serve it from there
22:09
<Hixie>
ew
22:10
<tantek>
subdomains are lame anyway
22:10
<tantek>
hierarchy inversion and all that
22:10
<jgraham>
You must hate html.spec.whatwg.org
22:10
<tantek>
usually indicate of corporate org charts
22:10
<Hixie>
putting aside the issue of subdomains being cooler than subdirectories, the more practical reason why we have subdomains is that we can more easily give people access to admin parts of the server
22:10
<tantek>
jgraham, meh. github is nicer than mecurial
22:10
<Hixie>
e.g. the way GPHemsley just updated the wiki
22:11
<tantek>
right, subdomains are political
22:11
<tantek>
they help you keep organizational silos
22:11
<jgraham>
They are also nice from the point of view of the SOP
22:11
<jgraham>
Although that might not be so important in this case
22:11
<groms>
vhosts, lovely things
22:12
jgraham
is still failing to figure out the github vs mercurial comment
22:12
<jgraham>
(it isn't even comparing two like entities)
22:13
Hixie
waves a svn flag quietly in the corner
22:14
<groms>
sccs
22:14
jgraham
hopes it's the white flag of surrender
22:15
<Hixie>
hey HTML is still done on subversion :-P
22:15
<jgraham>
Not at the W3C :p
22:16
<jgraham>
But I should be asleep. Good night / morning / afternoon, everyone.
22:56
<Hixie>
GPHemsley: everytime i read "republications" i read it as "republicans"
22:56
<Hixie>
i've been reading too much politics news, clearly
22:57
<GPHemsley>
I had a similar experience :)
23:08
<annevk>
GPHemsley: there's also minor spin-offs; parts of HTML ended up in the DOM and the Encoding Standard
23:08
<annevk>
(well actually, the latter has yet to happen fully)
23:08
<GPHemsley>
annevk: If you have a revision number, feel free to put it in the list. I'll investigate it later.
23:09
<GPHemsley>
(Right now I'm looking for some good extensions to install on the wiki. :) )
23:09
<annevk>
oh interesting
23:09
<annevk>
you're tracking revisions
23:09
<Hixie>
annevk: was there any attempt at doing the work that ended up in the encodings spec at the ietf/iana?
23:10
<annevk>
le me get you some references and then I'll get some sleep
23:10
<GPHemsley>
annevk: Yeah, I figure it's useful for archaeology; that way the work only has to be done once
23:10
<GPHemsley>
And there's no question about what happened
23:12
<GPHemsley>
Also, just to confirm: The only reason user creation is set to manual is to combat spam, right? So if better methods to combat spam were available, they would be preferred?
23:12
<annevk>
http://mail.apps.ietf.org/ietf/charsets/threads.html#01830 shows mostly disinterest so by my next thread I did the work http://mail.apps.ietf.org/ietf/charsets/threads.html#02027
23:12
<annevk>
http://mail.apps.ietf.org/ietf/charsets/threads.html#02034 was the last thread before I unsubscribed
23:12
<annevk>
Hixie: ^^
23:12
<Hixie>
annevk: oh, cool, thanks. didn't expect so much data :-)
23:13
<annevk>
Hixie: if you want to reply to James btw, http://wiki.whatwg.org/wiki/IETF
23:13
<annevk>
Hixie: I'm not subscribed to the uri list and he did not include me, but that would've been my answer
23:13
<annevk>
along maybe with some pointers to past attempts at "fixing things via them"
23:14
<Hixie>
k
23:14
<annevk>
GPHemsley: yes
23:14
<GPHemsley>
k
23:14
<annevk>
GPHemsley: e.g. if you don't mind deleting spam accounts that works too
23:14
<annevk>
I was mostly doing it for a while and grew tired of it
23:14
<GPHemsley>
annevk: Well, there are wiki extensions that combat spam that I could install.
23:15
<annevk>
that'd be awesome too
23:15
<GPHemsley>
I don't know how effective they are, though, so I wanted to make sure re-enabling regular user registration would be OK.
23:15
<annevk>
it's totally fine to try those things without asking
23:16
<annevk>
we hate the current process too
23:16
<annevk>
GPHemsley: thanks for all the work so far btw
23:16
<annevk>
GPHemsley++
23:16
<annevk>
nn
23:16
<GPHemsley>
:)
23:17
<Hixie>
indeed
23:17
<annevk>
GPHemsley: we mostly operate on ask forgiveness rather than ask permission, but people seem to like asking permission around here :)
23:17
<annevk>
really nn now :p
23:18
<GPHemsley>
I'll keep that in mind.
23:18
<GPHemsley>
Have a good night.
23:55
<GPHemsley>
FTR, I have generated whatwg.org reCAPTCHA keys. Not sure if anyone will want to use them outside of the wiki.